database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-14 08:21:07 +03:00
Code Activity

Last-minute updates for release notes.

Browse Source 
Security: CVE-2019-10129, CVE-2019-10130
This commit is contained in:
Tom Lane
2019-05-06 12:45:59 -04:00
parent 92880ff8a6
commit 02814c381b
1 changed files with 74 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
doc/src/sgml/release-11.sgml
View File

@ -35,6 +35,54 @@
<listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [1aebfbea8] 2019-05-06 11:38:43 +0100
Branch: REL_11_STABLE [0027ee3c5] 2019-05-06 11:41:22 +0100
Branch: REL_10_STABLE [940802830] 2019-05-06 11:43:09 +0100
Branch: REL9_6_STABLE [085d64d9d] 2019-05-06 11:45:01 +0100
Branch: REL9_5_STABLE [93c36145a] 2019-05-06 11:46:33 +0100
-->
<para>
Prevent row-level security policies from being bypassed via
selectivity estimators (Dean Rasheed)
</para>
<para>
Some of the planner's selectivity estimators apply user-defined
operators to values found in <structname>pg_statistic</structname>
(e.g., most-common values). A leaky operator therefore can disclose
some of the entries in a data column, even if the calling user lacks
permission to read that column. In CVE-2017-7484 we added
restrictions to forestall that, but we failed to consider the
effects of row-level security. A user who has SQL permission to
read a column, but who is forbidden to see certain rows due to RLS
policy, might still learn something about those rows' contents via a
leaky operator. This patch further tightens the rules, allowing
leaky operators to be applied to statistics data only when there is
no relevant RLS policy. (CVE-2019-10130)
</para>
</listitem>
<listitem>
<!--
Author: Michael Paquier <michael@paquier.xyz>
Branch: master [91248608a] 2019-05-06 21:44:24 +0900
Branch: REL_11_STABLE [52635c276] 2019-05-06 21:44:39 +0900
-->
<para>
Avoid access to already-freed memory during partition routing error
reports (Michael Paquier)
</para>
<para>
This mistake could lead to a crash, and in principle it might be
possible to use it to disclose server memory contents.
(CVE-2019-10129)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [c01eb619a] 2019-04-26 17:18:07 -0400
Branch: REL_11_STABLE [02c359eed] 2019-04-26 17:18:07 -0400
@ -592,6 +640,32 @@ Branch: REL_10_STABLE [19ff710aa] 2019-03-07 14:21:52 -0500
<listitem>
<!--
Author: Dean Rasheed <dean.a.rasheed@gmail.com>
Branch: master [a0905056f] 2019-05-06 11:54:32 +0100
Branch: REL_11_STABLE [98dad4cd4] 2019-05-06 11:56:37 +0100
Branch: REL_10_STABLE [ca74e3e0f] 2019-05-06 11:58:32 +0100
Branch: REL9_6_STABLE [71185228c] 2019-05-06 12:00:00 +0100
Branch: REL9_5_STABLE [01256815a] 2019-05-06 12:01:44 +0100
Branch: REL9_4_STABLE [3c0999909] 2019-05-06 12:05:05 +0100
-->
<para>
Check the appropriate user's permissions when enforcing rules about
letting a leaky operator see <structname>pg_statistic</structname>
data (Dean Rasheed)
</para>
<para>
When an underlying table is being accessed via a view, consider the
privileges of the view owner while deciding whether leaky operators
may be applied to the table's statistics data, rather than the
privileges of the user making the query. This makes the planner's
rules about what data is visible match up with the executor's,
avoiding unnecessarily-poor plans.
</para>
</listitem>
<listitem>
<!--
Author: Etsuro Fujita <efujita@postgresql.org>
Branch: master [b5afdde6a] 2019-03-12 16:21:57 +0900
Branch: REL_11_STABLE [fd1eaf920] 2019-03-12 16:32:27 +0900