libpq: Bail out during SSL/GSS negotiation errors
authorMichael Paquier <michael@paquier.xyz>
Mon, 11 Nov 2024 01:19:52 +0000 (10:19 +0900)
committerMichael Paquier <michael@paquier.xyz>
Mon, 11 Nov 2024 01:19:52 +0000 (10:19 +0900)
This commit changes libpq so that errors reported by the backend during
the protocol negotiation for SSL and GSS are discarded by the client, as
these may include bytes that could be consumed by the client and write
arbitrary bytes to a client's terminal.

A failure with the SSL negotiation now leads to an error immediately
reported, without a retry on any other methods allowed, like a fallback
to a plaintext connection.

A failure with GSS discards the error message received, and we allow a
fallback as it may be possible that the error is caused by a connection
attempt with a pre-11 server, GSS encryption having been introduced in
v12.  This was a problem only with v17 and newer versions; older
versions discard the error message already in this case, assuming a
failure caused by a lack of support for GSS encryption.

Author: Jacob Champion
Reviewed-by: Peter Eisentraut, Heikki Linnakangas, Michael Paquier
Security: CVE-2024-10977
Backpatch-through: 12

doc/src/sgml/protocol.sgml
src/interfaces/libpq/fe-connect.c
src/interfaces/libpq/t/005_negotiate_encryption.pl

index 4c0a1a006885f733bcb5e19ad0a2310d76a946ce..d5a78694b99ac732879f5a20d4c296a920ca3f27 100644 (file)
@@ -1508,10 +1508,10 @@ SELCT 1/0;<!-- this typo is intentional -->
 
    <para>
     The frontend should also be prepared to handle an ErrorMessage
-    response to SSLRequest from the server.  This would only occur if
-    the server predates the addition of <acronym>SSL</acronym> support
-    to <productname>PostgreSQL</productname>.  (Such servers are now very ancient,
-    and likely do not exist in the wild anymore.)
+    response to SSLRequest from the server. The frontend should not display
+    this error message to the user/application, since the server has not been
+    authenticated
+    (<ulink url="https://www.postgresql.org/support/security/CVE-2024-10977/">CVE-2024-10977</ulink>).
     In this case the connection must
     be closed, but the frontend might choose to open a fresh connection
     and proceed without requesting <acronym>SSL</acronym>.
@@ -1621,12 +1621,13 @@ SELCT 1/0;<!-- this typo is intentional -->
 
    <para>
     The frontend should also be prepared to handle an ErrorMessage
-    response to GSSENCRequest from the server.  This would only occur if
-    the server predates the addition of <acronym>GSSAPI</acronym> encryption
-    support to <productname>PostgreSQL</productname>.  In this case the
-    connection must be closed, but the frontend might choose to open a fresh
-    connection and proceed without requesting <acronym>GSSAPI</acronym>
-    encryption.
+    response to GSSENCRequest from the server.  The frontend should not display
+    this error message to the user/application, since the server has not been
+    authenticated
+    (<ulink url="https://www.postgresql.org/support/security/CVE-2024-10977/">CVE-2024-10977</ulink>).
+    In this case the connection must be closed, but the frontend might choose
+    to open a fresh connection and proceed without requesting
+    <acronym>GSSAPI</acronym> encryption.
    </para>
 
    <para>
index 61c025ff3bf4cad455dc43033793ee1fa2c1d241..51083dcfd8e4564e82f6e44745567ff6151e9992 100644 (file)
@@ -3509,22 +3509,12 @@ keep_going:                     /* We will come back to here until there is
                    {
                        /*
                         * Server failure of some sort, such as failure to
-                        * fork a backend process.  We need to process and
-                        * report the error message, which might be formatted
-                        * according to either protocol 2 or protocol 3.
-                        * Rather than duplicate the code for that, we flip
-                        * into AWAITING_RESPONSE state and let the code there
-                        * deal with it.  Note we have *not* consumed the "E"
-                        * byte here.
+                        * fork a backend process.  Don't bother retrieving
+                        * the error message; we should not trust it as the
+                        * server has not been authenticated yet.
                         */
-                       conn->status = CONNECTION_AWAITING_RESPONSE;
-
-                       /*
-                        * Don't fall back to a plaintext connection after
-                        * reading the error.
-                        */
-                       conn->failed_enc_methods |= conn->allowed_enc_methods & (~conn->current_enc_method);
-                       goto keep_going;
+                       libpq_append_conn_error(conn, "server sent an error response during SSL exchange");
+                       goto error_return;
                    }
                    else
                    {
@@ -3600,13 +3590,9 @@ keep_going:                      /* We will come back to here until there is
                    {
                        /*
                         * Server failure of some sort, possibly protocol
-                        * version support failure.  We need to process and
-                        * report the error message, which might be formatted
-                        * according to either protocol 2 or protocol 3.
-                        * Rather than duplicate the code for that, we flip
-                        * into AWAITING_RESPONSE state and let the code there
-                        * deal with it.  Note we have *not* consumed the "E"
-                        * byte here.
+                        * version support failure.  Don't bother retrieving
+                        * the error message; we should not trust it anyway as
+                        * the server has not authenticated yet.
                         *
                         * Note that unlike on an error response to
                         * SSLRequest, we allow falling back to SSL or
@@ -3615,8 +3601,8 @@ keep_going:                       /* We will come back to here until there is
                         * response might mean that we are connecting to a
                         * pre-v12 server.
                         */
-                       conn->status = CONNECTION_AWAITING_RESPONSE;
-                       goto keep_going;
+                       libpq_append_conn_error(conn, "server sent an error response during GSS encryption exchange");
+                       CONNECTION_FAILED();
                    }
 
                    /* mark byte consumed */
index 06d67de2db194d2297b9b0159977ad0049b624eb..31dec7dbb4955481222f46772925c7e33c9e6cf1 100644 (file)
@@ -455,7 +455,7 @@ nogssuser   disable      disable      postgres       connect, authok
        connect_test(
            $node,
            "user=testuser gssencmode=prefer sslmode=disable",
-           'connect, v2error -> fail');
+           'connect, v2error, reconnect, v2error -> fail');
        $node->restart;
 
        $node->safe_psql(