Video nasty lets VMware guests run code on hosts VMware's given vAdmins a busy Friday by disclosing three nasties to patch. One's a video nasty dubbed CVE-2017-4924 and impacts VMware ESXi, and the desktop hypervisors Workstation & Fusion. This one's “an out-of-bounds write vulnerability in SVGA driver device*” , an old virtual graphics card toolkit. The bug “may allow a …
The days of instruction sets being fully emulated are - unfortunately - gone. Most of the machine code of a program running in a VM actually runs directly on the host CPU when the VM CPU type is the same as the host, with only certain actions being trapped. I'm not up on the specific details, but its been like this for a long time now.
Err, yes; that's the difference between emulation and virtualisation. It's how code running in a VM gets native performance, not 1-2 orders of magnitude lower. I wouldn't call that unfortunate, I'd call it progress.
I think the issue here is essentially like a kernel vulnerability that can be exploited for privilege escalation. That is, it's a way to run code in the context of the host, instead of being restricted to the guest, like a kernel vulnerability may allow code to run in the context of the operating system, instead of being restricted to the user process.
"I wouldn't call that unfortunate, I'd call it progress."
Well hardly progress. If you want to run a contained program natively on a system you don't need a VM in the first place - virtual memory multi process OS's have been doing that for almost 50 years. Anyway, it would be nice if the option of pure virtualisation was available.
VMs are different from multi-process OS's -- If someone wants to run a RHEL5 user process but the kernel is Windows or MacOS or a different version. I.e. you need a multi-kernel "OS", which what the VM gives. Executing most instructions natively should be fine as long as dangerous instructions are intercepted.
In this case native/emulated does not seem to be the problem. Instead for SVGA at least, the issue is that to implement graphics for a VM running on desktop Fusion/Workstation you need code running in the hypervisor pretending to be real video hardware, possibly also different video/network drivers in the VM guest as well (e.g. "vmnet" instead of hardware ethernet). It looks like this code that emulates the SVGA hardware had the security bug.
"I.e. you need a multi-kernel "OS", which what the VM gives."
Yes, but how often does that happen? Usually VMs are used as an easy way to manage multiple large applications or user enviroments on Windows platforms since Windows itself isn't very good at it. DLL hell etc.
RE: "Yes, but how often does that happen? Usually VMs are used as an easy way to manage multiple large applications or user enviroments on Windows platforms since Windows itself isn't very good at it."
There's also this thing called cloud compute where people want to run VMs securely, no ...?
"There's also this thing called cloud compute where people want to run VMs securely, no ...?"
Cloud computing is nothing more than a marketing term, It has existed since before TCP/IP was invented and used to just be called a remote server. It doesn't require VMs at all to work though obviously they're supported, however most (all?) cloud providers give you the option of running natively on the metal.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
