Slashdot Mirror


New QuickTime Flaw Bypasses ASLR, DEP

Trailrunner7 writes "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. It was discovered by Ruben Santamarta of Wintercore, who said 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 he believes the parameter at the heart of the problem simply was not cleared out of older versions of the QuickTime code. '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."

1 of 162 comments (clear)

  1. Re:Well duh. by cbhacking · · Score: 5, Informative

    More to the point, this attack uses ROP (which, as you say, defeats DEP) but it does it using bits fo code, called "gadgets", that are part of a library which is loaded without ASLR. Even though the browser itself is using ASLR, some of its libraries will be loaded at known locations, which is what makes this attack work. That's not exactly defeating ASLR so much as it is taking advantage of the fact that it isn't universally used yet, kind of like the way some legacy programs aren't DEP-compatible.

    For the time being, ASLR is only opt-in; if a library doesn't mark itself as ASLR-compatible, the loader will put it at its preferred base address. Or at least, it will try to. The fact is that dynamically linked libraries can never guarantee that their preferred address range is available, and therefore should never assume that they are at a given location in memory. In fact, most of them don't... but they still don't have the opt-in flag, either because they're old or because the developer didn't set it. I wonder how hard it would be to simply *force* ASLR by telling each library, as it loads, that its preferred address is simply unavailable and it's going to be stuck someplace else...

    --
    There's no place I could be, since I've found Serenity...