Conclusions from CVE-2024-3094 (libxz disaster)

[Petr Štetiar]

Daniel Golle <daniel at makrotopia.org> [2024-04-03 01:11:41]:

Hi,

> > In this case, they were targeting specific audience and this attack vector was
> > cheapest/fastest, so the source code origin doesn't really matter.
> 
> I tend to slightly disagree, because an attacker will always chose
> what ever means are necessary or sufficient. Using tarballs instead of
> checkouts increases the attack surface in the sense that validating
> the tarball content is extra work for package maintainers.

I've noticed, that Debian for example imports upstream package tarballs into
their GitLab instance, so one would argue, that the Git diff is easily
available to package maintainers, yet they've happily included the
backdoor[1]. The package version bumps are usually huge, thus impossible to
review properly.

> > > Why do we need to rely one proprietary hacks such as Gibhub codeload
> > > just to safe a few megabytes of traffic and a few seconds of build
> > > time?
> > 
> > Ok, I don't like GH either, but I find this irrelevant, origin of the source
> > code is not a problem, the content is the problem.
> 
> ... and that crazy m4 script had to be noticed. As a diff one would ask:
> Why was that change necessary?

This was our case, jumping from v5.4.6 to v5.6.1, right? So just take a look
at the diff now:

 git diff --stat v5.4.6..v5.6.1 | grep changed,
 404 files changed, 26865 insertions(+), 17129 deletions(-)

 $ git diff --stat v5.4.6..v5.6.1 -- ':!windows/' ':!po/' ':!docs/' ':!.github/' ':!po4a/' | grep changed,
 357 files changed, 10544 insertions(+), 4529 deletions(-)

So realistically, to review that amount of changes somehow more properly, this
is huge amount of work, if you really want to question purpose of every
change, verify it, then this is like 16k lines, so lets say, that you can do
1-2k a day properly, thus around a week of work? Who have such resources and
dedication?

And even after that rigid review, I'm not sure if I would catch that famous
CMakeLists.txt '.' Landlock sabotage:

 +        #include <sys/prctl.h>
 +.
 +        void my_sandbox(void)

looking at the commit 328c52da8a2b ("Build: Fix Linux Landlock feature test in
Autotools and CMake builds.") alone, I still have a problem to spot it.

> They unpack the release tarballs into a git repo, so that makes the diff
> more visible and obvious again for maintainers. That would get the best
> of both worlds (at a significant resource pricetag, though...)

Providing the diff is not a problem, finding someone who would review the diff
_properly_ is a problem.

> But the m4 hackery which is excessive and seemingly unnecessary.

In this case, it would be hidden somewhere in between other 16-40k lines of
changes, so hardly spottable?

1. https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/m4/build-to-host.m4?ref_type=heads#L63

Cheers,

Petr