3 ms·
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
by 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 agoThis 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 agomerely 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 agoHow 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.