rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Last-minute updates for release notes. 

Security: CVE-2017-7484, CVE-2017-7485, CVE-2017-7486
This commit is contained in:
Tom Lane 2017-05-08 12:57:27 -04:00
parent 9a591c1bcc
commit c89d2d0204
5 changed files with 727 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

125
doc/src/sgml/release-9.2.sgml
View File

@ -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>
@ -40,6 +45,124 @@
<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 &lt;&gt; 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

143
doc/src/sgml/release-9.3.sgml
View File

@ -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>
@ -34,6 +39,142 @@
<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 &lt;&gt; 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

145
doc/src/sgml/release-9.4.sgml
View File

@ -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>
@ -38,6 +43,142 @@
<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 &lt;&gt; 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

145
doc/src/sgml/release-9.5.sgml
View File

@ -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>
@ -38,6 +43,142 @@
<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 &lt;&gt; 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

177
doc/src/sgml/release-9.6.sgml
View File

@ -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 &lt;&gt; 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