On 07/07/2015 04:15 PM, Stephen Frost wrote:
> * Fujii Masao (masao.fujii@gmail.com) wrote:
>> On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> + the compression ratio of a full page image gives a hint of what is
>>> + the existing data of this page. Tables that contain sensitive
>>> + information like <structname>pg_authid</structname> with password
>>> + data could be potential targets to such attacks. Note that as a
>>> + prerequisite a user needs to be able to insert data on the same page
>>> + as the data targeted and need to be able to detect checkpoint
>>> + presence to find out if a compressed full page write is included in
>>> + WAL to calculate the compression ratio of a page using WAL positions
>>> + before and after inserting data on the page with data targeted.
>>> + </para>
>>> + </warning>
>>
>> I think that, in addition to the description of the risk, it's better to
>> say that this vulnerability is cumbersome to exploit in practice.
>>
>> Attached is the updated version of the patch. Comments?
>
> Personally, I don't like simply documenting this issue. I'd much rather
> we restrict the WAL info as it's really got no business being available
> to the general public. I'd be fine with restricting that information to
> superusers when compression is enabled, or always, for 9.5 and then
> fixing it properly in 9.6 by allowing it to be visible to a
> "pg_monitoring" default role which admins can then grant to users who
> should be able to see it.
Well, then you could still launch the same attack if you have the
pg_monitoring privileges. So it would be more like a "monitoring and
grab everyone's passwords" privilege ;-). Ok, in seriousness the attack
isn't that easy to perform, but I still wouldn't feel comfortable giving
that privilege to anyone who isn't a superuser anyway.
> Yes, we'll get flak from people who are running with non-superuser
> monitoring tools today, but we already have a bunch of superuser-only
> things that monioring tools want, so this doesn't move the needle
> particularly far, in my view.
That would be a major drawback IMHO, and a step in the wrong direction.
- Heikki
