Bazel: incompatible_disallow_unverified_http_downloads: ignore plain `http` URLs (as opposed to `https` URLs) when downloading a file without given hash

Created on 11 Jun 2019  路  12Comments  路  Source: bazelbuild/bazel

mitm_build
Want to take over the Java ecosystem? All you need is a MITM!

The details in the blog post above describe my research over the past 4 months into the use of HTTP to resolve dependencies across the JVM ecosystem.

This vulnerability impacted the open source build infrastructure for organizations like the Apache Foundation, Eclipse Foundation, Jenkins, JetBrains, RedHat, ect...

One of the cases where I discovered this vulnerability was in the build infrastructure for some of Stripe's open source projects. They were declaring jar dependencies without an SHA checksum. Thus a MITM of their Bazel build could have allowed for the malicious compromise of their artifacts. For this finding, I was awarded a bug bounty by their security team.

I believe that it's the responsibility of API authors, especially of build tools to help protect their users from careless security vulnerabilities like this.

As such, I've begun work on fixing this for all users of Gradle in this PR:
https://github.com/gradle/gradle/pull/9419

Additionally, I've opened an issue with the Apache Maven team about fixing this there as well:
https://issues.apache.org/jira/browse/MNG-6673

Internal Report

The internal (security private) report of this industry-wide vulnerability can be found here:
https://issuetracker.google.com/issues/132071216

Deliverables

  • [ ] Next minor release: Begin warning users about their use of HTTP to download dependencies.
  • [ ] Next major release: Force users to explicitly opt-out of the security offered by using HTTPS.
P1 area-ExternalDeps breaking-change-1.0 incompatible-change migration-0.29 team-XProduct

Most helpful comment

Closing, as the flag has been flipped in 299655ee2600874667fa9e21e6d1e598bb011b56.

All 12 comments

Klaus, what do you think?
Maybe we could forbid HTTP dependencies without a sha256? Any good alternative?

Maybe we could forbid HTTP dependencies without a sha256?

That should work. What we most likely cannot drop is the "plain http but known-good checksum" use case. And of course, such a change can only become active in a release that allows incompatible changes.

Proposed implementation https://bazel-review.googlesource.com/c/bazel/+/103031 (plus a flip of that flag, once we're in the next window that allows incompatible changes).

Thanks!
Please send an email to bazel-dev@ for feedback about this change.

Please send an email to bazel-dev@ for feedback about this change.

https://groups.google.com/forum/#!topic/bazel-dev/sa0mkKXouoQ

Once https://bazel-review.googlesource.com/c/bazel/+/103031 is submitted, a flag --incompatible_disallow_unverified_http_downloads will be available that, if set, disallows downloads from http URLs if no checksum is provided.

Migration: add a checksum or at least one https source for fetching the file. Note that if no checksum is given, the http URLs will be ignored but it is no error if they are present, provided at least one non-http URL remains for the actual fetching. In this way, it is still possible to have the following mixed workflow. The developer updating the dependencies fetches from the authoritative https URL to compute the good hash and commits it. Everyone else would use the quick http-mirrors and verify against the committed hash.

@laurentlb Do we need a separate design document for that incompatible change, or is the information linked from this issue enough?

Please set a priority for this feature request.

Once https://bazel-review.googlesource.com/c/bazel/+/103031 is submitted, a flag --incompatible_disallow_unverified_http_downloads will be available that, if set, disallows downloads from http URLs if no checksum is provided.

Migration: add a checksum or at least one https source for fetching the file. Note that if no checksum is given, the http URLs will be ignored but it is no error if they are present, provided at least one non-http URL remains for the actual fetching. In this way, it is still possible to have the following mixed workflow. The developer updating the dependencies fetches from the authoritative https URL to compute the good hash and commits it. Everyone else would use the quick http-mirrors and verify against the committed hash.

This incompatible change has been approved. I will rebase the change and send it for review soon.

Thanks Bazel team for prioritizing this and working to protect your users and the JVM ecosystem.

Closing, as the flag has been flipped in 299655ee2600874667fa9e21e6d1e598bb011b56.

Sanity check: Does this check that any redirects are HTTPS based as well, or only the declared host is HTTPS based?

In Gradle, we are checking both that the declared host is HTTPS based, and all redirects are HTTPS based as well.
https://github.com/gradle/gradle/pull/10065

Was this page helpful?
0 / 5 - 0 ratings