[clug] A most interesting read, most interesting

Michael Cohen michael.cohen at netspeed.com.au
Thu Dec 28 12:31:27 GMT 2006

On Thu, Dec 28, 2006 at 10:37:30PM +1100, Sam Couter wrote:
> Michael Cohen <michael.cohen at netspeed.com.au> wrote:
> > even if you can only load signed device
> > drivers (which is rediculusly unworkable so I dont think that will even happen)
> You're wrong. Linky:
> http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx

Thanks for that link - this is very interesting. However, As I said _requiring_
all kernel drivers to be signed is simply unworkable in practice, and this is
not what they are doing:

Administrator privilege is required to install unsigned kernel-mode components.
This includes device drivers, filter drivers, services, and so on.

Thats not different from the current situation - you obviously need to be root
to insert kernel modules.

x64 versions of Windows Vista require Kernel Mode Code Signing (KMCS) in order
to load kernel-mode software.

This sounds like all kernel mode drivers need to be signed, but here is the catch:
Components must be signed by a certificate that Microsoft Windows "trusts" as
described in the white papers on this site.

Which means that its pretty easy to bypass this check - you just create a CA,
sign your code with it and add it to the "trusted CA" list - Which is probably
what most OEMs will end up doing. The problem is that kernel mode drivers are
written by heaps of people from virus scanners to security softwatre to
personal firewalls (to developers of these software as well). So its just
unworkable to issue them all with code signing certs. Also once you start
issuing every tom dick and harry with a code signing certificate they become
meaningless because anyone can walk off the street and just buy it.

To the individual who ownes their machine and is determined to load a driver it
should not be too difficult to add a CA - just boot into knoppix, add a
registry key and thats it.

The problem with code signing is that MS has always pushed it as increasing
security, but it doesnt do that at all. Anyone with a certificate can produce
signed code, and if certificates are easy to get, everyone can produce signed
code. There have been a couple of well known cases where some unknown person
obtained a MS code signing certificate from versign. Now thats a scarey concept
- just think, they can produce any software they like and pretend it came from
MS - and most windows systems will automatically run anything signed by ms
without a user prompt as well...

The other problem is that there are so many drivers around that will have to be
signed, and many may have vulnerabilities (deliberate or otherwise) which can
be exploited to get code executing in ring 0 that its difficult to keep track
of them. This reminds me of one of the first exploits for the Xbox where a
vulnrability (buffer overflow) was found in several games which allowed simple
code execution in ring 0, even though the game itself was signed.

The current theory is that MS will revoke the certificate of vulnerable drivers
and therefore disable them until a patched version is available. I dont think
its practical to revoke certificates of drivers which are vulnerable in some
way because then systems would break. Even if we suppose that MS will actually
do this, its impossible to do fairly because drivers are signed using the cert of
the author (which might cost several thousands of dollars to buy). If Nvidia
ownes a code signing cert, and version 10.0.1 of their driver is vulnerable how
can MS just disable that version? If they revoke nvidias cert, all nvidia
drivers will break. Do they force nvidia to get a new cert for each version and
point release? This is obviously not scalable because it has to be done for
thousands of developers. And even suppose that is the case - developers are
required to buy a new cert for every point release, you will start to issue
thousands of certs, how can you track where they all are at once? You only need
a single one of those certs to sign your code with.

Also, certificate revokation depends on the machine being conected to "windows
update" but why would a pirate want to do this? Would it not be more sensible
for a pirate to install a fresh 2 yo version of windows on a stand alone
computer and then load any driver they want without fear of revokation? Surely
windows must be allowed to operate standalone with no internet connectivity
(there are millions of applications where this is mandatory).

> > Adams demonstration was spectacular - he reprogrammed his linux laptop to look
> > like a firewire device, and was able to use the firewire bus protocol (which
> > seems to allow devices to map DMA regions) to map a windows  host's memory
> > space. He then searched through the memory for logon passwords/keys what ever
> > and was able to hack the windows logon screen directly (just as a demonstration
> > - he could have gotten any keys/passwords or data he wanted).
> That's a cool hack. I didn't know Firewire had such capabilities, I
> thought physical access to the PCI bus was required. Scary.

It is - firewire is a protocol that extends the PCI bus into the firewire bus,
so connecting to the FW bus is the same as connecting to the PCI bus just more
convenient. This doesnt work with USB for example, because USB is a whole other

> > The message was clear - first rule of security, do not allow physical access.
> > When you have physcial access you automatically win. This is why DRM can never
> > work. It would be funny to see big players spend millions trying and failing
> > especially MS. Maybe thats is a good thing....
> These people aren't dumb. They know they can't make unbreakable DRM.
> They've been told and shown (and burnt) often enough. They just need to
> make it difficult and illegal to break, and that is achievable.

Perhaps. I would argue that the average person doesnt really want to copy
anything anyway, Its the pirates that flog off thousands of copies in asia that
do, and they would have the resources and inclination to break it anyway - the
effort that goes into DRM is misguided.

One of the other points that people in this thread have raised is that the
value of windoze media center is just not worth it - because you can buy a $50
set top box and just watch it. Thats a good point, but I think that MS is
trying to corner the embedded market here. Most $50 set top boxes are actually
running linux (to keep the cost down) and the components are slightly modified
OEM components. I.e. the DVD drive in a set top box is in essense similar to
the one in a pc (just a different form factor but same electronics). By forcing
all hardware to be DRM compatible and dependant on MS for signing etc they are
hoping to make it impossible to use linux in the embedded market to sell cheap
DVD set top boxes. So developer will have to use embdded windows or whatever it
is MS thinks is appropriate. This is designed to blow the embedded market to
bits because adoption of windows on embedded platforms is typically very small.
If that happens your set top box will cost about the same as a PC because it
will essentially have to be one in order to support the sumo windows os on it
(not to mention the reliability issues).

Certainly interesting times ahead - I can just envision the next 2-3 blackhat
conferences (the ones not held in the USA - im sure noone wants to be another
Skolnakov) will find hole after hole in the new standard. Its just a shame that
we need to waste the time our top security researchers on breaking DRM instead
of breaking security systems that matter.


More information about the linux mailing list