</para>
<para>
- However, if you are upgrading from a version earlier than 9.2.20,
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+ </para>
+
+ <para>
+ Also, if you are upgrading from a version earlier than 9.2.20,
see <xref linkend="release-9-2-20">.
</para>
<itemizedlist>
+ <listitem>
+ <para>
+ Restrict visibility
+ of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+ </para>
+
+ <para>
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server <literal>USAGE</> permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ <structname>information_schema.user_mapping_options</>, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for <literal>PUBLIC</literal> and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+ </para>
+
+ <para>
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+ </para>
+
+ <procedure>
+ <step>
+ <para>
+ Restart the postmaster after adding <literal>allow_system_table_mods
+ = true</> to <filename>postgresql.conf</>. (In versions
+ supporting <command>ALTER SYSTEM</>, you can use that to make the
+ configuration change, but you'll still need a restart.)
+ </para>
+ </step>
+
+ <step>
+ <para>
+ In <emphasis>each</> database of the cluster,
+ run the following commands as superuser:
+<programlisting>
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Do not forget to include the <literal>template0</>
+ and <literal>template1</> databases, or the vulnerability will still
+ exist in databases you create later. To fix <literal>template0</>,
+ you'll need to temporarily make it accept connections.
+ In <productname>PostgreSQL</> 9.5 and later, you can use
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+</programlisting>
+ and then after fixing <literal>template0</>, undo that with
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+</programlisting>
+ In prior versions, instead use
+<programlisting>
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Finally, remove the <literal>allow_system_table_mods</> configuration
+ setting, and again restart the postmaster.
+ </para>
+ </step>
+ </procedure>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+ </para>
+
+ <para>
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from <structname>pg_statistic</>, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix possible corruption of <quote>init forks</> of unlogged indexes
</para>
<para>
- However, if you are upgrading from a version earlier than 9.3.16,
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+ </para>
+
+ <para>
+ Also, if you are upgrading from a version earlier than 9.3.16,
see <xref linkend="release-9-3-16">.
</para>
<itemizedlist>
+ <listitem>
+ <para>
+ Restrict visibility
+ of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+ </para>
+
+ <para>
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server <literal>USAGE</> permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ <structname>information_schema.user_mapping_options</>, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for <literal>PUBLIC</literal> and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+ </para>
+
+ <para>
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+ </para>
+
+ <procedure>
+ <step>
+ <para>
+ Restart the postmaster after adding <literal>allow_system_table_mods
+ = true</> to <filename>postgresql.conf</>. (In versions
+ supporting <command>ALTER SYSTEM</>, you can use that to make the
+ configuration change, but you'll still need a restart.)
+ </para>
+ </step>
+
+ <step>
+ <para>
+ In <emphasis>each</> database of the cluster,
+ run the following commands as superuser:
+<programlisting>
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Do not forget to include the <literal>template0</>
+ and <literal>template1</> databases, or the vulnerability will still
+ exist in databases you create later. To fix <literal>template0</>,
+ you'll need to temporarily make it accept connections.
+ In <productname>PostgreSQL</> 9.5 and later, you can use
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+</programlisting>
+ and then after fixing <literal>template0</>, undo that with
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+</programlisting>
+ In prior versions, instead use
+<programlisting>
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Finally, remove the <literal>allow_system_table_mods</> configuration
+ setting, and again restart the postmaster.
+ </para>
+ </step>
+ </procedure>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+ </para>
+
+ <para>
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from <structname>pg_statistic</>, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Restore <application>libpq</>'s recognition of
+ the <envar>PGREQUIRESSL</> environment variable (Daniel Gustafsson)
+ </para>
+
+ <para>
+ Processing of this environment variable was unintentionally dropped
+ in <productname>PostgreSQL</> 9.3, but its documentation remained.
+ This creates a security hazard, since users might be relying on the
+ environment variable to force SSL-encrypted connections, but that
+ would no longer be guaranteed. Restore handling of the variable,
+ but give it lower priority than <envar>PGSSLMODE</>, to avoid
+ breaking configurations that work correctly with post-9.3 code.
+ (CVE-2017-7485)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix possible corruption of <quote>init forks</> of unlogged indexes
</para>
<para>
- However, if you are using third-party replication tools that depend
- on <quote>logical decoding</>, see the first changelog entry below.
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+ </para>
+
+ <para>
+ Also, if you are using third-party replication tools that depend
+ on <quote>logical decoding</>, see the fourth changelog entry below.
</para>
<para>
<itemizedlist>
+ <listitem>
+ <para>
+ Restrict visibility
+ of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+ </para>
+
+ <para>
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server <literal>USAGE</> permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ <structname>information_schema.user_mapping_options</>, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for <literal>PUBLIC</literal> and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+ </para>
+
+ <para>
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+ </para>
+
+ <procedure>
+ <step>
+ <para>
+ Restart the postmaster after adding <literal>allow_system_table_mods
+ = true</> to <filename>postgresql.conf</>. (In versions
+ supporting <command>ALTER SYSTEM</>, you can use that to make the
+ configuration change, but you'll still need a restart.)
+ </para>
+ </step>
+
+ <step>
+ <para>
+ In <emphasis>each</> database of the cluster,
+ run the following commands as superuser:
+<programlisting>
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Do not forget to include the <literal>template0</>
+ and <literal>template1</> databases, or the vulnerability will still
+ exist in databases you create later. To fix <literal>template0</>,
+ you'll need to temporarily make it accept connections.
+ In <productname>PostgreSQL</> 9.5 and later, you can use
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+</programlisting>
+ and then after fixing <literal>template0</>, undo that with
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+</programlisting>
+ In prior versions, instead use
+<programlisting>
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Finally, remove the <literal>allow_system_table_mods</> configuration
+ setting, and again restart the postmaster.
+ </para>
+ </step>
+ </procedure>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+ </para>
+
+ <para>
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from <structname>pg_statistic</>, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Restore <application>libpq</>'s recognition of
+ the <envar>PGREQUIRESSL</> environment variable (Daniel Gustafsson)
+ </para>
+
+ <para>
+ Processing of this environment variable was unintentionally dropped
+ in <productname>PostgreSQL</> 9.3, but its documentation remained.
+ This creates a security hazard, since users might be relying on the
+ environment variable to force SSL-encrypted connections, but that
+ would no longer be guaranteed. Restore handling of the variable,
+ but give it lower priority than <envar>PGSSLMODE</>, to avoid
+ breaking configurations that work correctly with post-9.3 code.
+ (CVE-2017-7485)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix possibly-invalid initial snapshot during logical decoding
</para>
<para>
- However, if you are using third-party replication tools that depend
- on <quote>logical decoding</>, see the first changelog entry below.
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+ </para>
+
+ <para>
+ Also, if you are using third-party replication tools that depend
+ on <quote>logical decoding</>, see the fourth changelog entry below.
</para>
<para>
<itemizedlist>
+ <listitem>
+ <para>
+ Restrict visibility
+ of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+ </para>
+
+ <para>
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server <literal>USAGE</> permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ <structname>information_schema.user_mapping_options</>, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for <literal>PUBLIC</literal> and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+ </para>
+
+ <para>
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+ </para>
+
+ <procedure>
+ <step>
+ <para>
+ Restart the postmaster after adding <literal>allow_system_table_mods
+ = true</> to <filename>postgresql.conf</>. (In versions
+ supporting <command>ALTER SYSTEM</>, you can use that to make the
+ configuration change, but you'll still need a restart.)
+ </para>
+ </step>
+
+ <step>
+ <para>
+ In <emphasis>each</> database of the cluster,
+ run the following commands as superuser:
+<programlisting>
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Do not forget to include the <literal>template0</>
+ and <literal>template1</> databases, or the vulnerability will still
+ exist in databases you create later. To fix <literal>template0</>,
+ you'll need to temporarily make it accept connections.
+ In <productname>PostgreSQL</> 9.5 and later, you can use
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+</programlisting>
+ and then after fixing <literal>template0</>, undo that with
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+</programlisting>
+ In prior versions, instead use
+<programlisting>
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Finally, remove the <literal>allow_system_table_mods</> configuration
+ setting, and again restart the postmaster.
+ </para>
+ </step>
+ </procedure>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+ </para>
+
+ <para>
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from <structname>pg_statistic</>, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Restore <application>libpq</>'s recognition of
+ the <envar>PGREQUIRESSL</> environment variable (Daniel Gustafsson)
+ </para>
+
+ <para>
+ Processing of this environment variable was unintentionally dropped
+ in <productname>PostgreSQL</> 9.3, but its documentation remained.
+ This creates a security hazard, since users might be relying on the
+ environment variable to force SSL-encrypted connections, but that
+ would no longer be guaranteed. Restore handling of the variable,
+ but give it lower priority than <envar>PGSSLMODE</>, to avoid
+ breaking configurations that work correctly with post-9.3 code.
+ (CVE-2017-7485)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix possibly-invalid initial snapshot during logical decoding
</para>
<para>
- However, if you are using third-party replication tools that depend
- on <quote>logical decoding</>, see the first changelog entry below.
+ However, if you use foreign data servers that make use of user
+ passwords for authentication, see the first changelog entry below.
+ </para>
+
+ <para>
+ Also, if you are using third-party replication tools that depend
+ on <quote>logical decoding</>, see the fourth changelog entry below.
</para>
<para>
<listitem>
<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [3eefc5105] 2017-05-08 07:24:24 -0700
+Branch: REL9_6_STABLE [c928addfc] 2017-05-08 07:24:27 -0700
+Branch: REL9_5_STABLE [db2158108] 2017-05-08 07:24:27 -0700
+Branch: REL9_4_STABLE [b2423f0fa] 2017-05-08 07:24:27 -0700
+Branch: REL9_3_STABLE [b5b124046] 2017-05-08 07:24:28 -0700
+Branch: REL9_2_STABLE [99cbb0bd9] 2017-05-08 07:24:28 -0700
+-->
+ <para>
+ Restrict visibility
+ of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
+ protect passwords stored as user mapping options
+ (Michael Paquier, Feike Steenbergen)
+ </para>
+
+ <para>
+ The previous coding allowed the owner of a foreign server object,
+ or anyone he has granted server <literal>USAGE</> permission to,
+ to see the options for all user mappings associated with that server.
+ This might well include passwords for other users.
+ Adjust the view definition to match the behavior of
+ <structname>information_schema.user_mapping_options</>, namely that
+ these options are visible to the user being mapped, or if the mapping
+ is for <literal>PUBLIC</literal> and the current user is the server
+ owner, or if the current user is a superuser.
+ (CVE-2017-7486)
+ </para>
+
+ <para>
+ By itself, this patch will only fix the behavior in newly initdb'd
+ databases. If you wish to apply this change in an existing database,
+ you will need to do the following:
+ </para>
+
+ <procedure>
+ <step>
+ <para>
+ Restart the postmaster after adding <literal>allow_system_table_mods
+ = true</> to <filename>postgresql.conf</>. (In versions
+ supporting <command>ALTER SYSTEM</>, you can use that to make the
+ configuration change, but you'll still need a restart.)
+ </para>
+ </step>
+
+ <step>
+ <para>
+ In <emphasis>each</> database of the cluster,
+ run the following commands as superuser:
+<programlisting>
+SET search_path = pg_catalog;
+CREATE OR REPLACE VIEW pg_user_mappings AS
+ SELECT
+ U.oid AS umid,
+ S.oid AS srvid,
+ S.srvname AS srvname,
+ U.umuser AS umuser,
+ CASE WHEN U.umuser = 0 THEN
+ 'public'
+ ELSE
+ A.rolname
+ END AS usename,
+ CASE WHEN (U.umuser <> 0 AND A.rolname = current_user)
+ OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
+ OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
+ THEN U.umoptions
+ ELSE NULL END AS umoptions
+ FROM pg_user_mapping U
+ LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
+ pg_foreign_server S ON (U.umserver = S.oid);
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Do not forget to include the <literal>template0</>
+ and <literal>template1</> databases, or the vulnerability will still
+ exist in databases you create later. To fix <literal>template0</>,
+ you'll need to temporarily make it accept connections.
+ In <productname>PostgreSQL</> 9.5 and later, you can use
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
+</programlisting>
+ and then after fixing <literal>template0</>, undo that with
+<programlisting>
+ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
+</programlisting>
+ In prior versions, instead use
+<programlisting>
+UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
+UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
+</programlisting>
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Finally, remove the <literal>allow_system_table_mods</> configuration
+ setting, and again restart the postmaster.
+ </para>
+ </step>
+ </procedure>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Peter Eisentraut <peter_e@gmx.net>
+Branch: master [e2d4ef8de] 2017-05-08 09:26:32 -0400
+Branch: REL9_6_STABLE [c33c42362] 2017-05-08 09:18:57 -0400
+Branch: REL9_5_STABLE [d45cd7c0e] 2017-05-08 09:19:07 -0400
+Branch: REL9_4_STABLE [3e5ea1f9b] 2017-05-08 09:19:15 -0400
+Branch: REL9_3_STABLE [4f1b2089a] 2017-05-08 09:19:23 -0400
+Branch: REL9_2_STABLE [d035c1b97] 2017-05-08 09:19:42 -0400
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [b6576e591] 2017-05-08 11:18:40 -0400
+Branch: REL9_6_STABLE [cad159432] 2017-05-08 11:18:54 -0400
+Branch: REL9_5_STABLE [a199582ef] 2017-05-08 11:19:00 -0400
+Branch: REL9_4_STABLE [d3f3f9568] 2017-05-08 11:19:04 -0400
+Branch: REL9_3_STABLE [703da1795] 2017-05-08 11:19:08 -0400
+-->
+ <para>
+ Prevent exposure of statistical information via leaky operators
+ (Peter Eisentraut)
+ </para>
+
+ <para>
+ Some selectivity estimation functions in the planner will apply
+ user-defined operators to values obtained
+ from <structname>pg_statistic</>, such as most common values and
+ histogram entries. This occurs before table permissions are checked,
+ so a nefarious user could exploit the behavior to obtain these values
+ for table columns he does not have permission to read. To fix,
+ fall back to a default estimate if the operator's implementation
+ function is not certified leak-proof and the calling user does not have
+ permission to read the table column whose statistics are needed.
+ At least one of these criteria is satisfied in most cases in practice.
+ (CVE-2017-7484)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [0170b10df] 2017-05-08 07:24:24 -0700
+Branch: REL9_6_STABLE [aafbd1df9] 2017-05-08 07:24:27 -0700
+Branch: REL9_5_STABLE [96d745492] 2017-05-08 07:24:27 -0700
+Branch: REL9_4_STABLE [ed36c1fe1] 2017-05-08 07:24:27 -0700
+Branch: REL9_3_STABLE [3eab81127] 2017-05-08 07:24:28 -0700
+-->
+ <para>
+ Restore <application>libpq</>'s recognition of
+ the <envar>PGREQUIRESSL</> environment variable (Daniel Gustafsson)
+ </para>
+
+ <para>
+ Processing of this environment variable was unintentionally dropped
+ in <productname>PostgreSQL</> 9.3, but its documentation remained.
+ This creates a security hazard, since users might be relying on the
+ environment variable to force SSL-encrypted connections, but that
+ would no longer be guaranteed. Restore handling of the variable,
+ but give it lower priority than <envar>PGSSLMODE</>, to avoid
+ breaking configurations that work correctly with post-9.3 code.
+ (CVE-2017-7485)
+ </para>
+ </listitem>
+
+ <listitem>
+<!--
Author: Andres Freund <andres@anarazel.de>
Branch: master [2bef06d51] 2017-04-27 13:13:36 -0700
Branch: REL9_6_STABLE [28afff347] 2017-04-27 13:13:36 -0700
projects / postgresql / commitdiff