Update on PHP source code compromise: User database leak suspected

PHP maintainer Nikita Popov has posted an update concerning how the source code was compromised and malicious code inserted – blaming a user database leak rather than a problem with the server itself.

The PHP code repository was compromised late last month with the insertion of code that, if left in place, would have enabled a backdoor into any web server running it. The code was initially committed in the name of Rasmus Lerdorf, creator of PHP, and after it was removed, recommitted under Popov’s name.

The team originally believed that the server hosting the repository had suffered a break-in, but in a new post Popov said: “We no longer believe the git.php.net server has been compromised. However, it is possible that the master.php.net user database leaked.”

Password encryption has been upgraded to use bcrypt, which is not compatible with Apache’s HTTP Digest authentication

The server in question uses gitolite to enable git hosting, and Popov had observed that “these two commits bypassed the gitolite infrastructure entirely,” leading him to suspect a server compromise. This influenced the decision to promote the PHP repository on GitHub to become the primary one since it would take time to diagnose the vulnerability and set up a new server.

Later, though, Popov discovered the repository also supported changes made via HTTPS, using the “git-http-backend behind Apache2 Digest authentication against the master.php.net user database” – something he had not previously been aware of. “I’m not sure why password-based authentication was supported in the first place, as it is much less secure than pubkey authentication,” he said.

The speculation now is that the user database was leaked, though this theory is undermined by the fact that the logs show guesses at usernames. Once the correct username was found, however, authentication was immediate. This user database was part of “very old code on a very old operating system/PHP version,” said Popov, who added that a vulnerability “would not be terribly surprising.”

Legacy pain

The actions now taken include resetting all passwords, and amending the code to use parameterised queries, to protect against SQL injection attacks.

The use of parameterised queries has been recommended best practice for many years, and the fact that code which does not do this has been running at the heart of the PHP source code infrastructure for so long demonstrates how insecure legacy code can linger for long periods in an organisation if it works and does not cause any obvious issues.

Popov said that a “small handful” of PECL (PHP Extension Community Library) extensions were still using an older source code management system called Subversion, with code hosted at svn.php.net.

Password encryption has been upgraded to use bcrypt, which is not compatible with Apache’s HTTP Digest authentication. This constraint, as well as the security incident, means that svn.php.net has now also been made read-only and its active repositories migrated to GitHub.

“It’s likely that some things broke during the migration,” said Popov, and any issues should be reported to him.

The further explanation falls short of a full analysis of what went wrong, but the migration to GitHub makes this less important. Whether or not it turns out to be SQL injection, it is a handy reminder that the age of running code is no guarantee of its security, and all too often the reverse applies. ®

READ MORE HERE