|
41 | 41 |
|
42 | 42 | <listitem> |
43 | 43 | <!-- |
| 44 | +Author: Nathan Bossart <nathan@postgresql.org> |
| 45 | +Branch: master [cd7ab5753] 2024-11-11 09:00:00 -0600 |
| 46 | +Branch: REL_17_STABLE [edcda9bb4] 2024-11-11 09:00:00 -0600 |
| 47 | +Branch: REL_16_STABLE [562289460] 2024-11-11 09:00:00 -0600 |
| 48 | +Branch: REL_15_STABLE [6db5ea8de] 2024-11-11 09:00:00 -0600 |
| 49 | +Branch: REL_14_STABLE [4e51030af] 2024-11-11 09:00:00 -0600 |
| 50 | +Branch: REL_13_STABLE [952ff31e2] 2024-11-11 09:00:00 -0600 |
| 51 | +Branch: REL_12_STABLE [448525e8a] 2024-11-11 09:00:00 -0600 |
| 52 | +--> |
| 53 | + <para> |
| 54 | + Ensure cached plans are marked as dependent on the calling role when |
| 55 | + RLS applies to a non-top-level table reference (Nathan Bossart) |
| 56 | + <ulink url="&commit_baseurl;448525e8a">§</ulink> |
| 57 | + </para> |
| 58 | + |
| 59 | + <para> |
| 60 | + If a CTE, subquery, sublink, security invoker view, or coercion |
| 61 | + projection in a query references a table with row-level security |
| 62 | + policies, we neglected to mark the resulting plan as potentially |
| 63 | + dependent on which role is executing it. This could lead to later |
| 64 | + query executions in the same session using the wrong plan, and then |
| 65 | + returning or hiding rows that should have been hidden or returned |
| 66 | + instead. |
| 67 | + </para> |
| 68 | + |
| 69 | + <para> |
| 70 | + The <productname>PostgreSQL</productname> Project thanks |
| 71 | + Wolfgang Walther for reporting this problem. |
| 72 | + (CVE-2024-10976) |
| 73 | + </para> |
| 74 | + </listitem> |
| 75 | + |
| 76 | + <listitem> |
| 77 | +<!-- |
| 78 | +Author: Michael Paquier <michael@paquier.xyz> |
| 79 | +Branch: master [bf8835ea9] 2024-11-11 10:19:52 +0900 |
| 80 | +Branch: REL_17_STABLE [a5cc4c667] 2024-11-11 10:19:56 +0900 |
| 81 | +Branch: REL_16_STABLE [67d28bd02] 2024-11-11 10:19:58 +0900 |
| 82 | +Branch: REL_15_STABLE [d2c3e31c1] 2024-11-11 10:19:59 +0900 |
| 83 | +Branch: REL_14_STABLE [e6c945476] 2024-11-11 10:20:01 +0900 |
| 84 | +Branch: REL_13_STABLE [7b49707b7] 2024-11-11 10:20:02 +0900 |
| 85 | +Branch: REL_12_STABLE [2a951ef0a] 2024-11-11 10:20:03 +0900 |
| 86 | +--> |
| 87 | + <para> |
| 88 | + Make <application>libpq</application> discard error messages |
| 89 | + received during SSL or GSS protocol negotiation (Jacob Champion) |
| 90 | + <ulink url="&commit_baseurl;2a951ef0a">§</ulink> |
| 91 | + </para> |
| 92 | + |
| 93 | + <para> |
| 94 | + An error message received before encryption negotiation is completed |
| 95 | + might have been injected by a man-in-the-middle, rather than being |
| 96 | + real server output. Reporting it opens the door to various security |
| 97 | + hazards; for example, the message might spoof a query result that a |
| 98 | + careless user could mistake for correct output. The best answer |
| 99 | + seems to be to discard such data and rely only |
| 100 | + on <application>libpq</application>'s own report of the connection |
| 101 | + failure. |
| 102 | + </para> |
| 103 | + |
| 104 | + <para> |
| 105 | + The <productname>PostgreSQL</productname> Project thanks |
| 106 | + Jacob Champion for reporting this problem. |
| 107 | + (CVE-2024-10977) |
| 108 | + </para> |
| 109 | + </listitem> |
| 110 | + |
| 111 | + <listitem> |
| 112 | +<!-- |
| 113 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 114 | +Branch: master [5a2fed911] 2024-11-11 10:29:54 -0500 |
| 115 | +Branch: REL_17_STABLE [cd82afdda] 2024-11-11 10:29:54 -0500 |
| 116 | +Branch: REL_16_STABLE [ae340d031] 2024-11-11 10:29:54 -0500 |
| 117 | +Branch: REL_15_STABLE [a5d2e6205] 2024-11-11 10:29:54 -0500 |
| 118 | +Branch: REL_14_STABLE [2a68808e2] 2024-11-11 10:29:54 -0500 |
| 119 | +Branch: REL_13_STABLE [76123ded6] 2024-11-11 10:29:54 -0500 |
| 120 | +Branch: REL_12_STABLE [4c9d96f74] 2024-11-11 10:29:54 -0500 |
| 121 | +Branch: master [73c9f91a1] 2024-11-11 17:05:53 -0500 |
| 122 | +Branch: REL_17_STABLE [f4f5d27d8] 2024-11-11 17:05:53 -0500 |
| 123 | +Branch: REL_16_STABLE [95f5a5237] 2024-11-11 17:05:53 -0500 |
| 124 | +Branch: REL_15_STABLE [109a32380] 2024-11-11 17:05:53 -0500 |
| 125 | +Branch: REL_14_STABLE [00b94e8e2] 2024-11-11 17:05:53 -0500 |
| 126 | +Branch: REL_13_STABLE [dc7378793] 2024-11-11 17:05:53 -0500 |
| 127 | +Branch: REL_12_STABLE [0edad8654] 2024-11-11 17:05:53 -0500 |
| 128 | +--> |
| 129 | + <para> |
| 130 | + Fix unintended interactions between <command>SET SESSION |
| 131 | + AUTHORIZATION</command> and <command>SET ROLE</command> (Tom Lane) |
| 132 | + <ulink url="&commit_baseurl;4c9d96f74">§</ulink> |
| 133 | + <ulink url="&commit_baseurl;0edad8654">§</ulink> |
| 134 | + </para> |
| 135 | + |
| 136 | + <para> |
| 137 | + The SQL standard mandates that <command>SET SESSION |
| 138 | + AUTHORIZATION</command> have a side-effect of doing <command>SET |
| 139 | + ROLE NONE</command>. Our implementation of that was flawed, |
| 140 | + creating more interaction between the two settings than intended. |
| 141 | + Notably, rolling back a transaction that had done <command>SET |
| 142 | + SESSION AUTHORIZATION</command> would revert <literal>ROLE</literal> |
| 143 | + to <literal>NONE</literal> even if that had not been the previous |
| 144 | + state, so that the effective user ID might now be different from |
| 145 | + what it had been before the transaction. Transiently |
| 146 | + setting <varname>session_authorization</varname> in a |
| 147 | + function <literal>SET</literal> clause had a similar effect. |
| 148 | + A related bug was that if a parallel worker |
| 149 | + inspected <literal>current_setting('role')</literal>, it |
| 150 | + saw <literal>none</literal> even when it should see something else. |
| 151 | + </para> |
| 152 | + |
| 153 | + <para> |
| 154 | + The <productname>PostgreSQL</productname> Project thanks |
| 155 | + Tom Lane for reporting this problem. |
| 156 | + (CVE-2024-10978) |
| 157 | + </para> |
| 158 | + </listitem> |
| 159 | + |
| 160 | + <listitem> |
| 161 | +<!-- |
| 162 | +Author: Noah Misch <noah@leadboat.com> |
| 163 | +Branch: master [b7e3a52a8] 2024-11-11 06:23:43 -0800 |
| 164 | +Branch: REL_17_STABLE [3ebcfa54d] 2024-11-11 06:23:46 -0800 |
| 165 | +Branch: REL_16_STABLE [8fe3e697a] 2024-11-11 06:23:47 -0800 |
| 166 | +Branch: REL_15_STABLE [e530835c6] 2024-11-11 06:23:47 -0800 |
| 167 | +Branch: REL_14_STABLE [d15ec27c9] 2024-11-11 06:23:47 -0800 |
| 168 | +Branch: REL_13_STABLE [e428cd058] 2024-11-11 06:23:48 -0800 |
| 169 | +Branch: REL_12_STABLE [2ab12d860] 2024-11-11 06:23:48 -0800 |
| 170 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 171 | +Branch: REL_14_STABLE [f89bd92c9] 2024-11-11 10:42:32 -0500 |
| 172 | +Branch: REL_13_STABLE [6bccd7b03] 2024-11-11 10:42:32 -0500 |
| 173 | +Branch: REL_12_STABLE [b1e58defb] 2024-11-11 10:42:32 -0500 |
| 174 | +Branch: master [a34c33fd2] 2024-11-11 12:20:08 -0500 |
| 175 | +Branch: REL_17_STABLE [4cd4f3b97] 2024-11-11 12:20:08 -0500 |
| 176 | +Branch: REL_16_STABLE [88269df4d] 2024-11-11 12:20:08 -0500 |
| 177 | +Branch: REL_16_STABLE [168579e23] 2024-11-11 12:27:06 -0500 |
| 178 | +Author: Noah Misch <noah@leadboat.com> |
| 179 | +Branch: REL_16_STABLE [c335264c9] 2024-11-11 10:55:18 -0800 |
| 180 | +Branch: REL_15_STABLE [16ed4f4d0] 2024-11-11 10:56:05 -0800 |
| 181 | +Branch: REL_14_STABLE [c1fff7b1b] 2024-11-11 10:56:09 -0800 |
| 182 | +Branch: REL_13_STABLE [9f97c31c2] 2024-11-11 10:56:12 -0800 |
| 183 | +Branch: REL_12_STABLE [1e457468f] 2024-11-11 10:56:14 -0800 |
| 184 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 185 | +Branch: master [c4252c9ef] 2024-11-11 13:57:21 -0500 |
| 186 | +Branch: REL_17_STABLE [8d19f3fea] 2024-11-11 13:57:21 -0500 |
| 187 | +Branch: REL_16_STABLE [64df88700] 2024-11-11 13:57:40 -0500 |
| 188 | +Branch: REL_15_STABLE [c834b375a] 2024-11-11 13:57:41 -0500 |
| 189 | +Branch: REL_14_STABLE [256e34653] 2024-11-11 13:57:41 -0500 |
| 190 | +Branch: REL_13_STABLE [0bd9560d9] 2024-11-11 13:57:41 -0500 |
| 191 | +Branch: REL_12_STABLE [9fc1c3a02] 2024-11-11 13:57:41 -0500 |
| 192 | +--> |
| 193 | + <para> |
| 194 | + Prevent trusted PL/Perl code from changing environment variables |
| 195 | + (Andrew Dunstan, Noah Misch) |
| 196 | + <ulink url="&commit_baseurl;2ab12d860">§</ulink> |
| 197 | + <ulink url="&commit_baseurl;b1e58defb">§</ulink> |
| 198 | + <ulink url="&commit_baseurl;1e457468f">§</ulink> |
| 199 | + <ulink url="&commit_baseurl;9fc1c3a02">§</ulink> |
| 200 | + </para> |
| 201 | + |
| 202 | + <para> |
| 203 | + The ability to manipulate process environment variables such |
| 204 | + as <literal>PATH</literal> gives an attacker opportunities to |
| 205 | + execute arbitrary code. Therefore, <quote>trusted</quote> PLs must |
| 206 | + not offer the ability to do that. To fix <literal>plperl</literal>, |
| 207 | + replace <varname>%ENV</varname> with a tied hash that rejects any |
| 208 | + modification attempt with a warning. |
| 209 | + Untrusted <literal>plperlu</literal> retains the ability to change |
| 210 | + the environment. |
| 211 | + </para> |
| 212 | + |
| 213 | + <para> |
| 214 | + The <productname>PostgreSQL</productname> Project thanks |
| 215 | + Coby Abrams for reporting this problem. |
| 216 | + (CVE-2024-10979) |
| 217 | + </para> |
| 218 | + </listitem> |
| 219 | + |
| 220 | + <listitem> |
| 221 | +<!-- |
44 | 222 | Author: Álvaro Herrera <alvherre@alvh.no-ip.org> |
45 | 223 | Branch: master [a90bdd7a4] 2024-08-08 19:35:13 -0400 |
46 | 224 | Branch: REL_17_STABLE Release: REL_17_0 [344f9f5e2] 2024-08-08 19:35:13 -0400 |
|