4 ms·
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. Alt
by joeyh 3y ago
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 3y agoHow 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.
- slim 3y agoservers hosting gcc binaries are accessed using ssh
- joeyh 3y agodpkg-deb is linked with liblzma
- dist-epoch 3y agoWhen the backdoor is loaded by sshd it could modify the gcc/clang install, or some system header file.
- xorcist 3y agoTo 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 3y agothe installation process itself executes xz scripts which can make any (?) modifications to the system