Steady integration and steady supply (CI/CD) misconfigurations found within the open-source TensorFlow machine studying framework might have been exploited to orchestrate provide chain assaults.
The misconfigurations may very well be abused by an attacker to “conduct a provide chain compromise of TensorFlow releases on GitHub and PyPi by compromising TensorFlow’s construct brokers by way of a malicious pull request,” Praetorian researchers Adnan Khan and John Stawinski stated in a report printed this week.
Profitable exploitation of those points might allow an exterior attacker to add malicious releases to the GitHub repository, achieve distant code execution on the self-hosted GitHub runner, and even retrieve a GitHub Private Entry Token (PAT) for the tensorflow-jenkins person.
TensorFlow makes use of GitHub Actions to automate the software program construct, check, and deployment pipeline. Runners, which consult with machines that execute jobs in a GitHub Actions workflow, will be both self-hosted or hosted by GitHub.
“We advocate that you just solely use self-hosted runners with non-public repositories,” GitHub notes in its documentation. “It’s because forks of your public repository can probably run harmful code in your self-hosted runner machine by making a pull request that executes the code in a workflow.”
Put in a different way, this permits any contributor to execute arbitrary code on the self-hosted runner by submitting a malicious pull request.
This, nevertheless, doesn’t pose any safety concern with GitHub-hosted runners, as every runner is ephemeral and is a clear, remoted digital machine that is destroyed on the finish of the job execution.
Praetorian stated it was in a position to establish TensorFlow workflows that had been executed on self-hosted runners, subsequently discovering fork pull requests from earlier contributors that mechanically triggered the suitable CI/CD workflows with out requiring approval.
An adversary seeking to trojanize a goal repository might, due to this fact, repair a typo or make a small however authentic code change, create a pull request for it, after which wait till the pull request is merged with a purpose to turn out to be a contributor. This might then allow them to execute code on the runner sans elevating any crimson flag by making a rogue pull request.
Additional examination of the workflow logs revealed that the self-hosted runner was not solely non-ephemeral (thus opening the door for persistence), but additionally that the GITHUB_TOKEN permissions related to the workflow got here with intensive write permissions.
“As a result of the GITHUB_TOKEN had the Contents:write permission, it might add releases to https://github[.]com/tensorflow/tensorflow/releases/,” the researchers stated. “An attacker that compromised considered one of these `GITHUB_TOKEN’s might add their very own information to the Launch Property.”
On prime of that, the contents:write permissions may very well be weaponized to push code on to the TensorFlow repository by covertly injecting the malicious code right into a characteristic department and getting it merged into the primary department.
That is not all. A menace actor might steal the AWS_PYPI_ACCOUNT_TOKEN used within the launch workflow to authenticate to the Python Bundle Index (PyPI) registry and add a malicious Python .whl file, successfully poisoning the package deal.
“An attacker might additionally use the GITHUB_TOKEN’s permissions to compromise the JENKINS_TOKEN repository secret, although this secret was not used inside workflows that ran on the self-hosted runners,” the researchers stated.
Following accountable disclosure on August 1, 2023, the shortcomings had been addressed by the mission maintainers as of December 20, 2023, by requiring approval for workflows submitted from all fork pull requests and by altering the GITHUB_TOKEN permissions to read-only for workflows that ran on self-hosted runners.
“Related CI/CD assaults are on the rise as extra organizations automate their CI/CD processes,” the researchers stated.
“AI/ML corporations are significantly susceptible as a lot of their workflows require important compute energy that is not out there in GitHub-hosted runners, thus the prevalence of self-hosted runners.”
The disclosure comes as each researchers revealed that a number of public GitHub repositories, together with these related to Chia Networks, Microsoft DeepSpeed, and PyTorch, are vulnerable to malicious code injection by way of self-hosted GitHub Actions runners.
