Linux dodged a bullet. If the XZ exploit had gone undiscovered for only a few more weeks, millions of Linux systems would have been compromised with a backdoor.
We were lucky. But can we stay lucky?
The Open Source Security Foundation (OpenSF) and the OpenJS Foundation revealed that a similar hackling attempt had targeted several JavaScript programs.
Just as with XZ Utils, a few people wanted OpenJS to designate them as new project maintainers despite having little prior involvement. They “implored OpenJS to take action to update one of its popular JavaScript projects to address any critical vulnerabilities, yet cited no specifics,” wrote Robin Bender Ginn, OpenJS executive director, and Omkhar Arasaratnam, Open SSF general manager.
Well, that was never going to happen.
Jia Tan, the mysterious hacker who became a top XZ programmer and maintainer, before inserting a backdoor in the code, had spent years establishing his project credibility before making his move.
Still, warned Ginn and Arasaratnam, we’ll see more of these kinds of social engineering attacks. In such instances, the friendly attacker seeks to exploit “the sense of duty that maintainers have with their project and community in order to manipulate them.”
Specifically, these security leaders warn against pull requests containing blobs as artifacts. For example, they point out that the XZ backdoor included a cleverly crafted file in the test suite that wasn’t human-readable.
Dubious source code may also be intentionally obfuscated or difficult to understand. For example, the XZ issue started with a relatively innocuous replacement of safe_fprintf() with fprintf() to see if anyone would notice. No one did.
The question now is: Are such attacks already ongoing? Or, far worse, have they already been made, and they weren’t spotted? Chris Hughes, chief security advisor at Endor Labs, told me, he “suspects that many of these are already underway and may have already been successful but haven’t been exposed or identified yet.”
How? Hughes explained, “Most open source projects are incredibly underfunded and run by a single or small group of maintainers, so utilizing social engineering attacks on them isn’t surprising, and given the pressures maintainers are under, they will likely welcome the help. If done well by the attackers, it may be difficult for the maintainers to determine which involvement is from those interested in collaborating and contributing to projects versus those with malicious intent.”
He’s not wrong.
As Jim Zemlin, the Linux Foundation‘s executive director, said at the Open Source Summit North America in Seattle, we’ve been making progress with security. But “trust is something we need to talk more about,” he added. We need to answer the question: “Who writes all this software? This is different from a security question. Security is ‘Is there a vulnerability?’ Who is more of a trust question? Do we trust this identity? Enough to give them a maintainer role?”
Bad news, folks. Zemlin admitted we don’t have a good solution to this problem.
Indeed, we’ve seen such attempts before. In 2021, for example, researchers at the University of Minnesota tried to insert vulnerabilities in the Linux kernel to see if it could be done. Spoiler alert: They failed, and they were banned from the Linux kernel.
But don’t get comfortable. The Linux kernel has a large team of passionate, brilliant maintainers. Few projects are so lucky.
Dan Lorenc, founder and CEO of the security company Chainguard, put it well. “Projects get stale, maintainership changes, and there are a lot of considerations to keep in mind when granting someone new commit access to a critical project. There’s no single right way to do this, but cataloging best practices with the community would go a long way to helping prevent this in the future.”
What are the trust best practices? We honestly don’t know yet. But, if we’re to trust our open source projects, we must figure it out.
