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

Jim Meyering jim at meyering.net
Wed Feb 10 12:47:07 UTC 2010


Jon Masters wrote:
> On Wed, 2010-02-10 at 10:58 +0100, Jim Meyering wrote:
>> 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.
>
> I disagree that it's as critical as you make out - sure it needs fixing.
> To exploit this, you have to build within a directory path that is going
> to be writeable (i.e. have a world readable home directory and build in
> there directly), and be using a shared system on which you don't trust
> your users. In the latter case, it's often game over anyway.

Hi Jon,

This is definitely not a critical vulnerability.
The CVE now has a cvss2 rating of only 3.7.

However, that you mention "build within...writable" (ambiguous)
and that you say "world readable", not "world searchable"
suggest that I should clarify.

Anyone running "make distcheck" with a bad Makefile.in from
a world-_searchable_ build directory is vulnerable.  The build
directory certainly does not have be world-writable.  It need not even
be world-readable.  Just searchable.  The flaw is still exploitable if
an attacker can guess, say, via ps, the name of your build directory.
This is a good argument for running "chmod 700 $HOME/" and doing the
same on any other directory beneath which you build things.

Before this excursion, my umask was 022.  Now it's 077.

As for shared systems, while I'm fairly security conscious and maybe
even a little paranoid, I feel I have to treat my desktop system very
carefully.  While it is a well-secured single-user system, if somehow it
does become a "shared system", I won't fall to this particular exploit.
Note that on truly shared systems, while I may trust colleagues not to
take advantage of this sort of thing directly, my trust does not extend
to malicious users they may inadvertently invite.

In addition, there's habit to deal with.
Sometimes (portability testing) I would do things like this:

  cd /dev/shm && mkdir foo && cd foo && wget ...
    && tar xf FILE && ./configure && ...

Running "make dist" or "make distcheck" in the above would make me
vulnerable with a umask of 022.  Of course, now my umask is more
restrictive, so that's ok.


More information about the devel mailing list