Vista DRM Prevents Kernel Tampering 428
mjdroner writes "A ZDNet blog reports on a new DRM feature for Vista that 'protects' the kernel from tampering. The blog quotes a Microsoft document: 'Code (CI) protects Windows Vista by verifying that system binaries haven't been tampered with by malicious code and by ensuring that there are no unsigned drivers running in kernel mode on the system.' The blog says that much of the DRM in Vista is simply a port from XP, but that this feature is new to the OS."
innovative (Score:1, Informative)
Re:How Wonderful (Score:3, Informative)
Re:Updates? (Score:4, Informative)
You take a hash, and sign it with a private key. This is your signature. The loader then takes a hash of the file again. It also decrypts the signature with the public key. Compare the two. If they match, then the file hasn't been tampered with.
Tampering with this requires:
1. Tampering with the loader
2. Tampering with the public key stored in the loader (really part of #1)
3. Breaking MS's private key
4. Producing another executable with the same hash
1 and 2 are possible, but 3 and 4 are computationally hard. (The sun will have turned into a red giant long before the best-known alogrithms have found a solution, even if the hash is the relatively "weak" MD5.)
Already broken by Blue Pill (Score:5, Informative)
Many classes of software are affected (Score:5, Informative)
Installable file systems
Loopback mounts
Volume encryption
Rootkit detection
Packet sniffing
VPN software
I'm sure there are others. Vista's code signing requirement will make it difficult for any open-source program to do any of the things listed above. Large OSS projects backed by a company will probably be able to get a certificate from Microsoft and sign official builds, but third parties will be unable to modify and redistribute binaries, which is counter to the spirit of open source. I'm sure this is not an accident. Smaller OSS projects (such as installable file systems for ext3 or reiser) will most likely jsut disappear.
Re:Quis custodiet ipsos custodes (Score:3, Informative)
Apple however, had distributed unprotected versions of 10.4.1 prior to that. And a large amount of the kernel is open-source. There's no assurance you can do that with Windows.
No Colinux on Vista (Score:3, Informative)
Re:Coercion? (Score:3, Informative)
Re:Coercion? (Score:2, Informative)
Re:Quis custodiet ipsos custodes (Score:4, Informative)
The project is sometimes referred to as OSX86, I think. They release updates just about every time Apple has a major update, and at least very recently you could get a version of OSX that could run on generic x86 hardware, at the same version as what's available on Macs.
From what I understand, the difficulty of all this really isn't replacing the kernel, but more like ensuring there are good drivers for non-Apple hardware. In any event, the situation seems very different to me, between Apple locking OSX to Apple hardware and Microsoft locking the kernel in general.
Re:Get real (Score:3, Informative)
I'd say 50% of the drivers I install under XP warn me that they're unsigned. The ones from larger companies like nVidia are usually later updated to include said signing, but the others remain unsigned indefinitely - especially for older or more obscure hardware.
You can probably say goodbye to projects like the Omega Drivers [omegadrivers.net] unless they can summon up the requisite fee every year to get their modified drivers signed.
Re:HMmmmm (Score:4, Informative)
Nothing. Go to another signing-company, then.
I don't know about Vista, but XP has multiple root-certs from well-known signing companies pre-installed (verisign, etc). Pick one of them. If they all think that your driver "isn't good enough", then it probably isn't. BTW, "not good enough" usually means that they think the code in question is malware (win which case it's *good* that it be rejected) or piracy-ware (which would piss off the "information wants to be free" types) of some sort.
The other main reason for sigs is to ensure that a driver that you obtain wasn't mucked with. For example, if you download an ATI driver from some site and that driver has malware inserted into it, it likely won't have a digital sig, or at least not one that matches the driver or is valid, so it won't run.
Re:Coercion? (Score:5, Informative)
Input drivers cannot run in user mode (Score:3, Informative)
Yes you would. A console controller conversion requires a way to talk directly to a parallel port to send first-button and next-button request signals and receive button state signals. Input device drivers have additional restrictions; Microsoft's user-mode driver framework FAQ [microsoft.com] states the following:
This will have negative ramifications for the disability community, as it will become harder for hobbyists to develop novel assistive devices
Input drivers are still kernel mode (Score:3, Informative)
Input device drivers are still kernel mode [slashdot.org]. If you have a disability, and you want to build an assistive input device, and you can't afford $500 a year for a cert from VeriSign plus whatever your state charges to form and maintain a corporation to receive the cert (VeriSign does not sell code signing certs to sole proprietorships), tough copulating manure.
Re:Coercion? (Score:4, Informative)
Except in Vista, 99% of drivers DON'T reside and CAN NO LONGER reside in kernel space. Other than very special and limited applications (videocard drivers), most drivers are FORCED to be loaded in userspace.
The system is more stable because a crappy printer driver won't blue-screen your system, and the printer driver (and others) achieve the same functionality they had in kernel space using the new Windows Driver Model.
Although signing drivers costs $money, only companies like nVidia actually have to. The new DRM only protects kernel space, and the new kernel FORCES 99% OF ALL DRIVERS to reside in userspace. Kernel protection isn't a problem because most people can't put drivers there anyway.
Just the facts, maam (Score:3, Informative)
2. Win64 (whether Vista, 2003, and XP) requires signed drivers unless you boot up in "debug" mode. Win32 does not, although it will warn you.
3. If you have any unsigned drivers running (Win64 OR Win32), certain "trusted path" applications (i.e. DRM-enabled video players) will not run. Basically, the content author says "I only give permission to watch this video if your system is trusted" (for some definition of trusted, as defined by the content author). Microsoft is providing a way to certify your system as trusted. Without this certification, you don't have permission of the content author to view the content. (Workarounds will be found, I am sure, but legally, that's how it works.)
4. Microsoft will issue a PIC (driver signing certificate) to pretty much anybody with a valid code publishing certificate from an accepted certification authority. Currently, "accepted certification authority" means Verisign, but MS claims to be willing to entertain other applicants. It is the certification authority that gets the $500, not Microsoft.
5. The point of the signature is identification, not security. Basically, Microsoft wants to be able to identify the author of any kernel-mode code running on Win64. Stable? Well written? That is a completely separate matter covered by a different process. The idea is that if a kernel-mode driver does something stupid/illegal like sniff for passwords, Microsoft wants to be able to track down the author and possibly blacklist/revoke the driver signing certificate if flagrant violations are found.
Yes, this presents some inconvenience for small or not-for-profit organizations that want to write drivers. In most cases (something like WinPCap), I suspect they'll be able to find a "sponsor" organization willing to sign the driver. Other drivers can really never be trusted (CoLinux, for example) because the driver loads arbitrary externally supplied code into the kernel, so sponsors might be more hesitant to sign them (their certificate would probably be blacklisted).
On the other hand, it means that any rootkit/sniffer/malicious driver will have a name and address associated with it -- very handy for picking up the trail of the author (or at least shutting him/her down via certificate revocation).
Re:Coercion? (Score:3, Informative)
So how do they access the hardware if they're not in ring 0?
The Windows Driver Model provides an interface to do this. The software calls kernel functions, and the KERNEL accesses the hardware.
This lets drivers reside in user mode, yet still talk to the hardware. Keeps things nice and stable, and DOESN'T require signing.