Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

[Bob Friesenhahn]

On 3/30/24 19:00, Alexandre Oliva wrote:

> Bluntly, I don't think it would help with security.  The attacker would
> just have to disable or adjust the distcheck target to seemingly pass.
>
> Relying on something in a code repository to tell whether the repository
> is secure is akin to tying a dog with sausage.
>
> For security proper, the verification code needs to be held elsewhere,
> not compromisable along with the thing it's supposed to verify.
>
> Analogously, you don't run a rootkit checker on the system that's
> potentially compromised, because the rootkit may hide itself; you boot
> off secure media and then use the tools in it to look for the rootkit in
> the potentially-compromised system, *without* handing control over to
> it.
I am on the oss-security mailing list where this issue was perhaps first 
publicly reported, and has been discussed/analyzed furiously.

My first thought was that Autoconf is a relatively trivial attack vector 
since it is so complex and the syntax used for some parts (e.g. m4 and 
shell scripts) is so arcane.  In particular, it is common for Autotools 
stuff to be installed on a computer (e.g. by installing a package from 
an OS package manager) and then used while building.  For example, there 
are large collections of ".m4" files installed.  If one of the m4 files 
consumed has been modified, then the resulting configure script has been 
modified.

It may be that an OS package manager has the ability to validate already 
installed files, but this is not likely to be used.

If installed files were themselves independently signed (or sha256s of 
the files are contained in a signed manifest), and Autotools was able to 
validate them while copying into a project ("bootstrapping"), then at 
least there is some assurance that the many files which were consumed 
have not been subverted.  The same signed data could be used to detect 
if the files are modified after the initial bootstrap.

It seems common for OS distributions to modify some of the files 
(especially libtool related) so they differ from the original GNU versions.

The problem which happened with the xz utils software is that the 
maintainer signed a release package with his PGP key, but there were 
subtle changes in the released product.  It is not yet clear if the 
maintainer intentionally did this, or if the changes were introduced via 
a compromise of his computer.

Bob

--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt