Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 295357 (CVE-2009-4029) - sys-devel/automake: "make dist" race condition (CVE-2009-4029)
Summary: sys-devel/automake: "make dist" race condition (CVE-2009-4029)
Status: RESOLVED FIXED
Alias: CVE-2009-4029
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: A3 [glsa]
Keywords:
Depends on:
Blocks: 295947
  Show dependency tree
 
Reported: 2009-12-01 18:31 UTC by Robert Buchholz (RETIRED)
Modified: 2013-10-26 00:23 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Buchholz (RETIRED) gentoo-dev 2009-12-01 18:31:21 UTC
** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **

Automake background:
====================
Automake is a tool for automatically generating `Makefile.in'
files compliant with the GNU Coding Standards.

CVE-2009-4029 flaw:
==================
Jim Meyering found a race condition in the way Automake used to
prepare content of directories hierarchy (top-level directory
and its subdirectories), when the "distdir" based Automake target
was used. A local attacker could use this flaw to inject malicious
content into the resulting directory and potentially subsequently
execute arbitrary code with the privileges of the user issuing
the "./configure" command.

Further flaw description / analysis by Jim Meyering:
====================================================
I have discovered a flaw in automake-generated Makefiles that makes
a developer vulnerable whenever s/he runs commonly recommended "make"
rules in an other-searchable directory.

In a project that uses automake, when you run "make dist" or "make
distcheck" or any rule that depends on the "distdir" target[*], you
run commands to create a hierarchy that is tar'd and compressed.

Unfortunately, the final step in preparing the directory before tarring
it up is to chmod 777 each directory in it. Then it is tarred and
compressed, and that temporarily too-permissive directory is removed.

During that interval between find+chmod and tar, however, if your working
directory is other-searchable, an attacker may insert code into any of
those other-writable directories, e.g., into the usual configure script.
Who would notice a few extra lines of shell code in those? The one in
coreutils is 52,200 lines long. And if you were running "make distcheck"
(a commonly recommended pre-release sanity check), the next step in that
automatic process is to unpack this tainted tarball and run ./configure.
Boom.

So if I find someone running "make distcheck" in an other-searchable
directory, it would be trivial to set up an inotify-based trigger on
the existence of the distdir (whose name I can predict), and insert
malicious code the moment the permissions are relaxed.

Even if you are not running "make distcheck", the usual purpose of
creating a distribution tarball is to unpack it somewhere and build.
Thus, not only could the savvy attacker manipulate that directory to
make you, the package developer, run arbitrary code, they could also
end up inserting arbitrary code in a distribution tarball that is to
be released on a wide scale.

For your reference, here is the part of the distdir rule that is found
in every top-level Makefile.in:

distdir: $(DISTFILES)
...
$(MAKE) $(AM_MAKEFLAGS) \
top_distdir="$(top_distdir)" distdir="$(distdir)" \
dist-hook
-test -n "$(am__skip_mode_fix)" \
|| find "$(distdir)" -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r "$(distdir)"


[*] Here is the full list of rules that depend on distdir:
dist
distclean
dist-gzip
dist-bzip2
dist-lzma
dist-xz
dist-tarZ
dist-shar
dist-zip

Affected Automake versions (by Jim Meyering):
============================================
Looking through the version control history, I saw that this behavior
has been present in automake since at least 2000, so it's safe to say
every version of automake from every vendor is affected.

Projected into Automake versions this means (iankko):
-----------------------------------------------------
Automake-1.5 <= x <= Automake-1.11 (latest)

CVE identifier: CVE-2009-4029 has been assigned to this issue
===============

CRD date: Next Monday 2009-12-07, 12:00 UTC time
=========

PoC: 
====
  <jim> insert a "sleep 99h" into the Makefile rule, right after the find,
        then inspect the permissions of the directory
  <iankko> ok, regarding the probability fruitfulness of exploitation of this 
  -- the more files the 'directory hierarchy' contains, the bigger chance the
     attacker has to succeed
   <jim> don't worry.  with inotify, even a small directory should be exploitable
   <jim> it's easy to automate
   <jim> i.e., *do* worry ;-)

Patches:
=======
  Upstream fix against latest Automake version is public at:

    http://thread.gmane.org/gmane.comp.sysutils.automake.patches/3743

Credit:
=======
Jim Meyering
Comment 1 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-12-01 18:41:15 UTC
I guess the good side is that we should be able to patch all automake versions.
The bad news is that we're going to have to patch all automake versions.
Comment 2 Diego Elio Pettenò (RETIRED) gentoo-dev 2009-12-01 18:42:53 UTC
Oh and the bad side is that we have no way to find out if there is any compromised tarball out there.
Comment 3 SpanKY gentoo-dev 2009-12-09 09:01:30 UTC
ive added upstream 1.10.3 and 1.11.1 as they contain the fix, and ive added the upstream git commits for older ebuilds

so new versions:
automake-1.4_p6-r1
automake-1.5-r1
automake-1.6.3-r1
automake-1.7.9-r2
automake-1.8.5-r4
automake-1.9.6-r3
automake-1.10.3
automake-1.11.1
Comment 4 SpanKY gentoo-dev 2010-01-08 03:56:36 UTC
we should be OK to push for stabilization on these packages now ...
Comment 5 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2010-01-08 17:45:48 UTC
CVE-2009-4029 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-4029):
  The (1) dist or (2) distcheck rules in GNU Automake 1.11.1, 1.10.3,
  and release branches branch-1-4 through branch-1-9, when producing a
  distribution tarball for a package that uses Automake, assign
  insecure permissions (777) to directories in the build tree, which
  introduces a race condition that allows local users to modify the
  contents of package files, introduce Trojan horse programs, or
  conduct other attacks before the build is complete.

Comment 6 SpanKY gentoo-dev 2010-01-08 21:52:47 UTC
i think the CVE text is incorrect ... the point of the 1.11.1 and 1.10.3 and related releases were to fix this CVE, not to cause it
Comment 7 SpanKY gentoo-dev 2010-02-14 16:47:42 UTC
arches: see comment #3 for versions to stable
Comment 8 Christian Faulhammer (RETIRED) gentoo-dev 2010-02-16 22:20:26 UTC
(In reply to comment #7)
> arches: see comment #3 for versions to stable

SLOT=1.11 is excluded I assume.
Comment 9 SpanKY gentoo-dev 2010-02-16 22:46:03 UTC
there is Bug 295947 to track automake 1.11 stabilization if you dont want to do it right away
Comment 10 Jeroen Roovers gentoo-dev 2010-02-18 16:58:07 UTC
Stable for HPPA (except 1.11.1).
Comment 11 Christian Faulhammer (RETIRED) gentoo-dev 2010-02-21 22:09:52 UTC
x86 stable
Comment 12 Brent Baude (RETIRED) gentoo-dev 2010-03-01 20:43:56 UTC
ppc64 done except for -1.11.x
Comment 13 Markus Meier gentoo-dev 2010-03-07 22:51:46 UTC
amd64/arm stable
Comment 14 Joe Jezak (RETIRED) gentoo-dev 2010-03-09 22:35:58 UTC
Marked ppc stable.
Comment 15 Raúl Porcel (RETIRED) gentoo-dev 2010-03-13 19:31:16 UTC
alpha/ia64/m68k/s390/sh/sparc stable
Comment 16 Tim Sammut (RETIRED) gentoo-dev 2010-11-20 16:49:33 UTC
GLSA request filed.
Comment 17 GLSAMaker/CVETool Bot gentoo-dev 2013-10-26 00:23:53 UTC
This issue was resolved and addressed in
 GLSA 201310-15 at http://security.gentoo.org/glsa/glsa-201310-15.xml
by GLSA coordinator Chris Reffett (creffett).