Re: CVE Request: W3 Total Cache - public cache exposure

["Jason A. Donenfeld" <Jason () zx2c4 com>]

On Sat, Dec 29, 2012 at 6:35 AM, Kurt Seifried <kseifried () redhat com> wrote:
> As I understand it this is more of an .htaccess type issue than an
> actual issue with W3 total cache? Is this documented anywhere in the
> W3 total cache documents?

W3 generates .htaccess files and sets up the directory structure and
accesses. Nowhere is it documented that sysadmins should additionally
modify the .htaccess files to protect the cache, and W3's own htaccess
generation fails to protect it.


> > 2. Hash keys are easily predictable, in the case of (1) not
> > existing.
>
> explanation/algorithm/?

Sure:

        query_md5=md5("SELECT * FROM ${db_prefix}users WHERE ID =
'${user_id}'")
        key=md5("w3tc_${host}_${site_id}_sql_${query_md5}")
        url="
http://siteblabla/wp-content/w3tc/${key:0:1}/${key:1:1}/${key:2:1}/${key}";

"db_prefix" is by default "wp_", per wordpress config, and few people go in
and change that. "user_id" is an integer. IDs start at 1 and increase for
each added user. "site_id" is an integer that also starts at 1 and
increases for each site used in multi-site wordpress. "host" is the
hostname of the site. All of these values are known or guessable.



> > 3. Cached database values are downloadable by their hash keys on
> > the public internet, exposing sensitive information like password
> > hashes.
>
> Do they need to be downloadable? That is to say can these hash values
> be protected, or must they be exposed?

They _must_ be protected. They _must not_ be exposed or downloadable. The
hash values are raw SQL query responses, so they contain things like
password hashes. The cache is used only internally by the web application,
and client browsers should never have any direct contact with this cache.