▲ 77 points
back
52 comments
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.
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.
> and it's running on PHP 5.3.3 on a way outdated version of CentOS
That's probably not as bad as you make it out to be. CentOS 5.x is supported through 2017 with security patches, as would be CentOS/RHEL's customized PHP package. You don't get the new features, but you get the back-ported security fixes.
And if you want a newer version of PHP, you can always use IUS Community's repos[1]
> The IUS Community Project is a brain child of the RPM Development Team at Rackspace Hosting. Since 2006, we have provided and maintain packages for the latest versions of PHP/MySQL and other common software on Red Hat Enterprise Linux, because a lot of our customers strongly demand it. Internally we maintain a number of package sets for an audience of thousands of production servers. Until now, these packages have only been available internally to Rackspace customers. After a while we started thinking: Why not make this available publicly for everyone to benefit?
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.
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".
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.
The bleeding edge is getting pretty safe now, BC considerations being a major concern since 5.4 - which basically boils down to "if it works differently, it doesn't get into 5.x unless it's a security fix or obvious bugfix". If you look at the list of BC-breaking changes in 5.5[1] and in 5.6[2], it is very small.
As for supporting 5.2, I think people should start plain refusing to support outdated versions and educate their clients that running this version puts their business at risk. Unless there's super-important reasons for it (like the only supported PHP version for PrivateWeirdOS is 5.2 and nobody can port any supported version to it because the effort takes years), there should be no development targeting version that was EOLed 4 years ago.
You don't sound like a developer, more IT/ops side so let me try to put this in perspective.
The existing security holes in their code are going to be given equal weight with these concerns. Now unless you know what their bugfix backlog is, there's no reason to think security upgrades are a bigger priority than say PCI audits or whatever.
Unless there's a demonstrable value to fix this OVER all other security issues, only then would it make sense to hustle with a emergency fix.
And the thing about emergency patching is that you can't just toss your "solution" into the product. At the very starting line of sanity you need to research the risk an upgrade will have on your system. Don't think of the environment the system is hosted on, but the code itself.
That takes someone really smart and expensive to get pulled off whatever they were working on that generates money and focus on this security issue (over all others). They research, document and propose an upgrade path. Code will need to be refactored, tested system wide and then QA/UAT will chew on it. Data may need to be migrated or transformed (in production, risky!).
And that's all if they know the right way to do it! If you're unlucky you get a panicking CTO or boss who (read this article on hacker news and) demands a quick fix. In that case you upgrade the server, throw code up and fix related bugs for months. Who knows, maybe none of them will be security holes!
Which industry are they in?
The Hospitality (Hotel/Resort/Etc) industry.
Edit: I don't know if I can reveal the client, so please don't ask.
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.
Couple of useful links for those wanting to know the timelines:
Supported versions of PHP with their timelines: http://php.net/supported-versions.php
Unsupported versions of PHP with EOL dates http://php.net/eol.php
Debian wheezy originally shipped with 5.4.4 but now defaults to 5.4.34 through a security update made on 2014-11-05.
Which would then adjust this post's definition of "Insecure 5.4" to 72.2%. from 89.6%.
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.
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.
And if I'm not mistaken, CentOS 5.10 shipped with 5.3.3, and Ubuntu 12.04 Server ships with 5.3.10
But 5.4.36 came out Dec 18th.
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...
Servers running vulnerable PHP versions: 4,111,345 https://www.shodan.io/search?query=php+port%3A80%2C443%2C808...
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...
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.
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
> 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?
> 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
However, it's a tradeoff. It hurts some, helps others. After all, I'd rather have someone get security fixes than nothing...
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...
This applies to pretty much every popular package in a modern distro. I'm not running bash 4.1.2 (which was vulnerable to shellshock). I'm running bash-4.1.2-15.el6_5.2 (CentOS/Red Hat's patched version).
It's quicker for distros to backport specific security fixes than to test all the compatibility implications of updating the whole package to the latest version.
It would be interesting to know what percent of these vulnerabilities are remote.
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.
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.
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.
Looks like his definition of "has a security vulnuerability" is "is not the latest release".
Does every release fix security vulnuerabilities?
For 5.4, recently, yes, since 5.4 is "security only" mode since 3 month ago. For others, not necessarily, since there are a lot of fixes and improvements. Look at CVEs in the changelogs[1], while understanding that CVEs sometimes are assigned for issues like "if you could run arbitrary PHP code, then you could run any code" which IMO is always the case since PHP is not a security sandbox. But if you do not have enough in-depth knowledge to assess CVEs, just CVE presence should be a good upper bound. Note also some security issues are in the modules that may not be even used by the particular server (fileinfo and EXIF modules provided a bunch of CVEs recently but not everybody uses them) or may not be used in a way that is exploitable (so, unserialize() CVEs are only an issue if you unserialize user-controlled data, which is not a best practice). This is not to say those are not security issue, but running PHP version with a CVE would not always make your server exploitable. That said, you should upgrade anyway.
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)
Yes. But does every minor release fix bugs AND security holes? If some only fix bugs, the equation "not newest = insecure" is wrong.
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.
You can see a list of vulnerable PHP versions here: http://www.cvedetails.com/version-list/74/128/1/PHP-PHP.html
Note that this list refers to those versions as released, not as OS vendors may have patched them.
It's PHP. Fingers in the dike.
But don't take my word for it... http://php.net/ChangeLog-5.php
At least 90% of releases have a bugfix with an associated CVE vulnerability.
I readed the title, and expected an article about installing the Statistics package for PHP.
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.
I think it's safe to say that 100% of all software and hardware have a security vulnerability of some kind, though that doesn't mean the vulnerabilities are known or exploitable.
Exactly. Being on the bleeding edge doesn't mean that people aren't vulnerable, it just means that people don't know how vulnerable they are.
But it does make you much less vulnerable, because you're only vulnerable to the tiny proportion of attackers who have discovered a zero day exploit.
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.
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.
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.
There aren't several new diseases that people need to be inoculated against every month.
Unfortunately, nobody has invented yet a security vaccine. If you do, you can only regret they don't give Nobel prizes for computer stuff, but Turing award would be pretty much in the pocket for you.