Interview: Denis Sinegubko, Malware Researcher and Unmask Parasites
Back in May I posted about WordPress websites distributing malware in Google Image SERP. This research was done by Denis Sinegubko, a malware researcher and the developer of Unmask Parasites, a tool to help you find security vulnerabilities and hidden content on your website. In between putting together another mammoth blog post on Google image poisoning,
Denis took a few moments to do an interview with me about the new PHP and MySQL requirements for WordPress 3.2. Here’s what he had to say:
1. WordPress is expecting users to have PHP 5.2.4 and MySQL 5.0. Is this now the standard across web hosts?
Here are some W3Techs.com stats (I believe it uses May 2011 data)
- PHP 4: 7.8% of all PHP sites
- PHP 5: 92.2% of all PHP sites
So PHP 5 is virtually a standard these days.
So the combined share of PHP <5.2.4 sites (PHP4 +PHP5.1 +PHP5.2.0-3) is about %20 of all PHP sites.
When I check websites, I regularly come across sites with PHP version < 5.2.4 so this number is quite plausible. I talked to guys at Sucuri and they estimate that about 15% of sites they monitor are not compatible with WP 3.2.
I believe that major hosting providers mostly use compliant software, but it’s hard to tell unless you ask them.
For example, lets check what big players advertise on their shared hosting plans:
- Hostgator : “Unlimited MySQL Databases” and “PHP 5”
- GoDaddy: “MySQL” and “PHP5”
It is not clear whether MySQL is version 5 and whether PHP 5 is newer than 5.2.3.
- DreamHost is a bit better. They say “MySQL 5 Databases” (good) and “PHP5 Support” (again not clear whether it is >=5.2.4 or not)
So you have to ask hosting providers if you are thinking about installing WordPress. Moreover, sometimes versions of software may be different on different servers of the same hosting provider. So you need figure out whether your particular server is compliant.
2. Why do you think WordPress are making the switch and why now?
I not an expert in WordPress low level architecture and I don’t closely watch what new features they add to 3.2. But I guess, that main reasons for the switch are:
- Convenience of development – new features in PHP5 and MySQL 5 make the development process smoother while supporting legacy systems bloats the codebase and makes it harder to maintain thus significantly slowing down the development process and making it more prone to errors.
- Performance – MySQL 5 has numerous performance enhancements over v4. No one likes slooow blogs.
- Security and stability – PHP 5.2.4 fixes quite a few bugs (including security bugs). The chances are the development team has run into some of those bugs when tested new features.
3. How will this affect WordPress users who are unable to upgrade?
I haven’t tested the built-in “Automatical upgrade” feature as it only upgrades to the latest officially realeased version and version 3.2 is still a Release Candidate. Anyway, I hope when 3.2 is finally released, this “auto-upgrade” feature will check whether the system is compatible with the new minimal system requirements before actually upgrading the blog. Otherwise, many users will automatically break their blogs and I doubt that all of them will be able to rollback the upgrade.
Another interesting situation is SVN upgrades. For many reasons I prefer to use SVN to upgrade my blogs. So to upgrade a blog, you simply need to switch to a new tag branch. When I updated my test blog to WP3.2 RC2 on a development machine and tried to open the admin interface (which would usually ask me to press a button to upgrade database), I discovered that the blog wouldn’t open. All it said was (in my words): “WP 3.2 RC2 is not compatible with your version of PHP. Go get at least PHP 5.2.4“. This way I found out that my development machine used PHP 5.2.3 ;-)
So this maybe a big surprise for some users who use SVN updates on slightly outdated systems. Remember, very few people actually read system requirements, especially when upgrading something that already works well.
Fortunately, with SVN, it is equally easy to rollback to some previous version (in my case it was 3.1.3).
The same surprise and a bit more hassle with rollbacks will be experienced by users who just download WP archives and manually unpack them on their servers.
4. Should people consider moving hosts if they are unable to upgrade?
It’s probably a good idea if they know how to move sites or can find people who can do it for them.
5. What are the dangers of not upgrading at this point?
The main danger is that webmasters who regularly upgrade their WordPress blogs will get used to not be able to upgrade their blogs. They may feel bad about it when they can’t upgrade to WP 3.2. If nothing bad happens to their blogs after they missed the upgrade they may finally decide that upgrades are not that important. So a few months later they may even give up the idea of finding a fully WP-compatible host to be able to keep their blogs up-to-date.
As a result, if some day hackers find a security hole in WP 3.1.x branch, those blogs will be easy prey. Moreover, they won’t be able to easily prevent future attacks by upgrading to the latest version of WordPress…
In my experience, many owners of WordPress outdated sites want to upgrade their blogs but they can’t do it for some technical reasons:
- their blogs heavily rely on plugins that aren’t compatible with the latest version of WordPress
- they have a highly customized version of WordPress (patched WP core files) and the developer is no longer available.
They all have similar problems: they can’t upgrade WP and have to stick with what they have now (and hope that hackers won’t notice that.)
6. If users are unable to upgrade, do you have any suggestions for how they can protect their WordPress installations?
If you can’t ensure your site security (think about WP vulnerabilities that can be discovered in upcoming months), you should have an efficient disaster recovery plan:
- Fresh backups of the database and all files.
- Integrity monitoring – be warned then something unwanted happens
- Easy procedure of restoring your site from a backup.
There are tools and services that you can use for individual tasks and there are tools and services that combine all those tasks. For example, advanced users may use version control systems such as Subversion or Mercurial for backups, integrity monitoring and automated roll back to known clean states.
Less techie bloggers may resort to services like CodeGuard that provide an easy-to-use web interface for all those tasks