Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 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.
Can anyone think of a feasible way to prevent this sort of attack?
There have been some possibilities suggested on other branches of the
discussion. I have changed the subject of one of those to "checking
aclocal m4 files" to highlight it. There is progress being made, but
the solutions appear to be outside the direct scope of the GNU build
system packages.
Someone suggested that configure should not use m4 files that are
lying around, but rather should fetch them from standard release points,
WDYT of that idea?
Autoconf configure scripts do not use nearby m4 files and do not require
m4 at all; aclocal collects the files in question into aclocal.m4 (I
think) and then autoconf uses that (and other inputs) to /produce/
configure. (This may seem like a trivial point, but exact derivations
and their timing were critical to how the backdoor dropper worked.)
Other tools (at least autopoint from GNU gettext, possibly others) are
used to automatically scan a larger set of m4 files stored on the system
and copy those needed into the m4/ directory of a package source tree,
in a process conceptually similar to how the linker pulls only needed
members from static libraries when building an executable. All of this
is done on the maintainer's machine, so that the finished configure
script is included in the release tarball.
There have been past incidents where malicious code was directly added
to autoconf-generated configure scripts, so (as I understand)
distribution packagers often regenerate configure before building a
package. In /this/ case, the crackers (likely) modified the version of
build-to-host.m4 on /their/ computer, so the modified file would be
copied into the xz-utils/m4 directory in the release tarball and used
when distribution packagers regenerate configure before building the
package.
Fetching these files from standard release points would require an index
of those standard release points, and packages are allowed to have their
own package-specific macros as well. The entire system dates from well
before ubiquitous network connectivity could be assumed (anywhere---and
that is still a bad assumption in the less prosperous parts of the
world), so release tarballs are meant to be self-contained, including
copies of "standard" macros needed for configure but not supplied by
autoconf/automake/etc.
-- Jacob