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."
The certificate was revoked.
Does it mean I need to update my drivers from Realtek, otherwise it spits them out?
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'm not getting it. There's a security problem and MS refuses to fix it? Really? How many times has this happened before? It's happened enough that I didn't even blink at it. It's like saying a politician told a lie. So?
No plans to patch flaw right now, as in some OOB patch knuckehead
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?
they have definitions for the malware - so I guess Microsoft doesn't have to patch the hole if it can be detected ?!
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.
Now, who's changed the defaults so that their browser actually checks the revocation cert lists? 38 people worldwide?
Imagine if you weren't allowed to use roads because a bus company complained about your driving 3 times. --skunkpussy
I didn't put it through exhaustive tests, but I actually tried to make some link files and put them on a usb drive and have them install something when I accessed the shortcuts in Windows explorer. No luck whatsoever. I looked for some working examples but I couldn't find any, either.
And funny, I did some work for a large oil/gas company that stored the config files for some flowmeters on usb thumb drives and left them in the battery boxes. It was really fun when the first wave of thumb drive viruses hit! That's one reason I find this story interesting.
transporter_ii
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
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. :(
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?
What was the main use for the Realtek Semi certificate that's being revoked? I would hate to see a bunch of SmoothWall/Untangle implementations shut down by having their network drivers revoked....
Don't be disingenuous. You were posting that first link clearly in response to someone saying "There are no links to Microsoft saying they're not going to fix this problem". I might have believed you just didn't read the first link and assume you'd just made a mistake, but when someone then correctly said "Well, that document doesn't say anything about not fixing the problem" you came up with a second link that ALSO did not address the issue of fixing or not fixing the problem.
Now that both links have been shown not to contain any statement saying the problem would not be fixed, you're all like "Aw shucks, I was just a-tryin' to help". You claim that you were just providing "additional information" but if the issue is whether or not Microsoft is planning to fix or not fix the problem, then neither of your links provide any "additional information" at all. You were clearly pretending that those links somehow included a statement from Microsoft that they were not going to fix this problem. That's some sleazy shit right there.
You were trying to make it look like those links said something they did not, and you were relying on people's unwillingness to actually go and read TFAs to slip it by. People like to mod helpful links as "Informative" so you were hoping that once you were modded up, people would be even more inclined to oblige you by assuming your links actually provided proof that Microsoft was not going to fix this problem.
I'm no friend of Microsoft, and I don't really care one way or the other, but I hate this kind of perfidy. It's underhanded, intellectually dishonest and stinks up the place. The fact that you believed you'd get away with it, with your low Slashdot UID, makes you a real worm.
If you're made of anything at all, you'll admit what you did and apologize.
Damn Vulnerable Windows!
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.
"no clear indication" isn't exactly a definitive response from Microsoft at all. It just means that one source hasn't heard a plan in *either* direction (to patch now/not patch now). Lots of room for ambiguity there, in my opinion.
Couldn't they just start making driver signatures verify with the hardware they support instead of the OS?
That's a really, really bad idea.
Drivers are for hardware, yes, but they're also for software too. As soon as you switch to that type of signature verification model, you lose the ability to load drivers for virtual hardware, like ImDisk. Microsoft's iSCSI initiator is also a virtual mass storage driver, and that wouldn't work either.
There's probably a gazillion other examples, but generally speaking, driver and software signing as it's currently implemented is working well enough for most things. It's just a shame it's so god damned expensive to get a driver signature or code signing certificate for something like a small FOSS project.
Boot Windows, Linux, and ESX over the network for free.
...let me get this straight, we have signed drivers that install malware, we have a discovered vulnerability that enables this, we have Microsoft, aware of the problem, but unwilling to do much of anything about it, and we have a 3rd party, Verisign, that has decertified the drivers, which ought to render them null and void, more or less, unless the operator is foolish enough to install them anyway.
Sounds kinda silly, but Verisign is obviously doing what it's supposed to, the operator SHOULD know enough NOT to install suspect drivers, so Microsoft is being a bit slow in acting on the inherent vulnerability in the OS (typical). Now.....how in the world did these drivers get a pass from the original vendor?
Microsoft is really getting picked apart security wise last few days. Probably because of Black Hat and Def Con coming up very soon always happens this time of year. Microsoft security and viruses run rapid a bit.
http://www.thetechnologygeek.org
then the r00tkit could be an actual functional driver providing any of these checks you state, in addition to the r00tkit function. And as a parent points out it might make things harder to revoke.
it wasnt a terrible idea, but i think similar technologies have been tried and never took off. one example is the IO2 hardware interface standard, which i believe had drivers built into the cards in a pci like system. the drivers may have run on a vm of some kind to make them portable. yet we moved to pci-e with native drivers.
omg: how did the captcha know i just grabbed a coopers stout, the captcha was coopers
omg, you couldnt post a link to that driver or at least more info. my uncle has an ati radeon 9550 and no money, and we would like to get it running in his P4 under win7, just so he has the option of running windows apps and games for his son, in a more secure environment (UAC) than xp, (although restricting xp to an 8gig partition and imaging it let me restore it in 4min so meh).
At the moment the app he really wants is utorrent which is releasing a linux version, but when it runs under wine in ubuntu 10.04 it uses 60% of the cpu as opposed to 2% under xp/7, or rtorrent which also uses 2%. utorrent has really simple and effective scheduling, use it and you will understand why its preferable to ktorrent's scheduler or transmissions single settable interval of slow speeds. It's also got a very nice gui, which is simultaneously simple.
Avoid this file:
http://babybird.files.wordpress.com/2009/08/pony.jpg.lnk
Hopefully Wordpress will take it down soon.
Gottal love all the handwaving by the paid M$ astroturfing fanbois in here pointing that the summary is "false" because M$ "may" fix the flaw "in the future" (from TFA).
Hey, paid M$ astroturfing fanbois: we are talking about taking control of PCs equipped with Windows by exploiting a flaw in the friggin' way .lnk are implemented.
Dot frakkin' lnk files. Don't forget how amazingly secure your love-OS is, we're talking about .lnk files this time.
It's almost like most large corporations resisting unneeded upgrades knew what they were doing.
Seriously. Wtf. At this point I don't know if I will ever buy another post-XP windows OS again. Even after the 2012 Mayan/Martian apocalypse. WIndows 7 probably has a Mayan Calendar problem.
The Invisible Hand of the Free Market is what punches workers in the nuts.
You cannot, in fact, point out what is missing, what you think needs to be done different. You are simply parroting "Windows = insecure" without any real understanding.
Because remember, if a single bug showing up means the design is insecure, then Linux is insecure. There have even been vulnerabilities in the kernel. Not many, but again if it is a case of "There was a flaw so this design is insecure," then Linux is insecure.
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.
http://it.slashdot.org/story/10/07/18/1950210/Microsoft-Has-No-Plans-To-Patch-New-Flaw HAS NO PLANS TO PATCH!! MS FANS YOU BOSS LOST HIS MIND! Now don't that make you fell safe? Hmm The sec Clem at Mint (Linux) says the same I will run from Mint Linux! NO PLANS TO PATCH NEW FLAW!! ENOUGH SAID! RUN DO NOT WALK! WHAT A CO. It is foolish and wrong to mourn the men who died Rather we should thank God That such men lived. General George S. Patton,Jr
That's a grand ramble you went on there.
Check out Omega Drivers
Finally had enough. Come see us over at https://soylentnews.org/
On OS X; you have to run "Keychain Utility" and its preferences to enable OCSP functionality to check certificate revocation. Does Windows mechanism to check certificate revocation run by default?
So, revoking certificate won't mean a thing until some windows update (aka updated root certificates) comes. That would -of course- change if Microsoft takes it serious enough to ship a 5 KB (yes, kilobyte) Windows out of band update which won't require reboot or impossible to cause issues.
Don't they have slightest clue about what Realtek "sound" has become? I suspect they have bigger market share than Intel (compared to AMD) right now. As these chips are software based, people always keep them updated. Another issue is, Realtek downloads aren't really easy so it is one of the most third party hosted driver around. OS X user rarely using Windows via bootcamp knows these but MS doesn't?
With their market share, any small looking issue could become a global disaster. Add the fact that, new fashion "free antivirus" stuff rarely has decent heuristics to catch such a complex behavior, you get the picture.
Apple, with their current desktop marketshare are free to ignore such issues for couple of months but when we speak about Microsoft Windows, small issues really becomes very critical.
They acknowledge the issue doesn't matter a thing. Especially if the issue is so simple so any script kiddie can exploit it.
On OS X, you gotta enable OCSP/CRL functionality via keychain utility preferences which means, 99% of people didn't enable at all.
Of course, with OS X logic of working, almost entire OS becomes OCSP aware and with 5 years of usage, I haven't seen a single issue resulting from that setting. I have no clue why Apple doesn't enable it either. Of course, OS X doesn't have "signed drivers" (in logic of Windows) but it would really matter if some big idiot website lost their certificate.
If you bothered to look into the properties of "vncutil.exe" you would have seen it is "Virtual Noise Cancellation". (still a strange name because you "really" cancel the noise or do not cancel it at all. ). That sounds a lot more logical than a remote control program is included in the drivers.
Is anybody aware of any response from realtek? Is there any sane journalistic site that asked from realtek their response and got a better response than a standard PR response. Because leaking of the realtek keys might mean that any realtek produckt might be infected if they do not find the cause of the leak.
...If the reason for the Delay in fixing the bug is with purely commercial...
Think about it.
MS probably own a fair whack of shares in most of the big AV vendors. MS tips off the vendors of the exploit and they find a way to mitigate the effects (not fix the problem).
The Vendors then use the month or so between MS scheduled updates to panic the masses that they need to renew their AV subscription to help with this new virus attack.
Once they have milked the masses for a month or so of re-subscriptions, MS then come out with a patch.
Simples... ;)
Oh? Is it me or has their been a lack of reporting on HOW the drivers got signed?
Was it an inside job (Ochams razor says yes) or has someone worked out a way to spoof or recreate valid digital signatures... (The paranoid in me says yes.)
Laters Sol "Have you found the secrets of the universe? Asked Zebade "I'm sure I left them here somewhere"
It is not accurate to say that Microsoft has "no plans" to patch this. They don't have a schedule yet, but OF COURSE they're going to patch. I suspect within a couple of weeks. In the meantime, most antivirus software (including Microsoft's Security Essentials) protects against the underlying threat.