Want to have your server pwned? Easy: Run PHP

[fm7]

More to the point, Ferrara found that for each major version of PHP from 5.3 through 5.6, only a small number of minor versions are not known to contain any vulnerabilities, but most systems aren't running those secure versions.

In Ferrara's findings, 93.3 per cent of all PHP 5.6.x installs were insecure, 63.4 per cent of PHP 5.5.x installs were insecure, 89.6 per cent of PHP 5.4.x installs were insecure, and 66.1 per cent of PHP 5.3.x installs were insecure.

As for PHP 5.2, just write it off. No versions of that branch are considered secure.

http://www.theregister.co.uk/2014/12/31/want_to_have_your_server_pwned_easy_run_php/

 

[RTGHM]

Pretty sure that was already common knowledge?

 

[lbft]

What a shock, running old, insecure versions of software leaves you insecure.

 

[KuJoe]

Woot! <3 ServerPilot.io for keeping my PHP updated.

 

[Hxxx]

Woot! <3 ServerPilot.io for keeping my PHP updated.

Which plan do you use? @KuJoe

 

[eva2000]

Yeah one reason why my Centmin Mod LEMP stack source compiles Nginx and PHP-FPM so you can get up to date versions direct from the source without waiting on any repositories for updates  Even have support for PHPNG / PHP 7.0.0-dev on Centmin Mod LEMP .08 beta builds which I am running for my Wordpress blog at http://wordpress7.centminmod.com/

 

[KuJoe]

Which plan do you use? @KuJoe

The free version.

 

[tonyg]

What a shock, running old, insecure versions of software leaves you insecure.

I guess you didn't read the article.

The insecurity is sprinkled throughout most versions, old and new.

 

[SentinelTower]

What would be interesting is to to know what kind of vulnerabilities we are talking about. Are they vulnerabilities that can be exploited in real life or vulnerabilities which can only be exploited on specific conditions which are unlikely to happen.

Also, I quite agree with ibft, we are not talking about a specific vulnerability, we are talking about vulnerabilities in general. The minor versions partly exists because they are fixing the vulnerabilities and thus this is logic that previous versions contain vulnerabilities.

Without more info, that sounds more like PHP-bashing to me, but the conclusion is a good advice: keep your packages up to date.

 

[GIANT_CRAB]

I guess you didn't read the article.

The insecurity is sprinkled throughout most versions, old and new.

PHP exploits are quickly patched. If you're on their mailing list, you will know how fast it's done. PHP isn't exactly terrible, it's mostly the web developers at fault or terrible permissions handling. 

The PHP team are really experienced and better than the skids at HF. If PHP is really that bad, why isn't Facebook having any major problem?

 

[lbft]

I guess you didn't read the article.

The insecurity is sprinkled throughout most versions, old and new.

I guess you didn't read the article, click through to the original blog post that isn't covered in El Reg's "journalistic" jizz, or google how PHP version numbering works in your haste to have a "php suxxorz lol" jerk-off.

With PHP versioning, like many projects, releases are numbered in the form major.minor.release. The aim, if not always the way things are done in practice, is that significant changes don't occur within the same major.minor series. Like many projects (e.g. the Linux kernel) there may be releases in multiple series under security support at the same time. Right now, PHP officially still maintains support for the 5.4, 5.5 and 5.6 series. If a new security bug is found in all three they'll push out a new release for each of those series.

Then you get into distro packages - distros distribute PHP and offer security support for that distro release's lifetime, so Red Hat is still backporting fixes to PHP 5.1 for RHEL5 (and those flow downstream to CentOS 5).

Releases were categorised "secure" for this analysis if they were the latest release in a series supported by PHP.net, or still supported by Debian, Ubuntu (including LTS) or Red Hat/CentOS. That's why it's "sprinkled throughout most versions", those versions are in different series and under security support by different people for different purposes and reasons.

This table comes from the original blog post:



Distribution Distro Version PHP Version
Debian 7 (Wheezy) 5.4.4
Debian 6 (Squeeze) 5.3.3
Ubuntu 14.10 (Utopic) 5.5.12
Ubuntu 14.04 (Trusty) 5.5.9
Ubuntu 12.04 (Precise) 5.3.10
Ubuntu 10.04 (Lucid) 5.3.2
CentOS 7.0 5.4.16
CentOS 6.6 5.3.3
CentOS 5.11 5.1.6

Note that that doesn't include the versions supported by the PHP team.

The end of The Register's article:

"Check your installed versions," Ferrara urged. "Push for people to update. Don't accept 'if it works, don't fix it.' ... You have the power to change this, so change it. Security is everyone's problem. What matters is how you deal with it."

Literally the entire point is that Anthony Ferrera/ircmaxell, who is a PHP guy, said "update your shit".

 

[lbft]

PHP exploits are quickly patched. If you're on their mailing list, you will know how fast it's done. PHP isn't exactly terrible, it's mostly the web developers at fault or terrible permissions handling. 

The PHP team are really experienced and better than the skids at HF. If PHP is really that bad, why isn't Facebook having any major problem?

PHP is very far from perfect, but it's true that they're doing a lot better than they used to. But Facebook sucks as an argument because they had enough issues with PHP performance that they built their own runtime (first HipHop, then HHVM).

 

[perennate]

PHP is fundamentally flawed: errors like using variable that doesn't exist are non-fatal, the functions have inconsistent names (base64_encode, urlencode), request variables can be arrays, and $_SESSION is a variable instead of a library that can be configured per application. The only reason I use PHP is because I like $$$.