The security flaw was discovered on 18th of April in Cask’s review-cask-pr GitHub Action used on the homebrew-cask and all homebrew-cask-* taps (non-default repositories) in the Homebrew organization. The bug was reported on their HackerOne program.
How can the Homebrew Cask vulnerability be exploited?
“The discovered vulnerability would allow an attacker to inject arbitrary code into a cask and have it be merged automatically,” the organization said in their announcement.
The vulnerability stems from the git_diff dependency of the review-cask-pr GitHub Action, used to parse a pull request’s diff for inspection. As a result of the flaw, the parser could be spoofed into completely ignoring the offending lines, leading to successfully approving a malicious pull request.
„A single cask was compromised with a harmless change for the duration of the demonstration pull request until its reversal. No action is required by users due to this incident,“ the advisory added.
What has been done to countermeasure the vulnerability?
Following the discovery of the issue, the affected review-cask-pr GitHub Action was disabled and removed from all repositories.
The automerge GitHub Action was disabled and removed from all repositories, as well as the ability for bots to commit to homebrew/cask* repositories.
From now on, all homebrew/cask* pull requests will require a manual review and approval by a maintainer.
The repository is also improving its documentation to help onboard new homebrew/cask maintainers and training existing homebrew/core maintainers to help with homebrew/cask.
More about Homebrew Cask
According to the official page, “Homebrew installs the stuff you need that Apple (or your Linux system) didn’t.” In other words, Homebrew installs packages to their own directory and then symlinks their files into /usr/local.
Shortly said, Homebrew Cask is designed to extend the functionality to include command-line workflows for GUI-based macOS applications, fonts, plugins, and other non-open source software.
In 2018, Arch Linux user-maintained software repository called AUR was found to host malware. The discovery came after a change in one of the package installation instructions. The happening showed that Linux users should not explicitly trust user-controlled repositories.
The security investigation revealed that a malicious user with the nick name xeactor modified an orphaned package (software without an active maintainer), called acroread. The changes included a curl script that downloads and runs a script from a remote site. This installed a persistent software that reconfigured systemd in order to start periodically.