bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoreconf --force seemingly does not forcibly update everything


From: Eric Blake
Subject: Re: autoreconf --force seemingly does not forcibly update everything
Date: Mon, 1 Apr 2024 12:43:02 -0500
User-agent: NeoMutt/20240201

Widening the audience to include bug-gnulib, which is the upstream
source of "# build-to-host.m4 serial 3" which was bypassed by the
malicious "# build-to-host.m4 serial 30".

On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote:
> Hi!
> 
> While analyzing the recent xz backdoor hook into the build system [A],
> I noticed that one of the aspects why the hook worked was because it
> seems like «autoreconf -f -i» (that is run in Debian as part of
> dh-autoreconf via dh) still seems to take the serial into account,
> which was bumped in the tampered .m4 file. If either the gettext.m4
> had gotten downgraded (to the version currently in Debian, which would
> not have pulled the tampered build-to-host.m4), or once Debian upgrades
> gettext, the build-to-host.m4 would get downgraded to the upstream
> clean version, then the hook would have been disabled and the backdoor
> would be inert. (Of course at that point the malicious actor would
> have found another way to hook into the build system, but the less
> avenues there are the better.)
> 
> I've tried to search the list and checked for old bug reports on the
> debbugs.gnu.org site, but didn't notice anything. To me this looks like
> a very unexpected behavior, but it's not clear whether this is intentional
> or a bug. In any case regardless of either position, it would be good to
> improve this (either by fixing --force to force things even if
> downgrading, or otherwise perhaps to add a new option to really force
> everything).
> 
> [A] <https://lists.debian.org/debian-devel/2024/03/msg00367.html>
>     Longish mail, search for "try to go in detail" for the analysis.

My understanding is that the use of serial numbers in .m4 snippets was
intentional in gnulib (more or less where the practice originated),
but only because gnulib prefers a linear history (everything is
monotonically increasing, no forks for the serial number to diverge
on).  In light of this weekend's mess, Bruno may have more ideas about
how to prevent his files from being turned into backdoor delivery
mechanisms in the future.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]