Bug 1123870 (CVE-2015-0383) - CVE-2015-0383 OpenJDK: insecure hsperfdata temporary file handling (Hotspot, 8050807)
Summary: CVE-2015-0383 OpenJDK: insecure hsperfdata temporary file handling (Hotspot, ...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2015-0383
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20150120,reported=2...
Depends On:
Blocks: 1012121 1179762
TreeView+ depends on / blocked
 
Reported: 2014-07-28 13:48 UTC by Tomas Hoger
Modified: 2019-06-08 20:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2015-02-02 12:42:44 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0067 normal SHIPPED_LIVE Critical: java-1.7.0-openjdk security update 2015-01-22 02:45:27 UTC
Debian BTS 761683 None None None Never
Red Hat Product Errata RHSA-2015:0068 normal SHIPPED_LIVE Important: java-1.7.0-openjdk security update 2015-01-21 03:38:26 UTC
Red Hat Product Errata RHSA-2015:0069 normal SHIPPED_LIVE Important: java-1.8.0-openjdk security update 2015-01-22 02:38:44 UTC
Red Hat Product Errata RHSA-2015:0079 normal SHIPPED_LIVE Critical: java-1.7.0-oracle security update 2017-12-15 15:35:56 UTC
Red Hat Product Errata RHSA-2015:0080 normal SHIPPED_LIVE Critical: java-1.8.0-oracle security update 2017-12-15 15:34:38 UTC
Red Hat Product Errata RHSA-2015:0085 normal SHIPPED_LIVE Important: java-1.6.0-openjdk security update 2015-01-26 23:10:42 UTC
Red Hat Product Errata RHSA-2015:0086 normal SHIPPED_LIVE Important: java-1.6.0-sun security update 2017-12-15 15:35:12 UTC

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

Comment 19 errata-xmlrpc 2015-01-26 18:12:03 UTC
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


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