Black Hat letdown

I went to Black Hat over Wednesday and Thursday. The presentation most people wanted to see (including me) was Joanna Rutkowska breaking the Vista x64 driver signing that I hate so much. I wanted to see what trick she’d found. I was let down, however, when she presented her technique.

Her trick was to allocate a bunch of memory so that the kernel pages itself and drivers out, uses raw disk access to overwrite the pagefile, then does an uncommon operation that causes her desired code to execute in kernel mode. Sound familiar? This is the same thing I proposed as a reason why x64 driver signing is pointless when I whined about the real reason for driver signing. I’d already thought of it, so it was nothing new to me, like most of the rest of the conference.

Obviously, Joanna thought of it long before I did, so there is nobody to blame for it. Except, I guess, Microsoft.

5 thoughts on “Black Hat letdown”

  1. I really think that Microsoft’s response to this is going to be to make raw disk access only possible from kernel mode. That will result in a large number of third-party drivers whose sole purpose is granting access to disks from user mode again. Developers will just work around it, and you can use those drivers combined with the pagefile trick to do your rootkit installation. (Rootkit malware authors generally don’t care about copyright law so they’ll just copy Symantec Ghost’s driver or whatever.)

    myria

  2. Your logic doesn’t make sense.

    Vista driver signing cannot be to enforce DRM, because as you said yourself, you can disable it at startup. So anybody who wants to load new kernel drivers (for development or whatever) can do so.

    Now WMP may refuse to play if it can’t check the drivers are signed. But, this check already occurs in XP! So it’s nothing new that would require kernel level driver signature checking.

    I don’t see how you expect Microsoft to improve security without first protecting the kernel from attack. Either you think malware, botnets, spam relays etc are bad and that Microsoft should try and stop them, in which case the kernel has to be secured as it’s the base on which the rest of the system lies. Or you don’t think that’s as important as allowing arbitrary code to be loaded into the kernel, in which case I guess we have different value systems.

    As to most rootkits not being kernel mode – right, but so what? If you can’t secure the kernel you can’t make any headway against blocking these userland rootkits either (eg by protecting specific registry keys). The kernel MUST be secured before anything else can be meaningfully done.

  3. I think the difference is that in XP, you’d check the signatures on the video/sound drivers, to make sure the “graphics card” you’re writing that pay-per-view movie to isn’t really “vid2file.sys” – but, of course, a suitably-written driver could capture that from kernel mode without officially appearing as part of the graphics/sound path: from kernel mode, you can tamper with other drivers without anyone knowing.

    Vista, by disallowing that driver entirely, closes that loophole: you can’t get anything into kernel mode except a signed driver. (Of course, there seems to be nothing to stop that simply being a signed ‘vidgrabber.sys’ anyway, but that’s another step..)

  4. I dont understand how the use of ‘raw disk access to overwrite the page file’ is supposed to work. Here are the reasons,

    To make sure you don’t corrupt your pagefile while you overwrite it, cannot be done from user mode. You dont want other stuff to get paged out while you are doing your operation. The only way is to write a driver code, and raise the IRQL to above/at DISPATCH_LEVEL to make sure nothing gets paged out or paged in. But this is like the chicken and egg problem. Without signing your driver you will not be able to load it. And without loading your driver, you will not be able to exploit this?

    Am I missing something here?

Leave a Reply to Anonymous Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.