The malicious changes were submitted by JiaT75, one of the two main xz Utils developers with years of contributions to the project.
“Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system,” an official with distributor OpenWall wrote in an advisory. “Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the ‘fixes’” provided in recent updates. Those updates and fixes can be found here, here, here, and here.
On Thursday, someone using the developer’s name took to a developer site for Ubuntu to ask that the backdoored version 5.6.1 be incorporated into production versions because it fixed bugs that caused a tool known as Valgrind to malfunction.
“This could break build scripts and test pipelines that expect specific output from Valgrind in order to pass,” the person warned, from an account that was created the same day.
One of maintainers for Fedora said Friday that the same developer approached them in recent weeks to ask that Fedora 40, a beta release, incorporate one of the backdoored utility versions.
“We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added),” the Ubuntu maintainer said.
He has been part of the xz project for two years, adding all sorts of binary test files, and with this level of sophistication, we would be suspicious of even older versions of xz until proven otherwise.
This is really bad.
From the article…
Will Dormann, a senior vulnerability analyst at security firm Analygence, said in an online interview. “BUT that’s only because it was discovered early due to bad actor sloppiness. Had it not been discovered, it would have been catastrophic to the world.”
Is auditing for security reasons ever done on any open source code? Is everyone just assuming that everyone else is doing it, and hence no one is really doing it?
EDIT: I’m not attacking open source, I’m a big believer in open source.
I’m just trying to start a conversation about a potential flaw that needs to be addressed.
Once the conversation was started I was going to expand the conversation by suggesting an open source project that does security audits on other open source projects.
Please put the pitchforks away.
Edit2: This is not encouraging.
Having once worked on an open source project that dealt with providing anonymity - it was considered the duty of the release engineer to have an overview of all code committed (and to ask questions, publicly if needed, if they had any doubts) - before compiling and signing the code.
On some months, that was a big load of work and it seemed possible that one person might miss something. So others were encouraged to read and report about irregularities too. I don’t think anyone ever skipped it, because the implications were clear: “if one of us fails, someone somewhere can get imprisoned or killed, not to speak of milder results”.
However, in case of an utility not directly involved with functions that are critical for security - it might be easier to pass through the sieve.
You’re making a logical fallacy called affirming the consequent where you’re assuming that just because the backdoor was caught under these particular conditions, these are the only conditions under which it would’ve been caught.
Suppose the bad actor had not been sloppy; it would still be entirely possible that the backdoor gets identified and fixed during a security audit performed by an enterprise grade Linux distribution.
In this case it was caught especially early because the bad actor did not cover their tracks very well, but now that that has occurred, it cannot necessarily be proven one way or the other whether the backdoor would have been caught by other means.
That link doesn’t prove whatever you think it’s proving.
The open source ecosystem does not rely (exclusively) on project maintainers to ensure security. Security audits are also done by major enterprise-grade distribution providers like Red Hat Enterprise. There are other stakeholders in the community as well who have a vested interest in security, including users in military, government, finance, health care, and academic research, who will periodically audit open source code that they’re using.
When those organizations do their audits, they will typically report issues they find through appropriate channels which may include maintainers, distributors, and the MITRE Corporation, depending on the nature of the issue. Then remedial actions will be taken that depend on the details of the situation.
In the worst case scenario if an issue exists in an open source project that has an unresponsive or unhelpful maintainer (which I assume is what you were suggesting by providing that link), then there are several possible courses of action:
- Distribution providers will roll back the package to an earlier compatible version that doesn’t have the vulnerability if possible
- Someone will fork the project and patch the fix (if the license allows), and distribution providers will switch to the fork
- In the worst case scenario if neither of the above are possible, distribution providers will purge the vulnerable package from their distributions along with any packages that transitively depend on it (this is almost never necessary except as a short-term measure, and even then is extremely rare)
The point being, the ecosystem is NOT strictly relying on the cooperation of package maintainers to ensure security. It’s certainly helpful and makes everything go much smoother for everyone if they do cooperate, but the vulnerability can still be identified and remedied even if they don’t cooperate.
As for the original link, I think the correct takeaway from that is: If you have a vested or commercial interest in ensuring that the open source packages you use are secure from day zero, then you should really consider ways to support the open source projects you depend on, either through monetary contributions or through reviews and code contributions.
And if there’s something you don’t like about that arrangement, then please consider paying for licenses on closed-source software which will provide you with the very reassuring “security by sticking your head in the sand”, because absolutely no one outside the corporation has any opportunity to audit the security of the software that you’re using.
That link doesn’t prove whatever you think it’s proving.
That link strengthens my argument that we’re assuming because it’s open source that the code is less likely to have security issues because it’s easier to be audited, when in truth it really just depends on the maintainer to do the proper level of effort or not, since it’s volunteer work.
When someone suggested a level of effort to be put on code checked in to prevent security issues from happening, the maintainer pushed back, stating that they will decide what level of effort they’ll put in, because they’re doing the work on a volunteer basis.
And my rebuttal is three-fold:
-
Security does not depend entirely on the maintainer, and there is recourse even in the worst case scenario of an uncooperative or malicious maintainer.
-
The maintainer you quoted said he would be open to complying with requests if the requesters were willing to provide monetary support. You are intentionally misrepresenting their position.
-
The alternative of closed source software doesn’t actually protect you from security issues, it just makes it impossible for any users to know if the software has been compromised. For all you know, a closed source software product could be using one of the hypothetical compromised open source software project that you’re so afraid of, and you would never actually know.
If you’re willing to pay a license for a private corporation’s closed source software so you get the pleasure of never being able to know your security posture, then why would you be unwilling to financially support open source developers so they have the resources they need to have the level of security that you’d like from them?
You are intentionally misrepresenting their position.
No I’m not. Or you’re assuming my position incorrectly.
You’re either intentionally misrepresenting the post or you failed to understand them correctly. I’ll let you take your pick for which is less embarrassing for you.
-
Long game supply chain attacks, pretty much going to be state actors. And I wouldn’t chalk it up to the usual malicious ones like China and Russia. This could be the NSA just as easily.
I honestly think the NSA has changed. If you look at the known backdoors they haven’t got caught making any new backdoors since like 2010. Their MO also seems to be more hardware and encryption (more of an observational charter) than manipulation.
There’s also evidence US Congress acted to stop the NSA from doing these underhanded tacits at least once https://www.wired.com/story/nsa-backdoors-closed/
They’re not idiots, lots of smart people there that surely understand the risk of something like this to US national security interests. It’s not the NSA that’s been asking for encryption to be broken in recent years. They’ve been warning about quantum threats and … from what I’m aware of actually been taking on the defensive role they were conducted to perform https://gizmodo.com/nsa-plans-to-act-now-to-ensure-quantum-computers-cant-b-1757038212
This seems like something that could actually be weaponized against predominantly western technology companies so I’d be very surprised if it was them and very surprised if they used someone that appears to be a Chinese born resident to do it.
I really can’t believe they’ve stopped. Their mentality is “national security has no morals”. They’ll do everything they can do to facilitate that mission, though not getting caught is a big part of the facade they need to put on to keep or renovate their image to do this.
Maybe they’re being more careful, and doing simple things like putting in timestamps that emulate working hours in other timezones are certainly the first thing they’re going to think about. That one has always cracked me up, security researchers point to it like it’s proof of something, which is ridiculous. Just like our people are smart, I don’t think the foreign actors are dumb either.
And before you say it, I’d be all over not being paranoid if it hadn’t been proven to me time and again that these agencies won’t change, that they don’t give a shit about what’s right if it gets in the way of their mandate. The only thing that might change is how well they hide things now and intimidate their people into staying quiet. Because potential whistleblowers have seen the examples that have been made.
Please help me as a novice Linux user- is this something that comes preinstalled with Mint Cinnamon? And if so, what can I do about it?
You’re good. Even if you do use xz and ssh the version with the vulnerability only made it’s way to rolling release distros or beta version of distros like fedora 40
made its* way to
And that’s why you cannot trust open source software blindly.
And yet with closed-source software you have no choice but to trust it blindly. At least open source software has people looking at the code.
Bet you anything there were more pairs of eyes on SolarWinds code than this. Sick of this open source bystander effect.
Code scanners check for vulnerabilities not malicious code. Ain’t no one running full coverage dynamic scanners to trigger all branches of code on this thing, otherwise this would’ve been caught immediately
Vulnerabilities are caught and fixed faster in open source projects than closed ones.
The researchers found that open-source programmers fixed Linux issues in an average of only 25 days. In addition, Linux’s developers have been improving their speed in patching security holes from 32 days in 2019 to just 15 in 2021.
Its competition didn’t do nearly as well. For instance, Apple, 69 days; Google, 44 days; and Mozilla, 46 days.
Coming in at the bottom was Microsoft, 83 days, and Oracle with 109 days.
By Project Zero’s count, others, which included primarily open-source organizations and companies such as Apache, Canonical, Github, and Kubernetes, came in with a respectable 44 days.
deleted by creator
