GitHub Awards $25,000 Bug Bounty to the Google Employee
GitHub awarded $25,000 to the security researcher, Teddy Katz for discovering a bug and patching it. On March 17, bug bounty hunter and Google employee Teddy Katz published a note regarding a GitHub flaw discovered in the communication system between repositories and the organization’s workflow automation software, GitHub actions.
The security flaw was tracked as CVE-2022-22862 and was reported as an improper access control susceptibility that “allowed an authenticated user with the ability to fork a repository to disclose Action secrets for the parent repository of the fork.”
Katz identified the working method of GitHub and how it manages to pull requests. Every single pull request is meant to have a base branch, and this is often the main branch of a repository. Pull request designers can lay the base branch pointer. However, the bug bounty hunter recognized that it was possible to set branches to commits, and while this ended in errors due to merge conflicts, GitHub Actions converted the bug into something more dangerous.
GitHub executes merge pull request stimulations to stop pull request creators from accessing repository secrets. According to Katz, this “breaks the GitHub actions permission model” and evades Actions secrets restrictions.
“Since the base branch is part of the base repository itself and not part of a fork, workflows triggered by pull_request_target are trusted and run with access to secrets. We just created a pull request where the base branch is a commit hash, not a branch. And anyone can create a new commit hash in the base repository since GitHub shares commits between forks,” Katz explained.
An attacker could split public repositories that use GitHub Actions, design a pull request, and then set a malicious Actions workflow and separately commit to a fork – gaining access to repository secrets in the process.
“It would be difficult to conceal the malware for long – the malicious package would almost certainly be unpublished in a matter of hours or days depending on how fast the maintainers/npm security team were able to respond. Once it was exploited like this, the underlying GitHub vulnerability would probably have been noticed and fixed as well,” Katz stated.
from E Hacking News - Latest Hacker News and IT Security News https://ift.tt/31goyuU
Comments
Post a Comment