4 ms·

Not sure why it took days to find any malicious code modifications. Would have thought it would be pretty easy to find any malicious changes to any source code

by xd 16y ago

Not sure why it took days to find any malicious code modifications. Would have thought it would be pretty easy to find any malicious changes to any source code, be it tar balled or under source control. But then tar balls will have md5sums which are easy enough to check .. but I guess it's pretty easy to tamper with the source control logs ..

zdw 16y ago
Source control is the answer on this. Specifically, a hash based DVCS like git or mercurial would be fairly impervious to any tampering shenanigans, as they do a hash per file in the repo.
- eli 16y ago
  The article suggests they are manually reviewing recent commits to see if someone added something user credentials of an authorized committer, not that someone altered the source repository directly.
  - rll 16y ago
    Correct, checking for direct repository modification isn't very hard, even with Subversion. What took a little longer was to go through and make sure there wasn't a sophisticated attack hidden in a normal commit somewhere. Hard to sneak one of those in since the full diff of every commit is read by dozens of people, but it could still happen.
    - nupark 16y ago
      People rarely look at diffs closely enough to detect intentionally obscured malicious additions. Unintentionally malicious additions slip through all the time: they're called bugs.
      - rll 16y ago
        Ah, but we actually do. Especially when a commit comes from someone new or someone who doesn't normally commit to that part of the code. In order to sneak a malicious commit through, you would need to hijack the account of a user that normally commits to the part of the code you want to modify. On top of that, you probably want to find someone who has recently become less active since otherwise they would see a commit with their name on it and catch it right away. And finally, you would need to make it non-obvious so someone wouldn't be able to tell anything was amiss with a casual glance. It would be an interesting experiment.
        nupark 16y ago
        I think you're overestimating your ability to note a small security bug in a diff. If it was as easy as you seem to think, we probably wouldn't introduce such bugs by accident in the first place. It can be as innocuous looking as using strncpy instead of strlcpy.
nbpoole 16y ago
Edit: The linked article talks about people spending the past few days reviewing for code modifications. Based on other sources (VUPEN Twitter, PHP.net), it appears to have only taken a day or so. It has been several days since Friday though ;) --- Original (too harsh) reply below, for history's sake: Who said it took days? The wiki was down on taken Friday, that note was put up on Saturday. And they manually reviewed all revisions in case the credentials leak on the wiki box led to SVN access. It seems like a perfectly reasonable response to me.
- xd 16y ago
  "Maintainers of the PHP programming language spent the past few days scouring their source code for malicious modifications after discovering the security of one of their servers had been breached." First paragraph of the linked article.
  - nbpoole 16y ago
    Friday: "We are aware of a possible compromise of PHP.NET server(s) and a potential PHP source backdoor. "wiki.php.net" was taken offline" | https://twitter.com/#!/VUPEN/status/48696644975337472 https://twitter.com/#!/VUPEN/status/48696644975337472 Saturday: "php.net security notice" | http://www.php.net/archive/2011.php http://www.php.net/archive/2011.php The article backs up this timeline as well ("The site has been down since at least Friday"). Which do you trust more, the article with the linkbait title or actual facts? ;-)
    - xd 16y ago
      Yes, great points. I read the article linked to from the OP and didn't take the time to look elsewhere. I don't generally have time to crawl the web looking for the "facts" for every news story I read and have faith that a story being voted up on HN is based on a reliable source / article. I'm lost to why you felt it necessary to bait me with: "Who said it took days?", you could have just replied with the better sources you have just brought to my attention.
      - 16y ago

by xd 16y ago

zdw 16y ago

Source control is the answer on this. Specifically, a hash based DVCS like git or mercurial would be fairly impervious to any tampering shenanigans, as they do a hash per file in the repo.

eli 16y ago
The article suggests they are manually reviewing recent commits to see if someone added something user credentials of an authorized committer, not that someone altered the source repository directly.
- rll 16y ago
  Correct, checking for direct repository modification isn't very hard, even with Subversion. What took a little longer was to go through and make sure there wasn't a sophisticated attack hidden in a normal commit somewhere. Hard to sneak one of those in since the full diff of every commit is read by dozens of people, but it could still happen.
  - nupark 16y ago
    People rarely look at diffs closely enough to detect intentionally obscured malicious additions. Unintentionally malicious additions slip through all the time: they're called bugs.
    - rll 16y ago
      Ah, but we actually do. Especially when a commit comes from someone new or someone who doesn't normally commit to that part of the code. In order to sneak a malicious commit through, you would need to hijack the account of a user that normally commits to the part of the code you want to modify. On top of that, you probably want to find someone who has recently become less active since otherwise they would see a commit with their name on it and catch it right away. And finally, you would need to make it non-obvious so someone wouldn't be able to tell anything was amiss with a casual glance. It would be an interesting experiment.
      - nupark 16y ago
        I think you're overestimating your ability to note a small security bug in a diff. If it was as easy as you seem to think, we probably wouldn't introduce such bugs by accident in the first place. It can be as innocuous looking as using strncpy instead of strlcpy.

nbpoole 16y ago

Edit: The linked article talks about people spending the past few days reviewing for code modifications. Based on other sources (VUPEN Twitter, PHP.net), it appears to have only taken a day or so. It has been several days since Friday though ;) --- Original (too harsh) reply below, for history's sake: Who said it took days? The wiki was down on taken Friday, that note was put up on Saturday. And they manually reviewed all revisions in case the credentials leak on the wiki box led to SVN access. It seems like a perfectly reasonable response to me.

xd 16y ago
"Maintainers of the PHP programming language spent the past few days scouring their source code for malicious modifications after discovering the security of one of their servers had been breached." First paragraph of the linked article.
- nbpoole 16y ago
  Friday: "We are aware of a possible compromise of PHP.NET server(s) and a potential PHP source backdoor. "wiki.php.net" was taken offline" | https://twitter.com/#!/VUPEN/status/48696644975337472 https://twitter.com/#!/VUPEN/status/48696644975337472 Saturday: "php.net security notice" | http://www.php.net/archive/2011.php http://www.php.net/archive/2011.php The article backs up this timeline as well ("The site has been down since at least Friday"). Which do you trust more, the article with the linkbait title or actual facts? ;-)
  - xd 16y ago
    Yes, great points. I read the article linked to from the OP and didn't take the time to look elsewhere. I don't generally have time to crawl the web looking for the "facts" for every news story I read and have faith that a story being voted up on HN is based on a reliable source / article. I'm lost to why you felt it necessary to bait me with: "Who said it took days?", you could have just replied with the better sources you have just brought to my attention.
    - 16y ago