I had the opportunity to attend at talk by Mark Russinovich, of Sysinternals fame, during last week’s Trustworthy Computing Conference. The topic of the talk was about security boundaries in Windows, and more specifically, what is not a security boundary. The talk was very interesting, and I don’t want to reveal too much here, but there was one part of it that stuck with me and has been bothering me for a little while now. One of the technologies he addressed was Patchguard, or Kernel Patch Protection, which was introduced in 64-bit Vista and Server 2008. Patchguard is intended to keep programs from patching, hooking, or otherwise tampering with the internals of the NT kernel. It does this by periodically taking a checksum of some important structures in the kernel (SSDT, interrupt table, HAL tables, etc) and comparing the current value with the previous one. Any discrepancy here will indicate that the kernel has been subverted. If it notices any changes to these structures, it throws an exception which throws a blue screen error. Sounds good, right? Sounds like a great new security feature, no more rootkits! Well, not really. The truth is, KPP really does nothing to stop malicious code, and in fact, is pretty useless in doing so. Mark revealed in his talk, that that was never the intention of KPP, but rather, it was conceived as a way to force legitimate developers to stop using these techniques in their own programs. See, most anti-virus and security products will use some level of system hooking in order to get a good view of activity. In fact, one of Mark’s very own tools, RegMon, hook’s the SSDT to watch registry activity. He even wrote a publication about the technique! The problem with kernel hooking is that it is entirely unsupported and significantly reduces stability.
So here’s what I don’t understand. Microsoft has recognized that system hooking leads to instability. They’ve decided that programmers aren’t good enough to extend a kernel function safely without throwing a blue screen exception, so now they’re not going to allow us to hook certain system structures (pfft, allow is a funny thought). But, instead of actually fixing the gaping holes in their system, they’re going to simply watch for system hooking, and then guarantee that the system will crash, by causing the crash. Oh yeh, and they are going to blame it on the developer. It’s like a car company deciding that talking on your cell phone while driving is dangerous, so they’re going to create a system that detects if you’re on the phone and then drives the car off the road for you. That will show you!
I just don’t understand this anti-feature. There are plenty of legitimate reasons for hook these system functions, and it can be done safely. I know it can because Mark has done it, and I’ve done it. If you don’t want developers to subvert the kernel, then provide a complete API that we can use to extend and monitor the system, and fix the problems with your system that allows someone to take write-protected virtual memory, map it to physical memory, strip all the restrictions off of it, and send it back patched. Don’t just come behind perfectly valid code, throw an exception and blame it on us.
