Or Role-Based Access Control?

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!

“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.

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.

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.

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”.

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.

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.