@portfast
News & views, serious business.
News & views, serious business.
If you work anywhere near computers then you can't have missed the VENOM bug that has been in the news today.
It's an interesting one as it could allow code execution on a virtual machine's physical host, with the privileges of the emulator. This is something we always anticipated when building this platform, and each of our VMs runs as its own user, in a chroot with no permission to write or execute anything, so we hope this should prove an adequate trap should anyone try and exploit this particular bug.
We are obviously in the process of rolling out a patched qemu binary and where possible live migrating users over to it. We have a slight problem there in that the older VMs are running on qemu-kvm v1, which although it seems it should migrate into a v2 hypervisor, doesn't work terribly reliably and the failure mode is for both sides to crash.
We were planning to roll out v2 across the board slowly over a period of months to allow people to reboot into it in their own time, but as this has forced our hand somewhat, we will need to do these reboots imminently. Since some of the older VMs on the v1 platform will have uptimes of well over 1000 days, a reboot is probably due.
To this end, there's now a bit of code on each host which listens for reboot events and patches the metadata of the VM to start it up with the v2 hypervisor. From the inside, this should be identical to v1. There are instructions on how to connect to the VM's out of band console in the admin pages, but if you have any problems rebooting then give us a call.