

PHP Install Statistics - ingve
http://blog.ircmaxell.com/2014/12/php-install-statistics.html

======
deanclatworthy
I get the point of this article but a lot of the vulnerabilities require an
attack vector in the form of PHP code written in a certain way. Therefore the
number of vulnerable servers is actually far far lower than what's stated
here.

------
trebor
This drives me crazy: we have a billion-dollar business as a client who self-
hosts their website, and it's running on PHP 5.3.3 on a way outdated version
of CentOS. It's not as if they can't afford to upgrade, it's that they _won
't_.

We have other clients who won't leave their host, and we're locked to PHP 5.2
to try to "write a modern application" in.

The bleeding edge may not be safe, but staying locked to an ancient copy of
PHP 5 that was end-of-lifed years ago is not a smart idea.

~~~
gdulli
PHP has thrived due to the mindset of wanting to get pages on the web with the
least amount of effort to configure or understand the stack. It's what I've
always seen people cite as the reason for adopting PHP. The language isn't
simple, it's full of inconsistency, but the deployment is simple, the setup is
simple with default Apache and mod_php, the 1:1 correspondence between web
pages and files on the filesystem is simple.

It should be expected that the same mindset would lead to unpatched servers
and inattention to the nuances of the stack.

~~~
trebor
Actually, this company has their own internal development team that doesn't
use PHP. They also employ full-time sysadmins. The only reason they used PHP
is because they wanted to use a very well known CMS. We were explicitly told
to conform to their server specs with our vagrant box to ensure compatibility,
etc. So PHP was adopted to support the CMS, and I guess their sysadmin never
bothered to upgrade the server.

I wouldn't the cause of this unpatched server to inattention. More like
bureaucracy and a bad case of "too many cooks in the kitchen".

~~~
benjarrell
Speaking as sysadmin, I have inherited situations similar to what you
describe. It could be laziness, but I have also encountered program/project
managers that put so many obstacles that it makes you throw your hands up.
Having a manager that will back you up makes difference.

I've come to the conclusion that inertia is the most powerful force in
business.

------
mmaunder
Probably more useful to focus on remote vulnerabilities that matter like
CVE-2012-0830 which affected 5.3.9 of which according to the post 0.14% run.
Also many bugs are highly config dependent like CVE-2012-1823 which is serious
but only affects apache with a specific config. So counting a version
increment to indicate level of vulnerability - you probably need to add to the
survey to get a real indication of the level of vulnerability out there.

However, it's interesting data of what's out there so thanks to the author for
that. Most of the infections we see are default installations that haven't
been configured and a bot raced in and infected. Or old PHP apps, themes,
plugins or components like thumbnailers that were the vector. Targeting PHP
itself is quite rare because there are so many vectors via the PHP
applications themselves that it's not needed if you just want to own a few
thousand boxes for your botnet.

------
smsm42
Couple of useful links for those wanting to know the timelines:

Supported versions of PHP with their timelines: [http://php.net/supported-
versions.php](http://php.net/supported-versions.php)

Unsupported versions of PHP with EOL dates
[http://php.net/eol.php](http://php.net/eol.php)

------
eikenberry
Debian wheezy originally shipped with 5.4.4 but now defaults to 5.4.34 through
a security update made on 2014-11-05.

~~~
mappu
Came here to post this. I was actually upset about that change, it caused some
weird compatibility issues in my application, and i had a hard time finding
debian's rationale.

~~~
smsm42
It would be excellent if you reported the BC break (provided you figure it out
and it's PHP fault) to bugs.php.net and also to the PHP internals list
(internals@lists.php.net). Unless it's listed in UPGRADING file for your
version, BC break in advanced version should not happen and is a problem. This
happens from time to time (e.g. we had to break some hacks using unserialize()
on non-serialized strings because otherwise it created security hole) but it's
pretty rare.

------
achillean
Searching Shodan I get the following numbers, which indicate that roughly 56%
of PHP instances are vulnerable to some degree.

Total number of servers running PHP: 7,320,803
[https://www.shodan.io/search?query=php+port%3A80%2C443%2C808...](https://www.shodan.io/search?query=php+port%3A80%2C443%2C8080%2C8443+after%3A01%2F10%2F2014)

Servers running vulnerable PHP versions: 4,111,345
[https://www.shodan.io/search?query=php+port%3A80%2C443%2C808...](https://www.shodan.io/search?query=php+port%3A80%2C443%2C8080%2C8443+after%3A01%2F10%2F2014+-5.6.4+-5.5.20+-5.5.12+-5.5.9+-5.4.36+-5.4.16+-5.4.4+-5.3.10+-5.3.3+-5.3.2+-5.1.6)

------
chronid
I don't find it really that surprising. Some shared hosts run very
old/outdated PHP versions (at least one I know still uses 5.2).

At the same time many, many many linux servers are _never_ updated after the
first installation...

------
eblah
I've been a PHP developer for years, and recently switched jobs from a place
where we were proactive in ALWAYS upgrading to the bleeding edge PHP, MySQL
and, when possible, CentOS version.

Now I'm at a place that has VERY loosely managed code where they virtually
cannot upgrade some sites without a rewrite. They're on an old version of PHP
5.2 and MySQL 5.0. I'm doing all I can to get everyone there to understand the
issues with legacy software, but it's a tough battle. Thankfully, I've got new
code and features running the latest PHP and MySQL versions, it'll be several
(many) years until all of it's managed enough to be upgradable.

I can also say I've always thought the PHP complaints were unfounded -- no
real company doesn't understand OOP, datatypes, etc. Yeah... I completely
understand now. It's a fun challenge putting good, solid standards in place
and moving a horrid codebase into a great one, though.

~~~
arenaninja
So far I've only worked with companies with no upgrade path without rewrite.
Luckily I'm the most experienced dev with my current employer, so that may
soon change

------
jrochkind1
> Just because 5.3.3 is maintained by CentOS and Debian doesn't mean that
> every install of 5.3.3 is maintained. There will be a small percentage of
> installs that are from-source.

So is it just me, or is this a total release management failure that there can
be multiple different things called "PHP 5.3.3" (or any other version number),
which behave differently, some of which have security vulnerabilities and some
don't.

If you want to know if you are vulnerable or not, knowing you have "PHP 5.3.3"
is not enough -- I'm not even sure how you'd tell if you had a patched version
or a non-patched version, other than testing it for vulnerability.

Something seems horribly wrong here, no?

~~~
ircmaxell
> Something seems horribly wrong here, no?

Yes. The distributions are effectively forking these versions, and keeping the
same version numbers. Leading to some REALLY awkward problems:
[https://github.com/ircmaxell/password_compat/issues/10](https://github.com/ircmaxell/password_compat/issues/10)

However, it's a tradeoff. It hurts some, helps others. After all, I'd rather
have someone get security fixes than nothing...

~~~
vacri
It's not as bad as Ruby in Debian, which has the patch version number in the
package name. For a while there, 'ruby1.9.1' was version 1.9.3...

------
inglor
It would be interesting to know what percent of these vulnerabilities are
remote.

~~~
duskwuff
Depends on what the application exposes. For instance, the recent
unserialize() vulnerability is remote if the application deserializes data
from the user. This is a bad idea, but a lot of applications do it anyway.

~~~
wvenable
Deserializing data from the user is itself a security vulnerability, in my
opinion. Given that we have not had a mass outbreak of PHP vulnerabilities, I
imagine the impact here is low.

I wouldn't be surprised is the Linux distributions that these sites run on
have just as many vulnerabilities if you use the same criteria as presented
here.

~~~
trebor
An unserialize attack would require intimate knowledge of the operating
codebase, as well as an encoded object (only objects can be exploited this
way) that could be configured to execute an attack via its constructor or
__set_state() method. Or, installing a backdoor through another CVE to create
the opportunity for just this kind of attack. It's complex, but not unknown.

I'm not aware of any major applications (WordPress, Drupal, etc) that
deserialize user input. That's not to say a plugin or theme might be unsafe,
but not in the core code that I've seen.

------
xyby
Looks like his definition of "has a security vulnuerability" is "is not the
latest release".

Does every release fix security vulnuerabilities?

~~~
Rygu
PHP minor releases are bug and security fixes. But as long as the latest minor
release fixed a vulnerability, in 99% of the cases, you can assume that all
previous versions contain that vulnerability. (I know, I know, regressions do
happen)

~~~
xyby
Yes. But does _every_ minor release fix bugs AND security holes? If some only
fix bugs, the equation "not newest = insecure" is wrong.

~~~
ircmaxell
I counted any point release since the latest security release as secure.

So for PHP's 5.6 line, only 5.6.4 is secure, since 5.6.4 is a security
release.

I'm currently crunching numbers for other platforms. For example, Nginx's last
security release (for 1.7) was 1.7.5, so 1.7.5 -> 1.7.9 are all considered
security.

------
sebastianavina
I readed the title, and expected an article about installing the Statistics
package for PHP.

------
eyeinthepyramid
I think it's safe to say that 100% of PHP installs have a security
vulnerability of some kind, though that doesn't mean the vulnerabilities are
known or exploitable.

~~~
smsm42
This is as useful as coming to a hospital and telling the doctors "Why waste
your time, guys? Everybody is going to die anyway!". Close to 100% of software
is faulty and vulnerable, yet there's a difference between running software
with known published issues and running software without them.

~~~
TylerE
However, to use your analogy, ceasing to use PHP is like stopping smoking and
dropping 50lbs. Sure, it'll still happen _eventually_ , but the expectancy
curve is a lot flatter.

~~~
smsm42
Except that it's not. Unless you also cease to use bash, SSL, ssh, OpenVPN,
iOS, Java... well, with this list it's better stay away from computers
altogether. Good, healthy life as a goat herder somewhere up in the mountains.

The myth that PHP has some special bad security profile is completely
baseless. It is true that there's a lot of insecure software written _in PHP_
, but the reason has nothing to do with security of PHP as a platform, but
rather with its low learning curve, which makes it popular among the same
people that make security mistakes - the beginners. They don't make insecure
software in Haskell not because Haskell is so secure that you can't write
insecure software in it, but because they can't write any software in Haskell
at all.

Dropping PHP in this case is a cargo cult - you do not improve your security
situation by just mimicking people that made better security decisions in
aspects that have nothing to do with security. It's like stopping eating
bananas because your neighbor slipped on a banana peel and broke his neck, all
while keeping smoking and eating junk food. Replacing negligible risk with
another negligible risk while keeping very risky habits would not reduce your
overall risk.

