"bad file permissions" caused SQL attack at Network Solutions, says Matt Mullenweg

“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,” said Matt Mullenweg, responding to recent malware attack on WordPress blogs hosted on Network Solution. “WordPress, like […]

“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,” said Matt Mullenweg, responding to recent malware attack on WordPress blogs hosted on Network Solution. “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 web server can read them in order to decrypt the data. If a malicious user has access to file system — like they appeared to have in this case — it’s 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? A properly configured web server willn’t allow users to access files of another user, regardless of file permissions. The web server is the responsibility of hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years. If you’re a web host and you turn a bad file permissions story into a WordPress story, you’re doing something wrong,” said Matt.