Important security update in Gradle 5.6
Gradle 5.6 contains an important security update for some users.
Thank you to Uriah Carpenter for reporting this issue to us.
What kind of vulnerability is it? Who is impacted?
This is an information disclosure vulnerability (CWE-522: Insufficiently Protected Credentials) for the Gradle Build tool. This is tracked by CVE-2019-15052.
Anyone using the Gradle build tool to resolve dependencies against a custom authenticated repository may be vulnerable. Gradle may leak authentication data to third parties.
When authenticating to a repository host, Gradle sends authentication headers first to the host in the initial repository URL, but in the case of a redirect (30X HTTP response code), Gradle also sends the authentication headers to the redirect host. Authentication headers often contain privacy sensitive information or data that could allow others to impersonate the user.
We are not aware of any exploits of this flaw.
Am I Vulnerable?
Below are a few scenarios to help users determine if they are vulnerable.
You are vulnerable if and only if the repository Gradle uses requires authentication to access AND the repository redirects your requests to another host out of your control.
Using a Built-In Repository
If you are only using public repositories like mavenCentral()
, jcenter()
, gradlePluginPortal()
, or google()
you are not vulnerable.
Example:
repositories {
mavenCentral()
}
Using a Custom Repository
If you are using a custom repository that does not require authentication, you are not vulnerable.
Example:
// Maven
repositories {
maven {
url = "https://public-repository.some-company.example/repo"
}
}
// Ivy
repositories {
ivy {
url = "https://public-repository.some-company.example/repo"
}
}
Using a Custom Repository with Credentials
If you are using a custom repository that requires credentials you may be vulnerable.
// Maven
repositories {
maven {
url = "https://repository.some-company.example/repo"
credentials {
// We don't recommend hard coding credentials, this is just an example
username "my-user-name"
password "my-password"
}
}
}
// Ivy
repositories {
ivy {
url = "https://repository.some-company.example/repo"
credentials {
// We don't recommend hard coding credentials, this is just an example
username "my-user-name"
password "my-password"
}
}
}
In the above example, if the repository hosted on some-company.example
redirects to host another-company.example
, Gradle will erroneously send the authentication information for some-company.example
to another-company.example
too. The behavior of this depends on how the repository at some-company.example
is configured.
Has the problem been patched? What versions should users upgrade to?
Gradle 5.6 has been patched to fix this issue.
I can't upgrade. Is there anything I can do?
Unfortunately, this vulnerability is in the Gradle codebase and there are no simple flags to disable this behavior.
If you are affected by this vulnerability and cannot upgrade, we recommend that you do not proxy external repositories from the same repository that requires authentication.
In the example below, if repository.some-company.example/repo
serves your organization's internal artifacts as well as proxies Maven Central via redirects, you would be vulnerable. To workaround the vulnerability, you can configure your repository to no longer proxy Maven Central and split your repository declaration into two repositories:
// NOTE: Maven or Ivy would work for this
repositories {
maven {
url = "https://repository.some-company.example/repo"
credentials {
// We don't recommend hard coding credentials, this is just an example
username "my-user-name"
password "my-password"
}
}
mavenCentral()
}
Since your custom repository no longer redirects to another host, Gradle will not send authentication headers to other hosts.
Alternatively, if you trust the repositories that your repository redirects to, you can continue to use an older version of Gradle and follow good security practices:
- Do not share the credentials for your repository with any other critical service
- Prevent remote access from outside your organization to your repository via network configuration
For more information
For security related issues, please email us at security@gradle.com.
For non-security related issues, please open an issue on Github.
Important security update in Gradle 5.6
Gradle 5.6 contains an important security update for some users.
Thank you to Uriah Carpenter for reporting this issue to us.
What kind of vulnerability is it? Who is impacted?
This is an information disclosure vulnerability (CWE-522: Insufficiently Protected Credentials) for the Gradle Build tool. This is tracked by CVE-2019-15052.
Anyone using the Gradle build tool to resolve dependencies against a custom authenticated repository may be vulnerable. Gradle may leak authentication data to third parties.
When authenticating to a repository host, Gradle sends authentication headers first to the host in the initial repository URL, but in the case of a redirect (30X HTTP response code), Gradle also sends the authentication headers to the redirect host. Authentication headers often contain privacy sensitive information or data that could allow others to impersonate the user.
We are not aware of any exploits of this flaw.
Am I Vulnerable?
Below are a few scenarios to help users determine if they are vulnerable.
You are vulnerable if and only if the repository Gradle uses requires authentication to access AND the repository redirects your requests to another host out of your control.
Using a Built-In Repository
If you are only using public repositories like
mavenCentral()
,jcenter()
,gradlePluginPortal()
, orgoogle()
you are not vulnerable.Example:
Using a Custom Repository
If you are using a custom repository that does not require authentication, you are not vulnerable.
Example:
Using a Custom Repository with Credentials
If you are using a custom repository that requires credentials you may be vulnerable.
In the above example, if the repository hosted on
some-company.example
redirects to hostanother-company.example
, Gradle will erroneously send the authentication information forsome-company.example
toanother-company.example
too. The behavior of this depends on how the repository atsome-company.example
is configured.Has the problem been patched? What versions should users upgrade to?
Gradle 5.6 has been patched to fix this issue.
I can't upgrade. Is there anything I can do?
Unfortunately, this vulnerability is in the Gradle codebase and there are no simple flags to disable this behavior.
If you are affected by this vulnerability and cannot upgrade, we recommend that you do not proxy external repositories from the same repository that requires authentication.
In the example below, if
repository.some-company.example/repo
serves your organization's internal artifacts as well as proxies Maven Central via redirects, you would be vulnerable. To workaround the vulnerability, you can configure your repository to no longer proxy Maven Central and split your repository declaration into two repositories:Since your custom repository no longer redirects to another host, Gradle will not send authentication headers to other hosts.
Alternatively, if you trust the repositories that your repository redirects to, you can continue to use an older version of Gradle and follow good security practices:
For more information
For security related issues, please email us at security@gradle.com.
For non-security related issues, please open an issue on Github.