I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts). Would be interesting to see what's going on here; the person who did the releases has done previous releases too (are they affected?) And has commits going back to 2022 – relatively recent, but not that recent. Many are real commits with real changes, and they have commits on some…
Backdoor in upstream xz/liblzma leading to SSH server compromise
421–430 of 1001 posts
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#422"Lasse Collin," as other posters here have found, does not seem to exist as an experienced coder. Oddly, there is a Swedish jazz musician named Lasse Collin, which would otherwise be one of those names, especially the last name, that would stick out. Instead it is buried under a lot of mentions of a musician.
Searching for my real name on Google doesn't return anything either, I don't think this means anything.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#423Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo. He has been part of the xz proj…
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#424I 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…
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#425I am not embarrassed to say... is there anything in there that someone who runs a server with ssh needs to know? I literally can't make heads or tails of the risk here. All I see is the very alarming and scary words "backdoor" and "ssh server" in the same sentence. If I am keeping stuff up to date, is there anything at all to worry about?
You should probably not be running your own publicly-accessible ssh servers if this email is not sufficient to at least start figuring out what your next actions are. The email itself comes with an evaluation script to figure out if anything is currently vulnerable to specifically this discovery. For affected distributions, openssh servers may have been backdoored for at least the past month.
Thanks, though, for pointing out the little script at the very end of that technical gauntlet of an email intended for specialists. I had gotten through the first 3 or 4 paragraphs and had given up.
What I should have done is just googled CVE-2024-3094, whatever, still glad I asked.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#426Out of curiosity I looked at the list of followers of the account who committed the backdoor. Randomly picked https://github.com/Neustradamus and looked at all their contributions. Interestingly enough, they got Microsoft to upgrade ([0],[1]) `vcpkg` to liblzma 5.6.0 3 weeks ago. [0] https://github.com/microsoft/vcpkg/issues/37197 [1] https://github.com/microsoft/vcpkg/pull/37199
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#427Earlier quoted context omitted.
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.
I think you have to take the credibility of the maintainer into account. If it's a large company, made of people with names and faces, with a lot to lose by hacking its users, they're unlikely to abuse private disclosure. If it's some tiny library, the maintainers might be in on it. Also, if there's evidence of exploitation in the wild, the embargo is a gift to the attacker. The existence of a vulnerability in that c…
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#428Earlier quoted context omitted.
I imagine it might be easier to just compromise a weakly protected account than to actual put in a 2 years long effort with real contributions. If we mandated MFA for all contributors who contribute to these really important projects then we can know with greater certainty if it was really a long con vs. a recently compromised account.
github already mandates MFA for members of important projects
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#429The known unknowns can be better than the unknown unknowns.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#430Earlier quoted context omitted.
I imagine it might be easier to just compromise a weakly protected account than to actual put in a 2 years long effort with real contributions. If we mandated MFA for all contributors who contribute to these really important projects then we can know with greater certainty if it was really a long con vs. a recently compromised account.
I find it funny how MFA is treated as if it would make account takeover suddenly impossible. It's just a bit more work, isn't it? And a big loss in convenience. I'd much rather see passwords entirely replaced by key-based authentication. That would improve security. Adding 2FA to my password is just patching a fundamentally broken system.
All very fair points.