Building a backdoored Kernel - Attack vector 2?

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

1fc6e7dd1fa 2022-11-07 "liblzma: Include cached memory in reported memusage in threaded decoder. Thanks to Jia Tan." This code caches memory statistics. That could be useful to hide additional memory use from payload management within xz.

The commit with that SHA-1 ID is

xz: Avoid a compiler warning in progress_speed() in message.c.

(The commit you mean is 5e2450c75c.)

Your description is wrong, as far as I can see: it does the opposite, *including* cached usage in the memory limit (which previously excluded it, so memory could exceed the limit arbitrarily much). There is no attempt to cache anything new.

Further, this commit is not in the upstream kernel at all, nor in anything that has been submitted to the kernel as far as I can see (unsurprisingly, given that the kernel's xz decoder is *much* simpler than liblzma's and isn't even from the same project, but rather from XZ Embedded, which has barely been touched for years: its last non-Itanium-removal commit predates Jia Tan's involvement, thank goodness).

Building a backdoored Kernel - Attack vector 2?

Posted Mar 31, 2024 19:21 UTC (Sun) by ma4ris8 (subscriber, #170509) [Link] (1 responses)

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.