Has this affected OpenBSD at all?
Backdoor in upstream xz/liblzma leading to SSH server compromise
311–320 of 1001 posts
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#312Is the solution against such attacks in the future only to scrutinize more, or are there other reasonable options in terms of hardening?
The lesson here seems to not depend on tools written in languages that have complex, obscure build systems and no one is either able or interested to read. Using tools rewritten in Rust, Go or any other languege which resolves dependencies within project seems the only way to do hardening here.
Rust is the worst in terms of build system transparency. Ever heard of build.rs? You can hide backdoors in any crate, or in any crate's build.rs, or the same recursively.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#313I think its much more likely this was not a bad actor, given their long history of commits.
It's a known fact that China will "recruit" people to operate them. A quote:
> They talk to them, say my friend, I see you like our special menu. Are you from China? Are you here on a VISA? Do you have family back there? Would you like your family to stay alive? Is your loyalty to this temporary employer or is your loyalty to your motherland? You know, a whole bunch of stuff like that. That’s how Chinese intelligence operations acts...
This just gives feelings of less "compromised account" and more "Your account is now our account"
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#314Wait, I'm on mobile. Did this partially slip by because of the ABSURD PRACTICE of publishing release.tarballs that do not 1:1 correspond with source?
Let me guess, autotools? I want to rage shit post but I guess I'll wait for confirmation first.
EDIT: YUP, AT LEAST PARTIALLY. Fucking god damn autotools.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#315Earlier quoted context omitted.
I don't want to read too much into it, but the person (supposedly) submitting the PR seems to work at 1Password since December last year, as per his Linkedin. (And his Linkedin page has a link to the Github profile that made the PR).
Yeah the GitHub account looks really really legitimate. Maybe it was compromised though?
The PR's two commits are signed by a key that was also used to sign previous commits belonging to that author.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#316The author (Jia Tan) also changed the xz.tukaani.org (actually the github.io, where the main contributor is, surprise, also them) release description to state all new releases are signed by their OpenPGP key. I'd guess that was one of the first steps to a complete project takeover.
I hope Lasse Collin still has control of his accounts, though the CC on the kernel mailing list looks kind of suspicious to me.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#317Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project. > If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released. Reading that in a different light, it says giv…
How many of people like this one exist?
If this question had a reliable (and public) answer then the world would be a very different place!
That said, this is an important question. We, particularly those us who work on critical infrastructure or software, should be asking ourselves this regularly to help prevent this type of thing.
Note that it's also easy (and similarly catastrophic) to swing too far the other way and approach all unknowns with automatic paranoia. We live in a world where we have to trust strangers every day, and if we lose that option completely then our civilization grinds to a halt.
But-- vigilance is warranted. I applaud these engineers who followed their instincts and dug into this. They all did us a huge service!
EDIT: wording, spelling
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#318Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project. > If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released. Reading that in a different light, it says giv…
Security Researchers : Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long to me.
Whether its reasonable is debatable, but that type of time frame is pretty normal for things that aren't being actively exploited.
This situation is perhaps a little different as its not an accidental bug waiting to be discovered but an intentionally placed exploit. We know that a malicious person already knows about it.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#319> 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 looks to be limited to Linux systems that are running certain patches. macOS and BSD seem unaffected?
FreeBSD is not affected as the payloads in question were stripped out, however we are looking into improvements to our workflow to further improve the import process.
[deleted]
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#320It looks like the person who added the backdoor is in fact the current co-maintainer of the project (and the more active of the two): https://tukaani.org/about.html
Makes me wonder if he's an owner of the github organization, and what happens with it now?