Are the prebuilt binaries affected by xz/liblzma backdoor?

[bionade24]

I tried to investigate, but seems like the static linking doesn't leave any version info behind. From the release date they could have been linked against version 5.6.0, so they may be compromised.

Edit: Also, if you're ever feel you don't have the time or capacity to review a PR thoroughly or want a second view, feel free to tag me.

[mhx]

Thanks for raising this issue!

I literally just read about the incident a few minutes ago. I'm not familiar enough with the details to fully understand if having the malicious code in the prebuilt binaries would even be an issue — as far as I understand, the code checks argv[0] to see if it's sshd that's running in order to do it's work.

Anyhow, the prebuilt binaries have all been built on Ubuntu 23.04 and 23.10, which both use xz-utils 5.4.1. I've recently switched the build pipeline to 24.04, which uses 5.4.5, but I haven't made a release with that pipeline yet.

In fact you can check the versions of (some of) the libraries:

$ mkdwarfs -H
     ___                  ___ ___
    |   \__ __ ____ _ _ _| __/ __|         Deduplicating Warp-speed
    | |) \ V  V / _` | '_| _|\__ \      Advanced Read-only File System
    |___/ \_/\_/\__,_|_| |_| |___/         by Marcus Holland-Moritz

mkdwarfs (v0.9.6 [2024-02-23])
built for x86_64, Linux-5.15.0-94-generic, Clang 17.0.2

[...]

Compression algorithms:
  null     no compression at all
  lzma     LZMA compression (liblzma 5.4.1)
               level=[0..9]
               dict_size=[12..30]
               extreme
               binary={x86,powerpc,ia64,arm,armthumb,sparc}
  zstd     ZSTD compression (libzstd 1.5.5)
               level=[-131072..22]
  lz4      LZ4 compression (liblz4 1.9.4)
  lz4hc    LZ4 HC compression (liblz4 1.9.4)
               level=[0..12]
  brotli   Brotli compression (encoder 1.0.9, decoder 1.0.9)
               quality=[0..11]
               lgwin=[10..30]
  flac     FLAC compression (libFLAC++ 1.4.3)
               level=[0..8]
               exhaustive
  ricepp   RICEPP compression
               block_size=[16..512]
[...]

So you can see that it's linked against version 5.4.1 of xz-utils. dwarfsextract will also show the version of libarchive it has been linked against.

Fingers crossed that pre-5.6.0 versions of xz-utils are actually safe...

[mhx]

Also, it seems the malicious code only sneaks into sshd via systemd libraries — at which point I'm somewhat relieved that the only machines where I had xz-utils v5.6.x installed did not have any systemd code on them.

[bionade24]

argv[0] to see if it's sshd

I've read that too, but long after opening this issue as I focused on the deobfuscated script. Sorry for the false alarm. Additionally, the backdoor would only install if dwarfs was built as a deb or rpm package, not if built with manual cmds or with Arch's makepkg, nix, etc. The reproducible builds from Archlinux apparently prove that the binaries from the 5.6.1 tarball version are identical from the one which now uses the git tag.

In fact you can check the versions of (some of) the libraries

I only checked the dwarfs binary with grep --text and objdump. Checking this now, it doesn't has the version info stored anywhere? Idk if it'd make sense to also include it there, also in hindsight if some algorithm version would ever malfunction on certain hardware. Maybe a notice to mkdwarfs -H in dwarfs -h would suffice without increasing the codebase ?

OT, but maybe it'll help someone:

it seems the malicious code only sneaks into sshd via systemd libraries

It only happens when distros patch sshd with a patch that uses libsystemd to message the systemd-inotify socket, which is not recommended by systemd upstream. They state that you should write you should communicate via the socket interface directly. Archlinux (&maybe nix, Guix, Alpine, don't know) didn't apply this patch and therefor sshd doesn't depend on libsystemd.

[mhx]

Sorry, I'm having a hard time following your train of thought in this paragraph...

I only checked the dwarfs binary with grep --text and objdump. Checking this now, it doesn't has the version info stored anywhere?

Are you asking where mkdwarfs gets the version information from? You can check src/dwarfs/compression/*.cpp and look for the implementation of compression_factory::description(). In case of lzma, it uses lzma_version_string(), for example.

Idk if it'd make sense to also include it there, also in hindsight if some algorithm version would ever malfunction on certain hardware. Maybe a notice to mkdwarfs -H in dwarfs -h would suffice without increasing the codebase ?

I could certainly add the version information to all tools linking against compression libs. The information could even be added as part of the history in a DwarFS image.

[bionade24]

I only checked the dwarfs binary with grep --text and objdump. Checking this now, it doesn't has the version info stored anywhere?

Are you asking where mkdwarfs gets the version information from? You can check src/dwarfs/compression/*.cpp and look for the implementatio

It's badly articulated. I tried to find a version number for lzma in the sbin/dwarfs binary and after not finding any string matching lzma <vnum>. If such metadata gets included by lld/gold during static linking at all, it has surely has been removed in the stripping process. "Checking this now" ment trying to find the library version numbers in dwarfs -{h,H} . Which I was confused about not having the same info as mkdwarfs -H first, as I believed you picked mkdwarfs -H arbitrarily and -H would work on all dwarfs binaries.

I could certainly add the version information to all tools linking against compression libs. The information could even be added as part of the history in a DwarFS image.

If there isn't any reason why it's only in mkdwarfs now, I'd consider this a good idea.

[mhx]

I could certainly add the version information to all tools linking against compression libs. The information could even be added as part of the history in a DwarFS image.

If there isn't any reason why it's only in mkdwarfs now, I'd consider this a good idea.

Done. As of the next release, all tools will display relevant dependencies, e.g.:

$ dwarfs                                                     
     ___                  ___ ___
    |   \__ __ ____ _ _ _| __/ __|         Deduplicating Warp-speed
    | |) \ V  V / _` | '_| _|\__ \      Advanced Read-only File System
    |___/ \_/\_/\__,_|_| |_| |___/         by Marcus Holland-Moritz

dwarfs (v0.9.6-19-g146c39fe70 on branch mhx/work [2024-04-01], fuse version 35)
built for x86_64, Linux-6.1.46-gentoo-dist, Clang 18.1.2

using: FLAC++-1.4.3, brotlidec-1.1.0, brotlienc-1.1.0, crypto-3.0.13, fmt-10.2.1,
       lz4-1.9.4, lzma-5.4.2, xxhash-0.8.2, zstd-1.5.6

Usage: dwarfs <image> <mountpoint> [options]
[...]

Also, mkdwarfs will store these dependencies in the filesystem image as part of the history (unless this feature is disabled). This can then be read by dwarfsck:

$ dwarfsck test.dwarfs -j | jq '.history[].library_versions'
[
  "FLAC++-1.4.3",
  "brotlidec-1.1.0",
  "brotlienc-1.1.0",
  "crypto-3.0.13",
  "fmt-10.2.1",
  "lz4-1.9.4",
  "lzma-5.4.2",
  "xxhash-0.8.2",
  "zstd-1.5.6"
]