5 ms·
PHP.net breach: Concern over safety of source code
- nbpoole 16y agoDoes anybody know what version of DokuWiki was being run? I'd be interested to know whether this was a 0-day exploit (and if so when DokuWiki will be patched).
- splitbrain 16y agoDokuWiki lead developer here. I've contacted the PHP guys but haven't heard back, yet. We have no details of the breach so far. The Google cache of the page indicates that it was an outdated DokuWiki version, but we simply don't know. There are no known vulnerabilities in current DokuWiki. As soon as we learn about the nature of the problem we will release a security update if needed.
- nbpoole 16y agoThanks for the followup :-) Edit: For anyone else who's curious, here's what I'm seeing from the Google cache: <meta name="generator" content="DokuWiki Release 2008-05-05" /> There appear to have been three major releases of DokuWiki since then, so the vector could have been a previously fixed vulnerability.
- wiredfool 16y agoI was looking for this too. Must suck to be named as the source of a breakin and not have any more information.
- xd 16y agoNot 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 agoSource 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 agoThe 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 agoCorrect, 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 agoPeople 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 agoAh, 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.