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."

Comments

An important security sidenote

[Eponymous Cowboy]

Since it may not be obvious to all readers, be aware that when you can make a program crash by feeding it bad data, you can typically further manipulate the data you are sending it to take control of the program. That means a security hole. This is how buffer-overruns work. You can't always do it, but you can think of each way you can crash a program as a little "crack" in its exterior. If you can figure out a way to pry apart the crack, you've got yourself a hole.

So many of these "bugs" in Mozilla, Opera, Lynx, and Links are likely security holes as well.

It is interesting, then, to see that Internet Explorer did so well on this, with its notoriously bad history on security. My first instinct would be that the HTML parsing engine in Internet Explorer was written by a different team of programmers than worked on the rest of the software, and they used proper programming techniques (such as RAII in C++, or perhaps used one of their .NET languages, rather than programming in straight C like the others) which as a side effect prevented such problems.

Let's hope that all these bugs are taken care of in the other browsers quickly before the black hats find ways to make use of them.

Re:An important security sidenote

[LiquidCoooled]

My guess is this was recompiled with the new SP2 compilers?

But I guess I would have to rtfa for that (which I'm gonna do now)

One thing, if it is the compiler thats automagically cleaning up the code, does the gcc compiler support the same optimisations?

If not, why not, if so Woooohooooooo get recompiling.

Re:An important security sidenote

[UfoZ]

or perhaps used one of their .NET languages, rather than programming in straight C like the others

Not likely, since IE was created ages before .NET, and I don't quite think they decided to scrap and rewrite the entire parsing engine since then :)

As for the malformed HTML, it didn't crash my firefox, but I'll try again a couple of times just in case ;)

Re:An important security sidenote

[Anonymous Coward]

Perhaps it was written in Visual Basic and they just recompiled with VB.NET. :-D

Re:An important security sidenote

[InsaneCreator]

My first instinct would be that the HTML parsing engine in Internet Explorer was written by a different team of programmers than worked on the rest of the software

I's say the same about outlook express. Most security holes in OE were due to bad "glue" between components. And if I'm not mistaken, most holes in IE are also caused by bad integration.
It sure looks like the expert programmers create components which are then bolted together by an army of "learn programming in 24 hours" drones.

Re:An important security sidenote

[freedom_india]

I don't get it.

Microsoft Press writes the BEST books on how to write good code like Code Complete; but their "manufacturing" dept. does not follow their own best-practices and produce crap like IE 5.0/5.5.

Re:An important security sidenote

[dioscaido]

Your first instinct would be wrong, at least when it comes to it being built by a separate team. The fact is, as hard to believe at it is, for the past year Microsoft has put in place for every product systematic development techniques that directly target the security of an application (Threat Modeling, Secure coding techniques). Furthermore, this kind of test is standard within Microsoft (feed random inputs to all possible input locations). And once all the coding is done, the source still has to pass inspection through a security group within Microsoft! You can read about this stuff at the secure windows initiative.

And this shift is working. The trend per-product is a significant reduction in security vulnerabilities. That is not to say there aren't any, that would be impossible, but if you look at the vulnerability graph for, say, Win2k Server since it's release, and win2k3 Server since it's release, there is a significant drop in the amount of vulnerabilities that are coming in since the release of the product. Furthermore, a large part of the vulnerabilities are found from within the company. The same thing can be said for most products, including IE, IIS, Office, etc... We're getting there....

Now, go off and run as LUA, and nip this stupid spyware problem in the bud.

Re:An important security sidenote

[horrens]

and safari didn't crash either

Re:An important security sidenote

[Anonymous Coward]

I'm just wondering which is better. IE keeping running in weird state after malformed HTML (in some cases bypassing all security zones) or the browser crashing and forcing user to start it from "fresh".

Re:An important security sidenote

[Anonymous Coward]

They hire people right out of school, then get as much work out them as possible. A lot of their programmers have probably never had time to read books like that, or understand the reason why they should.

Re:An important security sidenote

[dioscaido]

That's certainly a good point (pre 2000).

The good news is that now people are required to know Writing Secure Code, and (more recently) Threat Modelling by heart. I can tell you first hand those approaches have been adopted company wide. While Threat Modelling can be time consuming, I've personally found possible issues in code that we wouldn't have noticed without it. Plus we got other people outside our department looking at our code. All in all this is the best approach we could be taking. Microsoft is not sitting on it's ass about this issue.

Re:An important security sidenote

[Erasmus Darwin]

"My guess is this was recompiled with the new SP2 compilers?"

My understanding of the SP2 compilation changes is that existing buffer-overflows still exist and will still cause the program to crash. The difference is that overflows which previously allowed the attacker to execute arbitrary machine code will instead crash before the code is executed.

Re:An important security sidenote

[mikael]

I'd prefer it to display a message box indicating that the file was corrupted, and that I should contact the webmaster for it to be fixed, but that would not give the user a "positive end-user experience".

Re:An important security sidenote

[Anonymous Coward]

It seems unlikely that the same programmers who wrote this marvelous HTML parsing engine, which can take anything thrown at it without even so much as choking, would also have written code that does so little in the way of data validation in all other parts of IE.

There are around fifty critical security updates listed on the Critical Security Updates for IE page, going back to 2001. How many of those mention HTML parsing? Zero.

If it's the same programmers, something went seriously wrong with them when they switched to working on the other parts of IE.

Re:An important security sidenote

[BarryNorton]

Not likely, since IE was created ages before .NET, and I don't quite think they decided to scrap and rewrite the entire parsing engine since then

Indeed. It would be interesting to know how much of it is preserved from the pre-Microsoft Mosaic code...

Re:An important security sidenote

[Anonymous Brave Guy]

I don't see how this is a bad thing. This just means that IE does not catch some of the malformed code people use to cause havoc on the net.

But the other browsers not only didn't catch it, they actually crashed when parsing it. I'm all for compatibility and standards compliance where possible, but a crash/potential security hole is far more serious an issue than letting through some sloppy HTML. (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.)

Re:An important security sidenote

[Dashing Leech]

Uh, can somebody repeat this guy's test. It sounds like nobody can repeat his results, which is generally a sign of a poorly performed experiment. I can do it, but it will be a few weeks before I have time.

Re:An important security sidenote

[Anonymous Coward]

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*.

Re:An important security sidenote

[antime]

My guess is they put in more (and better) handling of broken HTML. In a way understandable - when IE "grew up" web standards were in a flux and people handcoded webpages with barely adequate knowledge of the language. Thus proper handling of wrong code became a necessity.

Re:An important security sidenote

[Khazunga]

This is all shiny and great, but ignores the fact that present IE incarnations were developed before the Secure Windows Initiative.

Re:An important security sidenote

[Anonymous Coward]

*crashing* on malicious code is *GOOD*, while *running* malicious code is *BAD*.

Holy crap! How absolutely untrue. If your program is crashing, you've lost all control. If you still had control, it wouldn't have crashed: it would have printed an error message.

Once you've lost control of your program, all bets are off. The only difference between crashing and taking control is exactly WHAT bad data you feed into the program. These browsers simply crashed because RANDOM data was being fed in. That random data could be changed to carefully-crafted executable code, and BAM, your harmless "crash" is a security exploit.

Re:An important security sidenote

[murdocj]

You aren't a security expert, are you? Now, your first lesson in computer security is, write this a hundred times: *crashing* on malicious code is *GOOD*, while *running* malicious code is *BAD*.

It's true that *catching* bad input and deliberately aborting (hopefully with a somewhat reasonable error message) is good. According to the article, that's not what's going on... the browsers are NOT checking input, e.g. scanning into uninitialized buffer areas because they aren't finding an expected end marker, or a length is incorrect. So parent is exactly right... that kind of "buffer overrun" bug is exactly what can be exploited.

Re:An important security sidenote

[Scarblac]

You aren't a security expert, are you? Now, your first lesson in computer security is, write this a hundred times: *crashing* on malicious code is *GOOD*, while *running* malicious code is *BAD*.

HTML in a browser isn't code. It's data. Running any HTML as code is *BAD*.

The fact that it does crash some browsers indicates that they probably are trying to run part of it as code - probably because of buffer overruns and the like. The whole reason it crashes is that it's running the code. That's very bad. It's not a matter of "either run, OR crash".

A good job by Microsoft, and the rest has work to do.

Re:An important security sidenote

[fstrauss]

You aren't a developer are you?

Programs crash because they execute invalid code in memory. Somewhere a pointer changed, making the program execute some code it never should get to, this can be exploited if you can put your own instructions in the new place the program starts executing.

Getting invalid data shouldn't crash the program, that's very wrong, it should exit cleanly or carry on executing, ignoring the invalid data.

I've never before heard anyone claim that crashing is a good way for a program to deal with incorrect data.

if( data == confusing ) // what the hell???!?
x = x / 0; // abort abort abort!

Re:An important security sidenote

[Khazunga]

(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.)

Have you been giving them feedback(1) lately? The Mozilla team will either add stuff to quirks mode, or pass the site reference to evangelists.

(1) You'll have to copy+paste the URL, as bugzilla doesn't like slashdottings.

Re:An important security sidenote

[Flaming Foobar]

You aren't a security expert, are you? Now, your first lesson in computer security is, write this a hundred times: *crashing* on malicious code is *GOOD*, while *running* malicious code is *BAD*.

I think you are confusing two different things.

It's generally a good practice not to write a program to try to "best-guess" impossible situations such as malformed input. For example, if you've got a low-level function that returns legit data when it's called with invalid data, you are effectively covering a programming error somewhere else in your program. So it's better to return an invalid data flag than try to "best-guess" in that situation.

A program should never ever crash, however. A crash means that something that wasn't supposed to be executed got executed, which is always bad.

Re:An important security sidenote

[Hobbex]

Furthermore, this kind of test is standard within Microsoft (feed random inputs to all possible input locations).

So what you are saying is that this article consists of a Microsoft employee applying one type of stability test, one that happens to be used inside Microsoft, to their own browser, which has been patched against exactly this test, and others. Permit me to say I am somewhat underwhelmed by IEs amazing performance.

This is the security equivalent of Microsoft's "benchmarks" where the benchmark is decided first, then just those operations are optimized, and, wow and amazement, Micrsoft's products perform great.

While it is bad that the open source browsers crash on random input, this is only one, rather limited, test of security. Security against targetted attacks is a much harder, different problem. (CRC32 performs great at spotting random changes in Inputer - want to use to digitally sign your payments?)

Re:An important security sidenote

[Khazunga]

I think it all depends on the definition of crash. A top-level thrown Exception is a good crash. A GPF is the kind of crash that might evolve onto a buffer overflow.

Re:An important security sidenote

[shadoelord]

I'd have to say that "crashing" in general is _bad_. Here's a quick lesson in programming: check all return values :) You can write code that doesn't accept malformed input and still keeps running (perhaps by saying "Hey, id10t error, stop feeding me junk).

Re:An important security sidenote

[afidel]

The difference is that overflows which previously allowed the attacker to execute arbitrary machine code will instead crash before the code is executed.

Almost, it's more like they will crash and there is a near zero chance of the code being executed even by another running process because the area has been flagged as non-executable and the cpu will refuse to run anything found in that memory space.

Re:An important security sidenote

[UberGeeb]

I've come across plenty of sites that either don't work at all or are broken unless you use IE. Generally, it's because the site looks at the browser's identification tag and sends crippled pages to non-IE browsers. I can only think of one site I use regularly (a web app at work) that actually doesn't work in Opera if I set it to report itself as IE.

You might make sure that the sites you're having trouble with in Firefox are actually providing the same data they're giving IE before you assume it's a problem with the browser.

Re:An important security sidenote

[LiquidCoooled]

I have a file sitting on my desktop here at work which says IE was still growing up in July of this year.

It was an 11 byte html file which made IE go BOOOOOOOOM. I aptly named it "crashme.htm".

It remains on my desktop as a reminder of MS crap :)

Re:An important security sidenote

[Corngood]

What SP2 compilers? I think what you really mean is Microsofts new(ish) focus on security, which might be more on the mark. More likely it has to do with the HTML parser being more robust and better implemented, by less lazy coders. Also, IE is based on NCSA Mosaic.

It doesn't matter, these are code flaws, not issues that can be solved by a compiler update.

Re:An important security sidenote

[ptlis]

The moz ones certainly crash FF 0.10.1, I have the quality feedback agent installed so I simply added the url to the example HTML pages with the report.

Re:An important security sidenote

[peterhoeg]

Go the "gallery" he mentionds is his entry and try the mozilla_die?.htm files. With Firefox 1.0PR the first one did the trick for me and crashed firefox.

Re:An important security sidenote

[Corngood]

So what you are saying is that you prefer a negative end-user experience? That, and you'd like to close a dialog for basically every page you visit?

Re:An important security sidenote

[ceeam]

OTOH - the fact that they did not _see_ crashes on MSIE does not mean it has no bugs. It may well mean that they silently swallow the exceptions. I've seen stuff like this:

try
p := nil; //EG
p^ := ....;
except // do nothing
end;

(if you speak Delphi).

Re:An important security sidenote

[mangu]

Getting invalid data shouldn't crash the program

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.

Re:An important security sidenote

[Erik Hollensbe]

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.

Re:An important security sidenote

[fstrauss]

HTML is not code to a browser, it's data to the browser. HTML suggests to the browser how to display things. Not all browsers even display the same HTML the same way. Even javascript is only interpreted by the browser, your cpu does not execute HTML or javascript, your browser decides what to do with it.

That's like saying a word document is code executed by MS Word or OpenOffice, it's not, it's just data.

Re:An important security sidenote

[DigitumDei]

Isn't most of IE's security issues a result of MS's desire to make things user friendly. By user friendly I mean IE will, or at least used to pre SP2, run pretty much any activex program (plus whatever else). This combined with that fact that most users had root access meant that IE was a security nightmare that did not need any malformed html to be bad.

Re:An important security sidenote

[wheany]

A program must never crash because it received bad data. You always have to validate user input and there must always be sanity checks. If the browser receives malformed code, at worst it can give an error message, but it must never crash.

Crashes are always considered bugs.

Re:An important security sidenote

[Hobbex]

I'm not blowing off the fact that the open source browsers did not pass this test, I'm just saying that it does not say that much about IE's security that it passes a test it was optimized for. If security were about responding well to random data, then it would not be so difficult.

Re:An important security sidenote

[mistered]

Oh come on. While I'm as much of a Microsoft-basher as the next guy, this is a very useful technique (and not some obscure Microsoft idea). It's a pretty good idea for looking for bugs at all levels of protocol parsing. You send as much valid data as is needed to get the random garbage into the layer or module you want to test. If malformed data can crash the browser, there's a good chance it could be exploitable too.

Re:An important security sidenote

[jlipkin]

The reason that Mozilla and Firefox don't work with some sites that do worrk for IE, is that IE doesn't work very well with web standards. Developers are forced to write code that is non-standards compliant so that it will render properly in IE. This causes Mozilla and Firefox, which are standards compliant, to display pages 'improperly'. What some developers do is to write their HTML and CSS according to W3C guidelines, so they have valid code, then create a series of workarounds so that the code will render properly in IE. You can look at sites like simplebits.com and stopdesign.com to see how they've done this.

Re:An important security sidenote

[MarkedMan]

This is all to the good, but bugs and holes are not the real source of the Windows et. al. vulnerabilities. Microsoft products are insecure *by design*. Giving a scripting language (visual basic for applcations) the equivalent of root privileges so fundamentally violates security that it can't be fixed. Ditto for components (ActiveX) on unknown Web Pages. You at Microsoft obviously know this, since your solution is to tell users to turn these features off. However, you run smack up against your business plan which is to encourage end users to depend on these sorts of proprietary "features". It's a real bind for you guys - and as much as buttoning up your code is a good thing (TM), it's like fixing the acne on a plague victim...

Re:An important security sidenote

[pfdietz]

My guess would be that Microsoft has actually applied random input testing to IE and fixed the resulting problems, and that the other browsers have not yet done that.

Re:An important security sidenote

[Erik Hollensbe]

Actually, it is a large facet of security.

Are you familiar with XSS attacks? As a guy who writes web backends, I am. As a result, I have to make sure that every bit of content that comes to me and is subsequently displayed (which can get fun, especially if you have a database with 20M customers before you get started) needs to have no HTML tags, or even worse, allowable HTML tags. This can get very slow when processing a lot of content. If you have a templating language which uses different tag endings than an HTML tag, you've got another set of content to scan for. This is the reason things like mod_security were invented. Thing about a bulletin board or a "product review" system and how much content is availble to be sent straight to the database by one person and echoed right back to another.

SQL injection. While good database API's solve this, some systems don't (ahem... PHP's raw API). This is easily solved by something like DBI or PEAR's DB abstraction layer (which the name of escapes me), but once you're up to your knees in mud, it becomes a whole new nightmare. With the new mysql GRANT vulnerability (especially since, last I checked, mysql doesn't support binding at the client API level), SQL injection becomes something that can not only effect your live app, but something much more dire indeed. I won't even get into sql procedures that perform admin tasks.

The fact that IE passes a test, while other's don't, that it was made to pass, that says somethign positive about IE's security, and is not to be blown off. After all, I can inject some of that "wonderful" content right here and it might crash your browser, because there's nothing stopping me from doing it in slashdot's code. If I had the fingernail clipping of that guy's knowledge, I might be able to do something worse.

Of course, if you were running IE, you wouldn't have that problem. Do you understand now?

Re:An important security sidenote

[jallen02]

I think you mis-estimate how hard it is to manage projects with the complexity of Internet Explorer. Even teams of really good developers with noe one "non-expert" can be brought down by the integration trap. It can probably all be led back to the Waterfall development paradigm where you do things in huge chunks: "Requirements, Design, Implement, Integrate, Pray, Test". Each of those is done as a discreet phase. Any devleopment process still following that basic model tends to fall apart somewhere around Integrate. Even with better development paradigms such as agile development there are considerable challenges in integrating something so large as IE.

But that *IS* the point of Agile development, to ensure that every step of the way things are working toghether smoothly. The basic point is regardless of the paradigm IE is a big project with many different components requiring a high degree of integration. A key problem with many different components that are highly integrated is the fact that these components tend to "trust" each other to much. Meaning they just assume this component is friendly. If all integrated components were a little less trusting I think software as large and as complex as IE could be more secure.

This is just a guess, I don't know much about internal Microsoft culture. I have however seen security problems of this scale in projects I have cleaned up and worked on and the problems stem from the exact problems I describe. So its reasonable to assume that somewhere along the way MS has made the same mistakes everyone else does in the software world. Just because they have LOTS of smart people doesn't mean they are any better at managing software processes. Just look at what they are doing with the LongHorn requirements :)

Jeremy

Re:An important security sidenote

[iceperson]

I'd say it says more about developers who don't test their software using this method than it does about Microsoft.

Re:An important security sidenote

[roca]

The reason IE did well is probably because Microsoft did this kind of fuzz testing on it a while back and fixed the bugs. AFAIK no-one has done this kind of fuzz testing on Mozilla.

Re:An important security sidenote

[bunratty]

Yep, the first mozilla_die entry crashes Mozilla 1.8a4 for me, too. Sounds like the tests are repeatable enough. Now quick, everybody rush to file bug reports and the winners can collect their $500!

Re:An important security sidenote

[CausticPuppy]

I don't see how this is a bad thing. This just means that IE does not catch some of the malformed code people use to cause havoc on the net.

Let's turn it around... if it was IE that was crashing on bad HTML, and the other browsers simply ignored it, would you be making the same argument? IMO, the slashdot headline would then be "IE Crashes on simple malformed HTML."

How is it a bad thing when other browsers refuses to read that code. Isn't that a good thing? A good example is a compiler most compilers catch overflows and don't allow you to finish compiling.

NO, no, no, no!! It is a BAD thing, because at the very minimum it's a sign of non-existent exception handling. You should never get a runtime error from bad input. In some cases, you create an infinite loop-- is there any excuse for that?
And considering the nature of the crashes (one of the links caused Firefox 1.0PR to die with a windows memory error, shutting down ALL instances of firefox) this means that some memory was accessed that shouldn't have been, which means that you could conceivably put executable code into memory simply by constructing the right "invalid" HTML. Lo and behold, you now have a buffer overflow exploit for Firefox. And we're telling all the IE users on Windows to switch to Firefox!

I'm a firefox user, and there's no way I'm switching back to IE, but this MUST be fixed. Now that it's well known, I'm sure there will be a patch for Firefox fairly soon, though I have a feeling the code changes will be somewhat involved.

Re:An important security sidenote

[Erik Hollensbe]

I understand exactly what you're saying. I can count several projects at my last job where months were spent developing requirements and designing, only to find out during integration that they were flawed.

Project management is voodoo science at best. Leading a programming team (not managing, leading) is a nigh-impossible task. The computer may not be fallible, but the humans will always be. And I don't have to quote Darwin or any other Biologist to indicate where that leads.

Re:An important security sidenote

[Saint Aardvark]

Just my two cents: Firefox 1.0-PR on Linux crashed and burned on the mozilla_die1.html page. I'm curious to know if you're using Firefox on Linux or something else.

Re:An important security sidenote

[Scarblac]

No. The parsing engine is not written well enough to deal with nonsense in a reasonable way. Not parseable or almost-parseable == drop it, and report an error. Very simple.

Absolutely. That's about the total opposite of crashing though.

Re:An important security sidenote

[00420]

I have a file sitting on my desktop here at work which says IE was still growing up in July of this year.

It was an 11 byte html file which made IE go BOOOOOOOOM. I aptly named it "crashme.htm".

It remains on my desktop as a reminder of MS crap :)

Hehe. That reminds me of a CD I have. I stopped Nero in the middle of burning a CD, and now if you put the CD in any Win 2000 or XP box it'll crash the box :)

Re:An important security sidenote

[CTachyon]

The non-executable flagging (Data Execution Prevention in MS parlance) only applies when Windows is running on an architecture that supports it, which is pretty much only AMD64 at this point. They use stuff like stack canaries to protect x86, which makes an attack harder but not impossible.

Re:An important security sidenote

[sw155kn1f3]

Executed by another process? What are you talking about? Processes in windows cannot mess with each other address space.
And no, it's not NX bit fix that makes sp2 secure (NX bit works only at AMD64 processors and above last time I checked). SP2 includes NX support but it doesn't work on majority of computers.
What they did, is to randomize things and other software stack-protection techiniques built into the compiler (vs.net 2005).

Re:An important security sidenote

[cowens]

The guy who writes Code Complete does not work for Microsoft. He is published by Microsoft Press. There is a large difference between the two.

Re:An important security sidenote

[Hatta]

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.

Re:An important security sidenote

[mr_z_beeblebrox]

It is interesting, then, to see that Internet Explorer did so well on this

Is it interesting or curious? Who is Michael Zalewski and why is in Larrys blog? Is he an MS programmer doing a whole slew of tests and releasing only good data for MS? The programming world is full of that we just implemented a warehouse system after seeing several great sites running the system and giving rave reviews. After implementing it our support SUCKED and later a competitors rep revealed to us that all their reference sites had warehouses run by former employees. The employees were hired because they could not get good enough support, then because the employees had ownership they gave good reviews. Bah, trust not software people it will byte you in the arse.

Re:An important security sidenote

[Erik Hollensbe]

No argument there, but unfortunately the Slashdot article blends the two like they are one and the same.

I would go to say this is a bigger problem then bad integration. After all, Firefox runs on many platforms, and so does Opera. Whether or not that VB layer exists is insignificant, and with the number of UNIX clones (read: these days, pretty much anything but microsoft), that VB layer really doesn't matter if I can wipe out your whole home directory. Do you run your web browser on your server, or your workstation which is loaded with a good portion of your electronic life stored in $HOME? Hope to god you're not using NFS.

Yeah, I'm borderlining on scare tactics but this is a big problem, and really has little to nothing to do with IE.

Re:An important security sidenote

[Patoski]

Your first instinct would be wrong, at least when it comes to it being built by a separate team. The fact is, as hard to believe at it is, for the past year Microsoft has put in place for every product systematic development techniques that directly target the security of an application (Threat Modeling, Secure coding techniques). Furthermore, this kind of test is standard within Microsoft (feed random inputs to all possible input locations). And once all the coding is done, the source still has to pass inspection through a security group within Microsoft! You can read about this stuff at the secure windows initiative.

Your comment really burned me up since I have to deal with this crap every month in an enterprise environment. You can talk to me about "trend(s) per-product" all you want but how on Earth can you brag about the great job you're doing when this month you released 10 frigging hot fixes with 7 of those being critical? You should be keeping your head down this month trying not to attract attention to your miserable situation. Only Microsoft would think to brag about how well they're doing wrt to security during a month like this.

Look at the non-chalant way MS is handling the security vulns. In particular I'm thinking about MS04-028 (the JPEG vuln) which was just last month. On top of being one of the worst written security write-ups I've ever read, the tool you initially provided to detect the problem was worse than useless. Some random guy on the web managed to produce a useful tool by himself before MS did. With all the resources MS has and all the attention you're putting into security how can this be? Also, how could you release such a horrible, broken tool in the first place? Surely MS knew the tool was broken when they released it if they tested it at all!
http://seclists.org/lists/bugtraq/2004/Sep/0 328.ht ml

If you want me to take MS seriously wrt security then do not attempt to spin how severe a vulnerability is (like you did with MS04-028). How is anyone supposed to take you seriously when MS says things like this:
"Microsoft does not consider this a high risk to customers given the amount of user action required to execute the attack and is not currently aware of any significant customer impact".
http://news.com.com/Security+researchers +say+JPEG+ virus+imminent/2100-7349_3-5387380.html

If MS04-028 is not a high security risk then why did MS mark it as critical??? It is one thing to say that you think the JPEG vuln was overhyped (which it was to an extent) but to say that it isn't "high risk" while marking something as "critical" stinks of spin.

Also, I found it hypocritical for MS to yell from the mountain tops about how security is a top priority and yet at the same time refusing to back port very important workstation security enhancements to non-XP OSes (about 1/2 your install base). Note that this also includes security enhancements to IE6.
"We do not have plans to deliver Windows XP SP2 enhancements for Windows 2000 or other older versions of Windows," the company said in a statement. "The most secure version of Windows today is Windows XP with SP2. We recommend that customers upgrade to XP and SP2 as quickly as possible."
http://arstechnica.com/news.ars/post/20040923-42 24 .html

Finally, security is a design decision. If security is not a design decision (hello... ActiveX) then you'll constantly be chasing your tail trying to plug holes in the dam. The hack you suggest in your sig to "solve" the spyware issue really underlines this point. RunAs is broken and doesn't work in many cases and the fast user switching does not work very well unless all one does is browse the web and get email. I won't even get into all the reasons why the fast user switching idea is a non-starter except to say that many applications *require* admin privledges to even run. Both Macs and Linux have had an elegant solution for some time (ask the user for the Admin/root password) in order to elevate privleges. Why is that so hard?

Re:An important security sidenote

[penguinoid]

So if IE quietly accepts bad data where other browsers crash, does that make IE singularly bad for checking whether a web page works?

Re:An important security sidenote

[SilentChris]

"whereas *recovering* from the situation and responding with an *error message* is *GOOD*"

Actually, I prefer "bailing out with an exception" best. That's the .NET model (you can bail and recover, but the default is to bail and throw the debug code). Same as Java to a certain extent.

Re:An important security sidenote

[BrianHursey]

I fell like an idiot, having the possibility of a buffer over flow exploit is not a bad thing. This should be fixed and I think it will be fixed. I thought that it was not going that far to create an over flow. Now that I have done some testing of my own. The mozilla_crash2.html seams to be definitely causing an overflow.

Re:An important security sidenote

[bunratty]

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

Can you give an example of some HTML from a "perfectly usable in IE" website that doesn't work in Mozilla or Firefox?

In my experience, nearly the only sites that don't work in Mozilla are ones that are clearly designed for IE and IE only. For Mozilla to render all those pages as well as IE does would mean reverse-engineering the huge number of extensions and quirks (including outright bugs) in IE. It's really just not worth all the effort. It's less work for web developers to just code their sites better. And when they do that, their sites tend to work better in other browsers, such as Opera and Safari, too.

Re:An important security sidenote

[Erik Hollensbe]

Christ, it's not a fucking conspiracy theory. Heck, even if it was, you are going to get a better browser out of it.

So please folks, everyone trying to apologize for everything !IE kindly put a sock in it and be happy this happened. You guys sound like a preacher on a downtown street corner.

Re:An important security sidenote

[sqlrob]

Executed by another process? What are you talking about? Processes in windows cannot mess with each other address space.

They can intentionally, just not accidentially.

ReadProcessMemory
WriteProcessMemory
CreateRem oteThread

(NX bit works only at AMD64 processors and above last time I checked)

Celeron D is now shipping with NX enabled. I don't know whether XP will take advantage of it.

Re:An important security sidenote

[Curate]

Which buggy kernel were you using?

Re:An important security sidenote

[fstrauss]

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.

Your cpu doesn't directly interpret perl. It executes a program which interprets the perl language, which in turn generates cpu instructions from that.

You can't compare HTML to perl. HTML is formating, that's all it is. There's no direct translation of an html tag to a cpu instruction.

Do you really consider an MS Word doc to be code? If you do then i'm at a loss as to how to try and explain this

There's a difference between formatting instructions and cpu instructions.

Re:An important security sidenote

[pjrc]

...area has been flagged as non-executable and the cpu will refuse to run anything found in that memory space.

Does this SP2 enhancement work on today's installed base of CPUs, or only the newest models with the NX extension?

Re:An important security sidenote

[FooAtWFU]

As a web developer, I find it infuriating that users use a proprietary browser which takes standards-compliant code that results in perfectly good, beautiful pages in every other browser... and mangles it.

Re:An important security sidenote

[mr_z_beeblebrox]

You guys sound like a preacher on a downtown street corner.

No, I sound like a customer. It was you who mentioned Jesus padre. All I stated is look at who tested it and how it was tested. If I write some code with the intent of it passing a specific QC test. It will pass it, no doubt. That does not make it secure and the fact that another product does not pass your QC does not make it insecure. Here is a better test install Firefox on a large group of random machines and IE on a larger group. See if the security problems caused by random browsing are proportional to the install base. We can this test group 'reality'. Care for the benchmarks?

Re:An important security sidenote

[Fulcrum of Evil]

Plus we got other people outside our department looking at our code.

Nobody looks at my code. I send out prelim designs and get no response. I fear, however, that this is how most code shops operate.

Re:An important security sidenote

[minus9]

It wasn't modded down, it started at -1, presumably due to bad karma earned in previous posts. Incidentally, when you talk about "The members of this site", there are around eight hundred thousand of them, if you can find a group of that size who all think the same way then I'm impressed.

Re:An important security sidenote

[afidel]

No, it requires an AMD Athlon64, Opteron, or Intel Nocona Xeon processor. Going forward it should be a feature of all future designs of both companies CPU's.

Re:An important security sidenote

[johnnyb]

Just FYI - the biggest thing I run into on a daily basis is the fact that on Mozilla (and all CSS-compliant browers), width refers to the client-area only, while in IE it also refers to the padding (and margins and borders?).

Therefore, if you need both width and padding, you simply create two divs, one embedded in the other, one with the padding, and one with the width.

Also, I usually have a standard CSS prelude that sets borders and margins to 0 on a lot of elements , and sets the display type of images to "block".

Re:An important security sidenote

[NutscrapeSucks]

There's at least a few IE rendering issues which relate to Mosaic-compatibility ("&nbsp" for example). But that's probably intentional.

I suspect it is mainly due to the fact that IE4 was targetting Netscape 3.0, and Microsoft put a massive QA effort into making sure that every garbage htmlsoup legacy page that NS3 could render could also be handled by IE.

IE might not be fully standards-compliant, but it is a "modern" engine that supports DOM/CSS and probably has very little Mosaic code left in it.

Re:An important security sidenote

[mr_mischief]

Interestingly enough, it did crash my other instance of the oh-so-secure IE. Infinite loop variety, actually. IE 6 SP1 with 5 updates since then.

Re:An important security sidenote

[TheAncientHacker]

If you take it seriously, you'd also note that out of the 20+ patches released on "patch day" this month, only ONE was for XP-SP2. All the rest were for legacy code written before the SWI program was in place.

Re:An important security sidenote

[TravisWatkins]

One major site that doesn't work if you identify your browser as Opera is MSDN. Go on, try to search for something. Didn't Opera win a court case about this?

Re:An important security sidenote

[Ash-Fox]

Actually, microsoft windows will emulate on proccesors that don't support it (and I've tested this and it does, infact, work.)

Re:An important security sidenote

[KevMar]

I used to have that one as well. mine was called crashIE.htm. I say "was" because my anti-virus deleted it for me.

I have the same problem with nmap. oh well, atleast I am protected.

Re:An important security sidenote

[MagicBox]

This crashed my Firefox, but IE handled it OK. This is definitely a surprising eye opener

Re:An important security sidenote

[lcsjk]

Nope! My computer keeps crashing!

Re:An important security sidenote

[Ash-Fox]

[/form] in IE is like [/form][BR] while in firefox/mozilla/safari, it's just [/form]

Yes I know HTML uses diffrent brackets.

Re:An important security sidenote

[PeanutGallery]

You make a good point. People are assuming here that just because something crashed it is a buffer overrun.

I, personally would rather that a browser Assert(x); on something it can't handle than keep going and tap dance through memory -- Ala the JPEG bug.

Re:An important security sidenote

[dark_panda]

If it's of any help, I tried all of the examples in both Konqueror from KDE 3.3.1 and the latest Safari, and none of them caused either of the browsers to crash. (konq and safari both use KHTML, of course...)

J

Re:An important security sidenote

[julesh]

IE might not be fully standards-compliant, but it is a "modern" engine that supports DOM/CSS and probably has very little Mosaic code left in it.

If there is any, though, it's likely to be the lexical analyser, as that's the one area that hasn't really changed much at all with all the new features.

Re:An important security sidenote

[johnnyb]

Maybe they don't like my DocType -- I always use XHTML 1.0 Strict.

Re:An important security sidenote

[Patoski]

If you take it seriously, you'd also note that out of the 20+ patches released on "patch day" this month, only ONE was for XP-SP2.

We're talking about security and security bulletins of which there are "only" 10 this month. I'd love to move to XP SP2 but to be honest there is still some software we're waiting to become fully SP2 compatible and SP2 is still too wet behind the ears for us to deploy anyhow. That said we are testing XP SP2 ATM and are addressing several issues we've found with it in our environment.

http://www.microsoft.com/technet/security/curren t. aspx

All the rest were for legacy code written before the SWI program was in place.

Not true. 70% of these vulns listed 2003 Server as vulnerable which was released way after SWI.

Re:An important security sidenote

[Mouse42]

I thought they fixed that problem in IE6. You may have to include a doctype at the top, but I believe MS fixed that bug.

IE6 is different from IE5.5 and IE 5.0 and that also causes it's own problem. Not everyone uses IE6, at least not in my "important people who must be able to view this page perfectly on their computer" demographics. These are all people who have no concept of "Windows Update" and are still running on the same exact system they installed years ago.

In the end, whenever I create a webpage, I still have to make sure it works in the past three IEs. Generally, I can now create a page that works perfectly in IE5, IE5.5, Mozilla, Netscape, Opera, etc, and won't work in IE6. It is usually the padding/margin/width issue.

Re:An important security sidenote

[julesh]

The Mozilla team will either add stuff to quirks mode, or pass the site reference to evangelists.

Much more frequently the latter than the former. And guess what... it just _doesn't help_. I've tried to impress on several companies myself the reason why not working with Mozilla is a bad thing. Their response. "Sorry, we've optimized the site for Internet Explorer," or some shite like that. They just don't want to listen.

Re:An important security sidenote

[Darby]

They use stuff like stack canaries to protect x86, which makes an attack harder but not impossible.

What the heck is a "stack canary"?
Is that like a canary in a coal mine that dies first?

Re:An important security sidenote

[Tiram]

This works fine for me, using Opera 7.54. What did you search for?

Re:An important security sidenote

[TheWizardOfCheese]

Since it may not be obvious to all readers, be aware that when you can make a program crash by feeding it bad data, you can typically further manipulate the data you are sending it to take control of the program.

I agree with you that in practice this is often the case. However, it is not necessarily true; the "bad" data may merely exercise a branch not previously taken. When data is not interpreted as a pointer (or otherwise executed) there can be no control of exectution. For instance, the following snippet is a bug but not necessarily a security breach:

if (some rare condition) {
*0 = (void *)1 ;
}

Re:An important security sidenote

[LiquidCoooled]

Norton suddenly decided to detect and remove a file on my drive thats been there for years recently. It was a Service Pack 1 installation guide thats been happily sitting there since sp1 was released. I got a shock when the scan results window told me it had found a threat! First time its ever come up wheen I'm not expecting it (EICAR testing).

It was caught as part of a weekly scan, lets just say I removed the automatic cleanup immediately after.

Hey, what would happen if a virus somehow managed to change the NAV definitions to consider *.exe or *.dll a threat? .....

Turn the computers immune system on itself.

Re:An important security sidenote

[Fulcrum of Evil]

So what you are saying is that you prefer a negative end-user experience? That, and you'd like to close a dialog for basically every page you visit?

This is the sort of thing that status bars are made for. Stick a yellow ! and a message on the bottom of the window and bar further messages for that page.

Re:An important security sidenote

[TheAncientHacker]

Right, because we all got in this to AVOID having new technology around. You know, if you really want to avoid viruses and worms, just give up that new-fangled Internets thingie.

Re:An important security sidenote

[iamsunilk]

To make some more unknown BUGS is it hi hi!!!!!!!!!!

Re:An important security sidenote

[MarkedMan]

From above: "...it only executes at the same level of privs as the person/process that executed it."

And what exactly do you think the average level of privilege is for Window's users? I would guess that 99% of home/small business users and a very significant percentage of office users are logged in with administrative privileges.

The typical Microsoft answer to this is that users shouldn't do this. It's like putting a "Blow up my engine" button next to the radio on-off in a car and then saying "but we told everyone not to press it" The reality is that people do this. If only they were affected by the mistake, then hey, let the buyer beware. But everyone behind their firewall, everyone in their outlook directory, everyone they IM with is compromised as well.

It's as if Microsoft has built a building with an outside door for every office because it makes it easier for the pizza delivery guys. There are thousands of theives prowling around testing the locks. If one occupant leaves it open, the whole building is compromised. Micorsoft's security initiative essentially consists of putting better locks on the doors.

Re:An important security sidenote

[Quay42]

Are you sure you went to the right site?

It took a while, but mozilla_die.html (or whatever it's called) took out Firefox after a few minutes. He notes that some of them can take quite a while as it basically causes the browser to just sit there eating up memory. Perhaps if you have enough memory then there aren't enough malformed tags to cause the browser to take it all up.

I'm using .8 (I know, not the most recent).

--josh

Re:An important security sidenote

[jfsather]

I haven't done that much .NET client side programming (mostly WebServices/ASP.NET stuff), but I did help another programmer try to embed a browser inside his app. There was no .NET HTML renderer and in order to get a browser component inside the app we had to invoke the IE DLL. This is considered an insecure call out in .NET (invoking native, non-.NET code that has to run outside the sandbox). We were able to embed IE inside the app, but the bonus was that you get all the flaws that come along with it. This may have changed since we did it about 6 months ago.

-JFS

Re:An important security sidenote

[julesh]

Listen to me. I've written a (rudimentary) web browser. HTML is not executed or interpreted. It is parsed into data structures that are then processed to determine a screen area that is relevant for each one, and a description of their content is then drawn into that area.

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.

Listen -- if the browser behaves in a way that it isn't supposed to (i.e. crashing) when given invalid input, this is because it has done something wrong. By far the most likely symptom of doing something wrong in a program like this is crashing. Probably by either following a NULL pointer, a pointer to a data structure that has been freed, or attempting to free the same pointer twice. The latter two of these errors can almost always be exploited to execute malicious code. It is often difficult, but the merest possibility ought to concern you.

However, it is _highly_ unlikely that a program with a structure like the one I've described above (particularly one that is written in a compiled-to-native-code language without garbage collection, which I'm pretty sure IE is) could become subverted in some way by bad data, but continue running with the incorrect behaviour waiting to be run at some later point after the page in question is no longer being displayed. For this to happen, some data would have to be copied out of the internal representation of the HTML document (which will be deleted after the page is closed) and into IE's internal state. There is no reason for it to do this; in fact, there will be very little state held over between pages (history, user settings, and pointers to window related structures and resources like menus, toolbars, etc. probably account for almost everything), and anything copied from a document ought to be treated as 'suspicious' anyway.

Sorry, you've just got it plain wrong.

Re:An important security sidenote

[Fulcrum of Evil]

Besides some vague mumblings about "potential" exploits, I didn't see any evidence in the article of deleterious effects caused by those browsers "crashing".

That's not his job. If you don't like Mozilla crashing, then go fix it.

It's better to have the browser fail than to have it keep running with a possible exploit.

Better, but never good. It's best to check your buffers, complain on invalid input, and abort scripts that do stupid things.

Re:An important security sidenote

[Daniel Boisvert]

They didn't crash my Firefox 1.0PR. I ran through them all, and could continue browsing with no problem. When I closed firefox, it seemed to hang, and I killed it via the task manager (I'm at work on WinXP w/ SP2).

Here's my useragent string: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

It's certainly interesting that it doesn't seem to crash consistently..

Re:An important security sidenote

[jmischel]

So what you're saying is that Microsoft's IE team is exhibiting technical leadership by implementing procedures that improve the quality of their product? And they're doing this before any of the open source development teams?

Say it isn't so!

Re:An important security sidenote

[rdc_uk]

Um...

If you make the program crash, it has ceased processing in a (relatively) short time. You've had a window of opportunity, certainly, but once it crashes its closed.

On the other hand, if you can overflow a buffer and write data into areas that the program will continue to USE...badness ensues.

Methinks you may have "did so well in this" partly backward... (IE is, after all, watertight like a sieve, but its main flaw is that a compromised IE means a compromised windows PC.)

Of course, a really stable and robust program will do neither of these things; it will simply inform you that you fed it garbage, no over-run, no crash, no page.

Re:An important security sidenote

[Erik Hollensbe]

Please, look into getting that soft skull of your examined. How can you even compare this to a benchmark?

FireFox breaks when fed invalid input. It's not something you can argue with - if you read the post, there are links to files which will prove this to you. Since you don't seem to get it yet, there is no way you can argue against this.

Yet you choose to turn a blind eye to the real issue and use it for a platform (or a soapbox, if you will) to make your assumptions. Who are you trying to deceieve, me, or yourself?

Re:An important security sidenote

[Erik Hollensbe]

To add insult to injury, I hope you never get selected for jury duty. One could only hope that the lawyers are honest enough to not let you through with the way you factor argument.

Re:An important security sidenote

[Anonymovs Coward]

konq from kde 3.3.0 didn't crash on any of the examples either. Firefox did on a couple. I find konq much more reliable lately: less crash-prone (in fact I can't remember it crashing in months) and it actually renders some pages Moz/Firefox don't (of course, they too render some pages Konq doesn't, but it seems to me konq does better overall).

Re:An important security sidenote

[dioscaido]

I wasn't aware you had to pay for Windows Update/Automatic Updates.

Re:An important security sidenote

[antime]

Good for you. Remind me, what was your point again?

Re:An important security sidenote

[Cyberherbalist]

There is a large difference between the two.

Oh, come on. Really trying hard to separate Microsoft from any positives at all, aren't you?

Go ahead, try to find any authors who actually work for the publishers that publish their books! In any genre, not just IT. Authors are by and large independent contractors with respect to their publishers. And a fair number of MS Press authors work for non-Microsoft companies. So what? Microsoft recognized the value in the book, and that is a credit to them.

Re:An important security sidenote

[16K Ram Pack]

Sheesh.

Do I really have to reply to another "Mozilla is crap because pages using non-standard HTML don't work with it?

Well, all I can say to you is dgsdfgsdewrgerg.

You understand?

Re:An important security sidenote

[sharper56]

Those pages were just examples to prove that various browsers had repeatable crashable points.

If you run his mangle.cgi test against Konqueror it takes 15 secs for it to crash the browser!

Better fire up the KHTML bug track. :-)

Re:An important security sidenote

[greg_barton]

...but to say that it isn't "high risk" while marking something as "critical" stinks of spin.

Kinda sounds like, "We're raising the terror alert to ORANGE. You don't need to change your behavior, though..."

Re:An important security sidenote

[darkain]

almost...

as i have mentioned elsewhere, in SP2 of the Win32 SDK, Microsoft made major changes to their CRT libraries, such as making functions like sprintf and even snprintf deprecated in favour of more safer versions that do both range checking, as well as data type verifications. these new safer functions also have a bail-out function just in case an error has occured. The way that "safer" languages work is by either doing all range checking for you, or simply creating a new buffer each and every time it is manipulated, wich can be horribly slow.

Re:An important security sidenote

[NewStarRising]

Paretnt was refering to Uprading, not Updating.
Upgrading from previous verswions of Windows to WinXP /SP2.
This new version of Windows does cost money

Re:An important security sidenote

[Barlo_Mung_42]

You sir are an idiot.
If malicious code is able to crash your app it is likely also able to make it run arbitrary code. It is far better to respond with an error than to crash.

Re:An important security sidenote

[|<amikaze]

That's why you have to do it over and over :). Make some noise. Get the problem noticed. If it's a commercial site, and they start believing they're losing customers over it, then they might take notice. Or they might lose you as a customer.

Re:An important security sidenote

[|<amikaze]

ca.ingrammicro.com has this horrible javascript. Here's the double-bad part. They detect if you're running Netscape 6, and return proper javascript if you are. Otherwise, it returns IE dependant javascript that uses non-existant parts of the mozilla DOM.

Re:An important security sidenote

[HiThere]

Netscape was Mosaic. I thought IE was Spyglass...or was Spyglass another fork of Mosaic?

(If so, I lose 1/4 of my sympathy for Spyglass over the deal they signed with MS.)

Re:An important security sidenote

[GryMor]

Not really, it just means that it's corrupting the heap as opposed to corrupting the stack. This will lead to Heisenbugs as the initial state of the heap will be effectively random and dependent on every page you have previosly viewed and the timing of input.

Re:An important security sidenote

[temojen]

I used to have a page that caused windows 2000 to bluescreen when viewed in IE. There was nothing fancier than JavaScript DOM manipulations in it.

Re:An important security sidenote

[megarich]

Yea its not to be blown off but it also shouldn't be used to make i.e. all of a sudden the best browser on the market (i'm not saying you are but some people may see it in that light)

I've come to accept that all program WILL have security holes and i base my response on 1)how many serious security holes or crashes can be found in one program 2)how fast will the company respond to our needs about the security holes and such.

Re:An important security sidenote

[rspress]

The fact that the browser crashes and possibly closes the hole might be a good thing. IE and its seemingly good error handling may be doing more harm than good by letting the malformed code through without error.

IE was made by design to download and execute code without the user doing much if anything.

Re:An important security sidenote

[umshaggy]

This isn't a refutation or rebuttal or corroberation of anyone's point of view, but I'm reading a lot of people on this thread talking about the difference between code and data. This scares me. CS 101 stuff here. There is no difference between code and data as far as a computer is concerned. This is the reason buffer overruns are bad, because data is being interpreted as code (it's all 1s and 0s to the CPU afterall).

mangu is correct in calling the HTML code. Even more so if a buffer overrun occurs.

Re:An important security sidenote

[mrbkap]

Let's hope that all these bugs are taken care of in the other browsers quickly before the black hats find ways to make use of them.

I'm not sure about mozilla_crash2.html (and nobody seems to be crashing on mozilla_crash3.html) but at least mozilla_crash1.html is not exploitable. The problem was simply the effect of writing:

T* elt = 0;
elt->func();

which crashes, but isn't a write to random memory of any sort, so it isn't really exploitable beyond crashing the browser.

Re:An important security sidenote

[CTachyon]

A stack canary is a form of protection against stack overflows. And yes, the idea is named after the canaries used in coal mines. To put it in simple terms, a normal stack during a function call might look like this:

Buffer: XXXX XXXX XXXX XXXX ...
Saved registers: YYYY YYYY
Return address: ZZZZ

When the buffer is overflowed, the attacker fills it with more data than it can hold. The extra data first fills the saved registers, then overwrites the return address. The attacker can simply point the return address back into the buffer, or find more diabolical means ("return into libc", a few others), to run his own code.

If a recent OS (first Linux, now Windows) is running on, say, an AMD64 system, then the entire stack is flagged with the NX (no execute) bit. If the attacker uses the normal technique of returning into the buffer, the processor will halt the program because it's trying to treat data as code without asking first. (This doesn't protect against return into libc attacks.)

However, on ordinary x86 processors like Pentium 4 or Athlon XP, there is no NX bit. So, Microsoft altered their compiler to insert stack canaries into every function. The previous stack diagram is changed to something similar to this:

Buffer: XXXX XXXX XXXX XXXX ...
Canary: CCCC
Saved registers: YYYY YYYY
Return address: ZZZZ

Ideally, the canaries are chosen randomly each time a function is called. However, this is too slow in practice, since functions get called *a lot*, so a program will randomly choose a single canary number once at startup and reuse it.

Now the attacker can still overflow the buffer, but this time he has to overwrite the canary. If he already knows the canary, or guesses it correctly, everything works the same as in the case of an unprotected overflow. However, if he guesses wrong, the canary kicks in. To maintain the canary, there is some code inserted by the compiler at the start and end of every function. The start code inserts the canary into the stack, and the end code checks that the canary has not changed. If the canary changed, an error is triggered, and the program is halted before the function ever returns. This prevents the attacker's code from running if he doesn't know the canary number.

There are still some scenarios that aren't protected by a stack canary, but it is rather effective overall, and actually protects against a few scenarios that the NX bit doesn't cover. It doesn't help protect against heap overflows, though, although there's no reason heap canaries can't be used also. (The heap is a lot harder to explain than the stack, but a lot of programs put some or all of their buffers in heap memory instead, and the heap can be attacked as well.)

Re:An important security sidenote

[marsu_k]

Getting a bit offtopic, but while I really liked Code Complete, one of the most enlightening programming books I've read was The Practice of Programming. Check it out if you haven't yet.

Re:An important security sidenote

[rabidcow]

*crashing* on malicious code is *GOOD*, while *running* malicious code is *BAD*.

There is some truth to this, but it seems to have been lost in over-generalization. Crashing is better than data corruption. Detecting the bad data and recovering (even just throwing out the whole set of data) is better still. In some situations, crashing intentionally is a valid recovery method.

The only difference between crashing and taking control is exactly WHAT bad data you feed into the program.

Highly likely, but not necessarily true. It's hard to exploit a bug that causes it to crash on a division by zero. Still, if you don't know whether or not it can be exploited, it's safer to assume that it can.

Re:An important security sidenote

[dgatwood]

Also, IE is based on NCSA Mosaic.

I think you have them backwards. Netscape Mosaic was derived from NCSA Mosaic, which later was renamed to Netscape Navigator.

Re:An important security sidenote

[CTachyon]

No, this is the stack canary in action. To emulate per-page NX on a processor without it, Windows would have to single-step all your programs, making it slower than VMware. (VMware doesn't even emulate at that level of detail.)

(Technically, it could get by without single-stepping: it could mark your NX pages no-read, then handle the page fault by checking the instruction at the fault address, emulating a MOV or similar instruction but killing the program on a RET or similar. However, that's horrendously slow, since each page fault involves two context switches (one into ring 0, one back to ring 3), which would easily slow your program by 100-fold. Your 3GHz computer would effectively max out at 300MHz.)

Re:An important security sidenote

[SavingPrivateNawak]

Maybe Netscape too, but MSIE is based on Mosaic.

Check the 'About' page...

Re:An important security sidenote

[CTachyon]

I forgot to point out that you can prove this by compiling your program with an older or non-MS compiler. Write up a test C program, then compile it with Cygwin or MinGW GCC, and run it on an XP SP2 system running on a plain x86 processor. It should still overflow normally. Switch to Microsoft's compiler, and it should raise an error instead.

Re:An important security sidenote

[Cloudgatherer]

While MS software quality may be improving over versions, that does nothing to fix/address the current software currently in use.

Ironically, the "secure" initiative will only end up helping MS, as 'crappy security' in previous versions will influence upgraders. "Gee, that version of Windows is actually full of security problems, but if you buy the latest/greatest version, it will be more secure!"

Problem is, IE does not generate money, so appears to be getting very little MS attention. Enter Firefox and Browser War II. I say use IE to download Firefox/Mozilla and do nothing else with it!!! I tried using someone's machine that was only using IE, and it was so spy/adware laden that I could hardly control the OS and had to kill many many spy processes.

The real irony is the problem only stems from using IE, has created a 'market' for removal programs, and users should have never had this problem in the first place.

Re:An important security sidenote

[rjkimble]

I don't think that anybody is suggesting that IE is the best browser on the market. This guy has performed a useful service by devising a test script that highlights the flaws in other browsers and demonstrates that IE's HTML rendering engine doesn't have these same flaws. Nothing could be simpler. There is no need for all the open source advocates to run around flaming everything in sight, just because we now have an example that highlights a place where IE is better than our browsers of choice.

Pretty simple stuff, really.

Re:An important security sidenote

[roca]

I wouldn't quite call it technical leadership; fuzz testing is old and lots of people do it on all kinds of projects. But sure, they did a better job on this than Mozilla.

In the case of Mozilla it's really a resource and prioritization issue more than anything else: see http://it.slashdot.org/comments.pl?sid=126192&cid= 10564332
Not that that's an excuse.

Re:An important security sidenote

[The Pim]

But that *IS* the point of Agile development, to ensure that every step of the way things are working toghether smoothly.

Although your initial point is good, your "Agile development to the rescue" follow-on falls flat. The components of IE do work together smoothly, beautifully in fact, according to the typical user experience. How secure a program is, and how well it works under normal testing, are almost totally unrelated. The way to secury systems is through careful, security-conscious design of both the components and their interactions, along with programming technologies and techniques that make it hard to screw up. Frequent integration might help security a bit by encouraging communication between component authors, but on the other hand the "make it work" attitude of "agile development" probably works against security.

Re:An important security sidenote

[Corngood]

This is the sort of thing that status bars are made for. Stick a yellow ! and a message on the bottom of the window and bar further messages for that page.

Sort of like what IE does for page errors. No, wait, _exactly_ like it.

Re:An important security sidenote

[the arbiter]

Fine with Opera 7.51 here as well. The page renders nicely and search works just fine.

Re:An important security sidenote

[eSavior]

You must not know about quirks mode? Firefox defaults into this mode unless specifically said not to...
Information about Quirks mode

Re:An important security sidenote

[mdfst13]

Not to rain on your joke, but you only get the $500 if there is an actual security hole, not a potential security hole. I.e. you need to write an exploit that utilizes the crash code. Unfortunately, he hasn't done that for us yet. We'd have to do that ourselves.

Re:An important security sidenote

[ArsonSmith]

Killed epiphany 1.4.4 as well. I'm sure it's in the mozilla rendering engine which is mozilla 1.7.3.

Re:An important security sidenote

[malfunct]

The new compiler has a whole slew of tricks to prvent aribtrary code execution by buffer overrun. Most of it seems to be memory re-ordering as well as extra detection. Its pretty good stuff from what I've seen but it doesn't replace correct coding. If he is testing SP2 of IE the fact that IE has fewer crashes would have a lot to do with the new standards at MS in both development and testing.

Re:An important security sidenote

[DunbarTheInept]

You said:
"there's nothing stopping me from doing it in slashdot's code."

What about that bit at the bottom of the "Post Comment" form that always says:

Allowed HTML <B> <I> <P> <A> <LI> <OL> <UL> <EM> <BR> <TT> <STRONG> <BLOCKQUOTE> <DIV> <ECODE> <DL> <DT> <DD> (Use "ECODE" instead of "PRE" or "CODE".)

Re:An important security sidenote

[DunbarTheInept]

Checking for problems in HTML syntax is signifigantly simpler than data validation in the other parts of IE's glued-together add-ons. The check can occur entirely inside the parser. Therefore it is very easy to believe that it could be the same people despite the difference in security between the two. (It still probably isn't the same people, but that's more because it's a huge project and there are therefore probably people dedicated to the job of JUST writing the HTML parser.)

Re:An important security sidenote

[Erik Hollensbe]

Uh... How about I inject a null, or a div with a really, really long style attribute.

I think you're missing the point.

Re:An important security sidenote

[DunbarTheInept]

Since you don't seem to get it yet, there is no way you can argue against this.

Speaking of not getting it, the person you are arguing with never once argued against this. Does this test show places where Firefox needs fixing? Yes. Does this test show IE having better security? No. The test data was crafted explicitly for those things IE is better at. There are other things that crash it and not Firefox.

Re:An important security sidenote

[mdfst13]

"The fact that IE passes a test, while other's don't, that it was made to pass, that says somethign positive about IE's security, and is not to be blown off."

No, I disagree with that. It is reasonable to blow off that IE passes its own test cases. What is not reasonable is to blow off that other browsers do not.

IE still includes some basic security flaws due to faulty design. For example, there is phishing attack that displays http://www.bankname.com/ on mouseover but goes to http://ip.nu.mb.er on click. This is a security flaw in IE that should not exist (the same routine should be used to determine the URL for both mouseover and on click). Incidentally, this flaw does not exist in FireFox.

More relevant test cases are always good. New versions of Firefox, et. al. should be able to handle these test cases as well as those that they handle now that IE does not.

Re:An important security sidenote

[DunbarTheInept]

Those millions have no opinion becasue they don't even know what the hell is going on. Do you actually think they sit around going, "gosh, I wish this rendered table HTML this way instead of that way when it encounters the such-and-such tag."

Re:An important security sidenote

[DunbarTheInept]

NO, no, no, no!! It is a BAD thing, because at the very minimum it's a sign of non-existent exception handling. You should never get a runtime error from bad input. In some cases, you create an infinite loop-- is there any excuse for that?

Yes. There is a perfect excuse for that - to fix it you have to solve the unsolvable halting problem from computer science which I assume you are already aware of. Can a C compiler determine if the C code it is running will loop forever? No. Can an interpreted language like the Bourne shell figure out if the input shell script it is processing will result in an infinite loop? No - being an interpreted instead of compiled language doesn't let you fix the halting problem. Looked at this way, the HTML engine inside a browser is in fact actually a program interpreter, with HTML as the source code. Thus the only way to catch the halting problem is to deny possibly valid runs, as we all learned in CompSci. In this case, that's probably exactly what IE is doing (for example, in theory rendering a table of 10,000 columns is a finishable task and not an infinite loop, andtherefore it would be wrong for an interpreter to deny the program the ability to do it. But in the case of a rendering engine for viewable content, it can safely assume that such a task would never work anyway, and cut it off at a max cap.)


And considering the nature of the crashes (one of the links caused Firefox 1.0PR to die with a windows memory error, shutting down ALL instances of firefox) this means that some memory was accessed that shouldn't have been,

This is not necessarily true. When some kinds of input trigger a crash when others don't, the cause MIGHT be a case where the input can stuff values into buffer overruns, but it doesn't have to be. The unusual input could trigger a conditional branch that is not normally run, and has a bug in it that crashes. The unusual input could case a variable initialization to be skipped because of such a conditional check (such that it did cause a variable to be altered, but not in a way that the input could control). The unusual input could simply be a case of picking a bigger number than the program was expecting to have to handle, and thus causing a hardcoded loop somewhere to process too far through an array (in which case there is a buffer overflow, but not one that lets the user stuff whatever he likes into that overflow.) It could be a case of the program not being able to handle the large amount of memory it would need to (validly) perform the request (as in, "try to render this 100,000 column table."), and the crash could just be the result of such a thing leading to a failed malloc().

Re:An important security sidenote

[Erik Hollensbe]

You are correct, that point was poorly worded. I hope you'll find other comments I have made in this article more in line with my point.

And you're correct, the point is strengthening the browser, and has little to nothing to do with IE's "success". I was just getting tired of the retaliation of the fandom here.

Re:An important security sidenote

[Erik Hollensbe]

Did you read the SF post by the guy who actually wrote the code?

Since you obviously didn't, let me quote some of it for you:


6) Pointless rants

It appears that the overall quality of code, and more importantly, the
amount of QA, on various browsers touted as "secure", is not up to par
with MSIE; the type of a test I performed requires no human interaction
and involves nearly no effort. Only MSIE appears to be able to
consistently handle [*] malformed input well, suggesting this is the
only program that underwent rudimentary security QA testing with a
similar fuzz utility.

This is of course not to say MSIE is more secure; it does have a number
of problems, mostly related to its security architecture and various
features absent in other browsers. But the quality of core code appears
to be far better than of its "secure" competitors.

[*] Over the course of about 2 hours; I cannot rule out it would
exhibit problems in a longer run.


Still feel like you have a point?

Re:An important security sidenote

[DunbarTheInept]

*crashing* on malicious code is *BAD*

// --- example 1 ----
while(1){
//nothing
}
// --- example 2 ----
while(1){
fork();
}
// --- example 3 ----
ptr = malloc( INT_MAX );

So, every compiler out there is bad, then?

I think you meant invalid INPUT, not invalid CODE.

Re:An important security sidenote

[Old Wolf]

I have a worse CD.. if you put it in the drive then it starts to install Windows 98 :(

Re:An important security sidenote

[mr_z_beeblebrox]

Yet you choose to turn a blind eye to the real issue and use it for a platform (or a soapbox, if you will) to make your assumptions. Who are you trying to deceieve, me, or yourself?

No, it is not a benchmark you are right, I was frivolous with terms. My fault. The point I am making and the only true point is that this goes with a grain of salt. If ford released a study showing that on bumpy roads only fords were managable would you buy into it... I hope not. If the links and the files prepared generously for you by the person with a VESTED interest in proving A SPECIFIC point constitute proof to you. Well, I am happy that your world is so clear.

Re:An important security sidenote

[mikael]

I'd prefer a warning message, and the web page designer informed, than my browser to keel over without warning five pages later.

Re:An important security sidenote

[mr_z_beeblebrox]

One could only hope that the lawyers are honest enough to not let you through with the way you factor argument.

Since you wish to add insult to the discussion...One would hope that your writing is limited to internet forums 'with the way you craft sentence'.

Re:An important security sidenote

[sjalex]

If it's 100 fold it'd be 30MHz

ouch

Re:An important security sidenote

[mixmasterjake]

I think that I understand what you mean, however your terminology is perhaps a little confusing. When a program *crashes* I tend to think that it has hit an unhandled exception. I think you are actually trying to say "handle the error and terminate." That is a very different thing from *crash* in my mind.

That being said, I disagree with your point that an app should always terminiate when it hits some bad input. My opinion is that the program should terminate if, by continuing, it will be forced into an unknown state. Streaming audio/video apps are examples of software built to keep going if they get bad data. If some packets get lost and/or corrupt packets get through, it might skip, show static, play a little distortion, etc. But, it won't just terminate. If a video player terminated whenever it got a bad packet, it would probably be worthless.

Just because IE (or any browser) gets some malformed HTML code doesn't necessarily mean that it is going into an unknown state. If the browser app realizes that it has malformed HTML, then it is still in full control and can choose to render as much or as little as it can.

Re:An important security sidenote

[bunratty]

Can you point to where that's stated in the Mozilla Security Bug Bounty Program Reward Guidelines? I certainly don't see it.

Re:An important security sidenote

[Naeleros]

LOL. You must not be from the US. We have opinions on everything.. whether we understand it or not. They're not going to worry about HTML tags.. but, if their browser doesn't render the page correctly...they are not going to give a crap. Furthermore, they aren't going to be interested that the browser is 'right'. They can't see/interact with the page correctly.. so, the browser is broken.

Re:An important security sidenote

[ErrorBase]

Konqueror 3.2.1 (SuSE 9.1) also handles it fine.

Re:An important security sidenote

[Turmio]

At Microsoft they're not using Waterfall model but Synchronize and stabilize model to drive their software processes. In many studying materials for basics of software engineering in colleges it's also often called the Microsoft model.

Re:An important security sidenote

[mewphobia]

but a lot of programs put some or all of their buffers in heap memory instead, and the heap can be attacked as well

How would you put function arguments on the heap?

There are still some scenarios that aren't protected by a stack canary, but it is rather effective overall, and actually protects against a few scenarios that the NX bit doesn't cover

What scenarios are these?

Re:An important security sidenote

[Yankovic]

I would disagree that this is by design. This is actually by implementation, not design. You CAN log in as non-admin, and nothing you describe would be a vulnerability. To the best of my knowledge, this is exactly what they did with SP2.

Re:An important security sidenote

[lienyevrah]

Last year I wrote a similar program to Michael Zalewski's with the intent to test browsers AND operating systems security. IE's parser held up fairly well so I didn't pursue testing other "more stable" browsers. However, I did find a few holes in IE like:

IFRAME application/x-www-form-urlencoded> (which will crash pre-IE 6 browsers. It appears to overflow shlwapi.dll)

Next I turned the program to the O.S. and found that Windows coughs on

CALC inp11111111111 (Enter this at in run or from a command prompt)

To download my program and/or see more examples go to http://robohoba.temp.powweb.com/publications/bforc e.html

Proof that the ONLY way to approach thorough and complete code/program security is through brute force.

Re:An important security sidenote

[Reziac]

Didn't crash my beloved Netscape 3.04 either -- it just displayed the various examples as blank pages (its normal behaviour is to ignore unclosed or malformed tags, presumably because it doesn't make wild-assed guesses about the page's *intent*).

Re:An important security sidenote

[BarryNorton]

I should probably have said Spyglass Mosaic to be clear (since this is not the same code as NCSA Mosaic - which neither Netscape nor IE contain).

Re:An important security sidenote

[Reziac]

Just to say thanks for the explanation, which even this non-coder-but-interested-bystander understood perfectly. :D

As to Charles-A's question about why not use boundary checking, *is* there some reason why it's not typically used?? (at least not in C)

Re:An important security sidenote

[dveditz]

The bounty program page links to our description of critical security bugs: http://www.mozilla.org/security/bug-bounty-faq.htm l#critical-bugs

The Bug Bounty requirements also say "previously unreported" -- no one other than Michael Zalewski could claim the bounty on these bugs. The examples in his gallery, however, don't appear to be exploitable at first look.

Feel free to use his tool to find additional problems, though. Maybe you'll get lucky.

Re:An important security sidenote

[linear_shift]

For one thing, the NX bit doesn't protect against heap overflows, am I right (in regards not to possibly bring all the progs w/anchors in the heap to fault most likely)? Of course canaries don't usually take to the heap either, but as [grand]-parent said there is no reason it shouldn't, if you are willing to wipe/crash the heap and possibly segfault all your programs for the sake of security; though mabye you could transfer them to the stacks beforehand, its a mite bit kludgy though esp. in terms of, well, security ;P

As far as the heap goes, you could attack the total address space of the heap and flood it with crap just like the stack, even more so since the heap is usually unprotected and public so it could easily be overflowed and leak crap into any program using the heap space (if there is no boundary, that is). Please be incouraged to correct me on any of this since it has been awhile since I have really written any programs, though I pretty much know for sure I have the gist of it. If anything wrong does come to mind and/or if I happen to dig it out of my long-term memory in time before the /.'ers get to it I'll be sure to correct it ;)

Re:An important security sidenote

[kesuki]

Here you go..

# Security bug must be a remote exploit.

also, you don't get the $500 if you wrote the exploit as stated here.

# Submitter must not be the author of the buggy code nor otherwise involved in its contribution to the Mozilla project (such as by providing check-in reviews).

Re:An important security sidenote

[kesuki]

OMG you had me scared. Then i realized you said STARTS to install windows 98, clearly we're all safe, as it surely doesn't Finish instlling windows 98... thank god i can sleep now knowing that your cd only starts to install windows 98, but then halts errors or asks for a CD key, or some such which of course no decent person would know the answer to that question. so we're all safe for now...

Re:An important security sidenote

[jallen02]

I would have to agree with you. As one other pointed out here Microsofts development process probably COULD be classified as an agile process.

Call it synchronize and stabilize, or an agile process, or whatever. The basic ideas of improving the software development process are moving in the that general direction. Processes that are more flexible and learn from mistakes. Processes that are self aware of where they are and not just some vague well.. "we think its all integrated, we are testing now!". According to the little blurb I just read the MS process follows several tenets of agile and smart development. Regularly integrating things, increased communication, increased response to change (which is the only constant in software), enforced automation of building (which includes enforced automation of unit testing). When your build fails due to a test failing you get yelled at etc. And since everyone is more involved in the process it puts you into the hot seat, just for a unit test or two that could have failed.

So.. there IS no silver bullet, ever. But there is always a way to improve things. To make developers more aware of the things important to their project (Security, time to market). To make managers more aware of how to keep the project going, avoid death matches, improve communication etc. Its a large and pervasive process and based on what im hearing MS is moving in the right direction (No one can predict the future very accurately) :)

Jeremy

Re:An important security sidenote

[jallen02]

Well, I think you could classify Synchronize and stabilize as an agile process by most peoples measuring sticks. They are promoting many of the same tenets I do when I lead development teams. Ubiquitos automation of builds with integrated unit testing that can pre-empt the build process etc. Continuous integration. Improved communication, debugging and testing throughout, not just at the end etc.

Jeremy

Re:An important security sidenote

[CTachyon]

As to Charles-A's question about why not use boundary checking, *is* there some reason why it's not typically used?? (at least not in C)

(A) People think it's slow. In the case of an inner loop, they might actually be right, but the correct course of action is to move the boundary check to just before the loop. (This was one of the big reasons people complained about the speed of early Java revisions. Newer ones optimize the check when they JIT, I think.)

(B) People think they've already created a sufficient boundary condition (e.g. '\0' with C strings) and don't give any thought to abnormal inputs. Too few programmers understand the concept of "defensive coding".

(C) People *do* check boundaries, but the size can be wrapped around with an integer overflow and made to pass the check. E.g., suppose that on a 16-bit system, a string that's 65,534 bytes long needs to have a 4 bytes filename suffix appended to the end, and the result is stored in a 1KB buffer. The length according to the check is 65534+4 = 65538 mod 65536 = 2, because the number wraps around to 0 when it's too big. Since 2 is less than 1KB, the check succeeds, and 64KB of data gets written to a 1KB buffer. Integer overflows are devilishly hard to program against, which is why I believe it's a huge mistake that C doesn't have any mechanism to make them raise an error of some sort on overflow (most processors support something like that, and some extra work by the compiler can fake it on those that don't).

Re:An important security sidenote

[Mr 44]

Yup, spyglass came from mosaic. But IE3 was the last to use the spyglass code, IE4+ MSHTML rendering engine was re-written from scratch.

Re:An important security sidenote

[mewphobia]

Why can't the NX bit be set on the heap?

Re:An important security sidenote

[CTachyon]

How would you put function arguments on the heap?

You wouldn't directly. You'd allocate a buffer from the heap, then push a pointer to it on the stack.

What scenarios are these?

The big one is return into libc. Since the C library contains valid functions that are already marked as code, all you have to do is find one that does what you like, e.g. something from the exec family. As you're overflowing, you overwrite not just the return address, but the memory after it, creating a fake function call frame with new parameters. In memory, it looks like this:

Buffer: XXXX XXXX XXXX XXXX ...
Saved registers: YYYY YYYY
Return address: ZZZZ = Address of libc function F2
Return address for F2: AAAA (not necessarily used, exec doesn't return)
First parameter for F2: BBBB
Second parameter for F2: CCCC
...

You can also return into functions specific to the program, and you can return into the middle of a function, perhaps after bypassing security checks.

Re:An important security sidenote

[jseale]

You still have that? Geez! That's practically a collector's item now.

Re:An important security sidenote

[eugene ts wong]

Did you know about the "* html" CSS hack for IE? Only IE can understand it, so you could give IE a totally different set of styles. If this doesn't work for you, then why not?

Re:An important security sidenote

[TheAncientHacker]

Perhaps you hadn't done any prior to the October release. I had precisely ONE security fix. Maybe updating more than once a quarter might be in order. (Or at least bar yourself forever in saying how awful it is that Microsoft doesn't do fixes fast enough if you don't install them promptly)

Re:An important security sidenote

[Dorothy 86]

I have a worse CD...If you put it in the Drive it starts (and sans the prompts, finishes) to install ME :(

Re:An important security sidenote

[BlueStraggler]

(D) Programmers indirectly constrain the input, but then the code is reused or extended beyond its original use, and the old assumptions about input constraints are no longer valid. (Eg. 8-character filenames, 32-bit native word size, etc...)

(E) Programmers don't bother because it's garbage code that does a one-off task and will never see service in a production environment, and then they get hired at another job, and their garbage code is put into production because "it seems to work".

(F) Because they use a strong array processing language that can do automatic array bounds checking with a compiler switch, so why bother? And then someone further down the chain forgets to include the bounds checking switch and runs it with no safeguards.

(G) Laziness.

(I) Ignorance.

(H) Stupidity.

Re:An important security sidenote

[mewphobia]

but a lot of programs put some or all of their buffers in heap memory instead, and the heap can be attacked as well

How would you put function arguments on the heap?

You wouldn't directly. You'd allocate a buffer from the heap, then push a pointer to it on the stack.

Sorry by your response i've realised I misunderstood what you were saying. I thought you meant that you don't need a stack, because all buffers were on the heap. And so I was giving the example of function arguments as a counterexample. But now after re-reading, I get what you mean :)

There are still some scenarios that aren't protected by a stack canary, but it is rather effective overall, and actually protects against a few scenarios that the NX bit doesn't cover

What scenarios are these?

I was actually asking about the scenarios that the NX bit doesn't cover that stack canaries do? I've done penetration testing against stackguarded machines, but never come across the NX bit (changed my career before there were any NX protected user machines).

Re:An important security sidenote

[malfunct]

There are enhancements in the code compiled for SP2 that don't require a newer processor though the NX flag is only in newer processors. The point is that SP2 is better even for people without the NX flag due to changes in the compiler.

Re:An important security sidenote

[Erik Hollensbe]

Or, you could use a database that supports binding in the client API, like Postgres or Oracle. SQL injection then becomes the responsiblity of the database vendor, not your application.

Re:An important security sidenote

[CTachyon]

I was actually asking about the scenarios that the NX bit doesn't cover that stack canaries do?

Like I said, return into libc is the obvious one. Since a return into libc attack still requires overwriting the canary to get to the return address, a stack canary still prevents it from happening, but the NX bit approach can't stop it since libc *can't* be NX.

Stack canaries have different problems. First, since the security relies on the attacker's inability to guess the canary, the random algorithm is a huge weak link. Eris help you if you're using linear congruential. Second, since the stack canary isn're-seeded each time, there are scenarios where an attacker gets as many attempts as he likes to guess the canary, over as long a time as he likes. For instance, if you're using a pre-forking server like Apache, or just any old fork-on-accept server, each copy of the server is using the same canary, since they were forked from the same parent instance. (Unless your C library is aware of the canaries and re-randomizes them on fork() -- which is tricker than it sounds, because now all the canaries in the cloned call stack are invalid. Even if fork() is updated, multi-thread servers are likely still vulnerable. It's really tricky to get right if you're not re-randomizing with every function call, and if you are, you have the question of where to store the "canonical canary" to compare the stack canary against. You can't really store it on the stack, now can you? You might end up spending a register just on the canary, which on the register-starved x86 can kill you.)

Re:An important security sidenote

[CTachyon]

Actually, on a *real* OS (e.g. Linux, 32-bit Windows), the heap is a per-process area. It starts out as unallocated address space, and when the program needs more heap space, it asks the OS to map in more memory to expand the top of the heap. The heap allocator then breaks the heap into smaller chunks for the program to use. There's no reason why the heap shouldn't be marked NX by default (the program can always request execute permission if it's e.g. JITing something or building a trampoline).

(For anyone who's coded before but doesn't know what the heap is, it's where memory comes from when you call C's malloc, C++'s new, Visual Basic's Redim, etc. When a program needs memory, but doesn't know how much it needs until right before it asks, it's almost always using the heap.)

(Oh, and since there's probably someone out there wondering how the heap can be attacked, the problem boils down to the fact that each chunk of memory in the heap is part of a doubly-linked list. If you overflow your chunk and scribble on the header of the next one, the list pointers of the next block can be changed to point at any memory address you like. If you're very, very patient, you can figure out how to scribble on the heap in such a way that you can write any number to any place in memory, effective as soon as the program tries to free the chunk. The details vary a lot depending on the heap's implementation details, which can vary even from program to program on the same OS (e.g. the dlmalloc library on Linux replaces the built-in heap allocator in libc).)

Re:An important security sidenote

[fatphil]

So, is a postscript document data or code?

FP.

Re:An important security sidenote

[Reziac]

Ah, thank you, I think (now my brain hurts, but I get the idea :)

...and don't give any thought to abnormal inputs. Too few programmers understand the concept of "defensive coding".

Hire me ("The beta tester who can break anything!") to test their software, and they'd soon learn better... "what happens if I click over there?? What if I type in this random nonsense instead of what it expects?? Whoops, when I make it do 40 things at once, it falls down goes boom... Even tho I seldom do such things on purpose, I seem to find a lot of such errors :)

I've seen what's probably a "whaddya mean it's wrapped around and died" result with a "too much data" situation in an old DOS app... locked it up good and solid. I had to be careful never to exceed 32k (actually 30k plus some room for overhead) or it fell over.

Re:An important security sidenote

[DunbarTheInept]

The point is that if you declare that a mark of a bad OS, you've just damned all that major players in the OS market - they all have problems with that scenario. (It won't lead to a crash, but it will render the system so slow and unusable that it takes less time to reboot and check the disk than it does to actually kill the offending program.)

Re:An important security sidenote

[DunbarTheInept]

The point wasn't about user experience - it was about whether it is better to follow HTML standards or be lenient. If the standards were followed, the users wouldn't be seeing those broken pages because the page authors wouldn't write them that way in the first place. They get written that way because there exist browsers that allow it to work that way. You're acting like the browsers are written to deal with the HTML that people write. It's the other way around. People write the HTML that works with the browsers people use. Therefore the end-user is blissfully ignorant of which way around the web-authoring and browser-authoring community is doing it.

Re:An important security sidenote

[DunbarTheInept]

OF course I still have a point - a point that the original author agrees with, as shown by the quote you yourself chose to include - that while this does show a problem in firefox (and other browsers), this does not show IE to be more secure. It does the kind of test IE is good at - not crashing on random HTML. It avoids the kind of test IE is bad at - abuse of its specialized features.

Re:An important security sidenote

[spectecjr]

That is my point. Microsoft Press the publisher is not Microsoft the software company,

Err... yes, they are.

They have common streams of funding, but they are not the same. The same goes for Microsoft Research (who employs such luminaries as Butler Lampson, Gary Starkweather, and Gordon Bell).

No, actually, they're Microsoft the software company. Just because it's a different division, that doesn't mean it's a different company.

Re:An important security sidenote

[linear_shift]

Yeah, that was roughly what I was trying to say about how you'd attack the heap, the specifics were still more or less in the back of my mind (plus it was posted at about 12:30 MST, niks DST, and I wanted to get some sleep ;) ). I do remember what the heap is, what its for, and more or less how to utilize it, but, as I said, its been a while since I any "real" coding, so I'm not apt to give a real good definition ;P As far as the NX bit goes im not really informed with current x86-64, or really AMD/Intel x86 [current] in general, I'm still mucking around in with T-bird Athlons, older Celerons/Durons, and older Transmetas, in the x86 world, anyway.

Anyway, thanks for clearing that up and putting in the specifics for me :) Now if you'll excuse me I need to go refresh my memory, esp. since I'm designing, and hopefully later writing/rolling my own OS (slashlink above, the site is down, though. Plus I'm planning to move it to SourceForge anyway ;P ), I'd think I'd need to remember how to perform a bloody stack call :P

Re:An important security sidenote

[linear_shift]

I wouldn't really know, I'm not exactly current with AMD/Intel x86-64, the majority of the programming I have been doing lately is for the little 3.6MHz 16-bit Motorola 65HC02 on my little OnHand wristwatch-pda. Anyway, it now occurs to me that it probably could, so long as the program asks for execute permission first. So erm, nevermind ;P

Re:An important security sidenote

[fstrauss]

To a pc program definitely data. I'm not sure what it is to a printer, but i'd guess data too, as i highly doubt a printer executes it.

Would you consider a tiff code?

Re:An important security sidenote

[fatphil]

In that case, you should bow out of the argument now, before you embarass yourself further.

Postscript is a language very closely related to Forth. It's no more data than Java, Perl, Basic, JavaScript code are.

FP

Re:An important security sidenote

[fstrauss]

Just because it is a language does not mean it get's compiled to a binary that your cpu executes. Another program is needed to interpret it, to that program it is data. None of the languages you compare it to get compiled to a binary. Even java still needs a virtual machine to execute in.

How many years experience as a developer do you have? Just so i know what level of expertise i'm trying to convince here.

Re:An important security sidenote

[fatphil]

Just give me a yes or a no -
are Javascript programs, Perl programs, Java programs, and Basic programs just "data"?

Everything you've said so far leads me to believe that your only consistent answer would be "yes".

I'm in my third decade as a developer.

FP.

Re:An important security sidenote

[fstrauss]

yes, they're data

the mean nothing to your cpu without an interpreter

Re:An important security sidenote

[Dashing Leech]

It got rated a Troll? Wow, somebody can't take a joke (or tell the difference).

Re:An important security sidenote

[dotnetgurus]

My first instinct would be that the HTML parsing engine in Internet Explorer was written by a different team of programmers than worked on the rest of the software, and they used proper programming techniques (such as RAII in C++, or perhaps used one of their .NET languages, rather than programming in straight C like the others) which as a side effect prevented such problems.

No part of IE is written in any .NET language. If it was then the .NET framework would have to be installed to run IE. This is not the case, there are many Windows machines that can use the current version of IE and don't have .NET.
I suspect that IE code is written in C++. However, last year Microsoft released a version of the C runtime library that protects against buffer overruns (all buffers are bounds checked). I suspect that this is what has removed the vulnerabilities. This library is freely available, so the other browsers targetted for Windows should be able to improve too.

Re:An important security sidenote

[dkf]

Actually, you only need to single-step the instructions that write to memory. That's what memory-debugging tools like Purify do.

Because it's used to it?

[ideatrack]

There's a good phrase I can use to explain this one:

If you work in a monkey house, you expect to be pelted with shit.

Re:Because it's used to it?

[plover]

At first glance, I thought the original title of the story was "IE Shites On Broken Code".

I guess I wasn't that far off.

hmmm

[Anonymous Coward]

I'd love to read the article, but the page seems to contain malformed HTML...

Slashdot browser testing?

[richie2000]

It's strangely fitting that the response I first got was the error message: "Nothing for you to see here. Please move along." The Slashdot effect has finally spread to the browser.

However, my Mozilla passed the test without crashing. :-P

What they didn't say

[Anonymous Coward]

They didn't say that IE also started randomly installing Bonzi Buddy et al during the test, the users' credit card numbers were automagically emailed to Romania, there was an sudden increase in outbound port 25 traffic from the system, and they ended the session with about 37 momre toolbars installed then they started with.

Re:What they didn't say

[b374]

hey... I'm from Romania... can you tell me where do I subscribe to that credit card numbers email list?

Security Issues

[PrivateDonut]

Does the fact that most of the browsers crash mean that they are vunerable in some way? or does the fact that they do crash a good thing?

Re:Security Issues

[mccalli]

Does the fact that most of the browsers crash mean that they are vunerable in some way?

Potentially.

does the fact that they do crash a good thing?

No. Never ever is it a good idea to crash on receipt of invalid data. It's up to the program to try and parse this, realise it can't do so successfully, then act ccordingly (error message, best-guess try, whatever. I prefer error message myself, but can understand those who prefer best-guess).

Cheers,
Ian

Re:Security Issues

[Trillan]

XHTML is supposed to be refused if malformed; HTML prior to 4.0 is supposed to be best-guessed. I'm not sure what the behaviour of 4.0 Transitional and 4.0 Strict is supposed to be, but I'm sure it's documented as part of the spec.

Re:Security Issues

[iamdrscience]

Speaking of best-guesses, I recall a problem I had in Debian once that resulted in an error message something to the effect of "XYZ not found. Trying to wing it..."

Re:Security Issues

[say]

I'm not sure what the behaviour of 4.0 Transitional and 4.0 Strict is supposed to be

It's kind of in the name. Transitional should best-guess. Strict should not.

Re:Security Issues

[muhcashin]

It just means that IE for some reason or another is more robust than the other browsers, in terms of dealing with bad input. Feeding malformed input to any program is a way to test its robustness. Crashing applications is never a good thing. However in this case, if it crashes, then the program is stalled and no harm is done except that you have restart the browser. On the other hand, if IE does not crash and the others do, their must be something it does to make it withstand such treatment. That something could possibly be exploited. Mind you, I don't what kind of crap you can a feed browser to make it crash.

Re:Security Issues

[Bas_Wijnen]

Never ever is it a good idea to crash on receipt of invalid data.

You are talking about web browsers, and for those I agree. However, there are programs which should crash, in particular programs which trust the source of their input. If a trusted source sends malformed data, then something is terribly wrong, and ignoring it may corrupt the database the program is handling, for example. In such a case, a crash (or panic, whichever word you like better) is a good thing.

Of course this type of crash, which is triggered by the programmer, is very different from a really unexpected crash. Those are never good.

Re:Security Issues

[FireFury03]

XHTML is supposed to be refused if malformed; HTML prior to 4.0 is supposed to be best-guessed.

This reenforces my belief that XHTML is the way forward since it reduces the code complexity of the browser:

XHTML: Try to parse - fail - give up
HTML: Try to parse - fail - Try to reconstruct - hit bug - crash

XHTML is also good because it removes the fuzzy area of what to do if the code is crap - with HTML, a web developer will write a page, won't bother to validate it and just check it works in IE. Since different browsers have different methods of fixing broken code, the results of this page are not platform independent. With XHTML, if the developer writes broken code it just plain won't work. The management who pay the web developer probably don't know anything about standards compliance and if it works in IE the developer gets paid, but if it just sits there with a parse error the developer will either have to fix it or not get paid (Good Thing).

That said, IMHO there is something to be said for a couple of additions to the XHTML spec:

1. a button on the "parse error" page which tells the browser to render it as tag soup - that way the end user can try to view the page anyway even if it's broken (whilest still being informed that it really is broken code).
2. an automatic feedback system in which the browser will post details of the parse error back to the server. Otherwise the developer may never know there's a problem (especially important with dynamically generated markup which may not be easilly validated).

Similarly, it would be really nice, IMHO, if browsers made it clear (by placing a big X on the status bar or something) when they are viewing broken *HTML* code since this would indicate to the user why the page might not look quite right and would be an indication to the management not to pay the web designer they hired since he is obviously lacking in the ability to do his job.

Re:Security Issues

[Anonymous Brave Guy]

XHTML is supposed to be refused if malformed

But is that according to the people who wrote the XHTML standard, or the user who just wants to see the web page? One is rather more important than the other in this context.

Re:Security Issues

[Anonymous Brave Guy]

However, there are programs which should crash, in particular programs which trust the source of their input.

I think there's a difference in how you're using the word "crash" there. In one case, we're presumably talking about the application being shut down abruptly by the OS having attempted to violate system integrity. In the other, we're presumably talking about the application realising it cannot complete its task, taking whatever error recovery might be appropriate, and then immediately shutting itself down rather than attempting to proceed with bad data. There's a world of difference in terms of security and robustness between those two cases...

Re:Security Issues

[xoran99]

The damage is done! Malformed html is now a part of the culture. Have you ever tried to validate Microsoft.com? Madness.

Re:Security Issues

[JohnFluxx]

Actually I think it is you that is confused.

It's all about pre-conditions. If your pre-condition is that the data is trusted and correct, then if that data violates the pre-condition, then your program is free to do whatever it wants - from root your system to blow up the monitor.

Unfortunately it seems wikipedia doesn't have a good article on preconditions. It just says this: http://en.wikipedia.org/wiki/Precondition

Re:Security Issues

[Ford Prefect]

It's kind of in the name. Transitional should best-guess. Strict should not.

Not really - HTML 4 Transitional was designed so that it wouldn't be so much work for sites to change their markup from the previous, somewhat ad-hoc standards. As a result, it includes various tags and attributes from HTML 3.2, usually to do with more visual aspects of page layout. Such features aren't present in HTML 4 Strict, where CSS is used for visual formatting (almost) throughout.

References to the Transitional DTD appear at the top of many HTML documents which aren't anywhere near valid HTML 4 Transitional - I suspect this is why many browsers go into some kind of 'Quirks' mode when they see it. The Transitional specification is just as definitive as the Strict one, it just includes a lot of older features for the sake of compatibility and conversion.

Still, it says something about how much the W3C's standards are respected when even now, hardly anyone bothers following the Transitional spec from 1997, considering it too difficult...

Re:Security Issues

[Just Some Guy]

But is that according to the people who wrote the XHTML standard, or the user who just wants to see the web page?

Just to be clear, unparseable XHTML is not XHTML. In "Matrix" terms, there is no web page. Instead, there is a string of text that may resemble XHTML to the casual observer but that doesn't really represent anything at all.

Arguing that browsers should half-support broken XHTML is like saying that a C compiler should do something whenever it encounters invalid C, since the user obviously wants to run the code and isn't interested in bowing to the pedantic demands of some irrelevant standards committee.

One is rather more important than the other in this context.

I agree completely, but I don't think it's the one that you picked.

Re:Security Issues

[Bas_Wijnen]

Indeed. I tried to make that clear in my post. The point is that for users, the result looks the same: the program aborts.

Re:Security Issues

[say]

hardly anyone bothers following the Transitional spec from 1997, considering it too difficult...

Actually, I find XHTML everywhere nowadays. Just not on big dynamic sites, like government agencies, newspapers and so on. But many smaller sites are converting/have been written in XHTML. Which is really good.

Re:Security Issues

[DavidTC]

Many people think that, but no. All transitional means is that you don't have to move all your formatting over to CSS. All XHTML is supposed to fail if malformed, just like all XML is. Thank God.

Re:Security Issues

[cbiltcliffe]

I had in Debian once that resulted in an error message something to the effect of "XYZ not found. Trying to wing it..."

I think I've had that one before.... :)
I've also had one on boot that said:
"Uuuuhh. Dazed and confused. Trying to continue..."
Turned out that one was a bad memory controller on the motherboard...

Re:Security Issues

[jrexilius]

Yes, but how it is refused is the question. I agree with the principle that you should stop parsing the invalid data but not crash the application. Refuse to parse a page and give the user an error message saying sorry this page cannot be displayed, would you like to view it as plain text or some such.

I also realize that sometimes you cant always do that easily and sanity checks of exit (possibly with dumps or debug data) are better then nothing. When you get to this point it does start to beg architectural and design questions but it is still reasonable to exit ungracefully at times.

Re:Security Issues

[Anonymous Coward]

Arguing that browsers should half-support broken XHTML is like saying that a C compiler should do something whenever it encounters invalid C

While I understand the point you're making, C compilers generally do do something with invalid code. Constraint violations (sometimes referred to as syntax errors) require that the compiler output a diagnostic message, but they're free to continue to translate the code. Witness how gcc 2 dealt with:

const int x = 0; x = 1;

Then there's what's called undefined behavior. No diagnostic is required, but the code still violates the standard. It can compile, but the result is that anything could happen. For example:

i = i++;

So basically, C does what the OP is asking XHTML to do. Is this a good thing? I don't know. It makes compiler writers' jobs easier, and gives less overhead, and if you want all that safety, there are always languages like Ruby.

Re:Security Issues

[DrPizza]

"Just to be clear, unparseable XHTML is not XHTML."

And broken HTML is not HTML.

The reason browsers try to parse broken HTML is not because the HTML spec requires them to do so (it doesn't, and it gives such documents no semantics). It's because neither early browsers nor page authors followed the specs strictly; early browsers would try to render malformed pages (either deliberately or through not explicitly rejecting such pages), and early page authors would (usually unwittingly) exploit this fact.

If the first HTML renderers had followed the HTML spec and no more then the web would not be the mess it is today.

XHTML doesn't really fix any of this; it resolves a small class of ambiguities that un-DTDed HTML hypothetically has (in HTML one needs to refer to the DTD to determine whether something of the form <img> is an empty element or a malformed element that lacks is closing tag (the DTD says whether things are empty or not); in XML (and hence XHTML) it's unambiguously an error because XML requires even empty elements to have closing tags, or use special shorthand). But it's not this that make it easier to parse; that alone has negligble impact on ease of parsing.

Instead, it's the attitude that goes along with it--if it's not well-formed, reject it with an error message. There's no reason that the HTML spec couldn't be held in similarly high esteem.

Re:Security Issues

[shiftless]

ISOLINUX 1.75 2002-06-14 isolinux: Loading spec packet failed, trying to wing it

Re:Security Issues

[Trillan]

I never said anything about crashing the application -- to generalize perhaps just a bit, no application should ever crash based on input data. Refuse to process the data, certainly, but that refusal should be deliberate and not due to code that assumes some condition without checking and crashes.

which version of IE was it?

[jonwil]

Aparently, XPSP2 (including the new IE) was recompiled with the latest visual studio and with all the options turned on to better catch issues.

Re:which version of IE was it?

[metlin]

Not just that - you have access to the code of all the browsers that he's mentioned (except Opera).

Mozilla, Links and Lynx.

I'm not saying that the bugs do not exist, but if I had access to all that code (and presumably to IE too, since he's been at MS that long) - then it's quite conceivable that he came up with stuff that will crash on these browsers.

-tinfoil hat-

He _does_ work for Microsoft still, does he not? :)

-/tinfoil hat-

Re:which version of IE was it?

[wimvds]

Indeed, I seem to recall something in IE 5, which led to a crash. Someone still using it? If so, create a HTML page with , if memory servers me right it will crash Internet Explorer :p.

Re:which version of IE was it?

[wimvds]

Indeed, I seem to recall something in IE 5, which led to a crash. Someone still using it? If so, create a HTML page with an , if memory serves me right it will crash Internet Explorer :p.

Re:which version of IE was it?

[ClosedSource]

So your theory is that having access to the source of these browsers has enabled an individual to crash them, but having thousands of people have the source code hasn't resulted in the problems being fixed already.

Re:which version of IE was it?

[metlin]

No, my theory is that while these bugs are serious in themselves, if I had access to IE's source I maybe able to come up with code that would crash it, too.

Although thousands _can_ see them, very few actually do. There's a difference.

Either way, kudos to him, and a good job at finding the bugs. But that still wouldn't make me change to IE anytime soon.

Re:which version of IE was it?

[Erasmus Darwin]

"I'm not saying that the bugs do not exist, but if I had access to all that code (and presumably to IE too, since he's been at MS that long) - then it's quite conceivable that he came up with stuff that will crash on these browsers."

Except that he 1) provided a copy of the random malformed HTML generating tool that he used and 2) managed to crash the closed-source Opera, as well.

It's a little ridiculous to suspect that he spent countless hours searching the mozilla, links, and lynx source code to find HTML-interpreting crash-causing bugs and then created a random malformed HTML generator as a cover story as to how he found the bugs.

Re:which version of IE was it?

[mark_lybarger]

it's actually (no equals sign or quotes) wrapped around form and html tags. unfortunately i can't test it out much as my trend micro scanner deletes a file as soon as i save it.

Re:which version of IE was it?

[sysadmn]

Possible, but unlikely to have impacted this test. The XPSP2 update is supposed to cause malformed code to crash an app, rather than subvert it. The point of the article is that IE didn't crash. Sure, it's because MS already does this sort of testing - but the point is that others ought to as well.

Re:which version of IE was it?

[julesh]

Err, you may want to switch to extrans when posting HTML code. :)

Re:which version of IE was it?

[julesh]

Actually, MS have never used Visual Studio (whatever version) to compile any part of windows.

Visual Studio just isn't up to a project of that size.

Really? Many of the components that were included in the source code leak were of sizes similar to projects I've worked on with VS '97. Although, IIRC, there weren't any .dsp or .vcproj (or whatever) files in there, so maybe they don't use it anyway. Just saying, I don't think the size is the reason.

Not that I downloaded the source or anything. Wouldn't involve myself in such a blatant violation of MS's copyrights. Just word of mouth, kind of thing, you know?

Re:which version of IE was it?

[egoots]

Don't throw the baby out with the bathwater. If you are saying thet using MS Visual Studio and setting them up as a "project" (dsp/dsw/vcproj) in the IDE, I might agree with you. However, you can still use the compiler and linker and make file proecessor in Visual Studio and manage massive projects. Mozilla does this for example.

Re:which version of IE was it?

[beuges]

While Larry Osterman (who posted the story on his blog) recently celebrated his 20th anniversary at Microsoft, I have not yet been able to find anything that says that Michal Zalewski (who found the bugs and made the post to Bugtraq that Larry linked to in his blog) ever worked for Microsoft.

What I did find, however, was this:

"Michal Zalewski is a security researcher who has worked on topics ranging from hardware and OS design principles to networking. He has published research on many security topics and has worked for the past eight years in the InfoSec field for a number of reputable companies, including two major telecommunications firms."

So I doubt Mr Zalewski has ever had access to any of IE's code.

So what is "random" here?

[Anonymous Coward]

Without looking at it more closely my first reaction is, well for his values of "random" this might be true. But random is a horribly abused term in computer science. First of all it was no doubt arbitrary within certain ranges rather than random. Then, we need to look at why he chose those ranges.

Re:So what is "random" here?

[Kick the Donkey]

Thats the thing about randomness. You can never be sure.

Re:So what is "random" here?

[Lodragandraoidh]

His program was sending malformed HTML. Logically, you could collect the 'failures' and do correlation on what you found - hence his estimation of some of the problems being related to specific C library functions and their misuse (calloc, strlen etc...).

This is a good thing, because the developers of the browsers in question will now be able to refactor their code to handle error conditions properly.

On the other hand, while IE may have passed this 2 hour (his admition) test - that is certainly not definitive proof because there are too many unknowns (did the tests go through every HTML construct in all possible permutations? I am guessing not). Given the subset of potential malformed HTML thrown at these systems - yes IE won. Is that the final word on this? No, MicroSoft has a long history of poor software security that we can't simply sweep under the rug. Without the source, barring a complete test that covers all possible permutations, we will never be able to validate that assumption.

In a land of broken codes...

[kusanagi374]

... the broken app is the king!

Finally...

[fredrikj]

...a benchmark that actually measures real-world performance.

Off Topic

[z0ink]

With such a powerful parsing engine you would thing IE could parse web standards a little better.

Re:Off Topic

[CrazyWingman]

Actually, have you ever tried to write a parser for any "standard" language? It is almost always the case that you can parse 85% of the standard without any trouble at all. Then, in the last 15% you will find something that is just so complicated to do in your system that it's usually just easier to give up ...er... I mean promise it in Version 2.0. ;)

Re:Off Topic

[SpaghettiPattern]

With such a powerful parsing engine you would thing IE could parse web standards a little better.

Has it ever occurred to you that it is in MS interest to parse bad HTML? Maybe even to encourage bad HTML so IE is considered the best browser by the man in the street. Now where's my tin foil hat?

Re:Off Topic

[DrSkwid]

yes, it's here http://validator.w3.org

Biased = 0?

[octaene]

Sounds like a "here comes the science" article to me. I find the information in the article lacking since no mention is made of what version of IE is being used to conduct these tests.

Excellent!

[Mysticalfruit]

I suspect that the mozilla developers will be busy using this same tool to vigorously debug their application...

*shrugs*

So, if you feed IE random crap it doesn't crash? Too bad when you feed it stuff you'd like it to crash on (auto execution of malicous code, etc, it works just fine...)

When all is said and done, I still feel 100% safer surfing the web with some Gecko deriviative...

Re:Excellent!

[LiquidCoooled]

I still have a link on my xp desktop here called "crashme.htm". I used to be able to bring IE to its knees with it.

It consists of 11 characters - a Style opening tag and some malformed crap after it. It doesn't make it crash anymore, but I keep it there as a reminder.

MS mustv done a major cleanup of code to prevent egg on their faces. SP2 has also done a lot to cure problems of this nature.

I think MS might actually (finally) have an upper hand with this. Throwing manpower and resources at the problem will no doubt have assisted. However, this is only one facet in a much larger stack of cards.

Of course, just like you I don't see it as a problem and the OS developers will cure all issues allowing us to browse easy once again :)

Re:Excellent!

[metlin]

Actually, the code does not seem that great.

Here's the mozilla_die1.html code

<HTML><INPUT AAAAAAAAAA>

And the mozilla_die2.html code

<HTML>
<HEAD>
<MARQUEE>
<TABLE>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<TBODY>
Attack of the marquees!

It looks like he came across places where either boundary checks or type checks are not in place.

Besides, he's had access to almost all the browswer code, hasn't he?

I mean, these bugs are bad, but I'm sure if I had access to IE's code I could come up with a zillion bugs.

Re:Excellent!

[eht]

One guy with ten minutes came up with ways to crash Mozilla, Lynx, and Links, yet hundreds of thousands of programmers with years of access to the same code haven't fixed these same bugs.

Re:Excellent!

[Anonymous Coward]

contrary to belief access to thousands of programmers does not necessarily mean everyone looks at the code

there is a difference

Re:Excellent!

[EMN13]

As he stated in the article; the crashes are sometimes platform-specific.

I've tried this in 1.0PR firefox on win32, and the crashes do occur there.

I've gotta say - this really looks like a great tool; a simple and effective way of finding some bugs!

--Eamon

Re:Excellent!

[ggy]

No to mention the wonderful JScript that logged WinXP users out of the system. :)

Am I the only one remembering that one?

Re:Excellent!

[GAlain]

Nope, sorry... I've tried this using FireFox 1.0PR on Linux & win32 and Opera on Linux & win32 too; same things happenned: input box for the first and nothing for the second... Nothing so nasty happenned

Re:Excellent!

[SpaghettiPattern]

So, if you feed IE random crap it doesn't crash?

A program like a browser being fed random crap should never crash!!! It should either report syntax errors and/or do its best in correcting syntax errors because many/most bad HTML writers are not easily persuaded to correct their errors.

Come one, this time IE is more stable than our beloved Mozilla.

Re:Excellent!

[Christianfreak]

I opened these in Firefox on Linux. Die 1 showed an input box, Die 2 showed nothing at all, but neither crashed the browser.

Re:Excellent!

[roca]

On any given day we know of many HTML inputs that will crash Mozilla, and many that will crash IE, and ditto for other browsers. Which ones get fixed is simply a matter of priorities. And we prioritize by looking at the crash to see if it looks like it could be turned into a security hole; looking at talkback data to see which crashes people are hitting most frequently; focusing on the ones that occur on actual real websites, and maybe after that when there's nothing else to do we fix the ones exposed by artificial testcases.

No-one has enough resources to fix every bug, not even Microsoft.

Re:Excellent!

[sysadmn]

But the point of the article is that he didn't need access to source to create the tests. He just threw random junk and the browsers and noted which input made them barf. Clever idea, but some of us remember when you did this with a command line tool (crashme) back in the days of 68020s.

Re:Excellent!

[plj]

Interesting. I'm running FF 1.0PR on Redhat EL3, and mozilla_dies 1 & 2 crached my browser. Third test only showed a broken applet placeholder, as expected.

Re:Excellent!

[iabervon]

In mozilla_die1.html, you're missing an ASCII NUL, which is what is supposed to make the difference.

I wouldn't be too surprised if it were impossible to crash IE with randomly malformed HTML, because I bet that IE uses an SGML parser to extract a valid document (or nothing) from the file, and does not do anything tag-specific in parsing. This means that a relatively simple chunk of code is all that sees the random garbage, and the HTML engine gets nicely cleaned stuff.

I actually suspect that they're using an XML parser which supports being permissive in a variety of ways, including all of the ways permitted by SGML, but producing a parsed XML document which is completely valid by the DTD by ignoring anything completely unparsable.

This is not to say that IE is actually secure or anything; just that it is only vulnerable to valid but tricky HTML.

Re:Excellent!

[joel2600]

don't forget that most all of the Windows source code leak was actually most, if not all of the code for internet explorer.

a zillion bugs? you better get cracking.

Re:Excellent!

[Tralfamadorian]

Except that as others have posted, IE can be crashed on 100% valid XHTML (http://it.slashdot.org/comments.pl?sid=126192&cid =10563636)

This one is my favorite:

http://www.student.citg.tudelft.nl/c9864875/boempa ukeslag.html

The html there is so simple, no outrageous sizes, no nulls.

I agree that mozilla has a bug, but I don't think that IE is any better in the crashing on various input (now, if these are security threats.... that's another issue)

This is a blessing in disguise

[Darren Winsper]

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.

Re:This is a blessing in disguise

[pohl]

I remember crashme, and I just checked the debian packages and anybody can "apt-get install crashme" to give it a whirl.

I'd like to second the AC's suggesting of taking these HTML test cases and constructing an apache module that creates garbage HTML like this. The result would be a great contribution all browsers.

The mozilla project did have a test that sent the browser to random pages accross the web, which exposed it to all sorts of garbaged HTML, I'm sure, but generating randomly garbaged HTML would probably be a more strenuous test.

Re:This is a blessing in disguise

[Darren Winsper]

I don't see a need for an apache module, just have a script to do it, spawning mozilla-firefox each time. If the process dies, you've encountered a crash.

Re:This is a blessing in disguise

[pohl]

That would put a limit on the number of tests per unit of time you could perform. The server-side script does not necessarily needs to be in C. Any server-side scripting language would be fine, and would be no more difficult than the launch script you describe.

Re:This is a blessing in disguise

[iabervon]

An apache module isn't really a useful way to do it, because then you'll crash the only program that gets the test case, making it difficult to send it in with a bug report.

Re:This is a blessing in disguise

[Bazzargh]

"...you'll crash the only program that gets the test case, making it difficult to send it in with a bug report."

Not entirely true. While you have to do some work to get to a crash report, you want to generate the fuzz pseudo-randomly from a seed, always pushing the code that will fetch the next random page, with the seed as a parameter of the URL. With this setup, it should be possible to easily spot and reproduce crashes from the logs (the last URL served to each client crashed; since its only pseudo-random you can reproduce the test).

Frontpage

[bmongar]

Of course IE can handle broken html. That's what Microsoft Frontpage produces. They have to be able to handle their own product.

Re:Frontpage

[Angostura]

Why does this tedious MS bashing get modded insightful. Funny, at a push. But insightful?

Re:Frontpage

[ggy]

Hehe, I just helped an ex-coworker with HTML produced by Office 2000, which worked perfectly in Firefox, but displayed *alot* of garbage in IE (6SP2). A quick tour through HTMLTidy and it worked in both, with 50% of the filesize.

Re:Frontpage

[g051051]

Because it's true. This comment was almost exaclty what I was going to post. I've had to deal ith the incredibly broken output of Frontpage, and the idiosyncracies of IE for years.

To be fair, it certainly is not correct behavior for a browser (or any program) to crash on bad input. But citing IE for it's ability to deal with malformed input (which is another way of saying "lack of standards compliance") is pretty funny.

Tried with Safari on OS X ...

[Anonymous Coward]

Nothing crashed. I got blank pages, all the weird HTML and all, but no errors and nothing crashed. w00t.

Re:Tried with Safari on OS X ...

[Chanc_Gorkon]

I secodn that. Tried the 4 or 5 examples on the web page and had zero issues. My guess? They only tried browsers available on windows.

Re:Tried with Safari on OS X ...

[GAlain]

Does anyone have actually tried the code?
I did try it using Konqueror/Linux, Opera/Linux&winXP, Firefox 1.0PR/Linux&winXP, Mozilla/Linux and IE and nothing happenned anywhere!
I am willing to repeat my question again: does anyone else tried the code and saw something weird?

Re:Tried with Safari on OS X ...

[Anonymous Coward]

http://matt.ucc.asn.au/diesafari.html is a stripped-down version of the output of mangle with seed 0x5cdb0b39 (on 10.3.5, the seeding is probably different on other OSes). It certainly kills Safari here...

Re:Tried with Safari on OS X ...

[GAlain]

OK, I'm backing up this one, firefox & opera crashed. Click like crasy the refresh button if it doesn't ;-)
Konqueror seems to handle everything very well! If I were in the KDE team, I would reconsider the porting of Gecko to KDE for now :-)

Re:Tried with Safari on OS X ...

[HadenT]

Tried (live demo and gallery) on Konqueror 3.3 (from Debian sid) - nothing crashed (my default browser). I'm pleasantly surprised IE did so well, it's usefull test for mozilla devs to take a look.

Re:Tried with Safari on OS X ...

[Carewolf]

We have several bug-reports at bugs.kde.org that can crash both safari and konqueror.

Both document.write calls at bad times and malformed CSS seems to be dangerous to KHTML.

Re:Tried with Safari on OS X ...

[Swedentom]

Works with Safari here on 10.3.5. Displays a huge black box.

Re:Tried with Safari on OS X ...

[gregfortune]

Konqueror 3.2.3 also displays a black box rather than crashing...

Shining us on

[AndroidCat]

This being Slashdot, I had to RTFA to see in what sense IE was shining. (Shining us on = pulling our legs, con job.)

This Is to MS's Clear Business Advantage...

[judmarc]

It encourages web authors to make pages that don't work in other (standards-compliant) browsers. But even MS is getting a bit tired of this, because (1) there are now plenty of pages that don't work even with IE (I encounter them all the time at work), and (2) all the error correction code helps to keep IE bloated and slow.

Re:This Is to MS's Clear Business Advantage...

[nmg196]

> 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).

Re:This Is to MS's Clear Business Advantage...

[fireboy1919]

OTOH, when a IE recieves a bad page load it won't crash, unlike Firefox (it's done this to me many times).

What about this bloated and slow issue? Are you serious? Do you find that IE takes a long time to render things?

My experience is that Mozilla only caught up with IE in terms of speed last year (when rendering hard to render things).

Don't get me wrong, though. It doesn't run all of DOM correctly, which has caused me untold amounts of problems.

Re:This Is to MS's Clear Business Advantage...

[XO]

ah yes, I was just complaining about this sort of thing on Fark..

Here's what I normally have open on my computer:

gaim, sylpheed-claws, wine pokerstars, opera

running under KDE, on a 600MHz computer with 128MB ram.

The machine is perfectly useable, with barely a second of lag time, even switching desktops/to swapped out programs.

Replace Opera with Mozilla.

Whole system becomes completely unusably slow.

Updating Mozilla to latest daily snapshot helped somewhat - as long as I keep it to less than 2 windows, the computer is useable, but very slow.

if only I could get plugins to work right in Opera.. sigh.

Re:This Is to MS's Clear Business Advantage...

[DrSkwid]

did you count in the memory of the Windows DLL's IE loads ?

You remember those, the one's that have arbitrary IE functions spread across them to make removing IE from windows "unpossible"

Re:This Is to MS's Clear Business Advantage...

[nmg196]

It works the other way round. Windows has lots of references to IE in it - Windows does not have lots of IE's code *embedded* in it.

In fact, the very fact that IE also has to handle lots of OS functions as well as being a browser should make it bigger in memory than Firefox - but it it isn't.

If you like, I can add the entire footprint of explorer.exe (12mb) to IE (18mb) and it STILL doesn't use up as much RAM as Firefox is using at the moment with only a handful of pages open (42mb).

Re:This Is to MS's Clear Business Advantage...

[judmarc]

Yep, I'm serious about bloated and slow. I'm using "bloated" to describe IE's code size vs. Opera's. Re: "slow," I've been running Opera for years, until very recently on dialup. At work (T1 line), IE is the official "corporate desktop" browser app. Page render times for Opera, even on dialup, compared favorably to what I saw on IE at work.

A couple of years ago at work I ran Opera "unofficially" until I was asked to remove it, and recently I was granted permission to use it again at work. Much of my work involves legal research on the Web. I find that due to page rendering times as well as various Opera UI features (MDI, mouse gestures, tabbed browsing), I am approximately 50% more productive with Opera than with IE.

Re:This Is to MS's Clear Business Advantage...

[Politburo]

Correct me if I'm wrong, but doesn't Mozilla also use some of those DLLs?

Re:This Is to MS's Clear Business Advantage...

[Synistar]

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).

So I should drop CSS support in my web pages so that IE can render them faster!?! I suppose then you want that I should go back to editing each and every font and table tag by hand and resort to brute force editing of every single page on my site to change the font size and color of the footer. How 1998.

Re:This Is to MS's Clear Business Advantage...

[nmg196]

> So I should drop CSS support in my web pages so that IE can render them faster!?!

No?! What on earth are you blithering on about? I just said that it rendered them slower than Firefox if there's lots of CSS. I don't recall saying that "CSS is crap and you shouldn't use it". Strange man.

Re:This Is to MS's Clear Business Advantage...

[Minna Kirai]

Updating Mozilla to latest daily snapshot helped somewhat

Psst: people who think Mozilla is too slow normally upgrade to Firefox.

Re:This Is to MS's Clear Business Advantage...

[renoX]

> Bloated compared to what?! Slow compared to what?

Bloated and slow compared to Opera for sure.

Re:This Is to MS's Clear Business Advantage...

[azaris]

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.

You'll get a lot of flames for this, but as a Firefox/Thunderbird user I concur. Something must be done about the ridiculous resource consumption of what is supposed to be a lightweight browser.

More annoying is the fact that creating new tabs seems to leak memory which is not released immediately. Lean on CTRL-T to bring up a bunch of new tabs and watch the memory usage skyrocket to 60 MB+. Then do 'Close other tabs', leaving you with a single tab open. The memory usage will remain static for a good while until you minimize Firefox, at which point Windows caches to disk and when you bring Firefox back up the memory is released. Also I'm not sure all the memory is released since all my Firefox sessions get sluggish after several hours, sometimes up to the point that closing the last Firefox window leaves the process running, but no new Firefox windows can be created before I have shut down the old process.

Re:This Is to MS's Clear Business Advantage...

[fireboy1919]

Why not compare IE to Lynx while you're at it? I bet lynx can load pages faster than IE as well.

Opera isn't DOM compliant (it is very, very limited by comparison), so it can optimize page loading.

That doesn't have anything to do with security checks, or at least not much. I suppose you could think of using DOM as bloated, but it has many, many advantages for people who do development.

Re:This Is to MS's Clear Business Advantage...

[XO]

Well, I tried that, but Firefox crashes. all. the. time. Every click. Seg fault.

*shrug* Not worth my time to figure it out, I want a computer that works, and that's why I use Linux.

Re:This Is to MS's Clear Business Advantage...

[vinc17]

IE is probably bloated, even if users don't see it since code is shared with Windows, but the day microsoft would want to fix all these security bugs by making IE independent from Windows, this would probably be much clearer to the users.

And I agree that Mozilla is very memory hungry too. Under Linux, just after starting Mozilla (browser + calendar only, no mail/news module), my free (RAM + swap) memory decreases by 100 MB.

Re:This Is to MS's Clear Business Advantage...

[Minna Kirai]

I want a computer that works, and that's why I use Linux

I have to ask what distro you have. Firefox is one of the most popular Linux (desktop) applications, and I thought most Linux providers made it very easy to install correctly.

Re:This Is to MS's Clear Business Advantage...

[XO]

that was running it on a FC2 distribution, with the display set to my main system which runs Debian. (apt-get install firefox yielded nothing, and I really didn't have time to go searching)

OTOH, though, really how much less memory footprint does firefox have vs. mozilla? The various components that aren't included with firefox are mostly seperate executeables even with the full mozilla...

Re:This Is to MS's Clear Business Advantage...

[Valdar729]

What pages don't work with IE? I find that hard to believe since everyone will have tested their page in IE to make sure it displays correctly.

If you're talking about pages that are under development, well...they are still under development.

Re:This Is to MS's Clear Business Advantage...

[Minna Kirai]

(apt-get install firefox yielded nothing,

You need to either upgrade your debian, or learn keyword searching:
%apt-cache search firefox
gtkcookie - Editor for cookie files
latex-xft-fonts - Xft-compatible versions of some LaTeX fonts
libflash-mozplugin - GPL Flash (SWF) Library - Mozilla-compatible plugin
mozilla-firefox - lightweight web browser based on Mozilla
mozilla-firefox-dom-inspector - tool for inspecting the DOM of pages in Mozilla Firefox
mozilla-firefox-locale-ca - Mozilla Firefox Catalan language/region package
mozilla-firefox-locale-de - Mozilla Firefox German Language/Region Package
mozilla-firefox-locale-es - Mozilla Firefox Language/Region Package ...

OTOH, though, really how much less memory footprint does firefox have vs. mozilla?

For most users, the memory isn't as important as the less-complex renderpath for GUI decorations.

Re:This Is to MS's Clear Business Advantage...

[Reziac]

I had a similar problem with Mozilla 1.0 -- it crashed on EVERY page that included ANY javascript, and also when following ANY link from its bookmarks or from any file on my local disk. (It also leaked resources like nothing I'd ever seen, and was the ONLY app that *EVER* BSOD'd my good old Win95 box.) Which is why for a long time I reverted to Moz 0.99 as my "other" browser.

Moz 1.5 (currently my "other" browser -- normally I use NS3) doesn't crash much, but it's deadly slow on this poor old P3 with a lowly 1GB RAM.

Some of this is a side effect of development and testing being done almost entirely on Win2K/XP, where applications with nasty resource leaks are less of an issue (thus, as I've observed with MANY different newish programs, such leaks are no longer fixed).

Re:This Is to MS's Clear Business Advantage...

[Synistar]

Obviously you are not familiar with current web design practices. Any designer worth his salt will use CSS to improve their pages, not just "Linux advocates". Your conspiratorial tone and ignorance of the industry is what I was "blithering" about. Look here to see what I am talking about:

Why tables for layout is stupid

Re:This Is to MS's Clear Business Advantage...

[spectecjr]

LoL not counting all the ram used by windows itself where M$ keeps the large amount of the rendering engine. Just cause you hit ctrl-alt-del and saw 19mb next to iexplore.exe DOESN'T mean that IE os only using 19mb of ram. The LARGE majority of things that IE needs are preloaded by the OS.

Yes, it does mean that actually. The value you see in Task Manager is the Working Set Size of IE - that is, the total in-memory space of all DLLs and memory allocations currently in use by IE.

What IE ostensibly gets from being "preloaded" is faster loading times. Which are actually NOT the case - if you compile Mozilla from the Win32 source and let it run to completion, you'll find that they finally added support for rebasing and binding their DLLs. Which means that Mozilla loads at the same speed as IE if you turn off its splash screen with the /nosplash option.

If you want to argue this point, you can do other things - like use PerfMon or ProcExp (from Sysinternals.com) to look at the Working set size of the app. Which, by the way, is the same size as the value listed in Task Manager.

For your argument to have any teeth, Task Manager would have to be displaying the "Private Bytes" value - that is, the un-shared bytes used by the process - which it is not.

Please don't try to speak authoritatively regarding Windows when you plainly do not know what you are talking about.

Working Set Size - Private Bytes = amount of IE which is shared with other processes.

Note that Mozilla can gain similar benefits by using other DLLs used by the OS.

Re:This Is to MS's Clear Business Advantage...

[nmg196]

You're seeing what you want to see.

I'm not saying CSS is bad; I'm a web designer and I use it all the time! I'm just saying that pages with a non-realistic amount of CSS in them make IE feel rather slow compared to firefox.

Read my post before rambling on about something I'm already in agreement with you about!

Re:so?

[Dante Shamest]

I have never had a problem with my Firefox crashing (ever). But now thanks to this article, I can correct that. =)

Great

[Nehle]

When will it shine on working code?

Konqueror and bugs

[Anonymous Coward]

Konqueror has a neat bug symbol on the lower right corner when displaying buhhy html code.
I think this is a nice feature.
I wish that konqueror would have been tested. It's a good browser.

Let me get this straight...

[jav1231]

He starts sending bad data...data the program wasn't intended to read...it crashes...and this make them just as bad as IE? I tried to cat a binary once. My screen shat.

Re:Let me get this straight...

[AndroidCat]

Yes. If you can crash an app with bad data, it's usually not much further to find a buffer-overflow or such that will allow an exploit.

You have no control over what data a web site will send, so the browser has to be able to accept anything without exploits or crashing.

Re:Let me get this straight...

[lovebyte]

It's standard testing to send garbage input to a program to check its stability. It becomes compulsory when your program is likely to get garbage like a web browser which is guarenteed to access junk input from time to time.

Re:Let me get this straight...

[poptones]

I cat binaries all the time - not biggie. Did you cat it to stdout or to your browser or something? Choosing to do something bad on your desktop and causing a crash isn't nearly equatable to something that could allow Ivan's porn TGP to rootkit your machine simply by sending it a properly formed TEXT file.

Re:Let me get this straight...

[jav1231]

Point made. My point was largely tongue-in-cheek. :)

Re:Let me get this straight...

[Kupek]

Invalid input should still be handled sanely. Think of a compiler.

Re:Let me get this straight...

[Feanturi]

Yeah but a program shouldn't crash on bad data, it should figure out the data is bad and do something graceful about it.

All Other Browsers?

[polyp2000]

While I must admit that this is a great technique that can be employed by the various alternative browser vendors such as the firefox team to weed out problems. With its track record I find it rather dubious that the guy was unable to crash IE. Im willing to bet there are a couple of people here on Slashdot who know a few tricks that will crash IE with nothing more than a couple of lines of code. Which would enevitabley point to a flaw in his system. If anything at all this highlights IE's highly forgiving HTML parsing.

Re:All Other Browsers?

[nmg196]

> If anything at all this highlights IE's highly forgiving HTML parsing.

You say that like it's a bad thing. Would you rather see the web page you're trying to view, or have your browser crash?!

Re:All Other Browsers?

[TiggsPanther]

Well if IE also crashed on bad code then people who only ever use IE would be more likely to notice when their code is choppy.

IE is too highly forgiving. I was reading something where the author had used a row of &nbsp; to provide an indent. Only they'd missed off the trailing semicolon. IE rendered it fine. FF rendered it badly. As a result the author hadn't even noticed the error at all.

I doubt something that trivial would ever cause a Browser to bomb-out, but if it did then you'd get far less coding-mistakes getting though.

A browser really shouldn't be that forgiving. Otherwise how will people know when they have generated (or their software has...) malformed HTML?

The power of open source

[swinefc]

Larry Osterman is about to demonstrate one of the great values of open source. He's identified a set of malformed HTML and within a few days/weeks someone will have fixed it.

If this were a closed source / Microsoft browser, then there would have to be a complete release cycle before a non-security issue is resolved.

All software has defects, it is the access to the code that allows someone to rapidly fix issues that sets open source apart.

Re:The power of open source

[BenjyD]

Why? They're finding and fixing the bugs in Firefox already (check bugzilla).

Re:This is known

[Mr_Silver]

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?

You're confusing two seperate things here:

1. Broken HTML which doesn't render properly.
2. Broken HTML that causes corruptions, crashes and the potential for security issues.

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.

The reason for this is simple

[smartin]

Microsoft can afford a purify license.

Re:The reason for this is simple

[oever]

Try this:
valgrind
It's a Free Software purify alternative and works great!

All software has failure modes, question is...

[museumpeace]

...after it crashes does it hand the keys over to a malicious outsider or does it just stop working?
On my older [less mem, win2k] machine I could get Mozilla 1.5 throug 1.7 to hang by just visiting a lot of pages without using the BACK key. But the mozzie browsers don't have all those hooks into the OS that make backdoor control schemes possible. Mozzie failure modes would make for nuisance DOS, not subjigation of your system. If you accept the results claimed in the blog then its clear that MS did a better job of putting "containment" around their rendering context but the long list of vulnerabilities against IE also means MS has been too feature-happy or naive to avoid control hooks between the container and the OS.

Re:This is known

[metlin]

I know what he was talking about - my point was merely to highlight that IE has a robust renderer.

The renderer adequately makes up for errors in the HTML code, and consequently there are fewer crashes.

The same thing that helps it render bad code helps it withstand what he's just done. I merely said that there is a _downside_ to that capability, too.

Duh. Get it now?

Coding to Standards

[dapulli]

I like the idea that my browser (Firefox) may crash upon finding bad code that could be used to infiltrate my system. This is just another call for web monkeys to write standard html with the browsers to only parsing to said standards, therefore assigning things brought up by this study to history.

This also could be part of the intergration that Microsoft keeps harping on about. The error checking on the html is so good that it can only come from inside the OS*.

* Apologies if this is wrong, I know nothing about OS and Browser coding, and is based on wild speculation only

Re:Coding to Standards

[Jedi Alec]

I'd really prefer it to just refuse to parse the page mentioning that the code is bad instead of crash. As much as I like Firefox/Moz, when a piece of software is fed bad data, it should say so, not die on the spot, ever.

Re:Coding to Standards

[Seahawk]

Why are you reading slashdot then?

Slashdot would be unreadable if your browser did not accept fucked up html?

Not saying that I have a better solution - just pointing out that you're idea is not really a great idea! :)

Re:Coding to Standards

[Jedi Alec]

because if browsers consistently refused to parse Slashdot the coders would burn the carpet running to fix it. Anywayz, i never intented to say that it should completely ignore the entire page, if it can make something readable of it, i guess that's fine, after all this is just a browser we're talking about. however, i would greatly appreciate it if the browser a) does not attempt to parse bad code and b) notifies me of the fact that it has come across bad code it cannot parse, with the possibility of displaying that code to me and perhaps even a built in link that automatically generates a mail to admin@domain.com with the necessary info about the problem.

Let the insults fly...

[tomstdenis]

Assuming this MSFT guy is not lying...

Yes it's a slap in the face. But seriously this is what OSS is supposed to be about. Full public disclosure. If he did find scores of DoS related bugs then the OSS crowd [who like to show their names when the attention getting is good] ought to pay attention and fix the problems.

You can't gloat how open and progressive you are if you scowl and fight every possible negative bit of news.

And "mentioning how bad MSIE is" is not a way to make your product any better [just like "he's not bush" isn't a bonus for Kerry].

So shape up, take it in stride and get to the board.

Oh and while you're at it make Mozilla less bloatware. 30MB of tar.bz2 source could be your first problem....

Tom

Re:Let the insults fly...

[bbuR_bbuB]

First, I couldn't get the cgi to crash Firefox 0.10.1. I have a feeling this guy was testing crufty browsers, or something. Considering this tool said that "ALL" browsers except IE crash, it's obvious that it's FUD and not anything really serious. As an aside, Mozilla may have 30MB of compressed source, but you don't have to include all that source in your binary. It's pretty easy to snip stuff out of the Mozilla source. Remember phoenix, way back when? It can be done...

Re:Let the insults fly...

[tomstdenis]

My point is that being huge and largely unmaintainable [like gcc] makes it harder for other people to get involved. Granted GCC is rather complex Mozilla on the other hand is not.

Tom

Re:so?

[Lazy T]

I have crashed Firefox a few times. And no I didn't try to make it crash, it just did.
You can probably find someone who have crashed both and someone who have crashed neither. Without further information about the crash, feedback on what you have crashed and how many times you have crahed it is pretty much meaningless information.

Catch

[Quixote]

All browsers but Microsoft Internet Explorer kept crashing

Catch is, IE did not crash; the machine crashed. So, technically, it's not an IE crash... ;-)

Re:This is known

[metlin]

I know.

What I meant was this -

1. Broken HTML is corrected before rendering in IE
2. Therefore, Broken HTML cannot cause the same problems in IE

The fact that even bad code runs is what helps it handle his mangled code. However, the flipside is that this encourages bad code, which is what I meant to say.

Tested Konqueror

[unixmaster]

None of the samples in http://lcamtuf.coredump.cx/mangleme/gallery/ was able to crash Konqueror from KDE CVS Head. Heheh time to praise Khtml developers again!

Re:Tested Konqueror

[Anonymous Coward]

In the current version of Konqueror (3.3), I had quite a few crashes on the cgi version...

Re:Tested Konqueror

[Anonymous Coward]

http://lcamtuf.coredump.cx/mangleme/mangle.cgi

You're right, none of the samples work with Konqueror, however after doing a little testing myself with the above page it just took me about five tries to make it crash.

Bad luck? Maybe, but just try it yourself.

Re:Tested Konqueror

[Anonymous Coward]

My firefox managed to handle them all without incident too. Either the artical is out of date or we have a good case of FUD. Which reminds me I really need to update firefox from 0.9.3.

Re:Tested Konqueror

[Anonymous Coward]

Tested several (> 30) time. No crashes here!
Version 3.3

Re:Tested Konqueror

[Anonymous Coward]

The mozilla tests all worked for me with firefox-1.0-preview, so I doubt it's fud.

Re:Tested Konqueror

[BrianHursey]

Firefox 0.9.3 in Debian/GNU 3.0r Seamed to crash on mozilla_die1.html & mozilla_die2.html

The part of the malformed code that seamed to be throwing the error in mozilla_die1.html seams to be the

^@

in the

<INPUT^@AAAAAAAAAA>

On mozilla_die2.html just seams to be a buffer over flow.

<HTML>
<HEAD>
<MARQUEE>
<TABLE>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<TBODY>
Attack of the marquees!

All other tests ran fine including mozilla_die3.html in firefox 0.9.3.

Re:Tested Konqueror

[KjetilK]

Hehe. My Debian compiled one:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040917 Firefox/0.9.3

...did go down in flames....

But I know it will raise from the flames like a, uh, fox!

Re:Tested Konqueror

[WindBourne]

Odd, mine is running nice and stable and I have hit the above stuff as well as the .cgi that was linked. Works great.

Re:Tested Konqueror

[crazy blade]

Which version people?

I've loaded the above URL at least 50 times in Konqueror 3.3 (not even 3.3.1) with no crashes.

Re:Tested Konqueror

[WindBourne]

My konqi has done just great. I wonder how safari surivives it.

Re:Tested Konqueror

[Oestergaard]

I managed maybe 20-25 reloads before the crash, with Konq 3.3.

Re:Tested Konqueror

[alexborges]

Yeah, considering that most of the web doesnt render in it either, i think thats a great accomplishment.

It does come of better than links and lynx, but well, thats a surprise really.

Re:Tested Konqueror

[StormReaver]

I ran the script on my local Apache on a stock Mandrake 9.1.

Konqueror 3.1 crashes every time. Mozilla 1.3 crashes after a few refreshes.

On Windows XP (I don't have Firefox on Linux yet), Firefox 0.9.2 ran for about 10 minutes, stalling for a few seconds here and there, before freezing and eventually dying.

I.E. wouldn't run unattended, instead requiring me to constantly tell it I didn't want to debug the errors, so I couldn't test it as thoroughly.

Re:Conspiracy Theory time...

[Ann Elk]

RTFA. Larry didn't find the broken HTML, he just referenced an article which did.

I've seen that before

[hwestiii]

I saw something like this (not quite, but similar) a few years ago working with Java Script.

I wasn't that experienced with it, and as a result, certain pieces of my code were syntactically incorrect. Specifically, I was using the wrong characters for array indexing; I think I was using "()" instead of "[]". I would never have known there was even a problem if I hadn't been doing side by side testing with IE and Mozilla. A page that rendered correctly in IE would always show errors in Mozilla. This made absolutely no sense to me.

It wasn't until I viewed the source generated by each browser that I discovered the problem. IE was dynamically rewriting my JavaScript, replacing the incorrect delimiters with the correct ones, whereas Mozilla was simply taking my buggy code at face value.

Re:I've seen that before

[Zarf]

I think I was using "()" instead of "[]".

MSIE was embracing and extending your new syntax. They were effectively defining their own JavaScript variant. Meaning their JavaScript was a SuperSet of the real JavaScript standard. That means you can more easily fall into the trap of writing MSIE only JavaScript and inadverdently force your clients/customers/company to adopt MSIE as your standard browser.

Re:I've seen that before

[ronobot]

Since you've brought up JavaScript, there's something I'd like to note:

When IE encounters an infinite loop, it starts devouring the CPU and can only be shut down through the Task Manager. On the other hand, Mozilla (and Opera, if I recall correctly) will, after a few seconds, detect that it's an infinite loop and bring up an alert box giving you the option of shutting the script off without shutting down the browser.

Re:I've seen that before

[colinramsay]

That's strange, because that very thing happened to me this morning and after about ten seconds of unresponsive behaviour, IE6 popped up a little box asking if I wanted to stop the script.

Re:I've seen that before

[julesh]

Microsoft's is called JScript, not Javascript.

So that'll be why it calls it when I use a url of the form "javascript:[code]", or a tag like "<script language=javascript>" then?

MS's software all internally understands that this language is called Javascript. It's only MS marketing that decided to use a different name for it.

Re:I've seen that before

[GeckoX]

That is because that's not an infinite loop.
try:

while(true)
{
...
}

Re:I've seen that before

[julesh]

MSIE was embracing and extending your new syntax.

Yep. Another example, that I've now seen several sites falling over with, is that MS's Javascript implementation will accept statements with no terminating ';' in many situations that no other implementation will.

Re:I've seen that before

[MikeBabcock]

... not at all like how they define a TRY macro to use instead of try for C++ (although they both work). Or how they define new classes to do things the standard template library does very well. Not at all :)

Re:I've seen that before

[Chris Burke]

This is completely orthogonal to the points brought up in this thread, but if you're talking about MFC (Microsoft Foundation Classes) then it's not a big deal... The STL didn't exist when that was written, and in fact just about every vendor had their own set of classes to do all the basic stuff like containers.

Re:I've seen that before

[jesterzog]

The company that I used to work at fell into this trap completely, specifically because nearly all of the MSDN example code at the time was written using the MSIE-specific "()". MSDN is both a great resource that's more convenient than much of what's out there, and a horrible cesspool of mis-information, depending on the setting.

Eventually, during a week when there was less work for me to do, I managed to convince my co-workers to let me go through and standardise it properly. Until then, even the possibility of supporting another browser had been unimaginable because there were silly problems like round brackets throughout the code that made an overhaul seem tremendous. And as time went on it became even worse.

There was really no advantage to anyone but Microsoft for the MSDN example code to use this syntax. It didn't gain anything or add anything to the code quality or usefulness. All it did was to lock companies in to supporting nothing but MSIE.

Re:I've seen that before

[Reziac]

One of the odd things I've seen involving javascript:

As my everyday browser I use Netscape 3.04 (yes, really!) with images and javascript *disabled*.

Nonetheless, a very few pages' JAVASCRIPT would crash it. (Vonda McIntyre's former main page, for one.) The HTML part, minus the script, worked fine.

I'm wondering if NS is doing with JS (while disabled) like DOS did with comments: parse the comment, then go back to the beginning of the line and go OOOPs, that was a comment, not supposed to do that! (this is why you don't put pipe and angle-bracket characters in comment lines in DOS batch files -- they're parsed and executed *before* DOS goes back to the beginning of the line and processes the comment flag.)

Re:I've seen that before

[julesh]

Practically, of course, this depends on the browsers you're targetting. According to Microsoft's reference, for instance, the only strings supported by Internet Explorer are "JScript", "javascript", "vbs", "vbscript", and "XML". Seems they've never heard of the HTML 4 recommendation. ;)

You don't get it

[Interfacer]

1.) a browser should defiitly not crash when it is fed malformed html.
2.) crashes due to buffer overflow ARE security issues, since they allow you to insert malicious code.

if it was IE that crashed and not mozz, i bet you would have shouted that microsoft made crappy software.

now i am waiting for you to shout that mozilla is crappy software...

(crow disperses, mumbling that that is something totally different.)

Re:What about VALID html?

[tomstdenis]

This isn' insightful at all. First, you'll be the first person to bitch when a mozilla virus comes out.

Second, "crashing when invalid" as you and many others are alluding to is NOT a good idea. What if you had another tab open with email/urls/info you needed?

What if other software took this route? Invalid operands to open()? Time to crash. Invalid socket used in send()? Time to crash. Segfault in application? Kill the kernel processes!

It's a problem, it has to be fixed and there aren't two ways about it.

Tom

Reality Distortion Fields ON!

[Zarf]

The same person tells us that Apache sucks when compared with IIS. Does this mean we've all been wrong about Microsoft products? If we take Microsofts word for it we have indeed and should seriously consider switching back to IIS. After all, [THE FOLLOWING IS SARCASM:] this conclusively proves that IIS is far superior to the Linux Apache Mysql Perl/Python/Php system.

Re:Reality Distortion Fields ON!

[eqdar]

Of course, this all thing has *nothing* to do with the recent advices to switch to a different browser for security reasons published on CERT http://www.kb.cert.org/vuls/id/713878.

Couldn't this be Microsoft's answer ? "Just find anything we can communicate about -- and if our product is bad, our concurrents are even worse"... to me, it seems like yes, The Browser Wars are back

I agree that this is not a correct behaviour for any app to crash due to bad input, but at least Mozilla et al. are *apps*, not part of the system ! If Mozilla crashes, I just relaunch it, while IE crashing might bring the entire system down.

I think we should keep this in mind ; an app not properly handling error condition is not the only serious security problem around.

Re:Reality Distortion Fields ON!

[Alomex]

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.

Re:Reality Distortion Fields ON!

[Anonymous Coward]

> Reality Distortion Fields ON!

What the hell are you trolling about? It's a _FACT_ that mozilla and the other browsers crash on the HTML code he provided, regardless of what his opinions on Apache and ASP.NET are.

Re:Reality Distortion Fields ON!

[runderwo]

When's the last time a Linux distribution had a remote root vulnerability? Does Linux get immediately infected with viruses when attaching it to the internet to download updates?

Re:Reality Distortion Fields ON!

[Alomex]

A quick sample from a google search for "linux vulnerability root":

Vulnerabilities have been identified in "unzip" and GNU "tar" Commands.... DAMAGE: A local unprivileged user may be able to gain unauthorized root access and/or overwrite any file on the system.

or

EXtremail is a free pop3/smtp mail server for Unix. EXtremail versions 1.1.3 through 1.1.9 for Linux are vulnerable to a format string attack, caused by user-supplied input for a fprintf()statement in the flog() function. A remote attacker can supply specially-crafted strings to certain commands to gain root privileges on the system.

Here are some KDE related ones

KTVision version 0.1.1 in some Linux distributions could allow a local attacker to launch a symlink attack. KTVision creates temporary files with predictable file names. A local attacker could use this vulnerability to create a symbolic link in KTVision to gain root privileges. By default, KTVision is installed setuid root

and

The K Desktop Environment (KDE) provides an integrated graphical desktop environment for UNIX workstations. As a part of this environment, it supplies its own PPP implementation (kppp) and its own screen locking environment (klock), both of which are installed setuid root. Both of these programs have numerous security vulnerabilities which can expose the computer to a root compromise by a local user.

I could go on an on....

Re:Reality Distortion Fields ON!

[|<amikaze]

Local root vulnerabilities, while bad, are still not AS bad as remote root vulnerabilities. When you can spam a few packets at a machine and be given back a root shell, that's when you have serious issues.

Re:Reality Distortion Fields ON!

[The Bungi]

while IE crashing might bring the entire system down.

Um, no. Not on an NT system, at least.

Re:Reality Distortion Fields ON!

[Alomex]

and you really think linux has none of those either? ever heard of sendmail? or the bugs discovered in open/ssh? or apache?

Re:Reality Distortion Fields ON!

[eqdar]

You may be right ; after all, I haven't even *touched* a Windows machine for a couple of years, and it was running Windows 95 -- I know Windows has a different (NT) arch since 2000 Pro, but knowing and understanding are different things...

I guess I'll be wiser tonight ;-)

Re:Reality Distortion Fields ON!

[runderwo]

Can you fucking read? I said remote root vulnerability. Is your best argument an obscure mailer that isn't in the default install of any known distribution?

Re:Reality Distortion Fields ON!

[Alomex]

You don't get it. They are both buggy. That is why you have to split hairs about vulnerabilities... Plus read my other posting on this thread about sendmail and apache, if you want to talk about "obscure" software bugs that can be remotely exploited.

But hey, don't let the facts get on the way of your prejudices.

Re:Reality Distortion Fields ON!

[runderwo]

You don't get it. They are both buggy. That is why you have to split hairs about vulnerabilities...

Are you aware that not all bugs are equivalent in damage potential? The very fact that you list local rooters on the same scale as remote rooters betrays a large amount of ignorance.

Plus read my other posting on this thread about sendmail

Sendmail doesn't have anything to do with Linux, except that some Linux distributions ship it. So rag on those distributions. Sendmail is a joke and people have known this for at least 20 years.

and apache

Anyone who runs apache as root has no idea what they are doing. You have to use at least two exploits to gain control of a system through Apache, as it is installed under a non-root uid in every distribution I know of.

But hey, don't let the facts get on the way of your prejudices.

Oh, I get it, you're one of those "fair and balanced" people for whom there is no right answer to anything. Any preference one way or the other is automatically considered to be prejudice or religion. Give me a break. Some designs are sane, and others are not. Microsoft started out with NT as the Not-Unix, and slowly is re-learning every lesson Unix had already had to deal with.

Re:Reality Distortion Fields ON!

[spectecjr]

The same person tells us that Apache sucks when compared with IIS.

No, Larry Osterman did not tell you that.

Larry Osterman didn't even tell you that IE wins compares to the mass suckitude of other browsers such as Mozilla or Opera when fed malformed HTML.

Specifically, Michael Howard wrote the blog article about Apache vs. IIS

The person who wrote the article about IE being much better - in terms of NOT crashing - than other browsers is Michal Zalewski, who doesn't even work at Microsoft.

But hey, if you want to claim that Microsoft are the people making all this stuff up, and jump up and down, then go ahead. But please, don't be surprised if when people point out that it's not Microsoft doing it, you look like a fool.

Re:Reality Distortion Fields ON!

[Zarf]

Some people are biased. Their views of reality are distorted.

Re:Reality Distortion Fields ON!

[Zarf]

What's going on here is a presentation of facts in a distorted fashion. It is like asking:

Do you support the war in Iraq?
versus
Do you support keeping America safe by going to war in Iraq?
or
Do you support our Troops in Iraq or Terrorists?


By adding a bias into the question answering that you don't support the war in Iraq you are now implying that not supporting the war in Iraq is akin to supporting Terrorists, hating America, or hating our Troops.

While it's not as easy to see in matters like this. The blog in the article is biased. I establish this trend (albeit thinly) by pointing to the earlier postings showing only two flaws in IIS to an uncountable number of flaws in Apache. Then the blogger says, "it goes to show that maybe we really DO understand what we're doing." implying that IIS gets a bad rap, if you look at the numbers it's actually better than Apache.

That is bias. The MSIE superiority at handling "generous" inputs is not a feature... it is a positive side-effect of their "embrace and extend" philosophy. While it is indeed a horrible indictment of Mozilla et al. that they can't handle this simple malformed code... it is no great advantage to MSIE as a browser.

Here's an example of taking facts and over-blowing what they mean:

Reference: http://www.cia.gov/cia/publications/factbook/ranko rder/2129rank.html http://www.cia.gov/cia/publications/factbook/ranko rder/2186rank.html

Using the facts here I'll build the following erroneous argument. The US should model its economy on Uzbekistan's because Uzbekistan has one of the world's lowest unemployment rates.

It is a fact stone, cold, fact that Uzbekistan has nearly no unemployment. It is a stone cold fact that Uzbekistan has nearly public debt. These are elements of great discord in America today.

America has problems with things that Uzbekistan seems to find easy to deal with. Barely any debt or unemployment Uzbekistan must be a paradise to live in. America should be more like Uzbekistan.

But wait. You're not looking at all the facts now are you?

It may be harder to understand these distortions of reality when thinking about computer related things. But, they're there. The plain fact is that perhaps somethings are indeed better about Uzbekistan... but somethings are definately much, much, worse.

I would say the same analogies hold true for MSIE versus Mozilla and Apache versus IIS.

Re:Reality Distortion Fields ON!

[Zarf]

is it the same kind of severity when a mail server from gets "muled" as when a client Email reader leaks private information all over the web? When was the last time a sendmail bug sent people's private files and private information all over the net? OSS bugs aren't even in the same class as MS bugs in this instance.

Is it more severe to hurt a server (but not get out any data) or hurt a client and spill personal data everywhere?

Re:Reality Distortion Fields ON!

[spectecjr]

Some people are biased. Their views of reality are distorted.

But enough about you.

You're the one who was claiming that Microsoft employee Larry Osterman was the one who invented the Apache vs. IIS stats, and the IE vs. other browsers error stats.

He's not.

You were wrong.

Just be an adult and face up to it.

Re:Reality Distortion Fields ON!

[Zarf]

You're the one who was claiming that Microsoft employee Larry Osterman was the one who invented the Apache vs. IIS stats, and the IE vs. other browsers error stats.

I didn't mean to insinuate he invented the stats. I did mean to insinuate that the stats are biased. And yes, I know I'm biased. That's why my Reality Distortion field is up!

You however are just a big jerk. Wah! I want my mommy! Who thought people on slashdot could be so cruel?

Oh, and by the way... you are biased too...

Re:Reality Distortion Fields ON!

[runderwo]

I was waiting for someone else to correct that ludicrous assertion. Thanks!

Well, I found one ...

[digitalgimpus]

way back when
https://bugzilla.mozilla.org/show_bug.cgi?id =18827 8

(have to copy/paste that url since bugzilla blocks slashdot refer's)

The Reason why IE is still the most used browser

[dJOEK]

You don't need to know html to write pages for it ;-)

MSIE was through this already.

[Vo0k]

MSIE passed that problem already. They had that famous bug of which was an invalid NULL pointer. It seems instead of fixing this single bug, they gave a good overhaul to the whole code, fixing all vulnerable places and getting MSIE to swallow any malformed tags.
From what I've seen on Bugzilla, I haven't seen Mozilla to have any similar problems. Malformed tags cause misrendering, break pages etc but don't crash it. Or at least, didn't until now. It's just time for Mozilla people to do to Mozilla exactly what Microsoft people did to MSIE.

(about Opera, I'm not surprised. The shortcuts they've taken in DOM to make it "the fastest browser" are more than dangerous...)

Re:MSIE was through this already.

[Vo0k]

err, reason of which was invalid NULL pointer.
The bug was based on "<form action crash>" tag.

Re:MSIE was through this already.

[XO]

I've been using Opera for months , due to an older slower system (P2/600, 128M ram) .. aside from being unable to use plugins (except for Java, which I can't get working in any incarnation of Mozilla, and haven't since the very first releases of Mozilla), and it specifically not rendering most anything that does a browser detect even with the fake IE or fake Mozilla settings on, it's been flawless for me.

Opera is fast, and very memory friendly, compared to all the others.

Re:MSIE was through this already.

[Vo0k]

Sorry, maybe that's your impression as a user. For me, as a webmaster, making cross-browser pages that flawlessly run in Opera is hell. The standard stuff is okay, but try anything beyond... Just recently all browsers took the style sheet "z-index" correctly, overlaying the row of buttons over an image map. Only Opera pushed them behind the image. Earlier I've been trying some pull-down menus. Move the mouse over the menu, an invisible DIV with contents becomes visible. Unfortunately Opera's shortcuts caused that only the DIV becomes visible, its contents not.

Re:MSIE was through this already.

[XO]

Well, one of the really nice things is that Opera is fairly responsive to code that can be demonstrated to show that they are not rendering correctly, as well.

I've had two instances with my own pages, where things did not render correctly.. one, the bug was fixed in the next Opera update, and the other one, they emailed me back and pointed out that I was using something in a way that pretty much only worked in IE.

I would love to see code that causes Opera to fail, the more it gets fixed, the better I feel.

(I did recently submit all of www.ifilm.com as something that doesn't work)

Re:MSIE was through this already.

[Vo0k]

Code sent. (I hope the email you've given here is valid).
I'm not opera-hostile, it's an okay browser. I'd like to see it getting better and better too... Sure I won't exchange my Mozilla to some proprietary stuff, but hey! It's not Microsoft! They can't be all bad!

Re:MSIE was through this already.

[XO]

the address is good, though a lot of email servers will refuse to send to it, since it is a dynamic host. *shrug*

if not, ekdikeo4@yahoo.com works too..

Re:MSIE was through this already.

[XO]

ok, I received! I also replied, but I will post that here in case your mail reader filters me out as spam:

I think I've found the answer to your problem here:

http://www.w3schools.com/css/pr_pos_z-index.asp

It says:

The z-index property sets the stack order of an element. An element with greater stack order is always in front of another element with lower stack order.

Note: Elements can have negative stack orders.

Note: Z-index only works on elements that have been positioned (eg position:absolute;)!

Here is a page with a Z-Index test:
http://www.hixie.ch/tests/adhoc/css/box/abs olute/z -index/006.html

which Opera 7 handles flawlessly.

And the following page:
http://www.brainjar.com/css/positioning/def ault5.a sp

Which details that Opera has had functioning (although buggy) Z-Index support since v5, and support for fixed positioning that IE still doesn't have working right. :-) ..

Re:MSIE was through this already.

[Vo0k]

Yes - Opera handles THAT test flawlessly. Maybe Opera authors took w3schools text too literally - "(eg position:absolute;)!}" - w3.org says only "positioned" and that means "absolute", "fixed" and "relative" - only "static" is not. The case is simple - if all elements are "static", they never overlap, Z-index is completely redundant. You need to move the element in X and Y before moving it in Z starts to make sense.

Re:MSIE was through this already.

[XO]

I did send a description of what was happening in the code, and such, to the Opera devs, though I don't think I've received a reply yet (they usually take a few days) .. I didn't totally thoroughly look through the code, but most references indicate that z-index only supports absolutely positioned elements, which may have been changed possibly for CSS2.1 ? in which case the 2nd link below may explain the problem in more detail.. apparently setting "fixed" or "relative" doesn't automatically force a stacking order to be created.. is my basic understanding of it. perhaps more forthcoming, as more information is brought in to make it more muddy and confusing? ;)

From htmldog.com:

CSS Property: z-index
Specifies the order of absolutely positioned boxes in the z-axis. The higher the number, the higher that box will be in the stack.

http://weblogs.mozillazine.org/hyatt/archives/20 04 _09.html#006469

explains that IE is in fact, incorrect on z-index in some cases

Re:MSIE was through this already.

[Vo0k]

I think the problem may be rather related to VERY obscure concept of z-index "local context". As I analysed this in an older version of Moz, it looked something like this:

[div1]
[div2 z-index=1]
[div3 z-index=4]
AAAAAAA
[/div3]
[div4] z-index=2]
BBBBBBBBBB
[/div4]
[div5 z-index=2]
[div6 z-index=2]
CC
[/div6]
[div7 z-index=0]
DDDD
[/div7]
[/div5]
[/div1]

where the result would be:
CCDDAAAABBBB

The trick is since z-index of div5 is higher than z-index of div2, everything in div5 is above everything in div2 - in context of div1. And only after this has been sorted out, relations div3-div4 and div6-div7 are resolved, each within their own separate context of div2 and div5...
This used to be the case. Now... I don't know.

Re:MSIE was through this already.

[XO]

the whole thing seems rather difficult to implement properly, both in the browser, and in the web code, if you ask me.. I haven't noticed any replies back from Opera on it, but will keep posted...

To crash or not to crash

[MadFarmAnimalz]

His only criterion is whether the browser crashes or not. Somehow, it disturbs me more that IE doesn't crash; what precisely is the effect of the bad code then?

I agree that these are all potential security holes, yet the article author mistakenly correlates crashing with vulnerability.

What if IE is similarly vulnerable yet simply doesn't crash?

From that point of view, at least crashing is an indication that sometihng is not right.

All the same, I consider it a good beginning.

Re:To crash or not to crash

[julesh]

His only criterion is whether the browser crashes or not. Somehow, it disturbs me more that IE doesn't crash; what precisely is the effect of the bad code then?

I suspect it detects the error and does what any web browser ought to do on detecting malformed markup: ignore it.

Re:To crash or not to crash

[morzel]

Hint: if you feed random data to a buffer overflow, the application will most likekly crash, unless that data contains valid executable code that manages to do something bad and magically resume execution.

If IE does not crash, it means that either:

• The random number generator managed to crank out an exploit all by its own
• IE parsing engine does proper checking on the HTML and recovers gracefully from any baddies in the data

An application should never crash when fed bad data: it should deal with it gracefully, even if that means showing an error message and closing the application, not just trying to execute whatever the garbage may contain (which firefox seems to be doing).

I don't see why everybody is whining about how unsecure IE is, and that Firefox et al. are better. This test raises a valid concern: if you succeed in crashing Firefox by feeding it malformed HTML, chances are that you can exploit that vulnerability. This is a bad thing and warrants attention from the the Mozilla team.

few bugs or many bugs?

[mr_walrus]

so, did he REALLY find many bugs, or did he find just a couple bugs that
manifest themselves with many variations of html that really are doing
essentially the same thing?

Ahh...

[Atrophis]

So IE is better at handling junk.

Nothing new here...

strategic point of view

[ragnar]

I may be a little paranoid (heck, I actually am) but I've long suspected the IE support for loose HTML was a strategic decision. Go back to the days when Netscape would render a page with a unclosed table tag as blank. IE rendered the page, and I often encountered sites that didn't work on Netscape.

It could be a coincidence, but the loose HTML support of IE led to a situation where some webmasters conclude that Netscape had poor HTML support. You can argue about standards all day long, but if one browser renders and another crashes or comes up blank there isn't much of a contest.

Re:strategic point of view

[shyster]

may be a little paranoid (heck, I actually am) but I've long suspected the IE support for loose HTML was a strategic decision. Go back to the days when Netscape would render a page with a unclosed table tag as blank. IE rendered the page, and I often encountered sites that didn't work on Netscape.

Microsoft has always leaned towards maintaining backwards compatibility. If a site worked in IE 1.0, then it should work in IE 6.0. They work very hard at ensuring this. Of course, that leads to some inefficient code, continuing mistakes made in the past, and nobody ever fixing their HTML. But, it keeps the new version of IE from looking like it's breaking websites.

With XPSP2, MS has decided to let security trump compatibility. IMHO, this is a Good Thing(tm). And, with IE6's strict doctype declaration, bad HTML can be found and fixed by the developer. Of course, only those developers who care about such things will take the time to do this...so it may be moot.

Re:strategic point of view

[strider44]

Of course it is, as is the shying away from the HTML standard - it's all strategic. I have a feeling that if they lose to Firefox then they're going to have a harder time taking back than when they were losing against Netscape though.

Re:strategic point of view

[drfuchs]

Netscape made the first widely-used browser. Netscape's browser accepted non-conforming HTML all over the place (perhaps because many HTML files were hand-crafted).

IE came later. IE was forced to maintain compatability with all the non-conforming stuff that Netscape introduced; otherwise, the user-experience was "NS works; IE doesn't". And, having worked at the time on yet a different browser, let me tell you that it was a huge pain to try to even figure out the exact language that Netscape accepted, and what the exact semantics of all the non-conforming HTML that it accepted were. I don't know how IE managed to get so much of it to match. (It's hard enough to write to a spec; but when you've also got a, well, white box that you're trying to match the behavior of, good luck).

So, all this business about how it's all a MS plot may be fun to claim, but it doesn't match up with the reality of history. (OK, ok, this is not to say that once IE gained the lion's share of the market that they didn't pull the sort of trick being suggested; but they sure weren't first.) The world would be a much better place today if Netscape had been rigid in the language it accepted; by the time IE came on the scene, it just didn't have the option to enforce strictly-conforming HTML.

Re:strategic point of view

[danila]

You don't need to be paranoid. Even if there was no evil plan, rendering broken HTML correctly is a trait that benefits the survival of the browser. Just as rendering standard code is a beneficial trait for HTML-authoring tool.

Mozilla, Opera, Safari and the rest are simply less suited in this respect. They can argue as much as they want about their adherence to standards, but in the end they must learn to display malformed HTML/CSS/JS correctly or fail miserably (because some pages will only work in IE).

Re:strategic point of view

[DunbarTheInept]

IE didn't just match Netscape's overly tolerant HTML parsing and stop. They did the same thing back, and the two duked it out. They are both responsible.

Re:strategic point of view

[the pickle]

rendering broken HTML correctly

What the hell is "correct?" How do you decide?

"Broken" HTML is, by definition, not compliant with the standard by which HTML is defined. It isn't HTML. It's something resembling HTML, but it isn't HTML. I can't write a parser that "properly" interprets pseudo-HTML for the same reason I can't write a compiler that compiles pseudo-C. If the format of the document is wrong, don't expect the rendering agent (the browser, in this case) to do anything approaching a "standard" with it.

No matter what Microsoft people to think, "malformed HTML/CSS/JS" is not really HTML/CSS/JS. It is something closely akin to these, but it is not these. The sooner people understand that, the better.

p

Re:strategic point of view

[Tim Browse]

IE 1.0? Not sure about that. I remember installing NT4 (original edition CD) on a PC once, and using IE3 (I think) to go to the MS web site to get some updates. The site plain didn't work in that default OS browser - had to use another machine to download the patches so I could get IE4 or 5, etc, and actually access the MS website in a sane way.

Re:strategic point of view

[shyster]

Yeah, I don't recall IE 1.0 either. But, you missed the point. The point isn't that MS codes HTML to be backwards campatible, but that they code IE to be backwards compatible. Meaning if a site displays properly in IE 1.0 (or 3), it should display the same in IE 6.

Re:strategic point of view

[Reziac]

I think there was another explanation: Back in those days, Frontpage had a bug where if you were editing text inside a table in WYSIWYG mode, and happened to backspace too far, it would delete not only the text but ALSO the table tag, with a very common result of unclosed table structures. It would also mis-nest attributes when stuff was cut and pasted.

I suspect IE was tested primarily against code as *commonly produced by average Frontpage users*, and "taught" to ignore FP's more-common errors (primarily random unclosed tags and mis-nested attributes).

BTW, this bug was finally fixed as of FP2000.

Re:strategic point of view

[danila]

What the hell is "correct?" How do you decide?

If you allow me to continue the natural selection analogy, "correct" is anything that makes a user more likely to continue using the browser and make others use it.

People will not necessarily understand that broken HTML is not HTML. Microsoft, the most powerful player on the browser market, is not interested in people learning it and the very existence of IE prevents it. And when you say better, you must use the game theory and aks "better for whom?".

Re:This is known

[ClosedSource]

There's a difference between posting an error message and crashing. So I don't think there's any upside for the other browsers on this issue.

As for allowing sloppy HTML, that's a problem if you think the primary purpose of a browser is to enforce HTML standards rather than display web pages.

uhm...

[embeejay]

I just tested his CGI using FireFox 1.0PR. I reloaded it 50 times, and the browser never crashed.

Maybe his testing skills aren't that up to date? (From viewing the source, it is obvious that his html skills are lacking) ;)

Here's the bad code

[Araneas]

No real surprises here.

links_die1.html

<HTML>
<TABLE>
<TR>< TD ROWSPAN=2000000000>

lynx_die1.html

<FORM><TE XTAREA COLS=10000000000>
<KKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
KKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKK
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
KKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKK
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKK

mozilla_die1.html
n.b. - truncated at first binary 0
<HTML><INPUT

mozilla_die2.html

<HTML>
<H EAD>
<MARQUEE>
<TABLE>
<MARQU EE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<MARQUEE HEIGHT=100000000>
<TBODY>
Attack of the marquees! (sic)

opera_die1.html

<HTML>
<TBODY>
<C OL SPAN=999999999>

Re:Here's the bad code

[Araneas]

Excuse me but where exactly did I say in this particular post that I hated MS?

Look at the code. It is no surprise such malformed code would cause problems. It's pretty obvious we're dealing with some extreme edge cases like multiple one hundred million height Marquee tags. I am concerned that a recent version of any browser would choke on this code.

Re:This is known

[StrawberryFrog]

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.

Re:This is known

[BrianHursey]

Yes this is one thing that I have disliked about IE over the years people write their sites for IE instead of following standards placed bu W3C (World Wide Web Consortium) So because people have been ignoring standards so has IE. That is why IE is years behind when it comes to standards support.

This troubled me when I took web mastery in college and saw every one writing their sites for IE and no one testing for standards. I confronted my teacher about it. Explained my case and he gave us 10% extra credit if we made all of our sites for the semester standards complaint.

My point is a browser that runs bad HTML code implies bad programing methods.

A clue about the browser development process?

[constantnormal]

One wonders whether this indicates an emphasis on a "test case" driven development process, as opposed to a "functional spec" driven process. Certainly there must be a design rule that says "never crash, assume something and drive on".

Upon reflection, I don't recall ever seeing an error message from ANY browser telling me that a particular web page it is attempting to parse is fubar'd beyond hope, they all just drive on as best they can.

This is particularly highlighted in XHTML pages, where there is an abundance of structural features (strict closing of tag sets, for one) that enable detection of broken code. I don't recall (disclaimer for failing memory) ever seeing a message indicating that the page's code was broken, browsers just muddle through, producing erroneous displays and hoping the result is "good enough".

Perhaps if the browsers reported web page syntax errors -- something blunt (but not crude), like "the web page you are attempting to display is broken and is not properly displayed" in a large translucent block font over the rendered result -- the web would be a more syntactically correct place.

It would have to be something simple enough that Joe User wouldn't reformat his hard drive and reinstall the system upon seeing it, and blunt enough to motivate web content producers to make better code.

Re:A clue about the browser development process?

[hankwang]

Perhaps if the browsers reported web page syntax errors -- something blunt (but not crude), like "the web page you are attempting to display is broken and is not properly displayed" in a large translucent block font over the rendered result -- the web would be a more syntactically correct place.

1. It means you'll need to build in a strict parser and a normal parser into an agent. For example,

<img src=foo/bar-1.jpg alt="barbar">

is formally illegal since the '-' is not allowed outside quotes. I doubt that there is any browser that uses such strict rules for parsing. And if the browser has to parse everything twice, it will generate extra bloat.

2. It might be easy to set a flag in the parsing code whenever a "workaround procedure" is called, in order to get the warning message. However, the next thing your users will demand is an explanation about what is wrong. It isn't easy to generate human-readible error messages from a parser. The W3C validator often generates very cryptic messages. The above example will generate the message "required attribute "ALT" not specified". Go tell.

By the way, Opera has a hotkey, ctrl-alt-v, to submit a page to the W3C validator.

The difference between IE & Firefox

[t_allardyce]

Firefox has fast developement, they'll fix this in a month, meanwhile the IE css box model has been broken for the last 5 years, and they still don't have a pop-up blocker built in. I've noticed a few Firefox crashes that sound like this so hopefully its gonna be fixed very soon. I might sound biased against Microsoft, but actually i've been learning C# and loving it! Microsoft are hardcore, they just concentrate on business more than software sometimes, and as a budding young student, close to graduation with plenty of debt whos just totally sold-out i can respect that.

end-table tags...

[orion41us]

Once had a script that renderd a bunch of large tables (It was a report) - Had the end-table in the wrong spot that made the page look like it had 1000's of nested tables... IE when rendering the page would eat up TONS of RAM and eventualy ither crash or lock up the system......

You just never know..

His examples do not really crash Firefox

[SmilingBoy]

The author gave some examples that are supposed to crash Mozilla, Opera, Links and Lynx at the following URL:

http://lcamtuf.coredump.cx/mangleme/gallery/

I opened all the pages in tabs in Firefox 0.10.1 under Windows 2000, and Firefox did not crash. It became somewhat unresponsive, but I could still select other tabs, minimise and maximise. I could not load new pages anymore.

Can someone else test this as well, please?

And can someone tell us whether this has security implications or not?

Re:His examples do not really crash Firefox

[XO]

i find it fun that lots of people are putting firefox through all these tests and not having problems.. whereas, no matter what I do in Firefox, it crashes.

every single click to load another page. Boom! Seg fault!

Re:His examples do not really crash Firefox

[l3v1]

So at least your ignorance isn't contagious. Fortunately.

Re:His examples do not really crash Firefox

[TakaIta]

I run Windows 2000 and Firefox 0.10.1 and Firefox crashes on mozilla_die 1 and 2, but not on 3.

Re:His examples do not really crash Firefox

[noselasd]

Tested on WinXP SP2, firefox crashes.

Re:His examples do not really crash Firefox

[Anonymous Coward]

Not to mention the horribly annoying bug that hasn't been fixed since 0.8 that renders Slashdot (HTML 3.2?) incorrectly. You'd think they'd want to fix that bug since a lot of their users read Slashdot.

Re:His examples do not really crash Firefox

[kryptkpr]

The fix for that bug is non-trivial, and breaks many other sites. A quick Ctrl + +/Ctrl + - is a good workaround.

Re:His examples do not really crash Firefox

[rishistar]

Getting nothing happening when I try this in Opera - I don't know if this is my Opera not doing anything (but it still doesn't crash) or if /. has broken the site. Revenge is sweet!!!!

Re:His examples do not really crash Firefox

[SmilingBoy]

Weird! I checked this in detail again. It seems that there is a difference whether other Firefox Windows with several tabs are open or not. If I have other open windows and tabs (like I normally have when surfing around), mozilla_die1 just slows down the computer, but you can actually close the tab again and you are back to normal. mozilla_die2 also slows down the computer, you can select other tabs, but you can't close the offending tab or load new pages in other tabs.

If I only open mozilla_die 1 or 2 in a single tab in a single window and no other tabs are open, Firefox crashes immediately.

mozilla_die3 never crashes Firefox.

Re:His examples do not really crash Firefox

[NeoSkandranon]

havea lnk to the bugzilla entry? I didn't know that was an actual bug (rather thought it was lousy HTML coding on /.'s part)

Re:His examples do not really crash Firefox

[kryptkpr]

https://bugzilla.mozilla.org/show_bug.cgi?id=21752 7

(copy and paste, bugzilla doesn't allow /. links)

Re:His examples do not really crash Firefox

[NeoSkandranon]

Ah..not the bug I was thinking about. The one I see is where the middle column (aka where the story and comments sit) is HUGE wide, and all the text is over off screen to the right

Re:His examples do not really crash Firefox

[Lisandro]

Opera 7.54 (linux) dies when opening opera_die1.html

I found it funny he didn't include the shitload of perfectly valid HTML code that's known to crash IE; but still, he has a point. A browser shouldn't crash when fed malformed data.

Re:His examples do not really crash Firefox

[kryptkpr]

You're thinking of https://bugzilla.mozilla.org/show_bug.cgi?id=26491 3 then.

Re:His examples do not really crash Firefox

[NeoSkandranon]

Beautiful. I go tor ead this comment and the bug manifests.

Standard Testing

[BenjyD]

Shouldn't this random input be part of standard testing for any application?

I use it all the time for testing my PalmOS project: the PalmOS emulator has a "Gremlins" mode that throws random events at your application constantly. My basic rule is that if it survives 300,000 events without crashing, there should be no major problems.

Of course it won't catch functional bugs, but it's an incredible tool for catching unchecked inputs, memory leaks and similar problems.

Re:Standard Testing

[shaka]

I use it all the time for testing my PalmOS project: the PalmOS emulator has a "Gremlins" mode that throws random events at your application constantly. My basic rule is that if it survives 300,000 events without crashing, there should be no major problems.

This is very similar to what the Swedish Jargon File refers to as "Mathiasmetoden" ("The Mathias method"):

"Efficient method for debugging of programs. You put both palms on the keyboard and hammer away for 20 minutes. If the program is still alive, it's idiot-proof. (Named after Mathias Båge, the only hacker who can type in bolero tempo on a keyboard). Also called the elbow test, since it can also be done by putting the elbow on the keyboard."

Link.
Note: This translation from Swedish is mine, and it's not perfect in any sense of the word.

Re:This is known

[metlin]

There's a difference between posting an error message and crashing. So I don't think there's any upside for the other browsers on this issue.

Ofcourse.

Nowhere did I mention that it was so, did I?

I do agree that these are quite serious bugs (both of them seem to be associated with datatypes and boundary checks), however IE's ability to deal with retarded code may be what has saved them this time.

You don't get it...

[JudicatorX]

Take a second to compare IE's track record for security/stability when compared to Firefox/Mozilla. Also consider that the vast majority of the serious bugs in Moz have been fixed within *hours*. What has MS' response been to several critical vulnerabilities in IE: "Um.... we may get around to fixing it" or "No, we're never fixing that".

Compare this to: "Oh, X has a security bug.... therefore publisher(X) makes crappy software".

Next?

I _love_ his conclusions

[Ender Ryan]

I just love his conclusions at the end of TFA. Since IE crashes less often with broken HTML(this does, of course, ignore all the other things that cause IE to crash), it obviously went through much more rigorous security QA.

Pfft, bullshit. Security QA? Riiiiight.

My wife switched to the Fox over a year ago(well, it was called something different then...) because IE was too crash-prone. I didn't tell her to, she asked me if there was something else she could use. That is only one example of someone switching because of stability, I personally know several folks at work who did the same. I haven't used SP2, so I don't know if it's better there, I'm sure it is. But to conclude that IE went through more vigorous security QA is absolutely laughable.

OTOH, this does highlight serious problems with other browsers. OTOH2.0, there are a number of crash bugs in Moz that are known and aren't considered security vulnerabilities, so I wonder if any of the crashers the author found are the same.

Anyway, interesting article with ridiculous conclusions, however some very much needed good PR for IE ;D

hmm...

[neko9]

Opera 7.54 on Mandrake loads taht cgi "lite" live demo page succesfully and while refreshing shows random junk. no crashes and no slowdowns.

Who's Who

[Effugas]

Ugh. Not the best written Slashdot entry.

Larry Osterman -- former Microsoft guy; someone forwarded him a post to Bugtraq.

Michael Zalewski -- absurdly brilliant security engineer out of Poland. Did the pioneering work on visualizing randomness of network stacks, passively identifying operating systems on networks, and way way more.

Nothing bad against Larry. But this is all Zalewski :-)

--Dan

Re:Who's Who

[spectecjr]

Larry Osterman -- former Microsoft guy

Make that Larry Osterman -- current microsoft guy.

generated html

[noselasd]

The entry refrences this, which just spits out bad HTML from the tools he wrote. I'v been reloading
it _MANY_ times now in firefox 0.10, but havn't seen any crash yet.
Anyone crashed anything on the above link ?

Re:generated html

[BenjyD]

Yes, it took down firefox and my X server too. Firefox 0.9.3(ubuntu version), xfree 4.3, linux 2.6.8.1.
Firefox seems to have a great ability to crash the x-server.

Re:generated html

[XO]

Crashed the whole machine my webserver runs on, Mozilla 1.6, Fedora Core 2

Locked my X server on Mozilla 1.7, requiring me to go to console and kill the X server

Opera stared at it funny and said "What?" and rendered squat.

IE Crashes On Valid HTML!

[Diplo]

Nevermind using random garbage to crash a browser, you can make IE6 crash with perfectly valid strict HTML.

Try this page in IE6 and then hover your pointer over the link. Crash!!!

Re:IE Crashes On Valid HTML!

[Grey Ninja]

Don't forget this one either. (Mind you, this one has been fixed in XP SP2)

Re:IE Crashes On Valid HTML!

[NoMercy]

Tested the mangle.cgi on my own system, Firefox crashed with a offset to a null pointer, IE however crashed, locked up the system and trying to get back though ctrl+alt+delete locked up the system totally in need of a reset button push.

I personally wouln't say IE shines.

Re:IE Crashes On Valid HTML!

[jamesl]

Just tried it. IE 6.0, SP2. No crash. Works fine.

Re:IE Crashes On Valid HTML!

[farlukar]

Yay! Crash on page load!

Re:IE Crashes On Valid HTML!

[Midnight Thunder]

I just tried "mangle.cgi" with Camino (Cocoa app, gecko engine), on MacOS X, and it ended up using so much CPU that I was forced to reboot.

Re:IE Crashes On Valid HTML!

[julesh]

Yes. This is because it crashes IE. Whether this makes it a trojan or not is an interesting question, but the fact that it would was very obvious from the context...

Re:IE Crashes On Valid HTML!

[julesh]

Also fixed in Win2K + IE6 SP1, by the looks of things.

Re:IE Crashes On Valid HTML!

[mcsmurf]

Looked it up again, it was
<HTML><INPUT AAAAAAAAAA>
crashes here Mozilla every time.

Re:IE Crashes On Valid HTML!

[Reziac]

That's interesting -- I mean about the comment in the HTML source that says if it's removed, the crash goes away.

I found that in IE5.00, a table border was rendered as normal or collapsed depending on an assortment of *text* factors (and other tags that had nothing to do with the table structure), even if the HTML was exactly the same. And how it's misrendered is different depending on the exact build.

See various stuff in http://home.earthlink.net/~rividh/kennel/news/tabl ebug/
I was playing with IE 5.00.2314.1003IC, but a friend checked it in IE 5.00.29nn.something, and while the bug was still there, it manifested at different points.

results of testing mozilla on linux- NO CRASHES

[evil_one666]

Replicating the experiment on mozilla on linux (repeatedly refreshing the url: http://lcamtuf.coredump.cx/mangleme/mangle.cgi) causes NO CRASHES

I think there may be some FUD here...

Re:results of testing mozilla on linux- NO CRASHES

[Anonymous Coward]

Not so fast my friend (same goes for the moderators).

Try the known examples that "work" here:
http://lcamtuf.coredump.cx/mangleme/gallery /

They work for me using the latest firefox on linux.

Re:results of testing mozilla on linux- NO CRASHES

[fozzmeister]

the mozilla-die ones did kill it tho.

Re:results of testing mozilla on linux- NO CRASHES

[quadfour]

I've testes all the mozilla-die ones on my mozilla and it didn't have any issues, no crashing. The other ones (Opera, Links, lynx) all crashed though :(

Mozilla 1.7.2, Copyright (c) 2003-2004 mozilla.org, build 2004080400

Linux natalie 2.6.8.1-12.2mdk #1 Sun Oct 10 14:35:41 WST 2004 x86_64 AMD Athlon(tm) 64 Processor 3000+ unknown GNU/Linux

Re:so?

[Maestro4k]

• So what? I have never had a problem with my Firefox crashing (ever). Sure, if you try to make something crash, it eventually will. Considering how much security holes IE has, IE could be the missing link, and I still wouldnt use it.

Just because you haven't crashed it doesn't mean it's not happening. I switched my Mom over to Firefox for her computer's safety about 2 months back. She's still using it, but it crashes for her regularly and it's becoming a big frustration for her. As she put it "why does Firefox crash so much, IE never crashed on me?" If Mozilla/Firefox/Opera/etc. hope to continue gaining ground on IE, then this type of thing needs to be addressed.

As I see it the major problem that Mozilla/Firefox has is the vast majority of those using it (and most definitely the vast majority bothering to report bugs/crashes) are techies. Why is that a problem? Well we probably don't spend our time to going to "silly" E-card sites and joke sites that use bad flash/html. Sure we can dismiss those sites as not important, because to us they aren't, but to a large portion of the average users out there they're one of the most important things they do in a browser because to them they're fun.

So I'm betting Mozilla/Firefox actually crashes regularly on non-techies simply because they visit sites that most techies don't bother to test the browser on.

There is actually some truth to the matter

[grinder]

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

Re:There is actually some truth to the matter

[Brummund]

There's nothing wrong in rendering a GIF image from inline binary data provided in the SRC attribute of an IMG tag.

Check out RFC 2397 - The 'data' URL scheme

Re:There is actually some truth to the matter

[Hockney Twang]

Wanna see something neat? Copy their

<IMG
SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP ///ywAAAAAMAAw
AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvU UlvONmOZtfzgFz
ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP 5yLWGsEbtLiOSp
a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfn ycQZXZeYGejmJl
ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtw vKOzrcd3iq9uis
F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f 1cf5VWzXyym7PH
hhx4dbgYKAAA7"
ALT="Larry">

into an html file, open it in IE, red X, open in FF, displays perfectly.

A quick google search...

[ReKleSS]

Let's see... it came up with:
http://www.geoapps.com/ie6crash.shtml: Image exploit that does something to mozilla, but nothing serious
...and I'm having a hard time finding anything else. I remember seeing a few before, but I can't find them, and I really should be doing homework right now. CyberArmy used to have a crash page, but I can't find that either. Oh well... but they do exist.
-ReK

Re:A quick google search...

[Reziac]

ie6crash.shtml also crashes IE5.00 on Win98:

This program has performed and illegal operation, yadda yadda.. details:

IEXPLORE caused a stack fault in module SHLWAPI.DLL at 015f:70bdf369.
Registers:
EAX=00cc5260 CS=015f EIP=70bdf369 EFLGS=00010206
EBX=06000000 SS=0167 ESP=00551f44 EBP=005525cc
ECX=00552814 DS=0167 ESI=06000000 FS=4db7
EDX=00000009 ES=0167 EDI=00553300 GS=0000
Bytes at CS:EIP:
53 56 57 8d 8d 98 fd ff ff e8 fd 4e ff ff ff 75
Stack dump:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

followed by a dialog box that proclaims "There was an internal error and one of the windows you were using will be closed" [OK]. (Never seen that one before.) IE then closes, with no aftereffects, which is kinda unusual since more often than not, when IE crashes it takes Win9* with it.

No problems on Firefox 0.10.1

[bbuR_bbuB]

Huh? Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10.1 No crashes here. I must not be lucky.

Re:No problems on Firefox 0.10.1

[aldragon]

No crashes here either: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040817 Firefox/0.9.3

Tell me, Mr. Anderson...

[b374]

Tell me, Mr. Anderson, what good is a browser when you are unable to access the net?

Not a Security Issue, but a conceptual concern

[fwitness]

While it's great that IE can handle 'bad' web code, it really is a seperate issue from security. Now, when the other browsers actually *crash*, this is a concern. Yes crashes *can* be used to determine an exploit, but that doesn't mean they *do*.

To beat the dead horse of the car analogy, if my car doesn't start, it may be the entire electrical system, or maybe my battery is just dead. The moral is don't try to make a mountain out of a mole hill.

Meanwhile, I absolutely despise the fact that IE does handle a lot of 'bad' code. This is a side effect of the IE monopoly on the browsing world. We're not talking about it handling variables that arent declared before they are used or sumsuch. We're talking about code which *should* be causing errors. Since they don't cause errors most of the time (or are hidden from the user) and most web authors only test with IE, there is a massive amount of bad code on the net which is never fixed.

Now I'm glad that the author has found these crashing bugs in the other browsers. This obviously needs fixing, and I'm glad IE is at least stable when it encounters malformed code, but more error reporting needs to be done to the user on all browsers.

Summary:Good review, brings up great points, kudo's to MS for stability. Now everyone go back to work on your browsers and add blatant *THIS WEBSITE AUTHOR DOES NOT WRITE PROPER CODE* dialogs to all your error messages. It's the web author's fault, it's time we told them so.

Re:Not a Security Issue, but a conceptual concern

[Peyna]

While it's great that IE can handle 'bad' web code, it really is a seperate issue from security

There isn't much difference between 'bad' and 'malicious' code, except the intent of the author. By your reasoning, most of the security issues with IE would just be the result of 'bad' HTML code, and therefore not really security.

Re:Is this for real?

[Anonymous Coward]

Well I'm using Mozilla 1.7.2 on debian (stable) and mozilla_die1.html and mozilla_die2.html both caused my mozilla to crash. Whatever you may think of IE vs mozilla vs whatever, you have to admit that a browser crashing can be a little anoying.

Test your code at http://validator.w3.org/

[millahtime]

Test if your code is good or not at http://validator.w3.org/

Re:Test your code at http://validator.w3.org/

[pipacs]

Test if your code is good or not at http://validator.w3.org/

Just make sure you don't crash the validator!

doh?

[realkiwi]

Mozilla shines on broken code too!

What was this story suposed to prove? Oh! You mean browsers running on Windows crash. But they are supposed to crash on Windows. Windows has only one browser.

When you run his tests with Mozilla on Linux it has no problems with the code.

Strange story guys

Re:doh?

[iapetus]

Nice point, but sadly not true. I presume you just clicked a few times on the limited online demo of the script?

If you'd read the BUGTRAQ posting, you'd have found links to two files that reproducibly crash Firefox on Linux (I'm using build 20041014 Firefox/0.10).

In other news..

[rjshields]

This just in - a formal testing procedure helps reduce bugs.

Re:In other news..

[rjshields]

I'd love to see someone write the unit test for this before coding as required by test-driven development:

You seem to be implying unit tests are only useful if you write them before the code. This is not the case. Also, it's not difficult to write tests that test behaviour parsing broken html. If the article author can do it, so can browser vendors.

Congratulations, you've just proven yourself an ignorant AC.

Great Tool!

[EMN13]

These kind of tools make a hacker proud :-).

Simple, effective means of testing program to find bugs. I'm certainly sold on using this kind of program to test my code. Of course it's only the tip of the iceberg; similar tests should exist for css, javascript, images, http, ftp, etc. etc. etc.

--Eamon

useful

[zecg]

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

That's great! Now I can finally read all those randomly malformed sites I've been bookmarking lately.

Re:This is known

[Anonymous Brave Guy]

I repeat: code that crashes with a null pointer error is wrong. End of story.

It's never that simple. If you're talking about an end-user application that crashes, I'd probably agree. But it can certainly be appropriate for libraries to have undefined behaviour given bad input, rather than spending lots of time performing validity checks that are really the client code's job. (Think high-performance mathematical code, where the validity checks can cause unacceptable slow-down.)

I'd like to see a Safari test.

[Dink Paisy]

Perhaps Konqueror is better than other browsers, or perhaps the involvement of Apple means that Safari is better tested than Mozilla or Opera.

Unfortunately, handling the test cases provided with the post doesn't mean it's ok. Browsers were run with randomly generated test cases, and the article says that usually a hundred or so tests were required to cause a crash. The probability of a poorly written browser crashing on any given case is low.

The chances of any single test case being problematic are low, so passing the cases provided doesn't mean Safari is safe. If someone downloaded the cgi that automatically generated tests and left Safari with that for a few hours without crashes, we could then say that it lacks the flaws that Mozilla and Opera have.

Re:I'd like to see a Safari test.

[prockcore]

Perhaps Konqueror is better than other browsers, or perhaps the involvement of Apple means that Safari is better tested than Mozilla or Opera.

No, the reason Safari doesn't crash is because it stops reloading the page! Even though there's a meta refresh tag at the top, safari ignores it after 3 refreshes.

If you keep reloading the page by hand, safari will eventually crash.

So a bug in safari actually prevents the bug checker from running :)

Re:I'd like to see a Safari test.

[hc00jw]

Even though there's a meta refresh tag at the top, safari ignores it after 3 refreshes.

And...

So a bug in safari actually prevents the bug checker from running :)

Surely that's a feature!

No, really... Not in a "that's a feature not a bug" sort of way, I mean it really is a feature!

Re:This is known

[ClosedSource]

"The renderer adequately makes up for errors in the HTML code, and consequently there are fewer crashes."

This suggests that the solution for preventing crashes is to be liberal about what HTML you allow. You were making excuses for the other browsers implying that they were crashing because of their strict HTML handling, but the fact is that they could have posted an error rather than crashing and still been just as strict.

That's odd...

[jridley]

I just downloaded and ran his test suite against Firefox 1.0PR.
Everything looks fine to me. No crashes. I also ran it against his CGI and the "die" gallery in the tarball. No problems, though it did stop for a few seconds a few times.

Now, he does mention that sometimes the crashes are due to memory exhaustion. I've got the suite running right now on another tab of the browser I'm typing in, and the memory usage is going up, but only very slowly; I think it's due to the logging in the JavaScript console that's happening due to the bad JavaScript that's running over there. After 15 minutes of constant reloading, it's up from 39 to 44 megs. So maybe if you reloaded bad JavaScript constantly for a couple of days, you might eventually run out of memory. Certainly if there's a memory leak, it should be fixed, but IMHO that's not a security hole, while crashing indicates the possibility of one.

Re:That's odd...

[blueforce]

That's funny. I ran the Mozilla_die1.html and Mozilla_die2.html against Firefox 1.0P on Win2K and it crashed on both.

Certainly doesn't look fine to me.

Re:That's odd...

[jridley]

Those were the only two that really caused trouble for me, but they didn't crash it. They hung the tab they were on, but I just closed the tab and went on browsing in the others.

Re:That's odd...

[blueforce]

That is interesting then.

When I opened either of the files, it gave me the always fun windows app exception message saying memory couldn't be read and wiped out every running instance of firefox.

Version 1.0 preview release.
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

Safari holds up OK

[goynang]

Using Safari 1.2.3 (v125.9) and all is fine. Tried the online version of the tester and just got a blank page (with crazy source). No crash, no hang, no problems as far as I can tell.

Score one to the kool aid.

Re:This is known

[root2]

It's a little unfair to blame Microsoft for that. I mean, they create a more flexible product, and people take advantage of that to be lazy. Surely it's the fault of the people, not the product creator. Blaming Microsoft in the this instance is like blaming car manufacturers for selling cars with ABS and traction control, since it encourages people to drive badly (e.g. when they change to a car without ABS and traction control).

do the same with windows itself...

[loconet]

It's interesting that you can do the same type of test with windows utilities as well as described in this Full Disclosure note.

Hi all,

Wanna do a quick test to see if the programmers that wrote your windows operating system have any clue as to what there doing ? Run these
commands from cmd.exe in the system32 directory:

for %i in (*.exe) do start %i %n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n%n
for %i in (*.exe) do start %i AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.... (type as much "A"-s as
cmd.exe allows on one line.)

Each command will execute every program in your system32 directory, most
of them will either ignore the parameter or report an error because the
parameter doesn't make sence... But on my win2k system I found 6
programs vulnerable to these very simple formatsting and BoF tests....
grpconv even gives EIP 0x00410041, can it be any easier?

These are not vulnerabilities in itself: you cannot gain access or elevate priviledges but I just wanted to let you know that these programmers did a sloppy job.

Cheers,
SkyLined

handling malformed data is a pretty bad idea ...

[cascadingstylesheet]

... and here's why.

With correct data (in this case, HTML), there is a specified action that is "correct". In other words, a correctly marked up table will get layed out, according to the W3C rules for laying out tables. A paragraph will get formatted as a a paragraph, etc.

With malformed markup, the "correct" thing to do is indeterminate. If every browser just takes its best guess, they will all diverge, and the behavior is wildly unpredictable. Even from version to version of the same browser, the "best guess" will change.

"So? You've just described the web!" Well, exactly, but it could have been avoided. Bad markup shouldn't render. It ain't rocket science to do (or generate, though that can be a harder problem) correct markup. If you had do it to get your pages viewed, you would. Ultimately, it wouldn't cost anymore, and would actually cost less (measure twice, cut once).

Of course, what I just wrote only really applies in a heterogenous environment ... which MS doesn't want ... fault tolerance in your own little fiefdom can make sense.

Bug 265027

[Val314]

FYI http://bugzilla.mozilla.org/show_bug.cgi?id=265027 (copy/paste, Bugzilla doesnt like /. links)

Bugzilla

[Plutor]

How come this guy felt it was more appropriate to post this to a widely-read security mailing list than to submit a bug to Bugzilla? Complaining about QA to a group of security experts doesn't improve the product. That's what's great about the Mozilla Foundation, and Open Source in general. Don't just complain "Waah, it's broken", file a bug!

Luckily, someone did it for him: Bug 264944. I can't link from here, but if you visit http://bugzilla.mozilla.org/ and put the bug number in the little search field, you can see it for yourself.

Re:Bugzilla

[rjw57]

Why don't you think the chap himself posted the bug? He /did/ day that he notified the vendors before posting the message. A post to bugzilla could be part of a notification.

Re:Bugzilla

[Plutor]

Because, well, he didn't post it. The bug was submitted by Daniel Veditz. The guy who posted to Bugtraq was Michal Zalewski.

Whether he notified the Mozilla Foundation some other way, I'm unable to say.

maybe its a fluke..

[Anonymous Coward]

I tried this script on both Mozilla firefox at least 40 X now, and it hasn't crashed yet...

You'll also notice none of this random code tests activex security either, or many of the MS extensions which "enchance" security either.. So I think the tests should be taken more with a grain of salt.. Also while he did say null dereferences, its potentially due to all the same 1 or two flaws, and may not be exploitable at all..

Take this with a grain of salt I'd say, because when you check the tags being tested, there aren't a great amount..

Re:maybe its a fluke..

[iapetus]

Did you read the BUGTRAQ report? It contains links to two Mozilla-crashing examples, one of which I haven't tested, but the other of which hung a recent Firefox nightly quite handily. He ran the script for over an hour for each browser, AIUI, so getting no hits in 40 attempts isn't a real surprise. IE turned up no crashes in 2 hours.

Attempts to score political points aside, this is a handy test tool, and I'd hope that it leads to those bugs being fixed in Mozilla (and other browsers).

Re:The REAL reason

[dJOEK]

Actually, i just write my html freeform, and if it runs ok in Safari for me, it should be fine for everyone else.

I hardly feel superior to anyone, only to ACs such as yourself.

I suggest you ponder the following statement:
If something is worth doing, it's worth doing right.
It's what we elitist, insecure petty nerds call 'compliant'

Then again, it's quite hard to write 'wrong' ASCII, but you'll probably ask me to ponder:
If something is hard to do, it's not worth doing at all

Some of us who give a damn actually need certain HTML features.

As to your questions, everything I do has the security, uptime, accessibility, and reliability that I need.

I have one more question for you:

Are you over 40 and stuck in a dead end IT support or Junior Admin position? Or are you by any chance Eric S. Raymond?

Enjoy your 'real' life, because I more than enjoy mine, together with my insecure girlfriends, petty salary and elitist friends

Re:Is this for real?

[Grey Ninja]

I must be blind, I completely didn't notice the gallery. I am running hte October 18th nightly of Firefox on Windows XP SP2, and it crashed on mozilla die 1 and 2.

But the thing is that although there are a couple examples there of garbage that crashes mozilla, there are also plenty out there for IE too. I was working as a web developer for a corporate intranet for the last year, and I found many interesting ways of crashing IE6 with Javascript (I can't recall crashing Mozilla with Javascript at any point), but there are also HTML only ways to crash IE.

Seems true for Slash code, too.

[Vandil X]

Almost everytime I click on an article, what appears on screen makes me feel like I am loading broken layout code into my browser, resulting in multiple clicks of the Reload button.

However, the same code works fine in Internet Explorer, every time.

Re:Seems true for Slash code, too.

[tepples]

If you load Slashdot's semi-broken HTML into a Gecko browser, but glitchy incremental reflow screws it up, then force a manual reflow: press Ctrl+minus Ctrl+equals, and it should reflow correctly. Too bad there's no equivalent for crash bugs.

Borrring...

[PhraudulentOne]

He should have randomly fed STABLE code into each of the browsers and saw IE continue to freeze and hang while the other browsers continued to present real data to the end user ;) Sure IE may not suck for bad code, but I like to look at real code with real information and I know that IE hasn't quite figured that one out yet ;)

Re:Borrring...

[Blitzenn]

If IE hangs and freezes on your machine, I would hesitate to blame IE. It is probably indicative of a deeper problem that you have. Spyware has most likely infested your machine. IE works fine in a virus and spyware free environment on every machine that I have at home and in the office. No hangs or freezes at all with version 5.5 or greater.

I tend to think that you are simply bashing here and don't really have anything useful to contribute.

Re:Borrring...

[PhraudulentOne]

Actually, I don't use IE.

Thanks for the spyware tip, but I'm fully aware of the inner workings of windows and how spyware may negatively affect the performance of a machine.

You are correct. I didn't have anything useful to contribute except for the JOKE post. Unless you don't find humour useful....

Re:This is known

[pete_norm]

My point is a browser that runs bad HTML code implies bad programing methods.

Bad implementation of the standards maybe, but it has nothing to do with the programming methods.

It's ALWAYS that simple

[Rogerborg]

Processor power is cheap compared to engineer salaries. If you aren't prepared to take the hit for an "if(foo)" conditional, then be prepared to pay for my time in finding the flaw in your code.

Re:It's ALWAYS that simple

[tepples]

Processor power is cheap compared to engineer salaries

Even on mass-market battery-powered devices?

Re:It's ALWAYS that simple

[The Conductor]

That depends on how many times the code is executed vs. how many higher-level programmers will be inconveninced. If you are writing library code used in a simulation of the Big Bang on a supercomputer, it may be more cost-effective to leave consistency checks out. Or real time applications: When you have to decide to kick a defective jar off the conveyor before it moves past the kick-out mechanism, too-slow software won't work at all (unless you slow the whole factory down), but unsafe software may only require an attendant to re-start the system once every few hours.

Compiler and Memory Manager?

[Domini]

Perhaps the compiler and Memory Manager is such as to automatically discourage the software to do destructive buffer overflows?

I've noticed in the past that with writing flaky software in windows you can just ignore many memory related errors and continue with execution... or at least this is more common practice. In most cases this is justified IMHO.

Re:handling malformed data is a pretty bad idea ..

[hedge_death_shootout]

HTML is out there, and millions of malformed pages exist. Most of this is a result of mistakes by authors, but some of it is a result of the moving target that HTML has presented in the past.
While your argument is attractive in principal, in practice it's misguided. The horse has bolted. in 2004, no-one would use a browser that didnt work with a huge proportion of the web's content. This is an area where pragmatism is required.
And to respond to the ubiquitous MS-bash, let's step back and remind ourselves that this /. story is also about how various browsers, including the saintly Firefox, can be made to *crash* given certain input. Just thought that should get a mention :)
(And BTW, I speak as a Firefox user)

Re:so?

[XO]

I tried out Firefox a couple of days ago, and was pretty pissed off that it would crash while doing, quite literally, nothing. I had loaded slashdot and fark in seperate tabs. Was off playing pokerstars in wine.. went to go back to firefox after about 10 minutes, and realised it wasn't in my task bar anymore. Oops!

unstable. as. hell.

w3c validator

[El_Muerte_TDS]

I wonder what happens when I try the output on the w3c validator.

Re:w3c validator

[Trevin]

I just tried all 5 of the sample pages listed in the report with the W3C Markup Validation Service. None of them crashed the validator; they all showed "This page is not Valid !" and listed the specific lines which were in error.

Poll: WHO has experienced crashes?

[koi88]

From many posts here I get the idea that most people didn't have the crashes the author had...
So can those people who have tested his code write

• used browser and version number
• OS (exact)
• result

PS: I'm here at work on Mac OS 9 and all browsers are pretty old, so I don't write anything...

Re:Poll: WHO has experienced crashes?

[lahvak]

When using the link to cgi script included in the bug report from my work computer, I was only able to crash links and "hang" lynx. Firefox and IE worked fine.

But when I downloaded the program and installed it on my home computer and ran it locally with the auto-reload feature, galeon and other mozilla based browsers lasted about 5 minutes, lynx went down almost immediately. It looks like most, if not all, of the problems were with memory exhaustion and subsequent crash.

IE on another computer, connecting to my server, survived for 20 minutes, after that I terminated the test. It wasn't the latest version of IE, too.

I didn't have time to look at the code yet, but it seems to me, at least from the gallery examples and behavior of the browsers during the test, that the script tries to make browsers allocate some huge amount of memory. Possibly IE has a check agains this sort of problems.

This sort of test does not really prove that IE is bug free, it just show that the other browsers are not. Some major bug-squashing should follow.

Re:Poll: WHO has experienced crashes?

[The Raven]

Actually, that's false. Of the people who ran the ACTUAL TEST PROGRAM, most crashed their browser very quickly. Some ran it as many as 40 times, and it came out clean... but 40 is hardly conclusive. That's like running prime95 for 10 minutes and concluding that your processor has no issues.

Many people did not even run the real test app... they looked at the few examples posted and those did not crash, so they concluded it was false. There's a whole lot of 'did not read the whole article' going on with the people who claimed to have no issues.

Makefile

[kasperd]

I downloaded the tool and started looking in the files. The first file is the Makefile. Here I noticed some confusion between globing and regular expressions. The expression core.[1-9][0-9]* would make a lot of sense if it was a regular expression. But shell expansion does usually not use regular expressions but rather globing, which is slightly less powerful. That means make clean does not remove a file named core.9, but does OTOH remove a file named core.10abc. Of course he is not the first person to make that mistake, and it is easy to miss when testing.

Re:handling malformed data is a pretty bad idea ..

[oojah]

But handling it sufficiently well that you don't crash would be a good thing?

Cheers,

Roger

IE problems

[fionbio]

I've once managed to kill my Windows XP by similiar experiment. I've wrote a simple ASPX that generated randomly damaged WMFs and displayed them in browser doing reload afterwards. I don't know how well WMF problems were fixed after several WMF-related vulnerabilities are published, but the problem is that metafile data is directed right to GDI32 via PlayMetafile() and some of not-so-checked data even manages to get through to kernel-level win32k.sys. EMF has similiar problems. During these cruel experiments I've caused IE to crash many times, and after 30 mins of testing i've got BSOD. I've rebooted Windows, and it didn't find it's registry ... :( NTFS was severely damaged, and unfortunatelly the corresponding "test case" (broken wmf) was lost...

Re:This is known

[idlethought]

I think the point is: If IE responded to bad HTML by showing a blank page, there would be less bad HTML in the world. That doesn't excuse other browsers crashing, but it does mean that IE's behaviour is slighty better, not right.

Dumb developer question

[Halo-]

Wow, what a great test tool! I do software dev for a living, and the hardest part is when a user says: "umm, I did something, and it crashed... I dunno what..." and then you can't reproduce the problem. The problem exists, but due to the complexity of software, its environment, and the subtleties between the way individuals use it, it's hard to reduce the problem down to a few variables...

A tool like this would let the average wanna be contributer find a reproducable bugs and try to fix them. Which brings me to my dumb question: Is the Mozilla gecko engine more easily built/tested than the whole of Firefox? I love FF, and wouldn't mind throwing some cycles at improving it, but the entire build process is a bit more than I really want to take on... If I could just build and unit-test the failing component I'd be more likely to try.

Anyone have pointers beyond the hacking section at MozillaZine?

Re:Dumb developer question

[David Gerard]

This is why they do nightlys. Whereas compiling Mozilla or Firefox for yourself is extremely laborious, you can use this device to generate crashers, reduce them to test cases, see which nightlys they break and file the bug reports and talkbacks.

This could be the greatest Mozilla stability enhancement tool yet seen!

Re:Dumb developer question

[David Gerard]

Ah, sorry, I should read before posting. Gecko's internals are arcane indeed, but if you really want to dive in then:

1. Get it compiling on your system.

2. See if you can help with a bug that's in the system already (a crasher or even a misrendering).

3. Find the Gecko hackers and pick their brains.

Re:Dumb developer question

[Anonymous Coward]

If you think this is cool, you should also google on something called 'Delta Debugging'. DD takes over after the random test generator finds a bug-exposing input -- it systematically and automatically simplifies the input until a minimal bug-inducing input is found.

Random testing got a bum rap decades ago when running tests was expensive. Today it's extremely cheap, and being able to produce and run millions of tests on idle machines gives you enormous testing power with little manual effort.

DoS vs Security hole, vs just bad code

[qray]

My guess that most of the issues are the latter two, though obviously this needs to be verified. Most things probably stem from poor error handling and edge case. It will be interesting to see if this turns up any real security holes.

This reminds me of the article some years ago about a project reported in an ACM publication to feed broken command lines to UNIX. They found numerous problems doing that.

Having done both commercial and open source software, I've not found one to be all that better than the other. Sure the best open source project is better than the worse commercial. I'm just not sure the average is that different.

Re:handling malformed data is a pretty bad idea ..

[smoking2000]

You raise a nice question.

I would love to see a plugin for Firefox which enforces a "use strict" like with Perl.

When the plugin is enabled (a buildin option would have my preference, though), bad code won't be rendered at all.

Just like in the days of Mozilla prior to 1.0, before then it hardly ever rendered bad html, afterwards they focussed more on the "Website compatibility"

I tried his "live" POC...

[miketang16]

I'm not quite sure what this is supposed to prove. I refreshed the page a good 20 times at least, in 'Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1' and no crashing whatsoever. Could this be a Windows-only bug?

And also, about those NULL pointer references... the only ones I found were displayed in the JAVA CONSOLE and did nothing to affect the stability of the browser.

Correlation != Causation

[BabyDriver]

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).

A person writing a 'Linux advocate article' is likely to be making extensive use of CSS in order to properly separate the document structure and style. In other words they create documents that are easier to maintain and comply with the standards.

I don't suppose most of them will cry if IE renders it slowly but I doubt that's their primary reason for doing it, although they'll certainly be aware that IE's CSS compliance sucks.

Re:so?

[Christianfreak]

So I'm betting Mozilla/Firefox actually crashes regularly on non-techies simply because they visit sites that most techies don't bother to test the browser on.

My wife uses Firefox on Win2k. In the months she's had it it has maybe crashed once. She visits all sorts of random sites that "techies wouldn't test their browser on"

I've been using Firefox since it was Phoenix and Mozilla pre 1.0 before that. Combined all generations of the browser have crashed maybe a dozen times for me.

Contrast that to IE that crashes about every 10th time I use it.

It probably depends on the computer, what else is running, etc. etc. I'm willing to bet that has much more to do with it than the browser itself. You can also report these bugs and they will get fixed.

Re:handling malformed data is a pretty bad idea ..

[Tim C]

With malformed markup, the "correct" thing to do is indeterminate.

Well, that's debatable, but one thing that's for certain is that you absolutely should not crash due to malformed data. That's bad enough in a browser that doesn't support tabs, but in a tab-capable browser it's unforgivable. That one unparsable webpage that causes the browser to crash is a serious annoyance if it takes out another dozen or so tabs in the process.

Even ignoring questions of pragmatism (raised by other respondents), at the very most the browser should display some sort of "malformed page, unable to display" error. User input (which this is essentially) should not be able to crash an application. My compiler doesn't crash because of syntax errors in my code, why should my web browser?

and IE Breaks on Shiny Code

[Meostro]

sorry, that's all i got...

Basic question

[seguso]

Could somebody explain why bad pages can make a browser crash? For what I know, if a parser is fed illegal code, it simply returns "failure in parsing" or something like that. Why should it crash?

Re:handling malformed data is a pretty bad idea ..

[StrawberryFrog]

Bad markup shouldn't render.

It shouldn't crash the browser either.

If any input, even a pathological one, can crash my program, then I need to fix my program. Always.

OSX Safari A.O.K

[Uncertain Bohr]

I tried using Safari 1.2 on OSX and have had no problems. No crashes, no hangs, no problems. Loaded the test a few dozen times.

Ok, did he file a bug report?

[Stonent1]

Assuming he used Mozilla, did he file a report in Bugzilla?

Re:This is known

[StrawberryFrog]

But it can certainly be appropriate for libraries to have undefined behaviour given bad input

Well, that is arguable. All that means in a case like that is that the code that needs to be fixed with some extra checks is the client code to that library. It still needs a fix somewhere.

Konqueror works fine

[cs668]

At least I tried these examples with Konqueror and it did not hang or crash.

Don't try the Lynx one!

[ibentmywookie]

I tried the mozilla ones with Mozilla 1.6 and firefox 0.9.1, and they both crashed and burned. The Opera test crashed my Opera 7.54 (opera remembers where it was, so yay).

I tried the lynx (version 2.8.5rel.1) one, and um.. well.. Linux doesn't handle programs eating memory really quickly very well. I was getting mouse lag, and my system was really unresponsive. I hit ctrl-c about a thousand times, and managed to bring up KDE system guard and kill it.. it was using like 500MB of RAM. Nasty nasty stuff.

Re:Don't try the Lynx one!

[Lisandro]

Linux 2.6 is *MUCH* better in this regard; the improved scheduler and preemptive kernel patches really make the machine much more responsive, even under heavy load.
I can have my machine at 99% CPU usage and wouldn't be able to tell except for programs loading slower. Also, whenever i have "memory runaway" (programs that start eating more and more memory), the system stays responsive.

Anyway, if you haven't tried it, it's well worth the upgrade.

You mean Gnu

[PigeonGB]

You mean Gnu/Linux/Apache/Mysql/Perl/Python/PHP system, right?

Re:You mean Gnu

[Zarf]

No. I don't. I meant LAMP systems.

What are we saying here?

[The1Genius]

Are we assuming that having a program continue to run after parsing bad code is a good thing? Yes, it keeps running until someone can find a way to malform the code enough that they can take complete control over your machine.

I think I'd rather use a browser that abends.

Re:What are we saying here?

[tommck]

You'd rather have a program crash when it gets bad data?

Remind me not to run any or _your_ code!

Re:What are we saying here?

[The1Genius]

A more eloquent arguement posted here:

http://blogs.ittoolbox.com/eai/implementation/ar ch ives/002013.asp

IE couldn't have been written in .NET...

[generalpf]

...because it doesn't need the .NET CLR installed to run.

Re:so?

[sosegumu]

I have never had a problem with my Firefox crashing (ever).

Yesterday Firefox crashed numerous times on this page (great show BTW) after I clicked on a character and then clicked the 'character bio' link. I got to the page by clicking a link in an email in Outlook 2003. I've had this happen occasionally while browsing. I can't really compare IE, since I rarely use it. All in all, I'm pretty satisfied with Firefox--they probably just need to clean it up a bit.

His examples don't work (crash browser)

[Gilmoure]

I tried each of his 'die*.html files and none of them killed my browser. Most just resulted in blank pages.

I'm using Safari, on OS X (10.3.5)

Re:His examples don't work (crash browser)

[BenjyD]

Not exactly very informative - the die* files are browser specific and are not especially "difficult" cases or anything. Safari (assuming Apple didn't do this kind of testing, which is unlikely) would have different die files.

Why I stay at HTML 4 Transitional

[tepples]

HTML 4 Transitional was designed so that it wouldn't be so much work for sites to change their markup from the previous, somewhat ad-hoc standards. As a result, it includes various tags and attributes from HTML 3.2, usually to do with more visual aspects of page layout. Such features aren't present in HTML 4 Strict, where CSS is used for visual formatting (almost) throughout.

In HTML 4 Strict, how does one number an ordered list starting at 10? The value attribute of the li element (<li value="10">) is missing.

Re:Why I stay at HTML 4 Transitional

[Ford Prefect]

In HTML 4 Strict, how does one number an ordered list starting at 10? The value attribute of the li element (<li value="10">) is missing.

Hadn't known about that - apparently the correct route is via CSS, of course, but browser support is meant to be somewhat lacking. As always. ;-)

My favourite bit of HTML 4 brokenness is the retention of 'cellpadding', 'cellspacing' and friends in HTML 4 Strict's tables. Having attributes specifying pixel-sizes in the supposedly formatting-by-CSS-only system kind of undermines their arguments for removing the more esoteric, not-quite-display features like those list item attributes...

that's easy

[nazokoneko]

$ badhtml.o | /dev/null hey, my script doesn't crash either, and it's only one line! of course, the caveat is that it only displays GOOD tags about as well as IE, too...

Was Coded in VB.

[johnatjohnytech]

They just used

On Error Resume Next

GNU/Linux

[Hugonz]

Funny he refers to our favorite OS as Gnu/Linux....

RTFA before modding this whatever...

Is it just me...

[HerculesMO]

Or does it seem rather amusing that IE, a poorly written browser with many security holes that *brilliantly* links into the OS (not), allows poor code not to crash it...

Then again... properly written code it seems to have problems with.

Oh well.. I guess that's what you get.

Is Arbitrarily Rendering GIF's a Vulnerability?

[Inhibit]

I wonder if arbitrarily rendering image code spat into the middle of a page could be used as a vulnerability? Anyone ever try this?

Have you reported your problem?

[Anonymous Coward]

I hope you have reported the hang on http://bugzilla.mozilla.org . I would even mark it as security sensitive and as a possible Firefox 1.0 blocker.

It's only when people actually report these kind of problems, that they will actually get fixed. Otherwise you can still wait a long time for a fix, as it's not very likely someone else will hit this bug.

Instant IE Crash

[RichM]

...and what about the that he fails to mention then eh? http://www.neilturner.me.uk/2004/May/04/the_input_ type_crash_bug.html

Convenience trumps security again

[scruffy]

Maybe the underlying problem is that the browsers make the assumption that incoming HTML is syntactically correct. This is obviously a bad assumption, but no competitive browser wants to wait for the whole file before trying to display it, nor do they want to insist on purity in syntax for the same reason. Any browser that appears slow or refuses to display marginal HTML will lose on the market. It's another instance of convenience trumping security.

To be secure, you really need two passes, the first to ensure that it "compiles" correctly, or probably better to partially display as it compiles correctly or correctively. I don't imagine we'll see such a slow browser though.

(mal)form follows (mal) function

[tz]

Someone tried to say that crashes=security-hole. That is possible but doesn't follow. It is quite possible that IE's recovery system is going into wierd areas of the code in the recovery and that might be the greater security hole. What IS IE doing? If something crashes, it might be a DoS, but at least it doesn't send your password file. I don't think I've seen very many cases where these are exploitable - you can't "inject" code, merely cause a crash. Maybe the others need an exception handler?

IE has had more documented holes (and fixes). Maybe they will find more in FireFox and Mozilla as time goes by, but I doubt it. If they do I think they will be fixed more quickly since Firefox is NOT part of the OS. The monolithic design has its flaws. There is a dicipline in having to be cross-platform and by separating out the components - flaws tend to be isolated.

OSS does not automatically mean secure

[TheLink]

Netscape used to crash very often. Looks like the Mozilla people didn't learn much from it.

Mozilla is just as sucky security-wise as the old non-mozilla Netscape (3.x 4.x). Whether it is OSS or not doesn't make it secure/insecure, it's the programmers that count. Look at Sendmail and Bind (and many other ISC software), security problems year after year for many years. Look at PHPNuke - security problems month after month for years. Look at OpenSSL and OpenSSH and Apache 2.x - not very good track records. Compare with Postfix and qmail, djbdns.

Most programmers should stick to writing their programs in languages where the equivalent of "spelling and grammar" errors don't cause execution of arbitrary attacker-code. Sure after a while some writers learn how to spell and their grammar improves but it sometimes takes years. For security you need _perfection_ in critical areas, and you need to be able to identify and isolate the critical areas _perfectly_ in your architecture.

To the ignorant people who don't get it. Crashing is bad. A crash occurs when the (browser) process write/read data from areas where it shouldn't be touching, or tries to execute code where it shouldn't be executing. This often occurs when the process somehow mistakenly executes _data_ supplied by the attacker/bug finder, or returns to addresses supplied by the attacker...

This sort of thing is what allows people to take over your browser, and screw up your data (and possibly take over your computer if you run the browser using an account with too many privileges).

So while the FireFox people get their code up to scratch maybe people should reconsider IE - IE isn't so dangerous when configured correctly. Unfortunately it's not that simple to do that.

To make even unpatched IE browsers invulnerable to 95% of the IE problems just turn off Active Scripting and ActiveX for all zones except very trusted zones which will never have malicious data. Since I don't trust Microsoft's trusted zone (XP has *.microsoft.com as trusted even though it doesn't show up in the menus), I create a custom zone and make that MY trusted zone.

By all zones I mean you must turn those stuff off for the My Computer zone as well - but that screws up Windows Explorer in the default view mode (which is unsafe anyway).

For more info read this: <a href="http://support.microsoft.com/default.aspx?kb id=182569">Description of Internet Explorer security zones registry entries</a>

To make the My Computer zone visible change:
(for computer wide policy)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Win dows\Curr entVersion\Internet Settings\Zones\0\Flags

To: 0x00000001

(for just a particular user)
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Window s\Curre ntVersion\Internet Settings\Zones\0\Flags

To: 0x00000001

If you don't want to edit the registry and make the My Computer zone visible, you can still control the My Computer Zone settings from the group policy editor (gpedit.msc) or the active directory policy editor.

You just have to know some Microsoft stuff. But hey, securing an OSS O/S and _keeping_ it secure (esp when u need to run lots of 3rd party software) also requires some in-depth knowledge.

Be liberal in what you accept...

[jefftp]

Jon Postel said it best: "Be liberal in what you accept, and conservative in what you send." A web browser that crashes due to invalid HTML fails this test. Execution must stop at once... yes, but the program should handle the error. A program that crashes is the Operating System handling a program with bug. See RFC 1122 for more details about the Requirements for Internet Hosts. Section 1.2.2 about the Robustness Principle explains better than I can why you're wrong.

The 'Program Crash = Security Hole' doesn't follow

[c.ecker]

As other posters have said, I suspect that the crash is a better result than to happily continue executing code, which is where IE gets into trouble. Even though IE burps, nothing's there to stop execution when it should be stopped, resulting in regurgitation and the execution of worm code.

Admittedly, crashing isn't supposed to happen either, but I'd like to see one of these turned into an exploit before its declared an exploit. The argument that IE Buffer Overflow exploits are found and exploited in this manner doesn't mean that all program crashes are potential Buffer Overflow exploits - that's just does not follow.

It appears from other posters that the behavior depends on the OS you're running, which leads me to guess it might be an issue involving both the OS and the browser rather than just a browser issue.

Along those same lines, the security issue is going to be vastly different depending on the OS you're running the browser under. Mozilla may not provide the same security exploit under your OS as it does under Windows. Example: This bug fix (http://www.mozilla.org/security/shell.html) directed at fixing a *Windows Exploit*.

Finally, you'll not convince me Internet Explorer is a browser to use until its no longer a wide-open-gate for adware/spyware, virus and worms. Even then, I'm gonna have reservations based on IE's history.

Wanna be safe on the Internet? Use anything but IE.

Uhhh, private warez?

[topace]

So I was running the Mangle CGI from his site:
http://lcamtuf.coredump.cx/mangleme/mangle. cgi

and got this weird page:

----------
I see a bad moon rising.
I see trouble on the way.
I see earthquakes and lightnin'
I see bad times today.
Don't go 'round tonight,
It's bound to take your life.
There's a bad moon on the rise.

The page you are looking for is still somewhere around... Go and find it, if you can!

For private files archive, click here.
------------

the "click here" redirects to:

http://lcamtuf.coredump.cx/_private%20warez_/

which looks like:

----------------
SECEXPERTS ARCHIVE: RESTRICTED ZONE

Enter XGB password:
----------------

of course, i dont know what the password is, so i just put in something, and it says:

---------------
SECEXPERTS ARCHIVES: ACCESS DENIED

INCORRECT XGB:21 PASSWORD!!!

Your password is not valid. Try again.

To recover your password from XGB token certificate file, please download it here and use the recovery agent. In case of any troubles, please mail me.
-----------------

The "download it here" is a link to: http://lcamtuf.coredump.cx/_private%20warez_/passw d.dat

and the "please mail me" is a link to:
mailto:lcamtuf@coredump.cx

Interesting..... Very interesting....

*whew*

[Theatetus]

I sure am glad I use emacs to surf...

Why wasn't this tested?

[Anonymous Coward]

A looong time ago I designed hardware. A young software guy was given the task of writing a diagnostic for a memory board I had designed. He spent a lot of time investigating bit patterns and data patterns that caused failures in the specific memory chips we used.

About 4 weeks after he started, he came to me and congratulated me on my marvelous design: his test had run for 2 days solid with no memory failures. Not that I have trouble taking a compliment or anything... I asked to see the test setup. I unplugged one memory chip and the test still passed.

A week later he came back and told me that now it worked. Yeah, it would detect one chip pulled in one bank but when I pulled a different chip from each bank on the memory board it only detected the first bank failure over and over again.

The point of this story is: the software engineer was only interested in whether or not the test ran. I was interested in whether or not the test actually caught errors.

Now: why in the hell did it take a Microsoftie to code up this kind of test and run it on these browsers? How did the coders of these browsers test? By just feeding each browser properly formed HTML and making sure that they rendered right? That is only 1/2 the job!

I now write embedded firmware for a living. I only spend about 1/4 of my time getting the software to do what it is supposed to do with well-formed input. I spend the other 3/4 of the time making sure that mal-formed input does not cause the code to do anything hinky!

Credit where credit is due: kudoes to Microsoft for this particular facet of their browser. And shame, shame, SHAME on the open source coders responsible for those browsers!

Re:Why wasn't this tested?

[BrianHursey]

It's tempting to suggest that this is a MS Windows-issue, NOT a browser issue.

I tested all of the tests on Firefox 0.9.3 in Linux and the first 2 mozilla tests killed firefox the 3ed one did not do anything but the java console picked up this error when I went back and looked.

Error: uncaught exception: Permission denied to get property Window.sf

Re:Why wasn't this tested?

[BrianHursey]

Your also running a macs version of mozilla & firefox that could have something to do with it. Also your versions could have something to do whith it too. What versions are you running? As I said in my post I was running firefox 0.9.3 on Debian/gnu when I ran the tests. I don't see why your acting like im an idiot. I said nothing about OSX..

Re:Why wasn't this tested?

[DashEvil]

"As I said in my post I was running firefox 0.9.3 on Debian/gnu when I ran the tests."

"So, the whole test, which was meant to take down non-MSIE browsers just puts MS Windows in a bad daylight."

You're right! That DOES put MS Windows in bad light!

Anyone switching to IE now here?

[robotoil]

bet not. :-) Just stop touting Firefox as the end-all-be-all of browsing. Everyone has problems. IE is just the most publicized.

Re:Anyone switching to IE now here?

[Thrymm]

Not switching, I'd rather have a crashed browser than one that allows entry into my system!

Re:Anyone switching to IE now here?

[LO0G]

Your crashed browser just allowed an evil attacker to rootkit your system. All because they tricked you into clicking a link.

Are you still sure you'd rather have the browser crash?

The bad guys don't use valid HTML to attack browsers. They use invalid HTML. That's why Mikal's post is so relevant.

Re:handling malformed data is a pretty bad idea ..

[EchoMirage]

Bad markup shouldn't render.

Well, here's an example of where XML is your friend. XML requires well-formedness in code; if something like an end tag is omitted, the page is not well-formed and is broken. A correctly-conforming XML parser (such as the Gecko engine) will not render the page, but will display an error message.

This doesn't absolutely prevent someone from writing an XML parser that, like HTML parsers, stumbles its way through bad code, but it is explicitly outlined in the RFCs for XML that non well-formed code should not be rendered. (And practically speaking, XML parsers really do have to honor this; by definition it would be nearly impossible to have an XML parser that rendered XML correctly if it was agnostic to well-formedness.)

DOS?

[tepples]

Mozzie failure modes would make for nuisance DOS, not subjigation of your system.

I thought getting a DOS prompt on a remote system through the web browser was subjugation of the system.

this could be bad

[An ominous Cow art]

I think a lot of people are missing the point here. I don't have time to personally verify whether the author's claims are correct; let's assume they are. The type of errors he saw are potentially the type that could be exploited via the tried-and-true buffer overflow method. This is the kind of thing that leads to "execution of arbitrary code", in other words, 0wnage. If Bad Guys craft a apecial web page, they could target those of us who use these non-IE browsers.

In other words, the people who have been defending IE (and Microsoft in general) by saying "your Mozillas and Operas have been safe from security problems only because nobody uses them" will not only have a field day, but now the clock is ticking. There's proof that there are promising means of attack against these browsers. Someone is surely going to research this. I really hope the good guys developing these browsers rise to the challenge and tighten up the code before we (the people who have been recommending them for years) start losing credibility. I'm inspired to look into helping them out.

Sorry if this seems incoherent, I keep getting interrupted as I type this. Stupid work...

Re:this could be bad

[HolyCoitus]

I didn't read into the details on this, but glancing over them they were null pointers. Those are DOS style bugs, not arbitrary code execution. If there were exploits that allowed arbitrary code, I missed it on my glance over. A null pointer is nothing to worry about for some programmers. It's not a good thing, but someplace like Microsoft would not even take the time to fix those. There are countless ways to crash IE. One of them up until recently was doing an input field with the type set to crash. That's just careless.

What browser to use?

[leuk_he]

I am utterly confused what brwoser to use tomorrow.

This is clearly a lot of security problems for mozilla/firefox.
Opera is also not an option since the opera_die clearly is an security breach on opera.

Lynx is an option (limiting the memory of the current session. ) but is ugly.

i.e. has a long history of security problems and that is an important issue not to use it.

Should i use one of the other browsers that is not i.e. based?

This is why we need CHROOT browsers

[freelunch]

Because the complexity and importance of our web browsers continues to increase, security of those applications will never be "solved" or "fixed".

Other steps must be taken to deal with these issues. What we can do is treat the symptoms.

For those using Linux or UNIX, privilege separation (running the browser process as a user ID that has limited rights) and a chroot jail would be major steps forward.

I believe the browser projects need to work with the community to support that type of runtime configuration.. Before a big nasty vulnerability does damage.

Chroot, in particular, is very tricky.

Fault tolerance

[base_chakra]

It's common knowledge that IE is fault-tolerant. So it can render malformed code... wake we when it can finally properly render well-formed code.

Re:handling malformed data is a pretty bad idea ..

[tepples]

It's not exactly what you wanted, but at least this HTML validator extension for Windows or this validator bookmarklet doesn't require an $800 hardware key.

Re:handling malformed data is a pretty bad idea ..

[Finuvir]

Ther are no exceptions to Postel's Law.

Re:handling malformed data is a pretty bad idea ..

[tepples]

Well, here's an example of where XML is your friend.

Not if you're trying to maintain compatibility with the 94-percenters. XHTML doesn't work in IE. Send XHTML with the proper Content-type: application/xhtml+xml and you get a Save As... dialog box; send XHTML with text/xml and you still don't get access to the HTML DOM.

Bah

[JMZero]

The fact that it does crash some browsers indicates that they probably are trying to run part of it as code

No, it doesn't. Not at all. For example, if I feed the program "i=i/x" the number "0" for x that program may crash. But that doesn't mean the 0 was executed as code or something.

There are many ways of crashing on bad data that don't point to this kind of security problem. In order for a malicious exploit, you need to get bad data in just the right place - in a place where the address of some legitimate code is stored, and where that address is going to be used. You then need another fairly certain location for the exploit code you can point to.

Sometimes a crash does point to a vulnerability like the above (usually do to stack return addresses). But often not. And suggesting that all crashes point to some execution of data is just wrong.

Re:This is known

[Pieroxy]

I understand your point, but are you sure you replied to the correct post? This has nothing to do (if anything) with what I said in the parent...

My point is to rebute the argument of the grandparent which assumes that rendering well broken HTML and not crashing on broken HTML is completely dissociated...

Umh...

[vidarlo]

Crash IE! Citing from the source:

<html>
<form>
<input type crash>
</form>
</html>

That is fairly close to valid HTML IMO...yet IE crashes. Time after time.

But it shouldn't crash out, either!

[EnglishTim]

Firefox crashes out on me once or twice a day, taking not only the page it was rendering but all the other tabs I had open with it.

Sure, perhaps malformed HTML shouldn't render. But I'd much rather it rendered than crashed the browser, which is bad.

Plugins

[phorm]

I used to have Firefox crash and burn regularly on various webpages - linux and windows. The browser would segfault and be gone, sometimes without visible errors

Eventually I noticed it seemed to be mostly with pages having Flash content. I ended up nuking my plugins folder and reinstalling the flash/Java plugins, now it crashes a lot less.

While the article indicates it is possible to crash on bad code, you might want to check your plugins too just in case.

Testing by random input is not new...

[cayle clark]

...I first read about it in this CACM article (v33#12, Dec 90). The authors generated random text strings and fed it into UNIX utilities, producing a variety of entertaining crashes and lockups.

"A good portion of the paper discusses common mistakes made by programmers that caused the utilities to fail..." want to bet they mention buffer overruns? (sadly, full text requires ACM membership)

Re:handling malformed data is a pretty bad idea ..

[drew]

now watch as all the browsers implement this, and millions of geeks around the world scream because they can no longer read slashdot.

I hate propoganda

[coshx]

Come on guys, this is so obviously propoganda. The guy spends a month trying to find a way to crash mozilla, when it took me 2 minutes on google to find a way to crash IE:

http://www.meyerweb.com/eric/thoughts/2004/09/14/t en-things-to-do-in-cleveland-before-youre-dead/

-ben

I love random input

[John Jorsett]

I did much the same to test a user interface written by another programmer on a project we were assigned to. The interface wasn't a gui, it was a pure ASCII type, so I wrote a random character generator and threw the output at her interface for days at a time. Crash. Crash. Crash. It was wonderful. I don't know that it found every flaw, but I'll bet no one ever killed her interface by leaning on the keyboard (as actually happened on an earlier project I'd heard about).

Re:I love random input

[ggeens]

This story was told by a couple of friends:

They were taking a programming class, and they had a lab exercise. After the first person had finished, they called in the teacher for their quotation.

The teacher sits down, and starts whacking on the keyboard. Pretty soon, the program crashed and the teacher left the pupil to recover from the shock and fix it.

After a few assignments, the pupils started to "gorilla test" their programs themselves.

IE Good for Clients, Bad for Developers

[Anonymous Coward]

I ran into similar issues with IE ignoring stuff and Mozilla catching it a few years ago when I was developing one of my first web applications with servlets. Mozilla was a great browser for testing my web apps during development. I remember I had a bug in my code that was supposed to populate a dropdown with options from a database but instead choked somewhere in the model layer and populated it with a bunch of breakspaces. Mozilla would show me the space characters in the dropdown where IE simply ignored them and pretended like the dropdown was empty.

It's a real pain in the neck for IE to not try to show what's actually there because when I first looked at the page in IE I assumed that I just wasn't getting what I wanted from the database since my dropdown was empty. In reality it wasn't empty, IE just didn't want to show me 1000 breakspaces as an option in my dropdown which is bad from a developer's standpoint. However, masking and hiding bad code and data is something that I absolutely want a browser to do when the application is out in production being used by my clients.

The bottom line is you should always develop your web applications with a browser like Mozilla that is going to catch your mistakes but once your application is out the door it's better for clients to be using a broswer that will hide any mistakes you didn't catch!

First impression == cool

[sloth jr]

While I'm not thrilled that the browser I use seems to have some egregious problems in its parser, I feel Larry's done us (free software community) a huge service by providing us with the tools that highlight those areas that need improvement.

sloth_jr

You should all be using the standard Web Browser.

[Anonymous Coward]

NSCA Mosaic successfully survives all of these pages. This just shows that programmers these days Just Plain Suck, and Mozilla is the living embodyment of this.

There's no good reason that code should be vulnerable to integer or buffer overflow issues like this.

Re:This is known

[Stephan Schulz]

As for allowing sloppy HTML, that's a problem if you think the primary purpose of a browser is to enforce HTML standards rather than display web pages.

Well, a browser should display web pages. However, a string of broken HTML is not a web page, but rather some random data send out by a web server in response to a request. The problem with displaying broken pages is that it waters down the standard and erects artifical barriers to entry in the market. You cannot just implement the spec, but you have to copy all the quirks of your competitors. Fine if you have a near-monopoly, but not good in general.

Would you accept 6mm nuts for 8mm screws? After all, the primary purpose of the shop is to sell you stuff, not to enforce the standard...

Smackdown

[d_jedi]

It appears that the overall quality of code, and more importantly, the
amount of QA, on various browsers touted as "secure", is not up to par
with MSIE; the type of a test I performed requires no human interaction
and involves nearly no effort. Only MSIE appears to be able to
consistently handle [*] malformed input well, suggesting this is the
only program that underwent rudimentary security QA testing with a
similar fuzz utility.

So.. maybe Microsoft code isn't so bad, after all? Let's see the spin on this from the MS-is-the-devil crowd..

This is why I still use IE

[SnprBoB86]

I still use IE because IT WORKS. Sadly, IE may not be the most standard compliant browser, but very few web pages are standards compilant. Firefox and mozilla and whatever are al cool, but many sites (particuarly those with non-technical submatter :-P) just do not work as intended outside of IE because they were built for IE.

Did IE really not crash?

[divad27182]

I have to ask:

When saying that Microsoft Internet Explorer didn't crash, does he mean that the window never went away, or that the program iexplore.exe stayed running? I can't prove it, but I suspect that the "IE" window would survive a crash of the rendering engine, because the window is actually provided by explorer.exe, which is the desktop manager.

I also suspect that several of the open source browsers could defend themselves against this kind of crash within a day or two, simply be using a two process model. Personally, I would rather they did not! (I want to see it fail, otherwise I would not know something was wrong.)

Re:Did IE really not crash?

[The Bungi]

You need to inform yourself a tad more. You sound very authoritative and I'm sure the mods agreed, but you're wrong.

iexplore.exe provides the process, mshtml.dll provides the rendering and the shdocvw library provides the COM glue. IE has nothing to do with explorer.exe, which is the default Windows shell *and* the actual file explorer application. The shell can use the renderer and the glue library to show "web folders" and all that stuff, but it doesn't need them. Quite simply, IE would not run if you were using an alternative shell like Geoshell or BB4Win, and that's not the case. You can launch iexplore.exe and never see a single instance of explorer.exe loaded anywhere in your system. IE and Explorer do share DLLs (like the Common Controls and so on), but those are system libraries, not specific to either of them.

Re:Did IE really not crash?

[divad27182]

You are correct that my information was a bit off, but I suspect the idea wasn't... My apologies if I "sound very authoritative" when I am not.

It seems iexplore.exe does indeed provide the process, along with (at least) the crash handling, adding the text " - Microsoft Internet Explorer" after the web page title, and apparently varies some of the preferences (displayed toolbars at least). It does not seem to affect the rendering of the page, as either iexplore.exe or explorer.exe can do that.

My thought was that the rendering engine may be crashing, without causing the complete application to crash, and without appearing to have crashed. I will stand by that idea. It seems quite plausible to me that every request to render a page might kill any previous thread readering for the window, and start a new one, and this could quite successfully hide rendering engine failures. Other techniques could also mask rendering engine failures.

I guess I really have no idea how one would authoritatively detect if the IE rendering engine has failed. Does anyone?

Re:Did IE really not crash?

[The Bungi]

Since the renderer is a library mapped into the process space of the application that hosts it, a memory exception should bring it down, except if the library itself is preventing the exception to bubble up that far.

It's fairly easy to test this since you can always host mshtml somewhere else (as an OCX on a VB/VBA application for example) and see if you can make the hosting process die. It's possible that the iexplore process has an application exception hook eating up stack or heap corruption scenarios, but again you could prove or disprove that easily.

Of course it might be simply that the renderer does not crash because it's written that way, and the process never sees any exceptions because there are none.

Re:Did IE really not crash?

[m_pll]

It seems quite plausible to me that every request to render a page might kill any previous thread readering for the window, and start a new one, and this could quite successfully hide rendering engine failures.

I'm pretty sure IE doesn't do this. The reasonable thing to do is to let the application crash so that users can submit a crash report, and the problem can be fixed. Trying to continue execution after unhandled exceptions usually leads to undebuggable hangs.

I guess I really have no idea how one would authoritatively detect if the IE rendering engine has failed. Does anyone?

Run the process under debugger.

Re:handling malformed data is a pretty bad idea ..

[danila]

Of course, what I just wrote only really applies in a heterogenous environment

Wrong. This only applies in a homogenous environment where you can force everyone to write good HTML and force every application to ignore bad HTML. In the real world every developer and web-developer makes his choice. And it just so happens (by virtue of natural selection) that for browser-developers it makes most sense to write code that understands bad HTML. This way their product works better, users are happier and their browser enjoys the 90% market share. Microsoft is not evil (in this regard), they are just being rational.

Another way of looking at it....

[toolz]

I wonder how much of IE's "stability" is because of good code and good parsing, and how much of it is due to the fact that IE didn't *know* it's eggs were scrambled?

It wouldn't be the first time that a program went on "running", only to *eventually* go out to lunch and not come back.

At least the others *noticed* that something was wrong - and died.

OK - now lets see how long it takes to get fixed!

[strags]

Every sizeable project is likely to have bugs - fact of life. What's going to be really telling is seeing how long these problems take to get fixed as compared to the average MSIE exploit.

Re:An important security sidenote:A Mdk 10 Crasher

[davidsyes]

I watched "Moon Child", the VCD verison, and BOTH times when Xine reached the end of the VCD, as the last of the credits rolled, the entire laptop locke up.

Nothing worked, not even ctrl+fn+someletter would work. I am an avid Lxr, and I only use win98 inside Win4Lin, but last night I even had that off, I reniced MySQL to something like +15, and at one point reniced Xine to -9 or -10 before shutting it and restarting it.

However, I was off-line, and did not even have Firestarter nor Etherape running, so my CPU is not being overloaded. I do notice, unrelated to Xine, that running Win & in X4ce starts MUCH faster (as when KDE is FRESHLY run) than currently in KDE. I imagine one of my hidden dot files or authority or temp files is trashed, or maybe something in a win4lin path is hozed. Maybe my box has been cracked weeks ago. I dunno. Have to check my logs.

However, I accept that xine is .9.x release, and has not normally done this on other DVDs or VCDs I've watched. Just with Moon Child, the Japanese version with English & Jpns/Chns subtitles. Periodically, after taking 10 screen snaps with Xine's camera icon, Xine would just disappear. I'd then have to stop Alsa, by running /etc/rc5.d/S17also force-restart

And if Xine was alive at that point, the force-restart would kill it dead.

I know this is not exactly along the lines of browsers, but if VCDs and DVDs are being watched while a user is on-line, who knows if a batch of bad code is being fed to the userspace tools? Who knows if other compromises already on the box are aggregating to worsen things with a new breach's arrival. Fortunately, I prefer to yank my ethernet anytime I'm not surfing. I tend to yank my bband router, too, to keep its visibility low.

New Technology...

[hackwrench]

The Internet can be accessed just fine (spyware, viruses, and worms aside) with a Pentium 100Mhz computer. Windows XP cannot be installed on such a machine.

Re:New Technology...

[hackwrench]

No, properly configured it isn't. I know this from experience.

There's also "ntcrash", but Microsoft killed it

[Animats]

There's also "ntcrash2" which generates random Win32 calls. It saves what it's doing in a file, so when you crash, there's a record. After the reboot, it starts up again, avoiding all recorded crashes in its log. Microsoft was very upset about that.

That's not even a very tough test. A tougher test would be to generate calls which are permuted slightly from valid ones.

and safari didn't crash either

[EXrider]

and safari didn't crash either

and I can show you a site that crashes Safari reliably... http://www.wingimp.org/

that explains it

[kumar303]

no wonder IE is so slow compared to other browsers.

The thing about standards...

[Anonymous Brave Guy]

Just to be clear, unparseable XHTML is not XHTML. In "Matrix" terms, there is no web page.

Just to be clear, the user doesn't care. In "user" terms, there is a web page, and a browser that fails to render it is broken. This is intensely annoying to those of us (and this includes me as well as you) with technical mindsets, but it is true nonetheless.

I'm well aware of the nature of XML, and what the standards people would like to have happen. I'm also well aware of how frustrating it is to run a web site that has to work in browsers that's don't support the standards; I maintain a large site myself using XML, XSLT, HTML and CSS amongst other buzzabbreviations. However, the simple fact is that in the real world, standards are simply a means to an end (or not). If you're writing software for users, then the user experience is all that matters. Anything else -- standards, security, UI, file formats, whatever -- matters only to the extent that it affects the user experience.

As an interesting aside, you might like to read the AC reply to your previous post as well, and note that in fact C compilers do frequently have to deal with not-quite-right code because C programmers, like web developers, make mistakes.

Let firefox crush... leave jpeg's to MSiE

[deamonius]

Unfortunently for Mr Larry Osterman the www today is consisted of really "we formed html + more) code and the randomly mallformed pages are very few in number. The fact that MsExplorer does not crash on mallfomed code cannot by itself cannot make me feel secure and switch for example from firefox to MSiE. The problem out there today is that there are very carefully crafted sites,scripts,"applets" (not to mention even jpeg's) that are waiting to be rendered REALLY succesfully by our "trusted" MSiE and noone else. So I am waiting fom my firefox to crash on a randomly mallformed site and I leave all the succesfull rendering of all the "other" sites to MSiE

Why not use a boundary check?

[crovira]

I find it amazing that anybody puts bytes in a buffer without doing a boudary check.

There is more than enough CPU power to do it and it would dispose of entire classes of attacks.

Re:Why not use a boundary check?

[CTachyon]

That's actually the point of all this buffer overflow protection. The programmers *should* have used a boundary check, but they forgot to, and now there's a security hole because of it, so now the OS, processor, and compiler are trying to limit the damage caused by a forgetful programmer.

Some genuine flaws in Gecko for unbelievers :-)

[Anonymous Brave Guy]

OK, a lot of replies to my post have been the usual defence of Moz. I understand that; most of us are fans, and like many of you I use Firefox myself. But really, I didn't mention the margin hack and I didn't mention pages that browser detect. Gecko is quite capable of messing up perfectly standards-compliant pages in its own right.

For example, try playing with HTML+CSS pages and working with list tags. Try it particularly while you're working with block elements, floats, etc. You can easily get things like bullet points for unordered lists floating off the left of the containing box -- clearly not the intent of CSS standards. Trying to use an in-line format for lists rather than the usual vertical arrangement is a road to ruin as well. To their credit, they are getting better, but there are plenty of examples like this where IE does get it right and display a page sensibly, while Gecko's display is at best unpleasant. If you're going to give a point to Moz/FF for getting the box model right, you really have to give a point to IE for understanding elementary CSS when applied to lists.

Although we're talking about HTML specifically in this thread, there have been plenty of problems with XML/XSLT in Moz/Firefox as well. Simple XSLT elements for things like counting just didn't work properly for a long time, which meant those of us who really wanted to use XML+XSLT+CSS for Intranet sites and ditch HTML altogether couldn't if we used Moz (though IE can count, apparently) and had to use some intermediate step to generate (X)HTML that Moz could render properly instead. Again, to their credit, I think the dev team fixed this specific XSLT issue a little while back now, but it was outstanding for a long time.

Those are two concrete, and quite wide-ranging, examples where IE is clearly superior in how it renders the page, according to W3C standards, to Gecko-based browsers. Some web pages do work properly with IE and don't work properly with Gecko, even if they are completely compliant with W3C standards. Can we just learn to workaround the box model flaw like everyone else and play nice now, please? :-)

Re:Some genuine flaws in Gecko for unbelievers :-)

[bunratty]

OK. I'll ask again. Can you give a specific, concrete example of HTML or XML that renders properly in other browsers that doesn't in Mozilla? An example means typing out the code that demonstrates the problem. All you gave was a vague set of directions for generating code that demonstrates the problem. That is not an example.

Re:Some genuine flaws in Gecko for unbelievers :-)

[Anonymous Brave Guy]

No, sorry, I can't produce 50 lines of standard HTML+CSS off the top of my head that demonstrate each problem. However, in the time it took you to post that comment, you could have found bug reports for both the issues I mentioned in Bugzilla. :-)

(Being serious, pretty much any use of xsl:number used to confuse the XSLT generator when formatting was involved, and I think any use of unordered lists in combination with floats currently leads to the bullet points off the left margin problem.)

Re:Some genuine flaws in Gecko for unbelievers :-)

[bunratty]

I found bug 57882 which describes a situation that causes Mozilla to not render a page as well as IE. However, I can't find a case where Mozilla's rendering of HTML causes a page not to work, as you originally described. Can you give just one example of this?

Re:Some genuine flaws in Gecko for unbelievers :-)

[Anonymous Brave Guy]

However, I can't find a case where Mozilla's rendering of HTML causes a page not to work, as you originally described. Can you give just one example of this?

I don't know what you mean by "not to work". Are you talking about only crashes, and ignoring unacceptably bad user experiences or something? If you're talking about poor rendering, there are several examples in this thread at least as bad as the oft-cited box model bug in some versions of IE, and you need look no further than Slashdot, which regularly gets reports of massively incorrect rendering because of layout bugs. Or are you going to argue that the HTML is malformed and it's not Mozilla's fault, even though on a refresh or size up-size down, Moz renders it just fine? (Before anyone jumps in, I know steps are being taken to fix this, but it's been irritating loads of people for months so I think it's a valid example.)

I provided two scenarios where there are serious bugs, you're reading a site which exhibits a serious problem itself from time to time, and two minutes in Bugzilla searching for words related to those scenarios will find you several specific test cases. If that doesn't make the point well enough, then sorry, but I'm not going to waste ten minutes generating a whole HTML page and stylesheet for you.

Re:Some genuine flaws in Gecko for unbelievers :-)

[Anonymous Brave Guy]

I give up. Here you go.

Meanwhile...

[tsarin]

100% valid CSS and XHTML continues to crash IE.

This "random" test is dangerously incomplete.

[WebCowboy]

It mentions there is no scripting or stylesheets in this test--just random HTML tag soup. So yes, there was a very defined, arbirtrary range established. The results are disappointing for IE competitors for sure, but given IE is at major release SIX and at the end of its life cycle, while the likes of Thunderbird are for less mature (barely at 1.0 and at the early stages of its life cycle) I would expect and demand no less than perfection from IE.

Given the arbitrary limits on this test, it appears to be designed specifically to make IE look better than its competitors and prove some point rather than be an objective investigation. It is well known that the most serious problems in IE are with scripting and CSS support being unstable, broken or incomplete. A similar test should be conducted of IE should be done with these included. Kudos to the author of the bugtraq entry for doing this kind of testing, but I don't think the editorial commentary regarding the amount of testing of these browsers or their attention to security is warranted or productive.

The author freely admits he did not seriously analyse the source code for the root cause of these crashes (and in the case of IE, he cannot do so even if he wanted to--but that doesn't stop him from proclaiming it as superior quality). He also provides no evidence that these bugs compromise security in any way beyond consuming system resources, so it was not exactly appropriate to attack their security abilities without further study.

As to the jibe about lack of testing...Many of these alternatives are open source projects, not yet at official 1.0 release yet people! Being open source, the whole point of exposure is to get many eyes looking at the code, and get people involved in improving the code. He seems to know a great deal about programming so I suggest he volunteer some of his spare time to the Mozilla project to make things right, if he is indeed THAT concerned about the issue.

Re:This "random" test is dangerously incomplete.

[KarmaMB84]

Isn't Firefox using the mature Mozilla rendering engine?

Re:This "random" test is dangerously incomplete.

[abradsn]

ie is just plain better at this sort of thing. run the test yourself, or create your own. It's obvious.

Re:This "random" test is dangerously incomplete.

[Mordanthanus]

Oh please...

I am so tired of this crap. Someone ran a test and IE came out on top. Now we have people ranting that IE is a more mature product and has had a lot of stuff fixed over time (which is true). And all the open source products are still young and bugs are still being found and fixed by all the coders out there.

If this test had come out showing IE as the worst and all the others passed, there would be an MS bashing frenzy going on now talking about how all of the open source products are so much better and that is what MS gets for keeping closed source and how Billie Gates deserves herpes... etc, etc, etc.

I say it is about time that MS finally got their crap together and started making their product more secure. I say it is about time someone at MS got a fscking clue. And I also say it is about time MS started getting credit for trying to do so.

Just MHO.

Re:This "random" test is dangerously incomplete.

[Tetch]

> Given the arbitrary limits on this test, it appears to be designed specifically
> to make IE look better than its competitors and prove some point rather
> than be an objective investigation.

It sounds like you have little idea who the author is, or you wouldn't make such a statement. Michal Zalewski is a well-respected security researcher, with impeccable credentials, and no particular love for Microsoft, who's made an undeniably valuable contribution in many areas of IT security.

While he generally seems to work on Unix-like systems, he has also published work on M$ software security problems - e.g. http://www.bindview.com/Support/RAZOR/Advisories/2 001/adv_mstelnet.cfm
http://news.softpedia.com/news/2/2004/April/7797.s html
http://cert.uni-stuttgart.de/archive/bugtraq/2000/ 06/msg00066.html

A quick google will repay your time.

Give the guy some credit - it seems he's uncovered a surprising lack of robustness in non-IE browsers - and admittedly an even more surprising degree of resilience in IE's handling of the HTML tag soup he played with ... strange but apparently true :-)

What they forgot to mention...

[lone_knight]

'All browsers but Microsoft Internet Explorer kept crashing on a regular basis due to...'

Did they forget to mention that IE didn't appear to crash any more than it normally does, regardless of malformed HTML?

Not a problem with Konqueror

[Xerp]

Ran test on mine, coz I was bored.

Didn't see a problem with Konqueror 3.3.0. I had a look at all the files in the pretty gallery and ran the cgi thing for about 15 minutes before getting bored of watching random stuff.

Top marks KDE team. r0x0r

Gaelon 1.3.15 survived for the 15 minutes of the cgi thing I could be bothered with again, but died on the gallery stuff.

Bad Gnome. sux0r

Yes, I know 1.3.15 is oooold. I don't update my Gnome stuff for a reason. Seems I have another reason now.

In other news

[Raunch]

I took sandpaper and scraped it all over several media, including VHS, DVD, CD, Betamax and Vinyl.

The VHS and Betamax performed much better than the others, particularly of note was the DVD, and CD. They failed miserably.

Re:This is known

[mdfst13]

"My point is a browser that runs bad HTML code implies bad programing methods."

If Firefox, et. al. simply refused to render the page (i.e. said "HTML too ugly" and showed a blank page), that would be fine. That's not what they are doing. They are *crashing* on bad data. A program should never crash on bad data (no matter how bad); it should generate some kind of exception and take appropriate action.

To put this another way, Firefox is not recognizing that the data is bad. That's why it's a security hole.

Lynx gallery example

[lahvak]

Tried the gallery examples, firefox crashes reliebly, links does too (from the error messages it looks like they actually catch the NULL pointer - it says "malloc returned NULL pointer" - but don't react to it)

However, I was not able to crash lynx with the example. It takes a while to render the page, but it renders it just fine (considering it is actually invalid HTML). Perhaps it depends on the amount of memory you have.

If I remember correctly, while ago there were rumors being circulated that IE is specifically designed to deal well with invalid HTML. Lot of people were of the oppinion that it is really bad, and that invalid HTML code should be rejected. Thay said IE basically encouraged sloppy web design.

Didn't work for me...

[conebrid]

...when I tried it in IE. Although, several other links given did work, and IE crashed.

IE has its flaws

[the_womble]

I suspect that like MS's security holes, IE's crashes are worse than thsoe of rivals: try using OBJECT to embed a webpage in itself for example.

I use Safari, but I hate it

[grikdog]

Internet Explorer has a well-deserved reputation for working well on nearly every web page that matters - i.e., those involving the exchange of money. It's only its abuse in monopoly practices, i.e., Microsoft's absurd attempt a few years ago to shackle a simple web browser to OLE and ActiveX "standards" the world rightly sneers at, that makes my hackles rise. If the devil is a woman, Internet Explorer is her browser of choice, and would be mine except that Apple ties "security" to the use of Safari, a vastly inferior product imho.

Re:Tip of the iceberg

[c.ecker]

Oh so very, very funny ... thanks for taking the time to post that AC.

tried the cgi link

[lahvak]

...with all browsers I have installed on this system.
Sat there with IE for about 10 minutes, firefox for 2 10 minutes periods, lynx for about 5 minutes, hitting the reload button over and over, approx about ever 1 - 5 seconds, depending how fast did each page load.

No crash in IE or firefox. No crash in lynx, either, hanged lynx after 5 minutes. I didn't have time to wait and see if lynx eventually comes back (in the gallery example, lynx didn't actually go into an infinite loop as the site claims, it just took about 10 minutes or so to render the page).

Crashed links almost immediately every time I tried it.

As far as I can tell, both Firefox and IE handeled it pretty well, considering the garbage being thrown at them.

Safari crashes just like everything else.

[jelwell]

This is simply a misunderstanding of the article (no offense). The examples are specific outputs of a random machine. The outputs in question happen to kill the browser the file is named after. So by testing the html pages that are presented you've missed the beef of the article/posting, which is the random machine that came up with those specific html pages.

The true test is to download the man's application mangleme.cgi, install in on a server, and then point Safari at it.

I have done this and Safari (1.3 developer release) crashes quite quickly.

So does IE 5.2 for the mac.

As a side note. Netscape/Mozilla has had something, similar, but not quite the same as this for some time now. Called Browser Buster. It did not generate random html, but did continuously feed real websites, chosen somewhat at random until the browser crashed. I remember we used to have goals, like "last 24 hours on browser buster".

Joseph Elwell.

wow

[jmank88]

sooo, basically, Every browser cept IE crashes when they are forced to, but IE is the only one that crashes when it is not supposed to...sounds like this study only makes IE look worse... -jordan

Another test this guy could do.

[cjellibebi]

Another test he could do is to report all the bugs he discovered that he can recreate on demand to the team that writes the browsers, and see which team comes up with a fixed version the fastest.

Won't happen any time soon

[Anonymous Brave Guy]

Make some noise. Get the problem noticed. If it's a commercial site, and they start believing they're losing customers over it, then they might take notice. Or they might lose you as a customer.

<business manager>

<shrug/>

Some customers are worth losing. I'd rather spend my limited budget in a way that appeals to 95% of the visitors to my site.

</business manager>

I agree that it would be nice if web sites were all written according to standards and all worked in any browser. But right now, the world doesn't work that way, and expecting businesses to adopt some sort of moral stance on this at the expense of potentially vast sums of money is unrealistic.

Results in IE 5.00

[Reziac]

I just checked all the "free samples" against IE 5.00.2314.1003c (the Win2K team's internal build, and the only IE version that I consider halfway decent). It dates back to late 1999. My copy has NOT been patched.

NONE of the samples crashed my IE5.00.

mozilla_die3.html *did* cause IE5.00 to ask to access the internet (per ZoneAlarm's popup); from the simple HTML involved, I don't see why that happened, so I consider this response a security issue.

Otherwise the worst result was a really stupid looking text entry box (about 1/8th inch wide and half an inch tall).

If something like this breaks the browser...

[rush22]

...then someone is too stupid to write a parsing engine.

But what do I know. I'm sure I'll get flamed for saying that anyway. ("duh there's a NUL pointer!" You mean character 00? So what?)

Hey, at least...

[inode_buddha]

At least a browser crash won't lock up my OS or overwrite other portions of memory. Lesser evils and all that.

Why not use a separate return address stack?

[GrahamCox]

Clever, but surely the reason such buffer overruns are dangerous is because RETURNS are executed out of the same stack. Keep those addresses in a separate stack and the problem goes away. I can't see why CPU manufacturers don't do this, they would have a great marketing tool too - "use our processor and stop viruses!". It's this mix of code and data on a stack that is the root cause of this type of exploit, and seems to me it could be fixed very easily.

Re:Why not use a separate return address stack?

[CTachyon]

Yes, return stacks eliminate the direct problem. They add some overhead, debugging is a bit more complicated (harder to figure out where all the pieces of a function's frame are), and there's still some risk because other local variables to the function can still be overflowed, which might trigger insecure behavior, and saved registers from the calling function can be attacked as well. Overall, though, they do mitigate the problem quite a bit. The biggest stumbling block in implementing them is trying to allocate memory for two growable stacks that can't be relocated at runtime. The current approach is to have the stack grow downward from the top of memory, and have the heap grow upward from the bottom. Two stacks would break this compromise, which would mean a return to hard limits on the maximum depth of recursive functions.

Safari survives, Camino does not

[mistermoonlight]

Safari 1.2 for OS X 10.3 does not crash, Camino 0.8.1 does. Helloooo, TalkBack.

Different to what I expected

[Ed Avis]

I remember the old reliability test of Unix commands which showed that GNU versions were much less likely to crash or do odd things when given random or pathological input. I would have expected the same sort of results with free web browsers. Still, well done to Microsoft for making their HTML parsing code robust against this kind of bug.

That's great but...

[Game Genie]

It's too bad it can't deal with properly formed html.

Reflects badly on ALL sides

[TiggsPanther]

My first thought on this was "IE renders bad code that other Browsers choke on" which isn't exactly unkown to me. So I'd hardly say that the report really reflects all that well on IE. I've seen things before that although they didn't cause other browsers to crash they did render wrongly under anything other than IE, whereas IE just happily skipped the problem and rendered it the way that the author was expecting despite the bad code. So I'm not exactly thrilled that "Bad code doesn't crash IE", as it's a symptom of anotehr problem.

Having said all of that one thing that I've believed about Browsers is that they should fail gracefully. Kinda why I hated NS4.x and CSS. At least other non-CSS-compliant browsers would straight-render my old pages - Netscape just mangled it.
So from the looks of the article it seems that the other browsers aren't exactly handling the bad code is a very good way. If badly coded stuff causes a page to bomb-out then it's definitely a flaw.

Like I said, though, no side really comes off best here. 'Cos it means either your browsers dies on particularly bad code, or it renderes bad code "perfectly" and thus causing problems when "Well it runs fine on my Browser" is the only method of testing.

Firefox...

[WebCowboy]

...does use the same gecko engine, but it was written from scratch at a time that IE was already quite mature.

That said, there now seems to be a fire burning under the butts of team Mozilla, so expect things to be fixed rapidly.

Thanks for the info...

[WebCowboy]

It's comforting to know that his intentions are good--to make sure we simply get better software.

It's good to see that MS has removed the "crash" tags from IE's "feature list" and that tag soup will no longer kill it. It shows that MS is actually being serious when it says that it hasn't abandoned IE.

That said, I really hope Zalewski conducts a similar test involving scripting/DHTML/CSS. To this day I don't have to try hard to make IE barf on that stuff. In those cases the problem is even more insidious in IE--it doesn't crash much but it does mangle the document appearance. For example, IE makes things invisible when they should be visible onscreen, but they still behave like visible objects programmatically, etc. CSS is very strange in IE in particular...

Re:This is known

[ClosedSource]

"Would you accept 6mm nuts for 8mm screws?"

A better question is "Would you prefer a product that can accept 6mm nuts or 8mm nuts for an 8mm screw?"
MS isn't selling HTML.

better the browser crash than allow exploits

[konmaskisin]

... the reason IE is so exploitable is that it swallows anything without crashing ... right away.

A concrete example, with HTML+CSS

[Anonymous Brave Guy]

Enough already. If "I think any use of unordered lists in combination with floats currently leads to the bullet points off the left margin problem" isn't clear enough for you to try it out, you guys really aren't informed enough to be in this conversation. Still, just for you, here's a trivial example that obviously breaks in Firefox up to at least 0.9.2. Just add clutter to turn it into the standardised HTML version of your choice...

<HTML>
<HEAD>
<TITLE>Demo of a page Firefox gets wrong</TITLE>
<STYLE>
.floated {
margin: 0;
float: left;
width: 100px;
}
.main {
margin: 0;
}
UL {
list-style: outside;
}
</STYLE>
</HEAD>
<BODY>
<P>Norm al text</P>
<UL>
<LI>First item</LI>
<LI>Second item</LI>
</UL>
<P>Normal text</P>
<DIV CLASS="floated">Waffle waffle blah blah waffle waffle blah blah</DIV>
<DIV CLASS="main">
<UL>
<LI>First item</LI>
<LI>Second item</LI>
</UL>
</DIV>
</BODY>
</HTML&g t ;

Rather embarrassingly, it also breaks Slashdot's <ECODE> tag. :-)

Crashing on Bad Input != Error Handling

[billstewart]

no, no, no. Crashing is not error handling, and crashing is not strict HTML handline, crashing is LACK of competent error handling. Rendering incorrect pages liberally _is_ better than crashing, though error handling would be better.

Re:Crashing on Bad Input != Error Handling

[ClosedSource]

I assume you meant to reply to metlin instead of me. I agree with you (as my other posts in this thread indicate).

Is HTML Turing-complete?

[farnz]

The halting problem is only provably unsolveable for Turing-complete languages; if HTML isn't Turing-complete, it's entirely possible that you can prove that a given HTML input will or will not halt.

JavaScript is Turing-complete, so if your HTML includes JavaScript, you're doomed, but I believe that HTML and CSS are not Turing-complete, so it should be possible to prove that a given HTML input can be rendered.

Re:Is HTML Turing-complete?

[DunbarTheInept]

In theory, yes. But in practice, where computers do not have infinite memory or infinite time to finish a job like a theoretical Turing machine does, there is often no relevant difference between "this loop is guaranteed to end after 10 billion iterations" versus "this loop is infinite". HTML does have guaranteed endpoints to its "loops" such as they are (i.e. "please make me a table with 10,000,000 columns" essentially results in a loop even though it isn't expressed that way), but there is no rule for what the max cap should be. A renderer that actually tried to make a 10,000,000 column table would crash for lack of memory or time, even though it is in THEORY, a finite task that it is being asked to accomplish.

HTML limits

[farnz]

However, with HTML, you can just render the slice that's visible to the user, rather than the entire document. Thus, assuming displays are of finite size, you can bound the complexity of the render engine.

Re:HTML limits

[DunbarTheInept]

However, with HTML, you can just render the slice that's visible to the user

Yes, but you must still calculate it out some aspects of what it would look like even when you don't render it - for justification purposes. Consider if elsewhere on the page there is some center-justified text - you still need to calculate how wide the table is to determine where that other text gets rendered. Also consider the request for a 10,000,000 column table that is width='100%' - it is shrunk down to whatever the window width is - attempting to render it would result in a solid black bar since the screen pixels aren't dense enough - what would the correct solution be? The correct solution would be to heuristcly guess that the table is unrenderable, and not attempt to do what was requested exactly as requested (either by not honoring the request to make it 10,000,000 columns, or not honoring the request to make it width=100%.)

Re:HTML limits

[farnz]

You're not arguing my point here; because HTML is not Turing-complete, and because it is appropriately defined, a renderer can determine in finite time (probably quite short) that a particular HTML file renders outside of its limits; it can then handle this sanely.

To take your table example; you know that your windowing system limits windows to a maximum width (32-bit unsigned int, for example). Any table with more than that number of columns is automatically replaced by an appropriate marker.

Unlike with Turing-complete languages, there is no need to guess whether something is possible or not; whether it is renderable can be determined in O(size of HTML file) time. This contrasts with (say) executing Perl; there is no way to determine whether a given Perl program will terminate.

Re:HTML limits

[DunbarTheInept]

You're not arguing my point here

Then we're even. You're not arguing mine. Go up and re-read the thread to this point. I *already* had stated, even before you brought this up, that the way the problem is probably being solved is that IE is denying valid HTML that it knows it couldn't handle anyway - just like you're saying here. This is no different than, say, writing an interpreter for Perl code that knows the target machine archetecture can't have more than 64 Mb of memory, or can't stay running more than 1 hour at a time, and uses that knowlege to cut off Perl code that would otherwise have been 100% finite and might have completed if the archetecture was big enough to handle it.

The way the halting problem is being solved is by having the interpreter make use of the limits of the environment. It's the limits of the environment that break the problem moreso than the limits of the language.

We both agree that the limitations make it not a truly Turing-complete situation. But you're saying it's because of the HTML language not being Turing-complete, while I'm saying it's because the environment isn't an actual turing machine, in that it isn't infinitely capable, and the interpreter is what is using that to cut off the problem, NOT the language itself.

Re:HTML limits

[farnz]

You've misunderstood again; a Perl interpreter can't know that it needs more than 64MB to run a program, or that a program will take more than an hour to run without trying it, and cutting it off when it hits a limit. In contrast, a HTML renderer can examine the HTML it's presented with, and determine relatively rapidly (and in less than 64MB) that it will take more than 64MB, or more than an hour, without attempting to render the page.

Because HTML is not Turing complete, it is possible (and in fact manageable) to take a random chunk of HTML, and determine whether you will hit any arbitrary limit; doing so will not get anywhere near that limit. Because Perl is Turing complete, the only way to determine if Perl code will hit a given limit is to run it, and abort if the limit is reached.

Re:HTML limits

[DunbarTheInept]

No, you're not getting it. Even if it was fed a perl program with no looping, that was thus not turing-complete and finished in a single pass, a perl interpreter STILL could not predict accurately whether or not the program will use too much memory becuase the target environment has unknown limits that move dynamically. (There are 32 Mb free right now. Two seconds later there might be 120MB free, two seconds after that there might be only 8 Mb free - depending on other things totally outside the perl interpreter's knowlege or control.) The limitations of the HTML renderer that are relvant here are not like that. The screen won't suddenly grow new pixels. It wont resize (note: Yes, I realize the window can, but doing so results in a re-rendering of the data, so for the lifetime of a single pass through the interpreter/renderer, the resolution is fixed.)

The physical restrictions of the screen are an additional limit that a perl program doesn't have to work with, and it is those limits that allow HTML to be cut-off in a fashion that is guaranteed not to be a mistake. (Even if a perl interpreter *knew* that a singe-pass non-looping program would take exactly 64 MB to run, and it sees that it currently only has 48 MB free from the system, it would *still* be incorrect to cut off the run of the program, since that limit of 48 MB is not a certainty.)

Re:HTML limits

[DunbarTheInept]

And here's another thought:
Consider an HTML table with several hundred rows, the first 199 of which have 30 "TD" sections, and the 100th one has 10,000 "TD" sections. What should the HTML interpreter be doing at the moment when it is still halfway through reading the table and doesn't yet know that it is going to turn out to be padded out to 10,000 columns because it hasn't hit that last line yet? Most browsers I've seen start trying to pre-render the table before they've finished seeing all the content (if it's a big table, or a slow enough download that I can watch as it happens). Thus by the time the 10,000 column snafu is discovered, the browser has already committed itself to rendering the table and would now have to back up and undo a lot of things now to un-render the table.

(No, this doesn't have a direct impact on the point under argument. It's a response to your claim that it is managable to pre-determine before rendering whether a bit of HTML is going to be a resource problem or not. If HTML interpreters worked like the PERL interpreter, where they finish reading the whole input file in one pass before attempting to "run" anything, that might be true. But browsers are made to render as they download, since downloads are sometimes slow.)

Re:HTML limits

[farnz]

Which is completely irrelevant to the problem of Turing-completeness; you're trying to use practical arguments to say that theory is wrong, and theoretical arguments to say that practice is wrong.

Either Turing-completeness is relevant, in which case expanding the argument beyond the scope of Turing-completeness is a waste of time, or it isn't, in which case you should not have brought it up.

Re:HTML limits

[farnz]

On every interface I've worked on, the solution is simple. Store the partly-rendered HTML as a sequence of drawing commands, pointed to by a BSP (for fast redraws of revelant portions). When it comes to time to handle the HTML where you've drawn 999 rows with 30 TD sections, then the 1000th row needs 10,000 columns, go back, amend the BSP to allow for a 10,000 column table, erase the old bit, and redraw. This is manageable in O(log n), where n is the size of the section that has changed.