It was reported 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.
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
PHP Bug: https://bugs.php.net/bug.php?id=67390
(In reply to Remi Collet from comment #3)
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.
This issue did not affect binary PHP packages as shipped with Red Hat Enterprise Linux and Red Hat Software Collections.