On Wed, Apr 6, 2022 at 10:14 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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
