News for hackers. Stuff that matters.

A comment on XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable.". Parent comment

Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by ghostpepper on Saturday March 30, 2024 @06:40PM (#39879385)
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.
[ Parent | on HN ]
Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by dist-epoch on Saturday March 30, 2024 @07:36PM (#39879727)
When the backdoor is loaded by sshd it could modify the gcc/clang install, or some system header file.
[ Parent | on HN ]
Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by joeyh on Saturday March 30, 2024 @07:31PM (#39879685)
dpkg-deb is linked with liblzma
[ Parent | on HN ]
Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by slim on Saturday March 30, 2024 @07:13PM (#39879572)
servers hosting gcc binaries are accessed using ssh
[ Parent | on HN ]
Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by xorcist on Sunday March 31, 2024 @12:47PM (#39885805)
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.

[ Parent | on HN ]
Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by Bulat_Ziganshin on Tuesday April 02, 2024 @10:30AM (#39906163)
the installation process itself executes xz scripts which can make any (?) modifications to the system
[ Parent | on HN ]