IE Shines On Broken Code 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."
An important security sidenote (Score:4, Insightful)
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
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 (Score:3, Interesting)
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 (Score:5, Interesting)
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 (Score:5, Interesting)
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 (Score:4, Interesting)
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 (Score:5, Informative)
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:
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:
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 (Score:5, Interesting)
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 (Score:4, Interesting)
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 (Score:4, Informative)
They can intentionally, just not accidentially.
ReadProcessMemory
WriteProcessMemory
CreateRe
(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 (Score:4, Interesting)
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 (Score:5, Funny)
Re:An important security sidenote (Score:5, Interesting)
Not likely, since IE was created ages before
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 (Score:5, Interesting)
Re:An important security sidenote (Score:5, Informative)
Re:An important security sidenote (Score:5, Funny)
Re:An important security sidenote (Score:5, Insightful)
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 (Score:5, Interesting)
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 (Score:3, Interesting)
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 (Score:5, Interesting)
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 (Score:5, Interesting)
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 (Score:3, Interesting)
Re:An important security sidenote (Score:3, Insightful)
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 i
Comment removed (Score:5, Insightful)
Comment removed (Score:5, Interesting)
Re:An important security sidenote (Score:4, Insightful)
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 (Score:4, Insightful)
Pretty simple stuff, really.
Re:So what is "random" here? (Score:5, Funny)
This "random" test is dangerously incomplete. (Score:4, Insightful)
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:An important security sidenote (Score:5, Insightful)
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 (Score:3, Informative)
Have you been giving them feedback [mozilla.org](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 (Score:5, Informative)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
Crashes are always considered bugs.
Re:An important security sidenote (Score:5, Insightful)
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 (Score:5, Insightful)
*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 (Score:5, Informative)
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 (Score:4, Informative)
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 (Score:3, Informative)
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
Re:An important security sidenote (Score:4, Insightful)
Be liberal in what you accept... (Score:5, Insightful)
Because it's used to it? (Score:5, Funny)
If you work in a monkey house, you expect to be pelted with shit.
hmmm (Score:4, Funny)
Slashdot browser testing? (Score:3, Insightful)
However, my Mozilla passed the test without crashing. :-P
What they didn't say (Score:5, Funny)
Tell me, Mr. Anderson... (Score:3, Funny)
which version of IE was it? (Score:5, Informative)
Re:which version of IE was it? (Score:3, Insightful)
Re:which version of IE was it? (Score:3, Insightful)
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? (Score:4, Insightful)
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.
This is a blessing in disguise (Score:5, Insightful)
Re:This is a blessing in disguise (Score:5, Informative)
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.
Tried with Safari on OS X ... (Score:5, Informative)
Konqueror and bugs (Score:3, Informative)
I think this is a nice feature.
I wish that konqueror would have been tested. It's a good browser.
All Other Browsers? (Score:3, Interesting)
Let the insults fly... (Score:3, Insightful)
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 (Score:5, Informative)
Re:Tested Konqueror (Score:5, Interesting)
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 (Score:3, Interesting)
Version 3.3
I've seen that before (Score:5, Interesting)
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 (Score:5, Interesting)
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.
Reality Distortion Fields ON! (Score:3, Insightful)
Re:Reality Distortion Fields ON! (Score:5, Insightful)
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.
strategic point of view (Score:5, Interesting)
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.
His examples do not really crash Firefox (Score:5, Interesting)
http://lcamtuf.coredump.cx/mangleme/gallery/ [coredump.cx]
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 (Score:5, Informative)
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 (Score:5, Informative)
Larry Osterman -- former Microsoft guy; someone forwarded him a post to Bugtraq.
Michael Zalewski -- absurdly brilliant [coredump.cx] security engineer out of Poland. Did the pioneering work on visualizing [wox.org] randomness [coredump.cx] of network stacks, passively identifying operating systems [coredump.cx] on networks, and way way more.
Nothing bad against Larry. But this is all Zalewski
--Dan
IE Crashes On Valid HTML! (Score:5, Informative)
Nevermind using random garbage to crash a browser, you can make IE6 crash with perfectly valid strict HTML.
Try this page [nildram.co.uk] in IE6 and then hover your pointer over the link. Crash!!!
Re:IE Crashes On Valid HTML! (Score:5, Informative)
There is actually some truth to the matter (Score:5, Insightful)
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
Not a Security Issue, but a conceptual concern (Score:3, Insightful)
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.
handling malformed data is a pretty bad idea ... (Score:5, Insightful)
... 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.
Re:handling malformed data is a pretty bad idea .. (Score:4, Insightful)
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
(And BTW, I speak as a Firefox user)
maybe its a fluke.. (Score:3, Interesting)
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..
Poll: WHO has experienced crashes? (Score:3, Informative)
So can those people who have tested his code write
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 (Score:5, Interesting)
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?
OSS does not automatically mean secure (Score:5, Informative)
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?k
To make the My Computer zone visible change:
(for computer wide policy)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wi
To: 0x00000001
(for just a particular user)
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windo
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.
Did IE really not crash? (Score:4, Interesting)
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:Security Issues (Score:5, Insightful)
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 (Score:5, Interesting)
Re:Security Issues (Score:4, Informative)
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 (Score:5, Interesting)
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 (Score:5, Insightful)
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 (Score:3, Funny)
Re:This is known (Score:5, Insightful)
Great, but then it also encourages people to write bad code - see all that code with broken tables and a million tags that remain unclosed?
You're confusing two seperate things here:
This guy has been testing for (2) and not (1). Bad HTML should never cause crashes, memory corruption and buffer overflows. Period.
Finally, you can't go blaming the users for bad input. One of the golden rules of software design is that all software should either reject or handle gracefully bad input. Crashing is not graceful.
Re:This is known (Score:5, Insightful)
I repeat: code that crashes with a null pointer error is wrong. End of story.
Test your code at http://validator.w3.org/ (Score:3, Informative)
Re:Conspiracy Theory time... (Score:4, Informative)
RTFA. Larry didn't find the broken HTML, he just referenced an article [securityfocus.com] which did.
Re:What about VALID html? (Score:5, Informative)
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 (Score:4, Informative)
Re:Coding to Standards (Score:3, Interesting)
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:Excellent! (Score:3, Insightful)
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
Re:Excellent! (Score:5, Informative)
Here's the mozilla_die1.html codeAnd the mozilla_die2.html codeIt 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! (Score:5, Interesting)
Re:Excellent! (Score:5, Interesting)
No-one has enough resources to fix every bug, not even Microsoft.
Re:Excellent! (Score:5, Informative)
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:Let me get this straight... (Score:4, Insightful)
Re:This Is to MS's Clear Business Advantage... (Score:5, Insightful)
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:so? (Score:5, Interesting)
-
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.
Re:Off Topic (Score:4, Insightful)
Has it ever occurred to you that it is in MS interest to parse bad HTML? Maybe even to encourage bad HTML so IE is considered the best browser by the man in the street. Now where's my tin foil hat?
Re:The power of open source (Score:3, Informative)