Consider pausing use of XZ, LZMA and 7z until the fallout settles

[Moonchild]

So it seems that 7zip has existed longer than xz-utils

Yes it has. 7-zip is what put LZMA on the map. eventually Igor open-sourced 7-zip and that's when FOSS implementations of it took off, including XZ. At least that's my understanding of it, and I've used 7-zip since the beginning; pretty sure xz wasn't at all a thing back then.

[vannilla]

xz's "mainstream" use is actually fairly recent.
I don't know when xz's implementation of LZMA became a systemd dependency (i.e. the target of the attack), but until ten years ago or something very few people actually used xz for compression.
It gained traction because it is legitimately good, but until then it was mostly a niche tool; the library might have had the same fate.

[Bilbo47]

I also got details on how the backdoor exploit worked. On Linux, systemd was mentioned above. Could this particular exploit chain have been possible on Linuxen without systemd? As in, is the systemd hook an example of what the so-called naysayers got worried about back when the push was made to switch all the distros to systemd as a replacement for the previous design for an OS supervisor?

[Moonchild]

As far as I understood the library hijack could be done on any system that uses a run-time linker to tie together binaries and their libs, since the hijack is done through that linker to point to the malicious RSA functions instead of the actual ones. I'm not sure if that's systemd specific or not; it may be a general ELF thing. My knowledge of Linux binaries falls a bit short here, but I wanted to relay at least that bit.

[ron_1]

I'm certainly no expert, but I've been told on another forum that this attack (generally speaking, I think) could have happened without it being linked to systemd. To which I replied, that may be so, but this particular attack wasn't; it was tied to systemd. Since most distros (why?) have switched to the systemd init system, I believe we can expect more attempts at malware via systemd weaknesses.

So in the end I believe my decision to avoid systemd was prudent. That's just my non-expert .02¢ worth.

[Moonchild]

Off-topic:

That's just my non-expert .02¢ worth.

You do realize that that's not 2 cents, right?

[RealityRipple]

Off-topic:
oh god, the Verizon nightmare begins again...

[Moonchild]

It's already been assessed. There is no uncertainty about the situation - it's been clearly analysed and there has not been more fallout than a word of caution about Open Source development and auditing of code changes.

[ron_1]

Off-topic:

You do realize that that's not 2 cents, right?

Okay, 2¢.

[jb_wisemo]

Yes, I know that 7-zip is older than liblzma, indeed, the 7-zip dev invented the LZMA compression method and made it available to others, then the liblzma project forked it to provide a standalone compression library and gzip-like file format.

My concern when I started this thread was that the person (who had gained trust in the liblzma project to insert the back door) might in some way have done the same for 7-zip itself by doing similar social engineering on the 7-zip dev.

At the time, the liblzma main dev had not yet published his post-mortem document about the attack ( https://tukaani.org/xz-backdoor/ ) The writeups now on tukaani.org seem very clear about how the liblzma backdoor was limited to a few places in the project source code, however this says nothing about what the devil behind the "Jia" alias may have done to other projects such as 7-Zip. The 7-Zip web page is completely silent about what happened to liblzma, but does seem to have imported some features from the liblzma project shortly before the backdoor was discovered, though hopefully not anything actually backdoored.

[Moonchild]

The 7-Zip web page is completely silent about what happened to liblzma

That is because none of the actual lzma code was compromised. If you're read the write-ups about it you would have seen that this was a cleverly disguised supply chain hack, not actually even specific to LZMA (aside from it being a lib that is very widely used). Since there was no compromise in the actual lzma/7-zip code, there's nothing to state or clarify. I'm pretty sure Igor would have noticed any backdoors being cherry-picked.
But maybe you didn't fully understand the writeups? Maybe you want to re-read them.

[jb_wisemo]

I fully understood the write-ups and the tactics used to gain trusted commit access to the liblzma repository and download page. While I don't expect the 7z creator to blindly cherry pick the compromised build scripts and faux test files used in the specific attack, this doesn't rule out that the bad actor (using a different fake identity) might have gained similar access to the 7z project, since they seem to have the specific experience needed to contribute plausible changes to lzma-based code, such as the good changes that were accepted and later verified by the liblzma project.

I also note that the 7z project has a weaker security stance than other public projects, such as not signing their releases etc.

(Note: Not using the names of the people as this isn't meant to be a personal attack against anyone, just a call for caution given the recent actual attack against related code).

[Moonchild]

If you're that worried about these kinds of attacks then you really shouldn't be using any FOSS that has an open collaboration mentality, because anyone could try and do this kind of thing anywhere. It's up to individual project administrations to vet submitted code/commits; that's always been the case.
If you want to be safe from even the possibility of committed code being compromised, then you should only be using fully proprietary (without FOSS dependencies) or at least double-vetted code, or check the source of every piece of software yourself and build everything yourself afterwards.

You can make it as difficult for yourself as you want.

However, I'm not letting that determine for us whether we'd be crippling our release engineering.