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

[Bruno Haible]

Thanks for the forward, Eric.

Guillem Jover wrote in
<https://lists.gnu.org/archive/html/bug-autoconf/2024-03/msg00000.html>:
> > 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.

The 'serial' number in *.m4 files exists precisely so that tools like
'aclocal --install' or (as you say) 'autoreconf -f -i' can avoid
overwriting newer .m4 files with older versions.

I don't know exactly about the situations in which this happens. But
your investigations shed enough light on it. You write:
  "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"

The situation is:
  - Debian stable is still on gettext 0.21, which comes with
      gettext.m4 serial 71
  - gettext-0.22 comes with
      gettext.m4 serial 77
    which depends on build-to-host.m4.
Assume furthermore that a package P relies on gettext (via AM_GNU_GETTEXT),
and the user has installed gettext-0.22 or newer. And they run
  $ autoreconf
which invokes autopoint, which installs the gettext.m4.

If, in this situation, the newer .m4 file would not prevail, Debian's
old gettext.m4 would take precedence. This would mean that new features
from new gettext releases would not land in the users' hands; they
would be blocked by Debian, for the time the user uses this distro+version
(often 4 or 5 years).

Worse, this would also hold for Red Hat distro releases, which typically
are not 4-5 years, but 10-12 years behind the newest release. It would
mean that *for 10 years*, packages P could not make use of new features
(and bug fixes) that were added in GNU gettext upstream.

This is the problem that the 'serial' number annotation fixes.

It may be unexpected to you, but it is very much intended.

And if aclocal's preference was the other way around, always favouring
the smaller serial number, then the attacker would not have picked
'serial 30' but 'serial 1', in order to override the distro's version.

> 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).

The history is mostly linear, yes. There is a bit of nonlinearity
  - because gettext.m4 gets copied from gettext to gnulib and/or
    from gnulib to gettext,
  - because gettext has a release branch,
  - because gnulib has stable branches,
but all in all, it's linear.

> 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.

I gave my opinion here:
  https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00422.html
  https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00421.html

Basically I think that an attacker who is clever enough to bypass the
RELRO protection by using IFUNC, knowing that IFUNC gets processed
_before_ the GOT or PLT pages are made read-only, — such an attacker
will also find ways to conceal their malware triggers, regardless of
any simple measures at the source code level that we might invent.

Bruno