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."
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.
liqbase
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
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.
"Doing what i can, with what i have." ~ Burt Gummer
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.
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.
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.
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.
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.
-- Solaris Central - http://w
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.
http://lcamtuf.coredump.cx/mangleme/gallery/
I opened all the pages in tabs in Firefox 0.10.1 under Windows 2000, and Firefox did not crash. It became somewhat unresponsive, but I could still select other tabs, minimise and maximise. I could not load new pages anymore.
Can someone else test this as well, please?
And can someone tell us whether this has security implications or not?
-
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.
One guy with ten minutes came up with ways to crash Mozilla, Lynx, and Links, yet hundreds of thousands of programmers with years of access to the same code haven't fixed these same bugs.
Tested several (> 30) time. No crashes here!
Version 3.3
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.
I tried this script on both Mozilla firefox at least 40 X now, and it hasn't crashed yet...
You'll also notice none of this random code tests activex security either, or many of the MS extensions which "enchance" security either.. So I think the tests should be taken more with a grain of salt.. Also while he did say null dereferences, its potentially due to all the same 1 or two flaws, and may not be exploitable at all..
Take this with a grain of salt I'd say, because when you check the tags being tested, there aren't a great amount..
I have a file sitting on my desktop here at work which says IE was still growing up in July of this year.
:)
It was an 11 byte html file which made IE go BOOOOOOOOM. I aptly named it "crashme.htm".
It remains on my desktop as a reminder of MS crap
liqbase
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?
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?
I think you mis-estimate how hard it is to manage projects with the complexity of Internet Explorer. Even teams of really good developers with noe one "non-expert" can be brought down by the integration trap. It can probably all be led back to the Waterfall development paradigm where you do things in huge chunks: "Requirements, Design, Implement, Integrate, Pray, Test". Each of those is done as a discreet phase. Any devleopment process still following that basic model tends to fall apart somewhere around Integrate. Even with better development paradigms such as agile development there are considerable challenges in integrating something so large as IE.
:)
But that *IS* the point of Agile development, to ensure that every step of the way things are working toghether smoothly. The basic point is regardless of the paradigm IE is a big project with many different components requiring a high degree of integration. A key problem with many different components that are highly integrated is the fact that these components tend to "trust" each other to much. Meaning they just assume this component is friendly. If all integrated components were a little less trusting I think software as large and as complex as IE could be more secure.
This is just a guess, I don't know much about internal Microsoft culture. I have however seen security problems of this scale in projects I have cleaned up and worked on and the problems stem from the exact problems I describe. So its reasonable to assume that somewhere along the way MS has made the same mistakes everyone else does in the software world. Just because they have LOTS of smart people doesn't mean they are any better at managing software processes. Just look at what they are doing with the LongHorn requirements
Jeremy
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.
Range Voting: preference intensity matters
On any given day we know of many HTML inputs that will crash Mozilla, and many that will crash IE, and ditto for other browsers. Which ones get fixed is simply a matter of priorities. And we prioritize by looking at the crash to see if it looks like it could be turned into a security hole; looking at talkback data to see which crashes people are hitting most frequently; focusing on the ones that occur on actual real websites, and maybe after that when there's nothing else to do we fix the ones exposed by artificial testcases.
No-one has enough resources to fix every bug, not even Microsoft.
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.
0 328.ht ml
s +say+JPEG+ virus+imminent/2100-7349_3-5387380.html
2 24 .html
Your comment really burned me up since I have to deal with this crap every month in an enterprise environment. You can talk to me about "trend(s) per-product" all you want but how on Earth can you brag about the great job you're doing when this month you released 10 frigging hot fixes with 7 of those being critical? You should be keeping your head down this month trying not to attract attention to your miserable situation. Only Microsoft would think to brag about how well they're doing wrt to security during a month like this.
Look at the non-chalant way MS is handling the security vulns. In particular I'm thinking about MS04-028 (the JPEG vuln) which was just last month. On top of being one of the worst written security write-ups I've ever read, the tool you initially provided to detect the problem was worse than useless. Some random guy on the web managed to produce a useful tool by himself before MS did. With all the resources MS has and all the attention you're putting into security how can this be? Also, how could you release such a horrible, broken tool in the first place? Surely MS knew the tool was broken when they released it if they tested it at all!
http://seclists.org/lists/bugtraq/2004/Sep/
If you want me to take MS seriously wrt security then do not attempt to spin how severe a vulnerability is (like you did with MS04-028). How is anyone supposed to take you seriously when MS says things like this:
"Microsoft does not consider this a high risk to customers given the amount of user action required to execute the attack and is not currently aware of any significant customer impact".
http://news.com.com/Security+researcher
If MS04-028 is not a high security risk then why did MS mark it as critical??? It is one thing to say that you think the JPEG vuln was overhyped (which it was to an extent) but to say that it isn't "high risk" while marking something as "critical" stinks of spin.
Also, I found it hypocritical for MS to yell from the mountain tops about how security is a top priority and yet at the same time refusing to back port very important workstation security enhancements to non-XP OSes (about 1/2 your install base). Note that this also includes security enhancements to IE6.
"We do not have plans to deliver Windows XP SP2 enhancements for Windows 2000 or other older versions of Windows," the company said in a statement. "The most secure version of Windows today is Windows XP with SP2. We recommend that customers upgrade to XP and SP2 as quickly as possible."
http://arstechnica.com/news.ars/post/20040923-4
Finally, security is a design decision. If security is not a design decision (hello... ActiveX) then you'll constantly be chasing your tail trying to plug holes in the dam. The hack you suggest in your sig to "solve" the spyware issue really underlines this point. RunAs is broken and doesn't work in many cases and the fast user switching does not work very well unless all one does is browse the web and get email. I won't even get into all the reasons why the fast user switching idea is a non-starter except to say that many applications *require* admin privledges to even run. Both Macs and Linux have had an elegant solution for some time (ask the user for the Admin/root password) in order to elevate privleges. Why is that so hard?
G. Washington on Government "it is force. Like fire, it is a dangerous servant and a fearful master."
Those pages were just examples to prove that various browsers had repeatable crashable points.
:-)
If you run his mangle.cgi test against Konqueror it takes 15 secs for it to crash the browser!
Better fire up the KHTML bug track.
I have to ask:
When saying that Microsoft Internet Explorer didn't crash, does he mean that the window never went away, or that the program iexplore.exe stayed running? I can't prove it, but I suspect that the "IE" window would survive a crash of the rendering engine, because the window is actually provided by explorer.exe, which is the desktop manager.
I also suspect that several of the open source browsers could defend themselves against this kind of crash within a day or two, simply be using a two process model. Personally, I would rather they did not! (I want to see it fail, otherwise I would not know something was wrong.)
I watched "Moon Child", the VCD verison, and BOTH times when Xine reached the end of the VCD, as the last of the credits rolled, the entire laptop locke up.
.9.x release, and has not normally done this on other DVDs or VCDs I've watched. Just with Moon Child, the Japanese version with English & Jpns/Chns subtitles. Periodically, after taking 10 screen snaps with Xine's camera icon, Xine would just disappear. I'd then have to stop Alsa, by running /etc/rc5.d/S17also force-restart
Nothing worked, not even ctrl+fn+someletter would work. I am an avid Lxr, and I only use win98 inside Win4Lin, but last night I even had that off, I reniced MySQL to something like +15, and at one point reniced Xine to -9 or -10 before shutting it and restarting it.
However, I was off-line, and did not even have Firestarter nor Etherape running, so my CPU is not being overloaded. I do notice, unrelated to Xine, that running Win & in X4ce starts MUCH faster (as when KDE is FRESHLY run) than currently in KDE. I imagine one of my hidden dot files or authority or temp files is trashed, or maybe something in a win4lin path is hozed. Maybe my box has been cracked weeks ago. I dunno. Have to check my logs.
However, I accept that xine is
And if Xine was alive at that point, the force-restart would kill it dead.
I know this is not exactly along the lines of browsers, but if VCDs and DVDs are being watched while a user is on-line, who knows if a batch of bad code is being fed to the userspace tools? Who knows if other compromises already on the box are aggregating to worsen things with a new breach's arrival. Fortunately, I prefer to yank my ethernet anytime I'm not surfing. I tend to yank my bband router, too, to keep its visibility low.
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
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.)
Range Voting: preference intensity matters
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.
Range Voting: preference intensity matters
100% valid CSS and XHTML continues to crash IE.
Tried the gallery examples, firefox crashes reliebly, links does too (from the error messages it looks like they actually catch the NULL pointer - it says "malloc returned NULL pointer" - but don't react to it)
However, I was not able to crash lynx with the example. It takes a while to render the page, but it renders it just fine (considering it is actually invalid HTML). Perhaps it depends on the amount of memory you have.
If I remember correctly, while ago there were rumors being circulated that IE is specifically designed to deal well with invalid HTML. Lot of people were of the oppinion that it is really bad, and that invalid HTML code should be rejected. Thay said IE basically encouraged sloppy web design.
AccountKiller