SANS ISC is now reporting that the Apple Quicktime Content-Type Overflow that I've written about exensively is now being actively exploited in the wild. This is not surprising - this is easy to exploit, affects multiple platforms, and still hasn't been patched.

SANS posts a number of workarounds, all which center around disabiling Quicktime or blocking the traffic, none of which are going to be very effective. Below I discuss the problems with the current suggestions, and another possible workaround.

Even if Quicktime is disabled in browsers and file type associations, it is embedded in many products. One of the PoC exploits uses an iTunes playlist to trigger the exploit, and recently Linden Labs posted that because of Quicktime integation in the Second Life client, users may be vulnerable.

The traffic will be difficult to block. As SANS notes, the traffic can go over any valid port, and it seems that 80 and 443 would be popular choices.

The best method I've found for preventing successful exploitation is to set the client's RTSP proxy setting. The vulnerability is in RTSP only, not HTTP streaming, which is much more popular. In Quicktime you can disable RTSP streams while allowing HTTP streams to work by configuring an invalid RTSP proxy in the Quicktime control panel.

On Windows you can do that by going to Start > Control Panel, double click the Quicktime icon, click on the Advanced tab. Select (check) RTSP Proxy Server. In the Address field, type in "127.0.0.1" (without quotes).

Note to Apple: Please don't store common settings like RTSP proxy in binary files. That's what the Windows registry is for. With the RTSP proxy setting stored in a per-user binary file (C:\Documents and Settings\<user>\Local Settings\Application Data\Apple Computer\QuickTime\Quicktime.qtp) it'll be difficult for companies to change this through a script for company-wide mitigation.

Also, here's the final signature that was accepted into Bleeding Edge Threats:

#Joint contribution from Andre Ludwig, Blake Hartstein, and Chris Byrd at riosec.com
alert tcp $EXTERNAL_NET 554 -> $HOME_NET any (msg: "BLEEDING-EDGE WEB-CLIENT Apple
Quicktime RTSP Content-Type overflow attempt"; flow:established,from_server;
content:"RTSP/"; nocase; depth:5; content:"|0a|Content-Type|3a|"; nocase;
distance:0; content:!"|0a|"; within:50; reference:url,www.kb.cert.org/vuls/id/659761;
reference: url,www.milw0rm.com/exploits/4657; classtype:attempted-user; sid:2007703;
rev:2; )

Two notable changes over what I've posted here before. First, adding distance:0 is important in the rule. That anchors the content search at the end of the previous search. Without it, the next content match would have started from the beginning of the capture. Second, after discussion it has been combined back into a single rule. Although it may be possible to bypass with response splitting (that has yet to be proven), simplicity wins out in this case.

On a final note, while I'm a big Apple fan myself, I'm disappointed that there is still no official acknowledgement of the vulnerability or workarounds. I understand that it takes a while to QA fix, but it's still being offered up to unsuspecting people for download off of their site without a notice that it is exposing anyone who downloads it to a security vulnerability. Time to step up, Apple.