Venom vulnerablity

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

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.

While true on one level, I'm not sure on the proof of concept - if it was just a code review or an actual exploit the finder was able to take advantage of - that level of information is somewhat missing.

In terms of public facing vms - even when properly secured, there is always a risk of a vulnerability in some other service that might allow the attacker to drop into a shell that hasn't been found or patched yet - even a fully updated guest could have a vulnerability not announced or - depending on the patch compared to upstream cycle has just not yet made it.

From what I understood of the exploit, not only would it potentially allow the vms on that host to be compromised, but you actually then have access to the host and subsequently the private networks the host connects to which is where the issue becomes significantly more concerning. The potential threat is obviously significant enough to have organizations jump on getting it patched, I'm pretty sure redhat has generated a patch for their enterprise - according to their portal, it will undergo testing and should be available for them early next week (heck, they even appear to have a detection tool for their enterprise customers to determine if they are vulnerable - I can't tell for sure how/what it does since I don't have access to that area of their web portal).
 
The venom.sh script simply check signature and version of installed qemu-kvm and compares to blacklist. If the installed qemu-kvm package version is on the blacklist you are greeted with:
WARNING: qemu-kvm-${version} is out of date and vulnerable. Please update to newest version. Refer to https://access.redhat.com/articles/1444903 for more information.
 
The venom.sh script simply check signature and version of installed qemu-kvm and compares to blacklist. If the installed qemu-kvm package version is on the blacklist you are greeted with:
WARNING: qemu-kvm-${version} is out of date and vulnerable. Please update to newest version. Refer to https://access.redhat.com/articles/1444903 for more information.

Interesting - so it really doesn't do a test of any kind aside from a version check. Well, now that dietmar has released a fix, I'm off to shifting VMs around :)
 
Hello Dietmar,
I just subscribed "Proxmox VE Community Subscription 1 CPU/year" and activated the update service on my server.
I have no upgrade proposed in the web interface, neither with apt-get update / upgrade.
Maybe you didn't yet pushed the update to the suscribers repository ?
Best regards,
Gautier HUSSON
 
post the output of:

> pveversion -v

maybe you got already the fixed package.
 
post the output of:
> pveversion -v

Code:
proxmox-ve-2.6.32: 3.3-147 (running kernel: 2.6.32-37-pve)
pve-manager: 3.4-1 (running version: 3.4-1/3f2d890e)
pve-kernel-2.6.32-37-pve: 2.6.32-147
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.7-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.10-2
pve-cluster: 3.0-16
qemu-server: 3.3-20
pve-firmware: 1.1-3
libpve-common-perl: 3.0-24
libpve-access-control: 3.0-16
libpve-storage-perl: 3.0-31
pve-libspice-server1: 0.12.4-3
vncterm: 1.1-8
vzctl: 4.0-1pve6
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 2.1-12
ksm-control-daemon: 1.1-1
glusterfs-client: 3.5.2-1
 

Would you please let me know the pve-qemu-kvm version which has fixed this vul ?
 
Only stop and start VMs after upgrade is enough or I should reboot the physical server too?
 
Only stop and start VMs after upgrade is enough or I should reboot the physical server too?

start/stop (or live-migrate) your VM. a reboot is not needed.
 
Hi all,

We ran an
apt-get update; apt-get install pve-qemu-kvm
across a few client servers, but did not reboot.
A client server had just started after a planned power outage and No vms would start due to
error: detected old qemu-kvm binary (unknown)
[h=1][/h]A dist-upgrade brought it back, but this made me concerned with how it got into this state.

Am I right in saying that the newer pve-qemu-kvm package has dependencies that weren't announced by the apt-get process?

Please advise.
 
Hi all,

We ran an
apt-get update; apt-get install pve-qemu-kvm
across a few client servers, but did not reboot.
A client server had just started after a planned power outage and No vms would start due to
error: detected old qemu-kvm binary (unknown)
A dist-upgrade brought it back, but this made me concerned with how it got into this state.

Am I right in saying that the newer pve-qemu-kvm package has dependencies that weren't announced by the apt-get process?

Please advise.

Follow the update instruction on:

http://pve.proxmox.com/wiki/Downloads#Update_a_running_Proxmox_Virtual_Environment_3.x_to_latest_3.4
 
Hi Tom,

I am aware of the proper version upgrade procedure, however I am questioning if I should have been warned about apparent dependencies when installing solely the newer patched pve-qemu-kvm package.

Please re-read my post.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!