Skip to content
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

Closed
JLLeitschuh opened this issue Aug 14, 2019 · 9 comments

Comments

@JLLeitschuh
Copy link
Contributor

JLLeitschuh commented Aug 14, 2019

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:

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.

gradlew-failed-build

Request and response to my fake Maven repository:

repo-request

repo-reponse

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.

redirect-request

redirect-response

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.

@JLLeitschuh
Copy link
Contributor Author

Closing this out for now. Feel free to comment if you have any questions and I'm happy to re-open this.

@big-guy big-guy closed this as completed Feb 7, 2020
@wakingrufus
Copy link

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?

@JLLeitschuh
Copy link
Contributor Author

Can you provide a bit more context here?

@wakingrufus
Copy link

Nvm. I thought it was causing an issue, but it was something else. Thanks!

@DeleTaylor
Copy link

@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.

@JLLeitschuh
Copy link
Contributor Author

IIRC, no, I think we completely disabled it

@DeleTaylor
Copy link

Thanks for letting me know. Guess I'll have to bite the bullet on this one.

@JLLeitschuh
Copy link
Contributor Author

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.

@DeleTaylor
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants