Bug 1104978 (CVE-2014-3981)

Summary: CVE-2014-3981 php: insecure temporary file use in the configure script
Product: [Other] Security Response Reporter: Murray McAllister <mmcallis>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: fedora, jkurik, jorton, jrusnack, mmaslano, rcollet, vdanen, webstack-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-09 12:57:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1104981    
Bug Blocks: 1104983    

Description Murray McAllister 2014-06-05 07:13:23 UTC
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

Comment 1 Murray McAllister 2014-06-05 07:15:42 UTC
Created php tracking bugs for this issue:

Affects: fedora-all [bug 1104981]

Comment 2 Murray McAllister 2014-06-05 07:57:30 UTC
CVE request: http://www.openwall.com/lists/oss-security/2014/06/05/14

Comment 4 Tomas Hoger 2014-06-09 12:45:43 UTC
(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.

Comment 5 Tomas Hoger 2014-06-09 12:57:30 UTC
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.