Pointing fingers

Momma always said every time you point a finger, three more are pointing back at you. Well, there was a lot of finger pointing going on the last few weeks between IE and Firefox over a vulnerability in url handlers, and a recent twist continue to stir things up. First when the safari beta came out, Thor Larholm discovered you could use it to send unescaped data to Firefox's registered url handler if it was installed. Apple fixed the behavior in Safari, and the world moved on.

Then it was pointed out that IE was also prone to sending unescaped data to Firefox, and this could in turn be used to force Firefox to take any system commands or actions on the local machine just by visiting a page in IE. Here's where the finger pointing begins.

IE claims it's not a bug in IE and Firefox needs to be more careful about the input it accepts. Firefox contends that it's IE's job to sanitize the data since IE accepted it from the webpage and there's no way for Firefox to distinguish from that data and another local program using the URL handler.

In the end, Firefox fixed the vulnerability in their 2.0.0.5 release by modifying their registered handler so that it is immune to this style of attack, but still point fingers at IE since many other applications are similarly vulnerable if they register URL handlers and so users are currently vulnerable to the entire class of vulnerabilities still.

Remember what momma said about pointing? It turns out Firefox is equally vulnerable and could be used itself for a nearly identical attack, not requiring IE this time. In all fairness, the Firefox team did fix the issue in the as-of-yet-unreleased 2.0.0.6. Which is a good thing, because that fix happens to mitigate the attack found in the next episode of this little browser wars soap-opera.Nate McFeters and Billy Rios discovered yet another vulnerability while they were poking around with protocol handlers from all the recent fuss. Essentially, including a null character (those pesky nulls have shown up in all sorts of fun vulnerabilities over the years) in the URL causes a FileType handler to be launched instead of the appropriate URL Protocol handler, Windows then interprets the nulls and this can be used to run commands on the local machine without any user interaction.

Straight forward enough, right? Stay with me if not--the fact that there's a vulnerability is maybe not as interesting as what's next. When I was testing the vulnerability, I stumbled across one interesting aspect. I couldn't get the sample exploit working on a fresh, un-patched Windows XP SP2 build. I installed all the patches and the exploit worked. Yup -- the exploit only succeeded once the machine was updated. So I installed the patches in groups until I'd isolated which update was responsible. It turns out that only after installing IE7 is this particular vulnerability exploitable. I later found a comment on the Mozilla bug tracker that observes the same behavior. So now we have yet another situation where one browser is directly exposing a vulnerability in the other.

Are we possibly in for another round of the blame game?

It's worth noting that if you want to secure yourself from these sorts of attacks, there are built-in options that can be used to lock down Firefox from any similar attack in the future. Also, the NoScript Firefox extension included an update that fixes the vulnerability even before the officially updated version of Firefox is out.