Tag Archives: shared hosting

MediaTemple, WordPress, and attack vectors

Posted on by

WordPress has been mentioned a lot lately. Is this application specifically vulnerable?

No. WordPress is a high-quality project that updates their software whenever a security problem is found. The latest versions do not contain any vulnerabilities that we are aware of. If you are running an old version, please update yourself. This is a common practice and should be familiar to any Windows or Mac OS X desktop user.

This being said, due to the ubiquity as one of the world’s most popular open-source publishing systems, WordPress is often the target of the payload with code injections and backdoor entry points after the attackers have maliciously gained access to a user’s website. The fact that WordPress is frequently a payload target DOES NOT mean that WordPress itself is vulnerable. It just means it’s popular and very powerful. You should continue to use it and we think it’s great software.

I couldn’t have said it better myself. Thanks MediaTemple.

GoDaddy

Posted on by

At the risk of this getting drowned out with everything else abuzz in the WordPress community:

On Thursday, I am visiting GoDaddy headquarters. Please post any questions you may have for them and I will see to it that I can get them answered.

Some background: GoDaddy hosts a few hundred thousand WordPress sites, many through a special package. They have been bitten by the same attacks affecting other hosting companies. I previously mentioned GoDaddy when compiling my thoughts on WordPress security and the shared hosting attacks, and I didn’t mince words then.

What should I ask?

On PHP

Posted on by

By lwr. CC BY-NC-SA 2.0

I’ve been meaning to write this post nearly a month now, on the heels of WordPress 3.0′s release and preparing for an inevitable future discussion of when we should drop PHP 4 support. 1 And then current events give you the hook you need to sit down and do it.

A peculiar bug sent over the mailing list for WordPress support forum moderators piqued my interest. There was an incompatibility with WordPress 3.0 and Earthlink hosting, with no known solution. Until this point I wasn’t even aware Earthlink did web hosting. I’ve enjoyed communicating with MediaTemple, GoDaddy, Network Solutions and Dreamhost on Twitter, but I couldn’t find Earthlink, so I picked up the phone and simply called their support line.

I explained who I was, and someone helpfully filed my contact information in a ticket reported by an Earthlink customer. I wasn’t expecting a response, at least not a speedy one, but the next day I received an email from Earthlink.

I give them a ton of credit for this, because the initial email I received included everything they knew, along with full access to a test server. Since the email also included the fatal error from the log, I pulled up the file and line, and realized the problem immediately.

Well, not quite. The fix was obvious, but the bug was not. I consulted with Peter Westwood and we were able to locate two seemingly relevant PHP bugs and a note in the PHP 5.1.0 changelog. 2

Here’s where Earthlink stops receiving credit: they were running PHP 5.0.5, released in 2005. (I may agree with WordPress supporting old versions of PHP, but that doesn’t mean I support them being used.) Apparently, there was a change in 4.4 and 5.0.5, fixed in 5.1.0, that prevented you from passing by reference into one function the return value of another function, and requiring you to assign it to a variable first.

A few things to emphasize. This affects very few installs. Our PHP 4 usage is very low as of late, and given the few reports of the issue and that they can all be tied back to Earthlink, 5.0.5 is not seen in the wild often either. So while the fix is included in WordPress 3.0.1, there is nothing we have seen that would make me think we should speed up the 3.0.1 release, which generally comes about a month after the initial release. 3

While we do PHP 4 compatibility testing, as of late it is limited, which has valid reasoning but is also a valid problem. Even testing under our minimum requirements, 4.3.0, would not have caught this bug, which was only in 4.4 and 5.0.5.

Continue reading →

Notes:

  1. I look forward to discussing both when I speak at the DC PHP meetup in August. ↩
  2. “Allowed return by reference from internal functions.” ↩
  3. Version 3.0 was a very stable release, especially considering the massive amounts of refactoring that went into custom post types, the merge of WordPress MU, and improved custom taxonomy support. Plugins I have seen labeled as incompatible weren’t working right in earlier versions. ↩

Some thoughts on WordPress security and the recent shared hosting attacks

Posted on by

After being a guest on the ExplicitWeb podcast, recorded this afternoon, I noticed that I had been asked on Twitter to talk about what my thoughts were on the current hacks on WordPress and other PHP sites. We didn’t dive into security, instead talking about WordPress 3.0, the development process, and how to contribute, but I wanted to address this very valid question, and in more than 140 characters.

As of this writing, there are no known exploits of WordPress 2.9.2. The viruses going around on various shared hosts appear to be indiscriminately targeting any and all PHP files, and there is no indication that the payload is being delivered through WordPress. Indeed, there are some accounts that are not running WordPress but their PHP files are still being infected.

WordPress is incredibly secure, and we also take security very seriously. E-mail security@wordpress.org if you believe you have discovered a vulnerability. All indications are that these are server and hosting configuration issues. Network Solutions admitted the hacks infecting their users were their fault, while GoDaddy is demonstrating arrogant cluelessness.

WordPress is incredibly popular and used by millions, and thus is an obvious and very public target. But I wish to emphasize that there is a huge difference between a hack exploiting WordPress, and a hack targeting WordPress. Many bloggers are grouping both types of attacks as “WordPress hacks,” even though none are exploiting WordPress directly, and that other PHP applications are being infected — WordPress just happens to be the most widely used.

The difference is significant. A hacker can infiltrate a server and target WordPress files or the database without exploiting WordPress itself. This is quite common because WordPress is so commonly used. A hacker exploiting WordPress means that they are using a bug or vulnerability in WordPress as the attack vector. This is quite rare, especially in more recent versions of WordPress. When a vulnerability is discovered, it is fixed quickly and an update is released. Keep up to date and always ensure you are using the latest and greatest version of WordPress, currently 2.9.2.