|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Friday, 8 June 2001||Author: IRC Staff|
|Published to: interact_articles_irc_recap/IRC Recap||Page: 1/1 - [Printable]|
|Page 1 of 1|
<Wintersun> Thank you for coming to our event today, part of the Author Talks Series
<dori> Of course, if they want questions answered, that requires the book.
<Wintersun> If you have any questions, please /msg them to Dazman and he will ask them for you. Thanks!
<Wintersun> dori, would you like to start by saying something about your book?
<dori> First, thanks for coming, everyone!
<dori> It doesn't assume that you know anything at all about programming, and walks you through useful scripts slowly, but it's also handy for techies who just want to pick up a book, find out how to do some task, and put it down again without having to deal with tons of theory.
<dori> Anyone have a specific question?
<Dazman> From lazarus.
<Dazman> From lazarus: lynx, whatever doesn't require X11 or aGUI
--- Dazman gives channel operator status to lcModerator
<lcModerator> How much have you been involved with Linux?
<dori> I actually haven't had a lot of Linux experience; it's one of those projects that I keep planning on getting around to. I've got the box ready to go, but paying gigs keep me too busy to actually load it on there.
<lcModerator> What nix experience do you have?
<dori> Most of my nix experience is ancient, from back when I worked on workstations back in college. I've been messing around with Mac OS X lately, though, with is UNIX under the hood.
<dori> Sorry, folks, not a linux geekette. <g>
<dori> This is actually one of the coolest areas around, imo.
<dori> They've completely changed the way I use the web, and all with just a line or two of code.
<dori> You can find out more about them at www.bookmarklets.com (I'm not affiliated with them, just a happy user).
<dori> The first programming language I used, would be BASIC, back in 1977 (hey, don't laugh, it was what my high school had, okay?).
<dori> Now there's an interestingly phrased question...
<dori> Overall, I tried to keep the programming simple enough that it should work anywhere.
<dori> I don't like code that checks browser by browser and version by version to see if something can be done; instead, I show how to check by looking to see if objects exist.
<dori> Did that answer the question?
<lcModerator> Yes :)
<dori> It's not really a feature by feature type of book; more of a "Here's a bunch of useful things that you can do" cookbook.
<dori> Thankfully, the browser makers have listened to the screaming that happened everytime they shipped a non-standard browser, and have started working on making their browsers more standards compliant.
--- Wintersun gives channel operator status to lcModerator
--- Wintersun gives channel operator status to [Dazman]
<dori> Bloodline, if you have a question, do it through the moderator.
<dori> It depends on what you think the future is of non-MS OS's and browsers. If you think that everyone, everywhere, is going to change over to Windows and IE, then .NET is the way to go. If you want your stuff to work cross-browser and cross-platform, though, it's a waste of time.
<dori> I'll look at .NET when something real actually ships; until then, it's just more MS FUD (imo).
<lcModerator> What do you think about the future of properitary software in general, do you see Open Source software as the evolution of software in general. And how can a properitary software company compete with open source software that is BETTER, and FREE?
<dori> Was there actually a question there, or just a statement?
<lcModerator> i think v3 intended it as a question...
<dori> I think that many other people have discussed the economics of free software in book length form, and I'm not really going to go into it all. But I do have to ask: when is Mozilla going to ship?
<lcModerator> What do you think about the future of properitary software in general?
<dori> Proprietary software will do just fine, so long as the alternative is (like Mozilla) late, bloated, and buggy.
<dori> Paranoid people also turn off cookies, and most ecommerce and web apps require them. Paranoid people also remove the radio from their cars so that the Men in Black can't send them hidden messages. Their loss.
<lcModerator> going back to the browser question...
<lcModerator> as far as non-MS browsers are concerned, they have already failed, with IE controlling more than 80% share of the browsers and netscape 6 already showing signs of failing, and the Mozilla project also has failed to deliver, what do you say about that?
<dori> OTOH, at any time AOL could ship out 10 gazillion CD's with Netscape, and the stats would change literally overnight.
<dori> Flash is what, a $300 product vs. something that's free? Yeah, you can do cool things with Flash and AS, but that's a steep price to have to pay. SVG is a whole 'nother thing, and I'm not holding my breath on that one.
<lcModerator> (rather than mandatory)?
* lcModerator apologises for the poor copy and paste :)
<dori> And if the annoying popups annoy you, stop visiting pron sites. <g>
--- muks is now known as muks_away
<lcModerator> Most popular sites actually use URL based sessions rather than use cookie based sessions. Their site functionality does not require cookies to work (i.e. amazon). How can you justify to a customer "Hey, it's your customers loss if they cant view the site as you intend to" when dollars might be flying from their pockets
<dori> URL-based sessions have their own problems, though. What happens if you're halfway through a shopping visit, have a cart full of stuff, and the phone rings with an important call? You get back an hour later, and your cart has expired and you've lost all that time. A cookie, though, could have saved that info. Every type of functionality has its pros and cons.
<lcModerator> Well, that was the last of the questions sent to me... Thank you dori for coming along today. :) I will now unmoderate the channel, to allow anyone else wishing to ask a question to do so. Thanks again :)
--- lcModerator sets mode -m
<dori> Thanks all!
<lazarus> or is security only for the server, not the "ecommerce" client?
<brw> dori: Do you follow BugTraq?
<brw> dori: Many of these issues have been documented there.
<nate37> brw: your script can read it, but how would YOU read it
<dori> You can read the files (maybe, in certain circumstances), but you can't write them back out again. So, how is anything compromised? Again, you need CGI to actually do any writing.
<brw> I read a "secure" system file, say something with respect to a password file or something else. I then redirect to a page which saves that information for me.
<brw> CGI writes the info, yes
<brw> you code that in your script
<brw> the security hole allows access to it
<dori> You keep saying "the security hole". What security hole?
<lazarus> /etc/shadow is a fairly well-known /path/file, and there are many others to check for
<dori> Yep, and you can get there just fine by writing a CGI to get there.
* brw is looking up on securityfocus hang on
<brw> you know, lets move away from browsers for a moment
<brw> I am having problems finding the browser issues I remember
<dori> Couldn't find anything, huh?
<brw> working on it, dont get so defensive.
<dori> Nah, I'm laughing, I've been through this discussion a few times before.
<brw> well I am glad.
<brw> lets take a look at this article
<dori> That's OE, which is another thing altogether. Anyone who uses OE/Win is has a giant target pasted on their forehead (imo).
* lazarus agrees with cdlu
<Woad> brw: try here http://www.cen.uiuc.edu/~ejk/browser-security.html
<brw> there ya go dori:
<brw> Now I can find them
<brw> you dont need specific commands to read files because file reading is supported in URLs
<Woad> Juan Cuartango reported a flaw in MS Internet Explorer JScript that could allow a malicious server operator to read file's with known names from the
<Woad> user's hard drive after the user merely visits the malicious page.
<Woad> i remember that one
<brw> waod: That is the one I was looking for. :) The Cuartango bug.
<brw> unless you are going to use it in the same manner applescript is used for, simple shortcuts around your system.
<brw> noone is putting those words into your mouth
<Woad> well if you turned off all client side scripting languages/plugins/etc, I don't think there's any html exploits :)
<cdlu> nah, <marquee> is a security hazard! :P
<nate37> brw: hah yea
<dori> Oh, those are just stupid. I give how to do it in the book, along with an entire sidebar on why this is a dumb idea.
<brw> Unless you are in complete denial, you should agree with this.
<brw> woh woh, back up
<jericho> you don't even need server side scripting with flash
<brw> Java script opens the door!
<brw> That is like saying, Drunk Drivers dont kill anyone without cars.
<brw> CGI is run on the server and does not mess with the client.
<Woad> CGI is just the mechanism, the client side issue is the instigator
<brw> Not sure how many different ways it can be said, but if you still are in some sort of denial, I am sure we might come up with a few :)
<Assembler> dori: what do u think about the Opera JS implementation?
<brw> because you cant execute cgi on the client side
<brw> it is as simple as that
<brw> do you not know what CGI is or something?
<brw> you do understand that CGI is executed on the server right?
<brw> that restricts interaction with the client to port 80 communications
<dori> Opera? So close, but yet, so far. They tried to implement MS's document.all object, but didn't do it correctly/completely. Now, most of my scripts don't work in Opera because they assume that if document.all exists, it has certain properties. Grr.
<Assembler> eheh thxs dori :)
<dori> brw: yes, dear, I know what CGI is. And yes, I know that 100% of these exploits require *something* on the server side. While it's handy to have something on the client-side, it's not required, really.
<Woad> ashame, opera is an awesome browser
<brw> dori: Heh that statement just demonstrates that you have no idea what CGI is.
* Felix agrees with brw
<Felix> yepp :)
<Felix> thx nate
<jericho> you can't. so, so
<dori> Open a frameset, and have the page be 99% what they're expecting, and some small part be the file that you're trying to snag.
<dori> Or, use an image bug.
<dori> Or, or... there's a million and one ways to do this, if you know something about CGI.
<lazarus> but doesn't an image bug require cookies?
<lazarus> and who allows cookies through these days exceppt winlamers?
<Felix> dori: this window just created is meant to actually _hide_ a message box behind it
<brw> And most of those require further interaction of the user
<dori> Depends on what you're trying to do with an image bug. Yep, cookies is another way to do this.
<brw> whereas the curtango bug does not. And is much worse. YOu cannot access files on the local file system via CGI.
<brw> simply not possible
<lazarus> jericho: apparently, since i don't have a GUI on the box
<Felix> dori: a message box generated by windows(tm)...
<nate37> brw: its possible.. just would require another exploit in the browser :)
<jericho> but that doesn't mean it is useless
<dori> brw's problem seems to be a lack of imagination <g>
<lazarus> jericho: no, it's worse
<brw> dori: Hah, your problem seems to be a lack of knowledge
<nate37> brw: such as a backdoor that when give "Location: GIVE ME DAMN PASSWORD FILE" the browser would return /etc/shadow :)
<jericho> worse for unix users
<lazarus> jericho: its use prevents me from getting onto my isp's lame dsl "dashboard"
<Felix> dori: you're SOL, imho
<nate37> brw: and HTML isn't?!
<lazarus> jericho: and after all, the context here IS linux.com's #live :)
<brw> HTML is a markup language, not a scripting language.
<nate37> brw: if the browser had the tag: <give_me_damn_password_file to="myevilcgiscript" method=post>...
<nate37> brw: or if it would be:
<nate37> <form name="myform">
<nate37> <input type="hidden" from_file="/etc/shadow"> (i know from_file doesn't exist.. but lets pretend its an exploit)
<brw> heh, but that is the entire point. those kinds of things cant happen.
<nate37> ermm <form name="myform" method=post action="mycgi.cgi">
<brw> just like you cant get water from a rock, you cant get local user files from HTML.
<nate37> if html doesn't allow reading from a file
<jericho> how about an include("$link"); when link passed throught url = "../../../etc/passwd" ? ;)
<nate37> and javacsript doesn't allow reading from a file
<brw> nate: go read that url above
<Woad> nate37: say such a browser exploit existed, cgi is not the instigator, you could format that code with simple html files
<brw> jericho: keep in mind that those are server side exploits
<Woad> all cgi does is run something *server* side, and spit back html, just like any other web page
<nate37> Woad: i know what cgi is
<jericho> no, mines split back xml, though
<nate37> Woad: i'm talking mainly client-side so then i can compare a theoritcal exploit in cgi
<brw> but that is my whole point
<nate37> brw: which?
<lazarus> "spit back text (probably with tags)"
<Woad> nate37: point is it's *not* a "cgi exploit"
<Woad> that would be a browser exploit using HTML, you would not need server side CGI to do that
<nate37> brw: and back to why i orginally said...
<nate37> ermm what i orginally said
<dori> nate37: that should be <form><input type="file" name="whatever"></form>. Get them to somehow submit the form, and you're in business.
<nate37> what if there was a "GET_FILE: /etc/shadow\nLocation: Mycgi.pl"...an wayy over simplified exploit.. but it could exist somehow. and that would require cgi
<lazarus> dori: suggestion: add a Security chapter to version 2, as you can see, it would be popular
<nate37> lazarus: heh :)
<brw> nate: Those are not client side exploits
<brw> nate: You might want to read some of the RFCs that talk about the HTTP protocol and CGI
<Woad> nate37: you are thinking about it wrong. what if there was an browser/html exploit that caused /etc/passwd to be POSTed to a new user signup page on my.yahoo.com's cgi?
<brw> I understand your argument, but it is not valid because you are talking about things that dont exist.
<Woad> that's not yahoo.com's cgi exploit
<Woad> that's the browser's issue, cgi has got nothing to do with it
<nate37> brw: (1) they are client exploits since the browser IS interpretting the headers...
<brw> nate37: they are not exploits because what you are talkiung about is not possible
<lazarus> Woad: let's make it more plausible, the next time hotmail.com is cracked, change their new user cgi to ... :)
<Woad> that's not a 'cgi exploit' either, that's a hacked server :P
<jericho> i discovered one of the most 'dangerous' client side exploit yesterday :)
<nate37> brw: its possible, but unlikely.. but ya never know what MS puts in their browsers :)
<Woad> they could change the html too, and it wouldn't be an 'html exploit' :P
<jericho> only works on ie4+/win32 though
<lazarus> Woad: yeah, but you'd have to add some exploit code to the cracked server, not just "kilroy was here" defacement
<brw> nate: heh, well while you have a point there, it is still not possible :)
<nate37> brw: :p
<Woad> lazarus: and the malicious code would have to make the users browser do something it wasn't meant to do. hence, the problem lies in the browser's interpretation of the code. hence, it's a browser exploit
<Woad> the mechanism for delivery of the malicious code is irrelevant
<jericho> browser exploit, true
<Woad> it would not need to be cgi
<Woad> sure ;)
<brw> welp, I am out folx. seeyas
<lazarus> running something someone else hands you, that's the problem
<Woad> well it's 2 part, you trust the server's code, and you trust your browser vendor to interpret that code correctly
<Woad> moreso i think the fault lies in the browser vendor
<Assembler> cu all
<Assembler> thxs dori
<lazarus> what was that *.ini thing that mirc executed? same principle, don't trust other ppl's code, it's asking for trouble
<jericho> i'm off
<dori> Thanks all--I was supposed to be out of here an hour ago. Bye bye.
<lazarus> basically the presumption these says should be "assume everything foreign is hostile"
<Felix> lazarus: unfortunately yes
<lazarus> felix: gone are the days of .plan
<lazarus> okay, this client is no longer behaving, tab completion is dead, for one, and with my typing, i should remedy that
<Felix> lazarus: at _that_ point of time, I didn't even own a pocket calculator... *g*
<Woad> but by that token, you should never receive data from the 'net. ie. can't even browser web pages cause you might catch malicious html code that your browser vendor has a security problem with :)
<Woad> err browse web pages
<Felix> woad: pure html doesn't do any harm, does it?
<Woad> not that anyone has discovered afaik, but I was just feeding off the examples
<Woad> but it's theoretically possible to do weird stuff to browsers with anything it interprets
<BB> depends if the renderer has a bug in parse, image display or whatever.. possible though
<Woad> buffer overflow an html tag ;)
<Felix> woad: use telnet www.somedomain.com 80 and parse the html in your head then... ;)
<Woad> well I'm not worried about exploits. this is why you run things as a 'user' :)
<Woad> severity of possible exploits is now much less severe to the point I don't worry too much browsing the 'net
<Felix> it could still read e.g. your browsers history for that user
<Woad> nod. that's also why I keep track of exploits
<Woad> but at least I don't have to worry about what the windows users do
<Woad> like box rendered inoperable cause i browsed a web page ;)
<Felix> MS is great when it somes down to marketing, but the neither do stability nor security... *sigh*
<Felix> hallo miro
<Woad> MS is getting better.. it's just an extremely slow and painful process
|Page 1 of 1|