Slashdot Mirror
Microsoft Has No Plans To Patch New Flaw
Trailrunner7 writes "Microsoft has acknowledged the vulnerability that the new malware Stuxnet uses to launch itself with .lnk files, but said it has no plans to patch the flaw right now. The company said the flaw affects most current versions of Windows, including Vista, Server 2008 and Windows 7 32- and 64-bit. Meanwhile, the digital certificate that belonging to Realtek Semiconductor that was used to sign a pair of drivers for the new Stuxnet rootkit has been revoked by VeriSign. The certificate was revoked Friday, several days after news broke about the existence of the new malware and the troubling existence of the signed drivers."
Couldn't they just start making driver signatures verify with the hardware they support instead of the OS? Screw the OS saying whether or not it's legit, does the actual hardware it's meant for say it's legit code?
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
I know Slashdot's editorial standards have dropped, especially when it comes to Anti-Microsoft articles, but there is no link here to any article that claims Microsoft has no plans to patch the flaw. Do we even have editors anymore?
it's hardly an OS problem if some wanker has written a nasty driver then signed it with a legit cert
dam i consider most of my linux wifi driver malicious
it's hardly an OS problem if some wanker has written a nasty driver then signed it with a legit cert
I somewhat disagree: it clearly shows the flaws in an either/or trust model of that kind. Either it's signed and it's trusted to do anything at all to your system or it's not trusted to do anything at all... you only need one rogue signing key to break that model.
The ATI video card I have fails hard on XP64, so I got a driver some random guy that has nothing to do with ATI made instead, and it works great. If I were stuck using only drivers that were ATI-approved, I'd be majorly SoL.
I'm all for having the hardware verify that the driver actually is a valid driver for the hardware in question, just make sure that's ALL it does, or we'll lose the ability to use someone's hack to force a piece of hardware to work.
Do you propose a better model? How about the Linux model, where if the user decides to load it then it can do absolutely anything with the system? Of course, it would be great to be able to run drivers in unprivileged mode, but until we have an IOMMU in every system that won't actually buy any security (a malicious driver can just tell the device to DMA random data from anywhere in physical memory to the device and then back to the driver's address space, or data from the driver's address space into another process's).
I am TheRaven on Soylent News
Do you propose a better model?
Yes, don't trust anything unless you absolutely have to. In user land, for example, we have SELinux and Apparmor to prevent applications from accessing things they shouldn't; protecting the kernel is obviously harder.
How about the Linux model, where if the user decides to load it then it can do absolutely anything with the system?
Generally speaking, Linux drivers are only installed if signed by the distro repository, and you have to trust that key: if it's compromised you're toast. Windows has three bazillion drivers signed by three bazillion keys and only one needs to be compromised.
Nor will Linux drivers be loaded automatically from a random USB key just because you browsed there.
Reading the referencing articles and Microsoft's sites... They're not refusing to fix it. They said they're investigating and there's no plans to release an immediate fix. At best, this could summary could be stretched to "urgent 0day attack vector that Microsoft hasn't released a fix for". I wish there was a way to rate articles as flamebait. Somedays Slashdot is just like playing the "Telephone Game". sigh!
move along, nothing to see here.
I think Microsoft is right on this issue. This problem is truly not theirs, except for the amount it negatively affects them. (Which they can do little except attempt spin control on the issue.)
They designed their driver verification process intelligently: By implementing the requirement of the drivers being signed by an appropriate third-party certificate registrar (VeriSign in this case), thus leaving the issue of managing the business of encryption keys to the established so-called "experts".
Part of the process of obtaining a trusted VeriSign cert such as the device driver key involves the company desiring a high-trust certificate of this nature involves signing and complying with a detailed set of procedures describing the physical/organizational processes how to handle and store the signed keys in a very secure and documented "chain of trust".
In the case where the security chain was broken by a (previously) trusted third party, in this case we'll probably find that RealTek is the cause of the issue by not properly following the chain of trust requirements, or how else would a rogue employee be able to sign his malicious driver?
<CoolStoryBro
A decade ago, I was a systems engineer for the internet banking division of a large bank that owned a bunch of other regional banks, and I was a "primary key custodian" (A defined role in the chain of trust requirements), so I was the one who would handle the technical details as far as getting the cert created and installing it on the web banking servers. (Just SSL certs rather than driver signing certs, but at the core they're the exact same thing.)
The amount of procedural rigamorole for handling the certs was complex, and well thought-out. I would create our private key in front of a few handpicked suits from corporate and data security who would observe me as I created our unsigned private key, then I would look away while one of the security people entered a complex password that I was not allowed to know, then I would get the cert signed by VeriSign which would require the security guy to re-enter the password that I did not know, then we would get the certs back, print out several copies, seal them in an envelope, all of us would sign it and take it to a safety deposit box. The security guys were not allowed to have a copy of the unsigned private key, and I was not allowed to know the password to the VeriSign-signed (VeriSigned?) key.
[And it's been 10 years since I worked there, and the certs were only one-year certs (renewed each year going through the same type of process), so don't come try to hold me hostage for any info about the bank, my info expired 9 years ago! :) ]
</CoolStoryBro
So it looks like RealTek may have dropped the ball on their cert handling procedures. Maybe VeriSign was lacking in their process auditing as well. Who knows? (I don't)
But to blame this one of Microsoft is assinine, how were they supposed to do anything different?
I suppose Microsoft could release a Windows update that revokes trust for any cert signed by VeriSign, but would be devastating to online commerce as VeriSign has a near monopoly on the certificate registry market, so encryption would suddenly stop working on nearly all online businesses overnight. // But the bright side: All those sites would still work in the morning on Linux, giving it a huge boost! :) /// But on the dark side: All those sites would still work in the morning on Macs as well, giving the idiocracy movement a huge boost as well. :(
In this case, I think the question is whether Windows checks the certificate revocation lists. It is a code signature, nothing to do with the browser per se.
I'm not Windows expert, but isn't this exactly the way the certificate system is supposed to operate? This sounds like a security success story, not a failure.
Driver needs certificate to work with OS. Driver is found to contain security flaw. Certificate is revoked, OS refuses to recognize driver, security hole is closed. Now driver manufacturer has to clean up their act before their drivers are allowed back in the house.
The headline reads "Microsoft has no plans to patch new flaw", but isn't the certificate revocation at least as good as a patch? More so, because it seals off any *other* undiscovered bugs in the driver? Or am I missing something?
Generally speaking, Linux drivers are only installed if signed by the distro repository
Actually, for most distros, "drivers" (code executed as root, which is the main barrier in a Linux-system) are installed if they're signed by _any_ key in the keyring, including 3:d-party repositories.
Many people add 3:d party repositories to access newer versions of various packages, or packages not included in the distro, significantly increasing the attack vector. If you manage to get a hold of a key for any of those repository-signers, you pretty much have root-access to thousands-millions of users.
One of the things Linux distributions must really rethink is the concept of 3d-party software, and how it can be integrated and allowed more safely than it is today.
One concept could be special repository-system for 3:d-party packages, chrooted to separate container, and not allowed to execute any scripts during installation (or allowed, but at non-root privileges). Another idea could be per-user installs of 3d-party apps that installs to $HOME/.local or similar, and never root.
Are you serious? How the fuck did this get modded insightful. Why the hell would this affect products based off a Linux kernel that does not verify any drivers. Secondly who would build a serious firewall on Realtek hardware? They are notoriously problematic and unreliable.
No. Windows' security model only checks the certificate during install.
And even so, it doesn't update the revocation list automatically on install, nor does it check with OCSP; you won't get the revocation certificate unless you specifically install "Root certificate updates" through Microsoft Update, which is usually is found on the "optional" installs. So chances are that a lot of people will be able to install this malware in the future too.
Windows' security model only checks the certificate during install.
64-bit versions of Vista and Windows 7 require a valid Class 3 code signing certificate to load the driver, not just on installation. Revoking that certificate will stop the devices from working, as the parent poster suspected. Though it may not be the same certificate for all Realtek uses.
The article doesn't say it, and at no time was Microsoft reported as saying there were no plans to patch this bug.
Just because you are unaware of them reporting they will release a patch does not mean they have no plan to patch it.
They have offered workarounds and appear to be treating this seriously.
Just because it's the weekend and they haven't told you there will be a patch available monday DOES NOT mean they are ignoring or refusing to work on patching this.
See to secure against that, to truly secure against it, he'd have to lose all freedom. Children are soft targets, the only way to keep them secure from kidnapping is to have them under guard 24/7. Keep your kids in a locked compound with armed, trusted, guards and they could be secure (though even that could be overcome). If you want them to live a normal life, well there are risks.
So your complete and total paranoia bullshit actually proves the GP's point: Getting too paranoid about security is stupid. In the real world, there's no such thing as perfect security. If you think there is you are lying only to yourself. As such you want to design your security for two things:
1) Good enough to stop the attacks you are likely to face. You don't want to get all crazy and speculate on shit you aren't likely to see. You aren't guarding nuclear secrets, secure your house accordingly. Have it good enough, not stupidly overboard.
2) Relaxed enough you don't screw over your life. Living in a continual state of locked down paranoia and denying yourself everything because of supposed risks is no way to live. You want your security so it doesn't harm your ability to enjoy a normal life.
Also if you are dealing with someone deranged enough to try and stalk you to this degree, they needn't get in your computer to do it. You think you are safe? Not hardly. I hire a competent private investigator, they'll track you down, no breaking in to your computer needed.
You either need to be way less dramatic, get a sense of perspective, or get professional help. Maybe all three.
How about this for what is missing: an attempt to fix a (now very publically known) flaw in a somewhat timely manner.
And that's the essential difference. Linux had many flaws, and all were fixed in a timely manner, acknowledged and corrected. Correcting them might have been a pain in the ass but it was always possible. Which is not the case here. The flaw exists but it's rooted so deeply in the design that removing it without a major overhaul and breaking lots of compatibility is impossible. Insecure is not a system that has flaws, but one that has flaws that can't be fixed within current framework.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2