postgres.git / summary / log / commit / refs

commit    d83cdfdca9d918bbbd6bb209139b94c954da7228
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Mon Nov 08 16:14:57 2021 +0000
First released in: 15.0, 9.6.24, 10.19, 11.14, 12.9, 13.5, 14.1

    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        | 14 ++++++++++++++
 src/interfaces/libpq/fe-connect.c | 13 +++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 7e3c6ad22cb..db5918d36b4 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1307,6 +1307,20 @@
     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.
diff --git a/src/interfaces/libpq/fe-connect.c b/src/interfaces/libpq/fe-connect.c
index 1552eabe1e9..1c544802638 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -2371,6 +2371,19 @@ keep_going:						/* We will come back to here until there is
 				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;


[parent: 046c2c846b74]