But important software needs to be identified and proportionally more scrutinized by multiple independent parties, that's the lesson. Identification is the hard part. You can't easily determine that half of the world relies on this particular piece of software, or that it enables access to desirable targets.
Yes, this almost succeeded... but can you imagine how many scenarios where someone such as Andres Freund would have found irregularities, but then.. what? Just had to report it to some webpage's contact page? Without being able to even dig further?
Would he have known what was happening, or would it have just ended up as an oddity, with no source code, and with the binary purposefully obscured, and so on?
Or... even worse, it's reported directly to the 2 guy team, and the guy who put the back door in... takes the bug report?!
From where I sit the sleeper/mole problem exists in companies, and can be far harder to detect.
Yes, you get more eyes and people like Andres Freund.
However, if this had been a mole in a company, he wouldn't be able to hide behind a possibly anonymous fake persona and (likely) be immune from any consequences/fallout from this attack. It would be harder to gain entry in the first place, he would have needed a real identity. Background checks may not be a big hurdle, but they're at least something more than signing up for a GitHub account. He also wouldn't have had his posse of anonymous sock puppet accounts to add pressure to the original maintainer.
I also think that just being able to ramp up on liblzma and its dependencies to undertake this effort in the first place is a huge head start vs. trying to execute the same attack on a closed source corporate product.
At the same time, there are probably lower hanging fruits to attack if you really do get a mole inside a company, in addition to there being fewer eyes/opportunities for the attacks to be discovered as you pointed out.
I honestly don't know how all of these factors add up. I expect the argument opposite to yours to be raised (again) in the wake of this incident. I'd personally be hesitant to raise this argument (not that it matters here on HN).
Lots of companies hire remote workers sight unseen, and not all require proof of identity, and where they do, that proof can possibly be easily faked by someone willing to break the law.
Larger Open Source projects - e.g. Debian Developers, also have real-identity verification through chain of trust.
> Background checks may not be a big hurdle, but they're at least something more than > signing up for a GitHub account.
GitHub doesn't allow more than one free account per person. Companies might not look for employees sharing an IP address as much as GitHub does.
> He also wouldn't have had his posse of anonymous sock > puppet accounts to add pressure to the original maintainer.
Depending on the software, it might not be that hard to be a customer (or even pretend to be an employee of a known customer, if they aren't validating incoming requests claiming to be from customers enough) and add pressure for features that will provide cover for a backdoor, or even for a product that isn't a commercial success to be handed over to an external developer.
You can save a lot of time reading John LeCarre novels and take a short summary like this one of Adam Curtis [0].
If you watched the recent Oppenheimer film you'll know the name Klaus Fuchs. But what about Guy Burgess, Kim Philby and Anthony Blunt? If MI5, MI6 and GCHQ are. almost by tradition stacked to the rafters with defectors and spies, enclaves of enemies within, and enemies within enclaves of enemies... how does anyone expect a commercial company motivated by money and with such a weak perimeter as a "job market", to do better?
Trust does not have an organisational solution.
[0] https://www.bbc.co.uk/blogs/adamcurtis/entries/3662a707-0af9...
Success is making it to some machine, and then it's "how long it's successful for". Who knows how many other such vulnerabilities there are, and the openness of the source didn't protect us as quickly as we thought it would.
Did it? At least in Debian, where it was found in the first place, it only existed in sid/unstable and I think perhaps in testing. It never made it into stable which is the only thing you should be running on a production system.
I think in Fedora it was also only in a testing or RC of the next stable version but I'm not sure. Also unsure about others. I have seen several distros putting out advisories (Gentoo, Arch, OpenSuse and more) but I didn't go into the specifics.
The end goal seems to have been to get it into the LTS releases of rhel and Ubuntu. Since this was a valuable it's probably something kept around for when other methods fail. I doubt it would be used before the really valuable systems are compromised (rhel and Ubuntu in cloud and governments)
Though it was frighteningly close, 24.04 is scheduled to be released on April 25.
There's nothing wrong with Debian stable having years-old packages either. In any case:
> The current "stable" distribution of Debian is version 12, codenamed bookworm. It was initially released as version 12.0 on June 10th, 2023 and its latest update, version 12.5, was released on February 10th, 2024.
https://www.debian.org/releases/
That's just over 1 year. Sure, packages themselves will be older than that since they take some time soaking frozen in testing before they become part of stable but that's generally a good thing.
In any case, if there's pressing need for some newer packages, it's always possible to use apt pinning to pull those on top of a stable base.
> > It made it to production, for a long time
I never said it didn't make it to production. I was asking if that's the case, and giving one data point.
It apparently didn't make it into Ubuntu LTS either, so there's another one.
If you have information that proves or disproves either point, please present it.
If this happened on a proprietary software project, …I have verified proof of identity documents for everyone on my team. These can of course be faked or fraudulently obtained, but it heightens the barrier to entry and leaves more of a paper trail. That’s not something that we have in this scenario. There’s way more give and take between open and closed source than open source purists make out. They just like the idea of being able to see source code.
You should check the thread posted yesterday, the Lastpass guy who raised a PR for a go binding for xz but was otherwise unrelated to this fiasco already faced a bit of questioning regarding their motivations from their employer based on a user reporting them from a contact form.
Moreover, many companies already have information from background checks, and in certain countries, they also have the tax identification number of the employee which can pretty much identify who put in the backdoor.
That is pretty hard to defend against. I wonder if they were planning this all along, or if they wound up with a greedy plan later, or what.