Spring Security provides security services for the Spring IO Platform, available on their GitHub repository. Today we focus on the "oauth2" client, which provides an application with the capability to have users log in using their existing account at an OAuth 2.0 Provider, i.e., GitHub and Google, among others.
But what happens when we allow a single greedy user to tie up all of our resources with all of their requests? The short answer is CVE-2021-22119:
Name/Vulnerability Identifier: CVE-2021-22119
Type of Vulnerability: Uncontrolled Resource Consumption
Severity:
CVSS 3.1 Score: 7.5 / High
CVSS 3.1 Metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Components Affected:
Maven:
Org.springframework.security:spring-security-oauth2-client
Org.apache.servicemix.bundles:org.apache.servicemix.bundles.spring-security-oauth2-client
Versions:
[5.1.0.RELEASE, 5.2.11.RELEASE)
[5.3.0.RELEASE, 5.3.10.RELEASE)
[5.4.0, 5.4.7)
[5.5.0, 5.5.1)
The greedy user we mentioned? They can repeatedly send authorization requests to the application, one after another, or even write a simple script to quickly and easily fire off thousands. The application will attempt to blindly store all of them, disregarding details such as origin, state of current session, or rate.
The trick to exploiting this issue is exiting the authorization flow before it finishes, and thus leaving the request abandoned in the `AuthorizationRequestRepository.` The request will stay there until it expires but, at the moment, expiration is not enforced by the component. This leads to all abandoned requests being stored indefinitely. And eventually you'll see system resources exhausted, ultimately resulting in a Denial of Service (DoS) condition.
Resolving this vulnerability is relatively straightforward. The developers essentially reverted the vulnerable functionality, currently allowing only one authorization request per session by default. Still, the option remains to enable functionality, assuming there is a viable use case for it.
We always want applications to be secure by default. However, an option remains that could potentially make it vulnerable again unless the application itself consciously implements a mitigating control for it.
Part of the fix implemented for CVE-2021-22119. Check for configuration options before storing requests.
However, the developers are aware this is not the most ideal behavior, and have now deprecated the allowMultipleAuthorizationRequests option.
As we have seen before, many vulnerabilities come from insecure or "out-of-box" configurations. Having the knowledge and taking the time to understand the correct way to configure a service or application always pays off. Otherwise, we can easily be left exposed and vulnerable.
Something we take pride in here at Sonatype is the ability to find the true version ranges affected by an issue in their official repository source.
The official advisory states that the earliest version range affected by this CVE is 5.2.x until 5.2.11. But after our research team traced the vulnerable code back to the introduction commit, we noticed this took place earlier than that and is available in version 5.1.0.RELEASE.
The vulnerable functionality was introduced as an improvement back in 2018, and it is being fixed three years later in 2021. Large code bases can be difficult to audit or even debug, especially when a bug is found in a production environment. Not to mention how expensive it can be.
When the functionality was introduced, developers realized it was a potential issue, a memory leak, and briefly discussed it. They didn't make much of it at the time.
Our Security Research team was quick to expedite our complete deep dive research on the vulnerability, which was then published to Sonatype Intelligence and all of our products. Customers of Sonatype benefit from the following information.
The `spring-security-oauth2-client` package is vulnerable to Uncontrolled Resource Consumption. The `saveAuthorizationRequest` method in:
HttpSessionOAuth2AuthorizationRequestRepository.class
WebSessionOAuth2ServerAuthorizationRequestRepository.class
…does not limit the number of authorization requests that can be stored.
As noted above, an attacker can exploit this by sending multiple requests and eventually exhausting system resources within a single or multiple sessions, ultimately leading to a DoS condition.
We encourage users to upgrade to a version of this component that is not vulnerable to this specific issue. Note that if this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package.
Alternatively, we recommend investigating alternative components or a potential mitigating control.
If you're not yet a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Sonatype Vulnerability Scanner to quickly find out.
Finally, you can visit the Sonatype Intelligence Insights page for a deep dive into other vulnerabilities like this one. Or subscribe to automatically receive Sonatype Intelligence Insights hot off the press.