The QuickTime Vulnerability Overview

The details of the vulnerability were covered in my previous post. In this one I would like to briefly talk about the impact. Obviously, the vulnerability is very simple. Simple yet effective. However, this is not the type of vulnerability someone can exploit on a massive scale. Here is why.

Attack Vectors

The key element of the attack vector presented in my previous post is the attackers' ability to point the victim to a file hosted on a NETBIOS share. Therefore, in order to make the attack works, the attacker needs to ensure that the victim can communicate over NETBIOS with a computer which the attacker controls. Most ISPs in UK block NETBIOS traffic. This is due to the fact that many compromises in the past were a result of misconfigured Windows machines providing privileged access over NULL sessions. Although there are still some ISPs which DO NOT block NETBIOS traffic, I consider the exploit not very feasible over the Internet.

There are some ISPs which assign only NATed IP address to their customers. Usually when you associate with such ISP you get an IP in the 10.* range. Sometimes these ranges are not correctly filtered. This means that communication over NETBIOS is possible. However, attackers will be able to attack only customers of the same ISP.

Finally, the exploit works very well if the attacker is in the same network as the victim. WiFi networks seem to be perfect for this vulnerability. There is no point to discuss this in depth. Let's move on.

Class of Vulnerabilities

It is a lot more interesting to talk about why this vulnerability works. In my previous post I briefly covered why the attack works. Essentially, it comes down to QuickTime passing file:// protocol URL to FileProtocolHandler. What does that mean? It means that every application which sends user-supplied file:// protocol URLs to FileProtocolHandler is vulnerable to the same attack.

The next question is how many applications do that? Well, I do not know the exact number but if you do some googling you will notice that:

rundll32 url.dll,FileProtocolHandler URL

...is actually a code snippet recommended by many programmers and widely discussed in many programming books and forums. My suspicion is that there are many applications which blindly use FileProtocolHandler to launch URLs. I will try to get some rough figures out to the public once we have gone through enough client-side security audits provided as part of your cutting-edge services.

In the meanwhile, it might be a good idea to include the function into Errata's Looking Glass tool.