Building a backdoored Kernel - Attack vector 2?

Posted Mar 31, 2024 19:21 UTC (Sun) by ma4ris8 (subscriber, #170509)
In reply to: Building a backdoored Kernel - Attack vector 2? by nix
Parent article: A backdoor in xz

You are right : the hash was wrong one for the commit in "xz source code", outside of Kernel source code.
Sorry for the mistake.

Sometimes I have ideas, which prove to be false.
Maybe I'm just trying to think too much, with too little information, what the backdoor code creator attempted to do.

It could be that the Kernel changes in the merge request were not enough to enable the backdoor,
only the sshd side was completed. Also the target Kernel build process, could be something specific (for example specific distribution build environment, which would use "xz" RPM, not one from Kernel, for example).

It is interesting, that between 5.6.0 and 5.6.1 there were "ifunc" changes:
libarchive change was also related with "ifunc".

https://gist.github.com/martenson/398bdb7a928069cf67606c9...
"We're reasonably sure the following things need to be true for your system to be vulnerable:
You need to be running a distro that uses glibc (for IFUNC)
etc.
It may activate in other scenarios too, possibly even unrelated to ssh.
We don't know what the payload is intended to do. We are investigating."

Building a backdoored Kernel - Attack vector 2?

Posted Mar 31, 2024 19:46 UTC (Sun) by nix (subscriber, #2304) [Link]

Yeah, the IFUNC mechanism was abused to force different resolution for symbols in libcrypto (!) as used by openssl. It may be possible to spot and block this abuse, since it seems to me that no legitimate program would ever want to do what the exploit does, but let's not fool ourselves -- if this wasn't present, the exploit would just have done something else. By the time you have hostile code executing in the same address space as sshd before privsep has kicked in, you've lost, IFUNC or no IFUNC.