Impact
A policy rule denying a prefix that is broader than /32 may be ignored if there is
- A policy rule referencing a more narrow prefix (CIDRSet or toFQDN) and - This narrower policy rule specifies either enableDefaultDeny: false or - toEntities: all
Note that a rule specifying toEntities: world or toEntities: 0.0.0.0/0 is insufficient, it must be to entity all.
As an example, given the below policies, traffic is allowed to 1.1.1.2, when it should be denied:
apiVersion: cilium.io/v2 kind: CiliumClusterwideNetworkPolicy metadata: name: block-scary-range spec: endpointSelector: {} egressDeny: - toCIDRSet: - cidr: 1.0.0.0/8
---
apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy metadata: name: evade-deny spec: endpointSelector: {} egress: - toCIDR: - 1.1.1.2/32 - toEntities: - all
Patches
This issue affects:
- Cilium v1.14 between v1.14.0 and v1.14.15 inclusive - Cilium v1.15 between v1.15.0 and v1.15.9 inclusive
This issue has been patched in:
- Cilium v1.14.16 - Cilium v1.15.10
Workarounds
Users with policies using enableDefaultDeny: false can work around this issue by removing this configuration option and explicitly defining any allow rules required.
No workaround is available to users with egress policies that explicitly specify toEntities: all.
Acknowledgements
The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @squeed, @christarazi, and @jrajahalme for their work in triaging and resolving this issue.
For more information
If you have any questions or comments about this advisory, please reach out on Slack.
If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated with top priority.
Impact
The output of cilium-bugtool can contain sensitive data when the tool is run (with the --envoy-dump flag set) against Cilium deployments with the Envoy proxy enabled.
Users of the following features are affected:
- TLS inspection - Ingress with TLS termination - Gateway API with TLS termination - Kafka network policies with API key filtering
The sensitive data includes:
- The CA certificate, certificate chain, and private key used by Cilium HTTP Network Policies, and when using Ingress/Gateway API - The API keys used in Kafka-related network policy
cilium-bugtool is a debugging tool that is typically invoked manually and does not run during the normal operation of a Cilium cluster.
Patches
This issue affects:
- Cilium v1.13 between v1.13.0 and v1.13.16 inclusive - Cilium v1.14 between v1.14.0 and v1.14.11 inclusive - Cilium v1.15 between v1.15.0 and v1.15.5 inclusive
This issue has been patched in:
- Cilium v1.15.6 - Cilium v1.14.12 - Cilium v1.13.17
Workarounds
There is no workaround to this issue.
Acknowledgements
The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @sayboras for their work on triaging and remediating this issue.
For more information
If you have any questions or comments about this advisory, please reach out on Slack.
If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority.
Impact
In Cilium clusters with WireGuard enabled and traffic matching Layer 7 policies:
- Traffic that should be WireGuard-encrypted is sent unencrypted between a node's Envoy proxy and pods on other nodes. - Traffic that should be WireGuard-encrypted is sent unencrypted between a node's DNS proxy and pods on other nodes.
Patches
This issue affects:
In native routing mode (routingMode=native): Cilium v1.14 versions before v1.14.8 Cilium v1.15 versions before v1.15.2 In tunneling mode (routingMode=tunnel): Cilium v1.14 versions before v1.14.4 Cilium v1.14.4 if encryption.wireguard.encapsulate is set to false (default).
This issue has been resolved in:
In native routing mode (routingMode=native): Cilium v1.14.8 Cilium v1.15.2 In tunneling mode (routingMode=tunnel): Cilium v1.14.4. NOTE encryption.wireguard.encapsulate must be set to true. Workarounds
There is no workaround to this issue.
Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @brb, @giorio94, @gandro and @jschwinger233 for their work on triaging and remediating this issue.
For more information If you have any questions or comments about this advisory, please reach out on Slack.
If you think you found a related vulnerability, we strongly encourage you to report security vulnerabilities to our private security mailing list at security@cilium.io. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and your report will be treated as top priority.
Impact
In Cilium clusters with IPsec enabled and traffic matching Layer 7 policies:
- Traffic that should be IPsec-encrypted between a node's Envoy proxy and pods on other nodes is sent unencrypted - Traffic that should be IPsec-encrypted between a node's DNS proxy and pods on other nodes is sent unencrypted
Note: For clusters running in native routing mode, IPsec encryption is not applied to connections which are selected by a L7 Egress Network Policy or a DNS Policy. This is a known limitation of Cilium's IPsec encryption which will continue to apply after upgrading to the latest Cilium versions described below.
Patches
This issue affects:
- Cilium v1.15 before v1.15.2 - Cilium v1.14 before v1.14.8 - Cilium v1.13 before v1.13.13 - Cilium v1.4 to v1.12 inclusive
This issue has been resolved in:
- Cilium v1.15.2 - Cilium v1.14.8 - Cilium v1.13.13
Workarounds There is no workaround to this issue.
Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @jschwinger233, @julianwiedmann, @giorio94, and @jrajahalme for their work in triaging and resolving this issue.
For more information If you have any questions or comments about this advisory, please reach out on Slack.
If you think you have found a vulnerability in Cilium, we strongly encourage you to report it to our private security mailing list at security@cilium.io. This is a private mailing list that only members of the Cilium internal security team are subscribed to, and your report will be treated as top priority.
Impact
Cilium's HTTP policies are not consistently applied to all traffic in the scope of the policies, leading to HTTP traffic being incorrectly and intermittently forwarded when it should be dropped.
Patches
This issue affects:
Cilium v1.13 between v1.13.9 and v1.13.12 inclusive Cilium v1.14 between v1.14.0 and v1.14.7 inclusive Cilium v1.15.0 and v1.15.1
This issue has been patched in:
Cilium v1.15.2 Cilium v1.14.8 Cilium v1.13.13
Workarounds
There is no workaround for this issue – affected users are strongly encouraged to upgrade.
Acknowledgements
The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @romikps for discovering and reporting this issue, and @sayboras and @jrajahalme for preparing the fix.
For more information
If you have any questions or comments about this advisory, please reach out on Slack.
If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium internal security team, and your report will be treated as top priority.
Impact
In Cilium clusters where Cilium's Layer 7 proxy has been disabled, creating workloads with
- policy.cilium.io/proxy-visibility annotations (in Cilium >= v1.13) - io.cilium.proxy-visibility annotations (in Cilium <= v1.12)
causes the Cilium agent to segfault on the node to which the workload is assigned.
Existing traffic on the affected node will continue to flow, but the Cilium agent on the node will not able to process changes to workloads running on the node. This will also prevent workloads from being able to start on the affected node. The denial of service will be limited to the node on which the workload is scheduled, however an attacker may be able to schedule workloads on the node of their choosing, which could lead to targeted attacks.
Patches
Pull request with fix
This issue affects:
Cilium <= v1.14.1 Cilium <= v1.13.6 Cilium <= v1.12.13
This issue has been resolved in:
Cilium v1.14.2 Cilium v1.13.7 Cilium v1.12.14
Workarounds
Users can avoid this denial of service attack by enabling the Layer 7 proxy.
For more information If you have any questions or comments about this advisory, please reach out on Slack.
As usual, if you think you found a related vulnerability, we strongly encourage you to report security vulnerabilities to our private security mailing list: security@cilium.io - first, before disclosing them in any public forums. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and is treated as top priority.
Impact
An attacker with the ability to create or modify CiliumNetworkPolicy objects in a particular namespace is able to affect traffic on an entire Cilium cluster, potentially bypassing policy enforcement in other namespaces.
By using a crafted endpointSelector that uses the DoesNotExist operator on the reserved:init label, the attacker can create policies that bypass namespace restrictions and affect the entire Cilium cluster. This includes potentially allowing or denying all traffic.
This attack requires API server access, as described in the Kubernetes API Server Attacker section of the Cilium Threat Model.
Patches
This issue was patched in https://github.com/cilium/cilium/pull/28007
This issue affects:
- Cilium <= v1.14.1 - Cilium <= v1.13.6 - Cilium <= v1.12.13
This issue has been resolved in:
- Cilium v1.14.2 - Cilium v1.13.7 - Cilium v1.12.14
Workarounds
An admission webhook can be used to prevent the use of endpointSelectors that use the DoesNotExist operator on the reserved:init label in CiliumNetworkPolicies.
Acknowledgements The Cilium community has worked together with members of Palantir and Isovalent to prepare these mitigations. Special thanks to @odinuge for reporting this issue and @joestringer for the fix.
For more information If you have any questions or comments about this advisory, please reach out on Slack.
If you think you have found a vulnerability in Cilium, we strongly encourage you to report it to our private security mailing list at security@cilium.io first, before disclosing it in any public forum. This is a private mailing list for Cilium's internal security team, and your report will be treated as top priority.
Impact
An attacker with the ability to update pod labels can cause Cilium to apply incorrect network policies.
This issue arises due to the fact that on pod update, Cilium incorrectly uses user-provided pod labels to select the policies which apply to the workload in question.
This can affect:
Cilium network policies that use the namespace, service account or cluster constructs to restrict traffic Cilium clusterwide network policies that use Cilium namespace labels to select the Pod Kubernetes network policies
Non-existent construct names can be provided, which bypass all network policies applicable to the construct. For example, providing a pod with a non-existent namespace as the value of the io.kubernetes.pod.namespace label results in none of the namespaced CiliumNetworkPolicies applying to the pod in question.
This attack requires the attacker to have Kubernetes API Server access, as described in the Cilium Threat Model.
Patches
This issue affects:
- Cilium <= v1.14.1 - Cilium <= v1.13.6 - Cilium <= v1.12.13
This issue has been resolved in:
- Cilium v1.14.2 - Cilium v1.13.7 - Cilium v1.12.14
Workarounds
An admission webhook can be used to prevent pod label updates to the k8s:io.kubernetes.pod.namespace and io.cilium.k8s.policy. keys.
Acknowledgements The Cilium community has worked together with members of Palantir and Isovalent to prepare these mitigations. Special thanks to @odinuge for reporting this issue and to @nebril for the fix.
For more information If you have any questions or comments about this advisory, please reach out on Slack.
If you think you have found a vulnerability in Cilium, we strongly encourage you to report it to our private security mailing list – security@cilium.io – first, before disclosing them in any public forums. This is a private mailing list where only members of the Cilium internal security team are subscribed to, and is treated as top priority.