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."

10 of 217 comments (clear)

  1. Certificate revoked by Anonymous Coward · · Score: 1, Interesting

    The certificate was revoked.

    Does it mean I need to update my drivers from Realtek, otherwise it spits them out?

  2. Re:Possible mitigation? by Khyber · · Score: 2, Interesting

    There is a small difference to note, however; One is addressing an entire hardware set (motorola) the other is using code from a piece of hardware (is it a sound card/network driver certificate that got jacked?)

    Actually, bad example. let me see what my medicated brain can re-think.

    It's more like this, Motorola is stopping you from using hardware you purchased in a manner you wish with a hardware security check, where on the other hand, someone usurped a certificate from Realtek and used that to bypass security checks in a software-based system.

    To prevent such an attack, I'd force those certificates to authenticate with the particular hardware. If the certificate came from the sound card drivers, the ENTIRE code should be authenticated by the sound card. Not sound card code behind that certificate? Denied.

    --
    Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
  3. Re:Was there a point to this? by Anonymous Coward · · Score: 2, Interesting

    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

  4. Can someone explain how it works? by transporter_ii · · Score: 1, Interesting

    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
  5. Re:Possible mitigation? by Arainach · · Score: 3, Interesting

    That eliminates the possibility to revoke a certificate if one is comprimised. Also, it leads to situations like the TI calculator incident, which Slashdot seems to hate.

  6. Re:Possible mitigation? by RCL · · Score: 3, Interesting

    I don't like security news precisely because they result in such overreactions like yours one.

    We should not care about security too much. Security is the opposite of freedom, and by concentrating our efforts on security we may end up with completely locked environment.

    It's better to tolerate certain threshold of hijacked/owned computers than to require hardware verify the software.

  7. Who fault is it? by KlomDark · · Score: 5, Interesting

    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. :(

  8. Re:Was there a point to this? by rawler · · Score: 5, Interesting

    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.

  9. Re:Colatteral Damage? by Anonymous Coward · · Score: 1, Interesting

    I never trusted Realtek after fighting with their "HD" drivers on a Vista64 install that I was having trouble with.

    I started digging around in their driver kit and found a massive number of DLL's, VXD's etc etc, a lot more than what I would expect for a "sound card", but what really looked suspicious to me was that they included VNC in the drivers. Why in the hell would a sound card driver need to install VNC?

  10. Re:Possible mitigation? by Anonymous Coward · · Score: 1, Interesting

    Can you run any version of windows from something like a ramdisk, so there is no real way to write to the disk? how about the old, start the system up, shut it down, but leave iptables running router hack? A highly transparent bug/flaw reporting system, with a quick turn around?

    Yes you can. You can run DOS from a RAMdisk, why wouldn't you be able to do that with Windows. Lookup BartPE (no link provided on purpose). You can hack Windows into a lot of things. The problem with Windows detractors/alternative evangelists is they often spread myths about lack of capabilities of an demon operating system that many know are false or they even equivocate capabilities to a alt OS that are arguably inferior to the competition (yes, there are some things in the Windows API that are superior to POSIX... Yes there really are a few things)... and at that point are summarily dismissed as being idiots (and this is partially true).

    If you're going to criticize a book, for instance, it is problematic to start misquoting it.

    Windows sucks ass, but I'm not going to start off evangelizing by making stuff up.