Re: FPW compression leaks information

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Stephen Frost <sfrost(at)snowman(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FPW compression leaks information
Date: 2015-07-07 13:21:36
Message-ID: 559BD260.8080106@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/07/2015 04:15 PM, Stephen Frost wrote:
> * Fujii Masao (masao(dot)fujii(at)gmail(dot)com) wrote:
>> On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
>> <michael(dot)paquier(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oskari Saarenmaa 2015-07-07 13:23:48 Re: Repeated pg_upgrade buildfarm failures on binturon
Previous Message Stephen Frost 2015-07-07 13:15:08 Re: FPW compression leaks information