caution: avoid unpatched automake [CVE-2009-4029]

Jim Meyering jim at meyering.net
Wed Feb 10 09:58:37 UTC 2010


There was a nasty flaw in _every_ automake-generated Makefile.in
until recently[*].  When making releases, most of us who maintain
automake-using packages run "make dist" or "make distcheck".
Even if you don't, your users may.  The flaw put all of us at risk.

With a Makefile.in file generated by unpatched automake,
if you run "make dist" in a potentially hostile environment,
you risk including arbitrary code in a tarball that you may
then sign, thinking it's a faithful copy of your working sources.
Worse, if you run "make distcheck" you risk immediate arbitrary
code execution.

Even if you are confident you never run those commands
in a vulnerable environment, you have to consider that
someone who downloads your release tarball may run them.

I mention this because some recently released packages
included Makefile.in files generated by unpatched automake.
To check, simply run this against the any compressed tarball, $tgz:
[this command assumes you have GNU Tar 1.22 or newer, so that it
 will work with .xz-compressed files, too]

    tar --to-stdout -x -f $tgz '*/Makefile.in' | grep -e '-perm -777 '

If there's a match, you should get a fixed version of automake
and use it to regenerate that file.  If that's too much trouble,
at least correct the Makefile.in file(s), e.g., by running something
like this:

    perl -pe 's/perm -777 -exec chmod a\+rwx/perm -755 -exec chmod  755 /'

You can even apply that to an uncompressed tarball, since it is
careful not to change the length of the file.  In any case, there
is a small risk of a false-positive match, so check your work.

A check like the above has been protecting the upload-to-ftp.gnu.org
process for a few weeks now, and has already blocked numerous tainted
uploads.

Jim

[*] Here's the announcement of the "make dist" CVE fix

    http://thread.gmane.org/gmane.comp.sysutils.autotools.announce/131


More information about the devel mailing list