Bug 1104978 (CVE-2014-3981) - CVE-2014-3981 php: insecure temporary file use in the configure script
Summary: CVE-2014-3981 php: insecure temporary file use in the configure script
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2014-3981
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20140604,reported=2...
Depends On: 1104981
Blocks: 1104983
TreeView+ depends on / blocked
 
Reported: 2014-06-05 07:13 UTC by Murray McAllister
Modified: 2019-06-08 20:04 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-09 12:57:30 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
PHP Bug Tracker 67390 None None None Never

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.

Statement:

This issue did not affect binary PHP packages as shipped with Red Hat Enterprise Linux and Red Hat Software Collections.


Note You need to log in before you can comment on or make changes to this bug.