Mozilla has just released Firefox 2.0.0.5 which purportedly fixes one of the attack vectors of the Internet Explorer input validation flaw that I previously detailed. I will go on the record as stating that this does not actually fix the flaw in Internet Explorer, but simply patches one of the myriads of attack vectors.
As can be seen from the release notes this update fixes 8 different security vulnerabilities. The security update in question is MFSA 2007-23, which has the following choice quote:
Note: Other Windows applications can be called in this way and also manipulated to execute malicious code. This fix only prevents Firefox and Thunderbird from accepting bad data. This patch does not fix the vulnerability in Internet Explorer.
That is the official stance from the Mozilla Corporation, which matches my own assessment. You might remember that there was some controversy about who was to blame. I blamed Microsoft, Secunia blamed Mozilla, Mozilla blamed Microsoft and Microsoft blamed no one in particular, simply stating that it “is not a vulnerability in a Microsoft product”.
I can definitely understand the initial reaction from Microsoft. Most of the emphasis in the public vulnerability reports were dealing with Firefox, the -chrome command line argument and how to properly escape the exploit code.
However, I can still automatically launch a wide range of external applications from Internet Explorer and provide them with arbitrary command line arguments. AcroRd32.exe (Adobe Acrobat PDF Reader), aim.exe (AOL Instant Messenger), Outlook.exe, msimn.exe (Outlook Express), netmeeting.exe, HelpCtr.exe (Windows Help Center), mirc.exe, Skype.exe, wab.exe (Windows Address Book) and wmplayer.exe (Windows Media Player) - just to name a few
I can categorically deny that this flaw has been fixed in Internet Explorer. Nicolas Robillard even detailed this flaw back in 2004 and it has remained unpatched since long before then.
The only thing that is changing as time goes by is the exploration of new attack vectors, which simply means investigating the various command line arguments that each of the above processes will accept to execute code. As soon a new attack vector is uncovered a new exploit can be produced to automatically execute code through Internet Explorer.
That reminds me, outlook.exe is an interesting application to pick apart… ![]()

Suggested revised title: “Firefox /works around/ Internet Explorer flaw”, since it didn’t actually fix the original vector as you point out.
[...] latest from Larholm spells out the risk scenario: I can still automatically launch a wide range of external applications from Internet Explorer and [...]
[...] Firefox fixes Internet Explorer flaw [...]
[...] demonstrates the same attack through Internet Explorer to execute code in Trillian. Additionally, Thor Larholm says “I can still automatically launch a wide range of external applications from Internet Explorer [...]
I’ve already mentioned this in a reply to another user’s comment on your earlier post, but I think it’s worth making a stronger point about it as a lot of people don’t seem to realize this:-
STD66 requires that all URIs (hence URLs) consist of only a limited set of characters. The quote mark is not in this set; hence a URL with a quote mark is inherently illegal, regardless of the scheme. (Of course a quote mark can be included if it is properly encoded.)
IE doesn’t need to know the detailed syntax of every registered URL scheme. But it should know - and enforce - the restrictions that apply to all URLs!
This reminds me of the ActiveX problem - the fact that Internet Explorer 6 and prior will happily allow any web site to use any ActiveX control installed on the computer, unless the registering application specifically said it shouldn’t. This has been responsible for countless security issues over the years.
In both cases the fault (arguably) lies in the other program, the one registering the ActiveX control or URI handler. If the other program had only followed the documented procedures correctly, bemoan the IE developers, there wouldn’t be a problem.
IE version 7 finally addressed the ActiveX issue, at least in part; only those ActiveX components that are specifically enabled can be accessed by web sites.
Maybe, if we’re lucky, IE version 8 will fix the URI protocol issue.
[...] imprecisato di applicazioni Windows: qui c’è un POC (Proof of Concept) per Trillian, ma non si tratta di un caso isolato: I can still automatically launch a wide range of external applications from Internet Explorer and [...]
Harry, even if Internet Explorer has some problems I can’t let your last comment go unchallenged. It is a common misconception that IE will happily execute any ActiveX control on your system, but this is simply not true. There are extensive controls in place which forces the component developer to properly package, implement and sign his ActiveX control before it can be automatically used by script in the Internet Zone.
The vast majority of ActiveX controls on any given Windows system cannot be used by web content. http://msdn.microsoft.com/workshop/components/activex/tutorial.asp highlights just a few of the required steps to expose your ActiveX to web content.
Regards
Thor Larholm
Thor,
When you say Internet Explorer, do you mean IE6 or IE7? Or do you mean both?
Kimblim, I mean both
Regards
Thor Larholm
Larholm.com - Me, myself and I » Firefox fixes Internet Explorer flaw…
Mozilla has just released Firefox 2.0.0.5 which purportedly fixes one of the attack vectors of the Internet Explorer input validation flaw that I previously detailed. I will go on the record as stating that this does not actually fix the flaw in Intern…
I can’t claim to be an expert on ActiveX; I was basing my (apparently erroneous) assumption on the number of vulnerability notices I’ve read over the years that seemed to boil down to an ActiveX component being inappropriately exposed to web sites. (For one thing, there was hardly a cumulative IE update that didn’t set the kill bit for at least one control!)
I’ll accept that my statement was technically incorrect; however, it still seems that it is too easy (in practice) for software to expose an ActiveX control to the web without meaning to?
Thor,
1. I dont see SeaMonkey and other moz products mentioned, whether they are also affected?
2. your example show attack vector with javascript:, whether current firefox fix also stops chrome://, file://, jar://, resource:// being called?
3. what about target apps that registers scp:// ftp:// ssh:// protocals, ie apps like PuTTY, WinSCP, FileZilla, as well as P2P apps. any report them being tested for similar possible attack.
Thanks…
[...] Thor Larholm, one of the researchers who brought this problem to light, says in his Larhom.com blog that the Firefox update isn’t the end of the [...]
Biju, SeaMonkey should be affected as well as it registers a similar URL protocol handler, called SeaMonkeyURL. The definition can be found at http://lxr.mozilla.org/seamonkey/source/suite/installer/windows/nsis/shared.nsh#157
The fix in Firefox 2.0.0.5 prevents any kind of additional arguments from being parsed if Firefox is launched as a URL protocol handler. Other applications can still be called with arbitrary arguments.
Regards
Thor Larholm
[...] Firefox fixes Internet Explorer flaw [...]
[...] related to the infamous bugs that has been recently discussed on multiple blogs including GC (us), Thor Larholm’s blog, Mozilla’s Security Blog, the 0×000000 hack zine and Billy (BK) Rios‘ [...]
[...] Foundation poprawi?a b??d wraz z wersj? 2.0.0.5, problem po stronie IE zosta? po raz kolejny zignorowany (wprawdzie w tym przypadku jest to cz??ciowo zrozumia?e, gdy? przecie? istnieje mo?liwo??, [...]