Re: FPW compression leaks information - Mailing list pgsql-hackers

On Tue, Jul 7, 2015 at 10:31 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Heikki Linnakangas (hlinnaka@iki.fi) wrote:
>> 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.
>
> The alternative is to have monitoring tools which are running as
> superuser, which, in my view at least, is far worse.
>
>> >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.
>
> I'm not following.  If we don't want the information to be available to
> everyone then we need to limit it, and right now the only way to do that
> is to restrict it to superuser because we haven't got anything more
> granular.

A user can very easily limit such information by not enabling wal_compression.
No need to restrict the usage of WAL location functions.
Of course, as Michael suggested, we need to make the parameter SUSET
so that only superuser can change the setting, though.

Or you're concerned about the case where a careless user enables
wal_compression unexpectedly even though he or she thinks the risk
very serious? Yes, in this case, non-superuser may be able to exploit
the vulnerability by seeing the WAL position. But there are many cases
where improper setting causes unwanted result. So I'm not sure why
we need to treat wal_compression so special.

Regards,

-- 
Fujii Masao