Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Vista DRM Prevents Kernel Tampering 428

Posted by CmdrTaco
from the in-theory-anyway dept.
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."
This discussion has been archived. No new comments can be posted.

Vista DRM Prevents Kernel Tampering

Comments Filter:
  • innovative (Score:1, Informative)

    by Anonymous Coward on Wednesday October 11, 2006 @11:39AM (#16394805)
    It's about time they put something like this in. I hope it will have a effect on the rootkits that are increasingly common these days, both the legitimate ones (e.g. Sony's) and those from hackers (e.g. rootkit.com).
  • Re:How Wonderful (Score:3, Informative)

    by alienfluid (677872) on Wednesday October 11, 2006 @11:47AM (#16394943) Homepage
    Hmm, so you were hoping to use 32-bit drivers on a 64-bit OS? You shouldn't even be here. Go home.
  • Re:Updates? (Score:4, Informative)

    by EvanED (569694) <evaned@gmaiDEGASl.com minus painter> on Wednesday October 11, 2006 @11:52AM (#16395021)
    Cryptographically secure signatures?

    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.)
  • by TRS-80 (15569) on Wednesday October 11, 2006 @11:55AM (#16395087) Homepage Journal
    The kernel mode signed driver restriction has already been broken by Blue Pill [wikipedia.org]. Full details are in the black hat presentation [blackhat.com], but the basic gist is you force a driver (eg null.sys) to be swapped out to disk, overwrite a function in the copy in swap with your own code, then call that function. And now you're executing unsigned code in kernel space.
  • by yeremein (678037) on Wednesday October 11, 2006 @12:19PM (#16395509)
    This isn't just about supporting hardware. Several types of programs require kernel-mode drivers. Off the top of my head...

    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.
  • by ZachPruckowski (918562) <zachary.pruckowski@gmail.com> on Wednesday October 11, 2006 @12:23PM (#16395599)
    As Apple just learned with their TPM kernel extension, all that hackers need to do is replace the binary that verifies all other binaries, and the "goodies" are up for grabs.

    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)

    by Laur (673497) on Wednesday October 11, 2006 @12:27PM (#16395675)
    I beleive CoLinux is another FOSS program (and a very useful one at that) that is affected by this.
  • Re:Coercion? (Score:3, Informative)

    by Anonymous Coward on Wednesday October 11, 2006 @12:30PM (#16395725)
    Vista allows you to turn this protection off. The guy making his own hardware can turn it off while he's developing and then buy a license later if he wants to distribute it to others.
  • Re:Coercion? (Score:2, Informative)

    by MioTheGreat (926975) on Wednesday October 11, 2006 @12:31PM (#16395755)
    You're especially right with Vista. Microsoft is pushing things away from the kernel with new driver models. They want more stuff to live in userland. Look at WDDM, for example. In XP, nearly all the components of video driver lived in the kernel. Now they can put less and less there, and more into user space.
  • by nine-times (778537) <nine.times@gmail.com> on Wednesday October 11, 2006 @12:47PM (#16396103) Homepage

    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)

    by Spad (470073) <slashdot@nosPAM.spad.co.uk> on Wednesday October 11, 2006 @12:56PM (#16396281) Homepage
    Rubbish.

    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)

    by I'm Don Giovanni (598558) on Wednesday October 11, 2006 @12:56PM (#16396285)
    What is too keep microsoft or whoever from just saying nope your driver isn't good enough?

    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)

    by x_MeRLiN_x (935994) on Wednesday October 11, 2006 @01:06PM (#16396445) Homepage
    Oh, but it will. You just have to press F8 during boot and select the appropriate option in order to install unsigned drivers as I found out when installing my Creative 5.1 drivers.
  • by tepples (727027) <tepples&gmail,com> on Wednesday October 11, 2006 @03:14PM (#16398815) Homepage Journal
    just doing a console controller conversion (like making an old NES controller hook up to a computer) requires a driver.
    I don't think you would need a kernel level driver for that

    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:

    Q: What are the constraints on user-mode drivers?
    A user-mode driver cannot directly access hardware or use kernel-mode resources.
    [...]
    A user-mode driver cannot have kernel-mode clients because Windows does not allow calls from kernel mode to user mode. The majority of drivers for input, display, and most network and storage devices cannot be migrated to user mode because they have kernel-mode clients.

    This will have negative ramifications for the disability community, as it will become harder for hobbyists to develop novel assistive devices

  • by tepples (727027) <tepples&gmail,com> on Wednesday October 11, 2006 @03:38PM (#16399269) Homepage Journal
    What drivers are still kernel mode?

    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)

    by Z34107 (925136) on Wednesday October 11, 2006 @06:59PM (#16401979)

    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)

    by cookd (72933) <douglascook@j[ ].com ['uno' in gap]> on Wednesday October 11, 2006 @07:33PM (#16402335) Journal
    1. This is not news. Driver writers have known about this for years. This is how XP-64 and Server2003-64 work already. And this has been posted on Slashdot at least twice before.

    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)

    by Z34107 (925136) on Thursday October 12, 2006 @11:29AM (#16409913)

    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.

It's hard to think of you as the end result of millions of years of evolution.

Working...