The Protocol Handler Saga Continues: Say What Secunia?
Sometimes you just have to wonder how far people will go to lend undeserved credibility to opinions. The Protocol Handler Saga is rapidly becoming a religious war. The latest entry is related to a very cool exploit that Billy Rios and Nate McFeters published on Tuesday. Unfortunately, he failed to give Mozilla a chance to fix the problem before publishing it. Firefox users would have been far safer had he done that.
The exploit is quite simple: by embedding a null in a link to a protocol handler Firefox can be tricked into executing arbitrary commands on the users computer. Mozilla is working on a fix which will parse the URL looking for null characters and reject the request if it finds the. (This might be a good time to enter into a longer discussion on the ill advised strategy of looking for known bad stuff, but I have a different point to make).
My point however, is not in Billy's exploit, but rather related to Secunia's listing for this vulnerability. Secunia maintains a vulnerability database, which has not always been known to be entirely impartial. Nevertheless, Secunia's CTO, Thomas Kristensen, agreed with me last week that the responsibility for protection against malicious protocol handlers rests with the protocol handler.
That makes Secunia's advisory on the exploit that Billy Rios published even more astonishing. They claim it is an Internet Explorer 7 flaw and lists all versions of Windows Server 2003 and Windows XP as vulnerable! Let's see:
-
If a user browses the web using IE is he subject to this flaw? Answer: No
-
If a user browses the web using Firefox 2.0.0.5 and below, is he subject to this flaw? Answer: Yes
-
When a user clicks the malicious link in Firefox is IE launched? Answer: No
How exactly then does Secunia figure this is an Internet Explorer flaw? It's hard to tell really. Apparently, it is because the flaw only affects users that have Internet Explorer 7 installed. It turns out that Mozilla loads several components that ship with Internet Explorer, including ieframe.dll and urlmon.dll. Apparently, there is some interaction with those that causes this exploit to fire through Firefox, but not through IE. Maybe Mozilla expected those DLLs to do their input validation for them? A bit of threat modeling seems like it may be in order. This expectation that others are do input validation for you, without actually validating that they do, is seriously harming Mozilla's users.
On a slightly related note, several years ago when I was researching protocol handlers I wrote a little program that enumerated both protocol handlers and asynchronous protocol handlers. I thought it might be of interest to people to see just how many they have, so I have made that program available for download: listProtocols.zip.
In the meantime, what do we do? Well, several years ago, when there were some vulnerabilities in Internet Explorer's handling of protocols, the US-CERT had this advice: "It is possible to reduce exposure to these vulnerabilities by using a different web browser." Mozilla even echoed that sentiment two weeks ago, when they were trying to pin their protocol handling problems on IE.
If only the same advice worked now. If only there were a browser that was not subject to all these Mozilla flaws! Wait! I know:
We recommend people use Internet Explorer in Protected Mode on Windows Vista and practice safe browsing habits to protect themselves against these vulnerabilities in Mozilla Firefox.
I wonder why the US-CERT did not include that little piece of advice in its advisory?
Update Later That Evening
I wanted to answer Harry Johnston's comment about my seeming inconsistency in blaming Firefox for this instance of a protocol handler problem where Firefox only passes on the command; while I also claimed Firefox was to blame for the previous issue where it was the actual protocol handler. It does seem inconsistent, but so is Firefox' protocol handling. The best way, therefore, to answer turns out to be by amending the post.
The problem here is quite convoluted, but from what I can tell, it lies squarely with Firefox. I say that because Firefox never actually invokes the protocol handler in certain cases. Those cases happen to include the ones that Billy mentioned. You can actually test this using the test protocol handler that I included in a prior post. If you simply register that and then modify Billy's exploit like this:
<a target="_blank" href='testURL:%00%00..\..\..\..\..\..\windows/system32/cmd".exe ..\..\..\..\..\..\..\..\windows/system32/calc.exe " - " blah.bat'>testURL 0-day</a>
You will get the expected dialog:
Firefox calls the handler and the handler gets the nulls as you would expect. If this now caused code to be executed, then it most certainly would be the handler's fault, not Firefox'. However, that is not actually what happens.
It is actually Firefox that executes the malicious code. To test that you need to intercept the calls the one of the handlers that Billy exploited: mailto, nntp, news, snews, or telnet. The easiest way is to simply change the executable they point to. For instance, I changed the mailto protocol to point to this:
"c:\test.exe" /mailurl:%1
Then I clicked Billy's exploit. Calc.exe and a command prompt showed up just like it did when msimn.exe (Outlook Express) was the handler. The test.exe application was never invoked. Had it been, we would have seen it. In fact, you can confirm that Firefox is what launces the exploit (cmd.exe and calc.exe in this case) by using Process Explorer:
Notice the executable tree there. It is Firefox that launched cmd.exe. It launches that instead of the actual executable for some reason.
I do not fully understand why only some protocols are affected by this. It seems that Firefox does some kind of additional parsing of those protocols but not others, but it is not clear from a cursory look at the sources why that is.
Update 28 July, 2007
There will likely be plenty of blame to apportion once the investigations for this issue are concluded. For the moment, to allow vendor investigations to continue without giving much more away to the bad guys than what is already out there, I am not going to comment any further on the scope and source of the problem. First and foremost, we need to stop the bleeding. Then we can discuss what happened.