Re: libpq compression

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, 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-12 14:05:01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2/11/19 5:28 PM, Peter Eisentraut wrote:
> 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 (via spam), and that site
> automatically runs JavaScript code in the user's browser that contacts
>, which will then automatically send along any secret
> cookies the user had previously saved from The evil
> JavaScript code can then stuff the requests to with arbitrary
> bytes and run the requests in a tight loop, only subject to rate
> controls at

Right, CRIME is worse since it cannot be mitigated by the application
developer. But even so I do not think that my query is that odd. I do
not think that it is obvious to most application developer that putting
user supplied data close to sensitive data is potentially dangerous.

Will this attack ever be useful in practice? No idea, but I think we
should be aware of what risks we open our end users to.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2019-02-12 14:06:11 Re: [PROPOSAL]a new data type 'bytea' for ECPG
Previous Message Ramanarayana 2019-02-12 13:54:20 Re: BUG #15548: Unaccent does not remove combining diacritical characters