Monorail Project: project-zero Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 1037 VirtualBox: cooperating VMs can escape from shared folder
Starred by 1 user Project Member Reported by jannh@google.com, Dec 12 Back to list
Status: Fixed
Owner:
Closed: Mar 9
Cc:



Sign in to add a comment
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.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.
 
vboxsf_new.patch
1.4 KB Download
openspam.c
1.1 KB View Download
renamespam.c
227 bytes View Download
Project Member Comment 1 by jannh@google.com, Dec 12
Oracle assigned tracking# S0808102
Project Member Comment 2 by jannh@google.com, Dec 16
Oracle informed me that they can't roll out patched binaries before 2017-04-18.
Project Member Comment 3 by jannh@google.com, Feb 16
Oracle informed me in January that they're going to release a patched version on 2017-03-12, which is the deadline, or before that date.
Project Member Comment 4 by jannh@google.com, Mar 6
Oracle informed me that they're planning to release a fixed version on 2017-03-08.
Project Member Comment 5 by jannh@google.com, Mar 9
Status: Fixed
Oracle said that they were planning to fix the bug in 5.1.16 and 5.0.34, which have been released now. I have verified that the source release and the debian package for version 5.1.16 contain a fix. vbsfPathGuestToHost() now uses RTPathAbsEx() to make the path absolute, and afterwards, it checks whether the expected directory prefix is still present using RTPathStartsWith().

The patch is not yet in the SVN repository.
Project Member Comment 6 by jannh@google.com, Mar 13
Labels: -Restrict-View-Commit
Project Member Comment 7 by jannh@google.com, Apr 15
Labels: CVE-2017-3538
Sign in to add a comment