As a user of VMWare Fusion on OS X it happened to me to briefly look for security issues. I found 2 very trivial kernel infoleaks.

If you are interested into VMWare, you may be interested also in our Shakacon 2016 talk, 50 Shades of Fuzzing, where we discussed some details about VMWare GPU/Graphics fuzzing.

As you may know, OS X ships with kASLR (kernel ASLR) from quite some time, so it’s very important that pointers are not leaked to userspace, since it will defeat or weaken the kernel ASLR.

We already discussed one of those infoleak in our presentation at CanSecWest16, for which a OS X graphic driver was the culprit.

This mentioned issue was leaking a pointer in the IORegistry. Another way for the kernel to share variables to userspace is with sysctl.

You can read those sysctl easily with the help of the sysctl command on OS X.

So as you can imagine I’m saying this because the leaks are inside a sysctl variable.

If you have a OS X guest virtual machine in VMWare fusion, inside this VM you can try to run:

➜  ~ sudo sysctl -Ax | grep vmware

com_vmware_tools_vmhgfs.staticBase: 0xffffff7fa185f679

com_vmware_tools_vmhgfs.heapBase: 0xffffff8028b5e901

And the second issue, in the OS X Host itself also leaks pointers:

➜  Downloads sudo sysctl -Ax | grep vmware

com_vmware_fusion_vmnet.apiVersion: 0x00060000

com_vmware_fusion_vmnet.buildNumber: 0x0031ee2d

com_vmware_fusion_vmnet.staticBase: 0xffffff7f9a8bdf5a

com_vmware_fusion_vmnet.heapBase: 0xffffff803a0b4aa1

com_vmware_fusion_vmmon.apiVersion: 0x01340000

com_vmware_fusion_vmmon.buildNumber: 0x0031ee2d

com_vmware_fusion_vmmon.driverInUse: 0x00000001

com_vmware_fusion_vmmon.staticBase: 0xffffff7f9a8c90c2

com_vmware_fusion_vmmon.heapBase: 0xffffff8037e43a91

com_vmware_fusion_vmioplug.apiVersion: 0x000f0107

com_vmware_fusion_vmioplug.buildNumber: 0x0031ee2d

com_vmware_fusion_vmioplug.staticBase: 0xffffff7f9a8da9f2

com_vmware_fusion_vmioplug.heapBase: 0xffffff80404cc391

Other GPU memory corruptions bugs are pending, found by fuzzing like described in 50 Shades of Fuzzing but no expected time for fixes is given yet.

Timeline:

  • 2016/3/26 The issues is reported to the VMWare Security Team via email at security@vmware.com.
  • 2016/3/31 Still no reply or acknowledgement, I sent them an email again.
  • 2016/3/31 I received a reply, they are investigating the issues internally.
  • 2016/06/14 CVE-2016-5328 and CVE-2016-5329 are reserved. VMWare couldn’t make the fix in the last update, they will try to bundle the fix in an update scheduled for Q3 2016.
  • 2016/09/17 The Host infoleak seems fixed, but no security advisory is issued. The Guest infoleak is still present.
  • 2016/10/26 The isses are fixed and the advisory is published here.

Take aways:

  • Vendors must keep their threat model update. With System Integrity Protection usermode root is not the end of the game. You have to compromise the kernel to disable SIP usually, so you should not leak those informations even to root.