Thanks. Yeah, below I learned the '####Hello####' string to be present in the "bad test file" (I haven't seen it myself). I was just not expecting a "binary" file to be basically a text file and thought the `grep` was matching post extraction somehow. That's the root of my confusion. I do understand now where the file gets localized.
IIRC only the "binary" files where added secretly, right? But the build script was there for people to inspect? If so, I have to say, it's not that obfuscated, to someone who actually knew .m4, I guess. At least the grep line should have raised the question of why. I think, part of the problem is normalization of arcane, cryptic scripts in the first place, where people sign off on things they don't fully understand in the moment, since - c'mon - "knowledge" of these old gibberish scripting languages only lives transiently between Google searches and your working memory.
Without looking it up, can you tell me what this does in bash: `echo $(. /tmp/file)` ?
I think, I've seen at least one "xz backdoor detection script" by "someone trusted" in one of the xz threads here, which was at least as cryptic as the .m4 script, containing several `eval`s. I mean, you could probably throw your head onto the keyboard and there is a good chance it's valid bash or regex, or at least common bash can be indiscernible from random gibberish until you manually disassemble it, feeling smuck and dopaminergic. The condensed arcane wizardry around Linux (bash, autotools, CMake, ...) and C (macros, single letter variable culture, ...) is really fun in a way, but it's such a huge vulnerability in itself, before we even talk memory safety.
> IIRC only the "binary" files where added secretly, right? But the build script was there for people to inspect?
Yes, but it is important to note that these malicious m4 scripts were only present in the tar file. They were not checked into the git repo, which is why distros that actually built from git were not affected.
Totally agree with the problem of cryptic scripts in the build process, but unfortunately, if you maintain a project that needs to support a ton of different platforms, you don't have that much choice in your build tools. Pretty much everyone agrees that the 'autoconf soup' and its tooling (essentially m4, perl, shell, make) are all horrible from a readability perspective, and the amount of people who know these tools and can review changes is getting smaller, but switching to a more modern build system often times means dropping support for some platforms.
> Yes, but it is important to note that these malicious m4 scripts were only present in the tar file.
Looks like I got it backwards then. I thought, the test-files where the sneaky addition. Guess nobody cared for them...
> if you maintain a project that needs to support a ton of different platforms, you don't have that much choice in your build tools
Yeah, but, if possible, we could start porting those things into better frameworks instead of adding new features to this problematic Linux legacy code base. And maybe we could also retro-fix some of it with a better meta-layer, which generates the problematic code verbosely and standardized. If it can be done for JS, it can be done for the *nix ecosystem.
Lastly, part of it is culturally, too. Some people seem to get a kick out of reduced, arcane code, instead of expressive "prose". See, my example above... why the fuck is dot a shortcut for `source`?! Btw. I stumbled into this in Docker documentation[1]:
IIRC only the "binary" files where added secretly, right? But the build script was there for people to inspect? If so, I have to say, it's not that obfuscated, to someone who actually knew .m4, I guess. At least the grep line should have raised the question of why. I think, part of the problem is normalization of arcane, cryptic scripts in the first place, where people sign off on things they don't fully understand in the moment, since - c'mon - "knowledge" of these old gibberish scripting languages only lives transiently between Google searches and your working memory.
Without looking it up, can you tell me what this does in bash: `echo $(. /tmp/file)` ?
I think, I've seen at least one "xz backdoor detection script" by "someone trusted" in one of the xz threads here, which was at least as cryptic as the .m4 script, containing several `eval`s. I mean, you could probably throw your head onto the keyboard and there is a good chance it's valid bash or regex, or at least common bash can be indiscernible from random gibberish until you manually disassemble it, feeling smuck and dopaminergic. The condensed arcane wizardry around Linux (bash, autotools, CMake, ...) and C (macros, single letter variable culture, ...) is really fun in a way, but it's such a huge vulnerability in itself, before we even talk memory safety.
reply