VirtualBox Slirp NAT Packet Heap Exploitation

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

TL;DR

  • VirtualBox ships a heavily modified fork of Slirp whose packet buffers (mbufs) live in a custom zone allocator with inline metadata and function-pointer callbacks (pfFini, pfDtor).
  • A guest can rewrite the trusted m->m_len with an attacker-controlled IP header length, which destroys all later bounds checks and yields both infoleak and overwrite primitives.
  • By abusing UDP packets with checksum 0 and oversized ip_len, the guest can exfiltrate mbuf tails and the metadata of neighbouring chunks to learn heap and zone addresses.
  • Providing crafted IP options forces ip_stripoptions() to memcpy() too much data in-place, so the attacker can overwrite the next mbuf’s struct item header and point its zone field at fully controlled data.
  • Freeing the corrupted mbuf triggers zone->pfFini() with attacker-supplied arguments; pointing it to memcpy@plt gives an arbitrary copy/write primitive that can be steered toward GOT entries or other control data inside the non-PIE VirtualBox binary.

Packet allocator anatomy

VirtualBox allocates every ingress Ethernet frame from a per-interface zone named zone_clust. Each 0x800-byte data chunk is preceded by an inline header:

struct item {
    uint32_t magic;      // 0xdead0001
    void    *zone;       // uma_zone_t pointer with callbacks
    uint32_t ref_count;
    LIST_ENTRY(item) list; // freelist / used list links
};

When an mbuf is freed the call stack m_freem -> ... -> slirp_uma_free() trusts the inline header:

  1. uma_zfree_arg() recomputes item = (struct item *)mem - 1 and should validate item->zone, but Assert() is compiled out in release builds.
  2. slirp_uma_free() loads zone = item->zone and unconditionally executes zone->pfFini(zone->pData, data_ptr, zone->size) followed by zone->pfDtor(...).

Therefore, any write-what-where into the mbuf header translates into a controlled indirect call during free().

Infoleak via m->m_len override

At the top of ip_input() VirtualBox added:

if (m->m_len != RT_N2H_U16(ip->ip_len))
    m->m_len = RT_N2H_U16(ip->ip_len);

Because the assignment happens before verifying the IP header, a guest can advertise any length up to 0xffff. The rest of the stack (ICMP, UDP, fragmentation handlers, etc.) assumes m->m_len is trustworthy and uses it to decide how many bytes to copy off the mbuf.

Use UDP packets with checksum 0 (meaning “no checksum”). The NAT fast-path forwards m->m_len bytes without inspecting payload integrity, so inflating ip_len causes Slirp to read past the real buffer and return heap residues to the guest or to a cooperating external helper beyond the NAT. Because the chunk size is 2048 bytes, the leak can include:

  • The next mbuf’s inline struct item, revealing the freelist order and the real zone pointer.
  • Heap cookies such as magic fields, helping to craft valid-looking headers when performing corruptions later.

Overwriting neighbouring chunk headers with IP options

The same bogus length can be turned into an overwrite primitive by forcing the packet through ip_stripoptions() (triggered when the IP header has options and the payload is UDP/TCP). The helper computes a copy length from m->m_len and then calls memcpy() to slide the transport header over the stripped options:

  1. Supply a long ip_len so the computed move length extends past the current mbuf.
  2. Include a small number of IP options so Slirp enters the stripping path.
  3. When memcpy() runs, it reads from the following mbuf and writes over the current mbuf’s payload and inline header, corrupting magic, zone, ref_count, etc.

Because the allocator keeps packets from the same interface contiguous on the freelist, this overflow deterministically hits the next chunk after modest heap grooming.

Forging uma_zone_t to hijack pfFini

Once the adjacent struct item is corruptible, the exploit proceeds as follows:

  1. Use leaked heap addresses to build a fake uma_zone structure inside a mbuf fully controlled by the guest. Populate:
    • pfFini with the PLT entry of memcpy().
    • pData with the desired destination pointer (e.g. GOT entry, vtable slot, function pointer array).
    • size with the number of bytes to copy.
    • Optional: pfDtor as a second stage call (e.g. to invoke the newly-written function pointer).
  2. Overwrite the target mbuf’s zone field with the pointer to the fake structure; adjust list pointers so freelist bookkeeping remains consistent enough to avoid crashes.
  3. Free the mbuf. slirp_uma_free() now executes memcpy(dest=pData, src=item_data, n=size) while the mbuf still contains guest-controlled data, yielding an arbitrary write.

Because the Linux VirtualBox binary is non-PIE, PLT addresses for memcpy and system are fixed and can be used directly. The guest can also stash strings such as /bin/sh inside another mbuf that remains referenced when the hijacked call executes.

Heap grooming via fragmentation

Slirp’s per-interface zone is 3072 chunks deep and initially carved as a contiguous array whose freelist is traversed from high addresses downward. Deterministic adjacency can be achieved by:

  • Flooding the NAT with many IP_MF fragments of constant size so the reassembly code allocates predictable mbuf sequences.
  • Recycling specific chunks by sending fragments that time out, forcing frees back into the freelist in LIFO order.
  • Using knowledge of the freelist walk to place the future victim mbuf right after the mbuf that will carry the IP options overflow.

This grooming ensures the overflow hits the targeted struct item and that the fake uma_zone remains in-bounds of the leak primitive.

From arbitrary write to host code execution

With the memcpy-on-free primitive:

  1. Copy an attacker-controlled /bin/sh string and command buffer into a stable mbuf.
  2. Use the primitive to overwrite a GOT entry or indirect callsite (e.g. a function pointer inside the NAT device state) with the PLT entry of system().
  3. Trigger the overwritten call. Because VirtualBox runs the NAT device inside the host process, the payload executes with the privileges of the user running VirtualBox, allowing a guest-to-host escape.

Alternative payloads include planting a miniature ROP chain in heap memory and copying its address into a frequently-invoked callback, or repointing pfFini/pfDtor themselves to chained gadgets for repeated writes.

References

Tip

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks