# Venom Security Vulnerability



## KMyers (May 13, 2015)

Hello All,

It seems like there is a major bug in several server visualization platforms including QEMU and Xen that could allow an attacker to take over a complete node.

http://www.zdnet.com/article/venom-security-flaw-millions-of-virtual-machines-datacenters/?tag=nl.e589&s_cid=e589&ttag=e589&ftag=TREc64629f

Any thoughts?


----------



## Gang Starr (May 13, 2015)

KMyers said:


> Any thoughts?


Yes, we shall be thankful it was detected and we shall pray and wait for a fix  .


----------



## KMyers (May 13, 2015)

Edit : More details - http://venom.crowdstrike.com/


----------



## DomainBop (May 13, 2015)

> Subject     [sECURITY] [DSA 3259-1] qemu security update
> 
> 
> Date     Today 18:07
> ...


----------



## KuJoe (May 13, 2015)

Has anybody seen an update for CentOS 5 yet? Looks like CentOS 6 is taken care of but nothing for CentOS 5 in any of the mirrors I've checked.


----------



## zzrok (May 13, 2015)

The only thing on the announcement mailing list so far for Centos 5 is xen.


----------



## MannDude (May 13, 2015)

These vulnerabilities keep getting more and more creative names.

I predict we'll see a "Nuclear Aids" vulnerability in the next two years.


----------



## KuJoe (May 13, 2015)

MannDude said:


> These vulnerabilities keep getting more and more creative names.
> 
> I predict we'll see a "Nuclear Aids" vulnerability in the next two years.


Imagine how much sooner the exploit would have been reported to the right channels if they didn't have to figure out a fancy name and  wait for a logo to be created, website built, domain purchased, and hosting provisioned.


----------



## rds100 (May 13, 2015)

@KuJoe Just checked our CentOS mirror - there were these new/updated packages for CentOS 5:

5.11/updates/i386/RPMS/xen-3.0.3-146.el5_11.i386.rpm
5.11/updates/i386/RPMS/xen-3.0.3-146.el5_11.i686.rpm
5.11/updates/i386/RPMS/xen-devel-3.0.3-146.el5_11.i386.rpm
5.11/updates/i386/RPMS/xen-devel-3.0.3-146.el5_11.i686.rpm
5.11/updates/i386/RPMS/xen-libs-3.0.3-146.el5_11.i386.rpm
5.11/updates/i386/RPMS/xen-libs-3.0.3-146.el5_11.i686.rpm
 

But nothing for qemu or kvm ont CentOS 5.


----------



## joepie91 (May 13, 2015)

KuJoe said:


> Imagine how much sooner the exploit would have been reported to the right channels if they didn't have to figure out a fancy name and  wait for a logo to be created, website built, domain purchased, and hosting provisioned.


Doubtful. Vendors typically get advance notice.


----------



## Francisco (May 13, 2015)

Since I just woke up, has anyone confirmed if checkpointing a KVM would work or does that actually save a copy of the binary into memory too?

From what http://libvirt.org/guide/html/Application_Development_Guide-Lifecycle-Save.html is saying, it's only saving the VM's memory and not the entire binary, which means it should technically be able to boot the VPS back up on the new binary and continue onwards.

Since there's no POC out there's no way to know, but the above makes sense to me.

Any feedback?

*EDIT* - Since they said live-migrating a VM from a node, updating the node, and migrating ti back is perfectly OK and will have them running on an updated binary, a 'virsh save' should be fine. I still wish there was a way to test.

Francisco


----------



## Francisco (May 13, 2015)

https://github.com/juergh/lqs2mem outlines what a 'virsh save' looks like and it seems to be what I was thinking.

Since the exploit isn't in the BIOS or .rom files, it'd be OK.

Francisco


----------



## rds100 (May 13, 2015)

Updated kvm packages for CentOS 5 were released too.

5.11/updates/x86_64/RPMS/kmod-kvm-83-272.el5.centos.x86_64.rpm
5.11/updates/x86_64/RPMS/kmod-kvm-debug-83-272.el5.centos.x86_64.rpm
5.11/updates/x86_64/RPMS/kvm-83-272.el5.centos.x86_64.rpm
5.11/updates/x86_64/RPMS/kvm-qemu-img-83-272.el5.centos.x86_64.rpm
5.11/updates/x86_64/RPMS/kvm-tools-83-272.el5.centos.x86_64.rpm


----------



## HalfEatenPie (May 13, 2015)

I believe Proxmox has yet to receive updates on this.  

Anyone else confirm?


----------



## dcdan (May 14, 2015)

Time to switch to OpenVZ :lol:

Generally whenever there is an OpenVZ-related exploit first thing you hear is "everyone should switch to KVM". For some reason it does not work the other way.


----------



## HalfEatenPie (May 14, 2015)

dcdan said:


> Time to switch to OpenVZ :lol:
> 
> Generally whenever there is an OpenVZ-related exploit first thing you hear is "everyone should switch to KVM". For some reason it does not work the other way.


Everyone should switch to VMWare.

Kek.


----------



## DomainBop (May 14, 2015)

HalfEatenPie said:


> Everyone should switch to VMWare.


rebuttal to the pie's suggestion -->  http://www.vmware.com/security/advisories/


----------



## dabtech (May 14, 2015)

HalfEatenPie said:


> I believe Proxmox has yet to receive updates on this.
> 
> Anyone else confirm?


http://forum.proxmox.com/threads/22127-Venom-vulnerablity?p=111920#post111920

In pvetest, hopefully it'll hit the stable repo's soon.


----------



## Hxxx (May 14, 2015)

This is why exactly the "cloud" (see the ")  is not ready for PHI. Doesn't matter how much certified is the provider. Bugs like these make all the certifications go down the toilet.


----------



## KuJoe (May 14, 2015)

Hxxx said:


> This is why exactly the "cloud" (see the ")  is not ready for PHI. Doesn't matter how much certified is the provider. Bugs like these make all the certifications go down the toilet.


In reality, how many medical facilities are buying VPSs for their infrastructure or allowing outside parties on their servers? I doubt many if any at all.


----------



## Hxxx (May 14, 2015)

KuJoe said:


> In reality, how many medical facilities are buying VPSs for their infrastructure or allowing outside parties on their servers? I doubt many if any at all.


Well Joe, the answer to that is a lot.

Many facilities or organization use virtualization platforms in external locations. To just point a popular provider in this matter: Firehost

That is to host applications related to the field which contains PHI.

Another example is cloud backups (though you are supposed to encrypt these).


----------



## MartinD (May 14, 2015)

The vast majority of those outfits will be running in-house networks that would really only be attacked by people on the 'inside'. Still serious nonetheless.


----------



## KuJoe (May 14, 2015)

Hxxx said:


> Well Joe, the answer to that is a lot.
> 
> Many facilities or organization use virtualization platforms in external locations. To just point a popular provider in this matter: Firehost
> 
> ...


Based on their information it doesn't look like they are using shared servers like most VPS providers. Being HIPPA compliant is no joke (and something I never want to be involved in ever again) and you cannot be HIPPA compliant if you're hosting other clients on the infrastructure so an exploit like this would have no impact on this unless of course they compromised a server on their network which can happen in any environment.


----------



## Hxxx (May 14, 2015)

KuJoe said:


> Based on their information it doesn't look like they are using shared servers like most VPS providers. Being HIPPA compliant is no joke (and something I never want to be involved in ever again) and you cannot be HIPPA compliant if you're hosting other clients on the infrastructure so an exploit like this would have no impact on this unless of course they compromised a server on their network which can happen in any environment.


We are talking about VPS, Cloud, anything virtualized. Firehost is virtualized. How familiar are you with HIPAA and the requirements, because you can get compliance using a Cloud container such as the firehost or Amazon, or Microsoft, or Google. Plus the compliance is a mix of many things , from datacenter certification to ---------------------- office certification---------------------workstations compliance. Is a lot of things, (i worked in the field and had to assist some of my past clients).

But to end the blah, my intentions were not to derailed the thread, simply put, any platform using such virtualization technologies (not to forget the past emergency patches) could at some point leave the data to be compromised. Thought again, you are supposed to encrypt.


----------



## joepie91 (May 14, 2015)

Hxxx said:


> any platform using such virtualization technologies (not to forget the past emergency patches) could at some point leave the data to be compromised. Thought again, you are supposed to encrypt.


The same applies for a physical server. And "encrypting" in and of itself isn't going to do anything, unless you actually have a split architecture where encryption is automatic but decryption is not (eg. using public key cryptography). Anything else is security theater.


----------



## KMyers (May 14, 2015)

MartinD said:


> The vast majority of those outfits will be running in-house networks that would really only be attacked by people on the 'inside'. Still serious nonetheless.


True however if a flaw exists on one VM in that infrastructure such as an unpatched flaw in a web application or other 0-day, an attacker could still gain administrative access to a container on the network and could potentially use VENOM to travel into other containers.


----------

