Headline
CVE-2022-29179: Release 1.9.16 · cilium/cilium
Cilium is open source software for providing and securing network connectivity and loadbalancing between application workloads. Prior to versions 1.9.16, 1.10.11, and 1.11.15, if an attacker is able to perform a container escape of a container running as root on a host where Cilium is installed, the attacker can escalate privileges to cluster admin by using Cilium’s Kubernetes service account. The problem has been fixed and the patch is available in versions 1.9.16, 1.10.11, and 1.11.5. There are no known workarounds available.
We are pleased to release Cilium v1.9.16.
The following security issues have been identified and resolved by the community. These vulnerabilities first require an adversary to gain node-level access to nodes where Cilium is running, for instance gaining root access to the nodes, or gaining access to a user associated with group 1000. See the individual security advisories below for more details:
- CVE-2022-29179 (CVSS score: High, 7.5, CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H)
- CVE-2022-29178 (CVSS score:Moderate, 4.2, CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L)
Users are recommended to update following the upgrade guide to ensure that the Cilium ClusterRoles are correctly upgraded.
Summary of Changes
Minor Changes:
- metrics: Add go_* metrics (Backport PR #19634, Upstream PR #19153, @chancez)
CI Changes:
- jenkinsfiles: Increase VM boot timeout (Backport PR #19583, Upstream PR #19458, @pchaigno)
Misc Changes:
- build(deps): bump docker/login-action from 1.14.1 to 2 (#19741, @dependabot[bot])
- build(deps): bump docker/setup-buildx-action from 1.6.0 to 1.7.0 (#19621, @dependabot[bot])
- build(deps): bump docker/setup-buildx-action from 1.7.0 to 2 (#19740, @dependabot[bot])
- docs: fix version warning URL to point to docs.cilium.io (Backport PR #19583, Upstream PR #19563, @aanm)
- docs: set the right url for API version check (Backport PR #19680, Upstream PR #19610, @aanm)
- docs: Update max MTU value for Nodeport XDP on AWS (Backport PR #19680, Upstream PR #19593, @qmonnet)
- images/cilium: remove cilium group from Dockerfile (Backport PR #19733, Upstream PR #19711, @aanm)
- LRP minor improvements (Backport PR #19583, Upstream PR #19489, @aditighag)
- pkg/k8s: use subresource “nodes/status” to update node annotations (Backport PR #19675, Upstream PR #19590, @aanm)
- Trimmed down Cilium’s Cluster Roles to only the necessary rules (Backport PR #19675, Upstream PR #19074, @aanm)
Other Changes:
- install: Update image digests for v1.9.15 (#19474, @joestringer)
- Prepare for release v1.9.16 (#19754, @aanm)
Docker Manifests****cilium
docker.io/cilium/cilium:v1.9.16@sha256:984fe4256c6a88595c4661ec04a76c51c189a7f50c676f5dbbc0383b82104d78
quay.io/cilium/cilium:v1.9.16@sha256:984fe4256c6a88595c4661ec04a76c51c189a7f50c676f5dbbc0383b82104d78
clustermesh-apiserver
docker.io/cilium/clustermesh-apiserver:v1.9.16@sha256:c66958e4785f609892fa0bd08d1102e816e60c5bcf266de14a1533a8726e0188
quay.io/cilium/clustermesh-apiserver:v1.9.16@sha256:c66958e4785f609892fa0bd08d1102e816e60c5bcf266de14a1533a8726e0188
docker-plugin
docker.io/cilium/docker-plugin:v1.9.16@sha256:b4d4e191cdc58c53f5ffcd75b79376cc71d986e616605bb5f6caee510f105429
quay.io/cilium/docker-plugin:v1.9.16@sha256:b4d4e191cdc58c53f5ffcd75b79376cc71d986e616605bb5f6caee510f105429
hubble-relay
docker.io/cilium/hubble-relay:v1.9.16@sha256:1f1fc947bb0315c9d2b38c11a4e8c9158d6d800c81aef7cfd025ce05e63b6958
quay.io/cilium/hubble-relay:v1.9.16@sha256:1f1fc947bb0315c9d2b38c11a4e8c9158d6d800c81aef7cfd025ce05e63b6958
operator-aws
docker.io/cilium/operator-aws:v1.9.16@sha256:37b34b522e6008626a403724faae0fa05db5551d8b6b76f16084697d7fa94800
quay.io/cilium/operator-aws:v1.9.16@sha256:37b34b522e6008626a403724faae0fa05db5551d8b6b76f16084697d7fa94800
operator-azure
docker.io/cilium/operator-azure:v1.9.16@sha256:e883d83314435e7c9ec7c1815746d63505b28eb97f4eb3f8c87177ef7e62bb18
quay.io/cilium/operator-azure:v1.9.16@sha256:e883d83314435e7c9ec7c1815746d63505b28eb97f4eb3f8c87177ef7e62bb18
operator-generic
docker.io/cilium/operator-generic:v1.9.16@sha256:0cd8f0e7de19c873e7c5af02fbfa9f21b50ff4078f4c76dfa439c9a3c249738c
quay.io/cilium/operator-generic:v1.9.16@sha256:0cd8f0e7de19c873e7c5af02fbfa9f21b50ff4078f4c76dfa439c9a3c249738c
operator
docker.io/cilium/operator:v1.9.16@sha256:d1fa15e86dd8b2e06d1c918f21a8876b771090bbe11030c1ce15646fffce28f6
quay.io/cilium/operator:v1.9.16@sha256:d1fa15e86dd8b2e06d1c918f21a8876b771090bbe11030c1ce15646fffce28f6
Related news
Dell VxRail, version(s) 8.0.100 and earlier contain a denial-of-service vulnerability in the upgrade functionality. A remote unauthenticated attacker could potentially exploit this vulnerability, leading to degraded performance and system malfunction.
### Impact If an attacker is able to perform a container escape of a container running as root on a host where Cilium is installed, the attacker can leverage Cilium's Kubernetes service account to gain access to cluster privileges that are more permissive than what is minimally required to operate Cilium. In affected releases, this service account had access to modify and delete `Pod` and `Node` resources. ### Patches The problem has been fixed and is available on versions >=1.9.16, >=1.10.11, >=1.11.5 ### Workarounds There are no workarounds available. ### Acknowledgements The Cilium community has worked together with members of Isovalent, Amazon and Palo Alto Networks to prepare these mitigations. Special thanks to Micah Hausler, Robert Clark, Yuval Avrahami, and Shaul Ben Hai for their cooperation. ### For more information If you have any questions or comments about this advisory: Email us at [[email protected]](mailto:[email protected])
### Impact Users with host file system access on a node and the privileges to run as group ID 1000 can gain access to the per node API of Cilium via Unix domain socket on the host where Cilium is running. If a malicious user is able to gain unprivileged access to a user corresponding to this group, then they can leverage this access to compromise the integrity as well as system availability on that host. Operating Systems that have unprivileged users **not** belonging the group ID 1000 are **not** affected by this vulnerability. Best practices for managing the secure deployment of Kubernetes clusters will typically limit the ability for a malicious user to deploy pods with access to this group or to access the host filesystem, and limit user access to the nodes for users belonging to this group. These best practices include (but are not limited to) enforcing Admission Control policies to limit the configuration of Kubernetes Pod [hostPath](https://kubernetes.io/docs/concepts/storage/...