diff options
| -rw-r--r-- | doc/src/sgml/release-9.2.sgml | 125 | ||||
| -rw-r--r-- | doc/src/sgml/release-9.3.sgml | 143 | ||||
| -rw-r--r-- | doc/src/sgml/release-9.4.sgml | 145 | ||||
| -rw-r--r-- | doc/src/sgml/release-9.5.sgml | 145 | ||||
| -rw-r--r-- | doc/src/sgml/release-9.6.sgml | 177 |
5 files changed, 727 insertions, 8 deletions
diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml index ea86c8a42d0..62be52d0986 100644 --- a/doc/src/sgml/release-9.2.sgml +++ b/doc/src/sgml/release-9.2.sgml @@ -29,7 +29,12 @@ </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> @@ -42,6 +47,124 @@ <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 (Robert Haas, Michael Paquier) </para> diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml index 0bf5648be72..c5a5342afc7 100644 --- a/doc/src/sgml/release-9.3.sgml +++ b/doc/src/sgml/release-9.3.sgml @@ -23,7 +23,12 @@ </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> @@ -36,6 +41,142 @@ <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 (Robert Haas, Michael Paquier) </para> diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml index 5bc6f68fd15..2835776d772 100644 --- a/doc/src/sgml/release-9.4.sgml +++ b/doc/src/sgml/release-9.4.sgml @@ -23,8 +23,13 @@ </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> @@ -40,6 +45,142 @@ <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 (Petr Jelinek, Andres Freund) </para> diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml index b00b1e64ead..6a76463e78f 100644 --- a/doc/src/sgml/release-9.5.sgml +++ b/doc/src/sgml/release-9.5.sgml @@ -23,8 +23,13 @@ </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> @@ -40,6 +45,142 @@ <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 (Petr Jelinek, Andres Freund) </para> diff --git a/doc/src/sgml/release-9.6.sgml b/doc/src/sgml/release-9.6.sgml index 1ec705c71b3..b32826f2106 100644 --- a/doc/src/sgml/release-9.6.sgml +++ b/doc/src/sgml/release-9.6.sgml @@ -23,8 +23,13 @@ </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> @@ -40,6 +45,174 @@ <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 |