FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 02-10-2010, 08:58 AM
Jim Meyering
 
Default caution: avoid unpatched automake

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-10-2010, 09:07 AM
Jon Masters
 
Default caution: avoid unpatched automake

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.

umask is your friend.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-10-2010, 09:07 AM
Jon Masters
 
Default caution: avoid unpatched automake

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.

umask is your friend.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-10-2010, 09:12 AM
Jim Meyering
 
Default caution: avoid unpatched automake

Jim Meyering wrote:
> There was a nasty flaw in _every_ automake-generated Makefile.in
> until recently[*]. When making releases, most of us who maintain

To clarify, the vulnerability affects the "distdir" commands
that appear only in so-called top-level Makefile.in files.
Note however, that some packages include sub-packages, so it's not
enough to search the Makefile.in file in the top-level directory.

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

That's why this command searches all Makefile.in files:

> tar --to-stdout -x -f $tgz '*/Makefile.in' | grep -e '-perm -777 '
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-10-2010, 11:47 AM
Jim Meyering
 
Default caution: avoid unpatched automake

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-10-2010, 11:47 AM
Jim Meyering
 
Default caution: avoid unpatched automake

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

Thread Tools




All times are GMT. The time now is 03:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org