Bug 1123870 (CVE-2015-0383)

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:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	ahughes, aph, dbhole, jvanek, omajid, security-response-team, sgehwolf
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-02-02 12:42:44 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:	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

Upstream OpenJDK commits:

http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/f2c4a1559fce
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/d7b6bdd51abe

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

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