On Wed, Apr 03, 2024 at 02:01:23AM -0400, Robert Edmonds wrote: > 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.
My understanding of the exploit is that the IFUNC initialization function is run before relocated but read-only sections of the binary in memory are actually made read-only (that is, it's run before relocation is finished). That allows the exploit to overwrite GOT pointers. Arguably, a contructor can still call mprotect and overwrite GOT pointers, so there isn't a major advantage to use IFUNC over a more traditional constructor. I guess there's an advantage in not changing the pattern of syscalls called during library initialization to be more stealthy, but OTOH, Firefox does two mprotect calls per library it loads and nobody opened a bug about that behaviour on bugzilla.mozilla.org in the close to 7 years it's been doing that (and don't worry, that's expected, but also don't look at what Firefox does in unstable because it doesn't do it anymore ; upstream builds still do ; if you're curious about the details, see https://glandium.org/blog/?p=4297). There's an argument to be done that read-only portions of binaries ought to stay read-only (aka forbid mprotect). Mike
