Weekly Edition
Return to the Security pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Killing web browsers - part II
Last week's discussion on
crashing web browsers with random input noted that, of all the browsers
tested, only Internet Explorer survived. Since then, Michal Zalewski has
posted a followup stating that, eventually,
IE fell over as well. So, as Mr. Zalewski put it:
This means that VIRTUALLY EVERY BROWSER IN USE TODAY is unable to
securely render HTML. Keeping in mind that not only web browsing,
but also integrated e-mail is at risk, it is a grim thought.
Grim indeed. It will be interesting to see which browser manages to clean up its act first. Meanwhile, an improved version of mangleme, Mr. Zalewski's testing tool, has been released. This version has been ported to Python (for some reason) and includes some extra tests; its authors claim to have found a different set of IE crashes. (Log in to post comments)
turning crashes into minimal testcases Posted Oct 28, 2004 8:24 UTC (Thu) by aglet (guest, #1334) [Link] This paper is interesting: it describes an automated procedure to take "crashme" input and make minimal testcases. I can't remember if I read it here last week or not, but it seems as if it would be nice to do this for these browser fuzz tests.
duplicate Posted Oct 28, 2004 8:27 UTC (Thu) by aglet (guest, #1334) [Link] yes, it was last week, and the author of the document posted the URL (sorry hildeb); must check before posting:
turning crashes into minimal testcases Posted Oct 28, 2004 11:06 UTC (Thu) by pkolloch (subscriber, #21709) [Link] Admitted, this is sexy stuff. They extended their methodology, have a look at:
http://www.st.cs.uni-sb.de/dd/
(same guy, new place)
Killing web browsers - part II Posted Oct 28, 2004 11:23 UTC (Thu) by danscox (subscriber, #4125) [Link] While certainly it's incorrect behavior for a browser to crash on random input, why has no one seemed to notice it until now? How many YEARS have we been using the "Wild Wild Web" and how many times has it killed our browsers? Apparently, not too often. I think this whole vulnerability has been blown 'WAY out of proportion, given the relevant information. Harumph!
Killing web browsers - part II Posted Oct 28, 2004 12:32 UTC (Thu) by iabervon (subscriber, #722) [Link] Unless someone is actually attacking people, there's no reason to send input this broken, because it won't look like anything useful on browsers which don't crash. Furthermore, crashing browsers isn't really all that bad, provided that they crash cleanly (by referencing a pointer initialized to NULL, e.g.). When I was using an old version of Konqueror, it would crash reasonably frequently, and I'd restart it and avoid the site that did it.
Killing web browsers - part II Posted Oct 28, 2004 14:29 UTC (Thu) by bfields (subscriber, #19510) [Link] While certainly it's incorrect behavior for a browser to crash on random input, why has no one seemed to notice it until now? How many YEARS have we been using the "Wild Wild Web" and how many times has it killed our browsers? Apparently, not too often. I think this whole vulnerability has been blown 'WAY out of proportion, given the relevant information. Harumph! The problem is that these bugs are frequently security holes--for example the browser may be crashing on certain input because a buffer overflow in the processing of that input caused a crucial data structure to be overwritten; but with additional work such a buffer overflow can (and often is) turned into an exploit by crafting just the right piece of data to stick in that crucial data structure. More generally, once a program starts behaving in a way it wasn't designed to, it is difficult to tell whether it still honors the security guarantees it was designed to honor. --Bruce Fields
Killing web browsers - part II Posted Oct 28, 2004 13:09 UTC (Thu) by rmini (subscriber, #4991) [Link] From these results, a good argument can be made for privilege separationfor any applications that deal with "tainted" network data. If we do it for daemons, why shouldn't we be doing it for clients, too? Chroot/jail, subprocesses with restricted capability sets, etc. would greatly enhance security.
Killing web browsers - part II Posted Oct 28, 2004 13:35 UTC (Thu) by bk (guest, #25617) [Link] I could be wrong, but since browsers only run with user privileges anyway separation would not seem to bring any benefits. I was under the impression that privilege separation was only useful for daemons that needed to perform certain well-defined privileged operations such as MTAs, etc.
Killing web browsers - part II Posted Oct 28, 2004 14:45 UTC (Thu) by rmini (subscriber, #4991) [Link] I don't know about you, but having someone delete all my personal files would be a big blow; also running other applications (turning your machine into a spam bot, for example), etc. You don't necessarily need root to cause havoc.
It'd be a different form of privilege separation (same UID, but reduced capabilities via chroot/jail or some other mechanism) than used in, say, a mail server, but the same concept.
Killing web browsers - part II Posted Oct 28, 2004 20:49 UTC (Thu) by kleptog (subscriber, #1183) [Link] Rather nasty problem: most of the operations needed for priveledge seperation are root-only. chroot/setuid/jail etc can only be used by root.
Users as a rule can't fake anything, even if for supposedly good purposes. You might fake a setuid program to do something it shouldn't.
Killing web browsers - part II Posted Oct 29, 2004 14:41 UTC (Fri) by RobSeace (subscriber, #4435) [Link] All you really need to do to accomplish this form of "privilege separation"is to create yourself a separate user account, and use THAT to run your web browser under... Setup sudoers appropriately, and then have your web browser icon launch "sudo -u webuser -H mozilla" (or whatever browser) instead of launching the browser directly... (You'd probably want to setup sudoers so you didn't have to be prompted for a password for this, too, of course...) There, now your browser can only access stuff as this other user; and, presumably, you'd have pretty much NOTHING lying around which that user would have access to modify/delete...
Killing web browsers - part II Posted Oct 29, 2004 18:14 UTC (Fri) by NAR (subscriber, #1313) [Link] There, now your browser can only access stuff as this other user; and, presumably, you'd have pretty much NOTHING lying around which that user would have access to modify/delete...The problem is that the data the browser needs to read/write can be still sensitive - think about passwords stored by Opera's Wand function (and I think Mozilla has something similar)...
Killing web browsers - part II Posted Oct 29, 2004 19:36 UTC (Fri) by RobSeace (subscriber, #4435) [Link] Well, I've always thought those silly "remember all passwords I type"functions were completely stupid, anyway... I never use them... Yes, Moz does have such a thing, but I certainly don't use it, and I wouldn't recommend anyone use it... BUT, I thought it at least encrypted the saved passwords, and required some master password to unlock them? Maybe not... Like I say, I don't use it... If they just leave it lying around in plain-text, then it's a very broken design, in the first place, I'd say... You can't really help people if they TRY to shoot themselves in the foot by using broken-by-design security-compromising features, just to save themselves a little typing every now and then... Such people probably would never even bother going through the trouble of setting up such a separate user system for added security in the first place, since they're obviously not too concerned with security, it seems... But, I'd think there really SHOULDN'T be any need for a web browser to ever access any sensitive info on your hard drive...
|
|||||||||||