PHP Supply Chain Attack Shows Open Source’s Virtues and Vices
Well, that was no fun. On March 28, “two malicious commits were pushed to the php-src repo.” That repository, in case you didn’t know, is the PHP language’s master software code storage site. PHP, by the Web Technology Surveys count, by the way, is used by almost 80% of all websites.
The good news? The commits were spotted almost immediately. The bad news? The malicious commits were made in the first place.
Under the disguise of PHP founder Rasmus Lerdorf and well-known PHP developer and maintainer Nikita Popov, the attackers pretended to be making minor typo fixes. In reality, they were placing a backdoor. This would have enabled an attacker to run a remote program on anyone running software using this hacked version of PHP.
Can you say bad? I knew you could.
Fortunately, as Popov told Bleeping Computer: “The first commit was found a couple hours after it was made, as part of routine post-commit code review. The changes were rather obviously malicious and reverted right away.”
Had they got away with this though, this would have made the Solarwinds attack look like something done by a script-kiddie. Fortunately, because PHP is open source, the problem was spotted before it had a chance to screw anyone over.
We can expect to see these kinds of attacks continue. In Git, for example, everyone’s favorite source-code version control system, it’s frighteningly easy to pretend to be another local Git user and then upload and sign-off on a forged commit to a remote Git server.
This episode also revealed higher-level security problems with any program including open source ones. As Dan Lorenc, Google open source security team software engineer, told The New Stack, “Compromises like this show that the attack surface of our software supply chain is much broader than it appears. Components like build systems, source code management tools, and artifact repositories all need to be treated as critical production environments, because they are. The reality is this incident could have had far-reaching consequences, but the PHP team did a great job in detecting this early and preventing the compromised code from reaching end users.”
Lorenc is quite right. The Linux Foundation has been working on armoring the open source software chain with the Open Source Security Foundation (OpenSSF). This cross-industry group brings together open source leaders by building a broader security community. It combines efforts from the Core Infrastructure Initiative (CII), GitHub’s Open Source Security Coalition, and other open-source security-savvy companies such as GitHub, GitLab, Google, IBM, Microsoft, NCC Group, OWASP Foundation, Red Hat and VMware.
Recently, The Linux Foundation, with Red Hat, Google, and Purdue University, have created the sigstore project. This will improve software supply chain security by enabling the easy adoption of cryptographic software signing backed by transparency log technologies. It will do this by empowering developers to securely sign software artifacts such as release files, container images, and binaries. These signing records will then be kept in a tamper-proof public log. This service will be free for all developers and software providers to use. The sigstore code and operation tooling that will be used to make this work is still being developed by the sigstore community.
This is still being worked on and it’s far, far from ready for production use yet. In the meantime, you need to do what you can to secure your own code repositories.
PHP has decided, wrote Popov, that while “We don’t yet know how exactly this happened, but everything points towards a compromise of the git.php.net server (rather than a compromise of an individual git account).”
Since that’s the case, Popov continued, “we have decided that maintaining our own git infrastructure is an unnecessary security risk, and that we will discontinue the git.php.net server. Instead, the repositories on GitHub, which were previously only mirrors, will become canonical. This means that changes should be pushed directly to GitHub rather than to git.php.net.”
If you’re running your own git repositories and you’re not on top of your security, you may want to consider such a move as well, or some other trustworthy git site such as GitLab.
To get access to the new canonical repositories, you’ll need to contact Popov. On GitHub, you’ll also need to use two-factor authentication (2FA). Yes, many developers think 2FA is a pain, but it also would have gone a long way in preventing this problem from ever happening.
