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:
  • Coercion? (Score:5, Interesting)

    by P(0)(!P(k)+P(k+1)) (1012109) <math.induction@gmail.com> on Wednesday October 11, 2006 @12:39PM (#16394799) Homepage Journal
    From a related article [osnews.com]:
    Vista driver developers must obtain a Publisher Identity Certificate (PIC) from Microsoft. [] This costs $500 [EUR 412] per year, and as the name implies, is only available to commercial entities.
    Does this amount to indirect coercion? In XP, if I remember, unsigned drivers were allowed to run unhindered with loud information dialogs.
    • Re:Coercion? (Score:5, Insightful)

      by perlchild (582235) on Wednesday October 11, 2006 @12:49PM (#16394971)
      It does contribute to fighting open source, any way you look at it. I'm using a tap driver from the openvpn project, it isn't signed, and I don't know for sure, but I don't remember openvpn being a commercial entity. However, I'm not current enough in vista to know if they couldn't just get out of the kernel, and move to user-space for the required features.
      • Re:Coercion? (Score:4, Interesting)

        by Jugalator (259273) on Wednesday October 11, 2006 @01:45PM (#16396053) Journal
        If the OpenVPN drivers aren't signed, they may not install whatsoever on Windows Vista 64-bit. Vista 64 will simply not accept unsigned kernel-mode drivers at all anymore. I believe XP did, just after having displayed a dialog box with a lot of bolded text in it. I'm not sure what will happen as for Vista 32-bit.

        The information here [microsoft.com] also tell that drivers that load at boot time must contain a digital signature (I'm talking regardless of 32/64-bit platform now). There's also other cases where a signature is required, and in all these cases it has to be from an authority "Windows trusts" (read: Microsoft).

        While this "combats open source", it's really just the certification authority where "money = trustworthiness" stupidity applied all over. They made VeriSign et al. grow big, and now Microsoft will try to grow big(ger) using the same idea. Microsoft will defend themselves with that they can't let just about any authority without insight in how Windows works and lacking Microsoft's guidance to sign because then they could sign code that did harm to Windows. I guess both are kind of right.
        • Re:Coercion? (Score:5, Informative)

          by x_MeRLiN_x (935994) on Wednesday October 11, 2006 @02: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.
        • Re: (Score:3, Interesting)

          by Jeremi (14640)
          While this "combats open source", it's really just the certification authority where "money = trustworthiness" stupidity applied all over.


          Indeed. How long will it be before some company gets a driver signed that (intentionally or not) allows arbitrary code to be executed as a subroutine in its 'trusted' context? As soon as that happens, they're back to square one...

        • Re: (Score:3, Insightful)

          It all depends on if we'll be allowed to install other certs as trusted sources. If we can then that is a great change and will improve the security of the OS at only a minor ease of use hit for some users. If we can't, then it will certainly stand in the way of a lot of valid use.

          Unfortunately this seems like it will also put an end to binary patching of system files, which means we'll be stuck with acceleration. In XP the only way to remove acceleration involves patching win32.sys to JMP past the accelera
      • Re:Coercion? (Score:4, Informative)

        by Z34107 (925136) on Wednesday October 11, 2006 @07: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.

    • Re:Coercion? (Score:5, Insightful)

      by geekoid (135745) <dadinportland.yahoo@com> on Wednesday October 11, 2006 @12:51PM (#16395017) Homepage Journal
      Interesting.

      Independant developers should sue. MS is completly locking them out of the platform.

      Developers.Developers.developers. Indeed...
      • Re: (Score:2, Insightful)

        by rjstanford (69735)
        Bullshit.

        Anyone who has a need to write kernel-level drivers can almost certainly toss $500 a year at a certificate. Compared to the cost of, say, manufacturing hardware, this is noise.
        • Re:Coercion? (Score:5, Insightful)

          by Aladrin (926209) on Wednesday October 11, 2006 @01:01PM (#16395181)
          I totally disagree. You are assuming they have a commercial application in mind. What about someone who wants to write drivers for their new hardware they just built by hand? They shouldn't be required to go through this.

          It doesn't matter, though, because if you make it too hard to write software for Windows, people will stop. They'll find another platform that is more enticing to them. It won't happen immediately, of course. But it'll happen.
          • Re: (Score:3, Informative)

            by Anonymous Coward
            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: (Score:3, Insightful)

          by AuMatar (183847)
          Bullshit and FUD. THere's plenty of reasons you'd need to write kernel level code. Just because you're writing a driver does not mean you are a hardware manufacturer- just doing a console controller conversion (like making an old NES controller hook up to a computer) requires a driver.
          • by rjstanford (69735)
            Last time I checked (which was admittedly back in the old NT days, but since that's the source codebase these days...) there were different levels of driver. Writing something to convert USB commands to keystrokes should be different than writing something running in ring 0. At least, that's the way that I remember it. But I freely admit that I could be wrong here.
          • Re: (Score:2, Insightful)

            by Tod DeBie (522956)
            Just because you're writing a driver does not mean you are a hardware manufacturer- 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. The idea of requring kernel level drivers to be signed does not seem like that bad an idea; this would likely stop most rootkits and would improve the general security of the os.
            • 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

        • by yeremein (678037) on Wednesday October 11, 2006 @01: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 shmlco (594907) on Wednesday October 11, 2006 @01:52PM (#16396199) Homepage
            So? Half the things you mention are also things viruses and trojans do for a living, and unfortunately users tend to approve any message generated by the system, "Are you sure you want to install the game you just downloaded?"

            It's easy to shit on an idea, but the core components of a system need to be protected somehow, and while I hear a lot of whinning what I DON'T hear is anyone offering a better solution to the problem.

            If someone really wants to build one of the things you mention then they'll pay the frieght. And Vista isn't open source.
      • Developers.Developers.developers.

        I believe what Balmer meant was "Corporate Developers", or "Developers with $$$"... People w/o money need not apply.

      • by nizo (81281) *
        Yeah thanks for bringing this catchy video [youtube.com] back into my brain. Even now my skin is crawling remembering his sweaty armpits (*Shudder*)
    • by Homology (639438)
      By allowing only signed drivers it will make it harder for root kit crackers. I don't think there are many voluntaires that write device drivers for Windows in the first place, so the requirement that only companies can get a Publisher Identity Certificate is not that big a loss. The cost of $500 a year is not much for a company, anyway.

      Now, there are several open source OS you may use if you care to write your own device drivers, or see how they are made.

      • Re:Coercion? (Score:5, Interesting)

        by Tackhead (54550) on Wednesday October 11, 2006 @12:58PM (#16395127)
        > By allowing only signed drivers it will make it harder for root kit crackers. I don't think there are many voluntaires that write device drivers for Windows in the first place, so the requirement that only companies can get a Publisher Identity Certificate is not that big a loss. The cost of $500 a year is not much for a company, anyway.

        The cost of $500 a year is also not much for the Russian mob, or any other bunch of fuckweasels that want to sponsor the creation of a rootkit.

        • Re: (Score:3, Interesting)

          by RingDev (879105)
          Except for the fact that MS can revoke that certificate at any time. If any malicious code hits the web with your cert, they pull the cert and the malicious code is rendered worthless. Of course, so is any non-malicious code under that cert. I wonder what kind of protections go into that cert to prevent spoofing.

          -Rick
      • by CastrTroy (595695)
        It's not that much for a determined hacker either. And as we have seen with signed ActiveX controls, signing code doesn't really mean anything either. The cost of buying a license to sign something doesn't hasn't stopped hackers in the past from breaking through security holes, and it's not going to stop them in the future.
      • Re: (Score:3, Insightful)

        by Aladrin (926209)
        It sounds to me like they've given hackers a reason to fake signing drivers, instead. They've never really had a reason to bother before.
      • Re:Coercion? (Score:5, Insightful)

        by mrchaotica (681592) * on Wednesday October 11, 2006 @01:08PM (#16395303)
        By allowing only signed drivers it will make it harder for root kit crackers.

        Yeah, but it will also make it harder for people making tools to preserve Fair Use (DVD and HD-disc ripping programs, no-CD cracks for games, etc.). This is a Bad Thing.

        I'll keep my Fair Use and take my chances with the rootkits, thankyouverymuch!

    • by s31523 (926314)
      Coercion, perhaps. Pain in the arse, definitely. I remember installing drivers from not-so-know hardware manufactures and getting the scary dialog box about the driver not being signed and that it could be a virus or make my system "unstable". Now, all those drivers are null and void? That sucks. I wonder if MS charges a fee to get drivers approved and signed, if so I would imagine lawsuits brewing over this.
    • Re:Coercion? (Score:5, Interesting)

      by Keith Russell (4440) * <keith.russell@[ ]il.com ['gma' in gap]> on Wednesday October 11, 2006 @01:00PM (#16395173) Journal

      Nothing has changed for user-mode drivers. You'll still get the same old nagging wave-through dialog for unsigned drivers, now with added UAC screen flickering.

      Signatures are only required for kernel-mode drivers. In 64-bit Vista, it's a hard limit: No signature, no load, period. In 32-bit, you'll get the same UAC/nag dialog as user-mode drivers. The only time you'll be affected by the lack of signatures in 32-bit Vista is when you try to play back all those awesome Blu-Ray and HD-DVD movies you've been clamoring for on your shiny new HDCP-compliant flat panel monitor. </sarcasm>

      Reminder: Video drivers are user-mode in Vista.

      • Re: (Score:3, Funny)

        by mrchaotica (681592) *
        Reminder: Video drivers are user-mode in Vista.

        Ah, but what about "Trusted[sic]" Platform Module drivers?

  • Not all drivers (Score:5, Interesting)

    by Tony Hoyle (11698) <tmh@nodomain.org> on Wednesday October 11, 2006 @12:41PM (#16394831) Homepage
    Minifilter drivers don't have to be signed (at least in RC1 which is the last version I tried). That of course means you can get into ring 0 with a loadable driver - all that's needed is admin rights.

    Modfying the kernel after that is just a matter of working out which bits (kill the code that checksums the binaries first, etc.)
  • by rs232 (849320) on Wednesday October 11, 2006 @12:42PM (#16394835)
    "if unsigned code is allowed to load you won't be able to play protected high-definition multimedia content"
  • How Wonderful (Score:2, Interesting)

    This unsigned driver "feature" is causing hell for those using the x64 version of Vista, which has abysmal driver compatibility. Nobody can now install 32-bit drivers.
    • Re: (Score:3, Informative)

      by alienfluid (677872)
      Hmm, so you were hoping to use 32-bit drivers on a 64-bit OS? You shouldn't even be here. Go home.
    • by baadger (764884)
      Vista x64 detects every last bit of hardware in the box I built in February. As did Windows XP x64 Edition (which I run now as my secondary OS). Right now, It's just a matter of choosing hardware wisely, when I built this box I deliberately chose components that had manufacturer provided Windows XP x64 Edition drivers (and of course, good Linux drivers as I run Linux as my primary OS).

      Obviously for hardware over a year to 18 months old it's difficult... but it's no use whinging to Microsoft. Nag the manufac
    • by rcamera (517595)
      mr. linux geek speaks about windows vista. interesting. as a rc1 x64 guinea pig, i can tell you the situation is not as bad as you seem to think. i have yet to see hardware which is not supported by x64 out of the box. my only complaint so far is that there's no vista ready version of nero. but there's no x86 support for it either.
  • "From: (Blair P. Houghton)

    I predict that Eighth Generation computers
    will compile no programs, run no applications,
    and access no data. Instead they will be
    designed and tuned to give a continuously
    variable spectrum of elegant and precise
    error messages describing your failure to
    induce them to do so."

    Yay Vista!
    • Re: (Score:3, Funny)

      by ggalvao (1000487)
      Yay! One more barrier for open source free non-propietary drivers to jump over!
  • Updates? (Score:4, Insightful)

    by phorm (591458) on Wednesday October 11, 2006 @12:45PM (#16394907) Journal
    How exactly would it accomplish this properly though? Call home periodically to get a kernel hash? Have a built-in hash check? If you want to allow the kernel to be updatable (which at times, is necessary), then you are going to have to allow the kernel to be "tampered with" somehow. A crack, virus, or other program might just masquerade as a patch to allow the on-disk kernel to be modified.
    • Re:Updates? (Score:4, Informative)

      by EvanED (569694) <evaned@ g m a i l.com> on Wednesday October 11, 2006 @12:52PM (#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.)
      • It isn't that hard (Score:4, Insightful)

        by gillbates (106458) on Wednesday October 11, 2006 @03:49PM (#16398449) Homepage Journal

        Compare the two. If they match, then the file hasn't been tampered with... Tampering with this requires...

        No, all that is required is to copy one key over the other in memory. Alternatively, one could modify a single comparison instruction in the loader. Then the match occurs, and the code will be allowed to load.

        This is well within the range of an experienced hacker:

        1. Disassemble the loader
        2. Modify the assembly code so that the comparison is always true (JNE -> NOP, or other suitable instruction)
        3. Reassemble the loader and replace it on the filesystem.
        4. Note that all of these could be done without Windows' consent if the filesystem is mounted using Linux, or other suitably advanced OS.
    • by s31523 (926314)
      Maybe Vista will use some sort of private key encryption so that when good ol' Windows Update runs it is the only program with the keys to the castle, so to speak. That way only Windows Update can perform mods and reprogram the kernel with a new hash code/CRC, or something.
    • Re: (Score:3, Interesting)

      by qbwiz (87077) *
      Microsoft could sign patches with their private key, then include the public key in Windows to let them check that. AFAIK, they do that with the Xbox 360 and some other stuff already. The hard part will be making sure that the part that does the validation hasn't been cracked already - Apple is having problems doing that, and they even have a combined hardware/software solution.
  • For years, people on this site have acknowledged that the driver signing feature -while valid at first blush- would inevitably be used to shut out non-microsoft drivers. Now our prediction has finally come true.

    On a personal level, if I cannot uses the EXT2IFS drivers on an Vista system to access my linux drives, I will keep my XP cds and simply use XP and not bother about new games (since the games I use are from 2002, I pretty much already have abandoned new games anyway) or new versions of office.
    • by jb.hl.com (782137)
      Try explore2fs. It's a little clunky, but it works quite well and doesn't require installing drivers (I never did have much luck with EXT2IFS, it tended to screw up folder names and such quite a lot).
      • by CastrTroy (595695)
        I've always wondered why there was little/no support for other file systems under windows. Linux supports tons of file systems. Windows only supports 2, and is phasing out 1, so they pretty much only support NTFS. I hate that when I boot into windows, I can't access my ReiserFS files. I hate having to keep my music and picture files in a separate partition, just so I can access them under windows the few times a month that I bother booting into windows.
        • by Tony Hoyle (11698)
          Up until fairly recently the IFS kit cost about $1000 and the only book describing NT filesystems cost about $250 (and was out of print anyway).

          If you have the new DDK (labeled longhorn beta DDK on my MSDN but just don't use the longhorn bits) that has the IFS kit rolled in now.

          That said, writing a filesystem driver is *hard* and I would set aside 6-12 months development time for it.
        • by EvanED (569694)
          Because MS has very little incentive to support other drivers. They've got more to lose by possibly convincing other people to give Linux a shot than they do by annoying the few (percentagewise) who use Linux already.

          BTW, there's a program called RFStools I think that lets you access Reiser partitions from Windows. I've only tried it once or twice, and I think just to read, but it worked for that. I don't know how complete they are.

          (Besides, what are you doing using a filesystem from an alleged murder? )

  • I wonder whether or not its engineered to make vista more secure or to strengthen windows DRM (Dark ages Replayed for the Modern era). I've got a feeling its one or the other, but not necessarily both.

    • by Alchemar (720449)
      Lets just make the wild assumption that this is a security measure. Now you don't have to modify the kernel to destroy a computer, just change the hash code so that Vista thinks Vista is unsigned. I haven't looked at the code, so they might have figured some way around it, but I have faith that the black hats will find away around their way around.
  • Alter the boot-up code. Then modify CI. Work your way up to the kernel and off you go.

    The operating system loader and the kernel now perform code signature checks. On 64-bit x64 platforms, all kernel mode code must be signed and the identify of all kernel mode binaries is verified. The system also audits vents for integrity check failures.


    All your base... for great justice!!!
  • by Anonymous Coward on Wednesday October 11, 2006 @12:48PM (#16394959)
    MS can't win for losing. Clearly the subversion of the kernel through rootkitting is a growing problem. If MS doesn't fix it, they get knocked for having no security. If they fix it, it is called DRM. Myself, I find Vista less than compelling. 2003 works just fine, but it seems some of the haters in the Slashdot crowd will see anything MS does as bad. They are finally getting their act together on not running everything as root and they even get knocked for that.
  • Okay, I didn't rtfa, but it probably wouldn't have mattered (and it's not the /. way, after all). Will this mean there will be no unsigned drivers, or that unsigned drivers will have to work through the kernel like WinNT 3.5? Aside from all the DRM lock-down, bend-the-consumer-over-a-rail implications, this would also prevent home hacking and diy projects, and could have all sorts of implications for hobbiests.

    So, is this a way to prevent crashes (a la 3.5, no Ring 0 access) or is it a way to tighten the no
  • Ah, but what prevents something from tampering with Code (CI)?

    An incomplete DRM system can be ignored if there's still enough of a real computer (tm) left that doesn't have to jump through the DRM hoops. If you can run code in a way that doesn't HAVE to check the DRM for permission to run, then all the DRM becomes is a necissary bootstrap you need before your real software starts running.

    And from what I've seen so far, a completely protected system simply isn't worth the inconvenience for a general compute
    • And I don't think most people would want to play in a truly fully protected sandbox
      Change that to
      And I don't think most /.ers would want to play in a truly fully protected sandbox
      and I'll totally agree with you. However, mom and pop will be sold on the 'added security', and whomever makes the decisions about what OS to use on the thousends of PCs throughout the organisation I work for will love it to bits.
    • And I don't think most people would want to play in a truly fully protected sandbox, once the cat-and-mouse game of patches and hacks plays out fully - it won't be a pretty sandbox.

      But they have to realize it first, and do so before they get locked in. That's the hard part about fighting DRM.

  • I'm an optimist by nature, so I'll say it'll take hackers 3 months to crack the kernel DRM.
    • by ultranova (717540)

      I'm an optimist by nature, so I'll say it'll take hackers 3 months to crack the kernel DRM.

      I'm hoping for a year. That gives Vista enough time to spread to make it impossible to make large-scale re-engineering, and will also give people enough time to learn what DRM actually means for them. Let the people suffer enough that they'll hate DRM and view the DRM-breaking hackers as heroes.

  • by daeg (828071)
    What happens to third party, open source disk drivers like TrueCrypt?
    • by CastrTroy (595695)
      What happens to the developers of the drivers. How are keys managed in that situation. Does every developer have a copy of the private key for signing? Does every developer have to submit their file to some other server so it can be signed before they are able to test it? I don't develop drivers myself, so I'm not completely familiar with the testing/development/debugging process, but it seems like requiring to have these drivers signed would create a lot of extra hassle for the people developing them.
  • by TRS-80 (15569) on Wednesday October 11, 2006 @12:55PM (#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.
    • According to the URL you provided, there is no proof this even works.

      Since you don't have to page everything (it is a function of the OS after all), it is possible to not page out critical CI drivers, thus preventing re-writing of critical DRM signature code.
  • Freedom is Slavery (Score:3, Insightful)

    by orospakr (715849) on Wednesday October 11, 2006 @12:58PM (#16395131) Homepage
    The very idea of running software on my own equipment that considers me an enemy just doesn't sit at all well.

    That, and I really like the Free Software TUN/TAP driver for Windows.
  • The new security hurdles will be great for the average home user anything that makes it more protected and stable helps. The big hurdle is going to be convincing businesses that do active in-house development that this is a good idea. Its going to be hard enough to convince companies that most of their desktop systems have to be completely upgraded and they really have to push the upgrade since runing in reduced functionality mode appears to offer no real benefit over XP. MS has really created an uphill
  • Everytime I see articles like this I am so happy I switched away from Windows. I switched to a lesser of 2 evils, Apple. But, I tell you what I have spent far less time trying to maintain the system, then using it. Defrags, virus scans, spyware scans, updates, upgrades, reboots, etc.

    OS X is NOT perfect, nor is Linux. But, OS X is a lot closer then Windows AND Linux. Don't get me wrong, Linux has its place. As a server. I will use nothing but it for a server, but for a workstation it still has a long
  • Ummm, hello? (Score:5, Insightful)

    by finkployd (12902) * on Wednesday October 11, 2006 @01:17PM (#16395463) Homepage
    This is not new (at least the concept) at all. We have been talking about this for years now. What do you think trusted computing (palladium) is? This has always been the "good" side of the TCPA coin, media DRM being the "bad" side.

    Finkployd
  • Is everything DRM, piracy, and terrorists, these days?

    Protecting the core parts of the system against tampering is a perfectly good security measure, and it has been done by anti-virus software for years. It's also being done on Linux; at least one rootkit detector does it.
  • This seems primarily to protect revenue, both from software sales and from content sales. As an side benefit, there is some level of assurance that the drivers are in a known state.

    There has been some discussion of money changing hand to be licensed by MS as a kernel driver. This is not necessarily a bad thing, because not everything needs be in the kernel. One can imagine, however, that this would be a cheap way for sponsored applications to gain validity, sort of a membership to the BBB.

    Ultimately

  • by BlueCoder (223005) on Wednesday October 11, 2006 @01:25PM (#16395631)
    DRM is impossiable without chip level hardware security. There is going to be a whole new product field of new software that disables and replaces windows code security. Programs which actually give control of your computer back to you. But while it's won't stop computer infection (where there is a bug hole there is a way) it certainly raises the security bar for the basic default windows setup I install on (non nerd) family and friends computers.

    Even with chip level security I'd be drilling into chips and hot wiring them if needed or purchase pre hot wired hardware if the modification equipment was beyond my means. I will never stop striving for control of my own property even if control is an illusion.
  • No Colinux on Vista (Score:3, Informative)

    by Laur (673497) on Wednesday October 11, 2006 @01:27PM (#16395675)
    I beleive CoLinux is another FOSS program (and a very useful one at that) that is affected by this.
  • by QuietLagoon (813062) on Wednesday October 11, 2006 @02:09PM (#16396533)
    The real reason for the kernel DRM is to lock down the media content as much as possible. Microsoft doesn't care about its users getting infected by adware and viruses, Microsoft cares about the media content providers forking over royalty payments for using Windows Media.

    When the Windows DRM was cracked, how long did it take for Microsoft to issue a fix? A couple of days.

    When there is an IE security issue, how long does it take for Microsoft to issue a fix? Weeks, months, sometimes not at all.

  • Just the facts, maam (Score:3, Informative)

    by cookd (72933) <douglascook@juno.cBLUEom minus berry> on Wednesday October 11, 2006 @08: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).
  • Meh. (Score:3, Interesting)

    by Money for Nothin' (754763) on Wednesday October 11, 2006 @11:51PM (#16403959)
    What about the module that performs the verifcations (probably just a hash comparison, like Tripwire on *nix)? Suppose somebody conveniently inserts a JMP instruction to the location of the code following a successful verification, allowing the comparison binary to otherwise behave as if the check had succeeded (probably either terminating at that point or trying to perform another verification if a binary hash exists)?

    (I personally don't grok x86 ASM well enough to do this. But some people do.)

    As with privacy, the question is "who watches the watchers?"

"A great many people think they are thinking when they are merely rearranging their prejudices." -- William James

Working...