- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
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’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.
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.
Everyone assumes what you have stated, but how often does it actually happen?
How many people, and how often, and how rigorous, are code reviews actually done? Especially with large volume projects?
Depends on the project, but for a lot of projects code review is mandatory before merging. For XZ the sole maintainer can do whatever they want.
I’ve done plenty of code reviews in my time, and I know one thing, the more busy you are, the faster you go through code reviews, and the more chance things can be missed.
I would hope that for the real serious shit (like security) the code reviews are always thorough and complete, but I know my fellow coding brethren, and we all know that’s not always the case. Time is a precious resource, and managers don’t always give you the time you need to do the job right.
Personally I use a distro backed indirectly by a corporation and hope that each release gets the thorough review that it needs, but human nature is always a factor in these things as well, and honestly, there are times when everyone thinks everyone else is doing a certain task, and the task falls between the cracks.
Reviewing the code was irrelevant in this case because the back door only existed in the binaries.
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:
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.
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.
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.
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.
The same argument can be made about open source, some projects are very carefully and festidously managed, and others not so much.
Main difference is with closed source, it’s hard to know which sort of situation your are dealing with, and no option for an interested third party to come along and fix a problematic project.
Have those audits you allude to ever caught anything before it went live? Cuz this backdoor has been around for a month and RedHat is affected, too. Plus this was the single owner of a package who is implicitly trusted, it’s not like it was a random contributor whose PRs would get reviewed.
The code being open source helps people track it down once they try to debug an issue (performance issue and crashes because in their setup the memory layout was not what the backdoor was expecting), that’s true. But what actually triggered the investigation was the bug. After that it’s just a matter of time to trace it back to the backdoor. You understimate reverse engineers. Or maybe I’m just spoiled.
How long until US bans code from developers with ties to CN/RU?
That won’t happen because it would effectively mean banning all FOS which isn’t remotely practical.
How do you propose we meaningfully fix this issue? Hoping random people catch stuff doesn’t count.
An open source project that does nothing but security audits on other open source projects?
https://github.com/google/oss-fuzz/pull/10667#pullrequestreview-1518981986
This person says OSS Fuzz would not have found it.
How do you interpret the reactions to that comment that you linked?
I ask in trying to understand how to interpret the comment accuracy/validity.
That’s a great question. No way to tell. It’s freaking emoji.
A thumbs down could be displeasure of the product not being able to catch it, or it could be them not liking the comment because they think it’s untrue.
A fuzzer might catch the crashes related to the memory layout? But its purpose is to look for vulns not malice.
The dude himself is legit tho, he probably owns OSS Fuzz
https://www.linkedin.com/in/jonathan-metzman-b8892688
https://security.googleblog.com/2021/03/fuzzing-java-in-oss-fuzz.html
So many different ones too, not just up or down thumb emojis.
In time it may become a trade-off between new (with associated features and speed) Vs tried and tested/secure.
To us now this sounds perverse, but remember that NASA generally use very old hardware because they can be more certain the various bugs & features have been found and documented. In NASA’s case this is for reliability. I’ll concede ‘brute force’ does add another dimension when applying this logic to security.
This may also become an AI arms race. Finding exploits is likely something AI could become very good at - but a better AI seeking to obfuscate?
https://hachyderm.io/@drmorr/112193633428121537
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:
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 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?
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 incorrectly seeing more into what I’m saying than I’m actually saying, probably because you are very invested in defending Linux, and interpret what I’m saying as an attack on Linux.
For what its worth, I’m not attacking Linux. I use Linux as my daily driver (Fedora/KDE).
The key sentence in the post you linked which constituted more than 50% of the words being stated by the poster and yet you somehow conveniently missed which completely negates the whole narrative that you’re trying to promote:
Which means this person is NOT simply a volunteer as you insinuated here:
but in fact is available to be paid a fair rate for the labor they perform. In fact your entire description of the post is mischaracterizing what is being said in the post.
I don’t know how you could have accidentally missed or misinterpreted one of the two sentences being said by the poster, and the longer of the two sentences at that. It was also the first sentence in the poster’s statement. It seems more likely to me that you missed that on purpose rather than by accident. Maybe you’re just so eager to find evidence to match your narrative that your brain registered the entire point of the post incorrectly. Allow me to reframe what’s being said to simplify the matter:
As a self-employed contractor, if you demand that I perform free labor for you, I will decline that request.
Now just add a much more frustrated tone to the above and you get the post you linked.
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.
deleted by creator
What, experience doesn’t matter?
As Groucho Marx would say, “I can believe you, or my lying eyes”.
deleted by creator
You’re assuming I don’t already know what’s being discussed in the link (or have read the link), but disagree with how it’s being applied to me.
Also, experience doesn’t evaporate into the ether just because someone does not read a link. That’s a fallacy for sure.
deleted by creator
And you’re assuming that I’m assuming that you’re assuming. /s
Any particular reason why you’re getting on my case?
deleted by creator