6 ms·
That's completely crazy, the backdoor is introduced through a very cryptic addition to the configure script. Just looking at the diff, it doesn't look malicious
by asveikau 3y ago
That's completely crazy, the backdoor is introduced through a very cryptic addition to the configure script. Just looking at the diff, it doesn't look malicious at all, it looks like build script gibberish.
- zb3 3y agoYeah, now imagine they succeeded and it didn't cause any performance issues... Can we even be sure no such successful attempt has already been made?
- agwa 3y agoThanks to autoconf, we're now used to build scripts looking like gibberish. A perfect place to hide a backdoor.
- rwmj 3y agoThis is my main take-away from this. We must stop using upstream configure and other "binary" scripts. Delete them all and run "autoreconf -fi" to recreate them. (Debian already does something like this I think.)
- anthk 3y agoI always run autoreconfig -ifv first.
- cesarb 3y ago> We must stop using upstream configure and other "binary" scripts. Delete them all and run "autoreconf -fi" to recreate them. I would go further than that: all files which are in a distributed tarball, but not on the corresponding git repository, should be treated as suspect. Distributing these generated autotools files is a relic of times when it could not be expected that the target machine would have all the necessary development environment pieces. Nowadays, we should be able to assume that whoever wants to compile the code can also run autoconf/automake/etc to generate the build scripts from their sources. And other than the autotools output, and perhaps a couple of other tarball build artifacts (like cargo simplifying the Cargo.toml file), there should be no difference between what is distributed and what is on the repository. I recall reading about some project to find the corresponding commit for all Rust crates and compare it with the published crate, though I can't find it right now; I don't know whether there's something similar being done for other ecosystems.
- nolist_policy 3y agoOne small problem with this is that autoconf is not backwards-compatible. There are projects out there that need older autoconf than distributions ship with.
- rwmj 3y agoThere are, and they need to be fixed.
- cesarb 3y agoThe test code generated by older autoconf is not going to be work correctly with newer GCC releases due to the deprecation of implicit int and implicit function declarations (see https://fedoraproject.org/wiki/Changes/PortingToModernC https://fedoraproject.org/wiki/Changes/PortingToModernC), so these projects already have to be updated to work with newer autoconf.
- badsectoracula 3y agoTyping `./configure` wont work but something like `./configure CFLAGS="-Wno-error=implicit-function-declaration"` (or whatever flag) might work (IIRC it is possible to pass flags to the compiler invocations used for checking out the existence of features) without needing to recreate it. Also chances are you can shove that flag in some old `configure.in` and have it work with an old autoconf for years before it having to update it :-P.
- nicolas_17 3y agoThe backdoor is in an .m4 file that gets parsed by autoconf to generate the configure script. Running autoconf yourself won't save you.
- rwmj 3y agoThat's not entirely true. autoreconf will regenerate m4/build-to-host.m4 but only if you delete it first.
- tobias2014 3y agoIt seems like this was the solution for archlinux, pull directly from the github tag and run autogen: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad https://gitlab.archlinux.org/archlinux/packaging/packages/xz...
- 1oooqooq 3y agoit's shocking how many packages on distros are just one random tarball from the internet with lipstick
- k8svet 3y agoOh come on, please, let's put autotools out to pasture. I've lost so much of my life fighting autotools crap compared to "just use meson".
- account42 3y agoAs long as we also exterminate it's even more evil brother - libtool.
- snnn 3y agoI don't think it would help much. I work on machine learning frameworks. A lot of them(and math libraries) rely on just in time compilation. None of us has the time or expertise to inspect JIT-ed assembly code. Not even mentioning that much of the code deliberately read/write out of bound, which is not an issue if you always add some extra bytes at the end of each buffer, which could make most memory sanitizer tools useless. When you run their unit tests, you run the JIT code, then a lot of things could happen. Maybe we should ask all packaging systems splitting their build into compile and test two stages, to ensure that a testing code would not impact the binaries that are going to be published. I would rather to read and analysis the generated code instead of the code that generates it.
- demizer 3y agoMaybe the US Government needs to put its line in the sand and mandate the end of autotools. :D
- resonious 3y agoIt looks like they are trying to get rid of C, so maybe in luck!
- pornel 3y agoMaybe it's time to dramatically simplify autoconf? How long do we need to (pretend to) keep compatibility with pre-ANSI C compilers, broken shells on exotic retro-unixes, and running scripts that check how many bits are in a byte?
- hgs3 3y agoAutoconf is m4 macros and Bourne shell. Most mainstream programming languages have a packaging system that lets you invoke a shell script. This attack is a reminder to keep your shell scripts clean. Don't treat them as an afterthought.
- hypnagogic 3y agoI'm wondering is there i.e. no way to add an automated flagging system that A/B / `diff` checks the tarball contents against the repo's files and warns if there's a mismatch? This would be on i.e. GitHub's end so that there'd be this sort of automated integrity test and subsequent warning? Just a thought, since tainted tarballs like these might be altogether be (and become) a threat vector, regardless of the repo.
- phendrenad2 3y agoNot just autoconf. Build systems in general are a bad abstraction, which leads to lots and lots of code to try to make them do what you want. It's a sad reality of the mismatch between a prodecural task (compile files X, Y, and Z into binary A) and what we want (compile some random subset of files X, Y, and Z, doing an arbitrary number of other tasks first, into binary B). For fun, you can read the responses to my musing that maybe build systems aren't needed: https://news.ycombinator.com/item?id=35474996 https://news.ycombinator.com/item?id=35474996 (People can't imagine programming without a build system - it's sad)
- omoikane 3y agoIt looks like an earlier commit with a binary blob "test data" contained the bulk of the backdoor, then the configure script enabled it, and then later commits patched up valgrind errors caused by the backdoor. See the commit links in the "Compromised Repository" section. Also, seems like the same user who made these changes are still submitting changes to various repositories as of a few days ago. Maybe these projects need to temporarily stop accepting commits until further review is done?
- 20after4 3y ago> "Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system. Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the "fixes" mentioned above." Crazy indeed.
- tetromino_ 3y agoA big part of the problem is all the tooling around git (like the default github UI) which hides diffs for binary files like these pseudo-"test" files. Makes them an ideal place to hide exploit data since comparatively few people would bother opening a hex editor manually.
- acdha 3y agoHow many people read autoconf scripts, though? I think those filters are symptom of the larger problem that many popular C/C++ codebases have these gigantic build files which even experts try to avoid dealing with. I know why we have them but it does seem like something which might be worth reconsidering now that the tool chain is considerably more stable than it was in the 80s and 90s.
- bonzini 3y agoHow many people read build.rs files of all the transitive dependencies of a moderately large Rust project? Autoconf is bad in this respect but it's not like the alternatives are better (maybe Bazel).
- bdd8f1df777b 3y agoBazel has its problems but the readability is definitely better. And bazel BUILD files are quite constrained in what it can do.
- acdha 3y agoThe alternatives are _better_ but still not great. build.rs is much easier to read and audit, for example, but it’s definitely still the case that people probably skim past it. I know that the Rust community has been working on things like build sandboxing and I’d expect efforts to be a lot easier there than in a mess of m4/sh where everyone is afraid to break 4 decades of prior usage.
- bonzini 3y agobuild.rs is easier to read, but it's the tip of the iceberg when it comes to auditing. If I were to sneak in some underhanded code, I'd do it through either a dependency that is used by build.rs (not unlike what was done for xz) or a crate purporting to implement a very useful procedural macro...
- ptx 3y agoThe use of "eval" stands out, or at least it should stand out – but there are two more instances of it in the same script, which presumably are not used maliciously. A while back there was a discussion[0] of an arbitrary code execution vulnerability in exiftool which was also the result of "eval". Avoiding casual use of this overpowered footgun might make it easier to spot malicious backdoors. Usually there is a better way to do it in almost all cases where people feel the need to reach for "eval", unless the feature you're implementing really is "take a piece of arbitrary code from the user and execute it". [0] https://news.ycombinator.com/item?id=39154825 https://news.ycombinator.com/item?id=39154825
- bonzini 3y agoUnfortunately eval in a shell script has an effect on the semantics but is not necessary to do some kind of parsing of the contents of a variable, unlike Python or Perl or JavaScript. A $goo line (without quotes) will already do word splitting, though it won't do another layer of variable expansion and unquoting, for which you'll need eval "$goo" (This time with quotes).
- jwilk 3y agoeval in autoconf macros is nothing unusual. In (pre-backdoor) xz 5.4.5: $ grep -wl eval m4/* m4/gettext.m4 m4/lib-link.m4 m4/lib-prefix.m4 m4/libtool.m4
- lyu07282 3y ago> Usually there is a better way to do it in almost all cases where people feel the need to reach for "eval" unfortunately thats just standard in configure scripts, for example from python: ``` grep eval Python-3.12.2/configure | wc -l 165 ``` and its 32,958 lines of code, plenty of binary fixtures as well in the tarball to hide stuff. who knows, but I have feeling us finding the backdoor in this case was more of a happy accident.