Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IE Shines On Broken Code

timothy posted more than 9 years ago | from the crashing-is-unsafe dept.

Internet Explorer 900

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

cancel ×

900 comments

An important security sidenote (4, Insightful)

Eponymous Cowboy (706996) | more than 9 years ago | (#10563394)

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 [trustworthycomputing.com] 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 [google.com] 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.

So what is "random" here? (2, Insightful)

Anonymous Coward | more than 9 years ago | (#10563417)

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:An important security sidenote (3, Interesting)

LiquidCoooled (634315) | more than 9 years ago | (#10563426)

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 (5, Interesting)

UfoZ (680310) | more than 9 years ago | (#10563456)

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 (1, Funny)

Anonymous Coward | more than 9 years ago | (#10563463)

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

Re:An important security sidenote (2)

horrens (785051) | more than 9 years ago | (#10563504)

and safari didn't crash either

Re:An important security sidenote (4, Insightful)

InsaneCreator (209742) | more than 9 years ago | (#10563467)

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 (1, Interesting)

BrianHursey (738430) | more than 9 years ago | (#10563478)

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. Malformed java script and html can be known to automatically download things like adware via security holes. 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. From what I am reading her this is IE allows errors like this to keep on running. To me this is a very very bad thing.

Re:An important security sidenote (0)

Anonymous Coward | more than 9 years ago | (#10563494)

Catching bad html and informing the user about it is better than silently guessing what the author might have meant, but the latter is still better than not catching bad input and choking on it.

Re:An important security sidenote (3, Interesting)

freedom_india (780002) | more than 9 years ago | (#10563490)

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 (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10563523)

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

Re:An important security sidenote (5, Interesting)

dioscaido (541037) | more than 9 years ago | (#10563561)

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

The good news is that now people are required to know Writing Secure Code [microsoft.com] , and (more recently) Threat Modelling [microsoft.com] 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 (5, Interesting)

dioscaido (541037) | more than 9 years ago | (#10563492)

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 [microsoft.com] .

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 [asp.net] , and nip this stupid spyware problem in the bud.

Re:An important security sidenote (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10563521)

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

Because it's used to it? (5, Funny)

ideatrack (702667) | more than 9 years ago | (#10563397)

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

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

Re:Because it's used to it? (0)

DigiShaman (671371) | more than 9 years ago | (#10563464)

More true then funny (it's still is funny though) IMHO. It's a basic law of evolve or die. It looks like due to all the bad press (in part because of installed base popularity), Microsoft was forced to update and harden Internet Explorer.

As for the other browser, time will tell..

so (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10563399)

what?

hmmm (4, Funny)

Anonymous Coward | more than 9 years ago | (#10563400)

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

Slashdot browser testing? (2, Insightful)

richie2000 (159732) | more than 9 years ago | (#10563402)

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

When? (-1, Offtopic)

BoldAC (735721) | more than 9 years ago | (#10563403)

I'm wondering when Michael's post will show up on slashdot.

10/19/04 7:26 eastern time? :)

Hmmm (0)

Anonymous Coward | more than 9 years ago | (#10563408)

While it's all very interesting, the fact is, if this is a valid problem then you can be sure that all the freebie browsers (moz etc) will just fix it and issue an update. No biggie

Re:Hmmm (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10563508)

The've already fixed it by definition. Under the "many eyes" theory, the bugs are supposed to be fixed sooner than proprietary apps like IE.

What they didn't say (5, Funny)

Anonymous Coward | more than 9 years ago | (#10563409)

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

Re:What they didn't say (0)

Anonymous Coward | more than 9 years ago | (#10563435)

Please don't abuse the word automagically.

It's slowly but surely losing it's magical meaning...

Security Issues (2, Funny)

PrivateDonut (802017) | more than 9 years ago | (#10563410)

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 (4, Insightful)

mccalli (323026) | more than 9 years ago | (#10563436)

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 (4, Interesting)

Trillan (597339) | more than 9 years ago | (#10563510)

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 (2, Funny)

iamdrscience (541136) | more than 9 years ago | (#10563537)

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

IE does everythýng better (-1, Troll)

OffTheLip (636691) | more than 9 years ago | (#10563411)

Including running all varieties of malware, coersive scripts and junk http redirects.

This is known (0, Troll)

metlin (258108) | more than 9 years ago | (#10563412)

It's quite known that broken code runs quite well on IE.

Great, but then it also encourages people to write bad code - see all that code with broken tables and a million tags that remain unclosed?

Thank webmasters (if they can be called that) who tested their code solely on IE for that.

And lately, writing bad HTML has become the norm rather than exception.

amazing (0)

iamnotacrook (816556) | more than 9 years ago | (#10563448)

you complete missed the point and still got modded insightful.

Re:This is known (0)

gotw (239699) | more than 9 years ago | (#10563461)

He's talking about crashes, not rendering bad code, someone mod this down please.

Re:This is known (1)

metlin (258108) | more than 9 years ago | (#10563480)

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

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

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

Duh. Get it now?

Re:This is known (1)

ClosedSource (238333) | more than 9 years ago | (#10563560)

There's a difference between posting an error message and crashing. So I don't think there's any upside for the other browsers on this issue.

As for allowing sloppy HTML, that's a problem if you think the primary purpose of a browser is to enforce HTML standards rather than display web pages.

Re:This is known (5, Insightful)

Mr_Silver (213637) | more than 9 years ago | (#10563472)

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.

Re:This is known (1)

metlin (258108) | more than 9 years ago | (#10563493)

I know.

What I meant was this -

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

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

Re:This is known (0)

Pieroxy (222434) | more than 9 years ago | (#10563511)

I think you are confused now. Broken HTML is broken HTML. You can eventually have a level of how bad it's broken, but that is all.

So your categories would be:
1. Slightly broken HTML;
2. Completely broken HTML.

The fact that IE renders better broken HTML (1) certainly tells that it was tested with broken HTML. It can hardly be dissociated with it's robustness for broken HTML (2).

Or can it?

Re:This is known (-1)

Anonymous Coward | more than 9 years ago | (#10563473)

Your points are true, but this is about buffer overruns, crashes and other things that really shouldn't happen. This is to be taken seriously...

Re:This is known (0)

Anonymous Coward | more than 9 years ago | (#10563479)

This isn't about producing legible output from bad html, it's about not crashing due to random input.

so? (0, Redundant)

badpenguin (793665) | more than 9 years ago | (#10563413)

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.

Re:so? (1, Funny)

Dante Shamest (813622) | more than 9 years ago | (#10563453)

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

Re:so? (1)

Lazy T (788616) | more than 9 years ago | (#10563487)

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

You don't get it (1)

Interfacer (560564) | more than 9 years ago | (#10563513)

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

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

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

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

Bad people DO try to make your browser crash... (0)

Anonymous Coward | more than 9 years ago | (#10563535)

The point is that someone else could craft a page that makes your browser crash.
Which would be annoying enough - but some of these crashes have the potential to become 'arbitary code execution' flaws.

Having said that - yes, these flaws are less serious than many others - and will likely be fixed quite quickly in the open source browsers.

For information - I was unable to make my version of Opera (v5.12) crash on the sample 'opera-die' page - but it did render some of the random pages incredibly slowly and would probably run out of memory on a properly crafted one.

which version of IE was it? (4, Informative)

jonwil (467024) | more than 9 years ago | (#10563415)

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? (1)

metlin (258108) | more than 9 years ago | (#10563465)

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

Mozilla, Links and Lynx.

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

-tinfoil hat-

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

-/tinfoil hat-

Re:which version of IE was it? (1)

wimvds (615170) | more than 9 years ago | (#10563468)

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

Re:which version of IE was it? (1)

wimvds (615170) | more than 9 years ago | (#10563496)

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

In a land of broken codes... (2, Funny)

kusanagi374 (776658) | more than 9 years ago | (#10563420)

... the broken app is the king!

Finally... (2, Funny)

fredrikj (629833) | more than 9 years ago | (#10563425)

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

Misinterpreted the headline (0)

Anonymous Coward | more than 9 years ago | (#10563428)

I read it to mean that IE only excels as a web browser if your metric is "amount of broken code it contains". Which made a lot more sense.

Off Topic (2, Insightful)

z0ink (572154) | more than 9 years ago | (#10563429)

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

Conspiracy Theory time... (-1, Redundant)

KingDaveRa (620784) | more than 9 years ago | (#10563431)

So, a microsofty of some years, finds some code that crashes a slew of other browsers, but doesn't find any that crashes IE?

Hmm. I suppose its possible that IE handles bad code well, its just the purposefully bas stuff if doesn't fare so well with.

Re:Conspiracy Theory time... (3, Informative)

Ann Elk (668880) | more than 9 years ago | (#10563497)

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

Biased = 0? (1)

octaene (171858) | more than 9 years ago | (#10563433)

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

Excellent! (2, Insightful)

Mysticalfruit (533341) | more than 9 years ago | (#10563434)

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! (3, Insightful)

LiquidCoooled (634315) | more than 9 years ago | (#10563532)

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! (5, Informative)

metlin (258108) | more than 9 years ago | (#10563555)

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.

What about VALID html? (1, Interesting)

GabrielPM (633823) | more than 9 years ago | (#10563439)

OK, IE is the king of malformed HTML. It can take all the sh*t in the world and still run. Good job coding the parser.

But what about valid code? What about standard code?

I'd rather have full XHTML 1.1 support and abstrain from visiting sites made by monkeys with typewriters , or by Frontpage authors, than have an uncrashable parser for a browser who chocked on the proper XHTML content type.

Re:What about VALID html? (5, Informative)

tomstdenis (446163) | more than 9 years ago | (#10563520)

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

This is a blessing in disguise (5, Insightful)

Darren Winsper (136155) | more than 9 years ago | (#10563442)

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.

Frontpage (2, Insightful)

bmongar (230600) | more than 9 years ago | (#10563444)

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 ... (5, Informative)

Anonymous Coward | more than 9 years ago | (#10563445)

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

Shining us on (1)

AndroidCat (229562) | more than 9 years ago | (#10563449)

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

This Is to MS's Clear Business Advantage... (2, Insightful)

judmarc (649183) | more than 9 years ago | (#10563452)

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.

Great (1, Funny)

Nehle (784297) | more than 9 years ago | (#10563457)

When will it shine on working code?

Konqueror and bugs (3, Informative)

Anonymous Coward | more than 9 years ago | (#10563458)

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... (2, Funny)

jav1231 (539129) | more than 9 years ago | (#10563459)

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

AndroidCat (229562) | more than 9 years ago | (#10563485)

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

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

Re:Let me get this straight... (1)

lovebyte (81275) | more than 9 years ago | (#10563491)

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

This is why IE is so successful (0)

Anonymous Coward | more than 9 years ago | (#10563460)

This isn't just a security issue--this speaks to why IE has been so successful with consumers. It is designed very carefully to handle buggy code and therefore works with the widest set of web pages.


Other browsers have an insistence on adherence to standards that, although admirable in a compiler, is nonsense in a browser. Bad HTML will always be part of life, and a browser that can't make guesses about what bad tags mean is like a TV that crashes if it gets a noisy signal.


Too many people writing user-facing software seem to think that if the input isn't in the format they expect, they can just forget about it. Not true: your job isn't to handle some kind of platonic ideal input, your job is to write programs that work in the real world. Making smart guesses about bad input will always be necessary.

All Other Browsers? (2, Interesting)

polyp2000 (444682) | more than 9 years ago | (#10563470)

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 (2, Informative)

swinefc (91418) | more than 9 years ago | (#10563471)

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.

The reason for this is simple (1)

smartin (942) | more than 9 years ago | (#10563474)

Microsoft can afford a purify license.

All software has failure modes, question is... (1)

museumpeace (735109) | more than 9 years ago | (#10563477)

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

Coding to Standards (1)

dapulli (725620) | more than 9 years ago | (#10563481)

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

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

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

Re:Coding to Standards (4, Informative)

Jedi Alec (258881) | more than 9 years ago | (#10563526)

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.

Let the insults fly... (3, Insightful)

tomstdenis (446163) | more than 9 years ago | (#10563484)

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

Catch (1, Funny)

Quixote (154172) | more than 9 years ago | (#10563489)

All browsers but Microsoft Internet Explorer kept crashing

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

Tested Konqueror (4, Informative)

unixmaster (573907) | more than 9 years ago | (#10563495)

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

Re:Tested Konqueror (2, Informative)

Anonymous Coward | more than 9 years ago | (#10563545)

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

Re:Tested Konqueror (5, Interesting)

Anonymous Coward | more than 9 years ago | (#10563550)

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 (2, Insightful)

Anonymous Coward | more than 9 years ago | (#10563558)

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.

I've seen that before (4, Interesting)

hwestiii (11787) | more than 9 years ago | (#10563498)

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 (4, Interesting)

Zarf (5735) | more than 9 years ago | (#10563549)

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.

Hrm... (0)

Anonymous Coward | more than 9 years ago | (#10563507)

It causes no issues with Safari [apple.com] ...

Auch (-1)

Anonymous Coward | more than 9 years ago | (#10563514)

Some of the pages on the example script [coredump.cx] (it may take a few dozen refreshes) made Konqueror crash too.

This seems quite bad...

Off topic.. (-1)

Anonymous Coward | more than 9 years ago | (#10563518)

but I think it should be "Michal" not "Michael".

I think I know why IE works (0)

Anonymous Coward | more than 9 years ago | (#10563522)

At one point I was drafted to help fix an internal test tool that was notoriously buggy. It was so buggy that the previous owner of the tool had resorted to applying patches that simply nooped the instruction that segfaulted. There were dozens of these kind of patches. I know since I did patch analysis to figure out what the fix for the source code should be. The strange thing is that the program still appeared to work after a fashion.

I now know where the person who was the previous owner is working now. At Microsoft.

Reality Distortion Fields ON! (3, Insightful)

Zarf (5735) | more than 9 years ago | (#10563527)

The same person tells us [asp.net] that Apache [secunia.com] sucks when compared [asp.net] with IIS [secunia.com] . 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.

Well, I found one ... (1)

digitalgimpus (468277) | more than 9 years ago | (#10563529)

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

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

The Reason why IE is still the most used browser (1)

dJOEK (66178) | more than 9 years ago | (#10563530)

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

MSIE was through this already. (1)

Vo0k (760020) | more than 9 years ago | (#10563533)


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

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

Re:MSIE was through this already. (1)

Vo0k (760020) | more than 9 years ago | (#10563553)

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

To crash or not to crash (1, Insightful)

MadFarmAnimalz (460972) | more than 9 years ago | (#10563534)

His only criterion is whether the browser crashes or not. Somehow, it disturbs me more that IE doesn't crash; what precisely is the effect of the bad code then?

I agree that these are all potential security holes, yet the article author mistakenly correlates crashing with vulnerability.

What if IE is similarly vulnerable yet simply doesn't crash?

From that point of view, at least crashing is an indication that sometihng is not right.

All the same, I consider it a good beginning.

few bugs or many bugs? (1)

mr_walrus (410770) | more than 9 years ago | (#10563541)

so, did he REALLY find many bugs, or did he find just a couple bugs that
manifest themselves with many variations of html that really are doing
essentially the same thing?

Ahh... (1)

Atrophis (103390) | more than 9 years ago | (#10563544)

So IE is better at handling junk.

Nothing new here...

Now is this real world? (-1, Redundant)

digitalgimpus (468277) | more than 9 years ago | (#10563551)

Where, in the real world, do you find code this bad? This isn't even HTML... it's more like random characters.

oh, perhaps www.microsoft.com

big suprise.

strategic point of view (4, Interesting)

ragnar (3268) | more than 9 years ago | (#10563554)

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.

uhm... (1)

embeejay (446541) | more than 9 years ago | (#10563562)

I just tested his CGI using FireFox 1.0PR. I reloaded it 50 times, and the browser never crashed.

Maybe his testing skills aren't that up to date? (From viewing the source, it is obvious that his html skills are lacking) ;)
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...