Re: disable SSL compression?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Subject: Re: disable SSL compression?
Date: 2018-04-02 18:35:24
Message-ID: 20180402183524.e2g5a5smyjwjjmze@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-04-02 12:46:25 -0400, Tom Lane wrote:
> It seemed like the attack you described wasn't all that dependent on
> whether the data is compressed or not: if you can see the size of the
> server's reply to "select ... where account_number = x", you can pretty
> well tell the difference between 0 and 1 rows, with or without
> compression. So I'm still not very clear on what the threat model is.

Imagine that the attacker has control over *parts* of a query. The
server always sends a query like
SELECT mysecret FROM secrets WHERE ...;
but somehow, and there's definitely sneaky ways, there's a second query
sent alongside.
SELECT '$user-defined-string';

If those are compressed together *and* the attacker can observe the size
of the returned result, the attacker can change $user-defined-string
iteratively and infer knowledge about what the contents of mysecret
are. If $user-defined-string and mysecret are the same you're going to
get a smaller total response packet.

One such injection vector that's commonly changable can just be a
username or such.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2018-04-02 18:40:15 Re: [PATCH] Logical decoding of TRUNCATE
Previous Message Peter Eisentraut 2018-04-02 18:30:50 Re: [PATCH] Logical decoding of TRUNCATE