Last month I came upon this article from Dark Reading. It looked very familiar. It didn’t take me long to realize that the GitHub cross-workflow artifact poisoning vulnerability discussed in the article bore a striking resemblance to the GitHub cross-workflow cache poisoning vulnerability we reported on in March 2022.
GitHub workflows—A key component of GitHub CI/CD pipelines
GitHub workflows are used to define the specific actions that should be taken as part of the CI/CD pipeline. They are automated processes that can be triggered by specific events in a GitHub repository. Such events, for example, are when code is pushed to the repository, when a pull request is opened or closed, or when a new release is published.
Workflows are created using a YAML file, which specifies the actions that should be taken when the workflow is triggered. Such actions may be written by the developer or taken whole cloth from GitHub’s marketplace where more than 10,000 premade actions can be downloaded and used.
Workflows are made up of one or more jobs, which are defined as a series of steps. Steps can be a variety of actions, such as running tests, deploying code, or publishing a package.
GitHub workflows are a powerful tool that can help developers automate and streamline their workflows, saving time and effort and improving the reliability of their software development process, but they are not without their built-in flaws.
There are several potential security issues that can arise when using GitHub workflows. Here are a few common ones:
- Unauthorized access: Workflows that are not properly configured or secured could potentially be accessed and triggered by unauthorized users. This could allow them to execute arbitrary code or perform other unauthorized actions.
- Secrets leakage: Workflows often require the use of secrets, such as API keys or passwords, to access external resources or perform certain actions. If these secrets are not properly protected, they could potentially be leaked, leading to security breaches.
- Insecure dependencies: Workflows that rely on external libraries or dependencies could potentially be vulnerable to attacks if those dependencies are not secure. It is important to regularly review and update dependencies to ensure that they are secure.
- Lack of input validation and sanitization: Workflows that do not properly validate input could potentially be exploited to execute arbitrary code or perform other unauthorized actions.
Let’s take a closer look at the two cross-workflow vulnerabilities discussed in the articles mentioned above.
Cross-workflow artifact poisoning
GitHub workflow artifacts are the products of the work done in the CI/CD pipelines. Usually, each workflow would get its own bucket for storing such artifacts but sometimes workflows need to access artifacts created by other workflows. GitHub does not allow workflows to access storage/artifacts from different workflows outright. To get around that there is a GitHub-approved API that allows downloading artifacts based on basic filtering. The problem is that the API doesn’t differentiate between artifacts that were uploaded by forked repositories and those uploaded by the base repositories. That means that uploading potentially poisoned artifacts created by forked repositories is a real and present danger.
To remediate this issue, GitHub started providing additional information, as well as artifact metadata when downloading artifacts. This information is designed to help the author make sure they are downloading the correct artifact. The base issue of cross-workflow artifacts isn’t considered a problem by GitHub at this time. To learn more about this issue, check out the article mentioned above.
Cross-workflow cache poisoning
GitHub allows caching of artifacts and packages to speed up the CI/CD pipeline. Instead of downloading needed artifacts and packages again and again for each workflow they may be needed in, they can be cached and used in different workflows.
Since the cache is shared between workflows, all it takes is a single breach in a workflow using the cache with the permission to change it, and that cache can be poisoned for all following workflow uses. Since the cache is only updated when there is a new artifact or package to download, that means that a single poisoned cache may be active for a long time, influencing countless iterations of software builds being run in that pipeline.
GitHub doesn’t consider the issue of a potentially poisoned cache a problem. The cache is a useful feature and its ability to be shared between workflows is not considered a bug or an outright security issue at this time. To learn more about this issue, check out the article mentioned above.
Other Lesser Known GitHub Vulnerabilities and How to Defend Against Them
GitHub is one of the most popular Source Control Management (SCM) systems in the world. As such, it’s also widely used to build and distribute software using its CI/CD pipeline, actions, and workflows.
People need to remember that GitHub was created to facilitate code sharing and joint development. It was originally designed for open-source developers and the enterprise and organizational account capabilities were added later. At its core, security wasn’t a major concern of the system. The fact that you need to do a special set up on GitHub to enable security features on your account means that the idea that by using Git you are inherently more secure is only an illusion.
Later this month, Scribe will be hosting Tzachi Zornstain, Head of Software Supply Chain at Checkmarx in a webinar to talk about a few such potential software supply chain pitfalls in GitHub.
If you want to learn more about this lesser-known class of vulnerabilities and how to defend against them, listen to this on-demand webinar.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
