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

[JLLeitschuh]

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:

• Don't recommend the use of HTTP to download code #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.
gradle/gradle#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:
sbt/sbt#4905

Fixing Bazel

The Google team made the decision to require bazel users to specify SHA-256 checksums for all artifacts downloaded over HTTP.
bazelbuild/bazel#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.

[JLLeitschuh]

Possibly blocked by: microsoft/typed-rest-client#165

[bryanmacfarlane]

Thanks for reporting! I'll look into this.

[JLLeitschuh]

Any updates. I'd like to make sure we don't reach a point where there are lots of actions out there that are unintentionally insecure. The sooner this is nipped in the bud, the fewer projects I'll have to track down later that are vulnerable to this.

[bryanmacfarlane]

Security issues should not be logged here per https://github.com/actions/toolkit/blob/master/SECURITY.md

We will follow up on the bug bounty for discussions

[JLLeitschuh]

They (the GitHub security team) told me to report it here and open a PR. I don't have much free time. I started on one but got blocked by the typed-rest-client issue: microsoft/typed-rest-client#165

[bryanmacfarlane]

I'm following up.

[JLLeitschuh]

@bryanmacfarlane Friendly ping. I haven't heard anything on the h1 issue.

[bryanmacfarlane]

The typed-rest-client changes are in. Next, this will consume that for security in depth. Finally, I'm going to change this lib in a minor version update to default to http not allowed but have an option to allow explicitly (cases where that's intended). I'm also going to re-open even though we're trying to track sec issues outside of issues to discourage leveraging. In this case, it's more about security in depth and best practices more than an incident per se.

[JLLeitschuh]

I'd advocate for SHA-256 or SHA-512 signatures be passed if HTTP isn't supported over an explicit opt-out.

[bryanmacfarlane]

That's up to the specific actions. The api being discussed here is a low level http download to file.

[JLLeitschuh]

That's up to the specific actions.

Is it though? Doesn't the supply chain of one action cause a rippling effect down the supply chain?

I could understand this decision for internal corporations that have actions that only impact their supply chain, but when you are dealing with actions that are being used to build open-source software, I feel like requiring an SHA hash for HTTP downloaded resources seems completely reasonable.