Re: libpq compression

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>, Andres Freund <andres(at)anarazel(dot)de>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq compression
Date: 2019-02-11 16:28:40
Message-ID: eb3e3b41-24d1-8898-f71d-2975477b6a83@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/02/2019 00:36, Andreas Karlsson wrote:
>> 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].

One mitigation is to not write code like that, that is, don't put secret
parameters and user-supplied content into the same to-be-compressed
chunk, or at least don't let the end user run that code at will in a
tight loop.

The difference in CRIME is that the attacker supplied the code. You'd
trick the user to go to http://evil.com/ (via spam), and that site
automatically runs JavaScript code in the user's browser that contacts
https://bank.com/, which will then automatically send along any secret
cookies the user had previously saved from bank.com. The evil
JavaScript code can then stuff the requests to bank.com with arbitrary
bytes and run the requests in a tight loop, only subject to rate
controls at bank.com.

The closest equivalent to that in PostgreSQL is leading a user to a fake
server and having them run their \gexec-using psql script against that.
However, the difference is that a web browser would then augment those
outgoing requests with locally stored domain-specific cookie data. psql
doesn't have such functionality.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Grigory Smolkin 2019-02-11 16:32:59 Re: [PATCH] xlogreader: do not read a file block twice
Previous Message Arthur Zakirov 2019-02-11 16:25:39 [PATCH] xlogreader: do not read a file block twice