Over 78% of All PHP Installs Are Insecure

An anonymous reader writes: Anthony Ferrara, a developer advocate at Google, has published a blog post with some statistics showing the sorry state of affairs for website security involving PHP. After defining a list of secure and supported versions of PHP, he used data from W3Techs to find a rough comparison between the number of secure installs and the number of insecure or outdated installs. After doing some analysis, Ferrara sets the upper bound on secure installs at 21.71%. He adds, "These numbers are optimistic. That's because we're counting all version numbers that are maintained by a distribution as secure, even though not all installs of that version number are going to be from a distribution. 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. Therefore, the real 'secure' number is going to be less than quoted." Ferrara was inspired to dig into the real world stats after another recent discussion of responsible developer practices.

Comments

"Over 78% of All PHP Installs Are Insecure"

[MarcNicholas]

Well, some therapy should help them overcome their insecurities!

I don't believe this.

[Rufty]

22percent of PHP installs are secure???

Re:I don't believe this.

[ShadowRangerRIT]

Well, all the other installations are being used to run five year old unpatched copies of WordPress. But the underlying PHP is totally up to date!

Re:I don't believe this.

[NoNonAlphaCharsHere]

No, the other 22% don't work at all.

Re:I don't believe this.

[thegarbz]

22percent of PHP installs are secure???

Typical slashdot user not reading the summary. It's way less than 22%.

Re:I don't believe this.

[gweihir]

This is a real surprise. I guess they did not count insecure applications....

Re:I don't believe this.

[Yakasha]

22percent of PHP installs are secure???

The PHP install is secure.

That does not include the code being executed by PHP... just PHP itself.

Or, as a php dev would say

[BarbaraHudson]

Or, as a php dev would say, "Over 20% are secure. We're making progress, folks"

ircmaxell

[TheNinjaroach]

I would have never recognized him by the name Anthony Ferrara, but ircmaxell immediately rings a bell for me. That dude is smart, kind and helpful in situations on IRC where most people aren't. He took a lot of time helping me get a patch or two submitted and accepted into PHP, in spite of my rudimentary git submissions.

If you're reading this ircmaxell, thanks for the help. The PHP Project is better for it.

Re:ircmaxell

[ircmaxell]

Thank you for the kind words :-)

so the solution is....

[gbjbaanb]

to assume every web server is hacked already.

Seriously, if you assume this, and code your way in a more secure, 3-tier manner, with a separate, and secured, application server, then you will mitigate all the problems with an insecure web server - well, at least they won't have full unfettered access to your database.

This may mean giving up those "all in one" frameworks people so love (whether its PHP or .NET or any other language), but that can only be a good thing - write an app server with a secure API isn't so hard to do, but will mean your CEO won't have to appear on the news explaining why every user of his site needs to change their password and replace their credit cards.

PHP

[ledow]

And why?

Because upgrading PHP breaks shit. It's the old story of backwards compatibility versus security and, inevitably, when you've commissioned a website in a language that you can't program in yourself, you will choose backwards compatibility every time.

Most people do not host their own web services. As such they are at the mercy of their host and what their host needs to run for everyone to be happy.

Every web host I've ever used, personally or professionally, will give you a version of PHP and rarely update it. When they do, they will invariably warn you that your scripts (i.e. website) are probably about to break. Most people in that position do not have the skills and knowledge (or even the tools or hosting capability!) to log in and fix the problem. So it's "we're going to break your website... you have to pay money to fix it".

Hence, there is a pushback every time they do it, and that makes them even more reluctant to suggest to their users that they need to do it again next month.

This is partly a user problem, yes, but it's mainly in the court of the PHP developers. Why does going from PHP 5.3 to 5.5 break SO MUCH without reason? Almost every bulletin board, forum, image gallery or what-have-you you find that runs PHP tells you version it will work on, and has had to issue at least one update that fixes shit that breaks on the newer versions of PHP.

I'm not sure there's another language out there that's quite so undefined and variable when it comes to how things should work and what could change/break in new versions.

Sure, I get that we have to keep everything up-to-date when we're running net-facing servers, but the problems of PHP compatibility and that most web-hosts are scared to upgrade has caused more problems than those old scripts still running. For the most part, they are even worked around so they are still compatible with old PHP's rather than, as should happen, upping the minimum required PHP version and making people get secure throughout.

I think we can safely lay the majority of this problem on the removal of register_globals (something that should never have existed in the first place), magic quotes and safe mode. The last two of which were touted as the lazy-man's security functions so you didn't have to worry about all the fine detail. The rest of the changes in those versions are pretty minor and to-be-expected of a new version of software.

If PHP hadn't done a "PHP isn't safe", "Here, use this hodgepodge of half-assed security feature", "Shit, they're more dangerous than what we were avoiding, remove them!", then maybe they wouldn't be in this mess.

Re:PHP

[Narcocide]

Seems like you put a lot of thought into this but you're frankly wrong. Wordpress didn't exist until years after "register globals" got deprecated. I agree it should never existed in the first place, but Wordpress is insecure entirely without any help from "register globals."

Re:PHP

[ircmaxell]

Ummm... No. WordPress was first written in PHP3. Before it was even called "register globals". Back when that was just how you did things.

Re: PHP

[Anonymous Coward]

I've programmed heavily in both PHP and .NET and I can say the PHP upgrades are not the cause of security issues. PHP's weakness is a combination of being interpreted at runtime and not enough access to the kernel. Things break heavily between .NET versions yet those developers do not jump ship over it. As PHP moved towards being more object oriented the implementation of it changed. Code which ran in a safe manner previously all of a sudden is a security problem. In .NET things are structured so that in the same scenario the older code would just fail completely. Neither languages are perfect at security but in the case of PHP it comes down to how you use it. For instance C is very *unsafe compared to the structure of C++ depending on how it is used.

Re:PHP

[pspahn]

Wordpress is widely adopted. Very widely. The #1 reason it is insecure is because it is targeted so often.

Is that PHP's fault?

Along with WP, plenty of other platforms plainly store their database credentials in some config file. It might be PHP, maybe XML, maybe JSON ... irrelevant. The credentials are stored in plaintext on the server.

Is that PHP's fault?

All these platforms do things in their own way. I'm a Magento developer and it is a platform that is notorious for it's complexity. I understand it pretty damn well, but the majority of the code I see was clearly written by folks who don't understand it very well. I've seen /www/var/log left wide open and the justification was that /www/var/log doesn't contain anything important. Just errors and stuff like that. For those paying attention, what's the difference between Mage::log($order, null, 'orders.log') and Mage::log($order->debug(), null, 'orders.log')? If you said, "the first one will log the entire object -- including database credentials", you get a cookie.

I'm talking about Magento specifically there, but every platform has it's own thing and twists PHP into doing things a bit differently. This fragments the understanding of the code and results in company XYZ hiring a "PHP developer" when they should have hired "Platform X developer".

I am wary of the statistics presented by this article simply because they don't take into account platform insecurities and the plethora of code that was written with a lack of full understanding. The number of "insecure" PHP sites is probably much closer to 100% than advertised, but it usually isn't PHP's fault.

Re:PHP

[dgatwood]

Wordpress is widely adopted. Very widely. The #1 reason it is insecure is because it is targeted so often.

No, the #1 reason it is insecure is that it isn't secure. The #1 reason it looks insecure is because it is targeted so often.

Along with WP, plenty of other platforms plainly store their database credentials in some config file. It might be PHP, maybe XML, maybe JSON ... irrelevant. The credentials are stored in plaintext on the server.

There's nothing wrong with doing that. The database shouldn't be accessible from arbitrary machines anyway, so having the credentials buys an attacker nothing. Besides, how the heck else are you going to provide credentials to a script? No, the real problems are that:

• Many servers are misconfigured so that any Tom, Dick, or Harry can access the database and wreak havoc after they manage to steal those credentials.
• Many web servers are misconfigured so that it isn't possible to allow the script to access those config files without allowing other unrelated users to access them.
• Many shared web servers are misconfigured in ways that allow PHP scripts owned by other users to access those same files, with no way to prevent that access.

All of these fall under the category of sysadmin configuration mistakes, not flaws in the software, per se, though in some cases, the software may create files with poor permissions (or in an insecure way, allowing for race condition attacks) that exacerbate those problems.

All these platforms do things in their own way. I'm a Magento developer and it is a platform that is notorious for it's complexity. I understand it pretty damn well, but the majority of the code I see was clearly written by folks who don't understand it very well. I've seen /www/var/log left wide open and the justification was that /www/var/log doesn't contain anything important. Just errors and stuff like that. For those paying attention, what's the difference between Mage::log($order, null, 'orders.log') and Mage::log($order->debug(), null, 'orders.log')? If you said, "the first one will log the entire object -- including database credentials", you get a cookie.

To some degree, that points to the need for both better logging systems and better back-end software design. When I'm writing code, I'm very careful to explicitly have separate debug levels, with explicit comments about the security or insecurity of each of those levels. Those security-risky debug levels are turned on only for short periods of time while fixing authentication-related bugs, and any secret info goes into a separate log file in a location outside the web root so that you can't trivially access it by making requests to the server itself—and never to a syslog daemon (whose log files are potentially readable by other users on shared hosting systems).

I also segregate user credentials into separate objects/variables. With the exception of the numeric user ID itself, none of that info is ever used outside of my authentication and authorization code, which is segregated into separate files to avoid accidental disclosure. Thus, none of the authentication information ever appears in any object that could realistically get logged. The obvious exceptions are objects associated with the database, which ostensibly contain database auth information, but I'm never going to print_r a database connection object (assuming that's even possible), so that's mostly moot.

The number of "insecure" PHP sites is probably much closer to 100% than advertised, but it usually isn't PHP's fault.

Actually, it is probably much lower, for several reasons:

• OS X v10.9 gets regular security updates, and ships with a version lower than the version they list. However, Apple routinely patches the software that they ship (rather than updating it) when security vulnerab

Re:PHP

[Trane Francks]

There is a lot of angst here, but the reality is that putting a CMS online is not the end of the task, it's the beginning. If you want to have a public-facing web site, that means keeping it up to date so that providers have no qualms about upgrading. In many cases, the issue isn't the client, per se, but the requirements of the client site that slow down upgrading. As an example, Zend still hasn't managed to add PHP 5.5 support to their Guard product, so anybody who has clients using Zend in their sites will be stuck on 5.4.x till, well, whenever Zend gets a move on.

In any case, running a provider is a matter of pushing clients to keep up with server changes in a timely yet forgiving fashion. There's no reason that upgrading from PHP 5.4.35 to 5.4.36 should break ANYthing, so there's no excuse for a provider to not keep up with patch releases. Moving from 5.4 to 5.5, for example, will introduce potential incompatibilities, so providers need to give 30-60 days advanced notice to ensure client sites can be checked and upgraded as required. As long as plugins and CMS releases have been updated as they come along, the reality is that most upgrades are pretty painless. It's the big-jump scenario, 5.2-5.5 kind of upgrade that will be a nightmare. Those should never happen.

A good provider will retain legacy servers for those who still toddle along with FrontPage extensions and the like, but only till such time as the base services, e.g., Apache 2.2.x and PHP 5.4.x reach end of life. At that point, a provider needs to come to the realization that putting an entire server at risk at the behest of a few clients who are slow with the updates is bad business. PHP might have its downside, but keeping in tight lockstep with upgrades keeps things (usually/hopefully/OMG-I-pray) one step ahead of the kiddies and blackhats.

Re:PHP

[Tablizer]

Why aren't there "long-term support versions" similar to what Ubuntu offers? Only security flaws are patched in such versions. However, I realize patching security flaws can break existing software also, but if you only patch security flaws rather than add and change features for the line, the magnitude of problems from updates would be smaller.

Re: PHP

[AcerbusNoir]

Because upgrading PHP breaks shit.

Like upgrading from Python v2 to v3?

Re: PHP

[Anonymous Coward]

This.

Old php3 / php4 dev here. Moved to python when got the chance.

I think that one of the main reasons for not updating PHP on production arises from its interpreted nature, and some other come from the language itself. First, there is no mechanism to know if an application will work with a new version of the interpreter before running into production. You may say your test coverage is nearly complete, but: a) that leaves some code untested, and b) most of the php apps I've found have zero tests. Then, you just update php in your servers and wait 'til the users report all the bugs found along the way. There's lint, but mostly at the syntax level, and that won't find things like deprecated functions or changes in return values/arguments between versions. And finally, there's the php non-standard-way of error handling: nothing beats a 500 error or a blank page straight to the user.

If there were a way of checking the compatibility of a full source tree against a particular php version, be it by statical or dynamic analysis but verifying all the code paths, something like:

$ ./oh_please_tell_me_this_source_works_with_5.4.23 ./trunk
Yes. ... the number of updated platforms would be different.

Note that python (and most of the interpreted languages) share this problem, but the strong typing and exception handling make it less problematic.

Re:PHP

[kthreadd]

Why aren't there "long-term support versions" similar to what Ubuntu offers? Only security flaws are patched in such versions.

Ubuntu only supports a handful of packages, specifically those in the main and restricted sections of the package archive. This includes the main php5 package but a large number of modules are kept in universe and are not supported at all.

However, I realize patching security flaws can break existing software also, but if you only patch security flaws rather than add and change features for the line, the magnitude of problems from updates would be smaller.

It depends on the vulnerability. I had things break when the bash vulnerability was patched some time ago. There is no solution other than test that things work before you apply the update.

Re:Why the distros?

[ircmaxell]

The point most people make when you talk about running old versions is that "well, distributions backport security fixes, so 5.3.3 is secure on distro XYZ".

So, to get around that, I looked at the popular distro's versions that they maintain. Then I counted *all* of those point versions as secure (over counting). So 5.3.3 is insecure as distributed by php.net, but as installed by Debian 6 it is secure.

So therefore to get an upper bound (rather than lower bound) on secure versions, you need some way of factoring in for distro support.

So I picked the most popular distros for server usage. Is this hand-waving? Absolutely. But it should give a pretty reasonable upper-bound.

Security at the small scale

[tepples]

Seriously, if you assume this, and code your way in a more secure, 3-tier manner, with a separate, and secured, application server, then you will mitigate all the problems with an insecure web server

For PHP web applications that aren't yet quite popular enough to need even a single dedicated server, is there a way to see some of the benefits of "a separate, and secured, application server" without tripling the budget?

Re:Zend Powered!

[darkain]

This is why it is a good idea to find a solid, trusted, up to date 3rd party repository that is well managed for your OS build.

For you Debian guys and galz out there, check out DotDeb: https://www.dotdeb.org/categor...

Re:Bogosity

[ircmaxell]

There's a difference between a vulnerability and an attack vector. Even if it's not exploitable, the vulnerability still exists.

However, I would like to make a point. How many of these installs made a conscious decision by investigating the security fixes and balancing that against their codebase to see if it's exploitable or not? I'd wager that the number is so small as to not even register.

Besides, I think a variant of Schneier's law applies:

"any person can invent a security system so clever that she or he can't think of how to break it."

The same thing applies to vulnerabilities: If you can't think of a way to exploit it, that doesn't mean it isn't exploitable.

So yes, it is an over-statement. But it's also showing quite clearly how updates are being dealt with. And that was the precise point of the original post. If it gets people to think about upgrading more, then awesome. If not, nothing lost.

Ubuntu is all I know

[AndyCanfield]

Our company runs our own servers; we run Ubuntu Linux. Our web sites are PHP. All I know is to run apt-get every Sunday and Ubuntu can update whatever it wants to. These are in-company web sites with login user names and passwords. No e-commerce involved; no public involved.

Am I a security export? Hell no. I've been programming for 45 years. My first language was FORTRAN; my first "personal computer" was a 360/20.. If it takes a security expert to code a program today than our industry is fundamentally flawed.

5.3.10?

[CODiNE]

Why is it that 5.3.10 is listed as the last secure PHP 5.3 when there's many more releases after it?

Re: 5.3.10?

[ircmaxell]

The 5.3 branch is end-of-life. Meaning that the latest release (5.3.29) has known vulnerabilities that weren't fixed. Therefore, it's not secure.

5.3.10 is listed as secure by the post because that version is supported by Ubuntu 12.04...

Re:Zend Powered!

[Tablizer]

Hackers tend to focus on the most common tools because a discovered flaw can be used on more instances. If Python or Your Favorite Language were more common, it would probably be a bigger relative target. There is some truth to Security Through Obscurity.

Thus, write your CMS in Brainfuck :-)

Re:re

[Gavagai80]

Time traveler problems.

Responsible developers?

[plopez]

I have never heard of a developer held responsible for failures. EEs, CivEs, ChemsEs, etc have to carry malpractice insurance to work.Until they can be sued and held responsible they will not be responsible.

That is why Software Engineering, IMO, does not exist. At best developers are skilled workers but not engineers.