[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] FPW compression leaks information
From:       Michael Paquier <michael.paquier () gmail ! com>
Date:       2015-05-30 7:58:57
Message-ID: CAB7nPqSUYztvkdGzFVxN-F-L_JKR=fS20ZV4ySgGCVKcrJBKig () mail ! gmail ! com
[Download RAW message or body]

On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote:
>>>> On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
>>>>> 1) Doc patch to mention that it is possible that compression can give
>>>>> hints to attackers when working on sensible fields that have a
>>>>> non-fixed size.
>>>>
>>>> I think that this patch is enough as the first step.
>>>
>>> I'll get something done for that at least, a big warning below the
>>> description of wal_compression would do it.
>
> So here is a patch for this purpose, with the following text being used:
> +       <warning>
> +        <para>
> +         When enabling <varname>wal_compression</varname>, there is a risk
> +         to leak data similarly to the BREACH and CRIME attacks on SSL where
> +         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>
>
> Comments and reformulations are welcome.

To make things on this thread move on, I just wanted to add that we
should make wal_compression SUSET without waiting if we make this
parameter a reloption or not. As things stand, even if it is a
reloption, any user can enforce its value in a given session.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]