PHP.net breach: Concern over safety of source code | Hacker News Reader

PHP.net breach: Concern over safety of source code

theregister.co.uk

36 pointstaylorbuley18 comments

Does 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).

DokuWiki 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.

Thanks 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.

I was looking for this too. Must suck to be named as the source of a breakin and not have any more information.

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 ..

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.

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.

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.

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.

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.

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.

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.

"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.

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

Saturday:

"php.net security notice" | 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? ;-)

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.

I'm sorry. I wasn't attempting to bait you: I've been following this story since Friday, so I only skimmed this article the first time through. When I originally replied to you, I didn't know why you thought it took days. But you're right, my tone was much too harsh: my apologies.

No worries :)

It has been a few days, but there's no evidence other than that line to indicate they actually used all that time to review the source code. Probably just sloppy writing.

Reply on news.ycombinator.com