So... not a wordpress vulnerability but a plugin vulnerability. That's like saying "Massive Windows vulnerability!" in the Logitech USB speaker software!
New WordPress vuln emerges
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 …
-
This post has been deleted by its author
-
Friday 28th December 2012 00:36 GMT Anonymous Coward
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.
-
-
-
Friday 28th December 2012 08:23 GMT Anonymous Coward
So...
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!
-
-
Friday 28th December 2012 15:24 GMT Anonymous Coward
Nonsense
"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?
-
Saturday 29th December 2012 08:23 GMT ftownes
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.