Re: gnulib's build-to-host.m4 and its role in the recent xz backdoor

[Bruno Haible]

Collin Funk wrote:
> This file was .gitignore'd and only contained in the distributed
> tarballs. Given the rest of the situation, the goal was obviously to
> hide this as much as possible. It is annoying that they choose to hide
> it among real, useful Gnulib code.

It was pretty logical that Jia Tin used this .m4 files for hiding the
trigger:

  * Because "The malicious injection ... is obfuscated and only included
    in full in the download package - the Git distribution lacks the M4
    macro that triggers the build of the malicious code" [1] it was normal
    for him to look for a file that is not present in Git but present in
    the tarballs. Which files are this? Mainly
      - *.m4 files,
      - some build-aux/ files,
      - some *.c files (not here: they committed all .c files into git).

  * For the purposes of hiding and concealing malware, it is useful to
    pick a file whose programming language few people understand.
    *.m4 - perfect match! Better than a *.c file.

  * build-to-host.m4 in particular is deterring, due to its uses of [$1]
    and backslashes. Most people who look at this for one second immediately
    leave. Which also fits the goal.

When criminals proceed in a planned way, they abuse whatever is most
suited to their goals. In this case it was a .m4 file that I had created
a couple of days earlier. There is nothing we can do about it. We cannot
say "Let's stop writing *.m4 files, because criminals could abuse them".
It would be as silly as saying "Let's stop building roads for car traffic,
because criminals could abuse them for fleeing from a crime scene".

Bruno

[1] https://www.phoronix.com/news/XZ-CVE-2024-3094