|
31 | 31 | <para> |
32 | 32 | However, note that installations using physical replication should |
33 | 33 | update standby servers before the primary server, as explained in |
34 | | - thefirst changelog entry below. |
| 34 | + thethird changelog entry below. |
35 | 35 | </para> |
36 | 36 |
|
37 | 37 | <para> |
|
54 | 54 |
|
55 | 55 | <listitem> |
56 | 56 | <!-- |
| 57 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 58 | +Branch: master [28e241255] 2021-11-08 11:01:43 -0500 |
| 59 | +Branch: REL_14_STABLE [9d5a76b8d] 2021-11-08 11:01:43 -0500 |
| 60 | +Branch: REL_13_STABLE [e92ed93e8] 2021-11-08 11:01:43 -0500 |
| 61 | +Branch: REL_12_STABLE [d1bd26740] 2021-11-08 11:01:43 -0500 |
| 62 | +Branch: REL_11_STABLE [9394fb828] 2021-11-08 11:01:43 -0500 |
| 63 | +Branch: REL_10_STABLE [9ae0f1112] 2021-11-08 11:01:43 -0500 |
| 64 | +Branch: REL9_6_STABLE [046c2c846] 2021-11-08 11:01:43 -0500 |
| 65 | +--> |
| 66 | + <para> |
| 67 | + Make the server reject extraneous data after an SSL or GSS |
| 68 | + encryption handshake (Tom Lane) |
| 69 | + </para> |
| 70 | + |
| 71 | + <para> |
| 72 | + A man-in-the-middle with the ability to inject data into the TCP |
| 73 | + connection could stuff some cleartext data into the start of a |
| 74 | + supposedly encryption-protected database session. |
| 75 | + This could be abused to send faked SQL commands to the server, |
| 76 | + although that would only work if the server did not demand any |
| 77 | + authentication data. (However, a server relying on SSL certificate |
| 78 | + authentication might well not do so.) |
| 79 | + </para> |
| 80 | + |
| 81 | + <para> |
| 82 | + The <productname>PostgreSQL</productname> Project thanks |
| 83 | + Jacob Champion for reporting this problem. |
| 84 | + (CVE-2021-23214) |
| 85 | + </para> |
| 86 | + </listitem> |
| 87 | + |
| 88 | + <listitem> |
| 89 | +<!-- |
| 90 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 91 | +Branch: master [160c02588] 2021-11-08 11:14:56 -0500 |
| 92 | +Branch: REL_14_STABLE [30547d791] 2021-11-08 11:14:56 -0500 |
| 93 | +Branch: REL_13_STABLE [844b31692] 2021-11-08 11:14:56 -0500 |
| 94 | +Branch: REL_12_STABLE [36bb95ef2] 2021-11-08 11:14:56 -0500 |
| 95 | +Branch: REL_11_STABLE [a021a1d2a] 2021-11-08 11:14:56 -0500 |
| 96 | +Branch: REL_10_STABLE [e65d9c8cd] 2021-11-08 11:14:56 -0500 |
| 97 | +Branch: REL9_6_STABLE [d83cdfdca] 2021-11-08 11:14:57 -0500 |
| 98 | +--> |
| 99 | + <para> |
| 100 | + Make <application>libpq</application> reject extraneous data after |
| 101 | + an SSL or GSS encryption handshake (Tom Lane) |
| 102 | + </para> |
| 103 | + |
| 104 | + <para> |
| 105 | + A man-in-the-middle with the ability to inject data into the TCP |
| 106 | + connection could stuff some cleartext data into the start of a |
| 107 | + supposedly encryption-protected database session. |
| 108 | + This could probably be abused to inject faked responses to the |
| 109 | + client's first few queries, although other details of libpq's |
| 110 | + behavior make that harder than it sounds. A different line of |
| 111 | + attack is to exfiltrate the client's password, or other sensitive |
| 112 | + data that might be sent early in the session. That has been shown |
| 113 | + to be possible with a server vulnerable to CVE-2021-23214. |
| 114 | + </para> |
| 115 | + |
| 116 | + <para> |
| 117 | + The <productname>PostgreSQL</productname> Project thanks |
| 118 | + Jacob Champion for reporting this problem. |
| 119 | + (CVE-2021-23222) |
| 120 | + </para> |
| 121 | + </listitem> |
| 122 | + |
| 123 | + <listitem> |
| 124 | +<!-- |
57 | 125 | Author: Alvaro Herrera <alvherre@alvh.no-ip.org> |
58 | 126 | Branch: master [ff9f111bc] 2021-09-29 11:21:51 -0300 |
59 | 127 | Branch: REL_14_STABLE [64a8687a6] 2021-09-29 11:41:01 -0300 |
|