[joeyh]

Since a liblzma backdoor could be used to modify compiler packages that are installed on some distributions, it gets right back to a trusting trust attack.

Although initial detection via eg strace would be possible, if the backdoor was later removed or went quiescentit would be full trusting trust territory.

[ghostpepper]

How would this be possible? This backdoor works because lzma is loaded into sshd (by a roundabout method involving systemd). I don't think gcc or clang links lzma.

[dist-epoch]

When the backdoor is loaded by sshd it could modify the gcc/clang install, or some system header file.

[joeyh]

dpkg-deb is linked with liblzma

[xorcist]

To be fair neither does sshd. But I'm sure someone somewhere has a good reason for gcc to write status via journald or something like that? There's however no reason to limit yourself to gcc for a supply chain attack like this.

In any non trivial build system, there's going to be lots of third party things involved. Especially when you include tests in the build. Is Python invoked somewhere along the build chain? That's like a dozen libraries loaded already.

Nothing is gained from protecting against an exact replica of this attack, but from this family of attacks.

[Bulat_Ziganshin]

the installation process itself executes xz scripts which can make any (?) modifications to the system

[slim]

servers hosting gcc binaries are accessed using ssh