Four days after news of the recent Apple QuickTime vulnerabilitybegan to spread, a new proof-of-concept exploit, with a twist, has beenpublished. While the shell code in the previous exploit was containedwithin a malicious RTSP data stream, this time the shell code is sentvia JavaScript, separate from the stream.
Let’s break down how this might play out. A client requests a Webpage from a malicious site. The page that is sent contains maliciousshell code and a request for a QuickTime movie. If the client is usingInternet Explorer, the shell code is written to a heap area for lateruse. Meanwhile, the browser receives the QuickTime movie and then opensit 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 theclient’s QuickTime install. The end of the buffer overflow then callsthe shell code that was previously written to the heap, and voila!, themalicious code is executed.
This method of exploiting the vulnerability has its advantages anddisadvantages. On the plus side, the server hosting the exploit musthave a hacked RTSP server for this to work, since standard RTSP serverswill not operate in this way. On the downside, this new exploit makesit much easier for attackers to use their own shell code in an attackusing this vulnerability.
The good news is that this exploit is easily enough avoided bytaking a few precautionary measures. Symantec antivirus products withthe 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.