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