Back to Top

Tuesday, August 14, 2007

The case of the missing blog post

After seeing the post on rootkit.com about Atsiv I planned to take a look at it because the official announcement (which is by the way now changed to a reply to Microsofts actions) didn't give any details. Fortunately people smarter than me did that (proving the old saying that if you can do something today, leave it for tomorrow, maybe you don't have to do it), basically confirming my own suspicion that this tool is basically a signed driver to load other drivers.

I always been skeptical of driver signing as a security measure, but I assumed that it was done to enforce some quality (ie. that the driver had to be submitted to MS before it could get signed so that they can do some quality control on it). However after these happenings it is clear that this is not the case, the only thing you have to have is money (and it can be someone else's money too - from a stolen credit card for example :( ). On one case this is understandable, because in this system MS doesn't have to commit resources / it doesn't become a bottleneck in kernel development, on the other hand this negates the only possibly positive aspect of the driver signing requirement and it makes it look like a money making scheme for CA's.

(Further clarification: I've found an MSDN blog post that hints to the fact that the original plan was in-line with what I envisioned - drivers could be signed only if they passed the WHQL testing - but the process was later relaxed)

Here is also an other (possible) advantage to driver signing:

A primary benefit of KMCS is that it provides a means to identify the author of a piece of code, which helps enable follow-up with the author to address crashes that are observed through mechanisms such as Microsoft Online Crash Analysis.

However I claim that a similar level of traceability could have been assured by lower cost certificates.

Now back to the main topic of this post: Alex Ionescu has published (and shortly after pulled) a tool dubbed Purple Pill which used the following technique to load unsigned drivers: It dropped a perfectly good driver (signed) from ATi which had a design flaw that allowed arbitrary memory writes, loaded it, and then used it as a trampoline to load the unsigned driver. He claimed that this approach is superior since it activates Vista's DRM paranoid mode when the unsigned driver is loaded and thus it can not be used to circumvent it. Very shortly after publishing it however he pulled, saying that there is the potential (well, duh) that it could be used by malware.

My predictions are:

  • We are getting closer and closer to loading unsigned drivers on Vista (without special boot options, etc), and in the first half of 2008 (the latest) we will see a solid method to do it.
  • After that Chinese and Taiwanese manufacturers will start using in their driver install kits (which are well known for their great quality), making it an uphill battle for Microsoft to enforce it.
  • There will be several malicious individuals willing to cough up the money (probably someone else's money) to buy such a certificate
  • There will be several flaws discovered in third party drivers which could lead to similar actions, and it is possible for the bad guys to purposefully create such flawed drivers (for example by creating a freeware hex editor which has a flaw in the driver allowing it to do arbitrary memory overwrites and then packaging this driver with their rootkits). I will be very curious what MS's reaction will be to such attempts? Will they simply revoke the certificate of such programs? If yes, it means that your certificate can be revoked instantly just because you've had a bug in your program. If no, it means that the driver signing is not really a security solution, more a money making solution.

0 comments:

Post a Comment

You can use some HTML tags, such as <b>, <i>, <a>. Comments are moderated, so there will be a delay until the comment appears. However if you comment, I follow.