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

diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 132436c6e6842956d8987297b5a0c62f90f8ee37..43b74e9423e0c0a388aa23dbf3d5292cefe1db33 100644 (file)
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1477,6 +1477,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.
@@ -1539,6 +1553,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 b288d346f92682e106957c4145310479fbb0da97..f0fdd294a401da323fd5915bf5d62887e6ae91c6 100644 (file)
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -3097,6 +3097,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;
@@ -3196,6 +3209,19 @@ keep_going:                      /* We will come back to here until there is
                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;