4 ms·

Trying to sneak that diff in was a hugely wasted opportunity, it sticks out like a sore thumb. If they were going to commit anything, it should have looked like

Trying to sneak that diff in was a hugely wasted opportunity, it sticks out like a sore thumb. If they were going to commit anything, it should have looked like a legitimate change. Another option might have been to wait until just before a release and fiddle with the tags or the newly opened QA branch (if any). Check out https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/ 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

thomond 6y ago
They were presumably testing the waters to see if they were noticed first.
- carlio 6y ago
  It does beg the question if this was only the first time they were noticed.
- mvolfik 6y ago
  but why would you test that so obviously ('fix typo' but add code)? and they made it clear that they likely had access to the git server (by pushing 'from' different accounts), which (obviously, if that's what is actually happening) can kill their access
Ndymium 6y ago
In the diff, could they be hinting that they've had access since 2017? [1] Maybe they just wanted to burn it now for some reason. [1] https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d#diff-a35f2ee9e1d2d3983a3270ee10ec70bf86349c53febdeabdf104f88cb2167961R370 https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad...
stordoff 6y ago
It does make me wonder if something else was changed and this was what they wanted you to notice (as a diversion).
- lioeters 6y ago
  I think that's a good point. Apparently they had the ability to make commits as any user, which was a huge opportunity. Then they waste it on such an obvious backdoor? It does seem possible that this was a diversion tactic. Edit: Elsewhere someone mentioned, this could have been "marketing" - to demonstrate their ability to take over accounts.
  - orangepanda 6y ago
    > 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.
smsm42 6y ago
I don't see any way they could have snuck anything in unnoticed as a large patch. The number of people who regularly do big patches to PHP is not that large. If you send a big commit as one of them, that person would likely notice and raise an alarm they didn't do it. If you send as somebody who doesn't regularly make big changes, then people would wonder how come this person, who never submitted anything big, suddenly submits a large change without any discussion. So it would have stuck out anyway. 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.

thomond 6y ago

They were presumably testing the waters to see if they were noticed first.

carlio 6y ago
It does beg the question if this was only the first time they were noticed.
mvolfik 6y ago
but why would you test that so obviously ('fix typo' but add code)? and they made it clear that they likely had access to the git server (by pushing 'from' different accounts), which (obviously, if that's what is actually happening) can kill their access

Ndymium 6y ago

In the diff, could they be hinting that they've had access since 2017? [1] Maybe they just wanted to burn it now for some reason. [1] https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d#diff-a35f2ee9e1d2d3983a3270ee10ec70bf86349c53febdeabdf104f88cb2167961R370 https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad...

stordoff 6y ago

It does make me wonder if something else was changed and this was what they wanted you to notice (as a diversion).

lioeters 6y ago
I think that's a good point. Apparently they had the ability to make commits as any user, which was a huge opportunity. Then they waste it on such an obvious backdoor? It does seem possible that this was a diversion tactic. Edit: Elsewhere someone mentioned, this could have been "marketing" - to demonstrate their ability to take over accounts.
- orangepanda 6y ago
  > 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.

smsm42 6y ago

I don't see any way they could have snuck anything in unnoticed as a large patch. The number of people who regularly do big patches to PHP is not that large. If you send a big commit as one of them, that person would likely notice and raise an alarm they didn't do it. If you send as somebody who doesn't regularly make big changes, then people would wonder how come this person, who never submitted anything big, suddenly submits a large change without any discussion. So it would have stuck out anyway. 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.