Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit7b1fab3

Browse files
committed
Last-minute updates for release notes.
Add entries for security issues.Security:CVE-2014-0060 throughCVE-2014-0067
1 parent876f78d commit7b1fab3

File tree

5 files changed

+775
-0
lines changed

5 files changed

+775
-0
lines changed

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

Lines changed: 139 additions & 0 deletions
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

Lines changed: 139 additions & 0 deletions
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)
[8]ページ先頭
©2009-2025 Movatter.jp