August 11th, 2006

Impact of Vista x64 signed driver requirement bypass

Posted by George Ou @ 12:51 am

Categories: Defcon2006, Security, Vista

Tags:

At DEFCON 2006, I had a chance to sit down with Joanna Rutkowska who is a researcher from Poland working for Singapore-based Coseinc.  Rutkowska had presented two security presentations at Black Hat 2006 (occurred right before DEFCON 2006).  The first presentation detailed a way of bypassing Vista x64 signed driver requirement and the second presentation showed a proof-of-concept Hypervisor-based rootkit called "Blue Pill".  This blog will focus on the first presentation which shows how to bypass Vista x64’s signed driver requirements and we’ll leave Blue Pill for a subsequent blog.

Windows Vista x64 (hybrid 32/64 bit x86 OS) will implement additional kernel tampering protection against unsigned code or drivers.  This goes beyond the normal user-based security model and even prevents administrators from loading unsigned device drivers in to the OS.  Rutkowska figured out a way to bypass this restriction using the following technique:

• Fill up a computer’s available physical memory with anything to force a shortage of RAM and cause unused driver code to go in to the page file (a page file is space allocated on a hard drive that emulates more physical memory).  The shifting of kernel code in to the page file is known as "kernel memory paging".
• Replace that code living in side the page file with desired shellcode using raw disk write techniques which bypasses the OS mechanisms for preventing this.
• Ask the kernel to call the code living inside the page file.  The kernel is unaware of the fact that the code had been tampered with through raw disk modifications and executes the shellcode.

This means that system administrators will be able to bypass the signed driver requirement in Vista x64 using Rutkowska’s method to modify the kernel.  This effectively defeats one of the security mechanisms in Vista x64 and allows administrators the ability to deliberately or accidentally install Malware in to the kernel.  In fairness, Rutkowska stated in her presentation that it is very difficult to implement a fool proof kernel protection mechanism in a general purpose operating system.  This does seem like a daunting task since we’re trying to prevent a determined system-level administrator from modifying their own kernel.

Rutkowska presented three possible ways that Microsoft could close this loophole.  They are:

• Forbid raw disk access which may not be very practical since it would prevent legitimate applications like defrag applications from working.  It would still be possible to create a third party raw disk access application.
• Encrypt the paging file to prevent arbitrary tampering of it.  I didn’t get a chance to ask Rutkowska if Vista’s full disk encryption feature would work and I’ll try and get an answer from her.
• Disable kernel memory paging which Rutkowska estimates may eat up 80 megabytes of physical RAM and increase RAM requirements.  Given the current price of RAM, this may not be such a bad idea.  This could already be done with the registry but someone could simply undo that registry modification and reboot.  This would effectively put us back right where we started.

So what is the impact of this loophole?  It probably isn’t the end of the world though it effectively nullifies Vista x64’s claim that unsigned drivers will be rejected even when they’re being installed by an administrator.  Of course there are some mitigating factors to this loophole and the biggest one is UAC (User Access Control).  Windows Vista will default all users to standard users which will lack the ability to install unsigned code or any code in the first place with system level permissions.  The problem as Rutkowska points out is that most people will simply hit "accept" when they’re installing an unsigned driver if they are running as an administrator or they will type in their admin password and escalate if they are standard users.

I pointed out that there is an additional security mechanism for the security conscious and it would be easy for a domain administrator to restrict even administrators from escalating unsigned code to system level access as an enterprise wide policy.  This would not only block kernel level modification, it would block system level modification of any unsigned code which would be highly desirable from a security point of view and Rutkowska admitted this would probably work.

Privilege escalation restrictions would even work for home users using local policy restrictions and I would probably turn this feature on for friends and family that I’m building computers for who need the ability to install legitimate applications but aren’t savvy enough to avoid dangerous applications.  As far as I’m concerned, escalating unsigned code to system level privilege that you have no idea where it came from or if it has been tampered with is like handing any stranger on the street the keys to your car.