Hot off the heels of a new exploit found in WordPress 2.6.1, the WordPress developers have released an update to WordPress, version 2.6.2. This release fixes an annoying security issue where a new user can register and have the password of an existing WordPress user changed to a random password.

From the WordPress release:

Stefan Esser recently warned developers of the dangers of SQL Column Truncation and the weakness of mt_rand(). With his help we worked around these problems and are now releasing WordPress 2.6.2. If you allow open registration on your blog, you should definitely upgrade. With open registration enabled, it is possible in WordPress versions 2.6.1 and earlier to craft a username such that it will allow resetting another user’s password to a randomly generated password. The randomly generated password is not disclosed to the attacker, so this problem by itself is annoying but not a security exploit. However, this attack coupled with a weakness in the random number seeding in mt_rand() could be used to predict the randomly generated password. Stefan Esser will release details of the complete attack shortly. The attack is difficult to accomplish, but its mere possibility means we recommend upgrading to 2.6.2.

I would recommend that all users, even those that are using WordPress 2.6.1 to update to WordPress 2.6.2 as soon as possible.

Scott

I have checked on the servers and I am seeing about 15 percent compliance with the WordPress update. This means that 15 percent of the WordPress installs that were outdated last week have either been updated or removed.

Our WordPress updater program is still available to those that want to try it to upgrade their WordPress installs. We have updated a couple of WordPress 2.5.1 installs to WordPress 2.6.1 and did not encounter any problems. I am not sure if the updater will work on anything less than WordPress 2.5.1.

We have also received a few complaints and concerns from users who do not believe that they have to update their blogs. Please understand that we do not make the rules on the Internet. It is just a fact that if you run outdated software on an account then you are more likely to be hacked into. If your account is hacked into, then this can have adverse affects throughout the entire server. This is why we are pushing to these installs updated. We are trying to raise awareness that you have to keep these installs up-to-date.

If you have concerns about the new WordPress interface or something about the new version of WordPress then you need to contact WordPress about this. You can reach the WordPress forums at:

http://wordpress.org/support

I know some users have written in saying that they are using WordPress 2.5.1 and that WordPress 2.6.1 does not contain any new security fixes. It is true that 2.6.1 does not fix any major security flaws in WordPress. While I still believe that you should upgrade WordPress 2.5.1 installs to the latest version, I am less concerned with those installs that are version 2.5.1. The main issue is with the installs that are from the 2.3 release tree. WordPress 2.3 had a lot of security issues and these issues also affected versions prior to 2.3. These installs need to be updated. If you won’t take my word for it, then ask around on the WordPress forum and see if anyone still believes you should be running WordPress 2.3.

We are just trying to be proactive in regards to this. In order to make sure the servers stay secure we have to insure that the servers are secure. Any server administrator that knows that there are accounts on their servers that are running and old and outdated version of a script or application and they do nothing about it, then they are not doing a very good job administrating the server. We are just trying to keep you informed and trying to keep your data safe.

Scott

We have sent out notices to all of the accounts that we show as having outdated WordPress installs. You should have received one of these notices if you have an outdated WordPress script on your hosting account and if your contact information is up-to-date in our billing database. If you did not receive a notice and you think you might have an outdated install you can always submit a support request and have our technicians take a look at your account.

We have posted instructions for upgrading WordPress installs. You can follow these instructions if you want to upgrade your WordPress install to the latest version. The latest version at the time of this posting is 2.6.1. If you installed WordPress through Fantastico then you need to log into your control panel and use the Fantastico link and interface to update your WordPress to the latest version. If you installed WordPress through Fantastico and you try to update it through some other means then this could have potentially adverse affects on your hosting account and WordPress install.

I have also developed an experimental WordPress updater that I can run on your account to upgrade a given WordPress install. At this time the software is just experimental, but I am willing to try the software on your account if you want me to and if you are aware of the risks. The updater may cause your WordPress install to stop working, but I need to run the updater on some installs to figure out if there are any bugs or any ways to improve the system. If you want me to run the updater on your WordPress install just submit a support request ticket with your valid username and password information and a note containing what WordPress install to update and a note that you understand the risks involved. I will have to have the correct username and password of your account in order to validate that you are the true owner of the account before I can run the update. I also may have to turn away update requests through the WordPress updater if problems are encountered.

If you are not using the WordPress installs that are listed and you want them removed, you can submit a support ticket instructing us to remove the script. Again we need to know specifically what WordPress install to remove and the valid username and password for the account. Please Note, if you tell us to remove a WordPress script from your account then that script will be deleted and cannot be brought back. So if you tell us to remove a WordPress script from your account, you need to be sure that this is really the action you want to take.

Some of you may be running reasonably up-to-date WordPress scripts on your account and you may be safe from any major security exploit. However I still recommend that you upgrade to the latest version of WordPress, version 2.6.1. You just never know when a minor flaw may escalate to a major threat. One thing is for certain, if you are always running the most up-to-date version of any actively developed script then you know that you have done the most that you can do to keep your script and website secure.

Scott

This past week I conducted a preliminary check on all of the servers for outdated WordPress installations. I found quite a few that were old and outdated. Keeping any script on your account that is outdated is a security risk. Most of the time developers release a new version of a script or application to address a known security risk. This is not always the case and in most cases the security issue is very minor, but a minor security issue is still a security issue and should be dealt with. If you are not keeping your scripts up-to-date, then you could be open to some type of vulnerability which can lead to problems such as website defacement or information compromise where someone steals information you have stored on your website.

I think one thing that is forgotten when users install a script or application on their website is that the management of that script or application is just starting. On the Internet software has to be maintained and kept up-to-date because it is continually accessible by the outside world. If you have Microsoft Office installed on your home computer and a new exploit for Microsoft Office is discovered, you can always just turn off your home computer and it will be impossible for that exploit to do damage on your home computer. On the Internet, its not easy to turn off a server. If the web server is turned off, then your website won’t work at all. This is why the only real option on the Internet is to continually check and make sure that all of your scripts and applications are up-to-date.

I have singled out WordPress in this particular security check. It will be impossible for me to check each and every account for up-to-date script software. This is because every piece of software is different and finding out what version is installed on each account can be difficult. There could also be thousands of different scripts and applications installed on all of our hosting servers. Each script and application would require their own system-wide version checker. WordPress is just a very popular blogging script and with it being so popular it is important to keep it up-to-date.

I am working on getting a full list of the accounts that have outdated WordPress installs. I am hoping to send out a notice to those accounts that have outdated WordPress installs sometime next week. However if you know that you have WordPress installed on your account and you have not updated it, you should consider updating the install. To download the latest version of WordPress you can visit their website. The latest version of WordPress is version 2.6.1. In the mean time you should make sure that your contact information is up-to-date with us. You can update your contact information by visiting our Account Management page and clicking the Update your Contact Information link.

I am also working on an update guide for updating WordPress. I will need to complete this before I will send out notices about the outdated installations. I am also working on an experimental WordPress updater which I can run on the server to update your WordPress installation.

So if you have a WordPress installation and you have not updated and you feel comfortable updating the installation on your own, you should consider doing this as soon as possible. Otherwise, you can wait for our official notice concerning outdated WordPress installs and our guide for upgrading.

Scott

We have had a few more concerns regarding the register_globals issue. We talked about this in a previous post, which provided some good insight. However, we still have quite a few users that are requesting register_globals to be turned on and don’t understand why we can’t turn it on. This post aims to cover this in a bit more detail.

PHP’s register_globals can be a security risk. The keyword here is that it can be. In and of itself, register_globals is not an issue. Take someone who has a good strong programming background and register_globals doesn’t have to be an issue. Take that same person and ask them why register_globals should be left enabled, and you won’t get a reasonable response. If a programmer writes the code to their program correctly, then register_globals being on won’t be an issue. Any good programmer should know that securing their program is of the utmost importance. So the issue becomes, either a programmer spends more time securely defining their variables so that it can work in a register_globals enabled environment or they heed the advice of the entire PHP and PHP development community and code their script to work with register_globals off. A good programmer will recognize why having register_globals turned off and why writing a program in such a manner is a good thing.

The real issue here and to try and put this tactfully, is that PHP is a real easy language to learn. It is simple, yet powerful in creating dynamic websites. The end result is that there are a lot of PHP scripts out on the Internet that were written by programmers who had a lot less (if any) training than a seasoned programmer. These less trained programmers are not as adept at focusing on script security and input sanitation. I’m not saying that any of the PHP scripts I create are perfect in terms of security. I’m not saying that anyone can write a PHP script that is completely secure and will never have any security issues. I am just saying, if you had a project programmed, one by a 30 year programming veteran with 10 years of PHP coding versus someone that just wrote their first PHP program 2 months ago, whose program would you trust more?

The problem is there are a lot of PHP scripts available today are poorly written. They don’t take into account security of the script and they are not maintained or kept updated. They were just written one day by someone and forgotten about. This is where security issues pop up.

Ask anyone that has a website if they would prefer to have their website hosted on a server that is constantly blacklisted for sending spam or constantly being turned off due to phishing scams. They would all say no, everyone wants to be hosted on a reputable and secure hosting server. This is what we try to provide. If we relax our security procedures for even one account, then that relaxed setting can have ramifications for all of the webhosting accounts on that server. If by enabling register_globals for domain1.com on a server results in a hacker or malicious user breaking into that script and then using our server to send out spam, then we have effectively caused inconveniences for accounts, domain2.com, domain3.com, and domain4.com that are also hosted on this server. A server is not blacklisted based purely on the domain that was hacked into or exploited, when a server is blacklisted the entire server is blacklisted, regardless of what accounts are on that server or how the spam was sent out. Likewise a phishing scam on a server can result in connecting networks removing their connections to the server. Without network connectivity a webserver is as good as dead.

This is what users need to understand when raising concerns about register_globals being disabled on our servers. We as a webhosting company have to look after the well-being of all of our clients on the server. If we’re not, then we’re not doing our jobs. If we aren’t paying attention to basic security concerns, then we aren’t doing our jobs. For each account on a server that wants register_globals enabled there are atleast 100 other accounts on that same server that are grateful that we did not. If other webhosting companies are allowing register_globals to be turned on for any client requesting it, without offering to educate the client, then personally I would have to question that company’s dedication to offering a secure webhosting environment.

Check out the latest list of security vulnerabilities on Secunia which mention register_globals. At the time that I wrote this there were nearly 680 security vulnerabilities listed when you search for register_globals. I did not check all of these, but I suspect the vast majority of these include a line similar to “Successful exploitation of this vulnerability requires that register_globals is enabled.”

This is one of the best pieces of evidence as to why having register_globals disabled makes good sense in the webhosting community. There are new security vulnerabilities found in scripts everyday that require register_globals to be enabled in order to be successfully exploited. I don’t know when a particular script is going to be listed as vulnerable. Its entirely possible that there are scripts out there that are vulnerable right now and not listed with Secunia. Further, I don’t have any way of knowing specifically what scripts each account has installed. The safe bet is to disable register_globals. This way, whenever a new vulnerability comes out, if it states “Successful exploitation of this vulnerability requires that register_globals is enabled”, then with our servers having register_globals disabled, the vulnerability will have no affect on our servers.

To better understand how security can be circumvented in a register_globals enabled environment, I suggest reading a post from IBM’s website. Specifically read the section under the heading Unintended user input. This goes into a lot of detail as to how security can be circumvented in a poorly written PHP script. The author goes on to show that you can effectively reduce the risk of this behavior by defining your variables at the beginning of the script. This is probably not a bad idea itself, but if you are going to take the time to modify the script and define the variables at the beginning of the script, why not just go ahead and take the extra step and update the script to work with register_globals disabled? This is the part that I don’t understand. If register_globals is enabled, then chances are you are going to have to modify the script in order to define variables so that outside users cannot taint the variables. If you’re going to be modifying the script, why not just fix the script so that register_globals is not a requirement for the script.

The PHP language developers, the people behind the PHP language, recognize the security concerns with register_globals. They made the decision to remove register_globals completely in PHP version 6. Now PHP6 is a while away, but still, if you expect to use a script in a PHP6 environment, the script can’t require register_globals. So if you are having to modify the script, you might as well update the script to work better with future PHP releases.

This explains why having register_globals enabled on a webhosting server is a bad idea. Can a PHP script be written so that it is secure even with register_globals enabled? Yes, I won’t argue that point. The point I want to make is that I don’t believe that this happens very often. In order to really make this determination a script would have to go through a very extensive security audit. I don’t have the resources required to perform these individual script security audits. Even if a script was determined to be safe with register_globals enabled, this still doesn’t change the fact that PHP6 will deprecate register_globals completely. So even if your script is secure with register_globals enabled, you will have to modify the script again when PHP6 is released.

I just really cannot see a good reason to have register_globals enabled for a script. If a script is important to you, then you want that script to be secure. The best way to secure that script is to insure that it works with register_globals disabled. If you are running into an issue with a script that you downloaded or purchased, you should check to make sure that you are running the latest version of that script, as the issue with register_globals may have been taken care of with a script update.

I hope this helps explain the issues surrounding register_globals.

Scott Mutter

Director of Administration