Security
Headlines
HeadlinesLatestCVEs

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.

CVE
#vulnerability#amazon#git#java#auth#gradle#maven

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

CVE-2022-31151

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

CVE-2019-2999: Oracle Critical Patch Update Advisory - October 2019

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

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907