</para>
<para>
- However, if you are upgrading from a version earlier than 9.3.18,
+ However, if you run an installation in which not all users are mutually
+ trusting, or if you maintain an application or extension that is
+ intended for use in arbitrary situations, it is strongly recommended
+ that you read the documentation changes described in the first changelog
+ entry below, and take suitable steps to ensure that your installation or
+ code is secure.
+ </para>
+
+ <para>
+ Also, the changes described in the second changelog entry below may
+ cause functions used in index expressions or materialized views to fail
+ during auto-analyze, or when reloading from a dump. After upgrading,
+ monitor the server logs for such problems, and fix affected functions.
+ </para>
+
+ <para>
+ Also, if you are upgrading from a version earlier than 9.3.18,
see <xref linkend="release-9-3-18">.
</para>
</sect2>
<itemizedlist>
+ <listitem>
+ <para>
+ Document how to configure installations and applications to guard
+ against search-path-dependent trojan-horse attacks from other users
+ (Noah Misch)
+ </para>
+
+ <para>
+ Using a <varname>search_path</varname> setting that includes any
+ schemas writable by a hostile user enables that user to capture
+ control of queries and then run arbitrary SQL code with the
+ permissions of the attacked user. While it is possible to write
+ queries that are proof against such hijacking, it is notationally
+ tedious, and it's very easy to overlook holes. Therefore, we now
+ recommend configurations in which no untrusted schemas appear in
+ one's search path. Relevant documentation appears in
+ <xref linkend="ddl-schemas-patterns"> (for database administrators and users),
+ <xref linkend="libpq-connect"> (for application authors),
+ <xref linkend="extend-extensions-style"> (for extension authors), and
+ <xref linkend="sql-createfunction"> (for authors
+ of <literal>SECURITY DEFINER</literal> functions).
+ (CVE-2018-1058)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid use of insecure <varname>search_path</varname> settings
+ in <application>pg_dump</application> and other client programs
+ (Noah Misch, Tom Lane)
+ </para>
+
+ <para>
+ <application>pg_dump</application>,
+ <application>pg_upgrade</application>,
+ <application>vacuumdb</application> and
+ other <productname>PostgreSQL</productname>-provided applications were
+ themselves vulnerable to the type of hijacking described in the previous
+ changelog entry; since these applications are commonly run by
+ superusers, they present particularly attractive targets. To make them
+ secure whether or not the installation as a whole has been secured,
+ modify them to include only the <structname>pg_catalog</structname>
+ schema in their <varname>search_path</varname> settings.
+ Autovacuum worker processes now do the same, as well.
+ </para>
+
+ <para>
+ In cases where user-provided functions are indirectly executed by
+ these programs — for example, user-provided functions in index
+ expressions — the tighter <varname>search_path</varname> may
+ result in errors, which will need to be corrected by adjusting those
+ user-provided functions to not assume anything about what search path
+ they are invoked under. That has always been good practice, but now
+ it will be necessary for correct behavior.
+ (CVE-2018-1058)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix misbehavior of concurrent-update rechecks with CTE references
</para>
<para>
- However, if you are upgrading from a version earlier than 9.4.13,
+ However, if you run an installation in which not all users are mutually
+ trusting, or if you maintain an application or extension that is
+ intended for use in arbitrary situations, it is strongly recommended
+ that you read the documentation changes described in the first changelog
+ entry below, and take suitable steps to ensure that your installation or
+ code is secure.
+ </para>
+
+ <para>
+ Also, the changes described in the second changelog entry below may
+ cause functions used in index expressions or materialized views to fail
+ during auto-analyze, or when reloading from a dump. After upgrading,
+ monitor the server logs for such problems, and fix affected functions.
+ </para>
+
+ <para>
+ Also, if you are upgrading from a version earlier than 9.4.13,
see <xref linkend="release-9-4-13">.
</para>
</sect2>
<itemizedlist>
+ <listitem>
+ <para>
+ Document how to configure installations and applications to guard
+ against search-path-dependent trojan-horse attacks from other users
+ (Noah Misch)
+ </para>
+
+ <para>
+ Using a <varname>search_path</varname> setting that includes any
+ schemas writable by a hostile user enables that user to capture
+ control of queries and then run arbitrary SQL code with the
+ permissions of the attacked user. While it is possible to write
+ queries that are proof against such hijacking, it is notationally
+ tedious, and it's very easy to overlook holes. Therefore, we now
+ recommend configurations in which no untrusted schemas appear in
+ one's search path. Relevant documentation appears in
+ <xref linkend="ddl-schemas-patterns"> (for database administrators and users),
+ <xref linkend="libpq-connect"> (for application authors),
+ <xref linkend="extend-extensions-style"> (for extension authors), and
+ <xref linkend="sql-createfunction"> (for authors
+ of <literal>SECURITY DEFINER</literal> functions).
+ (CVE-2018-1058)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid use of insecure <varname>search_path</varname> settings
+ in <application>pg_dump</application> and other client programs
+ (Noah Misch, Tom Lane)
+ </para>
+
+ <para>
+ <application>pg_dump</application>,
+ <application>pg_upgrade</application>,
+ <application>vacuumdb</application> and
+ other <productname>PostgreSQL</productname>-provided applications were
+ themselves vulnerable to the type of hijacking described in the previous
+ changelog entry; since these applications are commonly run by
+ superusers, they present particularly attractive targets. To make them
+ secure whether or not the installation as a whole has been secured,
+ modify them to include only the <structname>pg_catalog</structname>
+ schema in their <varname>search_path</varname> settings.
+ Autovacuum worker processes now do the same, as well.
+ </para>
+
+ <para>
+ In cases where user-provided functions are indirectly executed by
+ these programs — for example, user-provided functions in index
+ expressions — the tighter <varname>search_path</varname> may
+ result in errors, which will need to be corrected by adjusting those
+ user-provided functions to not assume anything about what search path
+ they are invoked under. That has always been good practice, but now
+ it will be necessary for correct behavior.
+ (CVE-2018-1058)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix misbehavior of concurrent-update rechecks with CTE references
</para>
<para>
- However, if you are upgrading from a version earlier than 9.5.10,
+ However, if you run an installation in which not all users are mutually
+ trusting, or if you maintain an application or extension that is
+ intended for use in arbitrary situations, it is strongly recommended
+ that you read the documentation changes described in the first changelog
+ entry below, and take suitable steps to ensure that your installation or
+ code is secure.
+ </para>
+
+ <para>
+ Also, the changes described in the second changelog entry below may
+ cause functions used in index expressions or materialized views to fail
+ during auto-analyze, or when reloading from a dump. After upgrading,
+ monitor the server logs for such problems, and fix affected functions.
+ </para>
+
+ <para>
+ Also, if you are upgrading from a version earlier than 9.5.10,
see <xref linkend="release-9-5-10">.
</para>
</sect2>
<itemizedlist>
+ <listitem>
+ <para>
+ Document how to configure installations and applications to guard
+ against search-path-dependent trojan-horse attacks from other users
+ (Noah Misch)
+ </para>
+
+ <para>
+ Using a <varname>search_path</varname> setting that includes any
+ schemas writable by a hostile user enables that user to capture
+ control of queries and then run arbitrary SQL code with the
+ permissions of the attacked user. While it is possible to write
+ queries that are proof against such hijacking, it is notationally
+ tedious, and it's very easy to overlook holes. Therefore, we now
+ recommend configurations in which no untrusted schemas appear in
+ one's search path. Relevant documentation appears in
+ <xref linkend="ddl-schemas-patterns"> (for database administrators and users),
+ <xref linkend="libpq-connect"> (for application authors),
+ <xref linkend="extend-extensions-style"> (for extension authors), and
+ <xref linkend="sql-createfunction"> (for authors
+ of <literal>SECURITY DEFINER</literal> functions).
+ (CVE-2018-1058)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid use of insecure <varname>search_path</varname> settings
+ in <application>pg_dump</application> and other client programs
+ (Noah Misch, Tom Lane)
+ </para>
+
+ <para>
+ <application>pg_dump</application>,
+ <application>pg_upgrade</application>,
+ <application>vacuumdb</application> and
+ other <productname>PostgreSQL</productname>-provided applications were
+ themselves vulnerable to the type of hijacking described in the previous
+ changelog entry; since these applications are commonly run by
+ superusers, they present particularly attractive targets. To make them
+ secure whether or not the installation as a whole has been secured,
+ modify them to include only the <structname>pg_catalog</structname>
+ schema in their <varname>search_path</varname> settings.
+ Autovacuum worker processes now do the same, as well.
+ </para>
+
+ <para>
+ In cases where user-provided functions are indirectly executed by
+ these programs — for example, user-provided functions in index
+ expressions — the tighter <varname>search_path</varname> may
+ result in errors, which will need to be corrected by adjusting those
+ user-provided functions to not assume anything about what search path
+ they are invoked under. That has always been good practice, but now
+ it will be necessary for correct behavior.
+ (CVE-2018-1058)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix misbehavior of concurrent-update rechecks with CTE references
</para>
<para>
- However, if you are upgrading from a version earlier than 9.6.7,
+ However, if you run an installation in which not all users are mutually
+ trusting, or if you maintain an application or extension that is
+ intended for use in arbitrary situations, it is strongly recommended
+ that you read the documentation changes described in the first changelog
+ entry below, and take suitable steps to ensure that your installation or
+ code is secure.
+ </para>
+
+ <para>
+ Also, the changes described in the second changelog entry below may
+ cause functions used in index expressions or materialized views to fail
+ during auto-analyze, or when reloading from a dump. After upgrading,
+ monitor the server logs for such problems, and fix affected functions.
+ </para>
+
+ <para>
+ Also, if you are upgrading from a version earlier than 9.6.7,
see <xref linkend="release-9-6-7">.
</para>
</sect2>
<itemizedlist>
+ <listitem>
+ <para>
+ Document how to configure installations and applications to guard
+ against search-path-dependent trojan-horse attacks from other users
+ (Noah Misch)
+ </para>
+
+ <para>
+ Using a <varname>search_path</varname> setting that includes any
+ schemas writable by a hostile user enables that user to capture
+ control of queries and then run arbitrary SQL code with the
+ permissions of the attacked user. While it is possible to write
+ queries that are proof against such hijacking, it is notationally
+ tedious, and it's very easy to overlook holes. Therefore, we now
+ recommend configurations in which no untrusted schemas appear in
+ one's search path. Relevant documentation appears in
+ <xref linkend="ddl-schemas-patterns"> (for database administrators and users),
+ <xref linkend="libpq-connect"> (for application authors),
+ <xref linkend="extend-extensions-style"> (for extension authors), and
+ <xref linkend="sql-createfunction"> (for authors
+ of <literal>SECURITY DEFINER</literal> functions).
+ (CVE-2018-1058)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid use of insecure <varname>search_path</varname> settings
+ in <application>pg_dump</application> and other client programs
+ (Noah Misch, Tom Lane)
+ </para>
+
+ <para>
+ <application>pg_dump</application>,
+ <application>pg_upgrade</application>,
+ <application>vacuumdb</application> and
+ other <productname>PostgreSQL</productname>-provided applications were
+ themselves vulnerable to the type of hijacking described in the previous
+ changelog entry; since these applications are commonly run by
+ superusers, they present particularly attractive targets. To make them
+ secure whether or not the installation as a whole has been secured,
+ modify them to include only the <structname>pg_catalog</structname>
+ schema in their <varname>search_path</varname> settings.
+ Autovacuum worker processes now do the same, as well.
+ </para>
+
+ <para>
+ In cases where user-provided functions are indirectly executed by
+ these programs — for example, user-provided functions in index
+ expressions — the tighter <varname>search_path</varname> may
+ result in errors, which will need to be corrected by adjusting those
+ user-provided functions to not assume anything about what search path
+ they are invoked under. That has always been good practice, but now
+ it will be necessary for correct behavior.
+ (CVE-2018-1058)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix misbehavior of concurrent-update rechecks with CTE references
projects / postgresql / commitdiff