|
36 | 36 | <listitem> |
37 | 37 | <!-- |
38 | 38 | Author: Noah Misch <noah@leadboat.com> |
| 39 | +Branch: master [0c3185e96] 2020-11-09 07:32:09 -0800 |
| 40 | +Branch: REL_13_STABLE [c90c84b3f] 2020-11-09 07:32:12 -0800 |
| 41 | +Branch: REL_12_STABLE [ac8f6243c] 2020-11-09 07:32:12 -0800 |
| 42 | +Branch: REL_11_STABLE [43ebfea5a] 2020-11-09 07:32:13 -0800 |
| 43 | +Branch: REL_10_STABLE [f97ecea1e] 2020-11-09 07:32:13 -0800 |
| 44 | +Branch: REL9_6_STABLE [ff3de4c21] 2020-11-09 07:32:13 -0800 |
| 45 | +Branch: REL9_5_STABLE [aefc625de] 2020-11-09 07:32:14 -0800 |
| 46 | +--> |
| 47 | + <para> |
| 48 | + Block <command>DECLARE CURSOR ... WITH HOLD</command> and firing of |
| 49 | + deferred triggers within index expressions and materialized view |
| 50 | + queries (Noah Misch) |
| 51 | + </para> |
| 52 | + |
| 53 | + <para> |
| 54 | + This is essentially a leak in the <quote>security restricted |
| 55 | + operation</quote> sandbox mechanism. An attacker having permission |
| 56 | + to create non-temporary SQL objects could parlay this leak to |
| 57 | + execute arbitrary SQL code as a superuser. |
| 58 | + </para> |
| 59 | + |
| 60 | + <para> |
| 61 | + The <productname>PostgreSQL</productname> Project thanks |
| 62 | + Etienne Stalmans for reporting this problem. |
| 63 | + (CVE-2020-25695) |
| 64 | + </para> |
| 65 | + </listitem> |
| 66 | + |
| 67 | + <listitem> |
| 68 | +<!-- |
| 69 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 70 | +Branch: master [a45bc8a4f] 2020-09-24 18:19:38 -0400 |
| 71 | +Branch: REL_13_STABLE [cb8885ac4] 2020-09-24 18:19:38 -0400 |
| 72 | +Branch: REL_12_STABLE [fb93f784f] 2020-09-24 18:19:38 -0400 |
| 73 | +Branch: REL_11_STABLE [1738a61c8] 2020-09-24 18:19:39 -0400 |
| 74 | +Branch: REL_10_STABLE [1888ff8d0] 2020-09-24 18:19:39 -0400 |
| 75 | +Branch: REL9_6_STABLE [7c154f2fd] 2020-09-24 18:19:39 -0400 |
| 76 | +Branch: REL9_5_STABLE [56b46d3a1] 2020-09-24 18:19:39 -0400 |
| 77 | +Branch: master [8e5793ab6] 2020-10-19 19:03:46 -0400 |
| 78 | +Branch: REL_13_STABLE [1814f915b] 2020-10-19 19:03:46 -0400 |
| 79 | +Branch: REL_12_STABLE [c6d0b9b16] 2020-10-19 19:03:46 -0400 |
| 80 | +Branch: REL_11_STABLE [5a9f99bed] 2020-10-19 19:03:47 -0400 |
| 81 | +Branch: REL_10_STABLE [68f236993] 2020-10-19 19:03:47 -0400 |
| 82 | +Branch: REL9_6_STABLE [5c78f7977] 2020-10-19 19:03:47 -0400 |
| 83 | +Branch: REL9_5_STABLE [da129a04a] 2020-10-19 19:03:47 -0400 |
| 84 | +--> |
| 85 | + <para> |
| 86 | + Fix usage of complex connection-string parameters |
| 87 | + in <application>pg_dump</application>, |
| 88 | + <application>pg_restore</application>, |
| 89 | + <application>clusterdb</application>, |
| 90 | + <application>reindexdb</application>, |
| 91 | + and <application>vacuumdb</application> (Tom Lane) |
| 92 | + </para> |
| 93 | + |
| 94 | + <para> |
| 95 | + The <option>-d</option> parameter |
| 96 | + of <application>pg_dump</application> |
| 97 | + and <application>pg_restore</application>, or |
| 98 | + the <option>--maintenance-db</option> parameter of the other |
| 99 | + programs mentioned, can be a <quote>connection string</quote> |
| 100 | + containing multiple connection parameters rather than just a |
| 101 | + database name. In cases where these programs need to initiate |
| 102 | + additional connections, such as parallel processing or processing of |
| 103 | + multiple databases, the connection string was forgotten and just the |
| 104 | + basic connection parameters (database name, host, port, and |
| 105 | + username) were used for the additional connections. This could lead |
| 106 | + to connection failures if the connection string included any other |
| 107 | + essential information, such as non-default SSL or GSS parameters. |
| 108 | + Worse, the connection might succeed but not be encrypted as |
| 109 | + intended, or be vulnerable to man-in-the-middle attacks that the |
| 110 | + intended connection parameters would have prevented. |
| 111 | + (CVE-2020-25694) |
| 112 | + </para> |
| 113 | + </listitem> |
| 114 | + |
| 115 | + <listitem> |
| 116 | +<!-- |
| 117 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 118 | +Branch: master [85c54287a] 2020-10-21 16:19:00 -0400 |
| 119 | +Branch: REL_13_STABLE [2e4af4110] 2020-10-21 16:19:00 -0400 |
| 120 | +Branch: REL_12_STABLE [f656517ec] 2020-10-21 16:19:01 -0400 |
| 121 | +Branch: REL_11_STABLE [20be76d5c] 2020-10-21 16:19:01 -0400 |
| 122 | +Branch: REL_10_STABLE [8175da6e7] 2020-10-21 16:19:02 -0400 |
| 123 | +Branch: REL9_6_STABLE [870a23230] 2020-10-21 16:18:41 -0400 |
| 124 | +Branch: REL9_5_STABLE [6997da09a] 2020-10-21 16:18:41 -0400 |
| 125 | +--> |
| 126 | + <para> |
| 127 | + When <application>psql</application>'s <command>\connect</command> |
| 128 | + command re-uses connection parameters, ensure that all |
| 129 | + non-overridden parameters from a previous connection string are |
| 130 | + re-used (Tom Lane) |
| 131 | + </para> |
| 132 | + |
| 133 | + <para> |
| 134 | + This avoids cases where reconnection might fail due to omission of |
| 135 | + relevant parameters, such as non-default SSL or GSS options. |
| 136 | + Worse, the reconnection might succeed but not be encrypted as |
| 137 | + intended, or be vulnerable to man-in-the-middle attacks that the |
| 138 | + intended connection parameters would have prevented. |
| 139 | + This is largely the same problem as just cited |
| 140 | + for <application>pg_dump</application> et al, |
| 141 | + although <application>psql</application>'s behavior is more complex |
| 142 | + since the user may intentionally override some connection |
| 143 | + parameters. |
| 144 | + (CVE-2020-25694) |
| 145 | + </para> |
| 146 | + </listitem> |
| 147 | + |
| 148 | + <listitem> |
| 149 | +<!-- |
| 150 | +Author: Noah Misch <noah@leadboat.com> |
| 151 | +Branch: master [098fb0079] 2020-11-09 07:32:09 -0800 |
| 152 | +Branch: REL_13_STABLE [67029845b] 2020-11-09 07:32:12 -0800 |
| 153 | +Branch: REL_12_STABLE [3855e5b47] 2020-11-09 07:32:13 -0800 |
| 154 | +Branch: REL_11_STABLE [7b356c78f] 2020-11-09 07:32:13 -0800 |
| 155 | +Branch: REL_10_STABLE [a498db87b] 2020-11-09 07:32:13 -0800 |
| 156 | +Branch: REL9_6_STABLE [12fd81cb7] 2020-11-09 07:32:14 -0800 |
| 157 | +Branch: REL9_5_STABLE [a54dfbee1] 2020-11-09 07:32:14 -0800 |
| 158 | +--> |
| 159 | + <para> |
| 160 | + Prevent <application>psql</application>'s <command>\gset</command> |
| 161 | + command from modifying specially-treated variables (Noah Misch) |
| 162 | + </para> |
| 163 | + |
| 164 | + <para> |
| 165 | + <command>\gset</command> without a prefix would overwrite whatever |
| 166 | + variables the server told it to. Thus, a compromised server could |
| 167 | + set specially-treated variables such as <varname>PROMPT1</varname>, |
| 168 | + giving the ability to execute arbitrary shell code in the user's |
| 169 | + session. |
| 170 | + </para> |
| 171 | + |
| 172 | + <para> |
| 173 | + The <productname>PostgreSQL</productname> Project thanks |
| 174 | + Nick Cleaton for reporting this problem. |
| 175 | + (CVE-2020-25696) |
| 176 | + </para> |
| 177 | + </listitem> |
| 178 | + |
| 179 | + <listitem> |
| 180 | +<!-- |
| 181 | +Author: Noah Misch <noah@leadboat.com> |
39 | 182 | Branch: master [566372b3d] 2020-08-15 10:15:53 -0700 |
40 | 183 | Branch: REL_13_STABLE Release: REL_13_0 [592a589a0] 2020-08-15 10:15:56 -0700 |
41 | 184 | Branch: REL_12_STABLE [30e68a2ab] 2020-08-15 10:15:56 -0700 |
@@ -969,79 +1112,6 @@ Branch: REL9_5_STABLE [aff06436c] 2020-10-28 14:35:53 -0400 |
969 | 1112 |
|
970 | 1113 | <listitem> |
971 | 1114 | <!-- |
972 | | -Author: Tom Lane <tgl@sss.pgh.pa.us> |
973 | | -Branch: master [a45bc8a4f] 2020-09-24 18:19:38 -0400 |
974 | | -Branch: REL_13_STABLE [cb8885ac4] 2020-09-24 18:19:38 -0400 |
975 | | -Branch: REL_12_STABLE [fb93f784f] 2020-09-24 18:19:38 -0400 |
976 | | -Branch: REL_11_STABLE [1738a61c8] 2020-09-24 18:19:39 -0400 |
977 | | -Branch: REL_10_STABLE [1888ff8d0] 2020-09-24 18:19:39 -0400 |
978 | | -Branch: REL9_6_STABLE [7c154f2fd] 2020-09-24 18:19:39 -0400 |
979 | | -Branch: REL9_5_STABLE [56b46d3a1] 2020-09-24 18:19:39 -0400 |
980 | | -Branch: master [8e5793ab6] 2020-10-19 19:03:46 -0400 |
981 | | -Branch: REL_13_STABLE [1814f915b] 2020-10-19 19:03:46 -0400 |
982 | | -Branch: REL_12_STABLE [c6d0b9b16] 2020-10-19 19:03:46 -0400 |
983 | | -Branch: REL_11_STABLE [5a9f99bed] 2020-10-19 19:03:47 -0400 |
984 | | -Branch: REL_10_STABLE [68f236993] 2020-10-19 19:03:47 -0400 |
985 | | -Branch: REL9_6_STABLE [5c78f7977] 2020-10-19 19:03:47 -0400 |
986 | | -Branch: REL9_5_STABLE [da129a04a] 2020-10-19 19:03:47 -0400 |
987 | | ---> |
988 | | - <para> |
989 | | - Fix usage of complex connection-string parameters |
990 | | - in <application>pg_dump</application>, |
991 | | - <application>pg_restore</application>, |
992 | | - <application>clusterdb</application>, |
993 | | - <application>reindexdb</application>, |
994 | | - and <application>vacuumdb</application> (Tom Lane) |
995 | | - </para> |
996 | | - |
997 | | - <para> |
998 | | - The <option>-d</option> parameter |
999 | | - of <application>pg_dump</application> |
1000 | | - and <application>pg_restore</application>, or |
1001 | | - the <option>--maintenance-db</option> parameter of the other |
1002 | | - programs mentioned, can be a <quote>connection string</quote> |
1003 | | - containing multiple connection parameters rather than just a |
1004 | | - database name. In cases where these programs need to initiate |
1005 | | - additional connections, such as parallel processing or processing of |
1006 | | - multiple databases, the connection string was forgotten and just the |
1007 | | - basic connection parameters (database name, host, port, and |
1008 | | - username) were used for the additional connections. This could lead |
1009 | | - to connection failures if the connection string included any other |
1010 | | - essential information, such as non-default SSL or GSS parameters. |
1011 | | - </para> |
1012 | | - </listitem> |
1013 | | - |
1014 | | - <listitem> |
1015 | | -<!-- |
1016 | | -Author: Tom Lane <tgl@sss.pgh.pa.us> |
1017 | | -Branch: master [85c54287a] 2020-10-21 16:19:00 -0400 |
1018 | | -Branch: REL_13_STABLE [2e4af4110] 2020-10-21 16:19:00 -0400 |
1019 | | -Branch: REL_12_STABLE [f656517ec] 2020-10-21 16:19:01 -0400 |
1020 | | -Branch: REL_11_STABLE [20be76d5c] 2020-10-21 16:19:01 -0400 |
1021 | | -Branch: REL_10_STABLE [8175da6e7] 2020-10-21 16:19:02 -0400 |
1022 | | -Branch: REL9_6_STABLE [870a23230] 2020-10-21 16:18:41 -0400 |
1023 | | -Branch: REL9_5_STABLE [6997da09a] 2020-10-21 16:18:41 -0400 |
1024 | | ---> |
1025 | | - <para> |
1026 | | - When <application>psql</application>'s <command>\connect</command> |
1027 | | - command re-uses connection parameters, ensure that all |
1028 | | - non-overridden parameters from a previous connection string are |
1029 | | - re-used (Tom Lane) |
1030 | | - </para> |
1031 | | - |
1032 | | - <para> |
1033 | | - This avoids cases where reconnection might fail due to omission of |
1034 | | - relevant parameters, such as non-default SSL or GSS options. This |
1035 | | - is largely the same problem as just cited |
1036 | | - for <application>pg_dump</application> et al, |
1037 | | - although <application>psql</application>'s behavior is more complex |
1038 | | - since the user may intentionally override some connection |
1039 | | - parameters. |
1040 | | - </para> |
1041 | | - </listitem> |
1042 | | - |
1043 | | - <listitem> |
1044 | | -<!-- |
1045 | 1115 | Author: Andrew Dunstan <andrew@dunslane.net> |
1046 | 1116 | Branch: master [3eb3d3e78] 2020-09-04 13:54:54 -0400 |
1047 | 1117 | Branch: REL_13_STABLE Release: REL_13_0 [72857482c] 2020-09-04 13:55:11 -0400 |
|