A backdoor in xz

Posted Mar 29, 2024 19:26 UTC (Fri) by zblaxell (subscriber, #26385)
Parent article: A backdoor in xz

The "script to detect if it's likely that the ssh binary on a system is vulnerable" is some disturbing shell code.

It keeps calling eval on unique (and therefore unset?) variable names. It's moving strings between variable names in the middle, making it harder to read. It's making a whole lot of changes to src/liblzma/Makefile which it doesn't seem to ever use, some of which introduce code that ends in "| $(SHELL)".

If someone showed me the git commits and the detection script and said "one of these contains a trojan, you have ten minutes to decide which"...I'd pick the detection script. Is there a less obfuscated version?

A backdoor in xz

Posted Mar 29, 2024 19:33 UTC (Fri) by rwmj (subscriber, #5474) [Link]

Are you looking at the right script? You seem to be describing the injection script (written by the attacker). The detection script is just a fancy hexdump | grep.

A backdoor in xz

Posted Mar 29, 2024 19:34 UTC (Fri) by willmo (subscriber, #82093) [Link]

I don't think LWN processed the attachments correctly. See https://www.openwall.com/lists/oss-security/2024/03/29/4

A backdoor in xz

Posted Mar 29, 2024 19:39 UTC (Fri) by daroc (editor, #160859) [Link] (11 responses)

Unfortunately, the way that the site code handles attachments on mailing list items is a bit flawed, and currently only displays some of the attachments. It's on my list now to look into. I think you were looking at the backdoored m4 script, which is the first attachment on the message. The actual detection script looks like this:

#! /bin/bash

set -eu

# find path to liblzma used by sshd
path="$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')"

# does it even exist?
if [ "$path" == "" ]
then
	echo probably not vulnerable
	exit
fi

# check for function signature
if hexdump -ve '1/1 "%.2x"' "$path" | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410
then
	echo probably vulnerable
else
	echo probably not vulnerable
fi

Which I think you'll agree is much more readable.

A backdoor in xz

Posted Mar 29, 2024 21:45 UTC (Fri) by zblaxell (subscriber, #26385) [Link] (2 responses)

Wow...so today I get to add to my collection of "mail filtering/transformation worst-case outcomes" examples! In the LWN version, the text reads:

== Detecting if installation is vulnerable ==

Vegard Nossum wrote a script to detect if it's likely that the ssh binary on a
system is vulnerable, attached here. Thanks!


Greetings,

Andres Freund
P="-fPIC -DPIC -fno-lto -ffunction-sections -fdata-sections"
C="pic_flag=\" $P\""
O="^pic_flag=\" -fPIC -DPIC\"$"
R="is_arch_extension_supported"
[...]

so I'm thinking "OK, so it's attached here", not "this mailing list archive software dumps random text from a bunch of extremely heterogenous MIME parts into the message body without any markup indicating boundaries between sections."

Given the sensitivity, can that be fixed on the LWN archive before someone else makes the same mistake?

Attachment rendering

Posted Mar 29, 2024 22:09 UTC (Fri) by corbet (editor, #1) [Link] (1 responses)

Is it better now? That code has always sort of punted on attachments, I've tried to make it just a little bit less hackish.

Attachment rendering

Posted Mar 29, 2024 23:01 UTC (Fri) by zblaxell (subscriber, #26385) [Link]

Much better! The filenames really make all the difference in this case. Even without them, there are now two visible scripts on the page, and it's not hard to see which is the evil one.

Thanks!

A backdoor in xz

Posted Mar 30, 2024 9:00 UTC (Sat) by geuder (subscriber, #62854) [Link] (3 responses)

The script runs ldd on an untrusted binary. That itself can lead to code execution if the binary is suitably manipulated.

A backdoor in xz

Posted Mar 30, 2024 9:07 UTC (Sat) by geuder (subscriber, #62854) [Link] (2 responses)

Oops, I might have commented too fast.

sshd is not compromised (at least not by the issue discussed here...), a library it loads is.

I am not sure whether an attack (executing arbitrary code) using ldd needs to start in the main executable or whether it would also work in a shared library used by that executable.

A backdoor in xz

Posted Mar 30, 2024 14:04 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

ldd opens each referenced library, but only to read the ELF header (to find recursive dependencies, I assume).

Thus, unless the build process manages to create a library with a corrupted ELF header that exploits a bug in ldd (which this one doesn't seem to do) the detection script is safe to run.

A backdoor in xz

Posted Mar 30, 2024 14:49 UTC (Sat) by geuder (subscriber, #62854) [Link]

Yes. The risk I remembered is described in https://catonmat.net/ldd-arbitrary-code-execution.

It involves using a different loader, but the loader is specified by the main executable. Shared libraries cannot bring in their own one (AFAIK...).

A backdoor in xz

Posted Mar 30, 2024 14:56 UTC (Sat) by fghorow (subscriber, #5229) [Link] (2 responses)

I just ran into a case where hexdump was not available on the machine being tested. The script complained about that, but printed the "probably not vulnerable" result anyway. Rather than trying to correct the script and open up another can of worms, please just use common sense when interpreting the output of this script.

A backdoor in xz

Posted Mar 31, 2024 16:01 UTC (Sun) by vegard (subscriber, #52330) [Link] (1 responses)

Yes, sorry -- it was hacked up in a couple of hours in anticipation of the report going live. The script was tested by 3-4 people in private before it got posted, but it obviously had some flaws. It was also meant for advanced users, in a way (think organizations or system administrators who can adapt it to their systems, not necessarily end users). I felt it was better to keep the script short and readable as opposed to trying to adapt it to every possible configuration, as that would have made it harder trust (as in: here's yet another shell script doing who-knows-what...).

A backdoor in xz

Posted Mar 31, 2024 16:05 UTC (Sun) by fghorow (subscriber, #5229) [Link]

My comment was made as a "heads up" and it was not intended as criticism of your script.

You absolutely made the right call in keeping it simple, IMHO. Thank you.

A backdoor in xz

Posted Mar 30, 2024 18:20 UTC (Sat) by kreijack (guest, #43513) [Link]

> # find path to liblzma used by sshd
> path="$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')"

> # does it even exist?
> if [ "$path" == "" ]
> then
> echo probably not vulnerable
> exit
> fi
[...]

$(which sshd) returns "" IF not run as root...

In this case the message should be "Cannot find 'sshd'" and not be a "probably not vulnerable"

A backdoor in xz

Posted Mar 29, 2024 19:39 UTC (Fri) by kleptog (subscriber, #1183) [Link]

What you're looking at there *is* the injected shell code. I think you see it because as an artifact of the LWN archive.

If you look at the Openwall archive (https://www.openwall.com/lists/oss-security/2024/03/29/4) you'll see the first attachment is the injected code you see above, the second is a binary attachment and the actual detection script is the third, but doesn't appear in the LWN copy of the email.