On Wed, Apr 6, 2022 at 10:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > One last thought: I don't think it's right to suppose that every
> > security vulnerability is the result of some design flaw and every
> > security vulnerability must be patched.
>
> As far as Postgres is concerned, I'm kind of unimpressed by timing-based
> attacks. There are enough layers between a hypothetical attacker and a
> particular algorithm in the backend that it'd be really hard to get any
> reliable numbers. Length-based attacks are more realistic, since e.g.
> we allow you to find out the compressed size of a data value. But as
> you noted, those can be defeated by not storing sensitive data in the
> same place as attacker-controlled data. Or turning off compression,
> but that's largely throwing the baby out with the bathwater. In the
> end I think it's up to the DBA how concerned to be about this and
> what measures she should take to mitigate any risks.
I think that the paper shows that, under the right set of
circumstances, a timing-based attack is possible here. How frequently
those circumstances will arise is debatable, but I don't find it hard
to believe that there are production PostgreSQL clusters out there
against which such an attack could be mounted. I think you're right
when you say that length-based attacks might be practical, and perhaps
some of those might have more to do with PostgreSQL than than this
does, since this is really mostly about the properties of compression
algorithms in general rather than PostgreSQL specifically. I also
completely agree that it's really up to the DBA to decide how worried
to be and what to do about it. I think that the fact that compression
doesn't always run at the same speed or produce an output of the same
size is pretty much intrinsic to the idea of a compression algorithm,
and in a wide variety of circumstances that is absolutely fine and
absolutely desirable. When it permits this kind of attack, it's not,
but then don't use compression, or mitigate the problem some other
way.
--
Robert Haas
EDB: http://www.enterprisedb.com
