Re: Security lessons from liblzma

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