Skip to content

Weave Net clusters susceptible to MitM attacks via IPv6 rogue router advertisements

Moderate severity GitHub Reviewed Published Jun 3, 2020 in weaveworks/weave • Updated Jan 9, 2023

Package

gomod github.com/weaveworks/weave (Go)

Affected versions

< 2.6.3

Patched versions

2.6.3

Description

Impact

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.

Patches

Weave Net version 2.6.3 (to be released soon) will disable the accept_ra option on the veth devices that it creates.

Workarounds

Users should not run containers with CAP_NET_RAW capability. This has been the advice from Weave Net for years.
https://www.weave.works/docs/net/latest/kubernetes/kube-addon/#-securing-the-setup

For more information

If you have any questions or comments about this advisory:

References

@morancj morancj published to weaveworks/weave Jun 3, 2020
Reviewed May 24, 2021
Published to the GitHub Advisory Database May 27, 2021
Last updated Jan 9, 2023

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
High
User interaction
None
Scope
Changed
Confidentiality
None
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:H/A:N

EPSS score

0.050%
(21st percentile)

Weaknesses

CVE ID

CVE-2020-11091

GHSA ID

GHSA-59qg-grp7-5r73

Source code

No known source code
Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.