521–530 of 1001 posts
Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.
Warning, drunk brain talking. But a LLM driven email based "collaborator" could play a very long gMw adding basic features to a code made whilst earning trust backed by a generated online presence. My money is on a resurgance in the Web of Trust.
Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.
Probably a state actor. You can look far into the future when you’re working for the party.
Earlier quoted context omitted.
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
> 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.
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.
I'd love to be at Microsoft right now and have the power to review this user's connection history to Github, even though VPN exists, many things can be learned from connection habits, links to ISPs, maybe even guess if VPNs were used, roundtrip time on connections can give hints. I really don't think some random guy wants to weaken ssh just to extract some petty ransomware cash from a couple targets.
Which is why there's probably nothing remotely interesting in them logs.
Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.
Warning, drunk brain talking. But a LLM driven email based "collaborator" could play a very long gMw adding basic features to a code made whilst earning trust backed by a generated online presence. My money is on a resurgance in the Web of Trust.
Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.
Warning, drunk brain talking. But a LLM driven email based "collaborator" could play a very long gMw adding basic features to a code made whilst earning trust backed by a generated online presence. My money is on a resurgance in the Web of Trust.
This is also not a new insight. In the beginning of the naughties, there was a web site named kuro5hin.org, which experiemented with user ratings and trust networks. It turned out impossible to prevent take-overs.
A couple of years ago I wrote a Go library that wraps the xz C code and allows you to do xz compression in Go: https://github.com/jamespfennell/xz About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though.
There was also a bug report in Debian which requested updating xz-utils to 5.6.1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708
I think the lesson here for packagers is that binary testdata should not be present while doing the build. It is too easy to hide things in testdata.
Nice idea, but then you just hide the attack in logo.png that gets embedded in the binary. Less useful for libraries, works plenty good for web/desktop/mobile.