Re: libpq compression - Mailing list pgsql-hackers

From Andreas Karlsson
Subject Re: libpq compression
Date
Msg-id 8d210267-a2fa-662f-b167-0e5991d45dd7@proxel.se
Whole thread Raw
In response to Re: libpq compression  (Andres Freund <andres@anarazel.de>)
Responses Re: libpq compression  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Re: libpq compression  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: libpq compression  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
I will preface this with that I am not a security guy and that also do 
not know how the Zstd vompression works, so take any of what I say with 
a grain of salt.

On 2/8/19 8:14 AM, Andres Freund wrote:> I think compression is pretty 
useful, and I'm not convinced that the
> threat model underlying the attacks on SSL really apply to postgres.
I think only because it is usually harder to intercept traffic between 
the application server and the database than between the we bbrowser and 
the web server.

Imagine the following query which uses the session ID from the cookie to 
check if the logged in user has access to a file.

SELECT may_download_file(session_id => $1, path => $2);

When the query with its parameters is compressed the compressed size 
will depend on the similarity between the session ID and the requested 
path (assuming Zstd works similar to DEFLATE), so by tricking the web 
browser into making requests with specifically crafted paths while 
monitoring the traffic between the web server and the database the 
compressed request size can be use to hone in the session ID and steal 
people's login sessions, just like the CRIME attack[1].

So while compression is a very useful feature I am worried that it also 
opens application developers to a new set of security vulnerabilities 
which they previously were protected from when compression was removed 
from SSL.

1. https://en.wikipedia.org/wiki/CRIME

Andreas


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: dsa_allocate() faliure
Next
From: Justin Pryzby
Date:
Subject: Re: dsa_allocate() faliure