New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DISCUSSION] CVE-2019-15052: Repository authentication sent to server of HTTP redirection response #10278
Comments
|
Closing this out for now. Feel free to comment if you have any questions and I'm happy to re-open this. |
|
In the case of jfrog.io, where GETs to resolve artifacts are redirected to a CDN (which also need the auth), how can we get gradle 5.6+ to work? |
|
Can you provide a bit more context here? |
|
Nvm. I thought it was causing an issue, but it was something else. Thanks! |
|
@JLLeitschuh is there any way to enable the old behavior where the credentials will be sent to the redirection response? I looked through the PR (#10176) where this change was made (after lots of googling) and couldn't see how to turn this security fix off. |
|
IIRC, no, I think we completely disabled it |
|
Thanks for letting me know. Guess I'll have to bite the bullet on this one. |
|
If the root domain always redirects, you can make the HTTPS call yourself, read the value of the 300 response, and then pass that value to Gradle. |
|
Thanks for following up. Frankly, I can't spend any more time on this. I hate giving up, but I already spent the last 2 days fighting with Gradle to upgrade several projects from v4.7 to v7.6. For now, I'll just have to use the subdomain of my Maven hosting provider instead of my own subdomain when publishing. The good news is it won't affect users. |
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:
./gradlew classes --no-daemon --refresh-dependencies400response errorThe 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 servergradle-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 security@gradle.com.
The text was updated successfully, but these errors were encountered: