A Spanish security researcher has discovered a new vulnerability in Apple’s QuickTime software that can be used to bypass both ASLR and DEP on current versions of Windows and give an attacker control of a remote PC. The flaw apparently results from a parameter from an older version of QuickTime that was left in the code by mistake.
The flaw was discovered by Ruben Santamarta of Wintercore, who said that the vulnerability can be exploited remotely via a malicious Web site. On a machine running Internet Explorer on Windows 7, Vista or XP with QuickTime 7.x or 6.x installed, the problem can be exploited by using a heap-spraying technique. In his explanation of the details of the vulnerability and the exploit for it, Santamarta said that he believes the parameter that is at the heart of the problem simply was not cleared out of older versions of the QuickTime code.
The result of the problem is the creation of what amounts to a backdoor in the QuickTime code, Santamarta said. “WATCH OUT! Do not hype this issue beyond it deserves. This time Backdoor
!= malicious code but a horrible trick a developer implemented during
the development cycle.These hacks could end up having a harmful impact,” he wrote in his blog post explaining the vulnerability.
Santamarta has sent the exploit code to the folks at the Metsploit Project and there will be a Metasploit module available for this attack soon.
“The Quicktime plugin is widely installed and exploitable through IE; ASLR and DEP are not effective in this case and we will likely see this in the wild,” said HD Moore, founder of the Metasploit Project.
Moore added that it looks right now as though the bug is exploitable only through Internet Explorer, and is likely to be exploited through drive-by download attacks.
From Santamarta’s advisory:
Reversing this function we can see that, in certain cases, QTPlugin.ocx
could be instructed to draw contents onto an existing window instead of
creating a new one. Mistery [sic] solved.
However, although this functionality was removed in newer versions, the
param is still present. Why? I guess someone forgot to clean up the
code .
We are controlling the IStream Pointer passed to
CoGetInterfaceAndReleaseStream, at a certain point during the execution
flow of this function, an IStream method is going to be referenced.
ole32!wCoGetInterfaceAndReleaseStream -> ole32!CoUnmarshalInterface -> ole32!ReadObjRef -> ole32!StRead < = p0wn!!
So all we need to do is emulate a fake IStream interface in memory. How? aligned heap spray FTW!
Santamarta’s exploit involves creating a fake pointer in memory aas part of the heap-spraying technique.
“As you can see a couple of gadgets are used, since this is a ROP
exploit, however esp is not controlled at all. I’m taking advantage of
common code generated by c++ compilers to control parameters and
execution. The gadgets come from Windows Live messenger dlls that are loaded by default on IE and have no ASLR flag,” Santamarta said in his advisory.
Santamarta was one of the researchers who, in parallel with Tavis Ormandy, discovered a serious bug in Java in April.
