LayerOne 2017

### Overview At LayerOne 2017, Ignat (an engineer at Cloudflare) presented on the inner workings and security implications of USB/IP in Linux, specifically detailing a remote vulnerability tracked as CVE-2016-3955 (nicknamed "u-boat"). USB/IP is a technology designed to forward USB Request Blocks (URBs) over a TCP network connection, enabling a client machine to import and manage physical USB devices attached to an exporting server. Ignat demonstrated how architectural design decisions in the Linux implementation—specifically delegating network protocol parsing directly to the kernel—resulted in a critical remote heap buffer overflow.

### Key Topics - **USB/IP Architecture:** A client-server model where an exporter server runs `usbipd` alongside kernel drivers (`usbip-core`, `usbip-host`/stub driver), and an importing client uses a user-space utility, `usbip-core`, and the Virtual Host Controller Interface (`vhci-hcd`) driver. - **Kernel-Level Protocol Handling:** Unlike standard Linux VPN architectures that follow the "tools in kernel, policy in user space" paradigm using tun/tap devices and userland daemons, USB/IP passes the TCP socket file descriptor directly to kernel space after initial negotiation, executing full application-layer protocol parsing in ring 0. - **Vulnerability Mechanics (CVE-2016-3955):** In the client receiving path, packet header parsing extracts payload length into URB metadata without verifying whether the target URB transfer buffer is sufficiently large before pulling the rest of the payload off the socket, resulting in an arbitrary-length heap buffer overflow. - **Exploitation and SLUB Manipulation:** Leveraging SLUB cache allocations to turn a denial-of-service crash into potential arbitrary kernel code execution or data tampering.

### Technical Details In a standard USB/IP workflow, a client negotiates device import via TCP with the server's daemon. Once successful, the socket descriptor is handed to the kernel `vhci-hcd` driver. When handling incoming packets, the kernel parses the USB/IP header directly into an internal kernel `urb` structure, storing the payload length into a variable (`size`) and immediately receiving that amount of data into `urb->transfer_buffer`. Because standard USB host drivers allocate fixed-size transfer buffers (assuming benign hardware that never returns more data than requested during enumeration or driver operations), an unvalidated network payload allows an attacker to write arbitrary bytes past buffer boundaries.

Ignat demonstrated this attack using an Ubuntu machine running a vulnerable vanilla 4.4.8 kernel. By running a rogue user-space USB/IP server written in Go (running on an unprivileged port above 1024), the server advertised a fake device (vendor/product ID `0xdeadbeef`). When the client attempted device enumeration (expecting a 64-byte response), the server returned 576 bytes, corrupting kernel heap memory and triggering a kernel crash. Because an attacker controls URB responses and can emulate arbitrary USB device profiles (which trigger `udev` to load specific drivers allocating in desired SLUB caches like `kmalloc-32`, `kmalloc-64`, etc.), an attacker can systematically direct which SLUB cache to target, significantly easing reliable kernel heap exploitation beyond single-chunk corruption limits.

### Takeaways To mitigate these risks, users should: 1. Reconsider using USB/IP unless strictly necessary, especially for inexpensive hardware. 2. Keep Linux kernels patched, as USB/IP kernel modules in modern distributions are maintained in mainline. 3. Wrap all USB/IP network communications in authenticated and encrypted tunnels (such as TLS), because USB/IP natively lacks encryption, authentication, or tamper protection, leaving it vulnerable to MITM attacks or rogue servers capable of spoofing malicious devices (e.g., keyboards or monitors).