Linux xv issue, *BSDs are fine

[jmccue]

For people also using Linux, a xv/liblzma backdoor found, info here:

https://gist.github.com/thesamesam/2...e9ee78baad9e27

[Head_on_a_Stick]

The known issue reported under CVE-2024-3094 only affects distributions using the .deb or .rpm packaging format. Of course there may be other backdoors.

[shep]

Arch Linux and likely Derivatives too:

https://archlinux.org/news/the-xz-pa...en-backdoored/

[Head_on_a_Stick]

Arch was never affected by CVE-2024-3094. The upgrade advice is precautionary.

EDIT: reference: https://bbs.archlinux.org/viewtopic.php?id=294363

[Eric]

Awful scary situation.
Some interesting discussion below.
https://news.ycombinator.com/item?id=39877267

[blackhole]

The original mail: https://www.openwall.com/lists/oss-s...y/2024/03/29/4

Original xz author's site: https://tukaani.org/xz-backdoor/

From the OpenBSD mailing list (archive): https://marc.info/?l=openbsd-misc&m=171179460913574&w=2

Write up linked from that post: https://lcamtuf.substack.com/p/techn...he-xz-backdoor

This dependency [on xz/liblzma] existed not because of a deliberate design decision by the developers of OpenSSH, but because of a kludge added by some Linux distributions to integrate the tool with the operating system’s newfangled orchestration service, systemd.

[Head_on_a_Stick]

CVE-2024-3094 is not the entire story — there was a commit that sabotaged sandboxing but it's not used for the known exploit: https://git.tukaani.org/?p=xz.git;a=...58db2c422d9ba7

[jmccue]

Originally Posted by Head_on_a_Stick

CVE-2024-3094 is not the entire story — there was a commit that sabotaged sandboxing but it's not used for the known exploit: https://git.tukaani.org/?p=xz.git;a=...58db2c422d9ba7

Makes me wonder how many other issues exist in Linux.

I think the way BSDs are developed makes these type things harder due to a clear separation between ports and base.

[Eric]

Reminds me of the OpenBSD FBI backdoor scare in 2010.

[blackhole]

Originally Posted by Head_on_a_Stick

CVE-2024-3094 is not the entire story — there was a commit that sabotaged sandboxing but it's not used for the known exploit: https://git.tukaani.org/?p=xz.git;a=...58db2c422d9ba7

Assuming "Jia Tan" is a pseudonym for an individual or more likely a group, then it's by no means easy to trace them, nor indeed what other projects they have made commits to. It's important to note that the individual concerned spent two years infiltrating the project and by all appearances it was meticulously planned and bearing all the hallmarks of state sponsorship - as with most supply chain attacks. I very much doubt this is their one and only attempt nor that it was the only project they were involved in.

My gut instinct would tell me that such backdoors are more prevalent than we imagine and that the Linux kernel and other commonly used software may already have been compromised years ago.

Originally Posted by jmccue

I think the way BSDs are developed makes these type things harder due to a clear separation between ports and base.

It's hard to say... xz-utils was compromised, not because of e.g. an "open" development model or constantly changing team and/or relaxed attitude to who can commit patches - this all came about because of intentional sabotage by an infiltrator, and that could happen to any project developed according to the "cathedral" model, not just "bazaar" projects, and certainly to some proprietary projects as well.

I think the big "why" here - as in why this happened - is not something you can answer or solve overnight, or even in a few years. FLOSS projects come without warranty, are often developed by hobbyists in their own time, for free and there is no way you can impose any rules on said projects, without jeopardizing the pillars of FLOSS and arriving at the unfortunate "only tech companies / Big Tech can be trusted to properly audit code and those individuals contributing to that code" conclusion. Except they can't be trusted either.

This whole debacle also lends a lot of weight to the long standing OpenBSD philosophy of not trusting any of the software you are installing - by default.

[shep]

The time it takes to assemble a sophisticated attack vector is substantial. What I would be concerned with is:
1) Does the malicious code duplicate itself and insert itself into the compressed software?
2) Is the malicious code in other software?

Is it possible to run a script with diff to look for similar code fragments?

[blackhole]

This is more about liblzma and systemd than XZ compression itself or archive files. liblzma is part of XZ utils, but it's an old legacy format not used by XZ for XZ compression.

As a "supply chain" attack, over two to three years, they infiltrated the project, until effectively they were at the level where they were sitting in the chair and to all appearances, proven, trusted and then appointed as their successor by the previous project lead. That was clearly their objective - i.e. to fly under the radar and to give the impression of "business as usual". They would likely have remained in that position for as long as required to carry out their objective(s).

The Linux specific patch to OpenSSH, loads libsystemd and this is in turn how liblzma is loaded.

OpenSSH does not use, liblzma or even libsystemd at all, it's this 3rd party patch to load libsystemd which in turn loads liblzma (for compressing or decompressing log file data??? No idea...) that facilitates it.

So this is, in fact, by all appearances a systemd specific attack - and a Debian (Ubuntu) / Red Hat / SUSE specific attack - and that makes sense, as it's by far the biggest targets and the main enterprise Linux vendors.

The end result would have been a compromised ssh server, via this Linux specific patch, which could have allowed those in the know, back doors into computer systems in the US and elsewhere in the world. We have no idea who carried this out despite all the theorising of bloggers and self appointed experts. If it "bears all the hallmarks of China or Russia", that would only be because whoever were behind this wanted you to think it were China or Russia. That's all you can take away from that. We will probably never know. It could be a nation state sponsored thing, or could be corporate espionage, industrial sabotage, who knows.

[thirdm]

Originally Posted by blackhole

From the OpenBSD mailing list (archive): https://marc.info/?l=openbsd-misc&m=171179460913574&w=2
[/url]

"For the 5.6.0 and 5.6.1 release, the build-to-host.m4 macro package
that ships as part of GNU gettext was replaced by a modified version
that was copied into the release tarball and, importantly, was used
to generate a modified configure script. Let's call this stage 0." (from xz port maintainer email a few messages down the thread).

Why would they leave around the modified build-to-host.m4 file? It's input to autoconf generating configure with an exploit, so why not revert to the proper one once you've got the compromised configure? Would be that much harder to spot, yes?