W3 Total Cache critical Vulnerability disclosed

The author is aware of the issue and is working on a fix.

At a quick glance, however, this only affects users who use the “Database Cache” option with the “Disk: Basic” or “Disk: Enhanced” modes of caching. It won’t affect all users of the plugin, and is a rather minor issue at that.

Disclosure of the password hashes is not a highly critical issue, because the passwords are salted and ran through multiple iterations of the PHPass system. They are very difficult to crack if you use strong passwords and not dictionary words.

Thanks for your information. That’s mean its not a critical issue.

It’s an important issue, certainly, and if you use the plugin it is worth checking your settings to make sure you have it configured properly.

Can someone specify what the correct settings for “Database Cache” should be in order to avoid the exploit?

ithacaindy: Essentially, don’t use the “Disk: Basic” or “Disk: Enhanced” settings for the cache. Or, if you do, then make sure you have Directory Indexing disabled on the site, which is generally a good idea anyway.

To disable directory indexing on a site, add Options -Indexes as the first line in the site’s .htaccess file.

IMO, the database cache isn’t particularly effective in most cases anyway, and you probably should not have it enabled. The Object Caching mode will likely be more effective. Although this depends on your specific server configuration, among other things.

Otto: I updated my .htaccess to prevent directory indexing. Since I’m on a shared host, I need the database cache; disabling it brought things to a crawl. It would be nice if Object Caching were available for shared hosting accounts.

@ithacaindy & anyone else who needs to use DB caching – then you can create a deny all .htaccess file and upload it to your /w3tc/dbcache folder.

To create a deny all .htaccess file:
1. Open Notepad (not Word or WordPad)
2. Add these 2 lines of code.
order deny,allow
deny from all
3. Save the file with this name: denyall.htaccess.
4. Upload it to your /wp-content/w3tc/dbcache folder
5. Rename the denyall.htaccess file to just .htaccess.

And just an FYI – if you are using secure passwords then you have nothing to worry about since one-way hashed passwords cannot be cracked. If you are using a non-secure password then they can be easily cracked and a hacker would just use a tool like BackTrack R3 and not even bother with the extra effort required to download a W3TC dbcache file and crack it.

Note: downloading the hashed password does have one benefit – it allows unlimited attempts at cracking the hashed password, but if it is a secure password then the end result will be the same – the password will not be crackable.

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 www.ads-software.com. 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 www.ads-software.com 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.

Frederick Townes, 0.9.2.5 version was released, but my question is:

0.9.2.5 version include enhancements and corrections contained on previous development 0.9.2.5b (2011-08-31) versions?

??

No.

Is planned development 0.9.2.6b version with enhancements and corrections contained on previous development 0.9.2.5b (2011-08-31) versions, or enhancements and corrections contained on previous development 0.9.2.5b (2011-08-31) versions are deprecated and discarded on future release?

Ongoing development will move to 0.9.2.6b.

Apparently along with the changes on how the database queries are caching to disk, @frederick also made changes on how the pages are caching to disk.

That certainly made some problems with the page caching and probably the cron job, at least in some environments. So this is what is happening:

1. When caching pages to disc (basic), W3TC fails to even serve the cached pages. Time-stamps change on every single visit. The pages are created on disc, but not served.

2. When caching pages to disc (enhanced), W3TC fails to collect the garbage and refresh the pages at specified intervals. Time-stamps remain the same long after the collect garbage interval have passed. After some testing I’m assuming that what is happening is that W3TC is taking into account the caching intervals from the database caching, page caching, and browser html caching cumulatively.

When setting page cache (enhanced) to expire let say at 300, the cache will be gone at 600-700, depending on what I have set for the database and browser caching.

0.9.2.5 versione release is only simply security fix: all problems discovered on 0.9.2.4 version is the same and unfixed … Nothing, for now, was fixed!

??

Hello,
there is a new critical vulnerability affecting object cache.
I disabled this feature because some attacker executed malicious code through this component. Do you have some suggestion ? I also noticed that if I use some security plugins suggestion in folder permissions, W3 Total Cache doesn’t work as expected. For example also if my .htaccess contains all page cache directives, with 604 permission I got this error: It appears Page Cache URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration.
Any help is appreciated !
Best Regards
Gian Paolo