Sorry to spoil the day for any sysadmins that thought today would be a slow day, but a security researcher has announced a serious vulnerability in the default configuration of a popular WordPress plugin. W3 Total Cache, which boasts high-traffic sites like Mashable and Lockergnome among its users, has serious vulnerabilities, …
So... not a wordpress vulnerability but a plugin vulnerability. That's like saying "Massive Windows vulnerability!" in the Logitech USB speaker software!
Windows is bad, so is PHP
both Windows and PHP keep breaking stuff! STOP IT!!!!
Re: Windows is bad, so is PHP
Ok Eadon ,we get it. You need to mention Windows in every article, even if in no way is it related (.htaccess is used more Linux boxes than IIS servers, but let's ignore that). But you know what, I reckon your a closet MS lover, bit like those homophobic MP's that turn up in the gutter press with a ball gag in their mouth and a butt plug rammed where the sun don't shine.
Admit, you secretly luurve MS....go on, we won't mock you...feel the love.
MS and Eadon sitting in a tree,,,,,
Re: Windows is bad, so is PHP - Says Luser
Erm, sorry to rain on your parade, but Linux / Open source is MUCH worse: http://www.zone-h.org/news/id/4737
Re: Let off steam.... RANT!
Weird, I don't think I've had a windows driver issue since I last installed NT4 Server / Windows 2000 Pro, I mean I don't think I've seen a single common device that hasn't had at least basic support off of a basic windows install. Then again - I don't install operating systems now days, I have better things to do with my time.
I don't doubt that it happens, but it's been some time since I've heard about it.
Re: Let off steam.... RANT!
Windows: using it is its own punishment.
Well, considering how inefficient WP is under the hood, any blog with any amount of traffic really does actually *need* this plugin, and it is so commonly installed that yes, it is newsworthy in a lot of ways.
Now only if I hadn't already heard this 3 days ago... ;)
That should be the .htaccess file, not .httaccess
I presume that the advice to put "deny from all" in the .htaccess was a little joke, like advising people to fix their Unix system with rm -rf
They probably (hopefully) mean putting "deny from all" into a .htaccess file in the dbcache folder?
Maybe more logical would be:
order deny, allow
deny from all
allow from IP
If you need to permit access to the folder from a specific location, such as maybe the server itself?
It's not a wordpress vulnerability, but a plugin vulnerability - quite a big difference.
If the vulnerability was in the *core* of wordpress, then it would be a ... wordpress vulnerability.
But I guess it doesn't make such a *cough* 'interesting' headline.
And the 'deny from all' in .htaccess (with one t) would be set on the cache folder of the plugin = problem solved, or just change the permissions of the folder!
"And the 'deny from all' in .htaccess (with one t) would be set on the cache folder of the plugin = problem solved"
No so much problem solved in that case, rather problem just hidden from prying eyes. Definitely not 'problem solved'.
i agree 'Matt 89'...no reason why anything other than the webserver should need access to the cache directory anyway.
chmod 700 -R name-of-cache-directory
should do it. i'll prepare for the downvotes...haven't posted on here in a while and i fear the worst...
i'll prepare for the downvotes
I've upvoted you, just to confuse matters :)
BTW, quite a few people don't have command line access to their service, so the .htaccess method is sometimes the only reliable control they have, barring CHMOD features in their FTP client.
have gotten too used to a VPS. couldn't be doing with out shell access...
i'm sure, here, everyone knows how to do it with a client but just in case...
"cache files are by default publicly downloadable, and the key values / file name of the database cache items are easily predictable.
Yeah, its extremely easy to predict, for example, "dbcache/4/0/1/41194874842fc66679f745de0b453110", everyone knows this is where.... Well, I guess I'm stupid ;)
This file dates from today, but so does "dbcache/a/9/c/a9cfb6fa4674e52b4b5f1dd4f52d218d". How is that easily predictable for anyone who hasn't dived into the codebase of w3-totalcache?
For those of you that use W3 Total Cache to make your sites more performant, thank you. Security issues are always of paramount interest, no matter the scope.
The root of the possible vulnerability lies in the intersection of two configuration settings, one at the Web Server level and the other at the W3 Total Cache database caching level. You may be vulnerable if the following are true: your server is configured to allow directory listing with enabled public access on W3TC’s database caching directories and also use database caching via the disk caching method. These settings would allow a hacker to break the md5 hashing used for the then publicly accessible cached database objects. The manner, extent and timing of the vulnerability’s report leave much to be desired; nonetheless, the versions have now been patched on wordpress.org. Thanks to those that offered remediation advice. I’m sorry for the delay in turning this around, none of the proposed solutions were satisfactory.
The hotfix (tested with WordPress version 3.5) will help those who are just now upgrading to 0.9.2.4 or are otherwise getting started with W3 Total Cache. Specifically, the hash logic is improved via wp_hash(), significantly stronger than the previous md5 hashing at the compromise of a bit of speed. I’ve also made sure that a web server’s lack of security around directory listings and the standard file structure of W3TC’s hashing logic are no longer of consequence for those attempting to download them from your server.
For those who are using database caching to disk already, please be sure to disable directory indexing and deny web access to the “wp-content/w3tc/dbcache/” directory in your web configuration, then empty the database cache for good measure. Or, simply deactivate W3 Total Cache, uninstall it, and re-install it via wordpress.org to have the hotfix applied upon re-activation. Again, empty the database cache for good measure. Your settings will not be lost during this process. If all of this is gibberish to you, then simply disable database caching to disk until the next release or use another method if available. Once again, empty the database cache using the button of the same name available on the database caching settings tab.
If you’re reading this and have seen a post about the issue that does not have this response on it, please do post this for me. Thanks in advance. Happy Holidays.
...WP Super Cache is better anyway.