Re: Commitfest 2021-11 Patch Triage - Part 2

On 11/10/21 00:21, Bruce Momjian wrote:
> On Tue, Nov 9, 2021 at 12:43:20PM -0500, Stephen Frost wrote:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>> I'm not Robert, but I still have an opinion here, and that it's that this
>>> feature would at best be an attractive nuisance. If you need compression
>>> on a database session, it probably means that the connection is over the
>>> open internet, which means that you need encryption even more. And we
>>> know that compression and encryption do not play well together. The
>>> reason compression was taken out of the latest TLS standards is not that
>>> they wouldn't have liked to have it, nor that applying compression in a
>>> separate code layer would be any safer. I fear offering this would
>>> merely lead people to build CVE-worthy setups.
>>
>> I've got an opinion on this also and I don't agree that needing
>> compression means you're on the open internet or that we shouldn't allow
>> users the choice to decide if they want to use compression and
>> encryption together or not. Yes, there's potential risks there, but I
>> don't think those risks would lead to CVEs against PG for supporting a
>> mode where we allow compression and then also allow encryption- if
>> that's a problem then it's an issue for the encryption library/method
>> being used and isn't the fault of us for allowing that combination.
>
> Yeah, I am leaning this diretion too. On the one hand, the number of
> ways to exploit compression-then-encryption seem to continue to grow,
> but it is the complex behavior of HTTPS and connecting to multiple sites
> which seems to always be required, and we don't do that with the
> Postgres client/server protocol.
>

+0.5

I don't think the number of attacks grows all that much, actually. Or
more precisely, the new vulnerabilities are just variations on the CRIME
pattern adopting it to different contexts.

For example Voracle [1] applies to openvpn connections, but in principle
it's the same scenario - observing changes to the compressed size, after
tweaking the requests.

[1] https://community.openvpn.net/openvpn/wiki/VORACLE

So it's true compression is a side-channel, but these attacks require
other ingredients too - ability to MITM the connection, and ability to
inject custom data.

Doing MITM is probably harder than when attacking HTTPS, because DB
connections tend to be between app server and db server - so setting up
a rogue AP does not really work. Sometimes people / DBAs may connect to
the DB directly, although in a way that makes it hard to do modify the
data (which is why psql/ssh are immune to this). But it's possible.

But how hard is injecting custom data in a way that'd make CRIME-like
issue possible? Yes, you could hijack webapp similarly to CRIME, in a
way that initiates database requests with custom data. But we don't
generally send both the supplied and actual password to the DB to do the
check there - we just send one of them, and check it against the value
stored in the DB.

The one (somewhat) plausible scenario I can think of is an application doing

UPDATE t SET field = user_data WHERE id = 1;
SELECT field FROM t WHERE ...;

in which case we might learn if some other row in the result contains
the same value. Not sure how practical this could be, though.

AFAIK OpenVPN still supports tunnel compression, but it's disabled by
default. That probably says something about what they think about the
feature, although that might be due to having compression and not
wanting to just remove it.

One interesting idea OpenVPN allows is asymmetric compression, i.e.
allowing compression in just one direction. For example it might be
possible for the client to send compressed data, but the server would
never send compressed. Or vice versa. That might still help with e.g.
large imports or exports, depending on the use case, while maybe
mitigating some issues. But it's clearly not a solid defense.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company