Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

Post reply on HN
Print view View original

711–720 of 1001 posts

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

#711

Post by astrange »

dimgl wrote: post #559
jchoksi wrote: post #458

The two active maintainers seem to be: Lasse Collin and Jia Tan Searching DDG for "jiat0218" I came across a blog post which I found weird. Seems to be dated: 2006-05-03 Blog post: "Kuso拍賣．有靈氣的筷子 - 闕小豪" https://char.tw/blog/post/24397301 > Internet Archive link: https://web.archive.org/web/20240329182713/https://char.tw/b... > The contents of the page when translated seems to be about jiat0218 auctioning a pair of sp…

Crazy to think that the time horizon for these kinds of attacks span decades. This absolutely does not read like a coincidence. Chopsticks, little sister, "room to work hard", all sound like codewords.

Do you say that about every word commonly used in Asia?

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

#712

Post by pretzel5297 »

bodyfour wrote: post #240
arp242 wrote: 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…

> 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). Yeah, I've been banging on that same drum for ages too... for example on this very site a decade ago: https://news.ycombinator.com/item?id=7213563 I'm honestly surprised that this autoconf vector hasn't happened more often... or more often that we know of.

Given that this was discovered by sheer luck, I'd expect way more such exploits in the wild.

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

#713

Post by kzrdude »

smeehee wrote: post #246
rwmj wrote: 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…

Debian have reverted xz-utils (in unstable) to 5.4.5 – actual version string is “5.6.1+really5.4.5-1”. So presumably that version's safe; we shall see…

There are suggestions to roll back further

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

#714

Post by dualbus »

crispyambulance wrote: post #198

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?

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

From what I've read, there is still lots of unknowns about the scope of the problem. What has been uncovered so far indicates it involves bypassing authentication in SSH.

In https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b..., Sam James points out

> If this payload is loaded in openssh sshd, the RSA_public_decrypt function will be redirected into a malicious implementation. We have observed that this malicious implementation can be used to bypass authentication. Further research is being done to explain why.

Thus, an attacker maybe could use this to connect to vulnerable servers without needing to authenticate at all.

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

#715

Post by optimalsolver »

rpigab wrote: post #361

I'd love to be at Microsoft right now and have the power to review this user's connection history to Github, even though VPN exists, many things can be learned from connection habits, links to ISPs, maybe even guess if VPNs were used, roundtrip time on connections can give hints. I really don't think some random guy wants to weaken ssh just to extract some petty ransomware cash from a couple targets.

I'm guessing Microsoft just got a call from the Government telling them not to look too deeply into it.

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

#716

Post by frenchman99 »

userbinator wrote: post #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.

Totally agree. With things like Dependabot encouraged by GitHub, people now get automated pull requests for dependency updates, increasing the speed of propagation of such vulnerabilities.

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

#717

Post by syslog »

Epa095 wrote: post #710

I hope Lasse Collin is doing OK! Here is a older message from him [1] "I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see. It's also good to keep in mind that this is an unpaid hobby project. " Gi…

Relevant xkcd:

https://xkcd.com/2347/

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

#718

Post by kzrdude »

Tenobrus wrote: post #135

It 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

In various places they say Lasse Collin is not online right now, but he did make commits a week ago https://git.tukaani.org/?p=xz.git;a=summary

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

#719

Post by bobba27 »

hangonhn wrote: post #255
pfortuny wrote: post #159

Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.

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.

This is a state sponsored event. Pretty poorly executed though as they were tweaking and modifying things in their and other tools after the fact though.

As a state sponsored project. What makes you think this is their only project and that this is a big setback? I am paranoid myself to think yesterdays meeting went like : "team #25 has failed/been found out. Reallocate resources to the other 49 teams."

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

#720

Post by planb »

eigenvalue wrote: post #129
arp242 wrote: 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…

Every single commit this person ever did should immediately be rolled back in all projects.

I don’t thinks that’s necessary: there are enough eyes on this person’s work now.
Post reply on HN