Four days after news of the recent Apple QuickTime vulnerability began to spread, a new proof-of-concept exploit, with a twist, has been published. While the shell code in the previous exploit was contained within a malicious RTSP data stream, this time the shell code is sent via JavaScript, separate from the stream.

Let’s break down how this might play out. A client requests a Web page from a malicious site. The page that is sent contains malicious shell code and a request for a QuickTime movie. If the client is using Internet Explorer, the shell code is written to a heap area for later use. Meanwhile, the browser receives the QuickTime movie and then opens it with QuickTime, creating an RTSP stream to the malicious server. Only the RTSP server in this scenario is hosting a hacked version, which actually sends back a stream that overwrites the stack in the client’s QuickTime install. The end of the buffer overflow then calls the shell code that was previously written to the heap, and voila!, the malicious code is executed.

This method of exploiting the vulnerability has its advantages and disadvantages. On the plus side, the server hosting the exploit must have a hacked RTSP server for this to work, since standard RTSP servers will not operate in this way. On the downside, this new exploit makes it much easier for attackers to use their own shell code in an attack using this vulnerability.

The good news is that this exploit is easily enough avoided by taking a few precautionary measures. Symantec antivirus products with the latest definitions will detect this threat as Trojan.Quimkids. We also recommend the following options if you’d like to further protect yourself from such attacks:

Prohibit the RSTP protocol on your networks

Unless there is a need for using this protocol, it is best to avoid it for the time being.

Disable QuickTime browser objects

If QuickTime ActiveX controls in Internet Explorer and plug-ins in Firefox are disabled, the exploit will not work.

Disable JavaScript where possible

If the script cannot execute, it cannot write shell code to the heap.

Avoid untrusted QuickTime files

If you’re unsure of the source of a QuickTime file, do not execute it.

Domo arigato to Kazumasa Itabashi for his work in analyzing this new exploit.