Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 7b1fab3

Browse files
tglsfdctglsfdc
committed
Last-minute updates for release notes.
Add entries for security issues. Security: CVE-2014-0060 through CVE-2014-0067
1 parent 876f78d commit 7b1fab3

File tree

5 files changed

+775
-0
lines changed

5 files changed

+775
-0
lines changed

‎doc/src/sgml/release-8.4.sgml

+139
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,145 @@
4040

4141
<itemizedlist>
4242

43+
<listitem>
44+
<para>
45+
Shore up <literal>GRANT ... WITH ADMIN OPTION</> restrictions
46+
(Noah Misch)
47+
</para>
48+
49+
<para>
50+
Granting a role without <literal>ADMIN OPTION</> is supposed to
51+
prevent the grantee from adding or removing members from the granted
52+
role, but this restriction was easily bypassed by doing <literal>SET
53+
ROLE</> first. The security impact is mostly that a role member can
54+
revoke the access of others, contrary to the wishes of his grantor.
55+
Unapproved role member additions are a lesser concern, since an
56+
uncooperative role member could provide most of his rights to others
57+
anyway by creating views or <literal>SECURITY DEFINER</> functions.
58+
(CVE-2014-0060)
59+
</para>
60+
</listitem>
61+
62+
<listitem>
63+
<para>
64+
Prevent privilege escalation via manual calls to PL validator
65+
functions (Andres Freund)
66+
</para>
67+
68+
<para>
69+
The primary role of PL validator functions is to be called implicitly
70+
during <command>CREATE FUNCTION</>, but they are also normal SQL
71+
functions that a user can call explicitly. Calling a validator on
72+
a function actually written in some other language was not checked
73+
for and could be exploited for privilege-escalation purposes.
74+
The fix involves adding a call to a privilege-checking function in
75+
each validator function. Non-core procedural languages will also
76+
need to make this change to their own validator functions, if any.
77+
(CVE-2014-0061)
78+
</para>
79+
</listitem>
80+
81+
<listitem>
82+
<para>
83+
Avoid multiple name lookups during table and index DDL
84+
(Robert Haas, Andres Freund)
85+
</para>
86+
87+
<para>
88+
If the name lookups come to different conclusions due to concurrent
89+
activity, we might perform some parts of the DDL on a different table
90+
than other parts. At least in the case of <command>CREATE INDEX</>,
91+
this can be used to cause the permissions checks to be performed
92+
against a different table than the index creation, allowing for a
93+
privilege escalation attack.
94+
(CVE-2014-0062)
95+
</para>
96+
</listitem>
97+
98+
<listitem>
99+
<para>
100+
Prevent buffer overrun with long datetime strings (Noah Misch)
101+
</para>
102+
103+
<para>
104+
The <literal>MAXDATELEN</> constant was too small for the longest
105+
possible value of type <type>interval</>, allowing a buffer overrun
106+
in <function>interval_out()</>. Although the datetime input
107+
functions were more careful about avoiding buffer overrun, the limit
108+
was short enough to cause them to reject some valid inputs, such as
109+
input containing a very long timezone name. The <application>ecpg</>
110+
library contained these vulnerabilities along with some of its own.
111+
(CVE-2014-0063)
112+
</para>
113+
</listitem>
114+
115+
<listitem>
116+
<para>
117+
Prevent buffer overrun due to integer overflow in size calculations
118+
(Noah Misch, Heikki Linnakangas)
119+
</para>
120+
121+
<para>
122+
Several functions, mostly type input functions, calculated an
123+
allocation size without checking for overflow. If overflow did
124+
occur, a too-small buffer would be allocated and then written past.
125+
(CVE-2014-0064)
126+
</para>
127+
</listitem>
128+
129+
<listitem>
130+
<para>
131+
Prevent overruns of fixed-size buffers
132+
(Peter Eisentraut, Jozef Mlich)
133+
</para>
134+
135+
<para>
136+
Use <function>strlcpy()</> and related functions to provide a clear
137+
guarantee that fixed-size buffers are not overrun. Unlike the
138+
preceding items, it is unclear whether these cases really represent
139+
live issues, since in most cases there appear to be previous
140+
constraints on the size of the input string. Nonetheless it seems
141+
prudent to silence all Coverity warnings of this type.
142+
(CVE-2014-0065)
143+
</para>
144+
</listitem>
145+
146+
<listitem>
147+
<para>
148+
Avoid crashing if <function>crypt()</> returns NULL (Honza Horak,
149+
Bruce Momjian)
150+
</para>
151+
152+
<para>
153+
There are relatively few scenarios in which <function>crypt()</>
154+
could return NULL, but <filename>contrib/chkpass</> would crash
155+
if it did. One practical case in which this could be an issue is
156+
if <application>libc</> is configured to refuse to execute unapproved
157+
hashing algorithms (e.g., <quote>FIPS mode</>).
158+
(CVE-2014-0066)
159+
</para>
160+
</listitem>
161+
162+
<listitem>
163+
<para>
164+
Document risks of <literal>make check</> in the regression testing
165+
instructions (Noah Misch, Tom Lane)
166+
</para>
167+
168+
<para>
169+
Since the temporary server started by <literal>make check</>
170+
uses <quote>trust</> authentication, another user on the same machine
171+
could connect to it as database superuser, and then potentially
172+
exploit the privileges of the operating-system user who started the
173+
tests. A future release will probably incorporate changes in the
174+
testing procedure to prevent this risk, but some public discussion is
175+
needed first. So for the moment, just warn people against using
176+
<literal>make check</> when there are untrusted users on the
177+
same machine.
178+
(CVE-2014-0067)
179+
</para>
180+
</listitem>
181+
43182
<listitem>
44183
<para>
45184
Fix possible mis-replay of WAL records when some segments of a

‎doc/src/sgml/release-9.0.sgml

+139
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,145 @@
3434

3535
<itemizedlist>
3636

37+
<listitem>
38+
<para>
39+
Shore up <literal>GRANT ... WITH ADMIN OPTION</> restrictions
40+
(Noah Misch)
41+
</para>
42+
43+
<para>
44+
Granting a role without <literal>ADMIN OPTION</> is supposed to
45+
prevent the grantee from adding or removing members from the granted
46+
role, but this restriction was easily bypassed by doing <literal>SET
47+
ROLE</> first. The security impact is mostly that a role member can
48+
revoke the access of others, contrary to the wishes of his grantor.
49+
Unapproved role member additions are a lesser concern, since an
50+
uncooperative role member could provide most of his rights to others
51+
anyway by creating views or <literal>SECURITY DEFINER</> functions.
52+
(CVE-2014-0060)
53+
</para>
54+
</listitem>
55+
56+
<listitem>
57+
<para>
58+
Prevent privilege escalation via manual calls to PL validator
59+
functions (Andres Freund)
60+
</para>
61+
62+
<para>
63+
The primary role of PL validator functions is to be called implicitly
64+
during <command>CREATE FUNCTION</>, but they are also normal SQL
65+
functions that a user can call explicitly. Calling a validator on
66+
a function actually written in some other language was not checked
67+
for and could be exploited for privilege-escalation purposes.
68+
The fix involves adding a call to a privilege-checking function in
69+
each validator function. Non-core procedural languages will also
70+
need to make this change to their own validator functions, if any.
71+
(CVE-2014-0061)
72+
</para>
73+
</listitem>
74+
75+
<listitem>
76+
<para>
77+
Avoid multiple name lookups during table and index DDL
78+
(Robert Haas, Andres Freund)
79+
</para>
80+
81+
<para>
82+
If the name lookups come to different conclusions due to concurrent
83+
activity, we might perform some parts of the DDL on a different table
84+
than other parts. At least in the case of <command>CREATE INDEX</>,
85+
this can be used to cause the permissions checks to be performed
86+
against a different table than the index creation, allowing for a
87+
privilege escalation attack.
88+
(CVE-2014-0062)
89+
</para>
90+
</listitem>
91+
92+
<listitem>
93+
<para>
94+
Prevent buffer overrun with long datetime strings (Noah Misch)
95+
</para>
96+
97+
<para>
98+
The <literal>MAXDATELEN</> constant was too small for the longest
99+
possible value of type <type>interval</>, allowing a buffer overrun
100+
in <function>interval_out()</>. Although the datetime input
101+
functions were more careful about avoiding buffer overrun, the limit
102+
was short enough to cause them to reject some valid inputs, such as
103+
input containing a very long timezone name. The <application>ecpg</>
104+
library contained these vulnerabilities along with some of its own.
105+
(CVE-2014-0063)
106+
</para>
107+
</listitem>
108+
109+
<listitem>
110+
<para>
111+
Prevent buffer overrun due to integer overflow in size calculations
112+
(Noah Misch, Heikki Linnakangas)
113+
</para>
114+
115+
<para>
116+
Several functions, mostly type input functions, calculated an
117+
allocation size without checking for overflow. If overflow did
118+
occur, a too-small buffer would be allocated and then written past.
119+
(CVE-2014-0064)
120+
</para>
121+
</listitem>
122+
123+
<listitem>
124+
<para>
125+
Prevent overruns of fixed-size buffers
126+
(Peter Eisentraut, Jozef Mlich)
127+
</para>
128+
129+
<para>
130+
Use <function>strlcpy()</> and related functions to provide a clear
131+
guarantee that fixed-size buffers are not overrun. Unlike the
132+
preceding items, it is unclear whether these cases really represent
133+
live issues, since in most cases there appear to be previous
134+
constraints on the size of the input string. Nonetheless it seems
135+
prudent to silence all Coverity warnings of this type.
136+
(CVE-2014-0065)
137+
</para>
138+
</listitem>
139+
140+
<listitem>
141+
<para>
142+
Avoid crashing if <function>crypt()</> returns NULL (Honza Horak,
143+
Bruce Momjian)
144+
</para>
145+
146+
<para>
147+
There are relatively few scenarios in which <function>crypt()</>
148+
could return NULL, but <filename>contrib/chkpass</> would crash
149+
if it did. One practical case in which this could be an issue is
150+
if <application>libc</> is configured to refuse to execute unapproved
151+
hashing algorithms (e.g., <quote>FIPS mode</>).
152+
(CVE-2014-0066)
153+
</para>
154+
</listitem>
155+
156+
<listitem>
157+
<para>
158+
Document risks of <literal>make check</> in the regression testing
159+
instructions (Noah Misch, Tom Lane)
160+
</para>
161+
162+
<para>
163+
Since the temporary server started by <literal>make check</>
164+
uses <quote>trust</> authentication, another user on the same machine
165+
could connect to it as database superuser, and then potentially
166+
exploit the privileges of the operating-system user who started the
167+
tests. A future release will probably incorporate changes in the
168+
testing procedure to prevent this risk, but some public discussion is
169+
needed first. So for the moment, just warn people against using
170+
<literal>make check</> when there are untrusted users on the
171+
same machine.
172+
(CVE-2014-0067)
173+
</para>
174+
</listitem>
175+
37176
<listitem>
38177
<para>
39178
Fix possible mis-replay of WAL records when some segments of a

0 commit comments

Comments
 (0)