ARDAgent Exploit, MacOS X Malware, and Snow Leopard, Oh My!

As also reported by Intego and Matasano, a new local privilege escalation vulnerability has been found that gives local root access on MacOS X Tiger and Leopard.  While Intego calls this a critical vulnerability, I’m mostly with 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 MacOS 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 web 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 MacOS 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 MacOS X security, and how many users will install it.

Snow Leopard will hopefully raise the bar for MacOS 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 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.

Comments

  1. FYI: Many Mac servers are always logged in because the Rerospect extension only runs with a user logged in. Yes, Legato (EMC) is sad.

  2. john fsck says:

    Hey,

    WRT NX, I believe 64bit binaries have a non executable heap on OSX?
    For instance this covers httpd and some other daemons on OSX Leopard.

  3. Dino Dai Zovi says:

    @Chris

    This exploit requires that the user running it is the *same* user as who is logged in. Any user logging in remotely as the user who has access to Retrospect most likely already has all the access that they need :).

    @john

    You are right, x86-64 actually has a non-executable heap, but it is more the fact that all writable memory is non-executable. This is not due to NX, which is a x86 PAE thing, it is due to the fact that on x86-64 page permissions are actually meaningful and Apple has been careful to restrict page permissions to the minimum necessary. On x86, a page of memory is executable if it is marked readable (hence the need for the dedicated NX bit). Running vmmap on a 64-bit process like httpd shows that not a single page of memory is readable, writable, and executable at the same time.

  4. john fsck says:

    Sorry dino, I should have been more clear on that. Thats what you get for posting on blogs from work :P

    I think that is probably part of the reason Apple didn’t spend the $$ or engineering man power on getting ASLR terribly right. In fact their ASLR is a bit of a token effort to say “We have ASLR”.

  5. Joanna Rutkowska says:

    Hi Dino,

    I would argue that any kind of bug that allows for local-root-priv-escalation is should be treated as a critical. If we could eliminate all priv-escalation bugs, then we would be able to solve a lot of security problems on consumer OSes, e.g. Windows, that we have today. All those personal firewalls, and Host IDS/IPS systems would actually make sens then. Right now they don’t, just because malware is able to get into kernel (and right getting the root access on OSX is equivalent with getting into kernel).

    After all, you wrote it yourself that you wish to see more “Sandbox policies for Safari, Mail.app, and third-party applications.” — and what is sandboxing if not protecting the root/kernel from malware in the first place?

    I totally agree with you on the kernel component mandatory signing, more over, I think this should be extended to cover also all the usermode apps as well. However, assuming that this would protect the kernel from compromises is a wrong. Alex and myself has demonstrated this at Black Hat 2006 and 2007, taking Vista and its mandatory kernel code signing scheme as an example. One can’t effectively protect a monolithic kernel — the potential attack space is just too large. Especially, if we allow root-escalation attacks.

  6. Dino Dai Zovi says:

    Hi Joanna,

    I agree with you that having more defense-in-depth on individual systems would be good. But if we treat every local privilege escalation as critical, how do we treat remote (including client-side) exploits? Ultra-double-plus critical? I think with any system, once an attacker has remote code execution (even unprivileged), you have begun to lose the battle.

    I know that you love going straight to the kernel, but there is still a lot of badness that can be done without even obtaining root access, especially the kind that most malware would be interested in (showing ads, stealing passwords, data, etc). It’s just not as stealthy and not nearly as interesting.

    As for your attacks against Vista, I believed from the beginning that MS should have just encrypted their swap files, which would have stopped that specific attack as well as better protected the users data. I agree with you that protecting a monolithic kernel can be very difficult, especially when third parties are writing drivers for it, which as you also demonstrated, can be abused by attackers to get into the kernel also.

    Maybe we should just forget about protecting the kernel and just try to secure the hypervisors. There is no legacy code there, the entire thing can be written with modern secure coding techniques and have a smaller attack surface by design.

  7. Joanna Rutkowska says:

    Dino wrote:

    “But if we treat every local privilege escalation as critical, how do we treat remote (including client-side) exploits? Ultra-double-plus critical?”
    ;)

    Ok, so here’s an example of why a local-root exploit might be sometimes more dangerous then a remote-browser one. Before I switched to Mac, I used to use Vista system on my primary laptop. In order to somewhat secure it I used to run various programs using different accounts, e.g. my Web-browser (used for non-critical tasks) used to run as ‘joanna.web’, while my email client as ‘joanna.email’, etc. I also made use of some other sandboxing technologies available on Vista.

    So, in that case I didn’t care much about a bug in my browser, because all the attacker could get, theoretically, was just joanna.web’s privileges which pretty much meant only an access to my c:/tmp directory.

    But if somebody could use an exploit to elevate from joanna.web to admin/kernel, then all my clever security setup turned out being useless.

    Right now I’m using VMWare Fusion to run my browser and the situation is similar, with the difference that now an attacker needs to have a VMWare Fusion escape exploit, which I believe are a bit harder to find then local kernel exploits for Vista or Mac. Although, I must say, running a bowser inside VMWare Fusion sucks for various reasons (and the same for Parallels).

    Should we give up on securing guest OSes and focus only on securing hypervisors? If we followed this way of thinking then we should remove all the security mechanisms from the OS (ACLs, different user accounts, etc). I don’t like this approach — it’s inelegant, although I do think that secure hypervisors can be used as a remedy for current OS security problems. Heck, we even are engaged in a project in this area, but still I think we should not give up on securing guest OSes.

  8. Dino Dai Zovi says:

    @Joanna

    Even though, in your setup, it is the local exploit that you consider to be the damaging one, getting remote code running in your e-mail client or web browser is still bad. I think it’s getting the foot in the door that is the most serious on a single-user desktop because no matter what, at that point your privacy and security is violated. On multi-user interactive servers, a local vulnerability is more critical, but still not as critical as a remote vulnerability in my mind.

    I guess I was quick to write, “forget about protecting the kernel,” but should have written “focus on securing the hypervisor over making a secure non-monolithic kernel.” I basically think that eventually the hypervisor will become what we think of as the “kernel” and our current kernels will become “servers” that run on top of it. And what do we have then? A microkernel! In Tanenbaum and Torvolds’ classic debate, Tanenbaum finally wins!

  9. Boyd Waters says:

    Is there any work currently being done on Mandatory Access Control?
    Like
    http://www.sedarwin.org/
    ?

    Or Role-Based Access Control?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 3,530 other followers

%d bloggers like this: