Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

91–100 of 1001 posts

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

#91

That's completely crazy, the backdoor is introduced through a very cryptic addition to the configure script. Just looking at the diff, it doesn't look malicious at all, it looks like build script gibberish.

The use of "eval" stands out, or at least it should stand out – but there are two more instances of it in the same script, which presumably are not used maliciously.

A while back there was a discussion[0] of an arbitrary code execution vulnerability in exiftool which was also the result of "eval".

Avoiding casual use of this overpowered footgun might make it easier to spot malicious backdoors. Usually there is a better way to do it in almost all cases where people feel the need to reach for "eval", unless the feature you're implementing really is "take a piece of arbitrary code from the user and execute it".

[0] https://news.ycombinator.com/item?id=39154825

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

#92
post #79
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.

Do you have a writeup or any details as to what it does? The logical thing based on this post is that it hooks the SSH key verification mechanism to silently allow some attacker-controlled keys but I wonder if there's more to it?

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

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

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

#94
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…

Name and shame this author. They should never be allowed anywhere near any open projects ever again.

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

#95
post #79
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.

[deleted]

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

#96
post #22

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

No one is being “required by law” to add vulnerabilities, it’s more likely they are foreign agents to begin with.

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

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

So many malicious actors have been caught because they accidentally created a mild annoyance for someone that went on to bird-dog the problem.

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

#99
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…

Ubuntu still ships 5.4.5 on 24.03 (atm).

I did a quick diff of the source (.orig file from packages.ubuntu.com) and the content mostly matched the 5.4.5 github tag except for Changelog and some translation files. It does match the tarball content, though.

So for 5.4.5 the tagged release and download on github differ.

It does change format strings, e.g.

   +#: src/xz/args.c:735
   +#, fuzzy
   +#| msgid "%s: With --format=raw, --suffix=.SUF is required unless writing to stdout"
   +msgid "With --format=raw, --suffix=.SUF is required unless writing to stdout"
   +msgstr "%s: amb --format=raw, --suffix=.SUF és necessari si no s'escriu a la sortida estàndard"
There is no second argument to that printf for example. I think there is at least a format string injection in the older tarballs.

[Edit] formatting

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

#100
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…

Name and shame this author. They should never be allowed anywhere near any open projects ever again.

They might have burnt the reputation built for this particular pseudonym but what is stopping them from doing it again? They were clearly in it for the long run.
Post reply on HN