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
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