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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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_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

[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

[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

[Tiram]

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

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

[|<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

[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

[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

[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

[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

[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

[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]

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

[Old Wolf]

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

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.

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.

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

[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

[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

[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

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

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?

[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?

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

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.

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

[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?

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!

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

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.

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.

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

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

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

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

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

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

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.

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.

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

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

[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: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

[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: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

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.

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!

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

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

[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: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:The reason for this is simple

[oever]

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

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

[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

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

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.

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: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

[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

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.

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.

Test your code at http://validator.w3.org/

[millahtime]

Test if your code is good or not at http://validator.w3.org/

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

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)

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

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

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.

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: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: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?

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.

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.

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

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.

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.

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.

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

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.

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

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!

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

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.

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.

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.

[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 :-)

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.

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.