Details of the attack on the infrastructure used in the development of the PyTorch machine learning framework were revealed, which made it possible to extract access keys sufficient to place arbitrary data in the repository with project releases on GitHub and AWS, as well as to substitute code in the main branch of the repository and add a backdoor through dependencies. PyTorch release spoofing could be used to attack large companies such as Google, Meta, Boeing and Lockheed Martin that use PyTorch in their projects. As part of the Bug Bounty program, Meta paid researchers $16,250 for information about the problem.
The essence of the attack is the ability to run your code on continuous integration servers that perform rebuilds and run jobs to test new changes sent to the repository. The issue affects projects that use their own external "Self-Hosted Runner" handlers with GitHub Actions. Unlike traditional GitHub Actions, Self-Hosted handlers do not run on the GitHub infrastructure, but on their own servers or in developer-maintained virtual machines.
Executing assembly tasks on your servers allows you to organize the launch of code that can scan the internal network of an enterprise, search the local FS for encryption keys and access tokens, and analyze environmental variables with parameters for accessing external storage or cloud services. In the absence of proper isolation of the assembly environment, found confidential data can be sent externally to attackers, for example, through access to external APIs. To determine whether projects are using Self-Hosted Runner, the Gato toolkit can be used to analyze public workflow files and CI job launch logs.
In PyTorch and many other projects that use the Self-Hosted Runner, only developers whose changes have previously been peer-reviewed and included in the project's codebase are allowed to run build jobs. Having the "contributor" status when using the default settings in the repository makes it possible to launch GitHub Actions handlers when sending pull requests and, accordingly, execute your code in any GitHub Actions Runner environment associated with the repository or the organization supervising the project.
The link to the "contributor" status turned out to be easy to bypass - it is enough to first submit a minor change and wait for it to be accepted into the code base, after which the developer automatically received the status of an active participant, whose pull requests are allowed to be tested in the CI infrastructure without separate verification. To achieve active developer status, the experiment included minor cosmetic changes to correct typos in the documentation. To gain access to the repository and storage of PyTorch releases, the attack when executing code in the "Self-Hosted Runner" intercepted the GitHub token used to access the repository from build processes, as well as the AWS keys used to save the build results.
The issue is not specific to PyTorch and affects many other large projects that use the default settings for "Self-Hosted Runner" in GitHub Actions. For example, the implementation of similar attacks was mentioned to install a backdoor in some large cryptocurrency wallets and blockchain projects with a billion-dollar capitalization, making changes to the releases of Microsoft Deepspeed and the TensorFlow project, compromising the CloudFlare application, as well as executing code on one of the computers on the Microsoft network. Details of these incidents have not yet been disclosed. Under existing bug bounty programs, researchers have submitted more than 20 applications for rewards worth several hundred thousand dollars.
The essence of the attack is the ability to run your code on continuous integration servers that perform rebuilds and run jobs to test new changes sent to the repository. The issue affects projects that use their own external "Self-Hosted Runner" handlers with GitHub Actions. Unlike traditional GitHub Actions, Self-Hosted handlers do not run on the GitHub infrastructure, but on their own servers or in developer-maintained virtual machines.
Executing assembly tasks on your servers allows you to organize the launch of code that can scan the internal network of an enterprise, search the local FS for encryption keys and access tokens, and analyze environmental variables with parameters for accessing external storage or cloud services. In the absence of proper isolation of the assembly environment, found confidential data can be sent externally to attackers, for example, through access to external APIs. To determine whether projects are using Self-Hosted Runner, the Gato toolkit can be used to analyze public workflow files and CI job launch logs.
In PyTorch and many other projects that use the Self-Hosted Runner, only developers whose changes have previously been peer-reviewed and included in the project's codebase are allowed to run build jobs. Having the "contributor" status when using the default settings in the repository makes it possible to launch GitHub Actions handlers when sending pull requests and, accordingly, execute your code in any GitHub Actions Runner environment associated with the repository or the organization supervising the project.
The link to the "contributor" status turned out to be easy to bypass - it is enough to first submit a minor change and wait for it to be accepted into the code base, after which the developer automatically received the status of an active participant, whose pull requests are allowed to be tested in the CI infrastructure without separate verification. To achieve active developer status, the experiment included minor cosmetic changes to correct typos in the documentation. To gain access to the repository and storage of PyTorch releases, the attack when executing code in the "Self-Hosted Runner" intercepted the GitHub token used to access the repository from build processes, as well as the AWS keys used to save the build results.
The issue is not specific to PyTorch and affects many other large projects that use the default settings for "Self-Hosted Runner" in GitHub Actions. For example, the implementation of similar attacks was mentioned to install a backdoor in some large cryptocurrency wallets and blockchain projects with a billion-dollar capitalization, making changes to the releases of Microsoft Deepspeed and the TensorFlow project, compromising the CloudFlare application, as well as executing code on one of the computers on the Microsoft network. Details of these incidents have not yet been disclosed. Under existing bug bounty programs, researchers have submitted more than 20 applications for rewards worth several hundred thousand dollars.
