The recent compromise of the XZ compression library underscores the dangers present within modern software supply chains. This incident emphasizes why vigilance and robust security measures are necessities, particularly when utilizing open-source projects. The incident is a first of its kind and will have ripple effects throughout the community. We will need to look at what changes to the current maintainer accreditation, and acceptance practices will prevent the issue in the future. Despite the initial breakdown, this incident highlights the power of open source. The rapid detection of this attack underscores the transparency and collaborative nature of open-source models. Such threats often go undetected or unaddressed for far longer within closed ecosystems.
Attack Breakdown
- Social engineering success: Attackers successfully pressured the project maintainer through a series of well-crafted emails, ultimately gaining commit access to the XZ code repository. This highlights the effectiveness of social manipulation even in security-conscious environments.
- Malicious backdoor: The attackers subtly inserted a backdoor within the library’s test code. A brief code analysis reveals its intent to provide remote command execution capabilities.
The Wider Impact: CVE-2024-3094 and Kubernetes
The discovery of the SSH vulnerability (CVE-2024-3094) further illustrates the risks of compromised upstream dependencies. Kubernetes environments pose specific concerns:
- Node compromise: Nodes utilizing vulnerable OS versions with the compromised XZ library could be directly targeted.
- Cascading risk to containers: Container images built upon these OS versions inherit the vulnerability, perpetuating the impact.
Kyverno to the Rescue
Suppose you are a Nirmata customer running Nirmata Policy Manager or Kyverno in production. In that case, the following policy can give you a better view of this new vulnerability’s impact.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: check-image-vulns-cve-2024-3094
annotations:
policies.kyverno.io/title: Verify Image Check CVE-2024-3094
policies.kyverno.io/category: Software Supply Chain Security
policies.kyverno.io/severity: medium
policies.kyverno.io/subject: Pod
policies.kyverno.io/description: >-
CVE-CVE-2024-3094 is a critical vulnerability in the XZ library. Detecting
the affected package may be done in an SBOM by identifying the "liblzma & xz-utils" package
with one of the affected versions. This policy checks attested SBOMs in an image in CycloneDX format.
specified under `imageReferences` and denies it if it contains versions 5.6-5.6.1 of the
packages. Using this for your purposes will require customizing the `imageReferences`,
`subject` and `issuer` fields are based on your image signatures and attestations.
spec:
validationFailureAction: audit
webhookTimeoutSeconds: 10
rules:
- name: cve-2024-3094
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "*"
attestations:
- type: https://cyclonedx.org/schema
attestors:
- entries:
- keyless:
subject: "mysubject"
issuer: "myissuer"
rekor:
url: https://rekor.sigstore.dev
conditions:
- all:
- key: "{{ components[?name=='liblzma'].version || 'none' }}"
operator: AllNotIn
value: ["5.6.0","5.6.1"]
- key: "{{ components[?name=='xz-utils'].version || 'none' }}"
operator: AllNotIn
value: ["5.6.0","5.6.1"]
This policy utilizes the Software Bill of Materials (SBOM), attached to the image as signed metadata, i.e., an attestation, and checks the contents of the image. This will allow us to ensure that you do not permit the execution of Pods using vulnerable library versions.
This approach leverages SBOMs as signed attestations for software supply chain security, a recommended best practice. However, attestations are typically unavailable for images directly used from public registries. Implementing this requires scanning, attesting all images, and checking that only trusted images are allowed. Contact us to learn how to implement a secure software pipeline.
Further, Nirmata advocates using a new principle called Shift-Down to ensure we keep our worker nodes from this attack before deployment. We can utilize the following policy inside our CI/CD pipeline to check for vulnerable images using NCTL.
apiVersion: json.kyverno.io/v1alpha1
kind: ValidatingPolicy
metadata:
name: check-dockerfile-cve-2022-3094
spec:
rules:
- name: check-cve-2022-3094
assert:
any:
- message: "xz-utils are being installed"
check:
~.(Stages[].Commands[].CmdLine[]):
(contains(@, 'xz-utils')): false
- message: "liblzma is being installed"
check:
~.(Stages[].Commands[].CmdLine[]):
(contains(@, 'liblzma')): false
Container image signing and verification plays a crucial role in ensuring the authenticity and integrity of the code within your cloud native environments. It works like a digital fingerprint, allowing you to verify that the image you’re deploying hasn’t been tampered with or modified. This explicitly blocks potential vulnerabilities by ensuring you never execute unknown code.
Benefits
- Increased security: Signing helps prevent attackers from injecting malicious code into your images, potentially compromising your entire system.
- Enhanced trust: Signing verifies the image’s origin and publisher, ensuring you’re deploying what you intended.
- Improved compliance: Some industries and regulations mandate signed images for security and audit purposes.
- Reduced risk: Identifying and mitigating vulnerabilities becomes easier when you know precisely what code you’re running.
Mechanisms
- Signing key pair: You obtain a signing key pair with a private key (kept secret) and a public key (distributed).
- Signing the image: The private key is used to sign the container image cryptographically, creating a signature.
- Verifying the signature: The public key and signature confirm that the image hasn’t been altered on deployment.
Popular Tools
- Cosign: An open-source tool based on the Sigstore standard, supporting keyless signing and various signing authorities.
- Notary: An integrated solution from Docker for signing and verifying images within their ecosystem.
- AWS Signer: A managed service from AWS for signing images stored in their Elastic Container Registry (ECR).
- Venafi CodeSign Protect: A managed X.509 and HSM service with enterprise-grade signing and verification.
Key Takeaways
For long-term security, defense in depth is paramount. Each security measure needs constant revision. Advanced, persistent attackers will find ways to circumvent controls. Multi-layered security – from developer awareness to automated scanning tools – remains essential. Tools ensuring reliable tracking of software origins would make detecting malicious build elements easier, fostering supply chain integrity. Use Nirmata Policy Manager and Kyverno together to offer robust image security integrations, providing you with the ability to:
- Implement image signing and verification: This ensures the authenticity and integrity of your container images, preventing vulnerabilities. Consider combining Nirmata Policy Manager with tools like Cosign, Notary, AWS Signer, or Venafi CodeSign Protect.
- Prioritize image trust and attestations: Only pull images from trusted sources and registries. Avoid untrusted images to minimize the attack surface. Attaching signed metadata, i.e., attestations like SBOMs and scan reports, helps quickly identify and address issues.
- Maintain comprehensive patching: Patch not just Kubernetes but also low-level components like runc. A chain is only as strong as its weakest link.
- Use Nirmata Policy Manager: Leverage these tools to enforce security policies and automate vulnerability detection and mitigation.
Visit the Nirmata website to learn more about Nirmata Policy Manager, Nirmata Enterprise for Kyverno, and Kyverno OSS.
Sorry, the comment form is closed at this time.