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 :)
20 comments:
As well as the insecurities you have highlighted surrounding those things, saving 80MB etc, ain't a bad thing anyway.
Plus disabling the Swap/Paging file, providing you have enough RAM of course, has been recommended by me + others for quite some time, as a very good extra Privacy/Security consideration.
So whichever way you look at it, NO Paging is the way to go ....
Spanner
SpannerITWks
Just to make it clear - I recommended only to disable *kernel* memory paging, not paging altogether.
re: "As well as the insecurities you have highlighted surrounding those things, saving 80MB etc, ain't a bad thing anyway."
I think you have it backwards. In order to fix the 'insecurity' by turning off exec+driver paging (the kernel never pages anyway), you have to spend 80MB.
Checksumming is a way to avoid spending that 80MB, at some small cost in CPU.
There's no method proposed here to reduce your memory footprint by 80MB from the as-shipped configuration.
-dave
No, it wasn't Brad who pointed out this solution, it was in this post:
http://blog.bsd.org.il/index.php/2006/08/13/invisible-research/
I still think it was Brad, as the post you're referring to was published more then a week after I met Brad at defcon... sorry ;)
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.
Don't forget that criminals and malware authors can easily get certifaces via falsified credentials and other chicanery.
Don’t forget that criminals can just kidnap your g/f and ask for your secret data (in return for her life) – does that mean we should give up on all the security technology?
Joanna,
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.
What do you think?
Regards Pixon
I’m gonna shot the next person who can’t distinguish between Blue Pill and “pagefile” attack! ;)
Hi Joanna,
Sorry, I meant pagefile attack...
But, anyway, you did not answer my question. So, what is the real risk?
Pixon
Even with the Blue Pill, question remains valid: What is the real risk?
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.
"Don’t forget that criminals can just kidnap your g/f..."
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.
- Rossetoecioccolato.
:)
"inside the matrix"
ahahahahahaha!!
hey, Gigabyte! its you! i know it is! ;-P
"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 :)"
how is size calculated for hashing?
can size change?..etc ;)
well, i guess it is time to retest this with rc2 :)
Have you tested on RC2?
Let us know.
Yo joanna, what about the latest build of Vista, still vulnerable?
and it'll be nice to see PoC codes for BP and the pagefile attack...
Post a Comment