back to article 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 …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    So... not a wordpress vulnerability but a plugin vulnerability. That's like saying "Massive Windows vulnerability!" in the Logitech USB speaker software!

  2. This post has been deleted by its author

    1. Anonymous Coward
      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.

    2. Big-nosed Pengie

      Re: Let off steam.... RANT!

      Windows: using it is its own punishment.

  3. Pete Spicer

    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... ;)

  4. aidanstevens

    Minor correction

    That should be the .htaccess file, not .httaccess

  5. Charles E
    Alert

    htaccess

    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

    1. Darkwolf

      Re: htaccess

      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?

  6. Anonymous Coward
    Thumb Down

    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!

    1. Anonymous Coward
      Anonymous Coward

      Re: So...

      "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'.

  7. lupine

    permissions

    i agree 'Matt 89'...no reason why anything other than the webserver should need access to the cache directory anyway.

    a wee

    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...

  8. Fred Flintstone Gold badge

    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.

    1. lupine

      very tue

      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...

      http://www.dummies.com/how-to/content/how-to-change-file-permissions-using-filezilla-on-.html

  9. Anonymous Coward
    FAIL

    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?

  10. 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.

  11. Anonymous Coward
    Happy

    No problem...

    ...WP Super Cache is better anyway.

This topic is closed for new posts.

Other stories you might like