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

441–450 of 1001 posts

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

#441

Post by woodruffw »

progbits wrote: post #413
PedroBatista wrote: post #77

Given the recent ( not so recent ) attacks/"bugs" I feel there is a need to do more than the already hard task of investigating and detecting attacks but also to bring IRL consequences to these people. My understanding is that right now it's pretty much a name and shame of people who most of the time aren't even real "people" but hostile agents either working for governments or criminal groups ( or both ) Getting pun…

> Getting punched in the face is actually a necessary human condition for a healthy civilization. Aside from signed commits, we need to bring back GPG key parties and web of trust. When using a project you would know how many punches away from the committers you are.

PGP is more famous for "web of trust" topologies, not chains of trust.

For all of their nerd cred, key parties didn't accomplish very much (as evidenced by the fact that nothing on the Internet really broke when the WoT imploded a few years ago[1]). The "real" solution here is mostly cultural: treating third-party software like the risky thing it actually is, rather than a free source of pre-screened labor.

[1]: https://inversegravity.net/2019/web-of-trust-dead/

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

#442

Post by JaDogg »

leosanchez wrote: post #382
returningfory2 wrote: post #305

Another interesting data point: about 2 years ago there was a clear pressure campaign to name a new maintainer: https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.h... At the time I thought it was just rude, but maybe this is when it all started.

How many people are involved in this ?

Good cop bad cop play maybe.

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

#443

Post by dmarto »

Kinda relevant, as I saw few comments about how safer languages are the solution.

Here[0] is a very simple example, that shows how easy such supply chain attacks are in Rust; and lets not forget that there was a very large python attack just a few days ago[1].

[0] - https://github.com/c-skills/rust1

[1] - https://checkmarx.com/blog/over-170k-users-affected-by-attac...

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

#444

Post by Avamander »

wood_spirit wrote: post #124

A lot of eyes will be dissecting this specific exploit, and investigating this specific account, but how can we find the same kind of attack in a general way if it’s being used in other projects and using other contributor names?

More reproducible builds, maybe even across distributions? Builds based on specific commits (no tarballs like in this case), possibly signed (just for attribution, not for security per se)? Allow fewer unsafe/runtime modifications The way oss-fuzz ASAN was disabled should've been a warning on its own, if these issues weren't so common.

I'm not aware of any efforts towards it, but libraries should also probably be more confined to only provide intended functionality without being able to hook elsewhere?

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

#445

Post by Almondsetat »

Johnny555 wrote: post #331
port443 wrote: post #313

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…

Isn't that still a "bad actor" even if they are coerced into it?

"bad actor" doesn't mean "bad faith", it's not a value judgement

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

#446

Post by chrononaut »

mikolajw wrote: post #349

Tukaani website states "jiatan" as the nickname of the malicious code committer on Libera Chat. WHOWAS jiatan provided me the following information: jiatan ~jiatan 185.128.24.163 * :Jia Tan jiatan 185.128.24.163 :actually using host jiatan jiatan :was logged in as jiatan tungsten.libera.chat :Fri Mar 14:47:40 2024 WHOIS yields nothing, the user is not present on the network at the moment. Given that 185.128.24.163 is…

> it appears this is a proxy.

Yes, that IP address appears associated with witopia[.]net, specifically vpn.singapore.witopia[.]net points to that IP address.

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

#447

Post by mysidia »

ptx wrote: post #168
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…

Couldn't the autoconf soup be generated from simpler inputs by the CI/CD system to avoid this kind of problem? Incomprehensible soup as a build artifact (e.g. executables) is perfectly normal, but it seems to me that such things don't belong in the source code. (This means you too, gradle-wrapper! And your generated wrapper for your generated wrapper. That junk is not source code and doesn't belong in the repo.)

The other thing besides the autoconf soup is the XZ project contains incomprehensible binaries as "test data"; the "bad-3-corrupt_lzma2.xz" part of the backdoor that they even put in the repo.

It's entirely possible they could have got that injection through review, even if they had that framwork and instead put it in source files used to generate autoconf soup.

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

#449

Post by amluto »

formerly_proven wrote: post #132
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…

I think this has been in the making for almost a year. The whole ifunc infrastructure was added in June 2023 by Hans Jansen and Jia Tan. The initial patch is "authored by" Lasse Collin in the git metadata, but the code actually came from Hans Jansen: https://github.com/tukaani-project/xz/commit/ee44863ae88e377... > Thanks to Hans Jansen for the original patch. https://github.com/tukaani-project/xz/pull/53 There were…

Wow, what a big pile of infrastructure for a non-optimization.

An internal call via ifunc is not magic — it’s just a call via the GOT or PLT, which boils down to function pointers. An internal call through a hidden visibility function pointer (the right way to do this) is also a function pointer.

The even better solution is a plain old if statement, which implements the very very fancy “devirtualization” optimization, and the result will be effectively predicted on most CPUs and is not subject to the whole pile of issue that retpolines are needed to work around.

Post reply on HN