packages/postgresql
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

!87 update to 13.11

Browse Source 
From: @dillon_chen 
Reviewed-by: @zhengzhenyu 
Signed-off-by: @zhengzhenyu
This commit is contained in:
openeuler-ci-bot 2023-07-28 14:35:32 +00:00 committed by Gitee
commit 55eaaf9278
No known key found for this signature in database
GPG Key ID: 173E9B9CA92EEF8F
9 changed files with 7 additions and 332 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
CVE-2021-23214.patch
View File

@ -1,108 +0,0 @@
From e92ed93e8eb76ee0701b42d4f0ce94e6af3fc741 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
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);
/*

123
CVE-2021-23222.patch
View File

@ -1,123 +0,0 @@
From 844b3169204c28cd086c1b4fae4a2cbdd0540640 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
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;<!-- this typo is intentional -->
and proceed without requesting <acronym>SSL</acronym>.
</para>
+ <para>
+ When <acronym>SSL</acronym> encryption can be performed, the server
+ is expected to send only the single <literal>S</literal> byte and then
+ wait for the frontend to initiate an <acronym>SSL</acronym> 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
+ (<ulink url="https://www.postgresql.org/support/security/CVE-2021-23222/">CVE-2021-23222</ulink>).
+ 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.
+ </para>
+
<para>
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;<!-- this typo is intentional -->
encryption.
</para>
+ <para>
+ When <acronym>GSSAPI</acronym> encryption can be performed, the server
+ is expected to send only the single <literal>G</literal> byte and then
+ wait for the frontend to initiate a <acronym>GSSAPI</acronym> 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
+ (<ulink url="https://www.postgresql.org/support/security/CVE-2021-23222/">CVE-2021-23222</ulink>).
+ 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.
+ </para>
+
<para>
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;

BIN
postgresql-13.3-US.pdf → postgresql-13.11-US.pdf
View File

Binary file not shown.

BIN
postgresql-13.3.tar.bz2 → postgresql-13.11.tar.bz2
View File

Binary file not shown.

1
postgresql-13.11.tar.bz2.sha256 Normal file
View File

@ -0,0 +1 @@
4992ff647203566b670d4e54dc5317499a26856c93576d0ea951bdf6bee50bfb postgresql-13.11.tar.bz2

1
postgresql-13.3.tar.bz2.sha256
View File

@ -1 +0,0 @@
3cd9454fa8c7a6255b6743b767700925ead1b9ab0d7a0f9dcb1151010f8eb4a1 postgresql-13.3.tar.bz2

33
postgresql-pgcrypto-openssl3-init.patch
View File

@ -1,33 +0,0 @@
Upstream patch: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=135d8687ad
author Daniel Gustafsson <dgustafsson@postgresql.org>
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))

56
postgresql-subtransaction-test.patch
View File

@ -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 <module>
- s.__exit__(None, None, None)
+ PL/Python function "subtransaction_exit_subtransaction_in_with", line 2, in <module>
+ 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 <module>
- s.__exit__(None, None, None)
+ PL/Python function "subtransaction_exit_subtransaction_in_with", line 6, in <module>
+ 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();

17
postgresql.spec
View File

@ -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 <dillon.chen@gmail.com> - 13.11-1
- update to 13.11
* Tue Apr 18 2023 Wenlong Zhang<zhangwenlong@loongson.cn> - 13.3-8
- Fix build error for loongarch64