|
29 | 29 | </para> |
30 | 30 |
|
31 | 31 | <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, |
33 | 38 | see <xref linkend="release-9-2-20">. |
34 | 39 | </para> |
35 | 40 |
|
|
40 | 45 |
|
41 | 46 | <itemizedlist> |
42 | 47 |
|
| 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 <> 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 | + |
43 | 168 | <listitem> |
44 | 169 | <para> |
45 | 170 | On Windows, retry process creation if we fail to reserve the address |
|
410 | 535 | <para> |
411 | 536 | By itself, this patch will only fix the behavior in newly initdb'd |
412 | 537 | 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">. |
414 | 540 | </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 <> 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> |
484 | 541 | </listitem> |
485 | 542 |
|
486 | 543 | <listitem> |
|
0 commit comments