Venom vulnerablity

[chrisalavoine]

Hi all,

Would this affect Proxmox? I am running a mixture of 2.3 and 3.4 hosts.

http://www.zdnet.com/article/venom-security-flaw-millions-of-virtual-machines-datacenters/

Thanks,
Chris.

 

[sumsum]

I think that CVE-2015-3456 is affecting all Linux Distributions using an unpatched version of qemu - according the link you are refering to

 

[debian112]

I think that CVE-2015-3456 is affecting all Linux Distributions using an unpatched version of qemu - according the link you are refering to

So what will be the fix? Is this something proxmox will have, or debian? I assume debian?

 

[dallen1]

I would think it'd be Proxmox. The package PVE uses is called pve-qemu-kvm. It looks like RHEL already got a patch for their system available in their repos. hopefully we'll have one soon. https://access.redhat.com/articles/1444903

 

[Sakis]

After update (when it will be available) we will have to stop start all kvms, right?

 

[debian112]

I would think it'd be Proxmox. The package PVE uses is called pve-qemu-kvm. It looks like RHEL already got a patch for their system available in their repos. hopefully we'll have one soon. https://access.redhat.com/articles/1444903

Yeah, I just saw the package: pve-qemu-kvm

 

[Sakis]

Can we have an official update that this fixes the bug? (i see 2.2-8 as the last version.)

 

[nethfel]

I wonder if we can live migrate our running vms to another server in the cluster, update a given machine and live migrate the vms back to allow us to not have to reboot all of the vms and repeat the process for each node...?

 

[BloodyIron]

Proxmox devs have been pretty good about addressing vulnerabilities in the past. Looking forward to their statement when one is ready.

I'm sure they'll do the right thing. For now I guess we just keep bumping this thread to keep it on the radar.

Dear Proxmox devs, you rock.

 

[e100]

They are on top of this:
http://pve.proxmox.com/pipermail/pve-devel/2015-May/015123.html

I suspect that once an update is out you will be able to live migrate into the updated QEMU/KVM on another server or you will need to stop/start your VMs.

 

[mir]

This is the patch for Debian, right?

 

[dietmar]

We do not have support for FDC, so why do you think we are affected?

 

[Sakis]

We can use floppy disks with adding for example
-fda /path/disk.vfd
If a KVM is started without this option means that is not vulnerable?

https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/
"It is also exposed regardless of presence of any floppy related QEMU command line options so even guests without floppy disk explicitly enabled in the libvirt or Xen configuration files are affected."

 

[m.ardito]

We do not have support for FDC, so why do you think we are affected?

is the -fda switch still usable in .conf files? would this usage expose the node to the vulnerability?

(sorry after posting I saw the coment above)

Marco

 

[daedalus]

It doesn't matter whether or not the switch is there. Due to a secondary bug the vulnerable code is always active.

 

[tom]

we just uploaded a patched version to pvetest:

http://download.proxmox.com/debian/dists/wheezy/pvetest/binary-amd64/pve-qemu-kvm_2.2-10_amd64.deb

please test.

 

[Sakis]

Please provide a check procedure if possible.

Thank you.

 

[nethfel]

That is a good point - unlike things like heartbleed and shellshock, I don't know of any easy way to test for the vulnerability (which may be because of the "non-trivial" nature of taking advantage of it). If anyone does find a way to test, please share it!

Also, I'm wondering what everyone is doing with regard to their public facing VMs at this point?

 

[term]

From my understanding, no proof of concept has been released yet that targets this particular problem, but I am sure people are working on it now that its been announced. Until then, it's all "theory".

The risk is biggest for VPS providers. If I was one, I would be applying this ASAP whatever the cost may be.

Public facing VMs are ok as long as they are properly secured. The fun begins if someone gets access to one of your public facing guest VMs, which is a big problem anyway. Once they get in there, in theory the rest of the VMs on that host are compromised.

 

[dietmar]

I uploaded the fix to all proxmox repositories now.