3 ms·

No, the attack was not hidden in code that is autogenerated by autotools. If that was the case, rerunning autoconf (which most distros do) would have disabled t

No, the attack was not hidden in code that is autogenerated by autotools. If that was the case, rerunning autoconf (which most distros do) would have disabled the attack. Instead it was hidden in plain sight in the source that is processed by autoconf. > it's expected to have the generated executable of the build system "helpfully" packaged in the tarball as a packaging step. While this is true, most distros as I mentioned above rerun autoconf to ensure consistency in the tests and possibly to include autoconf bug fixes.

rcxdude 3y ago
The jumping off point was modified autotools output. re-running autogen did effectively disable the attack. The payload was stashed in some test files, but the build system needed to jump through quite some hoops to actually get that into the compiled library. Apparently the target distributions didn't re-run autogen for this package.
- masfuerte 3y ago
  This is what the early reporting said but the article has additional info. The code to include the backdoor in the build was in an m4 script. The initial reporting said that this code was not present in the github source, but the post-autogen code (including the attack) was included in the github releases. The article says that this modified script was present in the source on tukaani.org, which was controlled by the attacker and used by the distros as their upstream. If you downloaded from github and reran autogen you were OK. If you downloaded from tukaani and reran autogen, like the distros did, you lost.
- deleted 3y ago
  [deleted]
- markhahn 3y ago
  merely keeping build and test environments isolated would have entirely prevented this attack. better hygeine that way would also simplify both environments, since the tools for each are fairly different.
  - bonzini 3y ago
    How are they different? Both use make and the C compiler. xz is not different in this respect from any other C, C++, Go or Rust program.
kimixa 3y ago
the "build-to-host.m4" file seems to originally be from gnulib, and if that is installed on the system is not required by the build. So I see that as "part of the build system" myself. I mean the github repository with exactly the same .ac and .am files works fine with local automake/autoconf generation without that file existing. And thus no backdoor (the test files are still there, but "harmless" without the initial kicking off point to actually de-obfuscate and include their contents)
- bonzini 3y ago
  Gnulib is not installable, it is meant to be copied (aka vendored) in the sources of the program that use it. > if that is installed on the system is not required by the build This specific file defines a macro that is used by autoconf, not by the build. If it is installed on the system it is not required by autoconf, but then gnulib is practically never installed. Your original message blamed the backdoor on "the generated executable". This m4 file is not a generated file and not an executable. It is simply vendoring like you often see in other languages.
  - kimixa 3y ago
    I think it was more "hiding" as vendored code rather than really being in that category. The git repo never contained that "vendoring", as the m4/gettext.m4 file doesn't exist autoreconf just copies one from a system store, (which on my machine never calls the tainted BUILD_TO_HOST macros in the first place, which also doesn't exist in the upstream xz git repo). "Vendoring" by copying untracked files into the tarball seems discourteous to the definition. It seems to rely on the "possibly odd" behavior of autoreconf to allow files that happen to have the same name to override system-installed versions? I guess on the belief that local definitions can override them is useful? But that certainly bit them in the ass here. As to get a "completely" clean autoconf rebuild it looks like you have to delete matching files manually.

rcxdude 3y ago

The jumping off point was modified autotools output. re-running autogen did effectively disable the attack. The payload was stashed in some test files, but the build system needed to jump through quite some hoops to actually get that into the compiled library. Apparently the target distributions didn't re-run autogen for this package.

masfuerte 3y ago
This is what the early reporting said but the article has additional info. The code to include the backdoor in the build was in an m4 script. The initial reporting said that this code was not present in the github source, but the post-autogen code (including the attack) was included in the github releases. The article says that this modified script was present in the source on tukaani.org, which was controlled by the attacker and used by the distros as their upstream. If you downloaded from github and reran autogen you were OK. If you downloaded from tukaani and reran autogen, like the distros did, you lost.
deleted 3y ago
[deleted]
markhahn 3y ago
merely keeping build and test environments isolated would have entirely prevented this attack. better hygeine that way would also simplify both environments, since the tools for each are fairly different.
- bonzini 3y ago
  How are they different? Both use make and the C compiler. xz is not different in this respect from any other C, C++, Go or Rust program.

kimixa 3y ago

the "build-to-host.m4" file seems to originally be from gnulib, and if that is installed on the system is not required by the build. So I see that as "part of the build system" myself. I mean the github repository with exactly the same .ac and .am files works fine with local automake/autoconf generation without that file existing. And thus no backdoor (the test files are still there, but "harmless" without the initial kicking off point to actually de-obfuscate and include their contents)

bonzini 3y ago
Gnulib is not installable, it is meant to be copied (aka vendored) in the sources of the program that use it. > if that is installed on the system is not required by the build This specific file defines a macro that is used by autoconf, not by the build. If it is installed on the system it is not required by autoconf, but then gnulib is practically never installed. Your original message blamed the backdoor on "the generated executable". This m4 file is not a generated file and not an executable. It is simply vendoring like you often see in other languages.
- kimixa 3y ago
  I think it was more "hiding" as vendored code rather than really being in that category. The git repo never contained that "vendoring", as the m4/gettext.m4 file doesn't exist autoreconf just copies one from a system store, (which on my machine never calls the tainted BUILD_TO_HOST macros in the first place, which also doesn't exist in the upstream xz git repo). "Vendoring" by copying untracked files into the tarball seems discourteous to the definition. It seems to rely on the "possibly odd" behavior of autoreconf to allow files that happen to have the same name to override system-installed versions? I guess on the belief that local definitions can override them is useful? But that certainly bit them in the ass here. As to get a "completely" clean autoconf rebuild it looks like you have to delete matching files manually.