Headline
CVE-2019-15052: [DISCUSSION] CVE-2019-15052: Repository authentication sent to server of HTTP redirection response · Issue #10278 · gradle/gradle
The HTTP client in Gradle before 5.6 sends authentication credentials originally destined for the configured host. If that host returns a 30x redirect, Gradle also sends those credentials to all subsequent hosts that the request redirects to. This is similar to CVE-2018-1000007.
This issue is to discuss CVE-2019-15052 and answer any questions that people may have.
Our official advisory can be found here: GHSA-4cwg-f7qc-6r95
CVSSv3 Score
We believe that this vulnerability will receive the same CVSSv3 score as the cURL vulnerability listed below.
As such, we have provided the following estimated scoring:
CVSS v3.0 Severity and Metrics:
Base Score: 9.8 CRITICAL
Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Impact Score: 5.9
Exploitability Score: 3.9
Additional context
cURL had this same vulnerability which was fixed in cURL v7.58.0
Their disclosure can be found here:
https://curl.haxx.se/docs/CVE-2018-1000007.html
Original Report
Below is the contents of the original vulnerability disclosure reported by @uriahcarpenter.
Expected Behavior
If basic authentication is configured for a Maven repository credentials are only sent to the hostname configured.
Current Behavior
If the Maven repository responds with an HTTP redirection response (e.g. 302/304/307) to a different hostname Gradle includes the basic authorization header. Some may consider this an information disclosure security issue.
Context
Some Maven repositories may perform HTTP redirects to serve large-binaries from via a CDN; an example of this is Artifactory’s Direct Cloud Storage Download feature. This Artifactory feature ultimately uses a S3 signed URL as a HTTP redirect. However the S3 request fails because there is authorization in the URL and Gradle sends the unrelated basic authentication header.
Steps to Reproduce
I have created a full working example of this issue:
- Clone https://github.com/Widen/gradle-s3
- Execute ./gradlew classes --no-daemon --refresh-dependencies
- Build will fail with a 400 response error
The underlaying cause of the 400 error is slightly difficult to diagnose because Gradle does not output the text of the response, so I’m including screen shots of the request and responses using a local HTTP proxy.
Request and response to my fake Maven repository:
Request and response to S3 URL. Note the actual bug is that the header Authorization = Basic Zm9vOmJheg== is being sent to the server gradle-s3-auth-issue.s3.amazonaws.com.
Environment
Sample project is configured to use the latest Gradle release; 5.5.1.
Please feel free to leave any questions you may have below.
Please report any new security vulnerabilities to [email protected].
Related news
Authorization headers are cleared on cross-origin redirect. However, cookie headers which are sensitive headers and are official headers found in the spec, remain uncleared. There are active users using cookie headers in undici. This may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the 3rd party site. This was patched in v5.7.1. By default, this vulnerability is not exploitable. Do not enable redirections, i.e. `maxRedirections: 0` (the default).
Vulnerability in the Java SE product of Oracle Java SE (component: Javadoc). Supported versions that are affected are Java SE: 7u231, 8u221, 11.0.4 and 13. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE accessible data as well as unauthorized read access to a subset of Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Ja...