This backdoor abused the IFUNC mechanism in the GNU toolchain to hook into
the sshd process. Looking on my Debian sid workstation with about 1900 library
packages installed, I see a very small handful of source packages shipping
libraries with IFUNC symbols, mostly things like gcc, glibc, haskell, some Intel
GPU stuff, etc. [0]
I do not know enough about the underlying technology to guess why the attacker
chose to abuse the IFUNC mechanism versus, say, using the ELF .init_array
section to introduce an ordinary initialization function into the backdoor
library. (E.g., putting the equivalent of an __attribute__((constructor))
function in the compiled binary blob part of the backdoor.) Perhaps what the
attacker wanted to do was much easier to implement with the IFUNC mechanism to
the point that it justified the sourceful changes to the upstream repository.
If IFUNC symbols are sufficiently rare and sufficiently powerful, is it
worth implementing some hygiene around their proliferation in Debian? For
instance, something like a Lintian tag combined with an ftpmaster autoreject,
such as what we do for libraries that set RPATH?
[0] A quick and dirty way to check for IFUNC symbols in the libraries installed
on the system:
for fname in /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/*.so.*; do
echo "====> ${fname} <===="
readelf -X -s ${fname} | grep IFUNC
echo
done
--
Robert Edmonds
edmo...@debian.org
