Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JGSS). Supported versions that are affected are Oracle Java SE: 17.0.4.1, 19; Oracle GraalVM Enterprise Edition: 21.3.3 and 22.2.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via Kerberos to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).
An unspecified vulnerability in Java SE related to the Security component could allow an unauthenticated attacker to cause a denial of service resulting in a low availability impact using unknown attack vectors.
Java SE is vulnerable to a denial of service, caused by a flaw in the Lightweight HTTP Server. By sending a specially-crafted request, a remote attacker could exploit this vulnerability to cause a denial of service condition.
A flaw was found in Undertow with EJB invocations. This flaw allows an attacker to generate a valid HTTP request and send it to the server on an established connection after removing the LASTCHUNK from the bytes, causing a denial of service.
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.
An unspecified vulnerability in Java SE related to the VM component could allow an unauthenticated attacker to cause no confidentiality impact, high integrity impact, and no availability impact.
It was discovered that the computeNextExponential() method in the Libraries component of OpenJDK failed to comply with the documentation, returning sometimes negative numbers.
A flaw was found in Spring Framework Applications. Applications that use STOMP over the WebSocket endpoint are vulnerable to a denial of service attack caused by an authenticated user.
An unspecified vulnerability in Java SE related to the JNDI component could allow an unauthenticated attacker to cause no confidentiality impact, low integrity impact, and no availability impact.
An unspecified vulnerability in Java SE related to the Libraries component could allow an unauthenticated attacker to cause no confidentiality impact, low integrity impact, and no availability impact.
Eclipse Jetty is vulnerable to a denial of service, caused by an error related to some of the production servers spiking with CPU use. A remote attacker could exploit this vulnerability to consume CPU that remains high even without any traffic.
An unspecified vulnerability in Java SE related to the JAXP component could allow an unauthenticated attacker to cause a denial of service resulting in a low availability impact using unknown attack vectors.
Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 7u321, 8u311, 11.0.13; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).
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 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.
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.
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 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.
An integer overflow flaw was found in the fix applied to the BMPImageReader class implementation in the ImageIO component of OpenJDK to address the CVE-2021-35586 (bug 2015308) issue. This issue could allow a specially-crafted BMP image to bypass previously applied protection and cause a Java application to allocate 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 no confidentiality impact, low integrity impact, and no availability impact.
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.
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.
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.
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.
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.
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.
Impact
When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled.
The CVSSv3.1 score of this vulnerability is calculated to be a 6.2/10
Vulnerability Details
On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems.
The method File.createTempFile on unix-like systems creates a random file, but, by default will create this file with the permissions -rw-r--r--. Thus, if sensitive information is written to this file, other local users can read this information.
This is the case in netty's AbstractDiskHttpData is vulnerable.
https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L80-L101
AbstractDiskHttpData is used as a part of the DefaultHttpDataFactory class which is used by HttpPostRequestDecoder / HttpPostMultiPartRequestDecoder.
You may be affected by this vulnerability your project contains the following code patterns:
java channelPipeline.addLast(new HttpPostRequestDecoder(...));
java channelPipeline.addLast(new HttpPostMultiPartRequestDecoder(...));
Patches
This has been patched in version 4.1.59.Final.
Workarounds
Specify your own java.io.tmpdir when you start the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.
References
- CWE-378: Creation of Temporary File With Insecure Permissions - CWE-379: Creation of Temporary File in Directory with Insecure Permissions
Similar Vulnerabilities
Similar, but not the same.
- JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - Google Guava - https://github.com/google/guava/issues/4011 - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824
For more information If you have any questions or comments about this advisory: Open an issue in netty Email us here
Original Report
Hi Netty Security Team, I've been working on some security research leveraging custom CodeQL queries to detect local information disclosure vulnerabilities in java applications. This was the result from running this query against the netty project: https://lgtm.com/query/7723301787255288599/ Netty contains three local information disclosure vulnerabilities, so far as I can tell. One is here, where the private key for the certificate is written to a temporary file. https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L316-L346 One is here, where the certificate is written to a temporary file. https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/handler/src/main/java/io/netty/handler/ssl/util/SelfSignedCertificate.java#L348-L371 The final one is here, where the 'AbstractDiskHttpData' creates a temporary file if the getBaseDirectory() method returns null. I believe that 'AbstractDiskHttpData' is used as a part of the file upload support? If this is the case, any files uploaded would be similarly vulnerable. https://github.com/netty/netty/blob/e5951d46fc89db507ba7d2968d2ede26378f0b04/codec-http/src/main/java/io/netty/handler/codec/http/multipart/AbstractDiskHttpData.java#L91 All of these vulnerabilities exist because File.createTempFile(String, String) will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set. It is my understanding that when java creates a file, by default, and using this method, the permissions on that file utilize the umask. In a majority of cases, this means that the file that java creates has the permissions: -rw-r--r--, thus, any other local user on that system can read the contents of that file. Impacted OS: - Any OS where the system temporary directory is shared between multiple users. This is not the case for MacOS or Windows. Mitigation. Moving to the Files API instead will fix this vulnerability. https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#createTempFile-java.nio.file.Path-java.lang.String-java.lang.String-java.nio.file.attribute.FileAttribute...- This API will explicitly set the posix file permissions to something safe, by default. I recently disclosed a similar vulnerability in JUnit 4: https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp If you're also curious, this vulnerability in Jetty was also mine, also involving temporary directories, but is not the same vulnerability as in this case. https://github.com/eclipse/jetty.project/security/advisories/GHSA-g3wg-6mcf-8jj6 I would appreciate it if we could perform disclosure of this vulnerability leveraging the GitHub security advisories feature here. GitHub has a nice credit system that I appreciate, plus the disclosures, as you can see from the sampling above, end up looking very nice. https://github.com/netty/netty/security/advisories This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. Cheers, Jonathan Leitschuh
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.