lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <405C6AA5.4030207@domdv.de>
Date: Sat, 20 Mar 2004 17:00:37 +0100
From: Andreas Steinmetz <ast@...dv.de>
To: bugtraq@...urityfocus.com
Subject: Apache mod_disk_cache stores client authentication credentials on
 disk

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

View attachment "httpd-2.0.49-proxy-privacy.patch" of type "text/plain" (2901 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ