tool-cache download should only allow http if explicitly set and not allow downgrade on redirects.

Original report on H1 to the GitHub security team: https://hackerone.com/bugs?subject=user&report_id=689850

---

The GitHub Actions downloadTool API allows the download of tools over HTTP instead of forbidding it and forcing HTTPS or requiring opt-in flag for the insecure usage.

This is a security vulnerability pervasive in the Java ecosystem that I've been working to help stop. We have a chance to stop this vulnerability from spreading into the GitHub actions ecosystem by nipping this in the bud right now.

This is related to my research from a few months ago based upon Max Veytsman (now on the GH security team) research.

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

---

Examples of existing vulnerabilities:

The GitHub actions documentation:

• https://github.com/actions/toolkit/pull/120

Projects that are already vulnerable because of this:

• https://github.com/leafo/gh-actions-lua/blob/596c2b80c8fa4b9468b4b8c2affba42b417bfd3f/install-lua/main.js#L42
• https://github.com/leafo/gh-actions-lua/blob/596c2b80c8fa4b9468b4b8c2affba42b417bfd3f/install-lua/main.js#L77
• https://github.com/mihails-strasuns/setup-dlang/issues/5

Description:

The GitHub actions ecosystem creates a web of trust where we are relying upon other actions to have been written securely. Vulnerabilities in GH Actions can impact all downstream users.

Steps To Reproduce:

MITM any connection between GH Actions VM's and the tools being downloaded. This allows a compromise of the supply chain for these projects.

Impact

Supply chain takeover of downstream repos.

Other Build Tools

Fixing Gradle

In Gradle 6.0 we are aiming to begin warning users with warnings that we are formally deprecating the use of HTTP to download dependencies. The work to fix this can be found in my PR here.
https://github.com/gradle/gradle/pull/10065

We are essentially requiring users to opt-in to using HTTP instead of HTTPS with a flag.

repositories {
    maven {
       url = uri("http://my-company.example")
       allowInsecureProtocol = true // new API
    }
}

We have chosen to allow an opt-in flag because there are legitimate use cases where developers are building software on an internal corporate network & according to the security team's threat model they considerer it 'safe'.

Important note: Gradle will also ensure that all redirects are also HTTPS based.

Fixing Scala Build Tool (SBT)

The SBT team is working on resolving this issue and their progress is tracked here:
https://github.com/sbt/sbt/issues/4905

Fixing Bazel

The Google team made the decision to require bazel users to specify SHA-256 checksums for all artifacts downloaded over HTTP.
https://github.com/bazelbuild/bazel/issues/8607

Fixing Maven

No progress has been made by the Maven team to resolve this issue.
https://issues.apache.org/jira/browse/MNG-6673

What about GitHub Actions

My recommendations for GitHub actions here are as follows:

• Check the declared URL for HTTP instead of HTTPS
• Check all redirects from that URL to ensure no downgrades to HTTP occur
• Allow HTTP instead of HTTPS if and only if a SHA256 checksum for the artifact is also specified.
• Allow SHA256 checksums to be declared for HTTPS based downloads and ensure they are checked.

You may ask: Why not just allow an opt-out of HTTPS? Why require the SHA checksum?

GitHub Actions, are very likely to be executed as part of building downstream open source projects. Those downstream projects rely upon the security of the upstream actions they are using. It's important that we can guarantee that those downloaded tools are legitimate and haven't been backdoored by a MITM. Given that GH Actions are executed on Microsoft Azure and are not executed inside of corporate networks, the download must always traverse the 'unsafe' public internet.