database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-24 10:47:04 +03:00
Code

Last-minute updates for release notes.

Browse Source 
Security: CVE-2017-7546, CVE-2017-7547, CVE-2017-7548
This commit is contained in:
Tom Lane 2017-08-07 11:46:20 -04:00
parent fca17a933b
commit a8b37ebe40
5 changed files with 707 additions and 355 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -29,7 +29,12 @@
</para> </para>
<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">. see <xref linkend="release-9-2-20">.
</para> </para>
@ -40,6 +45,126 @@
<itemizedlist> <itemizedlist>
<listitem>
<para>
Further restrict visibility
of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
protect passwords stored as user mapping options
(Noah Misch)
</para>
<para>
The fix for CVE-2017-7486 was incorrect: it allowed a user
to see the options in her own user mapping, even if she did not
have <literal>USAGE</> permission on the associated foreign server.
Such options might include a password that had been provided by the
server owner rather than the user herself.
Since <structname>information_schema.user_mapping_options</> does not
show the options in such cases, <structname>pg_user_mappings</>
should not either.
(CVE-2017-7547)
</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
AND (pg_has_role(S.srvowner, 'USAGE')
OR has_server_privilege(S.oid, 'USAGE')))
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>
Disallow empty passwords in all password-based authentication methods
(Heikki Linnakangas)
</para>
<para>
<application>libpq</> ignores empty password specifications, and does
not transmit them to the server. So, if a user's password has been
set to the empty string, it's impossible to log in with that password
via <application>psql</> or other <application>libpq</>-based
clients. An administrator might therefore believe that setting the
password to empty is equivalent to disabling password login.
However, with a modified or non-<application>libpq</>-based client,
logging in could be possible, depending on which authentication
method is configured. In particular the most common
method, <literal>md5</>, accepted empty passwords.
Change the server to reject empty passwords in all cases.
(CVE-2017-7546)
</para>
</listitem>
<listitem> <listitem>
<para> <para>
On Windows, retry process creation if we fail to reserve the address On Windows, retry process creation if we fail to reserve the address
@ -410,77 +535,9 @@
<para> <para>
By itself, this patch will only fix the behavior in newly initdb'd 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, databases. If you wish to apply this change in an existing database,
you will need to do the following: follow the corrected procedure shown in the changelog entry for
CVE-2017-7547, in <xref linkend="release-9-2-22">.
</para> </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>
<listitem> <listitem>

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

@ -23,7 +23,12 @@
</para> </para>
<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">. see <xref linkend="release-9-3-16">.
</para> </para>
@ -34,6 +39,126 @@
<itemizedlist> <itemizedlist>
<listitem>
<para>
Further restrict visibility
of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
protect passwords stored as user mapping options
(Noah Misch)
</para>
<para>
The fix for CVE-2017-7486 was incorrect: it allowed a user
to see the options in her own user mapping, even if she did not
have <literal>USAGE</> permission on the associated foreign server.
Such options might include a password that had been provided by the
server owner rather than the user herself.
Since <structname>information_schema.user_mapping_options</> does not
show the options in such cases, <structname>pg_user_mappings</>
should not either.
(CVE-2017-7547)
</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
AND (pg_has_role(S.srvowner, 'USAGE')
OR has_server_privilege(S.oid, 'USAGE')))
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>
Disallow empty passwords in all password-based authentication methods
(Heikki Linnakangas)
</para>
<para>
<application>libpq</> ignores empty password specifications, and does
not transmit them to the server. So, if a user's password has been
set to the empty string, it's impossible to log in with that password
via <application>psql</> or other <application>libpq</>-based
clients. An administrator might therefore believe that setting the
password to empty is equivalent to disabling password login.
However, with a modified or non-<application>libpq</>-based client,
logging in could be possible, depending on which authentication
method is configured. In particular the most common
method, <literal>md5</>, accepted empty passwords.
Change the server to reject empty passwords in all cases.
(CVE-2017-7546)
</para>
</listitem>
<listitem> <listitem>
<para> <para>
Fix concurrent locking of tuple update chains (&Aacute;lvaro Herrera) Fix concurrent locking of tuple update chains (&Aacute;lvaro Herrera)
@ -497,77 +622,9 @@
<para> <para>
By itself, this patch will only fix the behavior in newly initdb'd 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, databases. If you wish to apply this change in an existing database,
you will need to do the following: follow the corrected procedure shown in the changelog entry for
CVE-2017-7547, in <xref linkend="release-9-3-18">.
</para> </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>
<listitem> <listitem>

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

@ -23,7 +23,12 @@
</para> </para>
<para> <para>
However, if you are upgrading from a version earlier than 9.4.12, 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.4.12,
see <xref linkend="release-9-4-12">. see <xref linkend="release-9-4-12">.
</para> </para>
</sect2> </sect2>
@ -33,6 +38,140 @@
<itemizedlist> <itemizedlist>
<listitem>
<para>
Further restrict visibility
of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
protect passwords stored as user mapping options
(Noah Misch)
</para>
<para>
The fix for CVE-2017-7486 was incorrect: it allowed a user
to see the options in her own user mapping, even if she did not
have <literal>USAGE</> permission on the associated foreign server.
Such options might include a password that had been provided by the
server owner rather than the user herself.
Since <structname>information_schema.user_mapping_options</> does not
show the options in such cases, <structname>pg_user_mappings</>
should not either.
(CVE-2017-7547)
</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
AND (pg_has_role(S.srvowner, 'USAGE')
OR has_server_privilege(S.oid, 'USAGE')))
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>
Disallow empty passwords in all password-based authentication methods
(Heikki Linnakangas)
</para>
<para>
<application>libpq</> ignores empty password specifications, and does
not transmit them to the server. So, if a user's password has been
set to the empty string, it's impossible to log in with that password
via <application>psql</> or other <application>libpq</>-based
clients. An administrator might therefore believe that setting the
password to empty is equivalent to disabling password login.
However, with a modified or non-<application>libpq</>-based client,
logging in could be possible, depending on which authentication
method is configured. In particular the most common
method, <literal>md5</>, accepted empty passwords.
Change the server to reject empty passwords in all cases.
(CVE-2017-7546)
</para>
</listitem>
<listitem>
<para>
Make <function>lo_put()</> check for <literal>UPDATE</> privilege on
the target large object (Tom Lane, Michael Paquier)
</para>
<para>
<function>lo_put()</> should surely require the same permissions
as <function>lowrite()</>, but the check was missing, allowing any
user to change the data in a large object.
(CVE-2017-7548)
</para>
</listitem>
<listitem> <listitem>
<para> <para>
Fix concurrent locking of tuple update chains (&Aacute;lvaro Herrera) Fix concurrent locking of tuple update chains (&Aacute;lvaro Herrera)
@ -601,77 +740,9 @@ Branch: REL9_4_STABLE [23a2b818f] 2017-08-05 14:56:40 -0700
<para> <para>
By itself, this patch will only fix the behavior in newly initdb'd 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, databases. If you wish to apply this change in an existing database,
you will need to do the following: follow the corrected procedure shown in the changelog entry for
CVE-2017-7547, in <xref linkend="release-9-4-13">.
</para> </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>
<listitem> <listitem>

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

@ -23,7 +23,12 @@
</para> </para>
<para> <para>
However, if you are upgrading from a version earlier than 9.5.7, 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.5.7,
see <xref linkend="release-9-5-7">. see <xref linkend="release-9-5-7">.
</para> </para>
</sect2> </sect2>
@ -33,6 +38,140 @@
<itemizedlist> <itemizedlist>
<listitem>
<para>
Further restrict visibility
of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
protect passwords stored as user mapping options
(Noah Misch)
</para>
<para>
The fix for CVE-2017-7486 was incorrect: it allowed a user
to see the options in her own user mapping, even if she did not
have <literal>USAGE</> permission on the associated foreign server.
Such options might include a password that had been provided by the
server owner rather than the user herself.
Since <structname>information_schema.user_mapping_options</> does not
show the options in such cases, <structname>pg_user_mappings</>
should not either.
(CVE-2017-7547)
</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
AND (pg_has_role(S.srvowner, 'USAGE')
OR has_server_privilege(S.oid, 'USAGE')))
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>
Disallow empty passwords in all password-based authentication methods
(Heikki Linnakangas)
</para>
<para>
<application>libpq</> ignores empty password specifications, and does
not transmit them to the server. So, if a user's password has been
set to the empty string, it's impossible to log in with that password
via <application>psql</> or other <application>libpq</>-based
clients. An administrator might therefore believe that setting the
password to empty is equivalent to disabling password login.
However, with a modified or non-<application>libpq</>-based client,
logging in could be possible, depending on which authentication
method is configured. In particular the most common
method, <literal>md5</>, accepted empty passwords.
Change the server to reject empty passwords in all cases.
(CVE-2017-7546)
</para>
</listitem>
<listitem>
<para>
Make <function>lo_put()</> check for <literal>UPDATE</> privilege on
the target large object (Tom Lane, Michael Paquier)
</para>
<para>
<function>lo_put()</> should surely require the same permissions
as <function>lowrite()</>, but the check was missing, allowing any
user to change the data in a large object.
(CVE-2017-7548)
</para>
</listitem>
<listitem> <listitem>
<para> <para>
Correct the documentation about the process for upgrading standby Correct the documentation about the process for upgrading standby
@ -635,77 +774,9 @@ Branch: REL9_2_STABLE [1188b9b2c] 2017-08-02 15:07:21 -0400
<para> <para>
By itself, this patch will only fix the behavior in newly initdb'd 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, databases. If you wish to apply this change in an existing database,
you will need to do the following: follow the corrected procedure shown in the changelog entry for
CVE-2017-7547, in <xref linkend="release-9-5-8">.
</para> </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>
<listitem> <listitem>

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

@ -23,7 +23,12 @@
</para> </para>
<para> <para>
However, if you are upgrading from a version earlier than 9.6.3, 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.6.3,
see <xref linkend="release-9-6-3">. see <xref linkend="release-9-6-3">.
</para> </para>
</sect2> </sect2>
@ -35,6 +40,165 @@
<listitem> <listitem>
<!-- <!--
Author: Noah Misch <noah@leadboat.com>
Branch: master [e568e1eee] 2017-08-07 07:09:28 -0700
Branch: REL9_6_STABLE [156099630] 2017-08-07 07:09:31 -0700
Branch: REL9_5_STABLE [36f9f6095] 2017-08-07 07:09:31 -0700
Branch: REL9_4_STABLE [b6e39ca92] 2017-08-07 07:09:31 -0700
Branch: REL9_3_STABLE [5e8e00914] 2017-08-07 07:09:31 -0700
Branch: REL9_2_STABLE [e255e97a2] 2017-08-07 07:09:32 -0700
-->
<para>
Further restrict visibility
of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
protect passwords stored as user mapping options
(Noah Misch)
</para>
<para>
The fix for CVE-2017-7486 was incorrect: it allowed a user
to see the options in her own user mapping, even if she did not
have <literal>USAGE</> permission on the associated foreign server.
Such options might include a password that had been provided by the
server owner rather than the user herself.
Since <structname>information_schema.user_mapping_options</> does not
show the options in such cases, <structname>pg_user_mappings</>
should not either.
(CVE-2017-7547)
</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
AND (pg_has_role(S.srvowner, 'USAGE')
OR has_server_privilege(S.oid, 'USAGE')))
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: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [bf6b9e944] 2017-08-07 17:03:42 +0300
Branch: REL9_6_STABLE [f6fc72cb6] 2017-08-07 17:03:49 +0300
Branch: REL9_5_STABLE [127835ddf] 2017-08-07 17:04:00 +0300
Branch: REL9_4_STABLE [d5d46d99b] 2017-08-07 17:04:07 +0300
Branch: REL9_3_STABLE [b2f833ea7] 2017-08-07 17:04:12 +0300
Branch: REL9_2_STABLE [06651648a] 2017-08-07 17:04:17 +0300
-->
<para>
Disallow empty passwords in all password-based authentication methods
(Heikki Linnakangas)
</para>
<para>
<application>libpq</> ignores empty password specifications, and does
not transmit them to the server. So, if a user's password has been
set to the empty string, it's impossible to log in with that password
via <application>psql</> or other <application>libpq</>-based
clients. An administrator might therefore believe that setting the
password to empty is equivalent to disabling password login.
However, with a modified or non-<application>libpq</>-based client,
logging in could be possible, depending on which authentication
method is configured. In particular the most common
method, <literal>md5</>, accepted empty passwords.
Change the server to reject empty passwords in all cases.
(CVE-2017-7546)
</para>
</listitem>
<listitem>
<!--
Author: Tom Lane <tgl@sss.pgh.pa.us>
Branch: master [8d9881911] 2017-08-07 10:19:19 -0400
Branch: REL9_6_STABLE [52a414387] 2017-08-07 10:19:20 -0400
Branch: REL9_5_STABLE [873741c68] 2017-08-07 10:19:21 -0400
Branch: REL9_4_STABLE [f1cda6d6c] 2017-08-07 10:19:22 -0400
-->
<para>
Make <function>lo_put()</> check for <literal>UPDATE</> privilege on
the target large object (Tom Lane, Michael Paquier)
</para>
<para>
<function>lo_put()</> should surely require the same permissions
as <function>lowrite()</>, but the check was missing, allowing any
user to change the data in a large object.
(CVE-2017-7548)
</para>
</listitem>
<listitem>
<!--
Author: Bruce Momjian <bruce@momjian.us> Author: Bruce Momjian <bruce@momjian.us>
Branch: master [0f33a719f] 2017-06-15 12:30:02 -0400 Branch: master [0f33a719f] 2017-06-15 12:30:02 -0400
Branch: REL9_6_STABLE [a0873fbab] 2017-06-15 12:30:02 -0400 Branch: REL9_6_STABLE [a0873fbab] 2017-06-15 12:30:02 -0400
@ -1193,77 +1357,9 @@ Branch: REL9_2_STABLE [99cbb0bd9] 2017-05-08 07:24:28 -0700
<para> <para>
By itself, this patch will only fix the behavior in newly initdb'd 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, databases. If you wish to apply this change in an existing database,
you will need to do the following: follow the corrected procedure shown in the changelog entry for
CVE-2017-7547, in <xref linkend="release-9-6-4">.
</para> </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>
<listitem> <listitem>