Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Virtualization Open Source

'Venom' Security Vulnerability Threatens Most Datacenters 95

Posted by Soulskill from the holes-in-legacy-code dept.
An anonymous reader sends a report about a new vulnerability found in open source virtualization software QEMU, which is run on hardware in datacenters around the world (CVE-2015-3456). "The cause is a widely-ignored, legacy virtual floppy disk controller that, if sent specially crafted code, can crash the entire hypervisor. That can allow a hacker to break out of their own virtual machine to access other machines — including those owned by other people or companies." The vulnerable code is used in Xen, KVM, and VirtualBox, while VMware, Hyper-V, and Bochs are unaffected. "Dan Kaminsky, a veteran security expert and researcher, said in an email that the bug went unnoticed for more than a decade because almost nobody looked at the legacy disk drive system, which happens to be in almost every virtualization software." The vulnerability has been dubbed "Venom," for "Virtualized Environment Neglected Operations Manipulation."
This discussion has been archived. No new comments can be posted.

'Venom' Security Vulnerability Threatens Most Datacenters More

'Venom' Security Vulnerability Threatens Most Datacenters

Comments Filter:

  • I've get to some across a virtual server provider that has a floppy disk driver enabled. Seems a lot of hype about nothing to be honest and scaremongering.

    • Re:Not very serious (Score:5, Informative)

      by qpqp ( 1969898 ) on Wednesday May 13, 2015 @08:20AM (#49680993)

      Seems a lot of hype about nothing to be honest and scaremongering.

      From venom.crowdstrike.com [crowdstrike.com]:

      Floppy drives are outdated, so why are these products still vulnerable?
      For many of the affected virtualization products, a virtual floppy drive is added to new virtual machines by default. And on Xen and QEMU, even if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers.

      • Re:Not very serious (Score:4, Insightful)

        by martyros ( 588782 ) on Wednesday May 13, 2015 @08:48AM (#49681203)

        ...an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers.

        Which is why the PV mode in Xen is such a killer security feature -- the more stuff you have just lying around, even if unused in theory, the higher the probability that there will be a bug somewhere that can be exploited.

        • Yet everyone's champing at the bit to get browsers to implement shit that used to be handled by optional plugins and calling it more secure.

          I can choose not to install a plugin, but I can't remove the analogous code in the browser - at best I can turn the feature off in the hidden settings page and hope it's actually disabled, never loaded into memory, and a bug can't be used to reenable/jump to the code and leverage it in an attack.

          Less is more.

    • Of course it's serious it has a badass nickname!

    • It only applies to folks running one of these packages:
      xen, qemu,

      The software is there for a reason - same goes for why there is still an ISA bus (used for timing) etc.

      These old devices need to exist for software compatibility.

  • What is the use case for virt floppy? Drivers nearly never fit, VM's should not need firmware updates. SO why would people still be exposing a virt floppy to VM's?

    • Re:Who uses virt floppy anymore (Score:4, Informative)

      by Nuitari The Wiz ( 1123889 ) on Wednesday May 13, 2015 @08:25AM (#49681037)

      From the article:

      Floppy drives are outdated, so why are these products still vulnerable?
      For many of the affected virtualization products, a virtual floppy drive is added to new virtual machines by default. And on Xen and QEMU, even if the administrator explicitly disables the virtual floppy drive, an unrelated bug causes the vulnerable FDC code to remain active and exploitable by attackers.

    • Re: (Score:2)

      by DarkOx ( 621550 )

      While I realize VMware isn't effected by this vuln;

      Fusion can't boot a VM off USB (why the fuck is that?) So if I want to test a USB boot stick on my MAC I have to use this to chain load the USB sticks boot loader: https://www.plop.at/en/bootman... [www.plop.at]

      Its pretty convenient to just keep a VM defined with a floppy and the plop disk always attached. It would be better if it could/would boot a USB device, but the virtual floppy is my work around.

    • Re: (Score:2)

      by Bert64 ( 520050 )

      Windows 2003, which is still supported for a short time, has to load storage drivers from floppy (it won't load them from cd)... If you want to use paravirtualized storage drivers for performance reasons you need to attach a virtual floppy from which to load the drivers.
      It's not uncommon to use a virtualization environment to run older systems for compatibility purposes either (e.g. to support legacy apps)... You likely also need privileged access to a guest to exploit this, so a legacy os would be a good t

  • They have probably spent more time (Score:5, Funny)

    by Anonymous Coward on Wednesday May 13, 2015 @08:20AM (#49680995)

    finding a full name that fits the really cool "venom", instead of actually going about fixing it.

  • Whoa, this is really bad (Score:4, Funny)

    by Anonymous Coward on Wednesday May 13, 2015 @08:21AM (#49681001)

    This must be a very serious vulnerability judging purely by it's name.

  • Legacy Code: Pwning all your machines since 2004 (Score:2, Interesting)

    by Anonymous Coward

    I love how even if the floppy drive is disabled, this is still exploitable due to another unreleased bug.

    The solution is just to get rid of all the old unmaintained code by default. If someone wants to use old deprecated code, let them apply the patches themselves.

    The Linux kernel is a goldmine of barely maintained crap that hasn't had more than 2 users for the least 30 years. Not breaking userspace is nice, but at some point you need to take into account the huge gaping security risks of mistery legacy cod

    • Re: (Score:2)

      by Bert64 ( 520050 )

      The problem is that virtual machines are often used to run legacy software on modern hardware, cutting out the legacy cruft by default would cut off all those users... Although having it configurable at runtime would be much easier for users than having it a compile time patch.

      Some of us do make hardened builds removing unwanted crap, but having the hardened option require the extra work is more practical from a usability point of view as those of us who care most about it tend to be the most capable of mak

      • The last time I did some ESXi troubleshooting (about two weeks ago), I had to look up documentation that I would think our "system admins" would already know. I personally don't even know that much about the actual nuts n bolts of it yet, but our Indian sysadmins really won't do anything without someone like me beating them over the head with step-by-step instructions for the entire maintenance window. "Enter this command"...silence on the phone..."now hit Enter"...it's ridiculous.

        I blame this on the Brit

  • Open Source Branding (Score:4, Interesting)

    by organgtool ( 966989 ) on Wednesday May 13, 2015 @08:33AM (#49681099)
    Not to get too far offtopic, but as a long-time user of open source software, it bothers me that open source software seems to have inferior names for its applications (GIMP, Yakuake, etc) but very marketing-friendly names for its vulnerabilities (Heartbleed, Shellshock, Venom). If you look at closed-source software it is the complete opposite - applications have marketing-friendly names while vulnerabilities are called something like "KBstringofnumbersnobodywillrememberorcareabout". So are open source developers just much better at naming vulnerabilities or are the marketing departments of closed software companies quietly assisting with the naming of open-source vulnerabilities?

    • Re:Open Source Branding (Score:5, Insightful)

      by thegarbz ( 1787294 ) on Wednesday May 13, 2015 @08:47AM (#49681199)

      Sure if you cherry pick your applications to suit your case then you could argue that. To me I see open source vulnerabilities which are called CVE-215-3456 which someone happens to have an alternate name for. I see programs called StarOffice, and Libre Office. I see MySQL, openLDAP, and systemd. All very descriptive of what they do.

      Let's not over generalise.

      • so mysql is a tool for making sql queries that pertain to me?

        openldap is probably not a good place to keep secret login data because it's "open"

        systemd is clearly some sort of pig latin

        yes these products have fine names

        • You mean like a program to do with SQL, a program to do with LDAP, and a daemon for managing the system.

          There's only so much you can put into a name before you need to start ignoring the people who can't see the obvious.

      • Sure if you cherry pick your applications to suit your case then you could argue that. To me I see open source vulnerabilities which are called CVE-215-3456 which someone happens to have an alternate name for. I see programs called StarOffice, and Libre Office. I see MySQL, openLDAP, and systemd. All very descriptive of what they do.

        Let's not over generalise.

        What does "Star Office" do? How is it different from "Libre Office" or "Open Office"? Wait, "Open Office" IS "Star Office"? Oh, it's NOT? Then why does installing "Open Office" give me and "soffice" executable?!

        What's "MySQL"? Is it mine? Whose is it? Is it a server? Can I only use it for personal use?

        What's an "LDAP"? Do I want an open one or a closed one? I need it to be secure, so I probably don't want an open one.

        Oh, you included systemd. Your entire post is a troll.

        • Re: (Score:2)

          by Rich0 ( 548339 )

          What's "MySQL"?

          It is the other implementation of MariaDB, which also installs /usr/bin/mysqld. :)

        • What does "Star Office" do? How is it different from "Libre Office" or "Open Office"? Wait, "Open Office" IS "Star Office"? Oh, it's NOT? Then why does installing "Open Office" give me and "soffice" executable?!

          Who cares, it's on office suite. Is the marketing supposed to deal with the technicalities of the product? No. It's supposed to give you an idea of what it does, and if you download Libre Office or Open Office you end up with a product that gives you an office productivity suite. The marketing works, and the only people who fret about it are nerds splitting hairs about ownership, history and freedoms.

          What's "MySQL"? Is it mine? Whose is it? Is it a server? Can I only use it for personal use?

          It's a product to do with SQL. Quite a bit more relevant than commercial programs like "Filemaker" is it not

      • I should have made my statement more clear. I didn't mean to imply that all open source projects have bad names (although I still believe that many do) but I was more focused on the fact that it seems to be only open source projects that have vulnerabilities with marketing-friendly names despite the fact that closed source software has had many vulnerabilities just as severe and I can't recall one closed source vulnerability with a memorable name. The point is: who is responsible for naming these vulnerab

        • I agree that there are many packages poorly named in closed source.

          But I stand by my thought that you're cherry picking or not researching enough.

          Blaster
          CodeRed
          SQL Slammer
          Conficker (ok this isn't a good one IMO)
          iPwn (This is a good one, it even tells you which platform it attacks)
          Sasser
          MyDoom

          These may be mostly named after the exploiting code rather than the exploit, but that is part of closed source madness of not hearing about something till it's actually exploited.

    • So are open source developers just much better at naming vulnerabilities or are the marketing departments of closed software companies quietly assisting with the naming of open-source vulnerabilities?

      You are telling us:

      Every software developer should have a publicist from fox news on retainer so that new projects can receive names that are considered more appropriate for inclusion in technology news stories, it's much more important than the actual software itself

      • Dear God, no. If software developers used publicists from Fox News, then LibreOffice would have been called "ObamaCommieOffice".

      • How did this straw man argument get modded up? I never suggested anything of the sort. I was implying that maybe these clever names for vulnerabilities aren't coming from within the open source community and that closed source software seems to be getting off easy when it comes to the level of effort in having their vulnerabilities named for them.
        • I'd guess that's because closed source has real marketing people in the organization, people with 4+ year advertising, promotion, and marketing degrees who are naming these. In open source, it's whatever the dev wants to call it...the "professional" closed source apps have a marketing department who steps in and says "that name is horrible, it will make our clients subconsciously afraid to use the product, call it this instead." Very few devs have any real education in marketing; I've taken a few classes i

    • Other proposed names that did not make it (Score:1)

      by Anonymous Coward

      Gvenom
      Kvenom
      GNUvenom
      FreeVenom
      OpenVenom
      venom-1.0.7-RC2
      Venom.js

    • Re: Open Source Branding (Score:1)

      by Anonymous Coward

      The reason is simple.

      Nobody cares that the tool is called hammer, bash, or clonk, as long as it does the job, but everyone should care that a bug in your hammer can allow any lunatic to grab it and bash your machine and clonk you over the head. Remotely.

      Hence the attention grabbing names for vulnerabilities.

      (Plus, the fact that a 20 year old bug in bash is BIG news and a major cause for concern kinda shows that open source doesn't need marketing. Its already widely deployed.)

    • Re: (Score:1)

      by Anonymous Coward

      As for product naming : most open source project maintainers don't have the funding or time to buy and defend a trademark, so they pick names that are unlikely to violate or be similar to trademarks of actual companies (who do have lawyers to defend them).

      As for vulnerability naming : who knows. Big companies have powerful lawyers/marketing. Didn't prevent names like "bendgate", so maybe it's just selection bias.

  • (CVE-2015-3456) (Score:1)

    by Anonymous Coward

    (CVE-2015-3456)?

    I've got the same vulnerability designation on my luggage!

  • There's got to be some test I can run on my VMs to see whether or not I'm vulnerable, right?

  • Goddamn Heartbleed (Score:5, Insightful)

    by glwtta ( 532858 ) on Wednesday May 13, 2015 @09:29AM (#49681587) Homepage
    So every single vulnerability from now on is getting an idiotic media name?

    We can't have CVE-1234, no no, must be RageBoner or PantShitter or no one will take it seriously!

    • Re: (Score:1)

      by Anonymous Coward

      pantshitter sounds pretty serious.

    • at least heartbleed is vaguely googleable though perhaps describing a medical condition. venom not so much.

    • HAHAHA LOL "PantShitter" is the best name ever. I can only dream of a vulnerability with that name...I'd pay good money to see that name up on my work's Situation Management page.

    • We can't have CVE-1234, no no, must be RageBoner or PantShitter or no one will take it seriously!

      We can't have CVE-1234 exactly because no one will take it seriously, though I suspect you have the cause and effect reversed.

      When the CVE list numbers in the tens of thousands and contains everything from the trivial (program may crash) to the severe (remote code execution), CVE numbers are meaningless. It doesn't tell me just how important this vulnerability is and whether I should be concerned. Whereas if som

    • It's the same reason we name major storms, stars, mountains, comets, planets, galaxies, etc. Relax, it's a good thing.

  • most systems vulnerable, not as bad as it looks (Score:3)

    by Chirs ( 87576 ) on Wednesday May 13, 2015 @10:38AM (#49682187)

    There's a recent post on the openstack-operators mailing list talking about this, but the basic gist is that pretty much all versions of qemu are susceptible to the bug, but that in practice it's not quite as big a deal as it sounds.

    The thing to note is that the major linux distros by default enable something called "sVirt" which basically locks down qemu to using only the resources that have been explicitly assigned to it. This should make it hard (ideally impossible) to break out and compromise the host or other qemu processes.

    Also, on most major linux distros qemu doesn't run as root but rather as a separate user with lower privileges.

  • The vulnerable code is used in Xen, KVM, and VirtualBox, while VMware, Hyper-V, and Bochs are unaffected. "Dan Kaminsky, a veteran security expert and researcher, said in an email that the bug went unnoticed for more than a decade because almost nobody looked at the legacy disk drive system, which happens to be in almost every virtualization software."

    I note that the two proprietary systems were not impacted. Of course all software has bugs and vulnerabilities without regard to open source or proprietary, but here on slashdot we like think that open source is always the better option. This is not always the case.

    The phrase "almost every virtualization software" is used, but the list of items given has three pieces of software that are impacted and three that are not. In terms of virtualization systems that are in production use by business, I would thi

  • But what if you're running your VM within a VM? Will the malware know it's still in a dream?

  • Xen security advisory notes that Xen paravirtualized setup is not vulnerable. It only strikes HVM, where the host OS is run unmodified and think it has access to a real floppy drive.

Slashdot Top Deals

It's a naive, domestic operating system without any breeding, but I think you'll be amused by its presumption.

Close