Tales from the Crypto

         Alun Jones (Security MVP Reconnect) writes about security, cryptography, SSL, PKI, and pretty much anything else that bothers him enough.

July 26, 2007


Part 3 – and I promise that’s the lot for now, because it’s starting to look like I’m obsessed or something.

Over the past week or so, you’ve read me talking about vulnerabilities in Fire fox’s protocol handlers, and how my perception is that Internet Explorer is neither the source of the flaw. A few others have weighed in on the issue in various directions, some at their own blogs, and others shuffling from blog to blog leaving comments.

Now, I think it’s time to look at Internet Explorer.

Some of my readers have suggested that I have been blinkered to what they see as Internet Explorer’s failings in this conversation, and in a sense, they’re right – I’ve been looking primarily at identifying where the actual security vulnerability lies, and deliberately not broadened my inspections to look at where related non-standard behaviour lies.

I’ve quoted RFC 3986 a couple of times, and in this article, it’s worth pointing out that although I believe it is correct that Internet Explorer should not percent-encode the URIs that it passes on to protocol handlers, I also believe that Internet Explorer should not be percent-decoding the URIs passed to protocol handlers.

Sadly, this is not the case – Internet Explorer decodes percent-encoded values, and also has a habit of percent-encoding some URIs on re-display. For instance, the URI “whatnot:hi there” becomes “whatnot:hi%20there” in the address display, even as it’s passed unfiltered to the protocol handler.

Just as Internet Explorer has no way to know what the URI’s intent in encoding is, it has no way to know what the URI’s intent at decoding is, and should feed the URI unvarnished to the protocol handler, for the protocol handler to deal with as it will. At least the developer documentation for writing a protocol handler documents that Internet Explorer decodes percent-encoded values before handling them to the protocol handler – and this is likely a result of noting how few protocol handlers were written by people who read RFC 3986.

What isn’t documented is that in addition to “%1”, there are other substitutions that can be made in the command line. %d and %l (that’s a letter ‘ell’) both appear to be the same as %1, as does %0, confusingly enough. %i gives some kind of identifier, in the form of :M:N, where N is the PID of the process that Internet Explorer is running – I have yet to figure out what M is. %s gives 1, and %h gives 0 – perhaps these indicate whether the handler is to be shown or hidden? Again, these are just guesses, and I have asked Microsoft if they can document these parameters.

Should Internet Explorer be changed?

So, now we’ve discussed that Internet Explorer decodes percent-encoded values on their way to the protocol handler, and encodes them on their way to the address bar, and I’ve stated my opinion that I think this is wrong. We’ve discussed that it’s documented behaviour, but that Internet Explorer exhibits other behaviour that ought to be documented.

Others have discussed that Internet Explorer does not encode values on their way to the protocol handler, and that they think this is wrong.

First, let me re-iterate that while that is definitely opinion on their part and mine, and I can’t call one definitively right or wrong, I am still going to say that Window Snyder is wrong to assess this behaviour as a critical vulnerability in Internet Explorer.

If Internet Explorer changes its behaviour, it will be as a convenience to the protocol handler developers, with the side effect of possibly protecting users from a small class of bugs in protocol handlers written by people with poor security skills (but not protecting against any number of wider classes of bugs that those developers might make). The critical vulnerability is still in any such exploitable protocol handler.

Many have pointed to Firefox’s quick fixes to the handler calling encoding as an example that Microsoft should make these changes themselves, and that Microsoft’s lack of change indicates a reluctance to address security.

We’ve seen a number of occasions where Microsoft has been quick to address security – and in a situation like this, you can bet that Microsoft staff have been asking the question “should we change this behaviour?”

If security was the only consideration, then making the change is still an unlikely decision – the flaw is not with Internet Explorer, and if you’re going to argue that “defence in depth” suggests that Internet Explorer should accommodate flawed protocol handlers, then you’re going to have to answer the question of whether you’re going to patch this in the TCP/IP stack, the Ethernet drivers, the Linksys/Cisco routers… All of these feature significantly in the path under consideration, and to all of these, the possibility of a malformed URI triggering a vulnerability in a protocol handler is but a miniscule fraction of the work they do.

Every time you change code, you run the risk of introducing related – and unrelated – damage. For Firefox, that risk is relatively small – the code-base is known for being changed at the drop of a hat, and vendors and users aren’t surprised to see weekly patches, some of which will kill functionality that they use. For Internet Explorer, there is a far greater expectation of stability. There is a far larger pool of documentation on its functionality, and if that documented functionality disappears or changes, users and developers call on Microsoft expecting assistance.

Don’t forget, also, that every Windows Firefox user is also an Internet Explorer user, and as Jesper found when delving into the bowels of the most recent Firefox bugs, Firefox on Windows is an Internet Explorer user.

As a result of all these things, Internet Explorer is going to always balance security against compatibility and usability – and where the security problem is external to Internet Explorer, there’s going to have to be a pretty powerful argument in place that Internet Explorer can best address the problem before changes will be made there.

To date, these exploits have centered around one vendor’s code. Should Internet Explorer be pushing a disruptive change to everyone just because that vendor calls IE by rude names in reaction to its own flaws? Should a change be forthcoming as a result of seeing how incompatible the URI behaviour is with RFC 3986?

I don’t think so. Maybe the next time significant disruptive change comes along – IE 8, perhaps. This time, why don’t you all test your apps while it’s still in beta, mm-kay?


  1.   Harry Johnston — July 28, 2007 @ 3:33 pm    Reply

    On the subject of IE percent-decoding what it passes to the handler, I’d like to point out that in some cases this is impossible for the handler to recover from.  To quote the RFC:

    “URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent.”

    For example, if the protocol handler sees a question mark, it doesn’t have any way to tell whether it was supposed to be a question mark or %3F, and they aren’t the same.

    However, I agree that Microsoft are stuck; they can’t change this already documented behaviour without potentially breaking existing applications that expect it.  (Personally, I wouldn’t mind breaking applications if they were violating the RFC standards, but that isn’t the case here; the change would affect properly coded applications.)

    What worries me about the security aspect is that this is one of those really ugly cases where a system is vulnerable simply because a particular application is installed, even if it isn’t being used.  People who use Firefox (for example) will hopefully be keeping it up to date – the problem is people who installed it once a few years ago, tried it out and went back to IE.

  2.   Michael Winters — July 29, 2007 @ 12:57 am    Reply

    If I am reading the Mozilla bug properly it seems that IE 6 and IE 7 behave differently on XP and that ShellExecute behaves differently on XP depending on whether IE 6 or IE 7 are installed. From the bug comments it also seems that some of the Firefox exploits can be reproduced with XP’s start run only when IE 7 is installed. At least some validation / cleanup is done to the url for some protocol handlers with IE 6 and IE 7 and the same appears to be true with ShellExecute with XP IE 7 which is different when compared to XP IE 6. There also seems to be different validation / cleanup on Vista’s ShellExecute when compared to ShellExecute on XP with IE 7. Since there are several different combinations perhaps documentation on all of the different combinations would be in order. Also, it seems that the behavior cited for Internet Explorer in the msdn article you referenced is for IE 7 and that IE 6 does escape.

  3.   alunj — July 29, 2007 @ 7:52 pm    Reply

    That’s right – it looks like there is some element of interconnectedness between Firefox and IE 7 on this bug. This suggests that there may be a flawed behaviour in IE 7 that Firefox is triggering. If that’s the case, of course, I’d expect Microsoft to fix the flaw.

  4.   Michael Winters — July 30, 2007 @ 9:48 pm    Reply

    It appears that the interconnectedness between XP with IE 7 and Firefox is also between XP with IE 7 and XP’s Start -> Run menu, Skype, Miranda, and likely others.

RSS feed for comments on this post. TrackBack URI

Leave a comment

© 2017 Tales from the Crypto   Provided by WPMU DEV -The WordPress Experts   Hosted by Microsoft MVPs