On Mon, Apr 1, 2024 at 2:31 PM Bruno Haible <br...@clisp.org> wrote: > > 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.
Please forgive my ignorance... If you bump the authentic version of the m4 file to version 31, will the issue mostly clear itself? And reserving version 30 for the miscreant's version should allow scanners like ClamAV to target it. Jeff
