PHP repository moved to GitHub after malicious code inserted under creator Rasmus Lerdorf's name
- Reference: 1617018377
- News link: https://www.theregister.co.uk/2021/03/29/php_repository_infected/
- Source link:
"Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo from the names of Rasmus Lerdorf and myself. 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)," [1]said PHP maintainer Nikita Popov, who works with the PHP team at JetBrains.
[2]
The malicious code is a backdoor into servers running the modified version. "This line executes PHP code from within the useragent HTTP header, if the string starts with 'zerodium'," explained PHP developer Jake Birchall.
The code was inserted under the misleading name "Fix typo" and claimed to be signed off by Rasmus Lerdorf, the creator of PHP. The attribution is "just part of the commit message," [3]said Popov in a discussion on StackOverflow.
[4]
Popov reverted the code, which was then restored by a criminal seven hours later, using Popov's name. The backdoor survived for one hour before being again removed.
[5]
The backdoor code was inserted yesterday under the title "fix typo" and attributed to PHP creator Rasmus Lerdorf
GitHub repos now canonical
The incident is still being investigated, but Popov said: "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."
Write access to PHP repositories will now require membership of the PHP organisation as well as enabling two-factor authentication for GitHub. Popov added: "We're reviewing the repositories for any corruption beyond the two referenced commits."
Even if we don't require it, we should STRONGLY encourage it. I've been signing my commits for several years now, it's not even that hard
"The PHP project is notoriously bad with infrastructure, it just doesn't have the funds to dedicate someone to it at the level necessary," [6]said Mark Randall, a software engineer, on StackOverflow. "GitHub is offering its services for free to us, just as it does to everyone else. We'd be silly to pass up the opportunity, if anything it's just a shame it took an attack to incentivise the move."
The incident has renewed pressure from the community for cryptographic signing of code commits. "Even if we don't require it, we should STRONGLY encourage it. I've been signing my commits for several years now, it's not even that hard," said developer Sara Golemon in a comment to Popov's announcement.
Lerdorf himself appeared to favour the proposal, saying: "I think for php-src commits we can require it. For doc and other repos we can make it optional for now until people are more comfortable with it."
[7]
Timeline of the PHP compromise: code inserted, removed, reinserted, and again removed
PHP is used by "79.1 per cent of all the websites whose server-side programming language we know," according to [8]statistics from W3techs.
The brief appearance of malicious code in the official repository does not mean it will make its way into many of those servers. PHP is most often installed from distribution repositories, such as those for Red Hat or Ubuntu, which are unlikely to be affected, unless malicious commits that have survived for longer are revealed.
Even so, the successful breach of the main PHP repository is a matter of great concern, as well as raising the question of how well other open-source repositories are protected – though the speed at which the PHP community noticed the problem is reassuring.
Google's open-source security team lead Dan Lorenc [9]told us : "We require that all open source we use is built by us, from our internal repositories."
Lorenc said this was mainly to ensure that it could build and patch the code itself if necessary, but it also reduces the risk from an incident such as this, if it is caught before the code is replicated.
[10]
Immediate action is required by maintainers of PHP repositories that pull code from the official source, which is to change the upstream repository to git@github.com:php/php-src.git. ®
Get our [11]Tech Resources
[1] https://news-web.php.net/php.internals/113838
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YGH5oWi9-Yjq5oqYY2q14QAAAEU&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://chat.stackoverflow.com/transcript/message/51874410#51874410
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YGH5oWi9-Yjq5oqYY2q14QAAAEU&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://regmedia.co.uk/2021/03/29/phphack.png
[6] https://chat.stackoverflow.com/transcript/message/51877798#51877798
[7] https://regmedia.co.uk/2021/03/29/reverts.png
[8] https://w3techs.com/technologies/overview/programming_language
[9] https://www.theregister.com/2021/02/24/google_ups_linux_security_effort/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YGH5oWi9-Yjq5oqYY2q14QAAAEU&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
Vulnerable by centralization
When our (dev-)infrastructure is concentrated at one or few sites, such as github, then we make ourselves just as or even more vulnerable as when using our own infrastructure. These companies only provide "free" as long as they profit from it in some way. When the wind changes or new management comes along, then you might be in an even worse situation than before. A breach also has more impact at a centralized place.
Building infrastructure costs money and requires a lot of expertise. Yes, it is easy to outsource this. It may even be cheap at first. The costs will come eventually and probably be higher than expected. That we have seen in the history of IT administration already. Here the short-term vs. long-term must be considered. But this is very difficult for most, apparently. And then, proper procedure is always a thing to have in place.
Maybe these large public projects should charge for the commits people want to make into the code-base. Most development is already steered by commercial entities. Why not have them pay their part?
Re: Vulnerable by centralization
> Most development is already steered by commercial entities. Why not have them pay their part?
I think you are confusing how PHP is developed.
It's not a large project, it's perilously small, with no funding at all except for some donated servers and maybe a couple of people paid to maintain it as part of their day job.
Commercial entities have little to no say over PHP's development path, it's all done via RFC vote among current / former contributors, of which 50 to 60 usually vote, each person having a single vote.
Re: Vulnerable by centralization
"The costs will come eventually and probably be higher than expected"
Yes, but that will most likely be under someone else's tenure, so who cares?
[Note this is a comment on general business logic, not the PHP team]
"The incident is still being investigated"
it would be good to know the results of said investigation, and if the perpetrator received proper legal repercussions.
"it would be good to know the results of said investigation, and if the perpetrator received proper legal repercussions."
Is that for the breach or for writing PHP?
And in particular, it would be good to know what git hosting software they were using (and what version), or whether it was a plain old SSH repository.
"which powers nearly 80 per cent of the internet"
Hey! I've got a bridge that carries 80% of London's traffic to sell you!
Why only now?
" Write access to PHP repositories will now require membership of the PHP organisation as well as enabling two-factor authentication for GitHub. "
Considering the extent to which the web has relied on PHP for so long, it seems a little surprising that only now is secure access being implemented,