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

Commit 57b995a

Browse files
tglsfdctglsfdc
committed
Last-minute updates for release notes.
Security: CVE-2017-7546, CVE-2017-7547, CVE-2017-7548
1 parent 52a4143 commit 57b995a

File tree

5 files changed

+707
-355
lines changed

5 files changed

+707
-355
lines changed

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

+128-71
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,12 @@
2929
</para>
3030

3131
<para>
32-
However, if you are upgrading from a version earlier than 9.2.20,
32+
However, if you use foreign data servers that make use of user
33+
passwords for authentication, see the first changelog entry below.
34+
</para>
35+
36+
<para>
37+
Also, if you are upgrading from a version earlier than 9.2.20,
3338
see <xref linkend="release-9-2-20">.
3439
</para>
3540

@@ -40,6 +45,126 @@
4045

4146
<itemizedlist>
4247

48+
<listitem>
49+
<para>
50+
Further restrict visibility
51+
of <structname>pg_user_mappings</>.<structfield>umoptions</>, to
52+
protect passwords stored as user mapping options
53+
(Noah Misch)
54+
</para>
55+
56+
<para>
57+
The fix for CVE-2017-7486 was incorrect: it allowed a user
58+
to see the options in her own user mapping, even if she did not
59+
have <literal>USAGE</> permission on the associated foreign server.
60+
Such options might include a password that had been provided by the
61+
server owner rather than the user herself.
62+
Since <structname>information_schema.user_mapping_options</> does not
63+
show the options in such cases, <structname>pg_user_mappings</>
64+
should not either.
65+
(CVE-2017-7547)
66+
</para>
67+
68+
<para>
69+
By itself, this patch will only fix the behavior in newly initdb'd
70+
databases. If you wish to apply this change in an existing database,
71+
you will need to do the following:
72+
</para>
73+
74+
<procedure>
75+
<step>
76+
<para>
77+
Restart the postmaster after adding <literal>allow_system_table_mods
78+
= true</> to <filename>postgresql.conf</>. (In versions
79+
supporting <command>ALTER SYSTEM</>, you can use that to make the
80+
configuration change, but you'll still need a restart.)
81+
</para>
82+
</step>
83+
84+
<step>
85+
<para>
86+
In <emphasis>each</> database of the cluster,
87+
run the following commands as superuser:
88+
<programlisting>
89+
SET search_path = pg_catalog;
90+
CREATE OR REPLACE VIEW pg_user_mappings AS
91+
SELECT
92+
U.oid AS umid,
93+
S.oid AS srvid,
94+
S.srvname AS srvname,
95+
U.umuser AS umuser,
96+
CASE WHEN U.umuser = 0 THEN
97+
'public'
98+
ELSE
99+
A.rolname
100+
END AS usename,
101+
CASE WHEN (U.umuser &lt;&gt; 0 AND A.rolname = current_user
102+
AND (pg_has_role(S.srvowner, 'USAGE')
103+
OR has_server_privilege(S.oid, 'USAGE')))
104+
OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
105+
OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
106+
THEN U.umoptions
107+
ELSE NULL END AS umoptions
108+
FROM pg_user_mapping U
109+
LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
110+
pg_foreign_server S ON (U.umserver = S.oid);
111+
</programlisting>
112+
</para>
113+
</step>
114+
115+
<step>
116+
<para>
117+
Do not forget to include the <literal>template0</>
118+
and <literal>template1</> databases, or the vulnerability will still
119+
exist in databases you create later. To fix <literal>template0</>,
120+
you'll need to temporarily make it accept connections.
121+
In <productname>PostgreSQL</> 9.5 and later, you can use
122+
<programlisting>
123+
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
124+
</programlisting>
125+
and then after fixing <literal>template0</>, undo that with
126+
<programlisting>
127+
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
128+
</programlisting>
129+
In prior versions, instead use
130+
<programlisting>
131+
UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
132+
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
133+
</programlisting>
134+
</para>
135+
</step>
136+
137+
<step>
138+
<para>
139+
Finally, remove the <literal>allow_system_table_mods</> configuration
140+
setting, and again restart the postmaster.
141+
</para>
142+
</step>
143+
</procedure>
144+
</listitem>
145+
146+
<listitem>
147+
<para>
148+
Disallow empty passwords in all password-based authentication methods
149+
(Heikki Linnakangas)
150+
</para>
151+
152+
<para>
153+
<application>libpq</> ignores empty password specifications, and does
154+
not transmit them to the server. So, if a user's password has been
155+
set to the empty string, it's impossible to log in with that password
156+
via <application>psql</> or other <application>libpq</>-based
157+
clients. An administrator might therefore believe that setting the
158+
password to empty is equivalent to disabling password login.
159+
However, with a modified or non-<application>libpq</>-based client,
160+
logging in could be possible, depending on which authentication
161+
method is configured. In particular the most common
162+
method, <literal>md5</>, accepted empty passwords.
163+
Change the server to reject empty passwords in all cases.
164+
(CVE-2017-7546)
165+
</para>
166+
</listitem>
167+
43168
<listitem>
44169
<para>
45170
On Windows, retry process creation if we fail to reserve the address
@@ -410,77 +535,9 @@
410535
<para>
411536
By itself, this patch will only fix the behavior in newly initdb'd
412537
databases. If you wish to apply this change in an existing database,
413-
you will need to do the following:
538+
follow the corrected procedure shown in the changelog entry for
539+
CVE-2017-7547, in <xref linkend="release-9-2-22">.
414540
</para>
415-
416-
<procedure>
417-
<step>
418-
<para>
419-
Restart the postmaster after adding <literal>allow_system_table_mods
420-
= true</> to <filename>postgresql.conf</>. (In versions
421-
supporting <command>ALTER SYSTEM</>, you can use that to make the
422-
configuration change, but you'll still need a restart.)
423-
</para>
424-
</step>
425-
426-
<step>
427-
<para>
428-
In <emphasis>each</> database of the cluster,
429-
run the following commands as superuser:
430-
<programlisting>
431-
SET search_path = pg_catalog;
432-
CREATE OR REPLACE VIEW pg_user_mappings AS
433-
SELECT
434-
U.oid AS umid,
435-
S.oid AS srvid,
436-
S.srvname AS srvname,
437-
U.umuser AS umuser,
438-
CASE WHEN U.umuser = 0 THEN
439-
'public'
440-
ELSE
441-
A.rolname
442-
END AS usename,
443-
CASE WHEN (U.umuser &lt;&gt; 0 AND A.rolname = current_user)
444-
OR (U.umuser = 0 AND pg_has_role(S.srvowner, 'USAGE'))
445-
OR (SELECT rolsuper FROM pg_authid WHERE rolname = current_user)
446-
THEN U.umoptions
447-
ELSE NULL END AS umoptions
448-
FROM pg_user_mapping U
449-
LEFT JOIN pg_authid A ON (A.oid = U.umuser) JOIN
450-
pg_foreign_server S ON (U.umserver = S.oid);
451-
</programlisting>
452-
</para>
453-
</step>
454-
455-
<step>
456-
<para>
457-
Do not forget to include the <literal>template0</>
458-
and <literal>template1</> databases, or the vulnerability will still
459-
exist in databases you create later. To fix <literal>template0</>,
460-
you'll need to temporarily make it accept connections.
461-
In <productname>PostgreSQL</> 9.5 and later, you can use
462-
<programlisting>
463-
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;
464-
</programlisting>
465-
and then after fixing <literal>template0</>, undo that with
466-
<programlisting>
467-
ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;
468-
</programlisting>
469-
In prior versions, instead use
470-
<programlisting>
471-
UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
472-
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
473-
</programlisting>
474-
</para>
475-
</step>
476-
477-
<step>
478-
<para>
479-
Finally, remove the <literal>allow_system_table_mods</> configuration
480-
setting, and again restart the postmaster.
481-
</para>
482-
</step>
483-
</procedure>
484541
</listitem>
485542

486543
<listitem>

0 commit comments

Comments
 (0)