A few days ago we told you about the WordPress hacks, and how to secure your wp-config’s permissions. As we went to post the article in our own WordPress, we saw a post from WordPress in the little Dev Blog window.
Boy, Matt from WordPress is ma-aa-ad…
Summary: A web host had a crappy server configuration that allowed people on the same box to read each others’ configuration files, and some members of the “security” press have tried to turn this into a “WordPress vulnerability” story.
Ouch. Ouch ouch ouch.
Developers and web hosts have a symbiotic relationship – we run the platforms that developers code rests on. Both sides have to try and work together, and a lot of the time that simply doesn’t happen. A huge portion of support in both directions gets pawned off on the other party. The web hosting company blames the software and reminds the client that they don’t support third party software (this is code for “anything whatsoever you may install in our servers even when we provide it to you”), and developers are quick to blame web hosting companies for their code, which is always perfect, barfing up errors. If it’s a symbiotic relationship, it’s grudgingly symbiotic.
In this case, both WordPress and Network Solutions have a vested interest in taking this blame game a step further. And Matt certainly does.
WordPress, like all other web applications, must store database connection info in clear text. Encrypting credentials doesn’t matter because the keys have to be stored where the web server can read them in order to decrypt the data. If a malicious user has access to the file system — like they appeared to have in this case — it is trivial to obtain the keys and decrypt the information. When you leave the keys to the door in the lock, does it help to lock the door?
Matt’s spot on here. WordPress is absolutely not the only program that keeps login info for the database in plain text – far from it. When we’re asked to help fix a database connection issue on just about any PHP program backended to a database, the first place we begin looking is in the files, by searching for the database name. The password’s usually right next to it.
A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.
This is not an easy transition to make, but I’m giving this one to Matt again. This implies that Network Solutions did not isolate users from each other, and from the permissions being bandied about it appears they didn’t run with suPHP (and running any shared hosting service without suPHP is inherently insecure, IMO).
Years ago when we first started, I can still remember the panicked tickets of people that navigated too far up and got to the top of the home directory. We even had people write in screaming that our server was insecure because they could see everyone else’s files when they jumped around – and I’ll kid you not, when shared hosting started, there was very little that was private. Shared hosting had to evolve into being secure. It didn’t start out that way because it’s a hell of an art form trying to secure one network point that 500 people from all over the world have to have 24 hour access to.
I don’t believe that any modern shared server should be running without certain things, and suPHP + chrooted enviornments is absolutely one of them. I don’t care if you host with us (ok, well, I do), but if you have to choose a host, your first questions should not be about disk space you will never fill and bandwidth you will never use. Your questions should be:
If you don’t know what those things mean, you should learn so that you can recognize when your site, by virtue of the server its on, is at risk. People shouldn’t have to wait for Matt from WordPress to post a rant to point it out to them that their host is making choices that many other hosts and developers think is just flatly stupid.
If anyone outside of you and people you deliberately gave access to (and your host with root access) can get to your files, run. Do not use that host. Don’t. If you can navigate up to the /home directory in SFTP and it doesn’t look like you’re the only one on the server or it doesn’t slap your hand when you try, find another host. No shared server should be running without limiting configurations ensuring in every way they can that when one site is hacked, the entire server and everyone else’s site is not at risk.
There are server settings that make the concern about file permissions moot. Your host should be using as many of those as they can, if not all of them.
While I love you all, my wonderful clients and customers and bloggers and businesses, 90% of you depend on that one click install for your web software, and 25% of you email in after you install it wondering where it actually went once you clicked. If I depended on you to know how to change file permissions to secure your sites, we’d be announcing hacks every damn day and I would retire and open an ice cream shop.
It is our job to mitigate security holes in every way we can when we can assume you won’t understand enough to secure it.
If you’re a web host and you turn a bad file permissions story into a WordPress story, you’re doing something wrong.
As much as I hate to admit it, he’s right.
Despite Network Solutions being competition and a fellow web host and as much as I am supposed to come down on the side of the web hosts and not the developers by virtue of what we do and who we are, in this case, Matt is 100% right. If the hack was performed by a user with access to their system through gaining access to other people’s files on the same system, then their set up is insecure.
So, there ya go… Team WordPress.
P.S. Network Solutions, it’s “WordPress” not “Word Press.”
Er… Team WordPress.