Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

Weave Net Pods can be used to escalate other Kubernetes vulnerabilities

Moderate
morancj published GHSA-pg3p-v8c6-c6h3 Jan 20, 2021

Package

No package listed

Affected versions

<=2.7.0

Patched versions

2.8.0

Description

Description

Weave Net is supplied with a manifest that runs pods on every node in a Kubernetes cluster, which are responsible for managing network connections for all other pods in the cluster. This requires a lot of power over the host, and the manifest sets privileged: true, which gives it that power. It also set hostPID: true, which gave it the ability to access all other processes on the host and write anywhere in the root filesystem of the host, and mounted some host volumes which indirectly gave it the same access.

Impact

For vulnerable installs, the attacker can take over any host in the cluster.

Am I vulnerable?

Only if you have an additional vulnerability (e.g. a bug in Kubernetes) or misconfiguration that allows an attacker to run code inside the Weave Net pod,
No such bug is known at the time of release, and there are no known instances of this being exploited.

Patches

Weave Net 2.8.0 removes the hostPID setting and moves CNI plugin install to an init container.

Even after removing the hostPID setting, the container still had the ability to write over the CNI plugin, which is executed as root with full access to the host by the runtime (e.g. Dockershim, CRI-O, ContainerD) every time a pod is added or deleted. The volume mounts which gave that access have been moved to an init container to mitigate the risk - now, getting inside the init container requires that an attacker have the ability to delete pods or reboot the machine.

Note that an attacker inside the Weave Net pod can still be highly disruptive - breaking network communications, etc. - so it is essential to have access controls (e.g. the RBAC rules supplied in this repo) and other measures to prevent attackers from getting inside.

Workarounds

Users who do not update to 2.8.0 can edit the hostPID line in their existing DaemonSet manifest to say false instead of true,
arrange some other way to install CNI plugins (e.g. Ansible) and remove those mounts from the DaemonSet manifest.

References

For more information on init containers visit the Kubernetes documentation

Credit

We would like to thank "Mobydick" for reporting the Host PID issue.

For more information

If you have any questions or comments about this advisory:

Severity

Moderate

CVE ID

CVE-2020-26278

Weaknesses

No CWEs