-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Summary:
========

mod_disk_cache stores all client authentication credentials for cached
objects on disk. This means proxy authentication credentials as well as
in certain RFC2616 defined cases standard authentication credentials.

In case of Basic Authentication *plaintext passwords* are stored on disk.

Affected:
=========

Apache 2.0.48, 2.0.49 and probably lots of earlier 2.0.x versions, if
mod_disk_cache is used.

This affects especially sites which use Apache 2.0.x as a proxy with
proxy authentication and that have a disk cache configured.

Vendor Status:
==============

The Apache team was notified via security@apache.org on March 2nd and
3rd, 2004. There was some communication and I did supply a patch to fix
the proxy authentication caching problem on March 7th. The fix, however,
is not included in Apache 2.0.49.

Actually I did plan to release this information on April 3rd, but as the
Apache 2.0.49 release is out without a fix and as I wasn't contacted by
the Apache team since March 7th I do assume that the problem is not
going to be corrected. So I decided to release this information today.

Details:
========

~From modules/experimental/mod_disk_cache.c, function write_headers(),
line 641 of apache 2.0.48 or line 598 of apache 2.0.49 (lines wrapped
and shortened):

========================================================================
/* Parse the vary header and dump those fields from the headers_in. */
/* Make call to the same thing cache_select_url calls to crack Vary. */
/* @@@ Some day, not today. */
if (r->headers_in) {
~    int i;
~    apr_table_entry_t *elts = (apr_table_entry_t *)
~       apr_table_elts(r->headers_in)->elts;
~    for (i = 0; i < apr_table_elts(r->headers_in)->nelts; ++i) {
~        if (elts[i].key != NULL) {
~            buf = apr_pstrcat(r->pool, elts[i].key, ": ",  elts[i].val,
~                  CRLF, NULL);
~            amt = strlen(buf);
~            apr_file_write(hfd, buf, &amt);
~        }
~    }
~    buf = apr_pstrcat(r->pool, CRLF, NULL);
~    amt = strlen(buf);
~    apr_file_write(hfd, buf, &amt);
}
========================================================================

So all r->headers_in headers are written to disk. These headers are the
complete header set as presented by the client which naturally includes
all client authentication credentials.

Note that these stored headers are later used only to handle the VARY
header for content negotiation.

Excerpt from RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1:

========================================================================
13.5.1 End-to-end and Hop-by-hop Headers

~   For the purpose of defining the behavior of caches and non-caching
~   proxies, we divide HTTP headers into two categories:

~      - End-to-end headers, which are  transmitted to the ultimate
~        recipient of a request or response. End-to-end headers in
~        responses MUST be stored as part of a cache entry and MUST be
~        transmitted in any response formed from a cache entry.

~      - Hop-by-hop headers, which are meaningful only for a single
~        transport-level connection, and are not stored by caches or
~        forwarded by proxies.

~   The following HTTP/1.1 headers are hop-by-hop headers:

~      - Connection
~      - Keep-Alive
~      - Proxy-Authenticate
~      - Proxy-Authorization
~      - TE
~      - Trailers
~      - Transfer-Encoding
~      - Upgrade
========================================================================

So the proxy authentication headers cannot be used for content
negotiation. Still they are stored on disk. This clearly violates the
'are not stored by caches' of RFC2616.

It is good security practice never to store authentication credentials
presented by a client on disk. Hopefully the Apache team will adopt this
practice.

I do attach the simple patch that I did send to the Apache team adapted
to Apache 2.0.49 (just offsets to the 2.0.48 version) to fix this
security problem for proxy authentication credentials and make Apache
conform to RFC2616.
Note that there may still be cached standard client authentication
credentials after applying this patch for cases where RFC2616 allows
caching of such objects.
- --
Andreas Steinmetz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAXGqlV/yW5kkAz4MRAi5SAJ48C5Kq8FjaW7Krawzkr62JF1YgsQCghz18
oTye7e5sTYn6gQ6Q64oShQE=
=oktn
-----END PGP SIGNATURE-----