lists.openwall.net   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  linux-hardening  linux-cve-announce  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]
Message-ID: <8ED9A241-70EC-4EED-B038-4B724B522534@rkw.io>
Date: Wed, 18 Oct 2017 08:34:44 +0100
From: "Mark Wadham" <fd@....io>
To: fulldisclosure@...lists.org
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 
release
- 4.0.24 - after that (but didn't update the public changelog on 
github).

Unfortunately 4.0.24 is still vulnerable, largely due to a fundamental 
design
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 
local
non-root user the encrypted ruby code that the plugin is comprised of 
must
remain owned by the non-root user. This means there is a huge attack 
surface
that we can exploit to manipulate the execution of the program and still 
get
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 
tricked
into working (at least partially) with Fusion 10 simply by patching out 
the
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 
monkey-patch
the version check out of the code, create a symlink for a binary that 
VMWare
moved in v10 and then we're away. I was able to vagrant up and ssh into 
the
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 
suid
helper binary with a new go binary that contains all the required 
elevated
operations and doesn't call back to the vulnerable ruby code.

ref: 
https://m4.rkw.io/blog/cve201712579-local-root-privesc-in-hashicorp-vagrantvmwarefusion-4024.html

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ