4 ms·

The commits say it was 'sold to zerodium, mid 2017', which would lead me to believe that someone has already been paid for this. I'd say the reason it doesn't

The commits say it was 'sold to zerodium, mid 2017', which would lead me to believe that someone has already been paid for this. 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.

rst 6y ago
The vulnerability most people here are talking about was introduced to the PHP codebase last weekend, as part of the block of code containing the "sold... mid 2017" message -- that vuln wasn't there previously, at least in that form. It's not clear what exactly is going on here, but if something was sold to Zerodium in 2017, it wasn't that vuln. So, the message "sold to zerodium, mid 2017" is there, but may not be true -- it might very well be deliberate misdirection.
- tyingq 6y ago
  Perhaps the vulnerability in the git server that allowed this is what was sold, rather than the commit.
- kenmacd 6y ago
  I don't see much point in discussing these latest commits. It's very unlikely they were actually malicious in intent (at least to PHP). 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.
  - insomniacity 6y ago
    Problem is, burning the exploit this way only works if someone does the work to find it. 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.
    - kenmacd 6y ago
      Sorry, I'm not sure what you mean. The commit was almost certainly never meant to make it in to some server log, it was meant to be seen, and it was. In that way it 'burned' (ie destroyed) the backdoor in to the PHP code repo. 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?
      - The_rationalist 6y ago
        Meant to be seen with a commit named "fix typo" wtf are you talking about? It's only due to luck that it has been reverted quick enough before being available through binaries.
      - insomniacity 6y ago
        I mean exactly what you did - "The vulnerability that is of interest is the one that allowed these commits to be injected". 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.
        kenmacd 6y ago
        Okay, I see what you mean. I guess I assumed they wouldn't just accept that their server was hacked and not do a through investigation (or have someone do so), but I suppose that's mostly because I couldn't imagine not if it was me.
      - Sebb767 6y ago
        > it was meant to be seen, and it was 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.

rst 6y ago

The vulnerability most people here are talking about was introduced to the PHP codebase last weekend, as part of the block of code containing the "sold... mid 2017" message -- that vuln wasn't there previously, at least in that form. It's not clear what exactly is going on here, but if something was sold to Zerodium in 2017, it wasn't that vuln. So, the message "sold to zerodium, mid 2017" is there, but may not be true -- it might very well be deliberate misdirection.

tyingq 6y ago
Perhaps the vulnerability in the git server that allowed this is what was sold, rather than the commit.
kenmacd 6y ago
I don't see much point in discussing these latest commits. It's very unlikely they were actually malicious in intent (at least to PHP). 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.
- insomniacity 6y ago
  Problem is, burning the exploit this way only works if someone does the work to find it. 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.
  - kenmacd 6y ago
    Sorry, I'm not sure what you mean. The commit was almost certainly never meant to make it in to some server log, it was meant to be seen, and it was. In that way it 'burned' (ie destroyed) the backdoor in to the PHP code repo. 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?
    - The_rationalist 6y ago
      Meant to be seen with a commit named "fix typo" wtf are you talking about? It's only due to luck that it has been reverted quick enough before being available through binaries.
    - insomniacity 6y ago
      I mean exactly what you did - "The vulnerability that is of interest is the one that allowed these commits to be injected". 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.
      - kenmacd 6y ago
        Okay, I see what you mean. I guess I assumed they wouldn't just accept that their server was hacked and not do a through investigation (or have someone do so), but I suppose that's mostly because I couldn't imagine not if it was me.
    - Sebb767 6y ago
      > it was meant to be seen, and it was 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.