Guest Editorial by Dino Dai Zovi
While Intego calls this a critical vulnerability, I'm mostly with Matasano's Thomas Ptacek on this one where I am saying this vulnerability is not nearly that serious. For one, it only works when it is run as the user who is logged into the console. This means that no Mac OS X servers are affected by this, but it can allow a Web exploit or Trojan horse to gain root access without the user's knowledge or permission. Also while root access is pretty serious, it is not necessary in order for the malware to do bad things to your system (i.e. install itself to run automatically, backdoor Safari, etc.) So I will dub this a serious, but not critical, vulnerability.
Perhaps the most interesting fact about this vulnerability is where it came from: a thread (from Google cache because the forums seem to be down now) on the forums at Mac Shadows, a Mac underground site. The aforementioned thread was discussing how to build AppleScript-based Trojans until "callmenames" discovered the vulnerability and the discussion moved towards the vulnerability and ensuing news and attention. And at the time of writing, the forums on the site have been taken offline.
The big question on everyone's mind is when malware will begin to seriously affect Mac OS X and what will happen when it does. As for when, I am betting that it completely depends on market share, as per Adam O'Donnell's game theoretic analysis. As for how bad, that will all depend on Snow Leopard: when it will ship, how it will improve Mac OS X security, and how many users will install it.
Snow Leopard will hopefully raise the bar for Mac OS X as much as Vista did for Windows. Of course it won't stop all security attacks, but it should make exploiting them beyond the reach of most attackers. I'd personally like to see the following improvements:
- Real ASLR (address space layout randomization). Library randomization with dyld loaded at a fixed location just doesn't cut it.
- Full use of hardware-enforced Non-eXecutable memory (NX). Currently, only the stack segments are enforced to be non-executable. Welcome to the new millennium where buffer overflows aren't only on the stack.
- Default 64-bit native execution for any security-sensitive processes. I don't particularly care that it may waste 5% more memory and a little bit of speed, I want Safari, Mail.app and just about everything else that has security exposure to run as a 64-bit process. Simply because function arguments are passed in registers rather than on the stack, this makes working around ASLR and NX damn near impossible for many exploits.
- Sandbox policies for Safari, Mail.app, and third-party applications. Code execution vulnerabilities aren't the only kind of vulnerabilities and good sandbox policies for security-exposed applications can help mitigate the exploitation of code execution and other vulnerabilities in these applications. I love the scheme-based policies, by the way.
- Mandatory code signing for any kernel extensions. I don't want to have to worry about kernel rootkits, hyperjacking, or malware infecting existing kernel drivers on disk. Most kernel extensions are from Apple anyway and for the few common 3rd party ones, they should be required to get a code signing certificate.
I'm hoping that Snow Leopard ships before we see too much Mac malware, fixes all of the above, and that it is a free upgrade. Yes, I know that’s unlikely, but users will not pay money for security features. When users don't upgrade and are subjected to malware, Apple may still get a bad rap for it.
* Dino Dai Zovi is an information security professional, researcher, and author. He is perhaps best known in the security and Mac communities for discovering the vulnerability and writing the exploit to win the first PWN2OWN contest at CanSecWest 2007. He publishes the Trail of Bits blog and can also be found on Twitter.