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

261–270 of 1001 posts

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

#261

Post by agwa »

poettering wrote: post #163
agwa wrote: post #8

> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…

Uh. systemd documents the protocol at various places and the protocol is trivial: a single text datagram sent to am AF_UNIX socket whose path you get via the NOTIFY_SOCKET. That's trivial to implement for any one with some basic unix programming knowledge. And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise. I…

> And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise

Could you point out where the man page (https://www.freedesktop.org/software/systemd/man/latest/sd_n...) says this?

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

#263

Post by computerfriend »

buildbot wrote: post #86
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…

In the article it says CISA was notified - that sounds like it's going to be a federal investigation if nothing else. If I was this person, I wouldn't be in the USA (or any US friendly nation) ASAP.

From their Git commits, they're in China's time zone.

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

#264

Post by trulyrandom »

londons_explore wrote: post #185
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?

Note that the malicious binary is fairly long and complex. This attack can be stopped by disallowing any binary testdata or other non-source code to be on the build machines during a build. You could imagine a simple process which checks out the code, then runs some kind of entropy checker over the code to check it is all unminified and uncompressed source code, before finally kicking off the build process. autogener…

This requires a more comprehensive redesign of the build process. Most Linux distributions also run the tests of the project they're building as part of the build process.

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

#265

Post by dandanua »

q3k wrote: post #14

NixOS/Pkgs 23.11 unaffected, unstable contains backdoored implementations (5.6.0, 5.6.1) but their OpenSSH sshd does not seem to link against systemd/liblzma, and the backdoor doesn't get configured in (only happens on .deb/.rpm systems).

That's one of the advantages of NixOS - viruses and mass hacks have lesser chance to function due to how different this OS is. Until it gets more popular, of course.

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

#266

Post by ncr100 »

gmnon wrote: post #224

Funny how Lasse Collin started to ccing himself and Jia Tan from 2024-03-20 (that was a day of tons of xz kernel patches), he never did that before. :) https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...

Also interesting, to me, how the GMail account for the backdoor contributor ONLY appears in the context of "XZ" discussions. Google their email address. Suggests a kind of focus, to me, and a lack of reality / genuineness.

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

#267

Post by wannacboatmovie »

Really disappointed in the number of posters here who are playing down rushing to judgement and suggesting perhaps a legitimate developer was compromised, when it's very clear this is sophisticated and not the work of a single person.

I'm recalling bad memories of the Juniper backdoor years ago.

Whoever did this, was playing the long game. As the top post pointed out, there was an effort to get this into Fedora.... which eventually makes its way into RHEL (read: high value targets). This was not for short term payoffs by some rogue developer trying to mine crypto or other such nonsense. What you are seeing here is the planting of seeds for something months or a year down the road.

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

#268

Post by salawat »

acdha wrote: post #120
tetromino_ wrote: post #69

Earlier quoted context omitted.

A big part of the problem is all the tooling around git (like the default github UI) which hides diffs for binary files like these pseudo-"test" files. Makes them an ideal place to hide exploit data since comparatively few people would bother opening a hex editor manually.

How many people read autoconf scripts, though? I think those filters are symptom of the larger problem that many popular C/C++ codebases have these gigantic build files which even experts try to avoid dealing with. I know why we have them but it does seem like something which might be worth reconsidering now that the tool chain is considerably more stable than it was in the 80s and 90s.

I mean, autoconf is basically a set of template programs for snffing out whether a system has X symbol available to the linker. Any replacement for it would end up morphing into it over time.

Some things are just that complex.

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

#270

Post by andruby »

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.

Hoe will you do that practically though? That’s probably thousands of commits upon which tens or hundred thousand commits from others were built. You can’t just rollback everything two years and expect it not to break or bring back older vulnerabilities that were patched in those commits.
Post reply on HN