CVE-2020-11091 in Weave Net
Summary
by MITRE
In Weave Net before version 2.6.3, an attacker able to run a process as root in a container is able to respond to DNS requests from the host and thereby insert themselves as a fake service. In a cluster with an IPv4 internal network, if IPv6 is not totally disabled on the host (via ipv6.disable=1 on the kernel cmdline), it will be either unconfigured or configured on some interfaces, but it's pretty likely that ipv6 forwarding is disabled, ie /proc/sys/net/ipv6/conf//forwarding == 0. Also by default, /proc/sys/net/ipv6/conf//accept_ra == 1. The combination of these 2 sysctls means that the host accepts router advertisements and configure the IPv6 stack using them. By sending rogue router advertisements, an attacker can reconfigure the host to redirect part or all of the IPv6 traffic of the host to the attacker controlled container. Even if there was no IPv6 traffic before, if the DNS returns A (IPv4) and AAAA (IPv6) records, many HTTP libraries will try to connect via IPv6 first then fallback to IPv4, giving an opportunity to the attacker to respond. If by chance you also have on the host a vulnerability like last year's RCE in apt (CVE-2019-3462), you can now escalate to the host. Weave Net version 2.6.3 disables the accept_ra option on the veth devices that it creates.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2020
The vulnerability described in CVE-2020-11091 represents a sophisticated network-level attack vector targeting the Weave Net container networking solution. This security flaw exists in versions prior to 2.6.3 and exploits a fundamental misconfiguration in IPv6 network stack handling within containerized environments. The vulnerability specifically targets scenarios where an attacker can execute processes with root privileges inside a container, creating a privilege escalation pathway that extends beyond container boundaries into the host system. The attack leverages the complex interaction between IPv6 networking parameters and container network interfaces, demonstrating how seemingly innocuous network configuration settings can create significant security risks in modern container orchestration environments.
The technical exploitation mechanism relies on the combination of two critical IPv6 system parameters that are commonly enabled by default in Linux systems. When IPv6 is partially configured on a host system with ipv6.disable=1 not set, the system typically maintains IPv6 interfaces that are either unconfigured or improperly configured. The critical vulnerability emerges from the default setting of /proc/sys/net/ipv6/conf//accept_ra == 1, which allows the host to accept router advertisements from network devices. Combined with potentially disabled IPv6 forwarding, this creates a scenario where an attacker can send malicious router advertisements that reconfigure the host's IPv6 stack. This reconfiguration can redirect traffic intended for legitimate services to the attacker-controlled container, effectively creating a man-in-the-middle position that can intercept and manipulate network communications. The vulnerability particularly affects clusters using IPv4 internal networks where IPv6 is not completely disabled, making it a widespread concern in containerized environments.
The operational impact of this vulnerability extends far beyond simple network interception, representing a complete compromise of container isolation principles. When an attacker successfully manipulates DNS responses to include both A (IPv4) and AAAA (IPv6) records, modern HTTP libraries that attempt IPv6 connections first before falling back to IPv4 provide the attacker with a window of opportunity. This dual-stack approach means that even if the original traffic was intended for IPv4-only services, the attacker can intercept and redirect IPv6 traffic to their container. The vulnerability becomes particularly dangerous when combined with other host-level exploits, such as the apt RCE vulnerability CVE-2019-3462, which could enable full host compromise. This chaining of vulnerabilities demonstrates how container security flaws can create pathways to complete system compromise, undermining the fundamental security assumptions of container isolation. The attack requires minimal privileges within the container environment but can result in significant host-level compromise.
The fix implemented in Weave Net version 2.6.3 addresses this vulnerability by disabling the accept_ra option on the virtual ethernet devices (veth) that the networking solution creates. This change effectively prevents the malicious router advertisement attacks from successfully reconfiguring the host's IPv6 stack. The solution aligns with security best practices for container networking and follows the principle of least privilege by removing unnecessary network configuration capabilities from container interfaces. From a cybersecurity perspective, this vulnerability highlights the importance of proper network stack configuration in containerized environments and demonstrates how network-level security controls must be carefully considered in microservices architectures. The fix represents a defensive measure that reduces the attack surface by eliminating the specific vector that enabled the privilege escalation attack, while also emphasizing the need for comprehensive network security monitoring and proper IPv6 configuration management in container orchestration platforms. This vulnerability serves as a critical reminder that container security requires attention to both application-level and network-level configurations, as network misconfigurations can create persistent backdoors that persist across container restarts and deployments.