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
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 |