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!
VirtualBox - Cooperating VMs can Escape from Shared Folder Exploit
Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1037 There is a security issue in the shared folder implementation that permits cooperating guests with write access to the same shared folder to gain access to the whole filesystem of the host, at least on Linux hosts. The issue is that, when the host checks whether a given path escapes the root directory of the shared folder in vbsfPathCheckRootEscape(), the function assumes that the directory hierarchy is static: E.g. the path "base/a/b/c/../../.." is assumed to be equivalent to "base/a/b/../..", "base/a/.." and "base". However, at least on Linux, renames can occur at the same time as path traversal. This means that, if VM A attempts to open "base/a/b/c/../../../foo" while VM B is moving "base/a/b/c" to "base/c_", VM A might actually end up opening "base/../../foo" instead of "base/foo". To demonstrate the issue, on a Linux host with Virtualbox 5.1.10: - Place a file called "real_root_marker" in the root directory of the Linux host, containing some secret text. The VMs will attempt to obtain the contents of this file. root@host:/# echo "this is secret text in the host fs" > /real_root_marker - Create two Linux VMs with a shared writable folder. - In the VMs, install the guest extensions, with the attached patch vboxsf_new.patch applied. - In the VMs, ensure that the new vboxsf kernel module is loaded and that the shared folder is mounted. - In VM A, compile and run the attached file openspam.c: root@vmA:/media/sf_vboxshared# gcc -o openspam openspam.c -std=gnu99 root@vmA:/media/sf_vboxshared# ./openspam entering directory... entered directory and prepared folders, racing... - In VM B, compile and run the attached file renamespam.c: root@vmB:/media/sf_vboxshared# gcc -o renamespam renamespam.c -std=gnu99 root@vmB:/media/sf_vboxshared# ./renamespam Now, in VM A, you should see the contents of the host's /real_root_marker within seconds: SUCCESS this is secret text in the host fs EOF Note: The exploit assumes that the shared folder isn't more than nine levels away from the filesystem root. # 0day.today [2024-12-24] #