Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 through Update 11, and OpenJDK 7, allows user-assisted remote attackers to bypass the Java security sandbox via unspecified vectors related to JMX, aka "Issue 52," a different vulnerability than CVE-2013-1490.
It was discovered that the XMLEntityManager class implementation in the JAXP component of OpenJDK did not properly perform access checks. A Java application using SAX XML parser in certain configuration could be tricked into disclosing information when parsing a specially-crafted XML file.
A flaw was found in the way the XMLEntityScanner and XML11EntityScanner classes in the JAXP component of OpenJDK handled and normalized newlines in XML entities. A specially-crafted XML document could cause a Java application to enter an infinite loop when parsed.
GStreamer before 1.18.4 may perform an out-of-bounds read when handling certain ID3v2 tags.
It was discovered that the Kerberos implementation in the Security component of OpenJDK used RSA-MD5 checksum in Ticket Granting Service (TGS) requests even though MD5 algorithm is no longer considered safe for such use case. A remote attacker could possibly use this flaw to manipulate TGS requests.
A flaw was found in the URL class implementation in the Networking component of OpenJDK. An incorrect check to determine if a URLStreamHandler is builtin or not can lead to incorrect URL normalization in certain cases.
Jakub Wilk reported in a Debian bug report [1] that the unpack200 program included in OpenJDK did not properly handle the logfile properly. If the the log file was unable to be opened, it would create /tmp/unpack.log instead as the fallback, but do so in an insecure manner, as shown in unpack.cpp (the below is from OpenJDK 6):
4732 void unpacker::redirectstdio() { ... 4757 #else 4758 sprintf(tmpdir,"/tmp"); 4759 sprintf(logfilename, "/tmp/unpack.log"); 4760 #endif 4761 if ((errstrm = fopen(logfilename, "a+")) != NULL) { 4762 logfile = errstrmname = saveStr(logfilename); 4763 return ; 4764 } 4765 4766 char tname = tempnam(tmpdir,"#upkg"); 4767 sprintf(logfilename, "%s", tname); 4768 if ((errstrm = fopen(logfilename, "a+")) != NULL) { 4769 logfile = errstrmname = saveStr(logfilename); 4770 return ; 4771 }
The same exists in OpenJDK 7 and 8.
This could allow a malicious local attacker to conduct local attacks, such as symlink attacks, where a file could be overwritten if the user running unpack200 had write permissions.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737562
Chris Evans discovered a memory leak flaw in LittleCms. This flaw could cause applications that use the system LittleCms library, or embed the source into their application, to crash.
Acknowledgements:
Red Hat would like to thank Chris Evans from the Google Security Team for reporting this issue.
A flaw was found in the way the RTFParser class implementation in the Swing component of OpenJDK handled memory allocations. A specially crafted Rich Text Format (RTF) file could cause a Java application using RTFParser to allocate an excessive amount of memory and possibly terminate on out-of-memory condition.
In numbers.c in libxslt 1.1.33, an xsl:number with certain format strings could lead to a uninitialized read in xsltNumberFormatInsertNumbers. This could allow an attacker to discern whether a byte on the stack contains the characters A, a, I, i, or 0, or any other character.
A flaw was found in the way the Attributes class in the Libraries component of OpenJDK performed reading of attributes with very long values from JAR file manifests. A specially-crafted JAR archive could cause a Java application reading its manifest to use excessive amount of system resources and hang.
An unspecified vulnerability in Java SE related to the Libraries component could allow an unauthenticated attacker to cause a denial of service resulting in a low availability impact using unknown attack vectors.
An unspecified vulnerability in Java SE related to the Libraries component could allow an unauthenticated attacker to cause a denial of service resulting in a low availability impact using unknown attack vectors.
A flaw was found in the Pattern class implementation in the Libraries component of OpenJDK. A specially crated input could cause the Pattern class to raise an unexpected exception while performing regular expression matching, possibly causing a Java application using the class to misbehave.
A flaw was found in the way the TIFFFaxDecompressor, TIFFLZWDecompressor, and TIFFPackBitsDecompressor classes implementations in the ImageIO component of OpenJDK handled memory allocations when processing TIFF images. A specially-crafted TIFF image with a small size could cause a Java application to allocate an excessive amount of memory when opened.
A flaw was found in the way the Hotspot component of OpenJDK generated class code. An untrusted Java application or applet could potentially use this flaw to bypass Java sandbox restrictions.
A flaw was found in the way the Hotspot component of OpenJDK handled array indexes on 64-bit x86 platform. A large index could trigger a displacement overflow in LIRGenerator::emitarrayaddress, possibly leading to an access at an invalid array position.
A flaw was found in the way the BMPImageReader class implementation in the ImageIO component of OpenJDK preformed memory allocations when reading palette information from BMP images. A specially-crafted BMP file could cause a Java application to consume an excessive amount of memory when opened.
An unspecified vulnerability in Java SE related to the Serialization component could allow an unauthenticated attacker to cause a denial of service resulting in a low availability impact using unknown attack vectors.
A flaw was found in the way the Hotspot component of OpenJDK processed classes with fields that needed to be written to in Rewriter::scanmethod(). A specially-crafted Java class file could use this flaw to crash Java virtual machine.
It was discovered that the TransformerImpl class implementation in the JAXP component of OpenJDK did not properly check access restrictions when performing URI resolution. This could possibly lead to information disclosure when performing XSLT transformations.
A flaw was found in the way the TIFFNullDecompressor class implementation in the ImageIO component of OpenJDK performed reading of uncompressed TIFF files. A specially-crafted TIFF image could cause the decompressor to create image objects with an inconsistent state due to failure to fully read the image.
An unspecified vulnerability in Java SE related to the Libraries component could allow an unauthenticated attacker to cause no confidentiality impact, high integrity impact, and no availability impact.
It was discovered that the TLS implementation in the JSSE component of OpenJDK failed to properly handle certificate chains during TLS session negotiation. A remote attacker attacker could use this flaw to affect the availability of a TLS connection (denial-of-service condition).
A flaw was found in the object reclamation process of the Hotspot JVM garbage collector in the way it enqueued references. An untrusted Java application or applet could use this flaw to possibly bypass Java sandbox restrictions and access sensitive information.
An HTML validation flaw was found in the Swing component of OpenJDK. A specially crafted HTML document could cause a Swing Java application to misbehave leading to integrity problems.
A flaw was found in the Serialization component of OpenJDK. The invokeWriteObject() method of the ObjectStreamClass method failed to catch InstantiationError exception during object stream deserialization, which could cause an unexpected exception to be raised when processing an untrusted serialized input.
An unspecified vulnerability in Oracle Java SE and Java SE Embedded related to the 2D component could allow an unauthenticated attacker to obtain sensitive information resulting in a low confidentiality impact using unknown attack vectors.
A flaw was found in the way the JSSE component of OpenJDK performed TLS server name verification. The HostnameChecker class did not check if names stored in TLS server's X.509 certificate are in the normalized form, possibly leading to an incorrect name being matched.
A flaw was found in the DerValue class in the Libraries component of OpenJDK. An incorrect implementation of the DerValue.equals() method could cause the class to raise an exception not declared to be thrown by the DerValue.