WordPress Database Backup: Directory Traversal Vulnerability

Thanks for the heads-up.

Thanks, skippy. You are, as always, a class act.

Hey skippy, I know you’re working on this (thanks for the heads up) But, for the time being, do you (or anyone else) have a recommendation as to what to do? What I mean is, will deactivate the plugin suffice or remove should it be removed completely?

My recommendation is now and always has been to not only NOT activate the plugin but to delete it. That’s nothing to do with skippy, just because I’m a paranoid bitch, and I don’t leave ANYTHING world-writeable.

lol @ vkaryl. I didn’t take it as anything to do with skippy. That plugin of his saved my butt – twice ?? However, I would agree vkaryl – thanks for the info.

Matter of fact, I’m heading over to skippy’s site right now to drop a small donation. Might be nice if others would too as he’s working hard to fix the issue (I do not work for skippy) ??

Yup. All too true. I realize that the world is full of folks who don’t know how to get a db dump, but truthfully I do NOT think it’s a kindness to hold their hands like this….

not sure what you mean by “I do NOT think it’s a kindness to hold their hands like this…” but I assume you are talking about the security issue <shrug>

I’m talking about including with the distro a plugin that requires one leave a whole area of one’s site world-writeable because a few people are too lazy to figure out how to do a database dump the normal way.

[That falls within “being a bitch”, btw.]

I renamed the file from wp-db-backup.php to something else. That way, when I replace the file with the fixed version I won’t need to re-activate it. Of course this means that cron jobs won’t run, but that shouldn’t be a big deal for the time being.

I honestly don’t know whether WordPress allows execution of the plugin when accessed directly, even if the plugin has been disabled.

vkaryl: for the record, the original version of my plugin only required write access to the /backup/ directory inside /wp-content/ and then only for the web server, not for everyone.

When Matt bundled WP-DB Backup with the core WordPress download, he modified it to use a semi-secret suffix on the directory name, so that folks couldn’t guess the on-disk location of the backup files. This was a reasonable thing to do.

The plugin tries to automatically make this directory, and dies if it cannot succeed. As such, the /wp-content/ directory needs to be writable. Again, it really only needs write access to the webserver, but the docs team seems to have found it easier to just tell people to make it world-writable.

I questioned Matt about this, and his reply was “/wp-content/ was always meant to be writable.” I disagree strongly with this position, myself, but it’s out of my hands at this point. *sigh*

vkaryl,

[That falls within “being a bitch”, btw] yeah, I’ve noticed alot of that around here to be honest.

I just don’t see the need for being that way myself – I guess to each their own. I just figure this is a place to seek help – from newbie’s to even seasoned veterans with really difficult sql issues (relating to wp)

Personally, I think it a good thing to add the plugin to make it easier for people to save their work, until they graduate to learning to use phpmyadmin to grab the db dump – the easier wp is to use, the higher the adoption rate. And I apply the same logic to etiquette in the forms (tis why I’ve been a stickler I guess about “politeness” as of late – even if in the process I’ve ended up being a jerk too) wp is a great tool and I hate to see people driven away by a persons need to answer a question less nicely. I just don’t understand the need – although, I don’t spend all day every day around here… I have today to try and get a feel for what it’s like.

as for you being a bitch vkaryl… I don’t think ya are ?? [of course, I don’t know you and I certainly won’t cross you] ??

First off, let me address something in this announcement:

You must have administrator rights in the wordpress blog to exploit this vulnerability.

Administrator users are expected to be trusted users. I mean, this goes back to the whole security “exploit” where admins of a blog could post malicious Javascript into a post. :rolleyes:

But then again, this does go a bit farther than that…

I honestly don’t know whether WordPress allows execution of the plugin when accessed directly, even if the plugin has been disabled.

Well, I don’t believe WordPress can stop that.

But regardless, functions like get_settings() and such usually break plugins when called directly because they are defined in WordPress. But it’s still a good idea to check permissions in plugins. ??

I know, skippy. I made my distress about Matt’s “position” known when it happened. What occurred is NOT YOUR FAULT. I guess those who have some major server difficulties with the obtaining situation should be pointed to Matt as far as blame, though I doubt he’ll accept responsibility or offer redress. In this world, in this ‘net culture, there IS NO EXCUSE for the way Matt allowed this to enter the script.

[Oh, “someone” doesn’t like my attitude? Hey, FIRE ME. Oh wait. I’m an unpaid volunteer….]

Vipe ol’ buddy…. those admin rights are just not very “safe” these days….

splanters – yeah, I AM a bitch – and an old one at that. I just try to keep it to a dull roar around here any more.