Re: GNU Automake 1.12.1 released

2012-07-09 Thread Jim Meyering 
Stefano Lattarini wrote:
> On 07/06/2012 12:10 AM, Diego Elio Pettenò wrote:
>> Il 05/07/2012 11:26, Stefano Lattarini ha scritto:
>>> How so?  Removal of $(mkdir_p) is only planned for Automake 1.13, that is
>>> still unreleased.
>>
>> Ehm Stefano, that's definitely not the case, I've been hitting that
>> issue in Gentoo in many packages.
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=automake-1.12
>>
>> mkdir_p is gone in automake-1.12.1 for what we're concerned — I also
>> listed it in the 1.12 instead of "planned for 1.13" in my own guide
>> http://goo.gl/bda6l as I thought it was intentional.
>>
> Ouch, I can reproduce this :-/  The issue is that the call to
> AM_PROG_MKDIR_P in AM_INIT_AUTOMAKE has been substituted by a
> call to AC_PROG_MKDIR_P, which doesn't define $(mkdir_p).  This
> was an unintended regression.
>
> I will soon push the attached patches to take care of the problem.
> Note that they only re-introduce the $(mkdir_p) variable (because
> is very easy to do so), but not the @mkdir_p@ substitution.  Anyone
> knows if this can create problems in practice?

Hi Stefano,

I see that @mkdir_p@ is used in gettext's Makefile.in.in template:

  # We use $(mkdir_p).
  # In automake <= 1.9.x, $(mkdir_p) is defined either as "mkdir -p --" or as
  # "$(mkinstalldirs)" or as "$(install_sh) -d". For these automake versions,
  # @install_sh@ does not start with $(SHELL), so we add it.
  # In automake >= 1.10, @mkdir_p@ is derived from ${MKDIR_P}, which is defined
  # either as "/path/to/mkdir -p" or ".../install-sh -c -d". For these automake
  # versions, $(mkinstalldirs) and $(install_sh) are unused.
  mkinstalldirs = $(SHELL) @install_sh@ -d
  install_sh = $(SHELL) @install_sh@
  MKDIR_P = @MKDIR_P@
  mkdir_p = @mkdir_p@

Since that file is copied into many projects,
I'd recommend to substitute @mkdir_p@, as well.

Re: GNU Automake 1.12.1 released

2012-07-09 Thread Stefano Lattarini 
On 07/09/2012 09:22 AM, Jim Meyering wrote:
>
> Hi Stefano,
> 
> I see that @mkdir_p@ is used in gettext's Makefile.in.in template:
> 
>   # We use $(mkdir_p).
>   # In automake <= 1.9.x, $(mkdir_p) is defined either as "mkdir -p --" or as
>   # "$(mkinstalldirs)" or as "$(install_sh) -d". For these automake versions,
>   # @install_sh@ does not start with $(SHELL), so we add it.
>   # In automake >= 1.10, @mkdir_p@ is derived from ${MKDIR_P}, which is 
> defined
>   # either as "/path/to/mkdir -p" or ".../install-sh -c -d". For these 
> automake
>   # versions, $(mkinstalldirs) and $(install_sh) are unused.
>   mkinstalldirs = $(SHELL) @install_sh@ -d
>   install_sh = $(SHELL) @install_sh@
>   MKDIR_P = @MKDIR_P@
>   mkdir_p = @mkdir_p@
> 
> Since that file is copied into many projects,
> I'd recommend to substitute @mkdir_p@, as well.
>
That is simply enough to do if we content ourselves with a substitution
that makes it usable in Makefiles only:

AC_SUBST([mkdir_p], ['$(MKDIR_P)'])

See attached patch.  OK?

Regards,
  Stefano
>From bcc3baae5b6e58132d304e41db79cfa5b27d3bcc Mon Sep 17 00:00:00 2001
Message-Id: 
From: Stefano Lattarini 
Date: Mon, 9 Jul 2012 10:33:49 +0200
Subject: [PATCH] compat: automake should substitute @mkdir_p@, for backward
 compatibility

That has been unwittingly broken by commit v1.12-19-g7a1eb9f of 2012-04-28,
"AM_PROG_MKDIR_P: deprecate, to be removed in Automake 1.13". We thought it
wasn't a big deal, but Jim Meyering reported that @mkdir_p@ is used in
gettext's Makefile.in.in template:


* lib/am/header-vars.am (mkdir_p): Don't define.
* m4/init.m4 (AM_INIT_AUTOMAKE): AC_SUBST 'mkdir_p' with $(MKDIR_P).
* t/mkdir_p.sh, t/mkdirp-deprecation.sh: Enhance.
* NEWS: Update.

Signed-off-by: Stefano Lattarini 
---
 NEWS|8 
 lib/am/header-vars.am   |5 -
 m4/init.m4  |5 +
 t/mkdir_p.sh|   12 
 t/mkdirp-deprecation.sh |   12 
 5 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/NEWS b/NEWS
index d38554d..eaab9d1 100644
--- a/NEWS
+++ b/NEWS
@@ -6,10 +6,10 @@ New in 1.12.2:
 long-deprecated 'configure.in' name for the Autoconf input file.
 You are advised to use the recommended name 'configure.ac' instead.
 
-  - The long-obsolete (since automake 1.10) @mkdir_p@ configure-time
-substitution and AM_PROG_MKDIR m4 macro will be removed in Automake
-1.13.  The $(mkdir_p) should still remain available for the moment
-though.
+  - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
+be removed in Automake 1.13.  The $(mkdir_p) make variable and the
+@mkdir_p@ substitution should still remain available (as aliases of
+$(MKDIR_P)) for the moment, for better backward compatibility.
 
   - Autoconf 2.65 or later will be required by the next major Automake
 version (1.13).  Until now, Automake has required Autoconf version
diff --git a/lib/am/header-vars.am b/lib/am/header-vars.am
index c65e08c..ba4aa0b 100644
--- a/lib/am/header-vars.am
+++ b/lib/am/header-vars.am
@@ -77,11 +77,6 @@ NORMAL_UNINSTALL = :
 PRE_UNINSTALL = :
 POST_UNINSTALL = :
 
-# For better backward compatibility.  To be removed once Automake 1.9.x
-# dies out for good.  For more background, see:
-# 
-mkdir_p = $(MKDIR_P)
-
 ## dejagnu.am uses these variables.  Some users might rely on them too.
 ?BUILD?build_triplet = @build@
 ?HOST?host_triplet = @host@
diff --git a/m4/init.m4 b/m4/init.m4
index 85228ba..cf47e76 100644
--- a/m4/init.m4
+++ b/m4/init.m4
@@ -82,6 +82,11 @@ AM_MISSING_PROG([MAKEINFO], [makeinfo])
 AC_REQUIRE([AM_PROG_INSTALL_SH])dnl
 AC_REQUIRE([AM_PROG_INSTALL_STRIP])dnl
 AC_REQUIRE([AC_PROG_MKDIR_P])dnl
+# For better backward compatibility.  To be removed once Automake 1.9.x
+# dies out for good.  For more background, see:
+# 
+# 
+AC_SUBST([mkdir_p], ['$(MKDIR_P)'])
 # We need awk for the "check" target.  The system "awk" is bad on
 # some platforms.
 AC_REQUIRE([AC_PROG_AWK])dnl
diff --git a/t/mkdir_p.sh b/t/mkdir_p.sh
index 624365c..2cc68a3 100755
--- a/t/mkdir_p.sh
+++ b/t/mkdir_p.sh
@@ -27,17 +27,21 @@ END
 cat > Makefile.am << 'END'
 SUBDIRS = sub
 all-local:
-	$(mkdir_p) . dir1/dir2
+	$(mkdir_p) . dir1/a
+	@mkdir_p@ . dir2/b
 check-local: all
-	test -d dir1/dir2
-	test -d dir1/dir3
+	test -d dir1/a
+	test -d dir2/b
+	test -d dir3/c
+	test -d dir3/d
 END
 
 mkdir sub
 cat > sub/Makefile.am << 'END'
 # '$(mkdir_p)' should continue to work even in subdir makefiles.
 all-local:
-	$(mkdir_p) .. ../dir1/dir3
+	$(mkdir_p) .. ../dir3/c
+	@mkdir_p@ .. ../dir3/d
 END
 
 $ACLOCAL
diff --git a/t/mkdirp-deprecation.sh b/t/mkdirp-deprecation.sh
index 0257391..68ffa58 100755
--- a/t/mkdirp-deprecati

Re: GNU Automake 1.12.1 released

2012-07-09 Thread Jim Meyering 
Stefano Lattarini wrote:
> On 07/09/2012 09:22 AM, Jim Meyering wrote:
>>
>> Hi Stefano,
>>
>> I see that @mkdir_p@ is used in gettext's Makefile.in.in template:
>>
>>   # We use $(mkdir_p).
>>   # In automake <= 1.9.x, $(mkdir_p) is defined either as "mkdir -p --" or as
>>   # "$(mkinstalldirs)" or as "$(install_sh) -d". For these automake versions,
>>   # @install_sh@ does not start with $(SHELL), so we add it.
>>   # In automake >= 1.10, @mkdir_p@ is derived from ${MKDIR_P}, which is 
>> defined
>>   # either as "/path/to/mkdir -p" or ".../install-sh -c -d". For these 
>> automake
>>   # versions, $(mkinstalldirs) and $(install_sh) are unused.
>>   mkinstalldirs = $(SHELL) @install_sh@ -d
>>   install_sh = $(SHELL) @install_sh@
>>   MKDIR_P = @MKDIR_P@
>>   mkdir_p = @mkdir_p@
>>
>> Since that file is copied into many projects,
>> I'd recommend to substitute @mkdir_p@, as well.
>>
> That is simply enough to do if we content ourselves with a substitution
> that makes it usable in Makefiles only:
>
> AC_SUBST([mkdir_p], ['$(MKDIR_P)'])
>
> See attached patch.  OK?

Thanks.  That patch looks fine, applied and passed "make check".
One wording nit below.

> Subject: [PATCH] compat: automake should substitute @mkdir_p@, for backward
>  compatibility
>
> That has been unwittingly broken by commit v1.12-19-g7a1eb9f of 2012-04-28,
> "AM_PROG_MKDIR_P: deprecate, to be removed in Automake 1.13". We thought it
> wasn't a big deal, but Jim Meyering reported that @mkdir_p@ is used in
> gettext's Makefile.in.in template:
> 
>
> * lib/am/header-vars.am (mkdir_p): Don't define.
> * m4/init.m4 (AM_INIT_AUTOMAKE): AC_SUBST 'mkdir_p' with $(MKDIR_P).
> * t/mkdir_p.sh, t/mkdirp-deprecation.sh: Enhance.
> * NEWS: Update.
>
> Signed-off-by: Stefano Lattarini 
> ---
>  NEWS|8 
>  lib/am/header-vars.am   |5 -
>  m4/init.m4  |5 +
>  t/mkdir_p.sh|   12 
>  t/mkdirp-deprecation.sh |   12 
>  5 files changed, 25 insertions(+), 17 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index d38554d..eaab9d1 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -6,10 +6,10 @@ New in 1.12.2:
>  long-deprecated 'configure.in' name for the Autoconf input file.
>  You are advised to use the recommended name 'configure.ac' instead.
>
> -  - The long-obsolete (since automake 1.10) @mkdir_p@ configure-time
> -substitution and AM_PROG_MKDIR m4 macro will be removed in Automake
> -1.13.  The $(mkdir_p) should still remain available for the moment
> -though.
> +  - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
> +be removed in Automake 1.13.  The $(mkdir_p) make variable and the
> +@mkdir_p@ substitution should still remain available (as aliases of

"should" can imply doubt.  There is none.

s/should still/will/

> +$(MKDIR_P)) for the moment, for better backward compatibility.
>
>- Autoconf 2.65 or later will be required by the next major Automake
>  version (1.13).  Until now, Automake has required Autoconf version

Re: GNU Automake 1.12.1 released

2012-07-09 Thread Stefano Lattarini 
On 07/09/2012 11:17 AM, Jim Meyering wrote:
>>
>> -  - The long-obsolete (since automake 1.10) @mkdir_p@ configure-time
>> -substitution and AM_PROG_MKDIR m4 macro will be removed in Automake
>> -1.13.  The $(mkdir_p) should still remain available for the moment
>> -though.
>> +  - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
>> +be removed in Automake 1.13.  The $(mkdir_p) make variable and the
>> +@mkdir_p@ substitution should still remain available (as aliases of
> 
> "should" can imply doubt.  There is none.
> 
> s/should still/will/
>
OK, consider this fixed.

Regards,
  Stefano

Re: GNU Automake 1.12.1 released

2012-07-09 Thread Stefano Lattarini 
On 07/09/2012 11:45 AM, Stefano Lattarini wrote:
> On 07/09/2012 11:17 AM, Jim Meyering wrote:
>>>
>>> -  - The long-obsolete (since automake 1.10) @mkdir_p@ configure-time
>>> -substitution and AM_PROG_MKDIR m4 macro will be removed in Automake
>>> -1.13.  The $(mkdir_p) should still remain available for the moment
>>> -though.
>>> +  - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
>>> +be removed in Automake 1.13.  The $(mkdir_p) make variable and the
>>> +@mkdir_p@ substitution should still remain available (as aliases of
>>
>> "should" can imply doubt.  There is none.
>>
>> s/should still/will/
>>
> OK, consider this fixed.
> 
And consider the below squashed in:

  diff --git a/NEWS b/NEWS
  index eaab9d1..faf10c9 100644
  --- a/NEWS
  +++ b/NEWS
  @@ -107,13 +107,9 @@ Bugs fixed in 1.12.2:

   * Bugs introduced by 1.12.1:

  -  - Automake generated Makefiles define once again the $(mkdir_p) make
  -variable (simple ans an alias for $(MKDIR_P)), for better backward
  -compatibility.  The '@mkdir_p@' substitution is however not enabled
  -by default anymore; anyone needing it should call the AM_PROG_MKDIR
  -m4 macro explicitly (beware that this macro has been deprecated since
  -the previous Automake release 1.12.1, and will be removed in Automake
  -1.13).
  +  - Automake provides once again the '$(mkdir_p)' make variable and the
  +'@mkdir_p@' substitution (both as simple aliased for '$(MKDIR_P)'),
  +for better backward-compatibility.

Regards,
  Stefano

Re: GNU Automake 1.12.1 released

2012-07-09 Thread Jim Meyering 
Stefano Lattarini wrote:

> On 07/09/2012 11:45 AM, Stefano Lattarini wrote:
>> On 07/09/2012 11:17 AM, Jim Meyering wrote:

 -  - The long-obsolete (since automake 1.10) @mkdir_p@ configure-time
 -substitution and AM_PROG_MKDIR m4 macro will be removed in Automake
 -1.13.  The $(mkdir_p) should still remain available for the moment
 -though.
 +  - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
 +be removed in Automake 1.13.  The $(mkdir_p) make variable and the
 +@mkdir_p@ substitution should still remain available (as aliases of
>>>
>>> "should" can imply doubt.  There is none.
>>>
>>> s/should still/will/
>>>
>> OK, consider this fixed.
>>
> And consider the below squashed in:
>
>   diff --git a/NEWS b/NEWS
>   index eaab9d1..faf10c9 100644
>   --- a/NEWS
>   +++ b/NEWS
>   @@ -107,13 +107,9 @@ Bugs fixed in 1.12.2:
>
>* Bugs introduced by 1.12.1:
>
>   -  - Automake generated Makefiles define once again the $(mkdir_p) make
>   -variable (simple ans an alias for $(MKDIR_P)), for better backward
>   -compatibility.  The '@mkdir_p@' substitution is however not enabled
>   -by default anymore; anyone needing it should call the AM_PROG_MKDIR
>   -m4 macro explicitly (beware that this macro has been deprecated since
>   -the previous Automake release 1.12.1, and will be removed in Automake
>   -1.13).
>   +  - Automake provides once again the '$(mkdir_p)' make variable and the
>   +'@mkdir_p@' substitution (both as simple aliased for '$(MKDIR_P)'),

s/aliased/aliases/

>   +for better backward-compatibility.
>
> Regards,
>   Stefano

Re: GNU Automake 1.12.1 released

2012-07-09 Thread Stefano Lattarini 
On 07/09/2012 12:04 PM, Jim Meyering wrote:
> Stefano Lattarini wrote:
>
>>   -  - Automake generated Makefiles define once again the $(mkdir_p) make
>>   -variable (simple ans an alias for $(MKDIR_P)), for better backward
>>   -compatibility.  The '@mkdir_p@' substitution is however not enabled
>>   -by default anymore; anyone needing it should call the AM_PROG_MKDIR
>>   -m4 macro explicitly (beware that this macro has been deprecated since
>>   -the previous Automake release 1.12.1, and will be removed in Automake
>>   -1.13).
>>   +  - Automake provides once again the '$(mkdir_p)' make variable and the
>>   +'@mkdir_p@' substitution (both as simple aliased for '$(MKDIR_P)'),
> 
> s/aliased/aliases/
> 
Oops, fixed.

Thanks,
  Stefano

GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)

2012-07-09 Thread Stefano Lattarini 
This message announces the Automake 1.11.6 bug-fixing release.

This release FIXES A SECURITY VULNERABILITY (CVE-2012-3386), so you are
strongly encouraged to upgrade your existing Automake installation ASAP.

With this release, the recipe of the 'distcheck' target no longer grants
temporary world-wide write permissions on the extracted distdir.  Even if
such rights were only granted for a vanishingly small time window, the
implied race condition proved to be enough to allow a local attacker to
run arbitrary code with the privileges of the user running "make distcheck".

The fix of this security vulnerability is the only change between the
earlier 1.11.5 release and the present 1.11.6 one.

Download the fixed release here:

  ftp://ftp.gnu.org/gnu/automake/automake-1.11.6.tar.gz
  ftp://ftp.gnu.org/gnu/automake/automake-1.11.6.tar.xz

Please report bugs and problems to , and send
general comments and feedback to .

Thanks to everyone who has reported problems, contributed patches,
and helped testing Automake!

GNU Automake 1.12.2 released (fixes a SECURITY VULNERABILITY!)

2012-07-09 Thread Stefano Lattarini 
We are pleased to announce the Automake 1.12.2 maintenance release.

This release FIXES A SECURITY VULNERABILITY (CVE-2012-3386; see the
NEWS excerpt below for details), so you are strongly encouraged to
upgrade your existing Automake installation ASAP.

See below for the detailed list of changes since Automake 1.12.1, as
summarized by the NEWS file.

Download here:

  ftp://ftp.gnu.org/gnu/automake/automake-1.12.2.tar.gz
  ftp://ftp.gnu.org/gnu/automake/automake-1.12.2.tar.xz

Please report bugs and problems to , and send
general comments and feedback to .

Thanks to everyone who has reported problems, contributed patches,
and helped testing Automake!

-*-*-*-

New in 1.12.2:

* Warnings and deprecations:

  - Automake now issues a warning (in the 'portability' category) if
'configure.in' is used instead of 'configure.ac' as the Autoconf
input file.  Such a warning will also be present in the next
Autoconf version (2.70).

* Cleaning rules:

  - Recursive cleaning rules descends into the $(SUBDIRS) in the natural
order (as done by the other recursive rules), rather than in the
inverse order.  They used to do that in order to work a round a
limitation in an older implementation of the automatic dependency
tracking support, but that limitation had been lifted years ago
already, when the automatic dependency tracking based on side-effects
of compilation had been introduced.

  - Cleaning rules for compiled objects (both "plain" and libtool) work
better when subdir objects are involved, not triggering a distinct
'rm' invocation for each such object.  They do so by removing *any*
compiled object file that is in the same directory of a subdir
object.  See automake bug#10697.

* Silent rules support:

  - A new predefined $(AM_V_P) make variable is provided; it expands
to a shell conditional that can be used in recipes to know whether
make is being run in silent or verbose mode.

Bugs fixed in 1.12.2:

* SECURITY VULNERABILITIES!

  - The recipe of the 'distcheck' no longer grants anymore temporary
world-wide write permissions on the extracted distdir.  Even if such
rights were only granted for a vanishingly small time window, the
implied race condition proved to be enough to allow a local attacker
to run arbitrary code with the privileges of the user running "make
distcheck".  This is CVE-2012-3386.

* Long-standing bugs:

  - The "recheck" targets behaves better in the face of build failures
related to previously failed tests.  For example, if a test is a
compiled program that must be rerun by "make recheck", and its
compilation fails, it will still be rerun by further "make recheck"
invocations.  See automake bug#11791.

* Bugs introduced by 1.12.1:

  - Automake provides once again the '$(mkdir_p)' make variable and the
'@mkdir_p@' substitution (both as simple aliases for '$(MKDIR_P)'),
for better backward-compatibility.

-*-*-*-

* WARNING: Future backward-incompatibilities!

  - Future versions of Automake will likely drop support for the
long-deprecated 'configure.in' name for the Autoconf input file.
You are advised to use the recommended name 'configure.ac' instead.

  - The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
be removed in Automake 1.13.  The $(mkdir_p) make variable and the
@mkdir_p@ substitution will still remain available (as aliases of
$(MKDIR_P)) for the moment, for better backward compatibility.

  - Autoconf 2.65 or later will be required by the next major Automake
version (1.13).  Until now, Automake has required Autoconf version
2.62 or later.

  - Starting from the next major Automake version (1.13), the rules
to build pdf, ps and dvi output from Texinfo input will use the
'--build-dir' option by default.  Since such an option was only
introduced in Texinfo 4.9, this means that Makefiles generated by
future Automake versions will require at least that version of
Texinfo.

  - Starting from the next major Automake version (1.13), the parallel
testsuite harness (previously only enabled by the 'parallel-tests'
option) will become the default one; the older serial testsuite
harness will still be available through the use of the 'serial-tests'
option.

  - The following long-obsolete m4 macros will be removed in the
next major Automake version (1.13):

  AM_PROG_CC_STDC:superseded by AC_PROG_CC since October 2002
  fp_PROG_CC_STDC:broken alias for AM_PROG_CC_STDC
  fp_WITH_DMALLOC:old alias for AM_WITH_DMALLOC
  AM_CONFIG_HEADER:   superseded by AC_CONFIG_HEADERS since July 2002
  ud_PATH_LISPDIR:old alias for AM_PATH_LISPDIR
  jm_MAINTAINER_MODE: old alias for AM_MAINTAINER_MODE
  ud_GNU_GETTEXT: old alias for AM_GNU_GETTEXT
  gm_PROG_LIBTOOL:old alias for AC_PROG_LIBTOOL
  fp_C_PROTOTYPES:old alias for AM_C_PROTOTYPES (which was part

CVE-2012-3386 Automake security fix for 'make distcheck'

2012-07-09 Thread Stefano Lattarini 
GNU Automake 1.12.2 as well as 1.11.6 fix a locally-exploitable
security-related race condition that affects "make distcheck" for
all packages that use Automake.

Before the fix, the recipe of the 'distcheck' target granted temporary
world-write permissions on the extracted distdir.  This introduced
a locally exploitable race condition for those who run "make distcheck"
with a non-restrictive umask (e.g., 022) in a directory that was
accessible by others.  A successful exploit would result in arbitrary
code execution with the privileges of the user running "make distcheck".

It is important to stress that this vulnerability impacts not only
the Automake package itself, but all packages with Automake-generated
makefiles.  For an effective fix it is necessary to regenerate the
Makefile.in files with a fixed Automake version.

For release series older than 1.11.x, no fix has been been applied to
the the git repository, and no official new release is planned that
fixes the vulnerability.  Users interested in having such a fix in
older releases will have to apply it manually (the attached patch is
what we used on the 1.11.6 and 1.12.2 release).

The issue was found and fixed by Stefano Lattarini.  Jim Meyering
wrote a proof-of-concept script showing that the vulnerability is
easy to exploit.

>From bab7065f75bb9680df8c782da06a8312e5fa95a6 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Stefano Lattarini 
Date: Fri, 6 Jul 2012 22:43:04 +0200
Subject: [PATCH] distcheck: never make part of $(distdir) world-writable

This fixes a locally-exploitable security vulnerability (CVE-2012-3386).

In the 'distcheck' rule, we used to make the just-extracted (from
the distribution tarball) $(distdir) directory and all its files and
subdirectories read-only; then, in order to create the '_inst' and
'_build' subdirectories in there (used by the rest of the recipe) we
made the top-level $(distdir) *world-writable* for an instant (the
time to create those two directories) before making it read-only
again.

Making that directory world-writable (albeit only briefly) introduced a
locally exploitable race condition for those who run "make distcheck" with
a non-restrictive umask (e.g., 022) in a directory that is accessible by
others.  A successful exploit would result in arbitrary code execution
with the privileges of the user running "make distcheck" -- game over.
Jim Meyering wrote a proof-of-concept script showing that such exploit is
easily implemented.

This issue is similar to the CVE-2009-4029 vulnerability:


* lib/am/distdir.am (distcheck): Don't make $(distdir) world-writable,
not even for an instant; make it user-writable instead, which is enough.

Helped-By: Jim Meyering 
Signed-off-by: Stefano Lattarini 
---
 NEWS  |9 +
 lib/am/distdir.am |2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index ee16961..4975e8e 100644
--- a/NEWS
+++ b/NEWS
@@ -92,6 +92,15 @@ New in 1.12.2:
 
 Bugs fixed in 1.12.2:
 
+* SECURITY VULNERABILITIES!
+
+  - The recipe of the 'distcheck' no longer grants anymore temporary
+world-wide write permissions on the extracted distdir.  Even if such
+rights were only granted for a vanishingly small time window, the
+implied race condition proved to be enough to allow a local attacker
+to run arbitrary code with the privileges of the user running "make
+distcheck".  This is CVE-2012-3386.
+
 * Long-standing bugs:
 
   - The "recheck" targets behaves better in the face of build failures
diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index e27b650..f636a1e 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -449,7 +449,7 @@ distcheck: dist
 ## Make the new source tree read-only.  Distributions ought to work in
 ## this case.  However, make the top-level directory writable so we
 ## can make our new subdirs.
-	chmod -R a-w $(distdir); chmod a+w $(distdir)
+	chmod -R a-w $(distdir); chmod u+w $(distdir)
 	mkdir $(distdir)/_build
 	mkdir $(distdir)/_inst
 ## Undo the write access.
-- 
1.7.9.5

Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)

2012-07-09 Thread Stefano Lattarini 
Hi Dmitry.

On 07/09/2012 11:34 PM, Dmitry V. Levin wrote:
> On Mon, Jul 09, 2012 at 06:14:03PM +0200, Stefano Lattarini wrote:
>> This message announces the Automake 1.11.6 bug-fixing release.
> 
> Could you push refs/heads/branch-1.11
> 
This branch is not active anymore, having been discontinued after Automake 1.12
had been released.  Just refer to the relevant tags in the Git repository (e.g.,
for the version containing the fix for the CVE-2012-3386 vulnerability, 
v1.11.6).

> and refs/tags/v1.11.6, please?
> 
Hmm...  hasn't this been published already?  I see:

  

Or am I missing something?

Regards,
  Stefano

Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)

2012-07-09 Thread Eric Dorland 
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote:
> This message announces the Automake 1.11.6 bug-fixing release.
> 
> This release FIXES A SECURITY VULNERABILITY (CVE-2012-3386), so you are
> strongly encouraged to upgrade your existing Automake installation ASAP.
> 
> With this release, the recipe of the 'distcheck' target no longer grants
> temporary world-wide write permissions on the extracted distdir.  Even if
> such rights were only granted for a vanishingly small time window, the
> implied race condition proved to be enough to allow a local attacker to
> run arbitrary code with the privileges of the user running "make distcheck".
> 
> The fix of this security vulnerability is the only change between the
> earlier 1.11.5 release and the present 1.11.6 one.
> 
> Download the fixed release here:
> 
>   ftp://ftp.gnu.org/gnu/automake/automake-1.11.6.tar.gz
>   ftp://ftp.gnu.org/gnu/automake/automake-1.11.6.tar.xz
> 
> Please report bugs and problems to , and send
> general comments and feedback to .
> 
> Thanks to everyone who has reported problems, contributed patches,
> and helped testing Automake!

Are older versions of automake also vulnerable?

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com



signature.asc
Description: Digital signature

Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)

2012-07-09 Thread Stefano Lattarini 
On 07/10/2012 12:14 AM, Eric Dorland wrote:
> 
> Are older versions of automake also vulnerable?
> 
Yes, all those back to 1.4 (at least).  Sorry for not stating that
explicitly.

Regards,
  Stefano

Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)

2012-07-09 Thread Eric Dorland 
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote:
> On 07/10/2012 12:14 AM, Eric Dorland wrote:
> > 
> > Are older versions of automake also vulnerable?
> > 
> Yes, all those back to 1.4 (at least).  Sorry for not stating that
> explicitly.

Awesome :) Is there a diff or git commit I can look at to start the
backporting. I just happen to be at DebConf this week so the timing is
pretty good.

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com



signature.asc
Description: Digital signature

Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)

2012-07-09 Thread Stefano Lattarini 
On 07/10/2012 12:40 AM, Eric Dorland wrote:
> * Stefano Lattarini (stefano.lattar...@gmail.com) wrote:
>> On 07/10/2012 12:14 AM, Eric Dorland wrote:
>>> 
>>> Are older versions of automake also vulnerable?
>>> 
>> Yes, all those back to 1.4 (at least).  Sorry for not stating that 
>> explicitly.
> 
> Awesome :) Is there a diff or git commit I can look at to start the 
> backporting.
> 
See the attachment to:


Not sure how well that will work with older Automake releases though; while
ploughing through the 1.4 and 1.5 releases, I remember seeing several scary
"chmod -R a+w ..." as well as "chmod 777 ..." commands.  You might want to
do a more sweeping audit of those older releases if you want to actually
(try to) secure them.

> I just happen to be at DebConf this week so the timing is pretty good.
> 
Well, good work then (and as an happy Debian user I might add: keep up the
good work :-)

Regards,
  Stefano

Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)

2012-07-09 Thread Dmitry V. Levin 
On Mon, Jul 09, 2012 at 06:14:03PM +0200, Stefano Lattarini wrote:
> This message announces the Automake 1.11.6 bug-fixing release.

Could you push refs/heads/branch-1.11 and refs/tags/v1.11.6, please?


-- 
ldv


pgpSNpKS9vUsV.pgp
Description: PGP signature

Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)

2012-07-09 Thread Dmitry V. Levin 
Hi,

On Tue, Jul 10, 2012 at 12:08:38AM +0200, Stefano Lattarini wrote:
> Hi Dmitry.
> 
> On 07/09/2012 11:34 PM, Dmitry V. Levin wrote:
> > On Mon, Jul 09, 2012 at 06:14:03PM +0200, Stefano Lattarini wrote:
> >> This message announces the Automake 1.11.6 bug-fixing release.
> > 
> > Could you push refs/heads/branch-1.11
> > 
> This branch is not active anymore, having been discontinued after Automake 
> 1.12
> had been released.  Just refer to the relevant tags in the Git repository 
> (e.g.,
> for the version containing the fix for the CVE-2012-3386 vulnerability, 
> v1.11.6).
> 
> > and refs/tags/v1.11.6, please?
> > 
> Hmm...  hasn't this been published already?  I see:
> 
>   
> 
> Or am I missing something?

Thanks.  What happened is that the tag was published but it is not
referenced by any branch so "git fetch" doesn't fetch it by default.
A little surprising, but not actually a problem.


-- 
ldv


pgpk4rH0kDpc9.pgp
Description: PGP signature