In a reminder that open source products can carry significant risks beyond intellectual property, a vulnerability in a compression tool commonly used by developers has triggered widespread concerns.
XZ Utils (“XZ”) is an open source data compression utility, first published in 2009, and widely used in Linux and macOS systems. The tool is primarily used for data compression and decompression and may reside on routers and switches, VPN concentrators and firewalls. XZ is used on many smartphones, televisions and most web servers on the internet. Despite its wide adoption, as an open source tool, XZ was primarily maintained by one volunteer—who maintained the open source software for free.
When this volunteer ran into some personal matters, he turned over the maintenance responsibilities to JiaT75, known as Jia Tan (or what many now believe was a group of hackers working under this alias). In February 2024, Jia Tan updated XZ for versions 5.6.0 and 5.6.1, which included malicious code. This malicious code could be used to create a backdoor on infected devices, including the potential for stealing encryption keys or installing malware. Jia Tan took several steps to obfuscate the addition of malicious code. For example, the malicious code was not included in the public GitHub repository but instead included only in tarball releases. Further, the backdoor was deployed only in certain environments to avoid detection.
On March 29, 2024, a security researcher stumbled onto a software bug that led him to discover and report the XZ attack. The Cybersecurity & Infrastructure Security Agency (CISA) issued an alert recommending that users downgrade to an uncompromised version of XZ, and Linux vendors promptly issued press releases and remediation efforts to minimize the effects of the attack.
The XZ attack has raised questions within the open source community about the risks of having critical software maintained and governed by unpaid volunteers. The attack also serves as a reminder that even widely adopted software is at risk of attack and companies should prepare for future attacks to its or its third party vendor’s software. As part of that process, companies should:
Know your dependencies. Be able to quickly identify, or ensure that third-party vendors can quickly identify, whether a certain software package with a known vulnerability is used in any of a company’s software.
Develop disaster recovery and incident response plans. Response plans are typically more comprehensive and more effective when they are created before an incident. Companies should consult with a variety of subject matter experts, internally and externally, to evaluate the size and scope of its business activities, amount and type of personal information that is collected and stored, the locations of operations and applicable federal, state and sector-specific regulatory requirements.
Apply technology mitigation strategies. Limit access to critical software systems to only those employees and independent contractors who need access to such systems and monitor usage for any unusual behavior.
Review applicable policies and procedures often. Outside counsel can review policies and procedures to ensure compliance with the fast-changing regulatory landscape.
Review vendor contracts for liability protections. Scrutinize vendor contracts for appropriate risk shifting terms. Indemnification clauses may be appropriate and might include claims related to cybersecurity incidents, data breaches and regulatory liability. Representations and warranties might be used to represent that certain mitigation strategies will be deployed and compliance standards will be maintained. Insurance can be a helpful tool, and covenants to purchase adequate insurance might be considered. Further, it may be appropriate to carve out some cybersecurity incidents from a liability cap. In-house and outside counsel can review risk shifting terms in light of current market and legal trends.
[View source.]
