Skip to content

P
Postgres FD Implementation
Commit 7b1fab3f authored by Tom Lane's avatar Tom Lane
Browse files
Options

Last-minute updates for release notes. 

Add entries for security issues.

Security: CVE-2014-0060 through CVE-2014-0067
parent 876f78d5
Show whitespace changes
Inline Side-by-side
Showing with 775 additions and 0 deletions
doc/src/sgml/release-8.4.sgml
View file @ 7b1fab3f
......@@ -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
......
doc/src/sgml/release-9.0.sgml
View file @ 7b1fab3f
......@@ -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
......
doc/src/sgml/release-9.1.sgml
View file @ 7b1fab3f
......@@ -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
......
doc/src/sgml/release-9.2.sgml
View file @ 7b1fab3f
......@@ -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
......
doc/src/sgml/release-9.3.sgml
View file @ 7b1fab3f
......@@ -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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment