It was discovered [1] that there's an issue in how automake handles temp directories. When the destination directory does not exist, install-sh checks if "mkdir -p" works, but it does so in an insecure way. Here are the relevant parts of the code: mkdirprog=${MKDIRPROG-mkdir} # ... tmpdir=${TMPDIR-/tmp}/ins$RANDOM-$$ trap 'ret=$?; rmdir "$tmpdir/d" "$tmpdir" 2>/dev/null; exit $ret' 0 if (umask $mkdir_umask && exec $mkdirprog $mkdir_mode -p -- "$tmpdir/d") >/dev/null 2>&1 then # ... rmdir "$tmpdir/d" "$tmpdir" else # ... In some shells (such as dash) $RANDOM is not set, so $tmpdir is easily predictable. Moreover, "mkdir -p" follows symlinks to existing directories. Local attacker can exploit this to create or remove empty directories named "d". (But on modern Linux systems this is mitigated by the protected_symlinks feature.) Same code exists in RHEL6 and RHEL7 versions of automake. Default shell is bash in RHEL, so this is Low priority issue. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760455
Created attachment 936942 [details] Firstly create the test directory, then check for mkdir -p Thanks for forwarding this bug report. Would attached patch resolve your concerns? I'll forward this discussion upstream afterwards. Note that as this is in automake from cca 2006, applying this downstream only would result just only in unnecessary risk. Why I think the fix should be OK: - this is all about low prio check, if attacker is able to guess the test directory, we simply fail the check and install-sh is not going to use 'mkdir -p' (will step-by-step directory creation) - once $tmpdir is created, we know that nobody should be able to write to that directory (note the $mkdir_umask) and create nasty symlinks or whatever - using $RANDOM now should not hurt even in dash - when $RANDOM is empty (or having some non-random value), it just increases the chance of collision - sadly, another process (mkdir) was needed Thanks for any comments, Pavel
Original reporter here. The patch looks good to me, thanks!
Upstream proposal: http://www.mail-archive.com/automake-patches@gnu.org/msg07704.html