A flaw was found in the way the DER (Distinguished Encoding Rules) decoder in the Security component in OpenJDK handled negative length values. A specially crafted DER encoded input could cause a Java application to enter an infinite loop when decoded.

It was discovered that the SSL/TLS implementation in the JSSE component in OpenJDK failed to properly check if the ChangeCipherSpec was received during SSL/TLS connection handshake. A man-in-the-middle attacker could possibly use this flaw to force connection to be established without encryption being enabled.

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/hsperfdatavictim directory before victim user creates it, to remove or overwrite arbitrary files with the permissions of the victim user.

There already exists the function isdirectorysecure() 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/perfMemorylinux.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 cleanupsharedmemresources() (which is called from mmapcreateshared()).

http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f8795cb3f5c1/src/os/linux/vm/perfMemorylinux.cpp#l488

Arbitrary file overwrite is possible via createsharedmemresources() via a symlink in an attacker-owned hsperdatavictim directory.

http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/f8795cb3f5c1/src/os/linux/vm/perfMemorylinux.cpp#l601

This issue is partially mitigated by the fact that attacker needs to create /tmp/hsperdatavictim 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.