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