Re: libpq compression

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: libpq compression
Дата
Msg-id eb3e3b41-24d1-8898-f71d-2975477b6a83@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: libpq compression  (Andreas Karlsson <andreas@proxel.se>)
Ответы Re: libpq compression  (Andreas Karlsson <andreas@proxel.se>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Arthur Zakirov
Дата:
Сообщение: [PATCH] xlogreader: do not read a file block twice
Следующее
От: Grigory Smolkin
Дата:
Сообщение: Re: [PATCH] xlogreader: do not read a file block twice