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

Commit57b995a

Browse files
committed
Last-minute updates for release notes.
Security:CVE-2017-7546,CVE-2017-7547,CVE-2017-7548
1 parent52a4143 commit57b995a

File tree

5 files changed

+707
-355
lines changed

5 files changed

+707
-355
lines changed

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

Lines changed: 128 additions & 71 deletions
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)

[8]ページ先頭

©2009-2025 Movatter.jp