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.
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
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.
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....
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.
Acknowledgment: This issue was discovered by Red Hat.
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
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
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
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
Upstream OpenJDK commits: http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f2c4a1559fce http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/d7b6bdd51abe
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
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
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
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
This issue has been addressed in the following products: Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Via RHSA-2015:0085 https://rhn.redhat.com/errata/RHSA-2015-0085.html