** 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
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.
Oh and the bad side is that we have no way to find out if there is any compromised tarball out there.
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
we should be OK to push for stabilization on these packages now ...
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.
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
arches: see comment #3 for versions to stable
(In reply to comment #7) > arches: see comment #3 for versions to stable SLOT=1.11 is excluded I assume.
there is Bug 295947 to track automake 1.11 stabilization if you dont want to do it right away
Stable for HPPA (except 1.11.1).
x86 stable
ppc64 done except for -1.11.x
amd64/arm stable
Marked ppc stable.
alpha/ia64/m68k/s390/sh/sparc stable
GLSA request filed.
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).