Slashdot Mirror
Vista DRM Prevents Kernel Tampering
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."
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.)
"if unsigned code is allowed to load you won't be able to play protected high-definition multimedia content"
davecb5620@gmail.com
What makes Sony's legitimate but the ones from Rootkit.com not?
If anything I would argue that rootkit.com is a more legit distribution mechanism than Sony.
Yes. The sooner enough people get bent over and used by proprietary technology, the faster we can move on to something that doesn't suck like this.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
"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!
stuff |
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.
Hmm, so you were hoping to use 32-bit drivers on a 64-bit OS? You shouldn't even be here. Go home.
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.
Cracking such a thing is trivial once you answer the question who watches the watchman?
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.
Obama likes poor people so much, he wants to make more of them.
I'm an optimist by nature, so I'll say it'll take hackers 3 months to crack the kernel DRM.
Due to circumstances beyond my control, I am master of my fate and captain of my soul.
The kernel mode signed driver restriction has already been broken by Blue Pill. Full details are in the black hat presentation, 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.
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.
But aren't most spambot trojans business assets ? After all, spam makes money - that's why spammers bother - so rootkits are business assets for blackhat hackers, even more so than they are for Sony.
No, these poor hackers are simply trying to protect their right to profit - just like Sony. And if that means taking the control of the computer away from its owner, well, surely you agree that that's a small price to pay to ensure that those damn users aren't depriving them of those profits, right ? Sony certainly seems to...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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
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.
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.
I beleive CoLinux is another FOSS program (and a very useful one at that) that is affected by this.
When you lose something irreplaceable, you don't mourn for the thing you lost, you mourn for yourself. - Harpo Marx
The only unsigned driver I have ever seen was for an old Voodoo board.
The last time I met anyone who was using custom hardware was around 1985-6, a sound board that plugged into a C-64.
If you can't use your old hardware with Vista, then don't run Vista. New hardware shipping with Vista will be able to run it.
As a security-conscious programmer with a lot of corporate development history, I support Vista's blocking of non-signed drivers 100%. It's actually the first time I've agreed with Microsoft's plans and features since suffering the pains of Windows 3.1 development and support.
Maybe it's time for the idealists to get real about security issues. They see DRM as preventing them from experimenting; the vast majority of government, corporate, and home users either don't care or see it as a benefit that provides more protection from crackers, viruses, rootkits, etc. Even OpenSuSE has a similar enforcement option for verifying binaries, and I doubt it'll be too long before bigger commercial OS vendors do the same.
Fight a battle you have a chance to win, and stop dreaming that unsigned platforms have a future. Without someone certifying that a platform is secure, businesses are going to stop using them. Eventually client nodes that aren't certified won't be able to do much useful, either.
I object more to the use of products like Entrust web sign-in that ignores the security provisions of products like Java sandboxing, artificially blocking clients unless they are running a paid-for commercial OS from Microsoft or Apple. (Try registering with http://www.gc.ca/main_e.html for a "My Government Account" with Linux or even with Firefox under WinXP Pro.)
There is no reason for such an artificial blockage of client access, and that worries me a hell of a lot more than whether a couple dozen hackers can run custom drivers for their own hardware. Why would such a hacker go through the pain of Win32 driver development instead of Linux drivers anyhow?
I do not fail; I succeed at finding out what does not work.
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.
-- "I never gave these stories much credence." - HAL 9000
Cost of WinVista Kernel DRM - part of the $300 price of WinVista
Cost of hair torn out by DRM refusing to let you do what the Constitution explicity permits - $1000 for hair plugs
Cost of WinVista hack to "fix" Kernal DRM - priceless
-- Tigger warning: This post may contain tiggers! --
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.
- The fee for the certificate is, apparently, $500/yr
- Presumably the certificate issued to the company expires or is revoked if they don't cough up next year (otherwise a cunning manufacturer could just buy one certificate, and then use that forever)
- Therefore, if your manufacturer goes belly-up, it's likely that your (100% genuine, legitimately-purchased) driver software—and the hardware that goes with it—will cease to work.
Either that, or MS will leave the certificate valid (to avoid annoying a huge number of customers), and the company's receivers will find that the certificate has a large value on the black market...Need to type accents and special characters in Windows? Use FrKeys
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:
The society for a thought-free internet welcomes you.
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 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 device drivers are still kernel mode. 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.
Nah you just send them the $500 from somebody's credit card that you got via your phishing scheme.
They'll "follow the money" for sure, but to where?
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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).
Time flies like an arrow. Fruit flies like a banana.
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?"
Is Capitalism Good for the Poor?