Cyrus httpd inappropriate Cache-Control header leads to exposition of private data to unauthorized clients (was: Caching related security issue? (Cyrus httpd CalDAV server behind Apache mod_proxy)

Thu Oct 31 19:35:10 EDT 2019

Hello,

it seams that Cyrus httpd does not set the Cache-Control header 
appropriate when serving private data. When operated behind a reverse 
proxy with caching (like for example Apache httpd with mod_proxy), there 
is a possibility that an unauthenticated anonymous client gets access to 
private information. I can reproduce this issue by having one client 
access the caldav URL with BASIC HTTP authentication. After this I use 
another client and request the same caldav URL without providing BASIC 
HTTP credentials. As long as the backend data did not change between the 
requests (304 Not Modified), the second client gets the private data 
without authentication from mod_proxy (which is unaware of the fact that 
this is private data).

Therefore I think it would be required to set the Cache-Control header 
for all httpd responses to "private".

As this is not an uncommon setup - having a reverse proxy doing the SSL 
offloading and URL routing - there might be a lot of hosts affected.

What is the best way to address this issue?

Kind regards
Matthias

Oct 31 23:18:33 mail http[14179]: read_body(flags=0x10, framing=2)
Oct 31 23:18:35 mail http[14167]: read & parse request-line
Oct 31 23:18:35 mail http[14167]: read & parse headers
Oct 31 23:18:35 mail http[14167]: conn flags: 0  upgrade flags: 0  tls 
req: 0
Oct 31 23:18:35 mail http[14167]: write_body(code = -1964266973, 
flags.te = 0, len = 0)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Date: Thu, 31 Oct 2019 
22:18:35 GMT)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Connection: Upgrade)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Upgrade: h2c)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Cache-Control: must-revalidate)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Vary: Accept-Encoding)
Oct 31 23:18:35 mail http[14167]: simple_hdr(ETag: 
"1569656021-1572492600-17592-1569921236-602")
Oct 31 23:18:35 mail http[14167]: simple_hdr(Last-Modified: Thu, 31 Oct 
2019 03:30:00 GMT)
Oct 31 23:18:35 mail http[14167]: [10.0.3.2] as "mpeterma" with 
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, 
like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0"; "GET 
/dav/calendars/user/mpeterma/ HTTP/1.1" 
(if-none-match=W/"1569656021-1572492600-17592-1569921236-602") => 
"HTTP/1.1 304 Not Modified"

On 10/7/19 7:45 AM, Matthias Petermann wrote:
> Hello,
> 
> since Cyrus is able to share calendars, I try to set up a CalDAV server 
> using Cyrus httpd behind an Apache reverse proxy (mod_proxy). During 
> this I made a security-related observation which makes me a bit 
> concerned. It seems to be about caching private data, probably more an 
> issue of my individual setup and not a bug in Cyrus. Anyway – I am a bit 
> clueless and would be happy to discuss this to find a mitigation.
> 
> ...
> 
> Test setup / precondtions:
> 
> - Cyrus 3.0.11 server (imapd, httpd) freshly restarted
> - Apache 2.4 with mod_proxy (ssl vhost, no explicit cache configuration, 
> only mod_socache_shmcb)
> - Browser A with clean cache
> - Browser B with clean cache
> 
> Test steps:
> 
> 1) Request CalDAV URL from Browser A
> 
> - Expected: Browser presents HTTP Auth, delivers content after 
> successful login
> - Observed: Browser presents HTTP Auth, delivers content after 
> successful login
> - Result: PASS
> 
> 2) Request same CalDAV URL from Browser B
> 
> - Expected: Browser presents HTTP Auth
> - Observed: Browser delivers content without presenting HTTP Auth
> - Result: FAIL
> 
> Test observations:
> 
> - The result of step 2) seems to differ depending of which Cyrus httpd 
> process is hit by the request
> - The cache-control header delivered by Cyrus httpd seems to not contain 
> „private“ which seems to allow intermediate caches to cache private data
> 
> ...
> 
> My first configuration of Apache did allow mod_proxy to reuse the 
> backend-connections to Cyrus httpd. After I added disablereuse=On (which 
> causes Apache to close the backend-connection immediately after 
> processing a single request), it seems to mitigate the observed issue. 
> How could this be possible? These two questions could help me to 
> investigate further on my system:
> 
> - When receiving a HTTP Request with an Etag included, when exactly does 
> Cyrus httpd decide whether to request HTTP Authentication? In case the 
> Etag is valid (content unchanged), will it return the 304 without 
> requesting a HTTP Auth?
> 
> - How do the Cyrus httpd workers handle HTTP Auth in general? In case of 
> re-using a worker by a permanent connection from a reverse proxy, does 
> it check Authentication on any request, or only at the very first?
> 
> I am happy about suggestions or pointers to best practises in regards of 
> using Cyrus httpd behind a reverse proxy.
> 
> Kind regards
> Matthias
> 
> 
> 
> 
> ----
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
> 