Security Issues That Aren’t – Part 2


Part 1 of Security Issues That Aren’t gave rise to a lot of interesting comments. Hearing back from you is really helpful in terms of understanding what issues folks are dealing with and where we need to focus our attention. To those of you who suggested I should worry more about security issues that are instead of those that aren’t: I do! That’s exactly why I chose the subject: The fewer non-security reports I need to investigate, the more time I can spend on more severe problems. So bear with me … today’s topic is IE crashes and hangs.

A crash is a crash is a crash – or is it? In terms of security implications there are huge differences; a useful way of categorizing crashes is by looking at how they can affect the user.

Remote Code Execution

This is the worst case scenario. When can a crash result in a remote code execution vulnerability? The canonical example is an exploitable buffer overrun (BO). When the BO is encountered inadvertently, the application typically crashes due to an illegal memory access. However, an attacker could be able to exploit the bug to inject code into the process memory space and transfer control to it. Not every BO is exploitable, but many are.

Denial of Service

A crash falls into the less severe denial of service (DoS) category if it cannot be exploited for code execution. An attacker can crash your browser when you visit his malicious site, but cannot do any harm beyond that. The classic example for DoS is a null pointer dereference. Read access beyond a buffer boundary (as opposed to write access, which is usually exploitable) can also give rise to a DoS crash.

The most severe types of DoS are

  • Mailable DoS: The IE crash also affects mail clients (e.g. Outlook Express) that host IE to render HTML mails. An attacker could then craft an email that will crash the mail client when you try to open or preview the mail.
    In the worst case, you might not be able to delete the mail or even open the mail client. Recent versions of OE and Outlook protect against this by not showing the preview pane if the client had previously crashed.
  • BSoD DoS: The root cause of a blue screen DoS is usually a driver problem. However, the browser or mail client can be the means to trigger the BSoD and are thus involved in the crash.

Hangs

In a hang scenario, the browser becomes unresponsive, forcing the user to kill the process from Task Manager and restart it. This can be easily achieved without exploiting any bugs, e.g. by scripting an infinite loop on a web page. Again, an attacker cannot do any harm beyond forcing the user to restart the browser. Hangs are not exploitable for code execution and are always low level DoS issues.

We are continuously working on improving the robustness of IE. Investigating crashes and hangs – such as those reported to us through online error reporting – is a big part of that. I hope I have given you some insight into how we think about these, in particular how we prioritize them in terms of security.

– Patrick

Comments (27)

  1. Anonymous says:

    IIRC, Netscape (since at least version 3) prevents the infinite loop DOS by popping up an alert if a loop is executed more than a million times, giving the user the option to abort the script. Is there any particular reason why this is not implemented in IE? After all, it retains backwards compatibility with any really old sites out there which rely on the user terminating their infinite loops :-)

  2. Anonymous says:

    I have seen IE pop up a message that a script is taking a long time, with an option to terminate it.

  3. Anonymous says:

    IE does attempt to do infinite loop detection for scripts. Try running

    javascript:while(true);

    and watch a dialog pop up about a second later on a fast machine to let you cancel the script.

    It’s not possible to be 100% accurate detecting an infinite loop but for most browser scripting scenarios that isn’t really important. Almost no real world scripts take a substantial amount of time to return so it is easy to make heuristics. Users just want something friendlier than using the task manager but don’t want to be bothered with false notices.

    That was one of the reasons I rewrote the infinite loop detection that Netscape used to be time based. A few million operations is an eternity to a 25 MHz SGI Indy but an eyeblink to a 4 GHz P4.

  4. Anonymous says:

    What’s the point of this article?

    Are you hoping that we understand that a crash is not a always a security issue? Here’s a thought: we do – we’re fricken web developers for frick’s sake!

    Again I ask (since no one answered the first time):

    What is the purpose of this blog and who is the audience?

  5. Anonymous says:

    Dave P, agreed entirely! However, the Fiddler article was really good, and the mimetypes one was at least technical (if just actually a big excuse for a kludge).

    Here are some suggested post titles, I’m sure others will suggest more:

    ——————–

    SECURITY:

    1 – Cross-site scripting: introduction to attacks and defenses, with real world examples

    2 – Heuristically determining browser type (ignoring UA) using traffic pattern analysis

    3 – Automated testing, and building fuzz testing frameworks

    ——————–

    UI:

    1 – Challenges of browsing on small form-factor devices, and how IE addresses them.

    2 – Design decisions in previous versions of IE, and honest opinions on UI (or other!) features in competing browsers.

    3 – How IEteam decides which options are settable by advanced users, and which are simply hard-coded.

    ——————–

    ENGINE:

    1 – Rendering order of Trident, and how to exploit this to optimize the perceived user experience

    2 – What is the total IE footprint? How do we keep it minimal?

    3 – IE support and resources for MathML (and similar)

    ——————–

    PR:

    1 – Contributions made by IE team to W3 specs

    2- Design mistakes IE has made, and lessons learned

    3 – How we are working with antitrust authorities to ensure compliance when we ship IE in Longhorn.

    ——————–

    These were just the first things which came to me, most of them are crap, I’m sure. Yet I’m also sure there are at least one or two ideas here which others might be interested in and which don’t violate your precious NDA.

    Other MSDN blogs manage it very well. By comparison, the content here is generally complete rubbish and doesn’t inspire confidence.

    Undoing the years of negative PR and deep-seated mistrust about IE is surely a primary purpose of this blog. You’re failing. Badly.

  6. Anonymous says:

    So how can a browser, or a mail client bug cause a BSoD? I thought the primary drive in NT was robustness. "If a user process can cause the system to fail then NT has a bug" etc.

    Unless someone can exploit the browser, inject code to be executed and cause the it to load a new driver into kernel mode I don’t see how it could work.

    Unless there are known issues with a particular graphics driver, for example, suppose it was known the an old S3 that it would crash when it rendered cyan and magenta in adjacent pixels. Then just displaying a certain image in the browser could cause a crash. But I can’t believe there are many situatuions that are common enough across platforms to be able to create a DOS exploit.

    I agree with DaveP, he has some very good suggestions for future posts.

  7. Anonymous says:

    I mean I agree with "names are just labels".

    The new Google maps site demonstrates the sorts of things that IE is really capable of, but it is difficult to know how to optimize for the renderer and avoid performance pitfalls.

    It made me wonder if thats what Google employed Joe Beda for, someone who knew the structure of IE inside out, so they could create these highly dynamic websites that appear to be a step beyond anyone elses capabilities.

  8. Anonymous says:

    I’d really like the IE team to work on the ability for users to trust what they see.

    For example, I’d like to see the BHO interface terminated, and replaced with a safer version. A safer one would be managed code only with tight CAS permissions, and unable to render outside the main frame. That way, you don’t get URL bar or SSL padlock visual attacks.

    I’d also like the HTML control to be hosted as a managed component. The speed of the CLR is quite acceptable on modern computers, particularly in relation to network connections most of us have. I’m sure many IE exploits like buffer overruns could be avoided if you are using a type safe, managed version of the code. I’ve done a bit of C++ -> Managed C++ and the results have always fixed many latent bugs.

    I’d also like to see tabbed browsing, but carefully done. For example, a tabbed browser where a user dupes a session (using control-n), all their state is also duped. This causes many web apps a great deal of grief with race conditions. I am not for a minute forgiving them for not handling race conditions, but IE by default should create blank pages (or go to the home page) when control-N is pressed, not dupe the current session.

    Tabbed browsing also has other issues with DOM. It is possible on some tabbed browser implementations to cross over to other tabs document objects. This is particularly pernicious with Internet Banking functionality.

    So please implement tabs, but take extreme care when you do.

    Andrew

  9. Anonymous says:

    http://www.gerv.net/hacking/security/phishing.html

    has some really good analysis and ideas on phishing.

    Any chance of some collaboration, or even comment? Or is interoperability just something you say, not something you do?

  10. Anonymous says:

    Good grief "Names", each of those "articles" would make for excellent reading and discussion, don’t sell yourself short.

    So, when are you setting up the site? :-)

  11. Anonymous says:

    My comments inserted below:

    SECURITY:

    1 – Cross-site scripting: introduction to attacks and defenses, with real world examples

    Interesting topic.

    2 – Heuristically determining browser type (ignoring UA) using traffic pattern analysis

    Why ask us? We make IE, not websites. You want to detect the user agent, use the UA string.

    3 – Automated testing, and building fuzz testing frameworks

    We certainly do a lot of automated testing. We’ve blogged about that in the past a bit. We could do more here. Another interesting topic.

    ——————–

    UI:

    1 – Challenges of browsing on small form-factor devices, and how IE addresses them.

    We don’t. The IE team in Windows doesn’t make small form factor devices or browsers for them; the Mobile guys make the Pocket IE. The only thing it shares is the IE brand.

    2 – Design decisions in previous versions of IE, and honest opinions on UI (or other!) features in competing browsers.

    Another good topic.

    3 – How IEteam decides which options are settable by advanced users, and which are simply hard-coded.

    Also a good topic, although something that is hard-coded isn’t an option, is it?

    ——————–

    ENGINE:

    1 – Rendering order of Trident, and how to exploit this to optimize the perceived user experience

    A good topic, but very hard to get make this type of post specific enough to be useful without exploding the scope. That takes a lot of time, and we’re a bit short on that right now.

    2 – What is the total IE footprint? How do we keep it minimal?

    Footprint as in "on disk" or "in memory"?

    There are websites that talk about removing bits and pieces of IE and other Windows components from Windows, go find them and enjoy. Not something I’m interested in talking about.

    Keeping a website from consuming tons of client memory is much more interesting.

    3 – IE support and resources for MathML (and similar)

    IE supports MathML and the like via extensions. There are plenty available. We could talk about those, certainly.

    ——————–

    PR:

    1 – Contributions made by IE team to W3 specs

    There are plenty of those. We’ve got a few people who were highly involved back in the day who might be able to write some interesting posts.

    2- Design mistakes IE has made, and lessons learned

    That topic assumes we’ve made mistakes and/or we’re capable of learning lessons :-)

    3 – How we are working with antitrust authorities to ensure compliance when we ship IE in Longhorn.

    While compliance is certainly one of our many responsibilities we take seriously, it’s probably not something we’re going to blog about. Why whack that hornet’s nest?

  12. Anonymous says:

    @Bruce

    "Keeping a website from consuming tons of client memory is much more interesting."

    That’s how I understood his initial suggestion.

  13. Anonymous says:

    agnostic, that phishing article is really thought-provoking – a highly recommended read ! Why not do an article on what smaller, less experienced developers of secure websites can do to mitigate phishing attacks via good site design – ideas like use a different set of data for verification each time, etc? Browser-based protection is just one aspect of the war against phish.

    Bruce Morgan, there are lots of reasons why developers want to know what browser someone is using (but designing different versions of a site for different browsers should never ever be one of them !). Browser fingerprinting might not be what you do for your job, just as how to build phish-resistant websites isn’t your job, but we do expect you, as a browser developer, to know a little about it ! It would certainly an extremely interesting article !

    Also, instead of telling us that crashes might or might not be vulnerabilities, how about: ‘A guided tour of how we analyze different crashes using actual online error reports’.

  14. Anonymous says:

    Money where my mouth is, considering I started this:

    HTML and IE:

    1. IE renders pages differently from, say firefox. One of the noticable differences is that IE waits for the entire page before displaying it. Tell us about this, why it was designed like this, benefits and issues, things we as devs need to keep in mind regarding our IE audience (code size, SSI etc).

    2. IE (like other browsers) trys to be "smart" in how it interprets malformed HTML. Although it will "close" tables </tables>, it won’t close table rows </tr>… Go through these each of these behaviours, when the browser decides the code needs to be "fixed" and when it does not; the reasons behind this; how different versions of IE differ in this (we still have to support them – so you should support us); workarounds, considerations etc.

    CSS and IE:

    1. A comprehensive, complete and always updated list of CSS behaviours that differ from published W3C specs. (similar to http://www.positioniseverything.net/explorer.html)

    Write an article on each one, explaining it, the reasons why it exists; variable ways to achieve the desired behaviour (include opinions on pros/cons of implementation); future thoughts (ie: we don’t consider this to be against the spec, this will be changed in next version, this isn’t worth the effort etc, etc)

    2. The bug fixing process… We hear a lot about how bringing IE up to spec will have an effect with regards to backwards compatabiliy, yet this didn’t stop the correction of the box-model in previous IE releases… Why? What considerations did you go through? What considerations would you go through for future corrections? Do this for each "bug".

    I think that’s enough for a lot of blogging for you guys.

  15. Anonymous says:

    Hi Dave P,

    Some of this is best addressed in new posts and documentation on MSDN. Having asked many times for feedback on what people would like to see addressed in documentation it is great to get some feedback on this.

    I would like to clarify the last issue you bring up around compatibility as there seems to bea myth that we won’t change anything for fear of breaking compatibility. We have repeatedly explained that compatibility is a constant consideration as indeed it should be for any platform. We’ve also been clear that we expect to use the DOCTYPE switch moving forward as we did in IE6. This allows us to address issues while maintaining compatibility with content that does not specify a strict DOCTYPE.

    We do look at compatibility for every single change in IE. Compatibility is not a constraint that restricts us from moving forward but it is a constant consideration and something we consider vital if we are to offer developers a platform on which they can rely. It’s easy to say that web developers should just fix their sites to accomodate a change. However to a company that has a solution that was developed some time ago and on which no future updates are planned this is often an unreasonable expense.

    Thanks

    -Dave

  16. Anonymous says:

    [i]It’s easy to say that web developers should just fix their sites to accomodate a change. However to a company that has a solution that was developed some time ago and on which no future updates are planned this is often an unreasonable expense.[/i]

    I hope you realize that IE is the reason that such sites are improperly coded…

    The web would be a better place if IE didn’t have to retard the acceptance of web standards set forth by the W3C…

  17. Anonymous says:

    The new version of the OWASP Guide 2.0 (I am the technical editor) deals (or will deal) extensively with phishing attacks, session fixation, mitigations and so on, and is suitable for developers of .NET, J2EE and PHP applications (you can use these techniques in any language).

    I am hoping to have it out by April / May. Drafts can be obtained here:

    http://www.greebo.net/owasp/

    The full OWASP site is here:

    http://www.owasp.org/

    Do not forget Michael Howard and David LeBlanc’s excellent work Writing Secure Code (available from dead tree retailers), and the ASP.NET Secure Coding Guidelines (free from MSFT in PDF form).

    thanks,

    Andrew

  18. Anonymous says:

    Dave M, A few points:

    ->Some of this is best addressed in new posts and ->documentation on MSDN.

    Well, I could go read about most of this stuff on usenet as well; point being that I’d like to discuss it "real time" with the folks who know the application inside out. I’m also not really familiar with any one that make it a regular habit to read product documentation for fun (probably because they don’t get out that much) – it’s bad enough maintaining my own!

    Use the blog, that’s what it’s there for :-)

    ->It’s easy to say that web developers should ->just fix their sites to accomodate a change.

    I didn’t say that, and by implementing DOCTYPE conditions as you just said I would suppose they wouldn’t have to.

    ->However to a company that has a solution that ->was developed some time ago and on which no ->future updates are planned this is often an ->unreasonable expense.

    It’s a shame that such considerations aren’t taken into account with say, oh I don’t know security maybe? (http://news.com.com/Microsoft+to+secure+IE+for+XP+only/2100-1032_3-5378366.html) for a refresher.

  19. Anonymous says:

    Dave, the audience of this blog may not always be people like you. If you don’t like what we blog about, well, change the channel to something you find more to your liking.

    The article you just posted is incorrect in many respects. I don’t quite get why you posted it.

  20. Anonymous says:

    Bruce, the article is valid…

    The IE Team has done little to secure people who can’t run XP or SP2 on their machines.

    I don’t know if it is was you or Dave M who said that people will need to upgrade to SP2 to be secure…

    Would you guys make a popup blocker for older versions of IE if you weren’t as busy?

    If Bill Gates and Steve Balmer had the courage to say that releasing Windows ME was a mistake, then you guys should be able to admit mistakes were made in the development of IE’s "security" for SP2 only.

  21. Anonymous says:

    That’s bunk. Look at http://www.microsoft.com/technet/security/bulletin/MS05-014.mspx, the latest security cumulative update for IE.

    The update applies to:

    Internet Explorer 5.01 Service Pack 3 (SP3) on Windows 2000 Service Pack 3

    Internet Explorer 5.01 Service Pack 4 on Windows 2000 Service Pack 4

    Internet Explorer 5.5 Service Pack 2 on Microsoft Windows Millennium Edition

    Internet Explorer 6 Service Pack 1 on Microsoft Windows 2000 Service Pack 3, on Microsoft Windows 2000 Service Pack 4, or on Microsoft Windows XP Service Pack 1

    Internet Explorer 6 Service Pack 1 on Microsoft Windows 98, on Microsoft Windows 98 SE, or on Microsoft Windows Millennium Edition

    I left some off, but clearly you’re just plain wrong that we only secure XPSP2.

    Further, there different types of security issues. Implementing a popup blocker doesn’t address the same security issue as fixing a buffer overflow, and that isn’t the same type of issue as implementing data execution protection.

    IE in XPSP2 has quite a bit more of the latter types of fixes, but all supported IE configurations (IE 5.01 onward) get buffer overflow fixes, fixes to the block drag-and-drop vulnerabilities, cross domain scripting fixes, etc.

    Yes, the most secure and feature rich IE is the one in XPSP2, so that’s what I recommend people use.

    But if you’re using IE 5.01 on Win2K, you still get security updates.

  22. Anonymous says:

    I don’t believe what I’m reading here.

    Bruce seriously now, stop playing semantics and listen to what we’re saying, damnit. We’re not idiots: http://blogs.msdn.com/ie/archive/2004/12/01/273377.aspx

    I posted the article as a counter to Dave’s claim that for certain organizations redesigning their websites to be standards compliant is an unneeded expense. The article points to the blatent hypocrisy that obviously, for Microsoft this overarching concern for their customer’s bottom line dosen’t extend to features such as pop-up blocking (which, IMO if it isn’t a security issue – run ad aware every damn day and you may be more inclined to agree that it is – is most definately a user experience issue). I don’t really have an opinion on IE security fixes, but for you to propose a completely opposite stance than the one you practice is ludicrous.

    Clearly, Microsoft doesn’t consider aspects that include more money for them as "unneeded expenses" regardless of their utility. I think the point that expenses companies would direct to indiviual contrators and/or third parties are "unneeded" is quite derogatory. Let the customers decide what they will or won’t spend their money on. You’re supposed to be supporting us as well. Keep in mind that we are the ones talking to your customers daily, not you.

    ->Dave, the audience of this blog may not

    ->always be people like you. If you don’t like

    ->what we blog about, well, change the channel

    ->to something you find more to your liking.

    I was waiting for a response like this. Clearly, you may be correct that this blog is "not for people like me". So what kind of people is it for? Who is your audience? You haven’t responsed to this, so I can only assume that this is the resource for "people like me".

    It’s possible that you have a silent majority of visitors interested in non-existant security issues, why you like windows and your favourite DHTML sites. Until they speak up however, I would have to go with what I know. Keep in mind that several people are agreeing with me in this thread, and I’m not seeing any other comments.

    I can find somewhere else to get my IE information, it doesn’t really solve anything, though.

    I suppose saying I don’t subscribe to the Redmond groupthink is an understatment, but you’d think voices like mine would be if not welcomed; tolerated, keeping in mind that we will help you to make your product better.

  23. Anonymous says:

    When the article says we’re only securing XP customers, it’s simply wrong. I don’t see it as semantics but if you want to, feel free.

    Point is, if you go to Secunia with IE5.01 and try out some of their exploit tests, they won’t work once you install our patches. That’s why it’s called a security update.

    We don’t have any real audience in mind for this blog, although I assume that each of us, when we write a post, has some sort of expected audience in mind for that particular post. John’s posts are more toward IT corporate types, Dave’s posts are more toward webdevs, some of our posts are of general interest to anybody driving by, and so on.

    I don’t think Dave really claimed rewriting a website to be standard compliant was an unnecessary expense. Frankly, reading is comment I don’t know what he was trying to say (sorry, Dave) but it didn’t sound like that to me.

    BTW, we do talk to lots of customers daily.

  24. Anonymous says:

    Quite correct Bruce. I certainly never meant to imply that "rewriting a website to be standard compliant was an unnecessary expense". What I meant to say is that for a company to have to change it’s web solution so that it continues to work in a new version of the browser is an unacceptable expense for most companies. They need to crack open the code, work out what to change, specify the change, review the change and test the change. In my experience companies do not appreciate being forced to do that even when we tell them that the browser is better than the previous version :-)

    Thanks

    -Dave

  25. Anonymous says:

    Bruce:

    ->"When the article says we’re only securing XP

    ->customers, it’s simply wrong. I don’t see it as

    ->semantics but if you want to, feel free."

    Now I know you guys get a lot of flak from a few cooks out there, but most reasonable people know full well that you continue to support security fixes on other platforms besides XP. That’s not the point I am taking with your stance.

    You do from time to time however deviate from this inclusive policy, at which point it becomes rather hypocritical to suggest that you do not. To deny that, and by focusing on it while ignoring the other very relevant points we’re raising is playing semantics.

    ->We don’t have any real audience in mind for

    ->this blog

    That much is evident. As I would say to those that I work for though, and with no disrepect to your team, you would do well to find one. This blog would be much more effective it is was more targeted to specific users. That user group may not be the one I’m a part of, but no matter, the blog would still be better off for it. Perhaps a few different blogs? Pehaps more meaningful categories?

    At any rate, I’ve done too much commenting on this blog as is for the time being, I’ll shut up now. :-)