PHP’s CVE vulnerabilities are irrelevant

Mattias Geniar, Friday, January 2, 2015 - last modified: Saturday, January 2, 2016

ircmaxell wrote a good blog post about usage of PHP versions in the wild, which shows the vast amount of different versions used. The summary is meant to provide an overview of "secure" vs. "unsecure" PHP installations, based on the known CVE's in previous PHP versions. The conclusion is that less than 25% of the PHP installations are secure. However, I think those numbers are all irrelevant.

I'm unsure if the list is complete, but here's an overview of known CVE's for PHP. There's a lot of them.

I'm active in the hosting sector. I manage and secure servers, used by clients to host their PHP code. Do you know how many hacked sites and servers I've seen due to PHP CVE's? Absolutely zero. How many are caused by outdated Content Management Systems or plugins? All of them.

We still see PHP 5.1 and 5.2 in the wild. They've been unsupported for years. They have known security vulnerabilities. But those are not being abused. What's an unsecure PHP installation? The one with an outdated WordPress or outdated plugins. Or a Drupal installation that isn't maintained. Or yet another WYSIWYG editor with upload functionality that is installed once, and never updated.

The most common security flaws are still the ones that get websites and servers hacked. The CVE's in the PHP code aren't easy to exploit. But a SQL-injection or Remote Code Execution vulnerability in a popular CMS? Those are the real danger.

I gave a presentation at PHP Benelux 2014 titled "Code Obfuscation, PHP shells & more: what hackers do once they get passed your code". In that talk, I never mentioned PHP CVE's. During the many discussions afterwards, CVE's were never the topic.

I love PHP as the language. I still do all my coding in it. Which is why it pains me to say this, but PHP's security problem isn't the CVE's of the core language, it's the users. It's in the nonchalance that users install their CMS and not look at it again. That's what gives PHP (among the many other things) a bad name.

WordPress 3.7+ does a really fantastic job on mass-patching security updates to all installations (if enabled). That still leaves Drupal, Joomla, Magento, ...



Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek, public speaker and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!

Comments

Brian Saturday, January 3, 2015 at 01:15 (permalink)

CVE’s list of PHP vulnerabilities is far from complete.

Reply


T Tuesday, January 13, 2015 at 21:29 (permalink)

Php 5.1 not supported ? False. It’s supported by centos 5 which will backport any vulnz until 31Mar2017.

Reply


BJ Hoffpauir Thursday, July 30, 2015 at 07:44 (permalink)

WordPress 3.7+ does a really fantastic job on mass-patching security updates to all installations (if enabled). That still leaves Drupal, Joomla, Magento, …

Mattias, love the blog – thanks for sharing. The one note that I always think of when I see this comment is how hard it is to balance this specific advice with the other thing I want to tell friends / family / business owners – you should be using source control to protect your systems and sites.

The challenge, of course, is that they wind up effectively having to choose one or the other. Once they try even basic usage of git or hg, they quickly learn that the auto-update features start to either get overwritten when redeploying from source control or more complex setups are needed to support local dev / staging / production environments. The trouble is when they inevitably do get hacked they will wish they had some sort of source control system even if they only ever needed it this one time….

It pains me because no matter how often you update your CMS, at some point you’re going to get hacked, especially if you’re a small business – there’s just too many entry points for anyone but professional IT teams to even try to keep up with (and even then we all know it happens at some point in our careers). I sometimes struggle with the sincere desire to provide unbiased advice based on my actual knowledge and the goal of providing a suggestion based on a user’s needs.

Usually I say, don’t waste your time or money – pay the extra $$$$ for a managed hosting plan as in the long run you’ll be happy. Thanks again!

Reply


    Mattias Geniar Thursday, July 30, 2015 at 09:19 (permalink)

    I sometimes struggle with the sincere desire to provide unbiased advice based on my actual knowledge and the goal of providing a suggestion based on a user’s needs.

    Exactly.

    There’s “doing the right thing” and “doing the thing right”.

    In most cases, especially shared hosting setups, having WordPress auto-update is “doing the right thing”. I’m with you 100% that version controlling your CMS is “doing the thing right”. It’s just not feasible for most users and that’s a reality we have to face.

    I’d much rather have an auto-updating CMS that prevents version control from working properly, than having to fix a hacked CMS every few months because version control is working properly but the client isn’t updating its CMS.

    Reply


Leave a Reply

Your email address will not be published. Required fields are marked *