On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
> <michael.paqu...@gmail.com> wrote:
>> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
>> <michael.paqu...@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:
Thanks for the patch!
> + <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
Isn't it better to add the link to the corresponding wikipedia page for
the terms BREACH and CRIME?
> + 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?
Regards,
--
Fujii Masao
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***************
*** 2311,2316 **** include_dir 'conf.d'
--- 2311,2339 ----
but at the cost of some extra CPU spent on the compression during
WAL logging and on the decompression during WAL replay.
</para>
+
+ <warning>
+ <para>
+ When enabling <varname>wal_compression</varname>, there is a risk
+ to leak data similarly to the
+ <ulink url="http://en.wikipedia.org/wiki/BREACH_%28security_exploit%29";>
+ BREACH</ulink> and <ulink url="http://en.wikipedia.org/wiki/CRIME";>
+ CRIME</ulink> 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. Such attacks are less likely to
+ occur in practice because an attacker has to be able to insert data
+ on the same page as the data targeted, to detect occurrences of
+ checkpoint, and to calculate the compression ratio of a full page
+ image by accessing to information on WAL position. Also an attacker
+ has to repeat many times the attempts to obtain the hint of data
+ from the compression ratio, which would take a long time.
+ Therefore this vulnerability is practically quite cumbersome to
+ exploit, but it's doable. If this risk of data leakage should be
+ avoided, <varname>wal_compression</varname> needs to be disabled.
+ </para>
+ </warning>
</listitem>
</varlistentry>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
