News for hackers. Stuff that matters.
Re:Backdoor in upstream xz/liblzma leading to SSH server com... by ui2RjUen875bfFA on Friday March 29, 2024 @06:31PM (#39869715)
those pipe usages are quite suspicious

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...

pipeing into this shell script which now uses "eval"

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...

i guess this will be revisited and removed soon

Re:Backdoor in upstream xz/liblzma leading to SSH server com... by Hackbraten on Friday March 29, 2024 @06:51PM (#39869887)
> pipeing into this shell script which now uses "eval"

I don’t actually see an issue with that `eval`. Why would one consider running `xz` followed by `eval`-ing its output more insecure than just running `xz`? If `xz` wants to do shenanigans with the privileges it already has, then it wouldn’t need `eval`’s help for that.

Re:Backdoor in upstream xz/liblzma leading to SSH server com... by ui2RjUen875bfFA on Friday March 29, 2024 @07:34PM (#39870223)
just take a closer look at the analysis https://www.openwall.com/lists/oss-security/2024/03/29/4

then try to understand the pattern. they backdoored by modifying the build process of packages. now consider the $XZ is also from a backdoored build and the call recognizes in the same way with parameters --robot --version and the shell environment with the hint "xz_wrap.sh" from the piped process. a lot stuff to recognize for the $XZ process that it run as part of a kernel build.

Maybe they put advanced stuff in a backdoored $XZ binary to modify the kernel in a similar way they modified lzma based packages in the build process.

Re:Backdoor in upstream xz/liblzma leading to SSH server com... by Bulat_Ziganshin on Friday March 29, 2024 @10:57PM (#39871444)
because in order to put backdoor into xz executable, you need to infect its sources. and in order to infect the sources, you need to use a similar technique to hide the modification