|
35 | 35 |
|
36 | 36 | <listitem> |
37 | 37 | <!-- |
| 38 | +Author: Andres Freund <andres@anarazel.de> |
| 39 | +Branch: master [5dc1e42b4] 2025-02-10 10:03:37 -0500 |
| 40 | +Branch: REL_17_STABLE [43a77239d] 2025-02-10 10:03:38 -0500 |
| 41 | +Branch: REL_16_STABLE [92e4170f4] 2025-02-10 10:03:39 -0500 |
| 42 | +Branch: REL_15_STABLE [370c94d4c] 2025-02-10 10:03:39 -0500 |
| 43 | +Branch: REL_14_STABLE [e0ef3d776] 2025-02-10 10:03:40 -0500 |
| 44 | +Branch: REL_13_STABLE [c906bfe1b] 2025-02-10 10:03:40 -0500 |
| 45 | +Branch: master [4dc289635] 2025-02-10 10:03:37 -0500 |
| 46 | +Branch: REL_17_STABLE [7d43ca6fe] 2025-02-10 10:03:38 -0500 |
| 47 | +Branch: REL_16_STABLE [6e05b195d] 2025-02-10 10:03:39 -0500 |
| 48 | +Branch: REL_15_STABLE [703b3fd5d] 2025-02-10 10:03:39 -0500 |
| 49 | +Branch: REL_14_STABLE [5bc33cbea] 2025-02-10 10:03:40 -0500 |
| 50 | +Branch: REL_13_STABLE [db3eb0e82] 2025-02-10 10:03:40 -0500 |
| 51 | +Branch: master [3e98c8ce5] 2025-02-10 10:03:37 -0500 |
| 52 | +Branch: REL_17_STABLE [61ad93cdd] 2025-02-10 10:03:38 -0500 |
| 53 | +Branch: REL_16_STABLE [56aa2dcdd] 2025-02-10 10:03:39 -0500 |
| 54 | +Branch: REL_15_STABLE [b1756da75] 2025-02-10 10:03:39 -0500 |
| 55 | +Branch: REL_14_STABLE [2ae54ae17] 2025-02-10 10:03:40 -0500 |
| 56 | +Branch: REL_13_STABLE [5df4e1632] 2025-02-10 10:03:40 -0500 |
| 57 | +Branch: master [ac00ff1c9] 2025-02-10 10:03:37 -0500 |
| 58 | +Branch: REL_17_STABLE [02d4d87ac] 2025-02-10 10:03:38 -0500 |
| 59 | +Branch: REL_16_STABLE [01784793f] 2025-02-10 10:03:39 -0500 |
| 60 | +Branch: REL_15_STABLE [de4b92f33] 2025-02-10 10:03:39 -0500 |
| 61 | +Branch: REL_14_STABLE [46ddf98df] 2025-02-10 10:03:40 -0500 |
| 62 | +Branch: REL_13_STABLE [4ea3f5ef3] 2025-02-10 10:03:40 -0500 |
| 63 | +Branch: master [979205e47] 2025-02-10 12:12:14 -0500 |
| 64 | +Branch: REL_17_STABLE [05abb0f83] 2025-02-10 12:12:53 -0500 |
| 65 | +Branch: REL_16_STABLE [41343f840] 2025-02-10 12:12:56 -0500 |
| 66 | +Branch: REL_15_STABLE [a085fa731] 2025-02-10 12:12:58 -0500 |
| 67 | +Branch: REL_14_STABLE [4a6825c76] 2025-02-10 12:12:59 -0500 |
| 68 | +Branch: REL_13_STABLE [7beb2af5e] 2025-02-10 12:13:02 -0500 |
| 69 | +Branch: REL_13_STABLE [00f1a1f66] 2025-02-10 10:03:40 -0500 |
| 70 | +Author: Tom Lane <tgl@sss.pgh.pa.us> |
| 71 | +Branch: master [5bf12323b] 2025-02-10 16:30:03 -0500 |
| 72 | +Branch: REL_17_STABLE [85c1fcc65] 2025-02-10 16:30:31 -0500 |
| 73 | +Branch: REL_16_STABLE [0075a5c6c] 2025-02-10 16:30:37 -0500 |
| 74 | +Branch: REL_15_STABLE [9862de917] 2025-02-10 16:30:54 -0500 |
| 75 | +Branch: REL_14_STABLE [e1f1b030d] 2025-02-10 16:31:01 -0500 |
| 76 | +Branch: REL_13_STABLE [f9fceef6e] 2025-02-10 16:31:09 -0500 |
| 77 | +--> |
| 78 | + <para> |
| 79 | + Harden <function>PQescapeString</function> and allied functions |
| 80 | + against invalidly-encoded input strings (Andres Freund, Noah Misch) |
| 81 | + <ulink url="&commit_baseurl;370c94d4c">§</ulink> |
| 82 | + <ulink url="&commit_baseurl;703b3fd5d">§</ulink> |
| 83 | + <ulink url="&commit_baseurl;b1756da75">§</ulink> |
| 84 | + <ulink url="&commit_baseurl;de4b92f33">§</ulink> |
| 85 | + <ulink url="&commit_baseurl;a085fa731">§</ulink> |
| 86 | + <ulink url="&commit_baseurl;9862de917">§</ulink> |
| 87 | + </para> |
| 88 | + |
| 89 | + <para> |
| 90 | + Data-quoting functions supplied by <application>libpq</application> |
| 91 | + now fully check the encoding validity of their input. If invalid |
| 92 | + characters are detected, they report an error if possible. For the |
| 93 | + ones that lack an error return convention, the output string is |
| 94 | + adjusted to ensure that the server will report invalid encoding and |
| 95 | + no intervening processing will be fooled by bytes that might happen |
| 96 | + to match single quote, backslash, etc. |
| 97 | + </para> |
| 98 | + |
| 99 | + <para> |
| 100 | + The purpose of this change is to guard against SQL-injection attacks |
| 101 | + that are possible if one of these functions is used to quote crafted |
| 102 | + input. There is no hazard when the resulting string is sent |
| 103 | + directly to a <productname>PostgreSQL</productname> server (which |
| 104 | + would check its encoding anyway), but there is a risk when it is |
| 105 | + passed through <application>psql</application> or other client-side |
| 106 | + code. Historically such code has not carefully vetted encoding, and |
| 107 | + in many cases it's not clear what it should do if it did detect such |
| 108 | + a problem. |
| 109 | + </para> |
| 110 | + |
| 111 | + <para> |
| 112 | + This fix is effective only if the data-quoting function, the server, |
| 113 | + and any intermediate processing agree on the character encoding |
| 114 | + that's being used. Applications that insert untrusted input into |
| 115 | + SQL commands should take special care to ensure that that's true. |
| 116 | + </para> |
| 117 | + |
| 118 | + <para> |
| 119 | + Applications and drivers that quote untrusted input without using |
| 120 | + these <application>libpq</application> functions may be at risk of |
| 121 | + similar problems. They should first confirm the data is valid in |
| 122 | + the encoding expected by the server. |
| 123 | + </para> |
| 124 | + |
| 125 | + <para> |
| 126 | + The <productname>PostgreSQL</productname> Project thanks |
| 127 | + Stephen Fewer for reporting this problem. |
| 128 | + (CVE-2025-1094) |
| 129 | + </para> |
| 130 | + </listitem> |
| 131 | + |
| 132 | + <listitem> |
| 133 | +<!-- |
38 | 134 | Author: Tom Lane <tgl@sss.pgh.pa.us> |
39 | 135 | Branch: master [34486b609] 2024-12-28 16:08:50 -0500 |
40 | 136 | Branch: REL_17_STABLE [15b4c46c3] 2024-12-28 16:08:50 -0500 |
|