Bug 1060907 - (CVE-2014-1876) CVE-2014-1876 OpenJDK: insecure temporary file use in unpack200 (Libraries, 8033618)
CVE-2014-1876 OpenJDK: insecure temporary file use in unpack200 (Libraries, 8...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20140203,reported=2...
: Security
Depends On:
Blocks: 1060911 1082776
  Show dependency treegraph
 
Reported: 2014-02-03 16:43 EST by Vincent Danen
Modified: 2014-09-08 03:05 EDT (History)
9 users (show)

See Also:
Fixed In Version: icedtea 1.13.3, icedtea 2.4.7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-10 10:09:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Debian BTS 737562 None None None Never

  None (edit)
Description Vincent Danen 2014-02-03 16:43:28 EST
Jakub Wilk reported in a Debian bug report [1] that the unpack200 program included in OpenJDK did not properly handle the logfile properly.  If the the log file was unable to be opened, it would create /tmp/unpack.log instead as the fallback, but do so in an insecure manner, as shown in unpack.cpp (the below is from OpenJDK 6):

4732 void unpacker::redirect_stdio() {
...
4757 #else
4758     sprintf(tmpdir,"/tmp");
4759     sprintf(log_file_name, "/tmp/unpack.log");
4760 #endif
4761     if ((errstrm = fopen(log_file_name, "a+")) != NULL) {
4762       log_file = errstrm_name = saveStr(log_file_name);
4763       return ;
4764     }
4765
4766     char *tname = tempnam(tmpdir,"#upkg");
4767     sprintf(log_file_name, "%s", tname);
4768     if ((errstrm = fopen(log_file_name, "a+")) != NULL) {
4769       log_file = errstrm_name = saveStr(log_file_name);
4770       return ;
4771     }

The same exists in OpenJDK 7 and 8.

This could allow a malicious local attacker to conduct local attacks, such as symlink attacks, where a file could be overwritten if the user running unpack200 had write permissions.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737562
Comment 1 Vincent Danen 2014-02-07 19:58:19 EST
MITRE assigned CVE-2014-1876 to this issue:

http://openwall.com/lists/oss-security/2014/02/08/1
Comment 2 Tomas Hoger 2014-02-28 07:35:09 EST
(In reply to Vincent Danen from comment #0)
> If the the log file was unable to be opened, it would create /tmp/unpack.log
> instead as the fallback, but do so in an insecure manner

There are actually multiple fallbacks.  Following is tried when unpacking, proceeding to the next if the current one fails:

- open log file that was specified on the command line using -l / --log-file option
- open /tmp/unpack.log
- use tmpnam() to generate unique filename with the pattern /tmp/#upkgXXXXXX, this file is also opened insecurely
- open /dev/null
- use stderr for logging

This has a rather limited impact.  Issue can only be triggered when user runs unpack200 with -l / / --log-file option with argument being a file that can not be created by unpack200 (e.g. file in a directory that does not exist or is not writable to the user running it, or file that already exists and can not be overwritten).

This issue currently remains unfixed upstream (it still exists in jdk9 hg).  The easy fix is to remove fallback to /tmp/unpack.log.  Fallback to tmpnam() generated temporary file should either be removed too, or replaced by safer variant (e.g. using mkstemp()).

Issue exists in all currently supported versions of OpenJDK, Oracle/Sun JDK, and IBM JDK shipped as part of Red Hat Enterprise Linux.
Comment 4 Tomas Hoger 2014-04-15 16:38:03 EDT
Fixed now in Oracle Java SE 5.0u75, 6u75, 7u55 and 8u5 via Oracle Critical Patch Update Advisory - April 2014.

External References:

http://www.oracle.com/technetwork/topics/security/cpuapr2014-1972952.html#AppendixJAVA
Comment 6 errata-xmlrpc 2014-04-16 07:24:18 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2014:0407 https://rhn.redhat.com/errata/RHSA-2014-0407.html
Comment 7 errata-xmlrpc 2014-04-16 07:31:46 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2014:0406 https://rhn.redhat.com/errata/RHSA-2014-0406.html
Comment 8 errata-xmlrpc 2014-04-16 07:35:30 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 6

Via RHSA-2014:0408 https://rhn.redhat.com/errata/RHSA-2014-0408.html
Comment 9 Tomas Hoger 2014-04-16 08:25:02 EDT
(In reply to Tomas Hoger from comment #2)
> The easy fix is to remove fallback to /tmp/unpack.log.  Fallback to tmpnam()
> generated temporary file should either be removed too, or replaced by safer
> variant (e.g. using mkstemp()).

Upstream fix implements this proposal and removes fall back to hard-coded log file name, or logging to file with name generated using tmpnam():

http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ce81e69d561d
Comment 10 errata-xmlrpc 2014-04-17 05:30:59 EDT
This issue has been addressed in following products:

  Oracle Java for Red Hat Enterprise Linux 6
  Oracle Java for Red Hat Enterprise Linux 5

Via RHSA-2014:0413 https://rhn.redhat.com/errata/RHSA-2014-0413.html
Comment 11 errata-xmlrpc 2014-04-17 05:33:59 EDT
This issue has been addressed in following products:

  Supplementary for Red Hat Enterprise Linux 6
  Supplementary for Red Hat Enterprise Linux 5

Via RHSA-2014:0412 https://rhn.redhat.com/errata/RHSA-2014-0412.html
Comment 12 Stefan Cornelius 2014-04-17 06:33:29 EDT
OpenJDK upstream commit:
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ce81e69d561d
Comment 13 errata-xmlrpc 2014-04-17 07:45:45 EDT
This issue has been addressed in following products:

  Oracle Java for Red Hat Enterprise Linux 6
  Oracle Java for Red Hat Enterprise Linux 5

Via RHSA-2014:0414 https://rhn.redhat.com/errata/RHSA-2014-0414.html
Comment 14 errata-xmlrpc 2014-05-13 15:48:18 EDT
This issue has been addressed in following products:

  Supplementary for Red Hat Enterprise Linux 5
  Supplementary for Red Hat Enterprise Linux 6

Via RHSA-2014:0486 https://rhn.redhat.com/errata/RHSA-2014-0486.html
Comment 15 errata-xmlrpc 2014-05-15 13:29:40 EDT
This issue has been addressed in following products:

  Supplementary for Red Hat Enterprise Linux 5
  Supplementary for Red Hat Enterprise Linux 6

Via RHSA-2014:0508 https://rhn.redhat.com/errata/RHSA-2014-0508.html
Comment 16 errata-xmlrpc 2014-05-15 14:22:39 EDT
This issue has been addressed in following products:

  Supplementary for Red Hat Enterprise Linux 5
  Supplementary for Red Hat Enterprise Linux 6

Via RHSA-2014:0509 https://rhn.redhat.com/errata/RHSA-2014-0509.html
Comment 17 errata-xmlrpc 2014-06-10 08:17:58 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 7

Via RHSA-2014:0675 https://rhn.redhat.com/errata/RHSA-2014-0675.html
Comment 18 errata-xmlrpc 2014-06-10 08:39:01 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 7

Via RHSA-2014:0685 https://rhn.redhat.com/errata/RHSA-2014-0685.html
Comment 19 errata-xmlrpc 2014-06-10 09:14:16 EDT
This issue has been addressed in following products:

  Supplementary for Red Hat Enterprise Linux 7

Via RHSA-2014:0705 https://rhn.redhat.com/errata/RHSA-2014-0705.html
Comment 20 errata-xmlrpc 2014-07-29 11:42:19 EDT
This issue has been addressed in following products:

  Red Hat Network Satellite Server v 5.4
  Red Hat Network Satellite Server v 5.5
  Red Hat Satellite Server v 5.6

Via RHSA-2014:0982 https://rhn.redhat.com/errata/RHSA-2014-0982.html

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