| 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
| ||
|
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