Slashdot Mirror
IE Shines On Broken Code
mschaef writes "While reading Larry Osterman'a blog (He's a long time Microsoftie, having worked on products dating back to DOS 4.0), I ran across this BugTraq entry on web browser security. Basically, the story is that Michael Zalewski started feeding randomly malformed HTML into Microsoft Internet Explorer, Mozilla, Opera, Lynx, and Links and watching what happened. Bottom line: 'All browsers but Microsoft Internet Explorer kept crashing on a regular basis due to NULL pointer references, memory corruption, buffer overflows, sometimes memory exhaustion; taking several minutes on average to encounter a tag they couldn't parse.' If you want to try this at home, he's also provided the tools he used in the BugTraq entry."
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.
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.
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.
Nothing crashed. I got blank pages, all the weird HTML and all, but no errors and nothing crashed. w00t.
or perhaps used one of their .NET languages, rather than programming in straight C like the others
.NET, and I don't quite think they decided to scrap and rewrite the entire parsing engine since then :)
;)
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
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.
Avantslash - View Slashdot cleanly on your mobile phone.
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.
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
Someday, I'll have a real sig.
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.
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.
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.
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.
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.
My Karma: ran over your Dogma
StrawberryFrog
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
> 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).
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!!!
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
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*.
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.
http://blog.nexusuk.org
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.
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.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
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.
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?
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.
Give me Classic Slashdot or give me death!
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.
Netscape used to crash very often. Looks like the Mozilla people didn't learn much from it.
b id=182569">Description of Internet Explorer security zones registry entries</a>
n dows\Curr entVersion\Internet Settings\Zones\0\Flags
w s\Curre ntVersion\Internet Settings\Zones\0\Flags
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.
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.)
Range Voting: preference intensity matters
I have a worse CD.. if you put it in the drive then it starts to install Windows 98 :(