Conclusions from CVE-2024-3094 (libxz disaster)

[Oldřich Jedlička]

Hi,

ne 31. 3. 2024 v 1:07 odesílatel Elliott Mitchell <ehem+openwrt at m5p.com> napsal:
> On Sat, Mar 30, 2024 at 10:54:00PM +0100, Oldřich Jedlička wrote:
> >
> > so 30. 3. 2024 v 16:31 odesílatel Daniel Golle <daniel at makrotopia.org> napsal:
> > > Hiding a malicious change in a commit is infinitely harder than hiding
> > > it in a tarball.
> >
> > Just a note: The malicious code was part of the tarball because it was
> > part of the main Git repository in the first place. Using Git would
> > not help in any way in this particular case. Just check [1] together
> > with findings [2].
> >
> > [1]: https://git.tukaani.org/?p=xz.git;a=shortlog
> > [2]: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
>
> One of the information sources (haha, one can wonder about *any* source
> of information):
> https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
>
> Under "Design":
>
> >Normally upstream publishes release tarballs that are different than the
> >automatically generated ones in GitHub. In these modified tarballs, a
> >malicious version of build-to-host.m4 is included to execute a script
> >during the build process.
>
> So the malicious source code was part of all tarballs, but only the
> tarballs with the modified `build-to-host.m4` would trigger the malicious
> payload.
>
> So obtaining GitHub's tarballs which came directly from the Git
> repository *does* avoid the breach.
>
> (as does avoiding SystemD, as does not building rpms or .debs, or using
> something besides amd64)

Yes, you are right. I wrote it wrong, I just wanted to point out that
the crafted files were part of the Git repository already as also
stated in  https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27

  There are crafted test files in the tests/ folder within the git
repository too.

The problem is not using release tarballs or tarballs from GitHub, but
trusting that what the author is doing is not malicious. Anyway, I do
not want to start discussion about reviews, many eyes watching Git
commits and related things, just keep this in mind - the malicious
author can do it again and if his plan crosses project boundaries like
in this case (xz + systemd), you will not discover it easily.

Cheers
Oldrich.