Edward, Thanks for the links. Great input as always. Great article on vmescape.com - also your article was great here as well. Totally agree that this is the wrong issue to worry about. Ho...
See more...
Edward, Thanks for the links. Great input as always. Great article on vmescape.com - also your article was great here as well. Totally agree that this is the wrong issue to worry about. However for those of us helping FUD-bound colleagues.... Although Mike's article was very good on this - if it has never happened on ESXi even internally at VMware, I wish he would come out and say "VM escape has never happened on ESXi" and make it clear. He says "Is there a risk? Of course" Also - the VMware security advisory says this: VMSA-2017-0006 "ESXi, Workstation, Fusion have a heap buffer overflow and uninitialized stack memory usage in SVGA. These issues may allow a guest to execute code on the host." For those of us trying to help FUD-bound colleagues - If a FUD-bound CISO looking for a problem with VMware reading the security advisory, it would give ammunition to the argument that ESXi is vulnerable to VM escape. It would have been more helpful for Mike to clarify like this: "Even though VMware says that this critical vulnerability may allow a guest to execute code on the host [including ESXi], that this has only been done on Workstation and noone has ever done it on ESXi even within VMware's internal labs / testing" Is there a reason he isn't saying it that emphatically? Also it seems the most recent successful VM escape on workstation was flip feng shui (correct me if wrong) https://www.vusec.net/projects/flip-feng-shui/ and would be helpful to explain in more specific technical detail why even though this exploit was done on workstation and a critical patch released by VMware for ESXi, that it could not and has not ever been executed on ESXi. Thoughts?