Without knowing the OS and patch version number, whether or not a company uses PHP 5.3 is completely irrelevant to how secure they are.

Ubuntu 12.04 LTS ships with PHP 5.3.10, and has been backporting security fixes since the PHP project EOL'd it. This will continue until April 2017.

RHEL 6 and CentOS 6 both support PHP 5.3.3, and will continue to do so for the remainder of their impressively long support cycle, until November 2020.

There's been a lot of FUD about outdated PHP versions going around in some circles, and I'm frankly very annoyed by it. Free and open-source software aren't like Windows XP. The original developer(s) announced EOL, so what? I'm under no obligation to get my PHP interpreter from the original developer(s), I get it from Red Hat and/or Canonical.

The whole point of having a stable Linux distribution is so that you can stop worrying about upstream EOL issues. Heck, RHEL/CentOS have even been backporting security fixes for PHP 5.1.6, not that any sane person would want to use that dinosaur of a version.

Some of the hosts on that list, however, are indeed using dangerously outdated PHP versions. Feel free to name and shame them.

To clarify, when we say outdated PHP 5.3, we only mean the standalone PHP version. When an ubuntu version was detected, it was correctly marked as maintained. So all these hosters use 5.3 without package managers.

That sounds much better. Please clarify it in the article so as not to spread FUD.

It would also be helpful to release a table of the exact versions you found, instead of merely linking to their websites. Those who are still running PHP 5.2 deserve to be shamed even more!

How are you scanning to detect the OS version though? And verifying if PHP came from a package or a separate compile? Some hosts deliberately fuzz external indications of the base OS so you'd need an account to log into to properly check this, and they could have a compile from source version of PHP due to install procedures that date back before major updates to the base OS (and were updated "the wrong way"). Your effort is laudable (I'm all for naming and shaming the insecure) but you are open to false positives which could cause you legal issues.

By using multiple versions of multiple software, you can determine the false positives. There are little servers that deliberately fuzz external in a consistent way of all software found. Mostly they only do PHP or Apache, but forget OpenSSH. If there is a hoster doing it in consistent way and ended on our shame list. Please stand up, you deserve a full new blog post about how it should be done.

I wonder if anyone bothered to contact the hosters? If not I think this is in poor taste. As far as I'm concerned when you see issues like this the right thing to do is to reach out to said companies, detail the problem you found and give them some time to fix it before setting up a wall of shame.

Besides that, being up to date with software patches is hardly the only measurement of good security. The fact that some hosters don't even provide 2FA for your account would have me equally if not more worried, as would their practices regarding storing data and credentials.

It is definitely not the only measure. There are many more aspects of security. But a hacker only needs to find one gap. So the security is not the average of all aspects, but the minimum. So finding hosters that fail one aspect (outdated software) are already problematic.

That is the reason why security is hard ;)

Mediacatch here. We really do appreciate it. I'm surprised we made it to the list of 100 hosters since we're very(extremely) small compared to the others.

As to the issues:

- Our apache was 2.2.29, it is recommended for 2.2.31 due to the 1 CVE. The re-compile is running now. Edit: It's now done.

- We use a piece of software called cloudlinux, and it features the ability to switch PHP versions. We just moved this server a few months ago and it had PHP 5.2 as the default. Admittingly, this was an oversight and I've just switched it to PHP 5.3.29. This PHP version does have security backports for CentOS/RHEL 6. This is the latest version that we can use due to our billing system. We use WHMCS, so we need to go to V6 instead of our current V5. This is a large undertaking since we need to re-theme a complex theme.

- Openssl/OpenSSH is now up to date according to the CentOS repo, which has backported patches for exploits mentioned. I'm actually not sure why this wasn't auto-updated since we had that enabled like our other servers. We don't have the experimental J-PAKE enabled, so the 2 warning vulnerabilities that your system cited are not relevant.

I've also run this your tool again on our site to confirm the openssl/openssh were fixed.

You didn't provide a contact on your blog post, would you be able to please downgrade/remove us?

Thank you.

Glad to see you fixed the issues, I absolutely love it that you acted to fast. You have been removed from the list.

> sometimes see that their front page has outdated PHP, as in 5.3 old. EOL for 11 months. That really bothers me. How can I rely on their security when their frontpage isn’t even up-to-date.

Errr... are you determining that the software is vulnerable through the version number alone? That won't work, some vendors backport security patches.

A version that has been end-of-lifed and is superseded by three minor releases is a pretty strong indication. The amount of work involved in backporting patches is likely to be significantly more than migrating to a supported version which receives timely patches.

No it's not a strong indication at all. Red Hat does the backporting work for you. You choose that platform if you want your software you spent man-decades writing to keep working for 10-13 years.

It is a strong indication, because we are talking about non-packaged versions. PHP 5.3 is still maintained in Ubuntu, so those hosters aren't on the blame list. Only if PHP 5.3 / 5.2 / 5.1 is used without package manager.

It might be a strong enough indication to investigate further, but it is not a strong enough indication to out a company. You need to actively test the vulnerability to be sure (or relabel your page with a heavy disclaimer).

That is true, there are many manufacturers that keep up to date and add their own patches. Though for a frontpage, I don't think that is true. It is much easier to update your software, than going through all patches, keeping up to date. So for clients I believe you can maintain 5.3, but for just your own frontpage? I doubt it...

Also I would believe that having PHP 5.3 is an unique selling point, so they would advert that unique selling point on their website. (What wasn't done)

> It is much easier to update your software, than going through all patches

If you're on CentOS, as a lot of web hosts are, all you need to do is `yum update` from time to time.

Yes and then you are using a packaged version. But those hosters don't use a packaged version. So yum update doesn't work. I would definitely advice everybody to use a package manager, because that helps you keep everything secure ;)

Because PHP au contrary to Apache returns the full packaged version (so PHP packaged version are easier to check out). Also having e.g. OpenSSH ubuntu version strongly suggest you are using PHP ubuntu version. In that way we could cross out some of the packaged versions.

How do you know that they don't? You state it, but you offer no proof to support that.

The dominant control panel on the web is cPanel, which offers no ability to used packaged versions of PHP, Apache, or any of its extensions. They have a special interface used to pull in everything (sources, and even custom patches from cPanel) and compile it on the server and install it directly (configuring PHP, Apache, and any of the chosen extensions) automatically.

"Error establishing a database connection", googlecache here: http://webcache.googleusercontent.com/search?q=cache%3Ablog....

The HackerNews effect, was unfortunately down for 3 min. Should be okay now. Apparently login into Wordpress was a query to much.

Pro-security? Stay away from shared hosting.

VPS/VDS are cheap nowadays

Depends on whether you consider "privacy" as paramount in your security, in that case VPS's aint that great either.

Shared hosting can be more secure than most self configured dedicated hosting options, simply because the hosting providers "cares" about the security in the former while outsourcing the risk to you for the most part in the latter.

If say we look at how many times a shared hosting provider was compromised (excluding stolen credentials for individual accounts since it doesn't matter if they steal your credentials for the shared control panel or for the SSH on your dedicated box) i think the picture will be quite different than what you imagine.

Big hosting providers rarely get actually compromised, on the other hand self configured dedicated hosting boxes get owned everyday by the truck load, from configuration issues to missing updates to unhardened environments they tend to be much more vulnerable.

Shared hosting providers need and do lockdown everything since their adversaries are not only external attackers but also customers with high degree of access. This doesn't just reduces the likelihood of a security issue but also reduces the impact of such issues for example SQL injection on a shared hosting will yield pretty much nothing, yes they'll be able to dump the application tables but that's it, forget about code/command execution that DB is locked down harder than one would think it's possible same thing go for other issues, local file inclusion? well GL, directory traversal, breaking out of the chroot, try agin...

Now this ofc doesn't mean that some one can't configure their own box to be just as secure for but for all effective purposes if you are running a small operation like a personal site or a site for you own small business the chances of you being able to effectively managing security at the same level of a solid hosting provider is quite slim.

In that case, you will probably need additional budget for a sysadmin to keep it up to date.