New QuickTime Flaw Bypasses ASLR, DEP 162
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."
Re:Well duh. (Score:5, Interesting)
This boils down to doing a heap spraying attack, and those are in the general class of exploits that ASLR (and to a lesser extent, DEP) are designed to prevent. However, it's fairly well-known at this point that ASLR can be defeated (sometimes) by well-crafted heap-spraying attacks. (Likewise, DEP can be defeated by stack-smashing using return-oriented programming.)
Re:Well duh. (Score:1, Interesting)
Indeed, ROP is fun and the easiest technique to exploit classical buffer overflow bugs right now, but this is only because the compiler is too lax at implementing canaries and ASLR is crap.
ASLR when performed right is unbeatable in the same way as 256-bit key encryption is, and I think the final nail on the code execution coffin will be full ASLR rather than DEP and Stack protection. The problem is that ASLR as shipped right now in most systems is far too weak and in some places it doesn't exist at all, giving the attacker a known environment. In certain circumstances, data corruption is as good as data execution - if it can be done in a predictable way, the game is over.
Full heap randomization and good canary protection should be priorities for the OSes which aren't doing it right now. Linux, for all its security aura is particularly shameful. Apparently keeping your data from organized crime isn't worth a 10% speed-down in Phoronix.
Re:ew quicktime? (Score:3, Interesting)
Re:Quicktime Uninstalled (Score:1, Interesting)
I have now uninstalled the Quicktime player. Would Quicktime Alternative be any safer? Seems Apple has had a rash of security issues lately.
Depends on what you want it for, but VLC is always a good alternative.
Windows 7 have basic support for playing mov files, without having to install Quicktime (and yay! for that). If you think upgrading to Win7 just for that is a bit overkill (it is of course :), your concern was security and Windows 7 is significantly better than XP overall in that regard.
Re:ew quicktime? (Score:4, Interesting)
Another outstanding reason to avoid shiny geegaws from an evil company.
To be fair, the flaw is almost a first for Quicktime --an ancient product line predating iProducts, back when "multimedia" came in big letters on all home computers and all videos on the web were MPEG or MOV downloads. What is so bad is how we sleep in our laurels and wake up to find that we falsely associated safety with it because QT ran on a little targetted OS before it was ported to Windows...
IIRC, Apple isn't the number one seller of smartphones nor MP3 players, or distributor of Windows Multimedia readers. Yet it's generating enough attention to get exploited. Even if you and I don't own recent apple products, we have been falling in a parallel situation and taking it for granted again: all those free Google clients downloaded over the years have become a juicy target. All we need is someone to find a weak spot.
Scratch that! All we need is an unlikely "someone" among that small group who will PUBLISH the weak spot of that juicy target. All the others just exploit it for months without us being the wiser.
Hold on (Score:3, Interesting)
If a badly-written program can circumvent ASLR and DEP for itself, then aren't DEP and ASLR a bit useless? The point of them is to prevent data execution, and to randomise the address space. How does a badly-written, ancient program "bypass" such measures? I can understand such measures not being applied (e.g. because ASLR or DEP on really-old code would break it because it was written with certain assumptions) but what that then assumes is that some administrator or Microsoft programmer has chosen at some point to disable DEP and ASLR for those old programs (if they have DEP and ASLR enabled at all). And if the code wasn't compiled without some DEP/ASLR magic enabled, then is this really surprising? What's to stop any other program similarly avoiding DEP/ASLR, or anyone exploiting such programs?
How is this a "Quicktime problem" when the code being attacked is years old, and yet the OS still lets it break basic security? Surely the problem is not the program, but the things that let it execute. Hell, I have used old Windows programs that refuse to work with DEP enabled because they make certain assumptions and I realised that because the DEP handler would prevent them working in XP - they were NOT compiled at a time when any knowledge of DEP or ASLR on Windows was around. That's the whole point of DEP, isn't it? To stop programs executing code they shouldn't? I had to force an override for them network-wide but that was my choice, and no I did not specifically enable DEP myself, the Windows XP install decided to do that for me.
Is this version of QuickTime whitelisted? Are DEP and ASLR really that worthless that "old programs" compiled before they came along are allowed to do anything? Isn't this the fault of an administrator running an outdated program rather than anything to do with DEP, ASLR, Quicktime or anything else? What's Quicktime doing differently to every other old, insecure program out there that makes it more of a risk?
Seems like a complete red herring to me. Don't run old software. Don't run insecure software. Don't run programs that you haven't authorised yourself. And, apparently, don't rely on DEP or ASLR to actually DO anything.
Re:Full advantage? (Score:3, Interesting)
The thing I love about the iPhone is the lack of OS X integration. It works via iTunes, just like an iPod, meaning that you have to plug in a cable to sync. Meanwhile, almost every other phone (including my last four, two from Ericsson and two from Nokia), sync via bluetooth in iSync, so you just put them in the same room as the Mac and click on the 'sync now' button in the top-right of the menu bar. All of your calendars, contacts, and notes are sync'd. You can transfer photographs and other files by browsing the device in the Bluetooth File Transfer thing and dragging them to or from Finder windows, or you can send them via OBEX from the phone and have them appear automatically in a folder that you designate.
It's almost like the iPhone team had never actually used a Mac.
Re:ew quicktime? (Score:3, Interesting)
Yes I do believe that the exposure in the PDF problem was Apple's fault due to a flaw in iOS. You might also recall (or maybe not given your response) that Apple closed that exposure (not Adobe).
The owner of the exposure was clear, just as it is clear in this case. If ASLR and DEP fails to protect against such an exposure, they are flawed.
Re:ew quicktime? (Score:3, Interesting)
Also curious if this exploit really only affects IE? If it doesn't affect FireFox doesn't that mean that IE is also part of the problem?