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

191–200 of 1001 posts

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

#191

Post by ok123456 »

JanisErdmanis wrote: post #128
notyoutube wrote: post #97

Is the solution against such attacks in the future only to scrutinize more, or are there other reasonable options in terms of hardening?

The lesson here seems to not depend on tools written in languages that have complex, obscure build systems and no one is either able or interested to read. Using tools rewritten in Rust, Go or any other languege which resolves dependencies within project seems the only way to do hardening here.

Wouldn't a supply chain attack like this be much worse with Rust and Cargo because of the fact it's not just a single dynamic library that needs to be reinstalled system-wise, but, instead, every binary would require a new release?

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

#192

Post by bombcar »

sslayer wrote: post #71
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

One thing that is annoying is that many open source projects have been getting "garbage commits" apparently from people looking to "build cred" for resumes or such.

Easier and easier to hide this junk in amongst them.

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

#193

Post by tobias2014 »

rwmj wrote: post #49
agwa wrote: post #18

Earlier quoted context omitted.

Thanks to autoconf, we're now used to build scripts looking like gibberish. A perfect place to hide a backdoor.

This is my main take-away from this. We must stop using upstream configure and other "binary" scripts. Delete them all and run "autoreconf -fi" to recreate them. (Debian already does something like this I think.)

It seems like this was the solution for archlinux, pull directly from the github tag and run autogen: https://gitlab.archlinux.org/archlinux/packaging/packages/xz...

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

#194

Post by dralley »

b112 wrote: post #43
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…

One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity. Yes, there are things delivered with that complexity. However, as an example, sysvinit is maybe, oh, 20k lines of code including binaries, heck including all core init scripts. What's systemd? 2M lines? It was >1M lines 4+ years ago. For an init syste…

This is a bit like complaining that the Linux kernel has 30 million lines of code, while ignoring that 3/4 of that is in hardware support (drivers) or filesystems that nobody is actually required to use at any given time.

systemd is a collection of tools, one of which is an init system. Nobody accused GNU yes of being bloated just because it's in a repository alongside 50 other tools.

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

#196

Post by [deleted] »

bonyt wrote: post #48

For those panicking, here are some key things to look for, based on the writeup: - A very recent version of liblzma5 - 5.6.0 or 5.6.1. This was added in the last month or so. If you're not on a rolling release distro, your version is probably older. - A debian or RPM based distro of Linux on x86_64. In an apparent attempt to make reverse engineering harder, it does not seem to apply when built outside of deb or rpm p…

[deleted]

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

#197

Post by bombcar »

Bromeo wrote: post #123
returningfory2 wrote: post #93

A couple of years ago I wrote a Go library that wraps the xz C code and allows you to do xz compression in Go: https://github.com/jamespfennell/xz About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though.

I don't want to read too much into it, but the person (supposedly) submitting the PR seems to work at 1Password since December last year, as per his Linkedin. (And his Linkedin page has a link to the Github profile that made the PR).

If I were trying to compromise supply chains, getting into someplace like 1Password would be high up on the list.

Poor guy, he's probably going to get the third degree now.

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

#198

Post by crispyambulance »

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?

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

#200

Post by klysm »

JanisErdmanis wrote: post #128
notyoutube wrote: post #97

Is the solution against such attacks in the future only to scrutinize more, or are there other reasonable options in terms of hardening?

The lesson here seems to not depend on tools written in languages that have complex, obscure build systems and no one is either able or interested to read. Using tools rewritten in Rust, Go or any other languege which resolves dependencies within project seems the only way to do hardening here.

People are going to be upset with this perspective but I completely agree. The whole autoconf set of tools is a complete disaster.
Post reply on HN