VMware recently released a patch on November 12th for CVE-2019-5540, an identified vulnerability within vmnetdhcp. When first reading this, I didn’t think much of it considering the “dhcp” inclusion. However, when reading the summary of the vulnerability on VMware’s website, my opinion of this changed and I thought it’d be important to briefly discuss this further.
Per VMware’s website, the “Known Attack Vectors” section states “Successful exploitation of this issue may allow an attacker on a guest VM to disclose sensitive information by leaking memory from the host process.”
That may not mean much if you’re not familiar with this threat, and the full extent of this vulnerability is not particularly clear, but guest VMs should be isolated from the machine hosting them. Imagine having a host system and a few VMs set up using a VMware product (Workstation or Fusion per the link). VMs can be used for various reasons but for me, I use them to have an isolated environment to conduct research or perform malware analysis that I wouldn’t want to directly do on my host system. This is also common for behavioral or analytical investigations for unknown threats. Now, imagine having one of the VMs exploiting this vulnerability. That VM would have obtained a portion of the physical host’s memory that was allocated to that process.
What’s not clear about this vulnerability is the extent of what’s disclosed in this leaked memory. Hypervisor’s (virtualization software) run VMs as processes and each VM runs on an independent process with its own appropriated amount of memory. Thinking about it like this essentially means that the VM can leak its own memory to itself. This isn’t too terrible I suppose, and this is perhaps why the severity of this vulnerability was only marked as “Important.” However, the saying “if you give them an inch, they’ll take a mile” comes into play here. And with the ever-changing threat landscape, I wouldn’t want a vulnerability like this looming around.