Supply Chain Shock: Backdoor in liblzma Highlights Third-Party Package Risks

The open-source software (OSS) ecosystem thrives on the principles of transparency and collaborative development. However, a recent critical vulnerability discovered in the core library, liblzma, has cast a shadow on this trust. The vulnerability, which was disguised as a bug fix, contained malicious code that could have potentially granted attackers access to users’ systems through SSH servers. This unsettling incident serves as a sobering reminder of the tangible risks inherent in relying on third-party software packages, even within the seemingly open and collaborative realm of OSS.

What happened?

liblzma, a critical library used for compression in many Linux distributions, was compromised by a backdoor hidden within its source code. This backdoor, attributed to a contributor named Jia T75, remained undetected for two years. During the build process, the backdoor would infect the system, specifically targeting x86_64 Linux systems. This vulnerability could have allowed attackers to compromise SSH servers, potentially granting them unauthorized access to a user’s system.

Why third-party packages are a risk

While OSS thrives on collaboration, it also introduces vulnerabilities. We rely on the good faith of developers contributing code. Malicious actors can exploit this trust by injecting backdoors or other harmful code into seemingly legitimate libraries like liblzma.

What can you Do?

To mitigate the risks associated with third-party software packages, it is imperative to stay vigilant and proactive. Patching software promptly by updating your system regularly ensures you have the latest security fixes in place. Furthermore, exercising caution when obtaining software updates and packages by exclusively utilizing official or trusted sources is of utmost importance. Thoroughly researching the maintainers of the software packages you rely upon can shed light on their track record of responsible updates and reputation within the community. Whenever feasible, exploring alternatives to widely used libraries can be a prudent strategy, as diversifying your software portfolio can reduce the potential impact of a single vulnerability. By adopting these measures, you can bolster the security posture of your systems and minimize the risks posed by third-party software dependencies.

How Meterian can help

The liblzma backdoor incident serves as a wake-up call, and it highlights the need for constant vigilance. By understanding the risks and taking preventative measures, we can build a more secure software ecosystem. Remember, security is an ongoing process, not a one-time fix .

Security solutions like Meterian can be powerful allies in mitigating the risks of third-party packages. Meterian’s notification system keeps you informed about the latest vulnerabilities impacting your software ecosystem, including critical flaws like the recently discovered liblzma backdoor. Through timely alerts and detailed reporting, Meterian ensures you stay on top of potential threats before they can be exploited]. Additionally, Meterian’s Software Composition Analysis (SCA) solution goes a step further by scanning your codebase for known vulnerabilities within dependencies like liblzma. By proactively identifying these risks, SCA allows you to take early action and prioritize patching vulnerable components, ultimately safeguarding your systems and data.

Don’t wait for the next major vulnerability to compromise your systems. Take control of your software security today. Try Meterian for free and experience the power of proactive vulnerability detection and management.

An important note!

The xz/liblzma packages are sometimes included in major Linux distributions, and much of the focus is now there, also because this vulnerability can be exploited to execute remote commands over SSH. However, please be aware that this vulnerability may affect also your application code, either because it may be linking directly liblzma in your C/C++ applications or because, via conan, you previously used the package xz_utils in one of the vulnerable versions (5.6.0, 5.6.1). Furthermore, other wrappers such as xz.ex (elixir), xz.net (dotnet), ruby-xz (ruby) and similar packages may indirectly pull the affected package.

Update – 15 April 2024

This is a novel situation, and there is still much uncertainty. We are aware of only a single known exploit path at this time, but there may be additional scenarios that have not yet been identified.

In detail, so far, it looks like the payload activates if the running program has the process name /usr/sbin/sshd, however, based on ongoing analysis, it may activate also in other scenarios too, unrelated to SSH. This matter is still investigated, you can keep an eye at this page to follow the active investigation.


References

  1. Backdoor in the xz source code: https://www.openwall.com/lists/oss-security/2024/03/29/4
  2. Backdoor in upstream xz/liblzma leading to SSH server compromise: https://news.ycombinator.com/item?id=39868673
  3. NVD reference: https://nvd.nist.gov/vuln/detail/CVE-2024-3094
  4. A live analysis of the backdoor: https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
  5. Ongoing investigation: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Supply Chain Shock: Backdoor in liblzma Highlights Third-Party Package Risks

Understanding SBOMs: A Crucial Aspect of the EU Cyber Resilience Act (CRA)

The EU Cyber Resilience Act

The European Union Cyber Resilience Act (CRA), which was proposed on September 15, 2022, is the first EU-wide legislation addressing cybersecurity requirements for software and hardware manufacturers. Unlike the U.S. Executive Order, the CRA extends to all vendors who create products with digital components that connect to the internet. It will become enforceable in early 2027, three years after its ratification.

SBOM Requirements of the CRA

One of its key requirements focuses on Software Bill of Materials (SBOMs). An SBOM is essentially a comprehensive inventory of all software components used in a product. It provides transparency by listing out the dependencies, libraries, and third-party code that make up a software application. Think of it as a “recipe” for your software – it tells you exactly what ingredients (components) are included.

The key points related to Software Bill of Materials (SBOM) requirements under the EU Cyber Resilience Act are:

  • Manufacturers must identify and document product components and vulnerabilities, including the creation of a SBOM of at least the top-level dependencies of the product
  • The SBOM does not have to be made publicly available
  • The SBOM should be included in the technical documentation and, upon request, provided to market surveillance authorities

The EU Cyber Resilience Act mandates SBOM adoption to enhance cybersecurity and ensure transparency in software and hardware supply chains. Manufacturers need to create SBOMs for their products, while public availability is not required.

Why SBOMs are essential

SBOMs are a sensible tool to manage your supply chain transparency. With the increasing complexity of software supply chains, understanding what goes into your product is crucial. SBOMs allow manufacturers to trace the origins of each component, identify vulnerabilities, and assess risks.

By having an SBOM, organisations can proactively address security vulnerabilities. When a known vulnerability is discovered in a library or component, manufacturers can quickly assess which products are affected and take necessary remediation steps.

They are also required for compliance and legal requirements. Specifically, the CRA mandates that manufacturers create SBOMs for their products. Compliance ensures that products meet cybersecurity standards and reduces legal risks.

Why SBOMs are complicated

Creating and maintaining Software Bill of Materials (SBOMs) is a time-consuming process due to the intricate nature of modern software. Applications are no longer simple; they consist of interconnected components, libraries, and dependencies. The prevalence of open-source software further complicates matters. Each component introduces its own set of dependencies, licences, and potential vulnerabilities. Identifying and tracking all these elements manually is a daunting task. Ensuring accuracy, compliance, and security within this complex landscape inevitably consumes significant time and effort.

That’s the reason why it’s a good idea to adopt an automated solution that takes this problem away.

Meterian: your automated SBOM solution

Using automated analysis, Meterian continuously scans your codebase, identifies the whole network of dependencies, and generates an SBOM automatically. No manual effort required, as SBOMS can be created and stored during the analysis, or later on demand. This will save a substantial amount of time to your developers, who can say goodbye to weeks of research at each release. Everything happens directly on your pipelines or at the touch of a button.

With the help of his powerful vulnerability scanner, Meterian provides you all relevant vulnerability Insights. The Meterian vulnerability database tracks more than 340k vulnerabilities across more than 20 different OSINT sources. You will also automatically receive real-time alerts about vulnerabilities in your components, even if you do not actively analyse them: Meterian will do it for you.

Meterian is easy to integrate in your processes, as it seamlessly integrates with your development pipelines, ensuring continuous monitoring without any extra activity. A simple click, some lines of YAML, one or two lines of script, is all it takes. You get protection against vulnerabilities and compliance at the same time, without any extra effort.

Conclusion

As the EU Cyber Resilience Act comes into effect, manufacturers are required to embrace SBOMs to ensure transparency, enhance risk management, and achieve compliance. The Meterian platform simplifies the generation of SBOMs, enabling you to concentrate on developing secure and resilient software.

Remember: An SBOM isn’t just a regulatory requirement; it’s a powerful tool for safeguarding your digital products. Start creating your SBOMs today!

Understanding SBOMs: A Crucial Aspect of the EU Cyber Resilience Act (CRA)