diff --git a/doc/src/sgml/release-8.4.sgml b/doc/src/sgml/release-8.4.sgml
index f6accba6cd7098f3037f5a08fe2fe4b203af5580..c3226d340e72b433eddc389ba45596f2d428c429 100644
--- a/doc/src/sgml/release-8.4.sgml
+++ b/doc/src/sgml/release-8.4.sgml
@@ -40,6 +40,145 @@
<itemizedlist>
+ <listitem>
+ <para>
+ Shore up <literal>GRANT ... WITH ADMIN OPTION</> restrictions
+ (Noah Misch)
+ </para>
+
+ <para>
+ Granting a role without <literal>ADMIN OPTION</> is supposed to
+ prevent the grantee from adding or removing members from the granted
+ role, but this restriction was easily bypassed by doing <literal>SET
+ ROLE</> first. The security impact is mostly that a role member can
+ revoke the access of others, contrary to the wishes of his grantor.
+ Unapproved role member additions are a lesser concern, since an
+ uncooperative role member could provide most of his rights to others
+ anyway by creating views or <literal>SECURITY DEFINER</> functions.
+ (CVE-2014-0060)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent privilege escalation via manual calls to PL validator
+ functions (Andres Freund)
+ </para>
+
+ <para>
+ The primary role of PL validator functions is to be called implicitly
+ during <command>CREATE FUNCTION</>, but they are also normal SQL
+ functions that a user can call explicitly. Calling a validator on
+ a function actually written in some other language was not checked
+ for and could be exploited for privilege-escalation purposes.
+ The fix involves adding a call to a privilege-checking function in
+ each validator function. Non-core procedural languages will also
+ need to make this change to their own validator functions, if any.
+ (CVE-2014-0061)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid multiple name lookups during table and index DDL
+ (Robert Haas, Andres Freund)
+ </para>
+
+ <para>
+ If the name lookups come to different conclusions due to concurrent
+ activity, we might perform some parts of the DDL on a different table
+ than other parts. At least in the case of <command>CREATE INDEX</>,
+ this can be used to cause the permissions checks to be performed
+ against a different table than the index creation, allowing for a
+ privilege escalation attack.
+ (CVE-2014-0062)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent buffer overrun with long datetime strings (Noah Misch)
+ </para>
+
+ <para>
+ The <literal>MAXDATELEN</> constant was too small for the longest
+ possible value of type <type>interval</>, allowing a buffer overrun
+ in <function>interval_out()</>. Although the datetime input
+ functions were more careful about avoiding buffer overrun, the limit
+ was short enough to cause them to reject some valid inputs, such as
+ input containing a very long timezone name. The <application>ecpg</>
+ library contained these vulnerabilities along with some of its own.
+ (CVE-2014-0063)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent buffer overrun due to integer overflow in size calculations
+ (Noah Misch, Heikki Linnakangas)
+ </para>
+
+ <para>
+ Several functions, mostly type input functions, calculated an
+ allocation size without checking for overflow. If overflow did
+ occur, a too-small buffer would be allocated and then written past.
+ (CVE-2014-0064)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent overruns of fixed-size buffers
+ (Peter Eisentraut, Jozef Mlich)
+ </para>
+
+ <para>
+ Use <function>strlcpy()</> and related functions to provide a clear
+ guarantee that fixed-size buffers are not overrun. Unlike the
+ preceding items, it is unclear whether these cases really represent
+ live issues, since in most cases there appear to be previous
+ constraints on the size of the input string. Nonetheless it seems
+ prudent to silence all Coverity warnings of this type.
+ (CVE-2014-0065)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid crashing if <function>crypt()</> returns NULL (Honza Horak,
+ Bruce Momjian)
+ </para>
+
+ <para>
+ There are relatively few scenarios in which <function>crypt()</>
+ could return NULL, but <filename>contrib/chkpass</> would crash
+ if it did. One practical case in which this could be an issue is
+ if <application>libc</> is configured to refuse to execute unapproved
+ hashing algorithms (e.g., <quote>FIPS mode</>).
+ (CVE-2014-0066)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Document risks of <literal>make check</> in the regression testing
+ instructions (Noah Misch, Tom Lane)
+ </para>
+
+ <para>
+ Since the temporary server started by <literal>make check</>
+ uses <quote>trust</> authentication, another user on the same machine
+ could connect to it as database superuser, and then potentially
+ exploit the privileges of the operating-system user who started the
+ tests. A future release will probably incorporate changes in the
+ testing procedure to prevent this risk, but some public discussion is
+ needed first. So for the moment, just warn people against using
+ <literal>make check</> when there are untrusted users on the
+ same machine.
+ (CVE-2014-0067)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix possible mis-replay of WAL records when some segments of a
diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index 8d75f8b16a8a8476c77cdce1c618da408619cefb..81897ae83785f518705954bc1f4fd64506e05f68 100644
--- a/doc/src/sgml/release-9.0.sgml
+++ b/doc/src/sgml/release-9.0.sgml
@@ -34,6 +34,145 @@
<itemizedlist>
+ <listitem>
+ <para>
+ Shore up <literal>GRANT ... WITH ADMIN OPTION</> restrictions
+ (Noah Misch)
+ </para>
+
+ <para>
+ Granting a role without <literal>ADMIN OPTION</> is supposed to
+ prevent the grantee from adding or removing members from the granted
+ role, but this restriction was easily bypassed by doing <literal>SET
+ ROLE</> first. The security impact is mostly that a role member can
+ revoke the access of others, contrary to the wishes of his grantor.
+ Unapproved role member additions are a lesser concern, since an
+ uncooperative role member could provide most of his rights to others
+ anyway by creating views or <literal>SECURITY DEFINER</> functions.
+ (CVE-2014-0060)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent privilege escalation via manual calls to PL validator
+ functions (Andres Freund)
+ </para>
+
+ <para>
+ The primary role of PL validator functions is to be called implicitly
+ during <command>CREATE FUNCTION</>, but they are also normal SQL
+ functions that a user can call explicitly. Calling a validator on
+ a function actually written in some other language was not checked
+ for and could be exploited for privilege-escalation purposes.
+ The fix involves adding a call to a privilege-checking function in
+ each validator function. Non-core procedural languages will also
+ need to make this change to their own validator functions, if any.
+ (CVE-2014-0061)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid multiple name lookups during table and index DDL
+ (Robert Haas, Andres Freund)
+ </para>
+
+ <para>
+ If the name lookups come to different conclusions due to concurrent
+ activity, we might perform some parts of the DDL on a different table
+ than other parts. At least in the case of <command>CREATE INDEX</>,
+ this can be used to cause the permissions checks to be performed
+ against a different table than the index creation, allowing for a
+ privilege escalation attack.
+ (CVE-2014-0062)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent buffer overrun with long datetime strings (Noah Misch)
+ </para>
+
+ <para>
+ The <literal>MAXDATELEN</> constant was too small for the longest
+ possible value of type <type>interval</>, allowing a buffer overrun
+ in <function>interval_out()</>. Although the datetime input
+ functions were more careful about avoiding buffer overrun, the limit
+ was short enough to cause them to reject some valid inputs, such as
+ input containing a very long timezone name. The <application>ecpg</>
+ library contained these vulnerabilities along with some of its own.
+ (CVE-2014-0063)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent buffer overrun due to integer overflow in size calculations
+ (Noah Misch, Heikki Linnakangas)
+ </para>
+
+ <para>
+ Several functions, mostly type input functions, calculated an
+ allocation size without checking for overflow. If overflow did
+ occur, a too-small buffer would be allocated and then written past.
+ (CVE-2014-0064)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent overruns of fixed-size buffers
+ (Peter Eisentraut, Jozef Mlich)
+ </para>
+
+ <para>
+ Use <function>strlcpy()</> and related functions to provide a clear
+ guarantee that fixed-size buffers are not overrun. Unlike the
+ preceding items, it is unclear whether these cases really represent
+ live issues, since in most cases there appear to be previous
+ constraints on the size of the input string. Nonetheless it seems
+ prudent to silence all Coverity warnings of this type.
+ (CVE-2014-0065)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid crashing if <function>crypt()</> returns NULL (Honza Horak,
+ Bruce Momjian)
+ </para>
+
+ <para>
+ There are relatively few scenarios in which <function>crypt()</>
+ could return NULL, but <filename>contrib/chkpass</> would crash
+ if it did. One practical case in which this could be an issue is
+ if <application>libc</> is configured to refuse to execute unapproved
+ hashing algorithms (e.g., <quote>FIPS mode</>).
+ (CVE-2014-0066)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Document risks of <literal>make check</> in the regression testing
+ instructions (Noah Misch, Tom Lane)
+ </para>
+
+ <para>
+ Since the temporary server started by <literal>make check</>
+ uses <quote>trust</> authentication, another user on the same machine
+ could connect to it as database superuser, and then potentially
+ exploit the privileges of the operating-system user who started the
+ tests. A future release will probably incorporate changes in the
+ testing procedure to prevent this risk, but some public discussion is
+ needed first. So for the moment, just warn people against using
+ <literal>make check</> when there are untrusted users on the
+ same machine.
+ (CVE-2014-0067)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix possible mis-replay of WAL records when some segments of a
diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml
index 310e7e28589902c8e894eff8933c54877030dd70..05724cc82b19f1bfe6dc883c31bd65aaa7746a16 100644
--- a/doc/src/sgml/release-9.1.sgml
+++ b/doc/src/sgml/release-9.1.sgml
@@ -34,6 +34,145 @@
<itemizedlist>
+ <listitem>
+ <para>
+ Shore up <literal>GRANT ... WITH ADMIN OPTION</> restrictions
+ (Noah Misch)
+ </para>
+
+ <para>
+ Granting a role without <literal>ADMIN OPTION</> is supposed to
+ prevent the grantee from adding or removing members from the granted
+ role, but this restriction was easily bypassed by doing <literal>SET
+ ROLE</> first. The security impact is mostly that a role member can
+ revoke the access of others, contrary to the wishes of his grantor.
+ Unapproved role member additions are a lesser concern, since an
+ uncooperative role member could provide most of his rights to others
+ anyway by creating views or <literal>SECURITY DEFINER</> functions.
+ (CVE-2014-0060)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent privilege escalation via manual calls to PL validator
+ functions (Andres Freund)
+ </para>
+
+ <para>
+ The primary role of PL validator functions is to be called implicitly
+ during <command>CREATE FUNCTION</>, but they are also normal SQL
+ functions that a user can call explicitly. Calling a validator on
+ a function actually written in some other language was not checked
+ for and could be exploited for privilege-escalation purposes.
+ The fix involves adding a call to a privilege-checking function in
+ each validator function. Non-core procedural languages will also
+ need to make this change to their own validator functions, if any.
+ (CVE-2014-0061)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid multiple name lookups during table and index DDL
+ (Robert Haas, Andres Freund)
+ </para>
+
+ <para>
+ If the name lookups come to different conclusions due to concurrent
+ activity, we might perform some parts of the DDL on a different table
+ than other parts. At least in the case of <command>CREATE INDEX</>,
+ this can be used to cause the permissions checks to be performed
+ against a different table than the index creation, allowing for a
+ privilege escalation attack.
+ (CVE-2014-0062)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent buffer overrun with long datetime strings (Noah Misch)
+ </para>
+
+ <para>
+ The <literal>MAXDATELEN</> constant was too small for the longest
+ possible value of type <type>interval</>, allowing a buffer overrun
+ in <function>interval_out()</>. Although the datetime input
+ functions were more careful about avoiding buffer overrun, the limit
+ was short enough to cause them to reject some valid inputs, such as
+ input containing a very long timezone name. The <application>ecpg</>
+ library contained these vulnerabilities along with some of its own.
+ (CVE-2014-0063)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent buffer overrun due to integer overflow in size calculations
+ (Noah Misch, Heikki Linnakangas)
+ </para>
+
+ <para>
+ Several functions, mostly type input functions, calculated an
+ allocation size without checking for overflow. If overflow did
+ occur, a too-small buffer would be allocated and then written past.
+ (CVE-2014-0064)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent overruns of fixed-size buffers
+ (Peter Eisentraut, Jozef Mlich)
+ </para>
+
+ <para>
+ Use <function>strlcpy()</> and related functions to provide a clear
+ guarantee that fixed-size buffers are not overrun. Unlike the
+ preceding items, it is unclear whether these cases really represent
+ live issues, since in most cases there appear to be previous
+ constraints on the size of the input string. Nonetheless it seems
+ prudent to silence all Coverity warnings of this type.
+ (CVE-2014-0065)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid crashing if <function>crypt()</> returns NULL (Honza Horak,
+ Bruce Momjian)
+ </para>
+
+ <para>
+ There are relatively few scenarios in which <function>crypt()</>
+ could return NULL, but <filename>contrib/chkpass</> would crash
+ if it did. One practical case in which this could be an issue is
+ if <application>libc</> is configured to refuse to execute unapproved
+ hashing algorithms (e.g., <quote>FIPS mode</>).
+ (CVE-2014-0066)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Document risks of <literal>make check</> in the regression testing
+ instructions (Noah Misch, Tom Lane)
+ </para>
+
+ <para>
+ Since the temporary server started by <literal>make check</>
+ uses <quote>trust</> authentication, another user on the same machine
+ could connect to it as database superuser, and then potentially
+ exploit the privileges of the operating-system user who started the
+ tests. A future release will probably incorporate changes in the
+ testing procedure to prevent this risk, but some public discussion is
+ needed first. So for the moment, just warn people against using
+ <literal>make check</> when there are untrusted users on the
+ same machine.
+ (CVE-2014-0067)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix possible mis-replay of WAL records when some segments of a
diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml
index 33e2a4e81058d24931ec2c192d615f01d7def51b..be3577977928bb0890ee98a7efa3131a6ef7a665 100644
--- a/doc/src/sgml/release-9.2.sgml
+++ b/doc/src/sgml/release-9.2.sgml
@@ -34,6 +34,145 @@
<itemizedlist>
+ <listitem>
+ <para>
+ Shore up <literal>GRANT ... WITH ADMIN OPTION</> restrictions
+ (Noah Misch)
+ </para>
+
+ <para>
+ Granting a role without <literal>ADMIN OPTION</> is supposed to
+ prevent the grantee from adding or removing members from the granted
+ role, but this restriction was easily bypassed by doing <literal>SET
+ ROLE</> first. The security impact is mostly that a role member can
+ revoke the access of others, contrary to the wishes of his grantor.
+ Unapproved role member additions are a lesser concern, since an
+ uncooperative role member could provide most of his rights to others
+ anyway by creating views or <literal>SECURITY DEFINER</> functions.
+ (CVE-2014-0060)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent privilege escalation via manual calls to PL validator
+ functions (Andres Freund)
+ </para>
+
+ <para>
+ The primary role of PL validator functions is to be called implicitly
+ during <command>CREATE FUNCTION</>, but they are also normal SQL
+ functions that a user can call explicitly. Calling a validator on
+ a function actually written in some other language was not checked
+ for and could be exploited for privilege-escalation purposes.
+ The fix involves adding a call to a privilege-checking function in
+ each validator function. Non-core procedural languages will also
+ need to make this change to their own validator functions, if any.
+ (CVE-2014-0061)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid multiple name lookups during table and index DDL
+ (Robert Haas, Andres Freund)
+ </para>
+
+ <para>
+ If the name lookups come to different conclusions due to concurrent
+ activity, we might perform some parts of the DDL on a different table
+ than other parts. At least in the case of <command>CREATE INDEX</>,
+ this can be used to cause the permissions checks to be performed
+ against a different table than the index creation, allowing for a
+ privilege escalation attack.
+ (CVE-2014-0062)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent buffer overrun with long datetime strings (Noah Misch)
+ </para>
+
+ <para>
+ The <literal>MAXDATELEN</> constant was too small for the longest
+ possible value of type <type>interval</>, allowing a buffer overrun
+ in <function>interval_out()</>. Although the datetime input
+ functions were more careful about avoiding buffer overrun, the limit
+ was short enough to cause them to reject some valid inputs, such as
+ input containing a very long timezone name. The <application>ecpg</>
+ library contained these vulnerabilities along with some of its own.
+ (CVE-2014-0063)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent buffer overrun due to integer overflow in size calculations
+ (Noah Misch, Heikki Linnakangas)
+ </para>
+
+ <para>
+ Several functions, mostly type input functions, calculated an
+ allocation size without checking for overflow. If overflow did
+ occur, a too-small buffer would be allocated and then written past.
+ (CVE-2014-0064)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Prevent overruns of fixed-size buffers
+ (Peter Eisentraut, Jozef Mlich)
+ </para>
+
+ <para>
+ Use <function>strlcpy()</> and related functions to provide a clear
+ guarantee that fixed-size buffers are not overrun. Unlike the
+ preceding items, it is unclear whether these cases really represent
+ live issues, since in most cases there appear to be previous
+ constraints on the size of the input string. Nonetheless it seems
+ prudent to silence all Coverity warnings of this type.
+ (CVE-2014-0065)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Avoid crashing if <function>crypt()</> returns NULL (Honza Horak,
+ Bruce Momjian)
+ </para>
+
+ <para>
+ There are relatively few scenarios in which <function>crypt()</>
+ could return NULL, but <filename>contrib/chkpass</> would crash
+ if it did. One practical case in which this could be an issue is
+ if <application>libc</> is configured to refuse to execute unapproved
+ hashing algorithms (e.g., <quote>FIPS mode</>).
+ (CVE-2014-0066)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Document risks of <literal>make check</> in the regression testing
+ instructions (Noah Misch, Tom Lane)
+ </para>
+
+ <para>
+ Since the temporary server started by <literal>make check</>
+ uses <quote>trust</> authentication, another user on the same machine
+ could connect to it as database superuser, and then potentially
+ exploit the privileges of the operating-system user who started the
+ tests. A future release will probably incorporate changes in the
+ testing procedure to prevent this risk, but some public discussion is
+ needed first. So for the moment, just warn people against using
+ <literal>make check</> when there are untrusted users on the
+ same machine.
+ (CVE-2014-0067)
+ </para>
+ </listitem>
+
<listitem>
<para>
Fix possible mis-replay of WAL records when some segments of a
diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index 11e429bb65d9f956be4da274c62f48c2ee51e407..5538707a0962d9c62da96763756d9038bd8c21ad 100644
--- a/doc/src/sgml/release-9.3.sgml
+++ b/doc/src/sgml/release-9.3.sgml
@@ -51,6 +51,225 @@
<itemizedlist>
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [fea164a72] 2014-02-17 09:33:31 -0500
+Branch: REL9_3_STABLE [475a1fbc4] 2014-02-17 09:33:32 -0500
+Branch: REL9_2_STABLE [15a8f97b9] 2014-02-17 09:33:33 -0500
+Branch: REL9_1_STABLE [5d320a16c] 2014-02-17 09:33:33 -0500
+Branch: REL9_0_STABLE [789063697] 2014-02-17 09:33:37 -0500
+Branch: REL8_4_STABLE [ff35425c8] 2014-02-17 09:33:38 -0500
+-->
+
+ <listitem>
+ <para>
+ Shore up <literal>GRANT ... WITH ADMIN OPTION</> restrictions
+ (Noah Misch)
+ </para>
+
+ <para>
+ Granting a role without <literal>ADMIN OPTION</> is supposed to
+ prevent the grantee from adding or removing members from the granted
+ role, but this restriction was easily bypassed by doing <literal>SET
+ ROLE</> first. The security impact is mostly that a role member can
+ revoke the access of others, contrary to the wishes of his grantor.
+ Unapproved role member additions are a lesser concern, since an
+ uncooperative role member could provide most of his rights to others
+ anyway by creating views or <literal>SECURITY DEFINER</> functions.
+ (CVE-2014-0060)
+ </para>
+ </listitem>
+
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [537cbd35c] 2014-02-17 09:33:31 -0500
+Branch: REL9_3_STABLE [fc4a04a3c] 2014-02-17 09:33:32 -0500
+Branch: REL9_2_STABLE [1d701d28a] 2014-02-17 09:33:33 -0500
+Branch: REL9_1_STABLE [23b5a85e6] 2014-02-17 09:33:36 -0500
+Branch: REL9_0_STABLE [c0ac4c75f] 2014-02-17 09:33:37 -0500
+Branch: REL8_4_STABLE [823b9dc25] 2014-02-17 09:33:38 -0500
+-->
+
+ <listitem>
+ <para>
+ Prevent privilege escalation via manual calls to PL validator
+ functions (Andres Freund)
+ </para>
+
+ <para>
+ The primary role of PL validator functions is to be called implicitly
+ during <command>CREATE FUNCTION</>, but they are also normal SQL
+ functions that a user can call explicitly. Calling a validator on
+ a function actually written in some other language was not checked
+ for and could be exploited for privilege-escalation purposes.
+ The fix involves adding a call to a privilege-checking function in
+ each validator function. Non-core procedural languages will also
+ need to make this change to their own validator functions, if any.
+ (CVE-2014-0061)
+ </para>
+ </listitem>
+
+<!--
+Author: Robert Haas <rhaas@postgresql.org>
+Branch: master [5f173040e] 2014-02-17 09:33:31 -0500
+Branch: REL9_3_STABLE [e1e0a4d79] 2014-02-17 09:33:32 -0500
+Branch: REL9_2_STABLE [820ab11fb] 2014-02-17 09:33:33 -0500
+Branch: REL9_1_STABLE [b5c574399] 2014-02-17 09:33:36 -0500
+Branch: REL9_0_STABLE [43d4e965e] 2014-02-17 09:33:37 -0500
+Branch: REL8_4_STABLE [e46476133] 2014-02-17 09:33:38 -0500
+-->
+
+ <listitem>
+ <para>
+ Avoid multiple name lookups during table and index DDL
+ (Robert Haas, Andres Freund)
+ </para>
+
+ <para>
+ If the name lookups come to different conclusions due to concurrent
+ activity, we might perform some parts of the DDL on a different table
+ than other parts. At least in the case of <command>CREATE INDEX</>,
+ this can be used to cause the permissions checks to be performed
+ against a different table than the index creation, allowing for a
+ privilege escalation attack.
+ (CVE-2014-0062)
+ </para>
+ </listitem>
+
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [4318daecc] 2014-02-17 09:33:31 -0500
+Branch: REL9_3_STABLE [e4a4fa223] 2014-02-17 09:33:32 -0500
+Branch: REL9_2_STABLE [f416622be] 2014-02-17 09:33:33 -0500
+Branch: REL9_1_STABLE [6a10e57b0] 2014-02-17 09:33:37 -0500
+Branch: REL9_0_STABLE [b9c3bb1b3] 2014-02-17 09:33:38 -0500
+Branch: REL8_4_STABLE [d0ed1a6c0] 2014-02-17 09:33:39 -0500
+-->
+
+ <listitem>
+ <para>
+ Prevent buffer overrun with long datetime strings (Noah Misch)
+ </para>
+
+ <para>
+ The <literal>MAXDATELEN</> constant was too small for the longest
+ possible value of type <type>interval</>, allowing a buffer overrun
+ in <function>interval_out()</>. Although the datetime input
+ functions were more careful about avoiding buffer overrun, the limit
+ was short enough to cause them to reject some valid inputs, such as
+ input containing a very long timezone name. The <application>ecpg</>
+ library contained these vulnerabilities along with some of its own.
+ (CVE-2014-0063)
+ </para>
+ </listitem>
+
+<!--
+Author: Noah Misch <noah@leadboat.com>
+Branch: master [31400a673] 2014-02-17 09:33:31 -0500
+Branch: REL9_3_STABLE [7a362a176] 2014-02-17 09:33:32 -0500
+Branch: REL9_2_STABLE [12bbce15d] 2014-02-17 09:33:33 -0500
+Branch: REL9_1_STABLE [0b7026d96] 2014-02-17 09:33:37 -0500
+Branch: REL9_0_STABLE [2c3203e18] 2014-02-17 09:33:38 -0500
+Branch: REL8_4_STABLE [98be8a6ea] 2014-02-17 09:33:39 -0500
+-->
+
+ <listitem>
+ <para>
+ Prevent buffer overrun due to integer overflow in size calculations
+ (Noah Misch, Heikki Linnakangas)
+ </para>
+
+ <para>
+ Several functions, mostly type input functions, calculated an
+ allocation size without checking for overflow. If overflow did
+ occur, a too-small buffer would be allocated and then written past.
+ (CVE-2014-0064)
+ </para>
+ </listitem>
+
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [01824385a] 2014-02-17 11:20:21 -0500
+Branch: REL9_3_STABLE [e3208fec3] 2014-02-17 11:20:24 -0500
+Branch: REL9_2_STABLE [655b665f7] 2014-02-17 11:20:27 -0500
+Branch: REL9_1_STABLE [4741e3160] 2014-02-17 11:20:31 -0500
+Branch: REL9_0_STABLE [45bf2404a] 2014-02-17 11:20:35 -0500
+Branch: REL8_4_STABLE [69d2bc14a] 2014-02-17 11:20:38 -0500
+-->
+
+ <listitem>
+ <para>
+ Prevent overruns of fixed-size buffers
+ (Peter Eisentraut, Jozef Mlich)
+ </para>
+
+ <para>
+ Use <function>strlcpy()</> and related functions to provide a clear
+ guarantee that fixed-size buffers are not overrun. Unlike the
+ preceding items, it is unclear whether these cases really represent
+ live issues, since in most cases there appear to be previous
+ constraints on the size of the input string. Nonetheless it seems
+ prudent to silence all Coverity warnings of this type.
+ (CVE-2014-0065)
+ </para>
+ </listitem>
+
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [01824385a] 2014-02-17 11:20:21 -0500
+Branch: REL9_3_STABLE [e3208fec3] 2014-02-17 11:20:24 -0500
+Branch: REL9_2_STABLE [655b665f7] 2014-02-17 11:20:27 -0500
+Branch: REL9_1_STABLE [4741e3160] 2014-02-17 11:20:31 -0500
+Branch: REL9_0_STABLE [45bf2404a] 2014-02-17 11:20:35 -0500
+Branch: REL8_4_STABLE [69d2bc14a] 2014-02-17 11:20:38 -0500
+-->
+
+ <listitem>
+ <para>
+ Avoid crashing if <function>crypt()</> returns NULL (Honza Horak,
+ Bruce Momjian)
+ </para>
+
+ <para>
+ There are relatively few scenarios in which <function>crypt()</>
+ could return NULL, but <filename>contrib/chkpass</> would crash
+ if it did. One practical case in which this could be an issue is
+ if <application>libc</> is configured to refuse to execute unapproved
+ hashing algorithms (e.g., <quote>FIPS mode</>).
+ (CVE-2014-0066)
+ </para>
+ </listitem>
+
+<!--
+Author: Tom Lane <tgl@sss.pgh.pa.us>
+Branch: master [6ef325429] 2014-02-17 11:24:32 -0500
+Branch: REL9_3_STABLE [1ec5988f3] 2014-02-17 11:24:38 -0500
+Branch: REL9_2_STABLE [ff3d533e5] 2014-02-17 11:24:42 -0500
+Branch: REL9_1_STABLE [800a3744b] 2014-02-17 11:24:45 -0500
+Branch: REL9_0_STABLE [369c229d2] 2014-02-17 11:24:48 -0500
+Branch: REL8_4_STABLE [f58663ab1] 2014-02-17 11:24:51 -0500
+-->
+
+ <listitem>
+ <para>
+ Document risks of <literal>make check</> in the regression testing
+ instructions (Noah Misch, Tom Lane)
+ </para>
+
+ <para>
+ Since the temporary server started by <literal>make check</>
+ uses <quote>trust</> authentication, another user on the same machine
+ could connect to it as database superuser, and then potentially
+ exploit the privileges of the operating-system user who started the
+ tests. A future release will probably incorporate changes in the
+ testing procedure to prevent this risk, but some public discussion is
+ needed first. So for the moment, just warn people against using
+ <literal>make check</> when there are untrusted users on the
+ same machine.
+ (CVE-2014-0067)
+ </para>
+ </listitem>
+
<!--
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Branch: master [3b97e6823] 2013-12-16 11:29:50 -0300