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?