Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

421–430 of 1001 posts

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#421
post #47

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…

Yeah this was my first thought too. Though I think the case against autoconf is already so overwhelming I think anyone still using it is just irredeemable; this isn't going to persuade them.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#422
post #408
post #400

"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.

Lasse Collin the contributor is findable, especially if you add "tukaani" to the search. But not in any other context, unless that's what old jazz musicians do in their retirement.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#423
post #42

Very 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…

Github accounts of both xz maintainers have been suspended.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#424

I 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…

A quote from... your arse?

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#425
post #228

I 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.

Yet here I am, getting up every morning and getting dressed and tying my shoes all by myself, and then maintaining a small number of servers that have openssh on them!

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

#426

Out 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

OMG: look at the other contributions. He is trying to take over projects and pushing some change to sha256 in a hundred projects.

Example: https://github.com/duesee/imap-flow/issues/96

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#427
post #258

Earlier 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…

In this case the maintainer is the one who deliberately introduced the backdoor. As Andres Freund puts it deadpan, "Given the apparent upstream involvement I have not reported an upstream bug."

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#428

Earlier 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

Doesn't it mandate it for everyone? I don't use it anymore and haven't logged in since forever, but I think I got a series of e-mails that it was being made mandatory.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#429
Looking at how many requests to update to the backdoored version have been made, I wonder if the fact that many people (including developers) have been conditioned to essentially accept updates as "always-good" is a huge contributing factor in how easy it is to spread something like this.

The known unknowns can be better than the unknown unknowns.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#430

Earlier 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.

yeah someone replied to one of my comments about adding MFA that an attacker can get around all that simply by buying the account from the author. I was way too narrowly focused on the technical aspects and was completely blind to other avenues like social engineering, etc.

All very fair points.

Post reply on HN