@triskelion GrapheneOS has responded to it.
| Website | https://daniel.micay.dev |
| https://twitter.com/DanielMicay | |
| GitHub | https://github.com/thestinger |
| Matrix | https://matrix.to/#/@strcat:grapheneos.org |
Daniel Micay
- 2.6K Followers
- 183 Following
- 664 Posts
Security researcher/engineer working on mobile privacy/security. Founder of @GrapheneOS.
@triskelion @kernellogger I didn't warn against using the upstream LTS branches although the older ones do get much less backported.
@triskelion @comex It uses the same kernel.org LTS branches that are officially supported for each device, but we switch to using the latest GKI LTS revision from Greg KH which are based on the kernel.org LTS releases.
We could use the current 6.1 LTS everywhere in theory but we don't want to deviate so far from what's heavily tested and officially supported, so we stick to what's officially used which will get officially migrated to newer LTS branches now that devices have 7 years of support.
@comex They also had a bunch of clear sockpuppet personas. At least one of those personas was reused a bunch of times to advocate for including their patches and then to advocate for the project adding them as a maintainer. They had commits in other projects too.
They were contributing to other projects beyond xz from the Jia Tan persona and it's quite possible they did more from other personas.
We don't really know the extent of their attacks. They may have had past successes already.
@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.
@comex It's quite scary for open source supply chain security as a whole right now because Debian sid/unstable are very widely used across the internet. There are surely many sshd instances exposed both on the default port and other ports which could have been easily detected by the attacker(s). My concern is mainly what happens next. What did they do with the attack after they succeeded? They could have started popping servers with sshd as soon as it shipped in Debian sid.
@comex My point is largely that Debian stable users were only shielded from the first phase of this attack. The attack is also quite probably still ongoing since many people will have updated to the backdoored sshd but not yet updated to patch out the backdoor. It's very easy to scan every port across the whole IPv4 space and take advantage of this against every server with it exposed. I don't think it's unlikely that many servers were compromised and that there's another phase happening.
@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.
@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
