comexMaybe I should reconsider my policy of running Debian unstable, on both desktops and servers…
Daniel Micay@comex Having updates delayed for years provides strong assurance you'll have lots of serious security vulnerabilities unfixed. Most security relevant fixes don't actually receive CVE assignments and therefore don't get backported. Delaying changes for a a month and backporting patches for serious issues might make sense but delaying for years is not going to bring you security. It's also possible that a tiny portion of the huge stream of security vulnerabilities being fixed were intentional.
@comex The person who did this had become the maintainer of the project. The issue was only caught at all because it caused performance issues someone looked into. It's entirely possible and perhaps even likely that there are similar, much longer term successful attacks similar to this one.
https://grapheneos.social/@AndresFreun[email protected]/112180083704855572
Since the attack was successful against Debian unstable, it's entirely possible it was used to compromise a lot of open source developers / projects and through that other projects.
AndresFreundTec (@[email protected])
I accidentally found a security issue while benchmarking postgres changes. If you run debian testing, unstable or some other more "bleeding edge" distribution, I strongly recommend upgrading ASAP. https://www.openwall.com/lists/oss-security/2024/03/29/4
@comex Many Debian developers likely use Debian unstable. The payload specifically targeted Debian. It relied on Debian adding liblzma as an indirect dependency of sshd through classic Debian downstream patching adding libsystemd as a dependency of sshd which pulled in liblzma. This avoided them needed to do more easily detected cross-process nonsense. If they hadn't caused a performance issue with their code, there's a high chance they would have gotten away with this for much longer.
@DanielMicay Well, that’s largely orthogonal to the issue of stable distros lacking upstream vulnerability fixed, unless a backdoor is removed by accident without people realizing it’s a backdoor, which is possible I suppose.
@comex My main point is that if an attacker can get a backdoor into Debian unstable, they can almost certainly get it into Debian stable from there. Many Debian developers likely use Debian unstable on machines they use to develop Debian. It's not clear what the ultimate goal was of this attack but I would expect whoever is behind it took advantage of their backdoor being shipped even if it didn't reach their ultimate targets directly. They were playing the long game:
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
@comex I think pretty much anyone with a lot of awareness of software security knew that this was possible. It's still pretty scary seeing a successful attack where they nearly got away with it for likely much longer if only they had optimized their code. It's scarier seeing it happen with core infrastructure, and we all know a whole lot of these projects are barely maintained if at all. As an example, every major distro has unzip/zip last updated in 2009 with dozens of downstream CVE patches.
@DanielMicay I have no illusion that stable will save me from every instance of a sophisticated backdoor like this, but to the extent a hypothetical backdoor exists in both stable and unstable, it wouldn’t affect the choice between them.
@DanielMicay I do wonder how lucky we got. It could have easily lasted longer than a month; but would it have lasted years? It was discovered by chance, but given how many different engineers there are doing different weird things, how long until someone should be expected to find it by chance? A better-designed backdoor would have made it (much?) harder. On the other hand, this is a core component present on systems with relatively small userlands.
@comex It's lucky to have discovered it so soon but we don't know how much they've compromised with it. It's very easy to mass compromise hosts via an easily exploitable vulnerability in sshd, nginx, etc. It's a concern we've had about having sshd exposed to the internet and is part of why we have our build infrastructure local without sshd publicly exposed. We expect compromising OVH, Hetzner, etc. would be easier than compromising sshd so it's not much of a concern for our public services.
@DanielMicay It will sure be spicy if a large hosting provider is ever revealed to have been backdoored! Especially if it’s named AWS. Just imagine.