Wednesday, September 13, 2006

Vista RC1 still vulnerable to the pagefile attack

Everybody talks now about the latest Vista RC1 and how ready it is for being shipped to customers. So, I downloaded Vista RC1, Build 5600, x64 edition from MSDN a couple of days ago and gave it a try... To my surprise, it turned out that it's still vulnerable to the signature check bypass attack which I demonstrated nearly 2 months ago at the SyScan conference...

This is not good, because, on the one hand, Vista requires all kernel drivers to be digitally signed (for security reasons), which, in turn requires that all driver developers get (read: buy) an appropriate signing certificate, but on the other hand, malware authors can load their code into kernel for free (without reboot, as I demoed during the talk).

The requirement for having all kernel drivers digitally signed raised a lot of controversy when it was announced by Microsoft in January. People argued not only about the fact that paying for a certificate might be unacceptable for e.g. students or open source authors, but also about more "philosophical" aspect that it should be the user's (administrator's) right to load whatever she wants on her own computer, regardless whether somebody has signed it or not.

Personally, I think that it's worth to sacrifice a little bit of "freedom" and to spend a few hundred bucks on a certificate in case you're a kernel developer, if this can stop kernel malware from loading. Even though kernel protection can be implemented without PKI, as we can see in case of BSD systems and their securelevel mechanism (although an attack has been presented against it a few months ago), I still think that a scheme based on digital signatures is the best solution for end-users. However, it's definitely not worth to sacrifice that all, if there is a known way for bypassing this mechanism... :(

It's quite surprising for me that MS still hasn't fixed that problem, especially that the best solution here is also the simplest one to implement. As I described during my talk, it's just enough to... disable kernel mode memory paging. Surly, it would cause a little waste of memory, but according to some Microsoft engineers I spoke to, it would be only around 80MB. This seems very little these days, doesn't it? After all, are people going to run Vista with 256MB or even 512MB of RAM? I'm not ;)

Another good solution (and I think it was Brad Spengler of grsecurity who pointed that out to me) would be to calculate a hash for each page which is going to be paged out and then check this hash again on each page which is about to be loaded into memory again. Not that simple as the previous solution, but at least we're saving those 80MB of physical memory :)

Hi Joanna,spender (Brad) here. The hash idea was from the guy in that blog post there; I didn't mention it to you at defcon. My idea was to simply deny raw i/o writes to sectors involved with the swapfile.

One question: What is the likelihood of Blue Pill to happen on a large scale? The impact is huge, but the likelihood: once in a week, once in a month, once in a year, once in 50 years? When you have this number, you can calculate the risk. And it seems that Microsoft did the calculation, and concluded that risk is not high, otherwise they would have fixed the problem.

I don't see any reason why the pagefile attack could not be used in the wild.

As to the BP and all the other hardware virtualization based malware – there is no risk of “massive infection” at the moment, just because there are very few machines with processors supporting those virtualization extensions. Situation will probably change next year, when more people will get those new CPUs.

That's why you should always have more than one. But I suppose that really devious criminals could kidnap your two g/f and your wife and threaten to put them all together in a room so they get to know each other. Then, on the other hand, the criminals could just use a signed Microsoft driver to do what they want. http://www.smh.com.au/news/security/security-conference-to-debut-windows-firewire-crack/2006/09/18/1158431640614.html.

"Another good solution (and I think it was Brad Spengler of grsecurity who pointed that out to me) would be to calculate a hash for each page which is going to be paged out and then check this hash again on each page which is about to be loaded into memory again. Not that simple as the previous solution, but at least we're saving those 80MB of physical memory :)"