<Issue Description> Spring Security OAuth versions 2.5.x prior to 2.5.2 and older unsupported versions are susceptible to a Denial-of-Service (DoS) attack via the initiation of the Authorization Request in an OAuth 2.0 Client application. A malicious user or attacker can send multiple requests initiating the Authorization Request for the Authorization Code Grant, which has the potential of exhausting system resources using a single session. This vulnerability exposes OAuth 2.0 Client applications only.

Impact

Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better fail fast as these are not allowed by the spec and could lead to HTTP request smuggling.

Failing to do the validation might cause netty to "sanitize" header names before it forward these to another remote system when used as proxy. This remote system can't see the invalid usage anymore and so not do the validation itself.

Vulnerability in the Advanced Networking Option component of Oracle Database Server. Supported versions that are affected are 12.1.0.2, 12.2.0.1 and 19c. Difficult to exploit vulnerability allows unauthenticated attacker with network access via Oracle Net to compromise Advanced Networking Option. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Advanced Networking Option, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Advanced Networking Option. Note: The July 2021 Critical Patch Update introduces a number of Native Network Encryption changes to deal with vulnerability CVE-2021-2351 and prevent the use of weaker ciphers. Customers should review: "Changes in Native Network Encryption with the July 2021 Critical Patch Update" (Doc ID 2791571.1). CVSS 3.1 Base Score 8.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H).

In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "limited" path traversal), if the calling code would use the result to construct a path value.

References:

https://www.openwall.com/lists/oss-security/2021/04/12/1 https://issues.apache.org/jira/browse/IO-556

Impact The content-length header is not correctly validated if the request only use a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1

This is a followup of https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj which did miss to fix this one case.

Patches This was fixed as part of 4.1.61.Final

Workarounds Validation can be done by the user before proxy the request by validating the header.

lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.

A flaw was found in nodejs-lodash. A Regular Expression Denial of Service (ReDoS) via the toNumber, trim and trimEnd functions is possible.

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

In Spring Framework versions 5.2.0 - 5.2.8, 5.1.0 - 5.1.17, 5.0.0 - 5.0.18, 4.3.0 - 4.3.28, and older unsupported versions, the protections against RFD attacks from CVE-2015-5211 may be bypassed depending on the browser used through the use of a jsessionid path parameter.

A flaw was found in Netty in the way it handles the amount of data it compresses and decompresses. The Compression/Decompression codecs should enforce memory allocation size limits to avoid an Out of Memory Error (OOME) or exhaustion of the memory pool.

In SQLite through 3.29.0 whereLoopAddBtreeIndex in sqlite3.c can crash a browser or other application because of missing validation of a sqlitestat1 sz field aka a "severe division by zero in the query planner."

A flaw was found in the Apache Commons BeanUtils, where the class property in PropertyUtilsBean is not suppressed by default. This flaw allows an attacker to access the classloader.

A vulnerability was found in Hibernate-Validator. The SafeHtml validator annotation fails to properly sanitize payloads consisting of potentially malicious code in HTML comments and instructions. This vulnerability can result in an XSS attack.

A Server Side Request Forgery (SSRF) vulnerability affected the Apache Axis 1.4 distribution that was last released in 2006. Security and bug commits commits continue in the projects Axis 1.x Subversion repository, legacy users are encouraged to build from source. The successor to Axis 1.x is Axis2, the latest version is 1.7.9 and is not vulnerable to this issue.

Apache Axis 1.x up to and including 1.4 is vulnerable to a cross-site scripting (XSS) attack in the default servlet/services.