8000 Last-minute updates for release notes. · MiniHero/postgres@56e55cf · GitHub
[go: up one dir, main page]
Skip to content

Commit 56e55cf

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 f58663a commit 56e55cf

File tree

1 file changed

+139
-0
lines changed

1 file changed

+139
-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

0 commit comments

Comments
 (0)
0