Hi, On 2024-03-29 18:37:24 -0400, Bruce Momjian wrote: > You might have seen reports today about a very complex exploit added to > recent versions of liblzma. Fortunately, it was only enabled two months > ago and has not been pushed to most stable operating systems like Debian > and Ubuntu. The original detection report is: > > https://www.openwall.com/lists/oss-security/2024/03/29/4 > > And this ycombinator discussion has details: > > https://news.ycombinator.com/item?id=39865810 > > It 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. > > and I think the configure came in through the autoconf output file > 'configure', not configure.ac: > > This 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.)
I don't think that's a useful lesson here, actually. In this case, if you ran autoreconf -fi in a released tarball, it'd just recreate precisely what the tarball already contained, including the exploit. I think the issue in this case rather was that the tarball contains files that are not in the release - a lot of them. The attackers injected the 'activating' part of the backdoor into the release tarball, while it was not present in the git tree. They did that because they knew that distributions often build from release tarballs. If the release pre-backdoor release tarball had been identical to the git repository, this would likely have been noticed by packagers - but it was normal for there to be a lot of new files. We traditionally had also a lot of generated files in the tarball that weren't in our git tree - but we removed a lot of that a few months ago, when we stopped including bison/flex/other generated code. We still include generated docs, but that's much harder to exploit at scale. However, they still make it harder to verify that the release is exactly the same as the git tree. > Now, we don't take pull requests, and all our committers are known > individuals, but this might have cautionary lessons for us. I am doubtful that every committer would find something sneaky hidden in e.g. one of the test changes in a large commit. It's not too hard to hide something sneaky. I comparison to that hiding something in configure.ac seems less likely to succeed IMO, that imo tends to be more scrutinized. And hiding just in configure directly wouldn't get you far, it'd just get removed when the committer or some other committer at a later time, regenerates configure. Greetings, Andres Freund
