|Summary:||CVE-2015-0383 OpenJDK: insecure hsperfdata temporary file handling (Hotspot, 8050807)|
|Product:||[Other] Security Response||Reporter:||Tomas Hoger <thoger>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||ahughes, aph, dbhole, jvanek, omajid, security-response-team, sgehwolf|
|Fixed In Version:||Doc Type:||Bug Fix|
Multiple insecure temporary file use issues were found in the way the Hotspot component in OpenJDK created performance statistics and error log files. A local attacker could possibly make a victim using OpenJDK overwrite arbitrary files using a symlink attack.
|Last Closed:||2015-02-02 12:42:44 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1012121, 1179762|
Description Tomas Hoger 2014-07-28 13:48:26 UTC
Multiple flaws were discovered in the way the Hotspot Java Virtual Machine, that is part of OpenJDK and Oracle Java SE, handled performance data temporary files. On Linux systems, these files are created in /tmp/hsperfdata_<user> directories. However, the code did not properly check permissions and ownership of existing directories, making it possible for local attackers, able to create /tmp/hsperfdata_victim directory before victim user creates it, to remove or overwrite arbitrary files with the permissions of the victim user. There already exists the function is_directory_secure() that is used to check if existing /tmp/hsperfdata_<user> directory is safe to use. It ensures it really is directory and that it isn't group or world writable. However, no ownership check is performed. http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f8795cb3f5c1/src/os/linux/vm/perfMemory_linux.cpp#l200 The missing ownership check, combined with a race to replace an attacker-owned hsperfdata directory with a symlink, can be used to remove arbitrary files in cleanup_sharedmem_resources() (which is called from mmap_create_shared()). http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f8795cb3f5c1/src/os/linux/vm/perfMemory_linux.cpp#l488 Arbitrary file overwrite is possible via create_sharedmem_resources() via a symlink in an attacker-owned hsperdata_victim directory. http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f8795cb3f5c1/src/os/linux/vm/perfMemory_linux.cpp#l601 This issue is partially mitigated by the fact that attacker needs to create /tmp/hsperdata_victim directory before victim user first runs JVM, as the hsperfdata directory is not removed on JVM exit, only JVM id / pid file is removed. On systems that use tmpfs for /tmp, or use other ways to clean up /tmp directory on every reboot, this mitigation is likely to have very limited impact. Another way to mitigate this issue is to run java with -XX:-UsePerfData option, which disables the performance monitoring feature and prevents creation of hsperfdata directory and files. This prevents tools as jstat (JVM statistics monitoring tool) from being able to get performance data.
Comment 1 Tomas Hoger 2014-07-28 13:51:27 UTC
Note that hsperfdata directory is always created in /tmp. The java.io.tmpdir property was honored as some point in past, but the change was reverted as it prevented monitoring tools form being able to find performance data: http://bugs.java.com/view_bug.do?bug_id=6447182 http://bugs.java.com/view_bug.do?bug_id=6938627 http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/a2ea687fdc7c http://bugs.java.com/view_bug.do?bug_id=7009828 http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/34d64ad817f4
Comment 2 Tomas Hoger 2014-07-28 14:00:41 UTC
The jstat tool also uses rather fragile method to locate performance data file for the specified JVM id / pid. It check all /tmp/hsperfdata_* directories, and uses the newest /tmp/hsperfdata_*/<pid> file. Therefore, local attacker can easily make jstat open incorrect (attacker-owned) file and supply incorrect performance statistics data.
Comment 5 jiri vanek 2014-07-28 16:34:51 UTC
hmm. Isn't this http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/013965.html the same? See the discussion why they revoke the fix....
Comment 6 Tomas Hoger 2014-07-28 19:33:27 UTC
This is different issue, as this affects hsperfdata directory that is created by default on every JVM run (unless explicitly disabled as described in comment 0). The concern you raised is about log files created on JVM crash, and is related to the file permissions and the leak of sensitive data. Upstream responded that the use of proper umask is the expected way to avoid the problem. I do not know if this guidance is provided anywhere in the documentation, but I agree that defaulting to more restrictive permissions at least when dumping to /tmp is reasonable. This issue is about other type of issues in handling of temporary files that lead to arbitrary file overwrites and removal, and that can not be avoided by restrictive umask setting.
Comment 9 Tomas Hoger 2015-01-16 12:52:08 UTC
Acknowledgment: This issue was discovered by Red Hat.
Comment 10 Tomas Hoger 2015-01-20 22:07:02 UTC
Public now via Oracle Critical Patch Update - January 2015. Fixed in Oracle Java SE 5.0u81, 6u91, 7u75, and 8u31. External References: http://www.oracle.com/technetwork/topics/security/cpujan2015-1972971.html#AppendixJAVA
Comment 11 errata-xmlrpc 2015-01-20 22:39:17 UTC
This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Via RHSA-2015:0068 https://rhn.redhat.com/errata/RHSA-2015-0068.html
Comment 12 errata-xmlrpc 2015-01-21 22:45:50 UTC
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2015:0069 https://rhn.redhat.com/errata/RHSA-2015-0069.html
Comment 13 errata-xmlrpc 2015-01-21 22:58:50 UTC
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Via RHSA-2015:0067 https://rhn.redhat.com/errata/RHSA-2015-0067.html
Comment 14 Tomas Hoger 2015-01-22 09:59:17 UTC
Comment 15 errata-xmlrpc 2015-01-22 21:24:27 UTC
This issue has been addressed in the following products: Oracle Java for Red Hat Enterprise Linux 6 Via RHSA-2015:0080 https://rhn.redhat.com/errata/RHSA-2015-0080.html
Comment 16 errata-xmlrpc 2015-01-22 21:35:03 UTC
This issue has been addressed in the following products: Oracle Java for Red Hat Enterprise Linux 7 Oracle Java for Red Hat Enterprise Linux 5 Oracle Java for Red Hat Enterprise Linux 6 Via RHSA-2015:0079 https://rhn.redhat.com/errata/RHSA-2015-0079.html
Comment 17 Tomas Hoger 2015-01-26 14:53:03 UTC
This issue was fixed in IcedTea6 1.13.6 and IcedTea7 2.5.4: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-January/030488.html http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-January/030469.html
Comment 18 errata-xmlrpc 2015-01-26 17:28:13 UTC
This issue has been addressed in the following products: Oracle Java for Red Hat Enterprise Linux 7 Oracle Java for Red Hat Enterprise Linux 6 Oracle Java for Red Hat Enterprise Linux 5 Via RHSA-2015:0086 https://rhn.redhat.com/errata/RHSA-2015-0086.html