It’s been a while since we made a blog post, I’ll see if I can dust this off.

Currently, our servers are running PHP 5.4 by default. The term “by default” means that unless you have made any requested changes to your account’s PHP version, then PHP scripts on your account are parsed through PHP 5.4.

PHP 5.4 will soon reach it’s end of life. This is scheduled to happen on September 14, 2015, a little less than 2 months from now. The term “end of life” means that no more attention will be paid to it. Effectively, this means that if a major bug is discovered in PHP 5.4 after it goes end of life, then it will not be fixed. This makes sense from a developer’s standpoint, because you cannot support something indefinitely.

What does this mean for you?
Technically, end of life’d software shouldn’t be used because of the risk of security bugs being found and not addressed. This is what happened with Microsoft and Windows XP a few a years ago. Windows XP went end of life and users were encourage to upgrade to a new operating system that Microsoft supports. However, in the real world this can be difficult to do (anybody know of anyone that still uses Windows XP?). Our intention isn’t to drop support for PHP 5.4 immediately. I will add the caveat that if a major security issue is discovered in PHP 5.4 after it reaches end of life, then we may have to cut off PHP 5.4 access when/if that happens.

Currently our servers support 4 different versions of PHP:

PHP 5.3 – End of life’d August 2014
PHP 5.4 – End of life pending September 2015
PHP 5.5 – Anticipated End of life July 2016
PHP 5.6 – Anticipated End of life August 2017

(PHP 5.3 is limited because it went end of life in August 2014, access to PHP 5.3 has been cut off for some servers and it is not being reactivated on those servers).

Keeping 4 different versions of PHP is far from ideal. Keeping 1 version is the most ideal, 2 versions is acceptable, 3 versions is tolerable, but 4 versions is just not something we want to do.

What are our plans?
Right now, we are planning to phase out PHP 5.3 completely before the end of August 2015. We would like to switch the default version of PHP to version 5.6 sometime in August 2015. And leave PHP 5.6, PHP 5.5, and PHP 5.4 available as different PHP options for accounts. Support for PHP 5.4 would be phased out by August 2016 or sooner, depending on how adoption of newer PHP versions takes place.

What does this mean for our clients?
Any reputable script or plugin/theme/extension/component is going to stay in tune with PHP’s development. If any reputable script developer is surprised by PHP 5.4’s impending end of life in September 2015, then sadly they are not very good at their job. If they have not made plans to move their script into a working PHP 5.5 or PHP 5.6 environment, then they are not paying attention, and it’s probably a sign that you shouldn’t be using their scripts. Most major script developers, like WordPress, Joomla!, and Drupal have written their code to be compatible, at least with PHP 5.5 if not PHP 5.6. The greater question is, are you using the latest and a supported version of their scripts?

An example might be Joomla! 2.5. I do not know if it is compatible with PHP 5.5 or PHP 5.6, but I know Joomla! 2.5 itself is end of life’d. If you are using Joomla! 2.5, then you are using and depending on an unsupported version of Joomla! You need to be updating to a supported branch (Joomla! 3.4) then if you have problems using PHP 5.5 or PHP 5.6, then that burden falls on the Joomla! developers for not properly maintaining the script.

Bottom Line: Make sure you are using the latest or a supported version of the script on your website.

We will post additional updates on the progress of the PHP changes on our servers through this blog. You can follow the progress through this link.

For reference – PHP supported versions: http://php.net/supported-versions.php

Steven

A critical vulnerability has been found in the Slider Revolution plugin that is popular in WordPress either as a stand alone plugin or packaged with many different themes.

We are working on getting messages sent out to users that may have been affected by this.

If you received a message from us that sent you to this blog, then you need to check and make sure the Slider Revolution plugin on your website is up to date. If you are using a theme that is using Slider Revolution then you will need to update that theme, assuming that the theme developers have updated the Slider Revolution that is packaged with their theme. You will have to contact your individual theme vendor or developer for more information on this.

If you installed Slider Revolution as a stand alone plugin, you will need to update it. See:

Slider Revolution Responsive WordPress Plugin

for more information.

I am sorry that we cannot be of much more help regarding this. Slider Revolution isn’t something we created or developed and play no role in it. You will have to contact the companies and individuals that you installed this from for more information. We are only passing on information that this has been compromised.

Additional Information concerning this exploit can be found at:

Slider Revolution Plugin Critical Vulnerability Being Exploited

Steven – AMS Support

One of the issues that has arose with the switch to PHP 5.4 has to do with MySQL username passwords. If you created a MySQL username and password combination many years ago, on a system that predates MySQL 4.0, then PHP 5.4 is not going to recognize this password. This has to do with the change of MySQL engines that PHP 5.4 uses versus what previous versions of PHP used.

If you see an error message or warning message on your website that says the page is not able to connect to the database server or error connecting to database server, it is likely that you are being hit by this issue.

If you are being hit by this error, you can submit a support ticket and our support staff will assist with this. Just be sure to include a link to the website or webpage that is giving you this error message.

You can also resolve this issue yourself, by changing or updating the MySQL password that your script uses. You can even use the same password, the system just has to update itself to store the password in a way that the new PHP 5.4 MySQL engine will understand.

– Before you start, you either need to know what the current MySQL username password is for your script or know how to change the password in the script’s configuration. If you do not know this information or do not know how to gather or change the information, then you will probably just want to submit a support ticket and let our support staff handle this issue for you.

To change or update the password for a MySQL username, log into your cPanel:

http://www.yourdomain.com/cpanel

Find the section labeled Databases and look for the MySQL Databases icon:

Click this icon.

Next, scroll down to the bottom of that page, you’ll find a section labeled Current Users. In that table you’ll see a list of your MySQL usernames:

Click on the desired MySQL username that you are wanting to change or update the password to.

Next, you’ll get a page labeled MySQL Account Maintenance and you will see the MySQL username you clicked and two boxes for the password:

Type the password for the MySQL username in both MySQL fields, or enter a new password in both MySQL fields, or use the Password Generator button to generate a new password, then click Change Password.

The password to this MySQL username should then be changed. If you reused the same password, then your script should be working now. If you entered a new password, you would need to update the configuration file for your script to use the new password.

As always, if you need assistance with this, you can submit a support ticket at:

http://www.amshelp.com

Steven – AMS Support

PLEASE READ IF YOU ARE SEEING A LOGIN PROMPT WHEN TRYING TO ACCESS YOUR WORDPRESS ADMIN AREA

Some of you may be aware that there has been a growing BOTnet across the Internet that has essentially been launching a DDOS attack on WordPress scripts throughout the Internet.

WordPress is an extremely popular blogging and CMS platform. Many people use it. It is widely installed throughout the Internet and on our web hosting servers. This makes it a very inviting target for hackers and other malicious users to take advantage of.

The attack is basically a system of thousands and thousands of IP addresses all trying to login into various site’s backend WordPress admin panel. All of these requests undermines the performance of the server, because the server has to respond to each of those requests. This is why this essentially becomes a DDOS like attack.

Up until now, we have been able to mitigate most of this with a series of IP blocks. But unfortunately this system is reaching it’s saturation and is no longer being effective. The next step to mitigating this is to employ a specific web/captcha system. With this enabled, you will see a dialog box when you go to log into your WordPress admin panel, telling you to enter a specific set of characters for a username and answering a simple arithmetic/addition problem as the password. This is becoming the standard way to mitigate this attack.

We don’t yet know if we will deploy this server-wide or if we will do it on an account-by-account basis. But it is becoming clear that we are going to have to deploy this system in some capacity.

If you see this dialog box pop up on your WordPress admin panel login screen, don’t be alarmed. It is a mitigation solution to stop this WordPress login attack.

We do apologize for having to deploy this, but if we do nothing this attack is just going to continue to undermine server performance for your site and all of the other sites on our web hosting servers.

Steven

Some of you may have recently received a notice from us regarding the end of life for PHP 5.2. If your account is using PHP 5.2, then you would have received this notice (most of our user accounts are running PHP 5.3, so this notice only went out to a small subset of our client base. Don’t be alarmed if you didn’t get a notice). We have received a lot of questions from users regarding this. Most of them center around users who want to keep using their outdated scripts that are not compatible with PHP 5.3 and higher. That is a bad idea, and I hope to answer some of the questions as to why in this post.

What is End of Life?

Over time software reaches a point to where it cannot be patched any more. Commonly used hardware changes, end-users expectations change and you just can’t “fix” software to account for all of that. When that happens, software has to be rewritten. If you’ve ever wondered why Microsoft releases a new version of Windows every few years, this is precisely why. Windows XP was a great product. But they just can’t keep adding to and patching Windows XP for all eternity. Eventually the developers at Microsoft take what was good about Windows XP, optimize that, add new features and release an updated operating system with better and more efficient code that works better with updated hardware and with end-user expectations.

All of this leads to software going end of life. Microsoft and other companies cannot support software forever. As far as they are concerned, they have released an updated and better version of their software, end-users should upgrade or switch to that product. Support for these old pieces of software eventually dies off. That software goes “end-of-life”.

Why is End of Life Important?

End of life means that the software no longer has any support. It’s no longer being developed. It’s not longer being cared for or cared about. Deficiencies found in the code of end-of-life software are met with shrugs and “who cares” responses from the developers. As far as developers are concerned, they have moved on to another project an updated code and only worry about maintaining that.

Take PHP 5.2 for example. It’s possible that a new root level security hole could be uncovered in PHP 5.2. This security hole could be extremely nasty, making it very easy for any would be malicious user to instantly gain root level or escalated privileges on the server through this security hole. If this were to happen, do you know what the developers for PHP (http://www.php.net) would do? Nothing. They would shrug their shoulders and say “well, you shouldn’t be using PHP 5.2 anyway.” This is why using end-of-life software, especially in a web environment where the applications and content is easily accessible to any user, is a dangerous idea. Monitoring for security holes in end-of-life software is very low, because it is end of life and not suppose to be used. So an exploit may be found and may not reach the mainstream community until months have passed.

Users that use Windows XP, you should be aware that your end-of-life is quickly approaching. Support for Windows XP ends on April 8, 2014. After that date there will be no more patches and no more support for Windows XP. If a security hole is found in Windows XP after April 8, 2014, it will be met with a shrug and a whimper from the developers at Microsoft.

Now, if you have a computer that is not connected to the Internet and you continue to run Windows XP, this is less of an issue. The computer is not easily accessible to just any user. Only certain people would have physical access to the computer and by doing that you can have a basic audit of who is using the system. You can’t have that audit in a web application environment. If it’s on the Internet, then anyone with an Internet connection conceivably has access to it. End-of-life means more when you cannot audit and restrict who has access to the system.

What if I don’t want to upgrade?

There’s really no tactful way to answer this question. You have to upgrade or stop using that product or run the risk of being compromised. Those are your only 3 options once a product reaches it’s end of life. If you continue to run Windows XP after April 8, 2014 and your computer gets infected via a security hole, you cannot go to Microsoft and complain to them about not fixing that security hole. Or at least you cannot be surprised when they don’t offer a solution (other than upgrading to a support version of Windows).

I understand that some software may not offer free upgrade paths. Microsoft Windows is like this. Just because you bought Windows XP doesn’t mean that you get a free copy of Windows 7. Whether that is right or wrong or the ethics involved, that’s not for me to say. But that is an understanding (or should be an understanding) that you have when you purchase Windows XP. You should be aware that you will eventually have to pay for a Windows upgrade at some point when Windows XP goes officially end-of-life.

vBulletin may be web application that many users use that may also be affected by this (I’m not really sure what their upgrade procedure is, I know it is a commercially licensed piece of software, but I do not know if you have to purchase each subsequent major vBulletin release). But this is something you need to find out before you purchase any software. What is the life cycle of that software? How long will that software be good for? Will I have to pay to upgrade to the next version when the life cycle of this particular product ends?

The good thing about free software is that it’s free to begin with and free for the upgrades. For example, Ubuntu – a popular end-user Linux distribution, is a free operating system. Ubuntu 10.04 was released in April 2010 and went end-of-life in May 2013. Ubuntu 10.04 is no longer supported by the Ubuntu developers. But when Ubuntu 10.04 was released in April 2010 it was free. When Ubuntu 12.04 was released in April 2012, it was also free. Users of Ubuntu 10.04 had to upgrade to Ubuntu 12.04 prior to Ubuntu 10.04 going end of life.

I can understand people’s frustration at having to rebuy software for upgrades. I’m not sure how a lot of commercially available web applications approach this (like vBulletin). I encourage you to discuss this with the developers of those applications if you believe it is unfair for them to charge you for an upgrade. The fairness of the that issue is really beyond the scope that I am after in this post.

I’m also not going to argue that some of the upgrades, upgrading from one major version to another, can be difficult. That is very, very true. But again, that’s an issue that needs to be discussed between you and the developer of the software. People tend to not look at this issue or the upgrade cost issue in a web application, they seem to think that they can install it on their website and it will be good forever. That’s just not the case. That is a myth. Because web applications are freely accessible to any user with an Internet connection, keeping them up to date and secure is even more important that any isolated system where an end-user accessibility audit can be done.

So all of that is the importance of why end-of-life matters. Because some of our servers continue to run PHP 5.2 and because PHP 5.2 is end-of-life, that can be a problem. If you are using a script that still requires PHP 5.2, then I’m sorry to say, but you’re really using software that is also end of life and that is leaving you vulnerable to being exploited and hacked. The security of our servers is important to us. Protecting your data and the data of every user on the server is important to us. That is why we are stressing the importance of this end-of-life notice.

Steven