A backdoor in xz

Posted Mar 30, 2024 9:07 UTC (Sat) by geuder (subscriber, #62854)
In reply to: A backdoor in xz by geuder
Parent article: A backdoor in xz

Oops, I might have commented too fast.

sshd is not compromised (at least not by the issue discussed here...), a library it loads is.

I am not sure whether an attack (executing arbitrary code) using ldd needs to start in the main executable or whether it would also work in a shared library used by that executable.

A backdoor in xz

Posted Mar 30, 2024 14:04 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

ldd opens each referenced library, but only to read the ELF header (to find recursive dependencies, I assume).

Thus, unless the build process manages to create a library with a corrupted ELF header that exploits a bug in ldd (which this one doesn't seem to do) the detection script is safe to run.

A backdoor in xz

Posted Mar 30, 2024 14:49 UTC (Sat) by geuder (subscriber, #62854) [Link]

Yes. The risk I remembered is described in https://catonmat.net/ldd-arbitrary-code-execution.

It involves using a different loader, but the loader is specified by the main executable. Shared libraries cannot bring in their own one (AFAIK...).