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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
