QuickTime, not Safari, to blame for MacBook vuln
pwn-2-own update
Updated The zero-day vulnerability that allowed a hacker to commandeer a brand new MacBook Pro late last week resides in a flaw in Apple's QuickTime media player, the exploit's author says. The revelation corrects descriptions given last Friday that the exploit targeted Safari.
Dino Dai Zovi set the record straight in a blog posting yesterday. It adds that Mac users browsing with Firefox are also vulnerable if QuickTime is installed and that QuickTime may put Java-enabled browsers on Windows machines at risk as well. Several hours after this story was first published, a new entry appeared that said unnamed sources at 3com have determined the QuickTime flaw is also exploitable on Internet Explorer versions 6 and 7.
Secunia has rated the QuickTime flaw highly critical, its second highest rating. "This can be exploited to execute arbitrary code when a user visits a malicious web site," the site warned. It recommends users disable Java as a work around until Apple releases a patch.
On Friday, Shane Macaulay, a friend of Dai Zovi's who participated in a "pwn-2-own" contest at the CanSecWest conference in Vancouver, described the flaw as residing in Safari. Dai Zovi, who wrote the exploit but didn't actually attend the conference, said on Tuesday that the vulnerability in fact lies in the way QuickTime handles Java. The exploit required a machine visit a booby-trapped website in order to work. Dai Zovi spent about nine hours writing the exploit, which allows a hacker to remotely gain full user rights to the targeted machine.
Under the contest rules, a successful exploit entitled the author to go home with the hacked machine. It also nets him a $10,000 bounty from security provider Tipping Point pending confirmation of the finding.
Dai Zovi on Tuesday declined to discuss the QuickTime in detail other than to say it allows a client-side Java error to execute arbitrary code when a Java-enabled browser visits a malicious website.
Dai Zovi's handiwork is only the latest discovery of a QuickTime vulnerability. Last month, Apple issued an update that plugged eight holes in the popular media playback software. ®
COMMENTS
No excuses
Not checking bounds is always bad. It's one of those things almost everybody does (in particular thanks to the C/C++ languages which leave this task explicitly to the programmers) but it is a very bad practise nevetheless.
Considering the speed of modern hardware, there is no reason to omit bounds checking. It is about time that programmers are getting their butts kicked to always do bounds checking, no exceptions ever allowed. Better still, compilers should be upgraded to apply bounds checking by default.
Until that time comes, we will have to put up with software ridden with security holes and bugs like a Swiss cheese.
I think. . .
I think it's more likely that the flaw is a combination of the two programs, probably Java generating some data, or doing something that it isn't supposed to do, since web java is supposed to play in a sandbox, and then quicktime, when presented with data that is totally unexpected, after all, you can't test for every possible case, and hence overflowing with some executable code causing a remote shell to pop up.
Hmmmmm....
The more we know, the less we know. We now know it wasn't a Safari flaw. So... was it *actually* a Quicktime flaw or (possibly more likely) a Java flaw....
