lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 18 Oct 2017 08:34:44 +0100
From: "Mark Wadham" <>
Subject: [FD] CVE-2017-12579 Local root privesc in Hashicorp
 vagrant-vmware-fusion 4.0.24

I have previously disclosed a couple of bugs in Hashicorp's
vagrant-vmware-fusion plugin for vagrant.

Unfortunately the 4.0.23 release which was supposed to fix the previous 
bug I
reported didn't address the issue, so Hashicorp quickly put out another 
- 4.0.24 - after that (but didn't update the public changelog on 

Unfortunately 4.0.24 is still vulnerable, largely due to a fundamental 
flaw in the way the plugin is written combined with the need to elevate
privileges for certain functions within Fusion.

Because Hashicorp need users to be able to update the plugin as the 
non-root user the encrypted ruby code that the plugin is comprised of 
remain owned by the non-root user. This means there is a huge attack 
that we can exploit to manipulate the execution of the program and still 
root on 4.0.24.

I wrote this exploit before Fusion 10 was released and on the surface 
4.0.24 is
not compatible with Fusion 10. Curiously though it can be fairly easily 
into working (at least partially) with Fusion 10 simply by patching out 
version check and creating a symlink. I discovered this while trying to 
get the
4.0.24 exploit working with Fusion 10 installed - we can simply 
the version check out of the code, create a symlink for a binary that 
moved in v10 and then we're away. I was able to vagrant up and ssh into 
running vm without any issues. It also means I was able to update the 
exploit so
that it works on Fusion 8.x and Fusion 10.

This seems to be (finally!) fixed properly in 4.0.25 by replacing the 
helper binary with a new go binary that contains all the required 
operations and doesn't call back to the vulnerable ruby code.


Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists