It quickly turned out that our exploit doesn’t work anymore! The reason: Vista RC2 now blocks write-access to raw disk sectors for user mode applications, even if they are executed with elevated administrative rights.In my Subverting Vista Kernel speech, which I gave at several major conferences over the past few months, I discussed three possible solutions to mitigate the pagefile attack. Just to remind you, the solutions mentioned were the following:
1. Block raw disk access from usermode.
2. Encrypt pagefile (alternatively, use hashing to ensure the integrity of paged out pages, as it was suggested by Elad Efrat from NetBSD).
3. Disable kernel mode paging (sacrificing probably around 80MB of memory in the worst case).
And I also made a clear statement that solution #1 is actually something which is a bad idea. I explained that if MS decided to disable write-access to raw disk sectors from usermode, not only that might cause some incompatibility problems (think about all those disk editors, un-deleters, etc…), but also that would not be a real solution to the problem…
Imagine a company wanting to release e.g. a disk editor. Now, with the blocked write access to raw disk sectors from usermode, the company would have to provide their own custom, but 100% legal, kernel driver for allowing their, again 100% legal, application (disk editor), to access those disk sectors, right? Of course, the disk editor's auxiliary driver would have to be signed – after all it’s a legal driver, designed for legal purposes and ideally having neither implementation nor design bugs! But, on the other hand, there is nothing which could stop an attacker from “borrowing” such a signed driver and using it to perform the pagefile attack. The point here is, again, there is no bug in the driver, so there is no reason for revoking a signature of the driver. Even if we discovered that such driver is actually used by some people to conduct the attack!
But it seems that MS actually decided to ignore those suggestions and implemented the easiest solution, ignoring the fact that it really doesn’t solve the problem…
Actually, if we weren't such nice guys, we could develop a disk editor together with a raw-disk-access kernel driver, then sign it and post it on COSEINC's website. But we're the good guys, so I guess somebody else will have to do that instead ;)
Kernel Protection vs. Kernel Patch Protection (Patch Guard)
Another thing - lots of people confuse kernel protection (i.e. the policy for allowing only digitally signed kernel drivers to be loaded) with Kernel Patch Protection, also known as Patch Guard.
In short, pagefile attack, which I demoed at SyScan/BackHat is a way to load unsigned code into kernel, thus it’s a way to bypass Vista kernel protection. Bypassing kernel patch protection (Patch Guard) is a different story. E.g. Blue Pill, a piece of malware which abuses AMD Pacifica hardware virtualization, which I also demoed during my talk, “bypasses” PG. The word “bypass” is a little bit misleading here though, as the BP does not make any special effort to disable or bypass PG explicitly, it simply doesn’t care about PG, because it’s located above (or below, depending on where your eyes are located) the whole operating system, including PG. Yes, it’s that simple :)
Also, almost any malware of type II (see my BH Federal talk for details about this malware classification) is capable of “bypassing” PG, simply because PG is not designed to detect changes introduced by type II malware. So, e.g. deepdoor, backdoor which I demonstrated in January at BH Federal, is undetectable by PG. Again, not a big deal – it’s just that PG was not designed to detect type II malware (nor type III, like BP). So, I'm a little bit surprised to hear people talking about "how hard would it be to bypass PG...", as that is something which has been done already (and I'm not referring to Metasploit's explicit technique here) - you just need to design your malware as type II or type III and your done!
But even that all being said, I still think that PG is actually a very good idea. PG should not be thought as of a direct security feature. PG's main task is to keep legal programs from acting like popular rootkits. Keeping malware away is not it's main task. However, by ensuring that legal applications do not introduce rootkit-like tricks, PG makes it easier and more effective to create robust malware detection tools.
I spent a few years developing various rootkit detection tools and one of the biggest problems I came across was how to distinguish between a hooking introduced by a real malware and... a hooking introduced by some A/V products like personal firewalls and Host IDS/IPS programs. Many of the well known A/V products do use exactly the same hooking techniques as some popular malware, like rootkits! This is not good, not only because it may have potential impact on system stability, but, and this is the most important thing IMO, it confuses malware detection tools.
Patch Guard, the technology introduced in 64 bit versions of Windows XP and 2003 (yes, PG is not a new thing in Vista!) is a radical, but probably the only one, way to force software vendors to not use undocumented hooking in their products. Needles to say, there are other, documented ways to implement e.g. a personal firewall or an A/V monitor, without using those undocumented hooking techniques.
Just my 2 cents to the ongoing battle for Vista kernel...
