CVE 2024-3094: A Container Guide
Felipe Costa
Senior Solutions Architect at Trend Micro | AWS Community Builder | Cloud Security Expert
Recently, a vulnerability was uncovered in the XZ tool, a component of the XZ utils suite. This vulnerability was discovered by the developer?Andres Freund?via an?open-source security mailing list?where he shared that he had discovered an upstream backdoor in the tool.
What is this "xz" tool?
XZ utils, previously known as LZMA Utils, is a set of open-source data compression tools and libraries designed to provide high compression ratios and fast decompression times. It is commonly used in various scenarios where efficient data compression and decompression are required such as?Software Packaging and Distribution, Archiving and Backup, Data Transmission?and many more use cases.
According to the Red Hat’s?advisory:
"...Red Hat Information Risk and Security and Red Hat Product Security learned that the latest versions of the “xz” tools and libraries?contain malicious code that appears to be intended to allow unauthorized access. Specifically, this code is present in versions 5.6.0 and 5.6.1 of the libraries. Fedora Linux 40 users may have received version 5.6.0, depending on the timing of system updates. Fedora Rawhide users may have received version 5.6.0 or 5.6.1. This vulnerability was assigned?CVE-2024-3094."
This vulnerability could potentially allow attackers to gain unauthorized access to the entire system remotely by interfering with authentication in sshd via systemd, and this is the reason why it is so critical to remediate as soon as possible in case you are affected.
Containers context
Containers rely heavily on isolation mechanisms to prevent one container from affecting others on the same host, If exploited, the CVE 2024-3094 could potentially breach this isolation, allowing an attacker to access sensitive data or manipulate other containers running on the same system.
The scale of deployment is also a major factor, since often orchestration frameworks, such as Kubernetes are used to make massive deployments, this results in a delay in detecting and responding to exploits such as the CVE 2024-3094, allowing attackers more time to carry out malicious activities.
This vulnerability represents a major concern for containers due to their inherent architectural characteristics and poses a significant risk due to the security and integrity of containerized applications and the underlying infrastructure.
Impact scope?
The good news is that the impact may be limited since the affected version is only found in newer versions of xz/liblzma, so it may not be as widely deployed in all Linux distributions. Some of the Linux distributions impacted are Red Hat, Debian, Arch, Kali, Ubuntu and Suse.
What needs to be done?
The first step is to verify if you are affected. If your containers use this affected library, you can use native tools such as docker-cli to extract the Software Bill of Materials (SBOM) and see if the vulnerable package is present, here's an example:
docker sbom debian:unstable-20240311 --output sbom.txt
cat sbom.txt | grep liblzma
In this example, the image is vulnerable so we're able to find the package, but this method will require a lot of commands to be run and will consume time, I've built a script that can help you identify if your image is affected more easily.
The script uses Trend Micro?Artifact Scanner (TMAS)?to perform an open-source vulnerability scanning of your images, and the tool uses Software Bill of Materials (SBOM) to perform the assessment. Once you execute the tool it returns a report of all vulnerable packages and with this information, we can know if your image has the affected library or not, you can find the details of the tool in GitHub. If you want to use the tool standalone, it can give a result similar to the example with the docker-cli extracting the Software Bill of Materials (SBOM):
The script that I've built makes it even easier: you can use the script against any image in any registry to get all the vulnerable libraries including the "xz" and it can simply tell you if you are affected or not by the CVE 2024-3094
If you have a lot of images to be scanned, a simple script executed manually won't be practical, in this case, you can run it in your pipeline so it can fail your pipeline to block images with the vulnerable package to be deployed to your environment, here's a very simple example using GitHub Actions that it can be used:
领英推荐
name: Scan Container Image
on:
workflow_dispatch:
env:
TMAS_API_KEY: ${{ secrets.TMAS_API_KEY }}
IMAGE_NAME: "ghcr.io/felipecosta09/cve-2024-3094"
jobs:
scan:
name: Scan Container Image
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Install TMAS
run: sudo curl -s -L https://gist.githubusercontent.com/felipecosta09/a3d0cf68f4e85fc53bd6d295c1bb2c5b/raw/fafd525ef1bccfe7a460ec29e5f6d8aca397448a/tmas_install.sh | bash
- name: Check for the CVE 2024-3094
run: |
echo ${{ env.IMAGE_NAME }} | bash cve2024-3094.sh
- name: Deploy to Prod?
run: echo "Deploying to Prod"
As a result, the pipeline should fail in case the vulnerable package is presented and continue in case not, you can use this process to apply at scale for all your images and make sure to not introduce any images to your production environment with this vulnerable package.
PS.: All this code is available at the GitHub repository and I've also added an image that contains that vulnerable package in case you want to run your tests.
If you are a Trend Micro Vision One customer, our Container Runtime Scanning provides visibility of operating system and open source code vulnerabilities that are part of containers running in clusters where you have Container Security installed, it can show if any running container in your environment is affected by this CVE.
How to remediate?
You must downgrade immediately to an older version (anything below 5.6.0) since this library is interconnected with other packages, there are some fixes already available like the example below where instead of downgrade you can upgrade to a newer version where the vulnerability has been fixed. Dependencies updates can sometimes include breaking changes that require modifications to the application's codebase.
In some cases rewriting of certain parts of the code might be needed to accommodate changes in the updated dependency - so make sure to test and update other packages accordingly. ?
For Trend Micro Vision One customers, a runtime rule is available for your Kubernetes clusters or Amazon ECS deployments, which can provide visibility into any activity of your running containers that violates a customizable set of rules.
If a pod violates any rule during runtime, the issue is mitigated by terminating or isolating the pod based on the runtime ruleset in the policy.
This situation is still evolving, and there are many unknowns. While we are currently aware of one potential exploit path, there may be others that we haven't discovered yet. Despite these uncertainties, it's important to remediate as soon as possible, even though we may not have all the information at this time.
In conclusion, this vulnerability uncovered in the XZ tool shows the importance of integrating security into every stage of the software development lifecycle. With the agility and automation inherent in DevOps practices, addressing vulnerabilities promptly becomes one of the most important measures for maintaining the integrity and security of software deployments.
?
Sources:
Experienced Product Marketer | Full Stack Marketing Leader | Content Strategist and Writer | Cybersecurity Buyer Advocate
11 个月Thanks Philipe. I told some engineers to check you out to learn how to talk about events like this and help us marketers out :).
Technologist | Cloud | Cybersecurity | Sales Leader
11 个月Great article Felipe Costa. Thanks for sharing.