Bazel allows users to use sha1 Hash for Jar Verification

[JLLeitschuh]

This is a public disclosure of a 0-day vulnerability in Bazel that has not been fixed within the 90-day vulnerability disclosure window given to the Google security team.

The original report to the Google Security Team can be found here:
https://issuetracker.google.com/issues/130163464

Summary: CWE-327: Use of a Broken or Risky Cryptographic Algorithm for Security Verification of Build Dependencies

Bazel's build uses SHA-1 hashes to verify the integrity of build artifacts resolved from artifact servers to ensure that they haven't been maliciously compromised.

https://docs.bazel.build/versions/master/be/workspace.html#maven_jar_args

sha1 String; optional

A SHA-1 hash of the desired jar.
If the downloaded jar does not match this hash, Bazel will error out. It is a security risk to omit the SHA-1 as remote files can change. At best omitting this field will make your build non-hermetic. It is optional to make development easier but should be set before shipping.

The specific quote that's important here is "It is a security risk to omit the SHA-1 as remote files can change."

According to Wikipedia: https://en.wikipedia.org/wiki/SHA-1
"Since 2005 SHA-1 has not been considered secure against well-funded opponents"

A practical SHA-1 attack has been demonstrated by Google:
https://shattered.io/

I want to note that some uses of Bazel I've found in Non-Google public repositories are using HTTP to resolve dependencies from artifact server, thus opening them to MITM attacks where an SHA-1 collision artifact is served. See #8607

Attack scenario:

Large, well-funded organizations with the capabilities to invest lots of CPU time into this attack.

Who is capable of mounting this attack?
This attack required over 9,223,372,036,854,775,808 SHA1 computations. This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations.

https://shattered.io/

By creating an SHA-1 collision of some JAR file, hacking a popular artifact server (like JFrog or Maven Central) and replacing those artifacts, Bazel users may be using maliciously compromised artifacts without knowing that's what they are doing.

---

The second preimage attack now only costs ~$100,000 according to new research published May 13th, 2019.

Our initial estimations were $1 million to compute the chosen-prefix collision, which is an amount of money we simply don't have. Thanks to our latest improvements, the cost went down below $100,000 and we are currently working on computing the first chosen-prefix collision for SHA-1.
- https://www.zdnet.com/article/sha-1-collision-attacks-are-now-actually-practical-and-a-looming-danger/

As such, this attack is now financially feasible against the Basel Build Infrastructure. Such an attack would only cost ~ the average 1 year salary of your average software engineer in the US.

[laurentlb]

cc @aehlig

Is it going to be fixed with #8607 or do we need another change?

[laurentlb]

Related: #6799

The vulnerability affects the function maven_jar which is deprecated. The replacement doesn't support sha1, only sha256.

[aehlig]

Is it going to be fixed with #8607 or do we need another change?

The native maven_jar function (which is deprecated anyway) is not affected by #8607, as that only changes the way how starlark repository rules (which, in the long run, should be the only repository rules, besides local_repository) download files.

[laurentlb]

I think the next steps are:

• Update the documentation. maven_jar documentation doesn't contain any warning.
• Check that the maven_jar replacement is production-ready.
• Flip the flag incompatible_remove_native_maven_jar to disable maven_jar by Bazel 1.0 (September) or before.

[dslomov]

This is not a security bug, and and not a vulnerability. sha1 function and maven_jar exist in Bazel, similar to how SHA1 functions are available to Java , C++ and other major languages. Its existence does not constitute vulnerability - if users do not want to use it, they are free to not to.

[laurentlb]

At least, the documentation is misleading:

It is a security risk to omit the SHA-1 as remote files can change.

It is also a security risk to specify SHA-1, as far as I understand.

[JLLeitschuh]

Should a CVE be issued for this report?

[jin]

We have added guidance in the documentation that SHA-1 is no longer considered a strong cryptographic hash, but it is still better than not using any. We have also added a recommendation to switch from maven_jar to rules_jvm_external, which supports a stronger SHA-256 hash verification.

See https://docs.bazel.build/versions/master/be/workspace.html#maven_jar.sha1 for more information.

Based on the above, I believe we have achieved remediation ("Add and recommend usage of stronger hashes (e.g. sha256)") and we can close this issue.

The next steps from here will be to remove the maven_jar feature from Bazel altogether. This work can be tracked in #6799.