CVE-2024-3661: Technical Analysis of DHCP Option 121 Route Injection
CVE-2024-3661, colloquially known as TunnelVision, identifies a fundamental design flaw in how various operating systems handle DHCP Option 121, allowing an attacker on the same local network to force traffic outside of an active VPN tunnel. By acting as a rogue DHCP server or compromising a legitimate one, an adversary can inject classless static routes into a victim’s routing table that take precedence over the virtual network interface's default gateway. This technique effectively "decloaks" the user by routing specific or global traffic through the attacker-controlled gateway rather than the encrypted VPN interface, bypassing the security guarantees of VPNWG compliant protocols and standard tunneling implementations.
The Mechanics of Routing Precedence
To understand TunnelVision, one must analyze the Longest Prefix Match (LPM) algorithm used by IP routing tables. Most VPN providers secure traffic by creating a virtual network interface (e.g., tun0 or utun1) and setting a default route (0.0.0.0/0) through this interface. While this captures all traffic not destined for the local link, it is the least specific route possible. DHCP Option 121 (RFC 3442) allows a DHCP server to provide a list of static routes that the client should install. These routes are inherently more specific than a /0 default route.
In a TunnelVision attack, the rogue DHCP server sends two specific routes: 1.0.0.0/1 and 128.0.0.0/1. Together, these two prefixes cover the entire IPv4 address space. Because a /1 prefix is more specific than a /0 prefix, the operating system's routing stack prioritizes these injected routes over the VPN’s default route. Consequently, traffic is sent to the local network gateway defined in the DHCP offer, completely bypassing the VPN's encapsulation and encryption. This occurs even if a "kill switch" is active, as many kill switches are implemented as firewall rules that allow traffic to the local gateway to maintain network connectivity.
DHCP Option 121 Specification (RFC 3442)
The vulnerability leverages the intended functionality of DHCP Option 121, which was designed to allow routers on a local segment to inform hosts of specialized paths to other subnets. The option format consists of a set of destination descriptors and their corresponding next-hop gateways. A destination descriptor includes a width (mask) followed by the significant octets of the destination IP.
Option 121 Data Format: Code: 121 Length: n Data: [Mask][Dest IP][Gateway IP]
For an attacker to capture all traffic, the payload in the DHCP ACK would look similar to the following configuration in a tool like dnsmasq:
# dnsmasq.conf snippet for TunnelVision dhcp-option=121,1.0.0.0/1,192.168.1.1,128.0.0.0/1,192.168.1.1
When the victim connects to the network, the OS processes the ACK and updates the routing table. A netstat -rn or ip route show on the victim machine would reveal that while the VPN's 0.0.0.0/0 route exists, the 1.0.0.0/1 and 128.0.0.0/1 routes pointing to 192.168.1.1 (the attacker's gateway) take priority for all non-local traffic.
Operating System Vulnerability Matrix
The impact of CVE-2024-3661 varies across operating systems based on their implementation of the DHCP client and the priority given to DHCP-pushed routes versus manually or programmatically set routes by VPN software. Research using Secably for vulnerability validation indicates that most desktop environments are susceptible by default.
| Operating System | Vulnerable | Notes |
|---|---|---|
| Windows | Yes | Standard DHCP client honors Option 121; routes override VPN interface. |
| macOS | Yes | Routes injected via DHCP take precedence over virtual interfaces. |
| Linux | Yes | Depends on NetworkManager/dhcpcd configuration; most defaults are vulnerable. |
| iOS | Yes | Exhibits similar behavior to macOS; limited user control over routing. |
| Android | No | Android's implementation of DHCP does not support Option 121 by design. |
Exploitation Scenario: Side-Channel Traffic Analysis
The attack is particularly effective because it does not drop the user's connection, making it invisible to the average user. Once the traffic is diverted to the attacker's gateway, the attacker can perform Man-in-the-Middle (MitM) attacks. Even if the traffic is encrypted via TLS, the attacker gains access to critical metadata: destination IP addresses, DNS queries (if not using encrypted DNS), and traffic patterns. Organizations can use Zondex to identify exposed internal services that might be inadvertently reached by "decloaked" clients who believe they are operating within a secure perimeter.
Furthermore, because the VPN tunnel itself remains "up," the VPN client often reports a secure status. The attacker can choose to forward the traffic to its original destination after logging it, ensuring the victim remains unaware of the redirection. This is a significant departure from traditional "VPN leaking" where a tunnel might crash; here, the tunnel is functional but the routing table is manipulated at a layer beneath the VPN's control.
Technical Deep Dive: Routing Table Manipulation
Consider a standard Linux environment where a VPN is active using OpenVPN or WireGuard. The routing table typically looks like this:
default via 10.8.0.1 dev tun0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
When the DHCP server pushes Option 121 with 1.0.0.0/1 and 128.0.0.0/1, the table is modified to:
default via 10.8.0.1 dev tun0 1.0.0.0/1 via 192.168.1.1 dev eth0 128.0.0.0/1 via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
When the CPU performs a lookup for an IP like 8.8.8.8, it compares the binary prefix. 8.8.8.8 matches both 0.0.0.0/0 and 1.0.0.0/1. Since /1 is a longer match than /0, the packet is egressed via eth0 to 192.168.1.1. The VPN interface tun0 is never reached for this packet. The only traffic that might still go through the VPN is traffic specifically addressed to the VPN's internal subnet or if the VPN client uses even more specific routes (e.g., /32 routes for every possible IP, which is computationally expensive and impractical).
Mitigation Challenges and Firewall Limitations
Mitigating CVE-2024-3661 is non-trivial because it targets the underlying network configuration protocol. Standard "Kill Switches" often fail here. A kill switch typically functions by allowing only two types of outbound traffic:
- Traffic to the VPN server's IP address.
- Traffic through the VPN's virtual interface.
To effectively block TunnelVision, administrators must implement stricter firewalling that binds traffic to the specific interface or use Network Namespaces (on Linux) to isolate the VPN traffic completely from the physical interface's routing table. Another approach is to disable DHCP Option 121 processing in the OS. On Linux, this can be done via /etc/dhcp/dhclient.conf by omitting classless-static-routes from the request statement. On Windows and macOS, however, there is currently no simple toggle to ignore Option 121 while still using DHCP for IP assignment.
DHCP Snooping and Layer 2 Security
On managed enterprise networks, DHCP Snooping can prevent this attack by ensuring that only trusted ports can issue DHCP ACK packets. This limits the attack surface to the legitimate DHCP server itself. If an attacker gains control over the legitimate DHCP server, they can still deploy TunnelVision across the entire subnet. In such cases, monitoring for unusual Option 121 attributes becomes critical. Modern EDR and NDR solutions should be configured to flag the presence of /1 routes in routing tables, as these are rarely used in legitimate network configurations and are a strong indicator of a TunnelVision exploit attempt.