Bug 1060907 (CVE-2014-1876)
| Summary: | CVE-2014-1876 OpenJDK: insecure temporary file use in unpack200 (Libraries, 8033618) | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | ahughes, dbhole, java-qa, jerboaa, jfabriko, jkurik, jrusnack, jvanek, omajid, pfrields |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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 14:09:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1060911, 1082776 | ||
MITRE assigned CVE-2014-1876 to this issue: http://openwall.com/lists/oss-security/2014/02/08/1 (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. 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 Fixed in IcedTea6 1.13.3 and IcedTea7 2.4.7: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-April/027214.html http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-April/027222.html 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 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 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 (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 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 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 OpenJDK upstream commit: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ce81e69d561d 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 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 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 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 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 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 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 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 |
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