EDIT: According to zerodiums charts, this would have been a payout of up to 250k$. However, I'm not quite sure what the attackers plan on cashing out on that would have been, given that the exploit would have quite obviously referenced zerodium and therefore would make the submitter the primary suspect of being the author. Maybe some APT used this "simple" format to disguise the actual power? But then again, it would be in their interest for the exploit to actually go through.
 https://bugs.php.net/bug.php?id=78224 (only mention I found with a documented use of the parameter)
I'd say the reason it doesn't hide better is because it's specifically meant not to hide. It's burning the vulnerability that has apparently existed for almost 4 years.
So, the message "sold to zerodium, mid 2017" is there, but may not be true -- it might very well be deliberate misdirection.
The vulnerability that is of interest is the one that allowed these commits to be injected. That is what I figure was sold years ago, and was burned recently.
Of course, it could appear in the server logs (or be detailed on a file dumped on the filesystem) - but it seems PHP have just decided to move to Github, and may not actually care about this, so it may not see the light of day.
And PHP does seem to care about the real exploit, the one in their infrastructure, which is why they're moving to Github.
Mind expanding on your above comment to help me understand?
Yes, it will be evident that the commits appeared in the git history, but not necessarily how they got there. If the git repo on disk suddenly has that commit, and no other usual indicators of compromise, that doesn't really give you anywhere to start looking for, what we agree is, the interesting vulnerability. All you have is "we know this box/service was definitely rooted, so look at all our infrastructure end-to-end".
They care about the exploit enough to move - of course. But do they care enough to investigate and find the actual exploit? Or hand over the server image to someone who does? Unless they've wrapped it in some PHP, it's probably not their core competency.
I don't follow the PHP project, so I don't know the answer to that.
Are you sure about that? If anyone wanted to demonstrate their access/power, they would probably leave some way to identify themself as the author - with a half-hearted concealment like this, anyone could claim to have been the hacker.
The only way this discovery would help the hacker, is if they intended to force a security audit of the karma system and/or the move to GitHub.
I agree. Of course I can't be sure of anything here, but to me this commit seems suggestive that there's other injected code somewhere since mid 2017.
You also make a good point on attribution. I had considered that too and if not wanting to take credit could tell us anything about the author.
For example say you were an intelligence agency that knew about this access and knew it was being used by an enemy. Perhaps you couldn't let php know about the vulnerability without exposing that you had access to other data allowing you to know about it. Creating this commit could be a way to share knowledge without it being known where/how it was found.
Of course that's all wild speculation.
Would they admit if they did?
Could be just a meme or a bad attempt of misdirection in case it went undetected for a while.
I think it's far more likely that someone tried to plant this there in order to cash out via zerodium.
but why so snarky?
Migrating accounts of PHP core developers by asking them for their username over unencrypted email? What could go wrong? A security incident already occurred, so we should be good on that front for a few years, right?
You need people to properly secure their keys of course, but it makes life a lot harder for an attacker.
When you git pull, then do your work and git commit/push, if you are not careful and you do not examine git status/diff you could sign and commit the hackers change (that you pulled from the repo initially) along with your new changes. So care is required even with PGP signed commits.
This is another good reason to not interrupt developers while they are working. Doing so, makes mistakes such as this more likely.
> if you are not careful and you do not examine git status/diff you could sign and commit the hackers change
I assume he meant that you pull, get an auto merge and then inattentively sign it. With this, you confirm the hackers change with your signature.
You could add a push hook to only allow fully signed chains, but given that we are talking about a compromised server, this does not help.
Even if we assume the git server is completely malicious, I'm still not seeing a case where an attacker can hide a change because I didn't 'status/diff'. I'm open to considering attacks I haven't thought of though.
Requiring two-factor auth for the GitHub account should be good for this though.
Just to make sure that someone doesn't go in and find a PHP account with recent commits, then email you with a third party github account.
> Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo  from the names of Rasmus Lerdorf and myself.
…and ends by saying:
> We're reviewing the repositories for any corruption beyond the two referenced commits. Please contact firstname.lastname@example.org if you notice anything.
Are you sure that using recent commits as confirmation is a good idea?
Combine that with a spoofed/typo'd sender and you're good to go.
(Yes, this still has holes, but it's a far smaller attack surface than "hello, it's me, trust me because I say so".)
In a perfect world, this would be fine, yes. But when adding work on top of a probably already very stressful workday, the likelihood of this creating additional problems is there.
Doesn't GitHub require e-mail validation before it associates commits with that e-mail address?
> Or they could have had different e-mails for php.net and GitHub, i.e. something like email@example.com and firstname.lastname@example.org.
Then require them to add their php.net mail address to their GitHub account.
> the likelihood of this creating additional problems is there.
That I agree with.
IIRC, nope! You can say your email is Linus Torvalds’, and GitHub will not question it (and even link to his GitHub profile in the commit history!)
That's the other way around though -- claiming the victims GitHub profile made a commit controlled by the attacker, instead of claiming the attackers GitHub profile made a commit controlled by the victim.
1. Look for a contributor without GitHub account (i.e. email@example.com )
2. Add firstname.lastname@example.org to your GitHub account/create one with that address 
2.1 The commits made by the victim will now link to your account on GitHub
3. Send a mail to Nikita with your faked GitHub-profile
None of this will survive a thorough check, but under pressure this will easily pass a surface-level check.
 I think you need to confirm your primary E-Mail, but not secondary ones. Alternatively, you could look for commits made from an now deleted mail account.
Although the victim would be notified that their address was added to a rogue account, the notification mail says: "If this wasn’t you, please ignore this email." Ugh.
Given that the attacker managed to push unauthorised commits, I don’t see how recent commits can be considered a reliable method of authentication.
Check out https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-... for another attempt, that one at least requires careful review to notice the problem
It could work if you do it in some poorly maintained extension, maybe, but that extension probably wouldn't be much used either.
Committing to release branch would be the worst way of doing it, since only RMs commit there, and RMs are those people who are going to notice if somebody commits to their branch and it's not them. Also, since releases are tagged manually, it'd not get into the release anyway, unless you somehow trick the RM into merging the change into their local repo without looking. Which they have no reason to since they created the branch and only they are supposed to commit there. So it'd require some serious trickery.
Edit: Elsewhere someone mentioned, this could have been "marketing" - to demonstrate their ability to take over accounts.
Hot take - They burned it, in a very visible way, to prove they've had access since 2017 (or whatever the investigation will reveal). A full security audit isnt very feasible.
Would force everyone to either downgrade and face known vulnerabilities, or do nothing and face high-risk unknown vulnerabilities.
Something like signing commits, and requiring all commits to be signed properly with a known key (and checking this on push and before release) would be an independent verification layer, and a more fundamental response to the compromise.
If that's what happened, then moving to Github solves nothing.
> I definitely trust GH more than myself in managing a git infrastructure securely
That's FUD, and appropriate too considering who owns Github now.
With Github, you can: (1) use "events" API to see which account did the push and (2) remove the account's ssh keys and change password from a secure machine to stop compromise right away. This stops the compromise completely.
Compared to that, if there was a compromise on our own server, it is quite hard to tell that everything was cleaned. Remember kernel.org compromise in 2011 ? They took a few weeks to recover, and this was with some of the best programmers.
Hell, the entire thing is simple enough to just be integrated in git.
Reminds me of that Linux compromise years ago where they picked it up because the change was directly on the build box, except at least that one was hidden behind an apparent `=` vs `==` "bug" - this one has a bit less style.
<!-- git web interface version 2.11.0, (C) 2005-2006, Kay Sievers <email@example.com>, Christian Gierke -->
The last commit looks to be Dec 2020: https://github.com/git/git/tree/master/gitweb
Though I don't know that this was how they got into the git server.
There's a strong possibility the vulnerability lay in their hosting setup rather than in the software application itself.
There's an argument to be made that self-hosted software that are non-trivial to configure for security have "dev ux" type security bugs, but I doubt that'd constitute a CVE. It could also be unrelated to the git-web hosting config.
The post mentions karma, there's some code here:
I think the most common attacks on Github repos and groups have been on individual accounts. Which 2FA would mitigate.
Or Rust, right? </sarcasm> https://github.com/php/karma/search?q=exec
- 8d743d5 Revert "Revert "Revert "[skip-ci] Fix typo"""
- 2b0f239 Revert "Revert "[skip-ci] Fix typo""
- 046827a Revert "[skip-ci] Fix typo"
- c730aa2 [skip-ci] Fix typo
(Yes, there's already such a script for GitLab.)
Someone responsible for release would have to manually keep a list of keys of authorized comiters and check the repository against this list at the very least prior to a release.
Looking at these commits they say mid-2017. Without signatures any previous commit could be by the same author.
Uh, you mean the features of ... Git?
They chose to burn -very publicly- the two accounts they had access to in order to showcase that they have an in that they can use somewhere else.
It's refreshing (as far as PHP goes) and worth checking out with an open mind. Performance on the other hand, that take a little more work.
I'm guessing your benchmarks are using native php-fpm and not through docker on your MBP?
I'm not convinced it's the best for building e-commerce sites and whatever people are piggy-backing on top of WordPress nowadays.