GH Actions - Cache Poisoning
For further details check the original post https://scribesecurity.com/blog/github-cache-poisoning/
Cache Poisoning
The Git action action/cache introduces a caching mechanism in the Continuous Integration (CI) process, encompassing two critical stages:
Run Action: This stage involves searching for and retrieving cached data during the CI run. The search utilizes a unique cache key, yielding two outcomes:
Cache-hit: The requested data is found in the cache and is consequently retrieved for immediate use.
Cache-miss: No matching data is found in the cache, prompting a fresh download of the required files and directories, akin to a first-time request.
Post Workflow Action: This stage is dedicated to caching data post the CI workflow. Specifically, if a cache-miss occurs during the run action, the current state of the specified directories is cached using the provided key. This process is automated and does not necessitate explicit invocation.
Security Measures: Cache Isolation and Access Restrictions
To maintain security and ensure cache isolation, access restrictions are enforced, creating a logical separation between different branches. For instance, a cache created for branch Feature-A (with its base in the main branch) will be inaccessible to a pull request for branch Feature-B (also based in the main branch).
The cache action adheres to a specific search order:
It first seeks cache hits within the same branch as the workflow run.
If unsuccessful, it extends the search to the parent branch and other upstream branches.
Importantly, cache access is branch-scoped, extending across all workflows and runs of a specific branch. Additionally, GitHub enforces a read-only policy for cache entries once they are created, prohibiting any modifications.
Real-World Implication: From Low to High-Permission Workflow Attack
An illustrative CI scenario demonstrates how an attacker might leverage cache poisoning to escalate privileges from a low-permission workflow to a high-permission one:
The Unit-test workflow, responsible for running unit tests and code coverage tools, is assumed to employ a compromised or vulnerable tool. This workflow utilizes the action/cache Git action, making the cache accessible to any workflow.
The Release workflow, tasked with building and releasing the application artifact, optimizes its operations by caching Golang dependencies.
In this scenario, the unit-test workflow introduces a malicious cache entry by substituting a legitimate Golang logging library (`go
Last updated