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

71–80 of 1001 posts

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

#71

Post by sslayer »

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 would be curious if their commits could be analyzed for patterns that could then be used to detect commits from their other account

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

#72

Post by canada_dry »

jeffbee wrote: post #3

Safety through obscurity and weirdness! If you disable ifunc, like any sensible person, this backdoor disables itself.

Is there a way to easily/reliably disable ifunc globally on a system (e.g. ubuntu/debian) without breaking a bunch of things?

FYI this looks for pkgs with liblzma:

> dpkg -l |grep liblzma

Versions >= 5.6 are compromised

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

#73

Post by b112 »

b112 wrote: post #55
AdmiralAsshat wrote: post #52

Yikes! Do you have any info on the individual's background or possible motivations?

Yikes indeed. This fix is being rolled out very fast, but what about the entire rest of the codebase? And scripts? I mean, years of access? I'd trust no aspect of this code until a full audit is done, at least of every patch this author contributed. (note: not referring to fedora here, a current fix is required. But just generally. As in, everyone is rolling out this fix, but... I mean, this codebase is poison in my…

This seems to be the account, correct me if wrong (linked from the security email commit link):

https://github.com/JiaT75

I hope authors of all these projects have been alerted.

STest - Unit testing framework for C/C++. Easy to use by simply dropping stest.c and stest.h into your project!

libarchive/libarchive - Multi-format archive and compression library

Seatest - Simple C based Unit Testing

Everything this account has done should be investigated.

Woha, is this legit or some sort of scam on Google in some way?:

https://github.com/google/oss-fuzz/pull/11587

edit: I have to be missing something, or I'm confused. The above author seems to be primary contact for xz? Have they just taken over?? Or did the bad commit come from another source, and a legit person applied it?

A bit confused here.

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

#74

Post by zb3 »

coding123 wrote: post #68
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…

[flagged]

Not sure why are people downvoting you... it's pretty unlikely that various Chinese IoT companies would just decide it's cool to add a backdoor, which clearly implies that no matter how good their intentions are, they simply might have no other choice.

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

#76

Post by yorwba »

_lvbh wrote: post #22
yogorenapan wrote: post #6

Very strange behavior from the upstream developers. Possible government involvement? I have a feeling LANG is checked to target servers from particular countries

One thing to note is that the person that added the commits only started contributing around late 2022 and appears to have a Chinese name. Might be required by law to plant the backdoor. That would be quite scary considering they have contributed to a wide variety of projects including C++ https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...

I don't think you need to worry about the C++ contribution: https://github.com/MicrosoftDocs/cpp-docs/commit/9a96311122a...

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

#77

Post by PedroBatista »

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 punched in the face is actually a necessary human condition for a healthy civilization.

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

#78

Post by neodypsis »

keepamovin wrote: post #39
lpapez wrote: post #20

So many security companies publishing daily generic blog posts about "serious supply chain compromises" in various distros on packages with 0 downloads, and yet it takes a developer debugging performance issues to find an actual compromise. I worked in the software supply chain field and cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the bl…

If you installed xz on macOS using brew, then you have xz (XZ Utils) 5.6.1 liblzma 5.6.1 which are within the release target for the vuln. As elsewhere in these comments, people say macOS effect is uncertain. If concerned you can revert to 5.4.6 with brew upgrade xz

It's been reverted now: https://github.com/Homebrew/homebrew-core/blob/9a0603b474804...

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

#79

Post by rwmj »

bawolff wrote: post #38

The terrifying part is that this was primarily found because the backdoor was poorly made and causing performance problems. Makes you wonder what more competent actors can do.

I've analysed the backdoor myself and it's very sophisticated, not poorly made at all. The performance problem is surprising in this context, but I think next time they won't make that mistake.

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

#80

Post by bawolff »

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 mean, a backdoor at this scale (particularly if it wasn't noticed for a while and got into stable distros) could be worth millions. Maybe hundreds of millions (think of the insider trading possibilities alone, not to mention espionage). 2 years doesn't seem like that much work relative to the potential pay off.

This is the sort of case where america's over the top hacking laws make sense.

Post reply on HN