diff --git a/CVE-2021-23214.patch b/CVE-2021-23214.patch deleted file mode 100644 index 318c20132efd7583c20e7c3d6414223df56da572..0000000000000000000000000000000000000000 --- a/CVE-2021-23214.patch +++ /dev/null @@ -1,108 +0,0 @@ -From e92ed93e8eb76ee0701b42d4f0ce94e6af3fc741 Mon Sep 17 00:00:00 2001 -From: Tom Lane -Date: Mon, 8 Nov 2021 11:01:43 -0500 -Subject: [PATCH] Reject extraneous data after SSL or GSS encryption handshake. - -The server collects up to a bufferload of data whenever it reads data -from the client socket. When SSL or GSS encryption is requested -during startup, any additional data received with the initial -request message remained in the buffer, and would be treated as -already-decrypted data once the encryption handshake completed. -Thus, a man-in-the-middle with the ability to inject data into the -TCP connection could stuff some cleartext data into the start of -a supposedly encryption-protected database session. - -This could be abused to send faked SQL commands to the server, -although that would only work if the server did not demand any -authentication data. (However, a server relying on SSL certificate -authentication might well not do so.) - -To fix, throw a protocol-violation error if the internal buffer -is not empty after the encryption handshake. - -Our thanks to Jacob Champion for reporting this problem. - -Security: CVE-2021-23214 ---- - src/backend/libpq/pqcomm.c | 12 ++++++++++++ - src/backend/postmaster/postmaster.c | 24 ++++++++++++++++++++++++ - src/include/libpq/libpq.h | 1 + - 3 files changed, 37 insertions(+) - -diff --git a/src/backend/libpq/pqcomm.c b/src/backend/libpq/pqcomm.c -index ee2cd86866da..93f2e0b81d32 100644 ---- a/src/backend/libpq/pqcomm.c -+++ b/src/backend/libpq/pqcomm.c -@@ -1183,6 +1183,18 @@ pq_getstring(StringInfo s) - } - } - -+/* -------------------------------- -+ * pq_buffer_has_data - is any buffered data available to read? -+ * -+ * This will *not* attempt to read more data. -+ * -------------------------------- -+ */ -+bool -+pq_buffer_has_data(void) -+{ -+ return (PqRecvPointer < PqRecvLength); -+} -+ - - /* -------------------------------- - * pq_startmsgread - begin reading a message from the client. -diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c -index 5775fc0c0910..1e0936e5b482 100644 ---- a/src/backend/postmaster/postmaster.c -+++ b/src/backend/postmaster/postmaster.c -@@ -2049,6 +2049,18 @@ ProcessStartupPacket(Port *port, bool ssl_done, bool gss_done) - return STATUS_ERROR; - #endif - -+ /* -+ * At this point we should have no data already buffered. If we do, -+ * it was received before we performed the SSL handshake, so it wasn't -+ * encrypted and indeed may have been injected by a man-in-the-middle. -+ * We report this case to the client. -+ */ -+ if (pq_buffer_has_data()) -+ ereport(FATAL, -+ (errcode(ERRCODE_PROTOCOL_VIOLATION), -+ errmsg("received unencrypted data after SSL request"), -+ errdetail("This could be either a client-software bug or evidence of an attempted man-in-the-middle attack."))); -+ - /* - * regular startup packet, cancel, etc packet should follow, but not - * another SSL negotiation request, and a GSS request should only -@@ -2081,6 +2093,18 @@ ProcessStartupPacket(Port *port, bool ssl_done, bool gss_done) - return STATUS_ERROR; - #endif - -+ /* -+ * At this point we should have no data already buffered. If we do, -+ * it was received before we performed the GSS handshake, so it wasn't -+ * encrypted and indeed may have been injected by a man-in-the-middle. -+ * We report this case to the client. -+ */ -+ if (pq_buffer_has_data()) -+ ereport(FATAL, -+ (errcode(ERRCODE_PROTOCOL_VIOLATION), -+ errmsg("received unencrypted data after GSSAPI encryption request"), -+ errdetail("This could be either a client-software bug or evidence of an attempted man-in-the-middle attack."))); -+ - /* - * regular startup packet, cancel, etc packet should follow, but not - * another GSS negotiation request, and an SSL request should only -diff --git a/src/include/libpq/libpq.h b/src/include/libpq/libpq.h -index b1152475ace5..54c5fa779773 100644 ---- a/src/include/libpq/libpq.h -+++ b/src/include/libpq/libpq.h -@@ -72,6 +72,7 @@ extern int pq_getmessage(StringInfo s, int maxlen); - extern int pq_getbyte(void); - extern int pq_peekbyte(void); - extern int pq_getbyte_if_available(unsigned char *c); -+extern bool pq_buffer_has_data(void); - extern int pq_putbytes(const char *s, size_t len); - - /* diff --git a/CVE-2021-23222.patch b/CVE-2021-23222.patch deleted file mode 100644 index 0bd5ada95e7e5d55ff31c95837218655acb49754..0000000000000000000000000000000000000000 --- a/CVE-2021-23222.patch +++ /dev/null @@ -1,123 +0,0 @@ -From 844b3169204c28cd086c1b4fae4a2cbdd0540640 Mon Sep 17 00:00:00 2001 -From: Tom Lane -Date: Mon, 8 Nov 2021 11:14:56 -0500 -Subject: [PATCH] libpq: reject extraneous data after SSL or GSS encryption - handshake. - -libpq collects up to a bufferload of data whenever it reads data from -the socket. When SSL or GSS encryption is requested during startup, -any additional data received with the server's yes-or-no reply -remained in the buffer, and would be treated as already-decrypted data -once the encryption handshake completed. Thus, a man-in-the-middle -with the ability to inject data into the TCP connection could stuff -some cleartext data into the start of a supposedly encryption-protected -database session. - -This could probably be abused to inject faked responses to the -client's first few queries, although other details of libpq's behavior -make that harder than it sounds. A different line of attack is to -exfiltrate the client's password, or other sensitive data that might -be sent early in the session. That has been shown to be possible with -a server vulnerable to CVE-2021-23214. - -To fix, throw a protocol-violation error if the internal buffer -is not empty after the encryption handshake. - -Our thanks to Jacob Champion for reporting this problem. - -Security: CVE-2021-23222 ---- - doc/src/sgml/protocol.sgml | 28 ++++++++++++++++++++++++++++ - src/interfaces/libpq/fe-connect.c | 26 ++++++++++++++++++++++++++ - 2 files changed, 54 insertions(+) - -diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml -index e26619e1b53d..b692648fca47 100644 ---- a/doc/src/sgml/protocol.sgml -+++ b/doc/src/sgml/protocol.sgml -@@ -1471,6 +1471,20 @@ SELCT 1/0; - and proceed without requesting SSL. - - -+ -+ When SSL encryption can be performed, the server -+ is expected to send only the single S byte and then -+ wait for the frontend to initiate an SSL handshake. -+ If additional bytes are available to read at this point, it likely -+ means that a man-in-the-middle is attempting to perform a -+ buffer-stuffing attack -+ (CVE-2021-23222). -+ Frontends should be coded either to read exactly one byte from the -+ socket before turning the socket over to their SSL library, or to -+ treat it as a protocol violation if they find they have read additional -+ bytes. -+ -+ - - An initial SSLRequest can also be used in a connection that is being - opened to send a CancelRequest message. -@@ -1532,6 +1546,20 @@ SELCT 1/0; - encryption. - - -+ -+ When GSSAPI encryption can be performed, the server -+ is expected to send only the single G byte and then -+ wait for the frontend to initiate a GSSAPI handshake. -+ If additional bytes are available to read at this point, it likely -+ means that a man-in-the-middle is attempting to perform a -+ buffer-stuffing attack -+ (CVE-2021-23222). -+ Frontends should be coded either to read exactly one byte from the -+ socket before turning the socket over to their GSSAPI library, or to -+ treat it as a protocol violation if they find they have read additional -+ bytes. -+ -+ - - An initial GSSENCRequest can also be used in a connection that is being - opened to send a CancelRequest message. -diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c -index f80f4e98d8e0..57aee9518308 100644 ---- a/src/interfaces/libpq/fe-connect.c -+++ b/src/interfaces/libpq/fe-connect.c -@@ -3076,6 +3076,19 @@ PQconnectPoll(PGconn *conn) - pollres = pqsecure_open_client(conn); - if (pollres == PGRES_POLLING_OK) - { -+ /* -+ * At this point we should have no data already buffered. -+ * If we do, it was received before we performed the SSL -+ * handshake, so it wasn't encrypted and indeed may have -+ * been injected by a man-in-the-middle. -+ */ -+ if (conn->inCursor != conn->inEnd) -+ { -+ appendPQExpBufferStr(&conn->errorMessage, -+ libpq_gettext("received unencrypted data after SSL response\n")); -+ goto error_return; -+ } -+ - /* SSL handshake done, ready to send startup packet */ - conn->status = CONNECTION_MADE; - return PGRES_POLLING_WRITING; -@@ -3175,6 +3188,19 @@ PQconnectPoll(PGconn *conn) - pollres = pqsecure_open_gss(conn); - if (pollres == PGRES_POLLING_OK) - { -+ /* -+ * At this point we should have no data already buffered. -+ * If we do, it was received before we performed the GSS -+ * handshake, so it wasn't encrypted and indeed may have -+ * been injected by a man-in-the-middle. -+ */ -+ if (conn->inCursor != conn->inEnd) -+ { -+ appendPQExpBufferStr(&conn->errorMessage, -+ libpq_gettext("received unencrypted data after GSSAPI encryption response\n")); -+ goto error_return; -+ } -+ - /* All set for startup packet */ - conn->status = CONNECTION_MADE; - return PGRES_POLLING_WRITING; diff --git a/postgresql-13.3-US.pdf b/postgresql-13.11-US.pdf similarity index 69% rename from postgresql-13.3-US.pdf rename to postgresql-13.11-US.pdf index 542844ef03da4dc9cb1a4b9393c7fb783772e43c..45887b5be98aaf5580d346893330dd974c1220f3 100644 Binary files a/postgresql-13.3-US.pdf and b/postgresql-13.11-US.pdf differ diff --git a/postgresql-13.3.tar.bz2 b/postgresql-13.11.tar.bz2 similarity index 68% rename from postgresql-13.3.tar.bz2 rename to postgresql-13.11.tar.bz2 index cd1774994fa0062d5650b2418ccf64c4e998c90e..3b4865e9f01d82d96a54119825106504f7df8114 100644 Binary files a/postgresql-13.3.tar.bz2 and b/postgresql-13.11.tar.bz2 differ diff --git a/postgresql-13.11.tar.bz2.sha256 b/postgresql-13.11.tar.bz2.sha256 new file mode 100644 index 0000000000000000000000000000000000000000..c5f9baf814fdf93372f947ffff1499ec03e03b1f --- /dev/null +++ b/postgresql-13.11.tar.bz2.sha256 @@ -0,0 +1 @@ +4992ff647203566b670d4e54dc5317499a26856c93576d0ea951bdf6bee50bfb postgresql-13.11.tar.bz2 diff --git a/postgresql-13.3.tar.bz2.sha256 b/postgresql-13.3.tar.bz2.sha256 deleted file mode 100644 index 7898d34af591ae255a822e5d7fe86f61fad94682..0000000000000000000000000000000000000000 --- a/postgresql-13.3.tar.bz2.sha256 +++ /dev/null @@ -1 +0,0 @@ -3cd9454fa8c7a6255b6743b767700925ead1b9ab0d7a0f9dcb1151010f8eb4a1 postgresql-13.3.tar.bz2 diff --git a/postgresql-pgcrypto-openssl3-init.patch b/postgresql-pgcrypto-openssl3-init.patch deleted file mode 100644 index 7656ba5df605b313a2dde5d15f8126726f4ea59a..0000000000000000000000000000000000000000 --- a/postgresql-pgcrypto-openssl3-init.patch +++ /dev/null @@ -1,33 +0,0 @@ -Upstream patch: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=135d8687ad -author Daniel Gustafsson - -The PX layer in pgcrypto is handling digest padding on its own uniformly -for all backend implementations. Starting with OpenSSL 3.0.0, DecryptUpdate -doesn't flush the last block in case padding is enabled so explicitly -disable it as we don't use it. - -This will be backpatched to all supported version once there is sufficient -testing in the buildfarm of OpenSSL 3. - -diff -ur postgresql-14rc1/contrib/pgcrypto/openssl.c postgresql-p/contrib/pgcrypto/openssl.c ---- postgresql-14rc1/contrib/pgcrypto/openssl.c 2021-09-20 17:33:01.000000000 -0400 -+++ postgresql-p/contrib/pgcrypto/openssl.c 2021-10-06 04:07:24.628836908 -0400 -@@ -379,6 +379,8 @@ - { - if (!EVP_DecryptInit_ex(od->evp_ctx, od->evp_ciph, NULL, NULL, NULL)) - return PXE_CIPHER_INIT; -+ if (!EVP_CIPHER_CTX_set_padding(od->evp_ctx, 0)) -+ return PXE_CIPHER_INIT; - if (!EVP_CIPHER_CTX_set_key_length(od->evp_ctx, od->klen)) - return PXE_CIPHER_INIT; - if (!EVP_DecryptInit_ex(od->evp_ctx, NULL, NULL, od->key, od->iv)) -@@ -403,6 +405,8 @@ - { - if (!EVP_EncryptInit_ex(od->evp_ctx, od->evp_ciph, NULL, NULL, NULL)) - return PXE_CIPHER_INIT; -+ if (!EVP_CIPHER_CTX_set_padding(od->evp_ctx, 0)) -+ return PXE_CIPHER_INIT; - if (!EVP_CIPHER_CTX_set_key_length(od->evp_ctx, od->klen)) - return PXE_CIPHER_INIT; - if (!EVP_EncryptInit_ex(od->evp_ctx, NULL, NULL, od->key, od->iv)) - diff --git a/postgresql-subtransaction-test.patch b/postgresql-subtransaction-test.patch deleted file mode 100644 index e470e18da996986a1b2fc587d7b658f3556e4e95..0000000000000000000000000000000000000000 --- a/postgresql-subtransaction-test.patch +++ /dev/null @@ -1,56 +0,0 @@ -Fix subtransaction test for Python 3.10 - -Starting with Python 3.10, the stacktrace looks differently: - - PL/Python function "subtransaction_exit_subtransaction_in_with", line 3, in - - s.__exit__(None, None, None) - + PL/Python function "subtransaction_exit_subtransaction_in_with", line 2, in - + with plpy.subtransaction() as s: -Using try/except specifically makes the error look always the same. - -RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1959080 - -diff -up postgresql-13.2/src/pl/plpython/expected/plpython_subtransaction.out.patchnew postgresql-13.2/src/pl/plpython/expected/plpython_subtransaction.out ---- postgresql-13.2/src/pl/plpython/expected/plpython_subtransaction.out.patchnew 2021-02-08 22:54:11.000000000 +0100 -+++ postgresql-13.2/src/pl/plpython/expected/plpython_subtransaction.out 2021-05-11 21:04:25.085586012 +0200 -@@ -171,8 +171,11 @@ with plpy.subtransaction() as s: - $$ LANGUAGE plpythonu; - CREATE FUNCTION subtransaction_exit_subtransaction_in_with() RETURNS void - AS $$ --with plpy.subtransaction() as s: -- s.__exit__(None, None, None) -+try: -+ with plpy.subtransaction() as s: -+ s.__exit__(None, None, None) -+except ValueError as e: -+ raise ValueError(e) - $$ LANGUAGE plpythonu; - SELECT subtransaction_exit_without_enter(); - ERROR: ValueError: this subtransaction has not been entered -@@ -224,8 +227,8 @@ PL/Python function "subtransaction_enter - SELECT subtransaction_exit_subtransaction_in_with(); - ERROR: ValueError: this subtransaction has already been exited - CONTEXT: Traceback (most recent call last): -- PL/Python function "subtransaction_exit_subtransaction_in_with", line 3, in -- s.__exit__(None, None, None) -+ PL/Python function "subtransaction_exit_subtransaction_in_with", line 6, in -+ raise ValueError(e) - PL/Python function "subtransaction_exit_subtransaction_in_with" - -- Make sure we don't get a "current transaction is aborted" error - SELECT 1 as test; -diff -up postgresql-13.2/src/pl/plpython/sql/plpython_subtransaction.sql.patchnew postgresql-13.2/src/pl/plpython/sql/plpython_subtransaction.sql ---- postgresql-13.2/src/pl/plpython/sql/plpython_subtransaction.sql.patchnew 2021-02-08 22:54:11.000000000 +0100 -+++ postgresql-13.2/src/pl/plpython/sql/plpython_subtransaction.sql 2021-05-11 21:02:34.386415376 +0200 -@@ -121,8 +121,11 @@ $$ LANGUAGE plpythonu; - - CREATE FUNCTION subtransaction_exit_subtransaction_in_with() RETURNS void - AS $$ --with plpy.subtransaction() as s: -- s.__exit__(None, None, None) -+try: -+ with plpy.subtransaction() as s: -+ s.__exit__(None, None, None) -+except ValueError as e: -+ raise ValueError(e) - $$ LANGUAGE plpythonu; - - SELECT subtransaction_exit_without_enter(); diff --git a/postgresql.spec b/postgresql.spec index 9d0c5560c8fce59f1628a12382df063a95de5f4e..865403560f64f1eb2ca5798cdc0f3142017d3c70 100644 --- a/postgresql.spec +++ b/postgresql.spec @@ -31,8 +31,8 @@ Summary: PostgreSQL client programs Name: postgresql %global majorversion 13 -Version: %{majorversion}.3 -Release: 8 +Version: %{majorversion}.11 +Release: 1 # The PostgreSQL license is very similar to other MIT licenses, but the OSI # recognizes it as an independent license, so we do as well. @@ -76,13 +76,9 @@ Patch8: postgresql-external-libpq.patch Patch9: postgresql-server-pg_config.patch Patch10: postgresql-no-libecpg.patch Patch11: postgresql-datalayout-mismatch-on-s390.patch -Patch12: CVE-2021-23214.patch -Patch13: CVE-2021-23222.patch -Patch14: postgresql-subtransaction-test.patch -Patch15: postgresql-pgcrypto-openssl3-init.patch Patch16: postgresql-pgcrypto-openssl3-tests.patch -BuildRequires: gcc +BuildRequires: gcc clang BuildRequires: perl(ExtUtils::MakeMaker) glibc-devel bison flex gawk BuildRequires: perl(ExtUtils::Embed), perl-devel BuildRequires: perl-generators @@ -382,10 +378,6 @@ goal of accelerating analytics queries. %endif %patch9 -p1 %patch11 -p1 -%patch12 -p1 -%patch13 -p1 -%patch14 -p1 -%patch15 -p1 %patch16 -p1 # We used to run autoconf here, but there's no longer any real need to, @@ -1295,6 +1287,9 @@ make -C postgresql-setup-%{setup_version} check %changelog +* Thu Jul 27 2023 dillon chen - 13.11-1 +- update to 13.11 + * Tue Apr 18 2023 Wenlong Zhang - 13.3-8 - Fix build error for loongarch64