IE Shines On Broken Code
mschaef writes "While reading Larry Osterman'a blog (He's a long time Microsoftie, having worked on products dating back to DOS 4.0), I ran across this BugTraq entry on web browser security. Basically, the story is that Michael Zalewski started feeding randomly malformed HTML into Microsoft Internet Explorer, Mozilla, Opera, Lynx, and Links and watching what happened. Bottom line: 'All browsers but Microsoft Internet Explorer kept crashing on a regular basis due to NULL pointer references, memory corruption, buffer overflows, sometimes memory exhaustion; taking several minutes on average to encounter a tag they couldn't parse.' If you want to try this at home, he's also provided the tools he used in the BugTraq entry."
I don't know if they still use it, but the Linux kernel developers used to use a program called "crashme" to help test kernel stability. Essentially, it generated random code and tried to execute it. Something like this for web browsers would make for a very useful procedure. Generate the code, throw it at the browser and log the code if it crashed the browser.
Great, but then it also encourages people to write bad code - see all that code with broken tables and a million tags that remain unclosed?
You're confusing two seperate things here:
This guy has been testing for (2) and not (1). Bad HTML should never cause crashes, memory corruption and buffer overflows. Period.
Finally, you can't go blaming the users for bad input. One of the golden rules of software design is that all software should either reject or handle gracefully bad input. Crashing is not graceful.
Avantslash - View Slashdot cleanly on your mobile phone.
No. I don't care how bad the input is, if my program reads the input and throws an access violation, then it is my job to fix my program, test the input more, assume less about it or whatever, until my program does something more sensible and less dangerous with the input - like giving up with an error message or even an assertion failure.
I repeat: code that crashes with a null pointer error is wrong. End of story.
My Karma: ran over your Dogma
StrawberryFrog
> all the error correction code helps to keep IE bloated and slow.
Bloated compared to what?!
Slow compared to what?
IE has quite a small footprint for a web browser. I've opened this page in IE and Firefox. Currently IE is using 19Mb of ram and Firefox is using 28Mb. In fact, currently the top three processes using the most RAM on my machine are all open source products (the top two being Firefox and the enormously memory hungry Thunderbird which is currently using 58mb of RAM). All the commercial software comes later.
IE also tends to render pages faster than Firefox under most circumstances (except where Linux advocate article authors have carefully crafted CSS heavy pages which cause IE to slow down a bit).
Case in point.
Last week I wrote some Perl to process an mbox mail folder. I just wanted a quick and dirty way to view its contents in a web page. A couple of CPAN modules and a few dozen lines of code and thing was done. Then I started to get fancy and dealing with stuff like embedded MIME-encoded GIF images. This was pretty simple to do, but I made a mistake. Once I had the decoded GIF data lying around, I wrote it to the HTML file of the current e-mail message, rather than writing it to a seperate file and writting <img src="foo.gif"> in the HTML file.
I was viewing the results with Firefox 0.10.1. When it got to a message with an embedded GIF, with a big slodge of GIF binary data sitting in the middle of the page, Firefox either just sat there spinning its hourglass, or crashed and burned.
Then I looked at the same file with IE, and the GIF image showed up. I was puzzled for a while until I noticed that in the directory where I had created the file, no GIF files had been created. It is of course arguable that IE should not have attempted to render the GIF image from the binary data sitting in the middle of the page, but it did so without complaint. Not rendering it would also be acceptable.
Firefox, on the other hand, has a number of better alternatives to crashing or hanging. Should it display gibberish (like when you forget to set up your bz2 association correctly) or nothing, or the image? I don't know, and don't particularly care about which course of action is taken. Anything is better than crashing, especially when IE doesn't.
Anyway, I fixed the Perl code, and all is well.
The End
Idiot. Crashing = denial of service attack.
*Your* first lesson in computer security is, and write this a thousand time: *crashing* on malicious code is *BAD*, whereas *recovering* from the situation and responding with an *error message* is *GOOD*.
This is a simple, nearly infallible rule of detecting exploits, to the point where I even know it. :)
If you can get a program to write past the end of it's allocated memory segment, you can overwrite all sorts of fun stuff with things like shellcode and anything else you want to throw in the executable stack.
The program (I read the SF post yesterday) generates standard things that would confuse a program in HTML - Null (ASCII 0) characters, overly large integers (Opera, IIRC, brought his system to a halt with a giant colspan="" element), things that need to be checked pre-emptively.
Regardless of his "bias", this is a problem. In fact, sometimes the people with the most to gain do a great job giving the others the opportunity to gain instead. Either way, he just upped the bar for browser security, which benefits us all.
Don't just blow him off.
Besides which, as a user, I find it infuriating that Mozilla/Firefox are so stuck up on perfectly standard HTML that they just don't work with some web sites that are perfectly usable in IE anyway.
As a user, I find it infuriating that people write non-standard compliant HTML that only works in one proprietary browser.
Give me Classic Slashdot or give me death!
Does this mean we've all been wrong about Microsoft products?
Actually yes. People here always talk about Microsoft products being buggier than the average, without any evidence to back it up beyond their own prejudices.
They use to laugh at the "much inferior" IE code, until the mozilla project got started and it turned out Netscape had the inferior code base.
OSSers used to laugh at the "bloat" of the windows source code.... until Linux got to have a decent user interface that is, and guess what? source code size is comparable to Windows.
There are many reasons to loathe the evil empire (monopolistic bully for one), but buggy code is not one of them. That is just something OSSers tell each other to feel better about what they do.