Re: [FYI] {maint} distcheck: never make part of $(distdir) world-writable

[Jim Meyering]

Stefano Lattarini wrote:
> 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:
> <http://lists.gnu.org/archive/html/automake/2009-12/msg00012.html>
>
> * lib/am/distdir.am (distcheck): Don't make $(distdir) world-writable,
> not even for an instant; make it user-writable instead, which is enough.
...
> 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)

Back when we dealt with CVE-2009-4029, I started using "umask 077"
everywhere (i.e., in .bashrc/.zshrc both as root and non-privileged),
in case something like that were to arise again.  Using such a restrictive
umask does cause trouble occasionally, when tools/packages assume a
relaxed umask, but it does protect me from this one, even when I clone
into e.g., /tmp and build+test on a shared system.