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