The XZ Utils Backdoor in Linux: A Symptom of Ailing Security in the Software Supply Chain

The cybersecurity industry was once again placed on high alert following the discovery of an insidious software supply chain compromise. The vulnerability, affecting the XZ Utils data compression library that ships with major Linux distributions, is logged under CVE-2024-3094 and boils down to a backdoor deliberately inserted by a once-trusted volunteer system maintainer, who managed to socially engineer his way to a position of trust before turning rogue. Allowing remote code execution (RCE) in some instances if successfully exploited represents a high-severity issue with the ability to cause serious damage in established software build processes.

Thankfully, another maintainer discovered this threat before the malicious code entered stable Linux releases, but, if this discovery were not made in time, the risk profile would make it one of the most devastating supply chain attacks on record, perhaps even eclipsing SolarWinds.

The reliance on community volunteers to maintain critical systems is widely documented, yet rarely discussed until high-impact issues such as this incident bubble to the surface. While their tireless work is essential to the maintenance of open-source software, this highlights the need for serious emphasis on security skills and awareness at the developer level, not to mention heightened access controls around software repos.

Software is the foundation of virtually every modern enterprise, yet our reliance on potentially vulnerable open-source components in critical systems represents an extreme risk in the software supply chain. It’s an ailment for which we must find an appropriate cure.

The XZ Utils Backdoor Is a Symptom of Lax Code-Level Security Protocols

The XZ Utils malicious package was painstakingly obfuscated by the threat actor, which, when triggered to construct itself during the build process, hampers authentication in SSHd via systemd. As Red Hat detailed, in the right circumstances, this interference could potentially allow an attacker to break SSHd authentication and gain remote unauthorized access to the entire system. It is no simple exploit, but a general lack of access control and zero-trust measures certainly aided its creation.

Preventing this attack type is incredibly difficult - especially when utilizing open-source components in software - as there is precious little assurance and transparency over the security of the supply chain. As an industry, we are accustomed to combatting accidental flaws in the software supply chain, but this attack reveals that risk has elevated to include security bugs deliberately planted with malice to compromise open-source security. Recent research from Enterprise Strategy Group (ESG) detailed that a staggering 91 percent of enterprises had experienced a software supply chain security incident in the past 12 months, suggesting that, along with attack vectors like APIs, this is a prime target for cybercriminals looking to cause as much disruption as possible.

Most developers will not be able to stop an attack of this nature unless they have a strong sense of security awareness, healthy security knowledge, and a sprinkling of paranoia. It’s almost a case of requiring a threat actor mindset. However, a chief consideration should always center around source code repos that are controlled internally (i.e., not open-source). These should only be accessible to people who have verified, relevant security skills.

As a potential risk mitigation technique for this scenario, AppSec professionals might consider a setup like branch-level security controls, only allowing security-skilled developers to commit changes to the final master branch. However, this same level of scrutiny into both individual secure coding skills and subsequent access control would go a long way in providing a higher standard of security overall and reducing risk in the supply chain. The ESG survey also detailed that 90% are prioritizing efforts to shift security left to developers, but unless their security skills are continuously practiced, assessed, and verified across the board - not just in the verification of third-party components - it is unlikely to make a significant dent in avoiding code-level vulnerabilities.

Volunteer Maintainers Are Heroes, But It (Should) Take a Village To Sustain Secure Software

To those outside the realm of software engineering, the notion that a spirited community of volunteers painstakingly maintains critical systems in their own time is a difficult concept to grasp, but this is the nature of open-source development, and it continues to be an area of critical risk for security professionals protecting the supply chain and lacking the transparency required to safely assess each component.

Open-source software is a vital part of virtually every enterprise’s digital ecosystem, and trusted maintainers (of which most are acting in good faith) are truly heroic in their selfless pursuit of technological progress and integrity, but it is farcical to keep them delivering in isolation. In these DevSecOps-centric times, security is a shared responsibility, and every developer must be armed with the knowledge and right-fit tooling to navigate the security issues they are likely to encounter in their workday. Security awareness and hands-on skills should be non-negotiable in the software development process, and it’s up to security leaders to influence change at the enterprise level.