Slashdot Mirror
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."
It's quite known that broken code runs quite well on IE.
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?
Thank webmasters (if they can be called that) who tested their code solely on IE for that.
And lately, writing bad HTML has become the norm rather than exception.
I just spent 5 minutes here refreshing the garbage generator, and other than the odd security exception thrown when it tries to access my hard drive, I find absolutely nothing wrong with Mozilla. Memory usage has been nearly constant, and it's not crashed once. Perhaps the testing computer was using an ancient version of Mozilla, or Windows was running too long without a reboot?
Honestly, I'm not seeing the issue here, other than a Microsoft guy throwing around some FUD.
A couple of seconds work would have shown that it is complete bullshit.
I have trouble with some of the "Linux is God" articles but crap like this really should have been let go through to the keeper.
You and the other astroturfers who replied to my post are forgetting one very important detail: HTML is not data, it's code that's interpreted by the browser. Besides, it generally contains subroutines written in several other languages, like javascript, flash, activex, etc. Whenever an interpreter gets invalid code, it should crash. By "crash", I mean aborting, generating a GPF, dumping core, raising an exception, abending, or any other similar expression you want to use.
My point was that the execution must stop at once on invalid code. If the interpreter itself is able to keep working after the crash, with no adverse effects, that's good but not essential. The most important thing is that code execution *must* stop on invalid code, at all costs, without leaving anything in memory that may be executed later.
My cpu also interprets Perl or Java, but they are code, nevertheless. In the same way that a browser determines what to do with HTML, an interpreter determines what to do with interpreted code. It may allocate memory or parse expressions, for instance, in several different ways.
However, the important thing about security is that the interpreter should always keep its own code well separated from the program being interpreted. Or, if you prefer to think about it as "data", a browser should keep its own code well separated from the HTML being displayed.
What the astroturfing POS which generated the story failed to provide is a well-defined procedure to determine if this separation is being maintained. The author stated that some browsers "crash" on being presented with broken HTML, while IE keeps chugging along, but he didn't present any evidence that the compiled code in IE hadn't been contamined by the broken HTML.
Besides some vague mumblings about "potential" exploits, I didn't see any evidence in the article of deleterious effects caused by those browsers "crashing". And I didn't see any evidence that IE survived the same broken HTML without side effects. Anyhow, the evil you know about is better than the one you ignore. It's better to have the browser fail than to have it keep running with a possible exploit.
Guess what? As one of a few thousand web developers.. your opinion doesn't matter 'one-hill-of-beans'. As soon as you realize that its the millions of web surfers that have an important opinion on interoperability.. the better off you'll be.