- cross-posted to:
- privacy@lemmy.ml
- cross-posted to:
- privacy@lemmy.ml
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.
You must log in or register to comment.
Here is a more detailed FAQ about what happened:
This is also a good summary of the timeline: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
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.
Auditing can be done only on open source code. No code = no audit. Reverse engieneering doesn’t count.
The answer is the same as closed source software: sometimes.
But that’s beside the point, a security audit is not perfect. Plenty of audited codebases are the source of security vulnerabilities in the wild. We know based on analysis that the malicious actor’s approach would have a high chance of successfully hiding from a typical security audit.
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.
It’s maybe possible, but perhaps even unlikely still.
Overwhelmingly thorough security review is time consuming and expensive. It’s also not perfect, as evidenced by just how many security issues accidentally live long enough to land Even in enterprise releases. That’s even without a bad actor trying to obfuscate the changes. I think this general approach had several aspects that would made it likely to pass scrutiny:
- It was in XZ, which was likely not perceived as a security critical library. A security person would recognize any thing as potentially security critical, but they don’t always have the resources and so are directed to focus on obviously security related and historically security incident magnets.
- it was carried out by someone who spent years building up an innocuous reputation. Investigation may even show previous “test samples” to be malicious but not caught, or else it was a red herring to get people used to random test samples getting placed in the project.
- The only “source code” he touched was “just build scripts”. Even during a security audit, build shell scripts are likely going to be ignored, they are just build scripts and maybe you run some tests on all scripts, but those tests aren’t going to catch this sort of misbehavior.
- The actual runtime malicious code was delivered as portions of ostensibly throw away test sample xz files. The malicious code is applied by binary patch of the build output. A security audit won’t be thinking too hard about a sea of binary files that are just throwaway samples as fodder for test.
So while I see the point about logical fallacy about it accidentally not getting far enough to see if the enterprise release process would have caught it, I think we know track records well enough to deem this approach likely to get through. Now that it has been caught, I could see some changes that may mitigate this in the future. Like package build scripts deleting all test samples and skipping tests when building for release, as well as more broad scrutiny.
There’s also the reality that a lot of critical applications deem themselves too cool to settle for “old crusty enterprise distributions”. They think that approach is antiquated and living on the edge is better. Admittedly I doubt theyd go as far as arch, tumbleweed, or rawhide, but this one could have easily made it to Debian testing, fedora release, or an Ubuntu release.
I think we know track records well enough to deem this approach likely to get through.
That was my concern, and why I brought up my point.
Human nature, especially when volunteer work versus paid work is being done, as well as someone who purposely over the long-term is trying to be devious, could be a potent combination for disaster.
I still wonder if there should be an actual open source project that does nothing but security audits of all other open source projects, hence my original question as an opener to a conversation that I never got to elaborate on because I was getting attacked almost immediately by people who are very sensitive about bringing any criticisms/concerns about open source out in the open.
The issue is that it implies that open source has a problem due to volunteers that is not found in closed source, which is not really the reality.
You can look at a closed source vendor like Cisco and see backdoors, generally left over from developer access, yet open for abuse. The nature of those is so blatantly obvious any open review would have spotted it instantly, yet there it was
With this, you had a much more device obfuscated attack that probably would have passed through even serious security audits unnoticed, yet it was caught because someone was curious about a slight performance degradation and investigated. Having been in the closed source world,I can tell you that they never would have caught someone like this. Anyone even vaguely saying they wanted to spend some time investigating a session startup delay of half a second would be chastised for wasting time.
Further, open source projects are also the fodder for security researchers to build their resumes. Hard to prove your mettle without works, and catching vulnerabilities in OSS code is a popular feather in their cap.
It also implies that open source is strictly a volunteer affair. Most commercial applications of a Linux platform involve paid employees doing some enablement, and that differs place to place. There’s of course red hat paying for security research, Google, Microsoft also. I know at least one company that distrusts everything and repeats a whole bunch of security audits, including paying external companies to audit open source code. I would wager that folks downstream of say centos stream or certain embedded platforms can feel pretty good about audits. Of course all bets are off when you go grab yarballs, npm, pip, etc.
The issue is that it implies that open source has a problem due to volunteers that is not found in closed source, which is not really the reality.
I (partially) disagree. Fundamentally, my belief is that someone who gets paid to do the work is more rigorous doing the work than someone who does it on a volunteer basis, a human nature thing. Granted, I’m speaking very generally, and what I stated is not always true, but still.
Also, corporations that write close source programs are much more legally adverse to being sued if their product fails (there’s a reason why we’re seeing so many corporations slapping in arbitration clauses into their agreements these days; risk-averse).
Open source projects tend to just be more careful about their code base not being tainted, and write in disclaimers (“As-is”) to protect themselves legally for the failure of the product scenario, and call it a day (again, very generally speaking (I use Fedora specifically for a reason)).
And speaking of Fedora, I do agree with your point that some open source projects are actually done by paid coders. I just believe that’s more of the outlier, than the norm, though. Some of that work is done by corporate employees, but still on a volunteer basis.
Not dismissing at all, I am thankful for corporations that actually spend time letting their employees do open source work, even if it’s just for their own direct benefit, as it also benefits everyone else.
Having worked with closed source, whatever they project externally, internally they are generally lazy and do the bare minimum. If there is a security review, it might just be throwing it at something like bdba that just checks dependencies against cve. Maybe a tool like coverity or similar code analysis. That’s about as far as a moderately careful closed source so goes. It is exceedingly rare for them to fund folks to endlessly fiddle with the code looking for vulnerabilities, and in my experience actively work to rationalize away bugs if possible, rather than allocating time to chasing root cause and fix.
There may be paragons of good closed source development, but there are certainly bad ones. Same with open source.
I also think most open source broadly is explicitly employee work nowadays. Not just hobbyist, except for certain niches.
internally they are generally lazy and do the bare minimum.
Day to day, and with a lazy manager who is not technically knowledgeable, I would agree, and they do existence in corporations.
But if you work for one who knows what they’re doing and gets a mandate from their boss to make sure the code doesn’t leave the corporation legally exposed, then not so much.
Also special events like Y2K also gets extra scrutiny for legal reasons way up and above the normal level scrutiny thing production code gets.
I’ve worked it both types throughout my career.
Also they are counting the hits and ignoring the misses. They are forgetting that sneaking a backdoor into an open source project is extremely difficult because people are reviewing the code and such a thing will be recognized. So people don’t typically try to sneak back doors in. Also, backdoors have been discovered in an amazing amount of closed source projects where no one was even able to review the code.
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.
-
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.
No, I’m actually making that comment based on a career as a software developer, who has actually worked on a few open source projects before.
Your credentials don’t fix the logical fallacy.
Experience matters.
That’s another logical fallacy: Argument from authority
The backdoor has existed for a month at least. Yikes.
There are no known reports of those versions being incorporated into any production releases for major Linux distributions
…
A stable release of Arch Linux is also affected.
… BTW.
I liked the joke, but ya arch is not compromised. Check out this user’s detailed comment.
The malicious code is only thought to have affected deb/rpm packaging (i.e the backdoor only included itself with those packaging methods). Additionally, arch doesn’t link ssh against liblzma which means this specific vulnerability wasn’t applicable to arch. Arch may have still been vulnerable in other ways, but this specific vulnerability targeted deb/rpm distros
Dude seems like a foreign asset
Jia Tan, University of Hong Kong in China. He’s been the sole maintainer of the package for almost two years.
Looks like he’d done a lot for various US companies on his LinkedIn.
I would not be surprised if he was previously legit but pressured into doing this by the CCP.
Maybe he wasn’t sloppy by accident if he was indeed coerced by someone. I don’t think we’ll ever find out the backstory of this though.
I’ve watched a rundown of what the backdoor does. It’s impossible that this was an accident. It hides a compiled library in test data and injects that into the ssh binary to override code there.
They didn’t mean the backdoor was (or was not) an accident. They meant the backdoor was implemented sloppily enough to be discovered and maybe that was not an accident (as in, he wanted it to be found, but still wanted to plausibly be seen as trying his best to keep those coercing him appeased)
It would make more sense to compromise developers in trusted positions, or steal their credentials, than going through the time and effort of building trusted users and projects only to burn them with easily spotted vulnerabilities.
This wasn’t easily spotted. They use words like sloppy, but it all started with someone digging in because starting ssh season was about a half second slower that it used to be. I could easily imagine 99.99% of people shrugging and deciding just something in the chain of session startup took a bit longer for a reason not worth digging into.
Also, this was a maintainer that just started two years ago. xz is much older than that, just he took over.
foreign to whom?
his mother. he hasn’t called in a week, he doesn’t write.
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
dpkg --list | grep xz
should return what version of xz package is on your system. Likely 5.4, in which case you should be okay.
ii xz-utils 5.2.5-2ubuntu1 amd64 XZ-format compression utilities On my latest Mint install.
which isn’t an effected version, so you should be okay.
This is why I don’t use Linux. Insecure as fuck.
This. Everyone knows that windows is a perfectly safe and secure environment with no exploits and vulnerabilities whatsoever.
Windows user?
Tell me you dont know shit about software development without telling me you dont know shit about software development
Technically it breaks libsystemd encryption, which is not used in upstream openssh. There are unofficial redhat patches that use this library instead of reading one enviroment variable and writing to one file.
And that’s why you cannot trust open source software blindly.
Ftfy: And that’s why you cannot trust people blindly.
Just because we cant observe the code of proprietary software and is sold legally doesn’t mean its all safe. Genuinely I distrust anything with a profit incentive.
The backdoor appears to specifically target RSA public key authentication, so they must have had a target in mind that they know uses RSA keys.
I would highly recommend Curve25519, etc., just because such keys are faster and less common than RSA public-private keys in today’s world. RSA 2048-bit keys are considered weak today, while the Curve25519 256-bit keys remain stronger. Also, the ChaCha20-Poly1305 cipher has an interesting backstory and doesn’t necessarily need hardware acceleration (which, in theory, could be borked by the HW-vendor) to obtain good performance.
Unfortunately, some SSH front-ends don’t play nice with Curve25519 public-private keys yet… (I’m pointing at the putty SSH client, but that may have improved from the last time I had to use it)
It would be Ed25519 for SSH:
$ ssh-keygen -t ed25519
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 think you are greatly underestimating FSB incompetense.
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.
Backdoors at a mation-state level are a double edged sword. In order to successfully implement a backdoor, you need to ensure that you are more clever than your adversaries, because those same backdoors can be used against you. You must assume that they will eventually discover them, and be able to leverage them against you. Then you must be able to identify that it had been compromised, and then “responsibly disclose” the vulnerability before too much damage is done.
Much better to be on the defensive. Discover 0days first, either accidental or intentional, and then use them until someone else discloses them and they get patched to hell.
In order to successfully implement a backdoor, you need to ensure that you are more clever than your adversaries, because those same backdoors can be used against you.
In this instance, that’s not the case. Only those in possession of the right key can use the backdoor. Also, discovering infected systems from the outside, appears to be impossible - the backdoor simply does not do anything to reveal itself if you don’t have the key.
I must be mistaken then. I suppose keys have never, ever been compromised. Nobody has ever taken sensitive information without authorization, either. Especially not from the NSA!
You were talking about adversaries discovering the backdoor. That’s something entirely different from compromised keys. So your sacrasm is quite misplaced here.
It’s not the NSA that’s been asking for encryption to be broken in recent years.
I remember 2013 backdoored crypto by NSA. If they get caught less doesn’t mean they make less backdoors.
EIDT: it was discovered in 2007 and revoked as standard in 2014
Also they owned corporation that made backdoored crypto algos till 2018. And the only reason they stopped is FOIA.
I don’t know man. Imagine you could have ssh access to every Debian and fedora server on the planet, and all you had to do was write tests for some compression library for 2 years and sneak in a clever patch. I’d guess such an exploit is worth millions. You wouldn’t work 2 years for millions of dollars?
This is sophisticated but it doesn’t have to be a state actor.
A stable release of Arch Linux is also affected. That distribution, however, isn’t used in production systems.
Shots fired!
It seems WSL Ubuntu and Kali are safe with versions 5.2.5 and 5.4.4 installed respectfully.
Damn, I installed mine disrespectful.
Don’t forget about openSUSE Tumbleweed! It’s actually affected AFAIK.
I think the AI that wrote the article misunderstood.
Arch doesn’t build from release tar balls, but straight from git. Arch also doesn’t link sshd against liblzma. So while they’ve shipped the dirty version of xz utils, at least sshd is not affected.
It’s possible that the dirty version affected some of the other things that link liblzma. Like a handful of kde components for example.
Also, the malicious code only activated if it detected being built as dpkg or rpm.
the AI that wrote the article
The linked article is by Dan Goodin from Ars Technica. He’s not immune to mistakes, but he’s been writing good articles about security for years.
Can we please not accuse everybody of being AI just because they made a mistake?
Can we please not accuse everybody of being AI
Suspicious. /s
Well, he’s credited as the editor overseeing security stuff. Reading between the lines I’d say he’s just taking responsibility for the articles correctness.
This article in particular is just so poorly written that you’d forgive me for assuming it wasn’t man-written.
This is really bad.
openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.
It’s all systemds fault, got it.
Had redhat’s patch write
READY=1into $NOTIFY_SOCKET instead linking to libsystemd to do this, this backdoor would not be possible.
