Re: libpq compression

On 12.02.2019 17:05, Andreas Karlsson wrote:
> 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 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.
>
> 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.
>
> Andreas
>

Attached please find updated version of the patch with more comments  
and warning about possible vulnerabilities of using compression in 
documentation.


-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company