Red Hat Bugzilla – Bug 1104978
CVE-2014-3981 php: insecure temporary file use in the configure script
Last modified: 2015-07-31 03:21:23 EDT
It was reported[1] to the full-disclosure mailing list that PHP's configure script uses a predictable filename in /tmp/, "/tmp/phpglibccheck". A local attacker could use this flaw to perform a symbolic link attack against a user building the source RPM or running the configure script. [1] http://seclists.org/fulldisclosure/2014/Jun/21
Created php tracking bugs for this issue: Affects: fedora-all [bug 1104981]
CVE request: http://www.openwall.com/lists/oss-security/2014/06/05/14
CVE-2014-3981 PHP Bug: https://bugs.php.net/bug.php?id=67390 commit: http://git.php.net/?p=php-src.git;a=commitdiff;h=91bcadd85e20e50d3f8c2e9721327681640e6f16
(In reply to Remi Collet from comment #3) > http://git.php.net/?p=php-src.git;a=commitdiff;h=91bcadd The above upstream commit replaced fixed file name with a tmpnam(NULL) call. While this makes it harder to predict temporary file name, it does not fully block the issue. Quoting tmpnam(3) man page for further details: Although tmpnam() generates names that are difficult to guess, it is nevertheless possible that between the time that tmpnam() returns a pathname, and the time that the program opens it, another program might create that pathname using open(2), or create it as a symbolic link. This can lead to security holes. To avoid such possibilities, use the open(2) O_EXCL flag to open the pathname. Or better yet, use mkstemp(3) or tmpfile(3) I assume this make get an incomplete fix CVE if updates are released with the above fix.
This problem is in the configure script, which is only executed when compiling PHP. Therefore, this issue does not affect binary packages distributed as part of Red Hat products (or Fedora), and has no impact on customer deployments. This can only affect users rebuilding php packages from source. There is no plan to release Red Hat Security Advisory for this issue. Future product versions, based on fixed upstream PHP versions, are likely to contain the fix in their source code. Statement: This issue did not affect binary PHP packages as shipped with Red Hat Enterprise Linux and Red Hat Software Collections.