mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

libpq: Bail out during SSL/GSS negotiation errors

Browse Source 
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
This commit is contained in:
Michael Paquier 2024-11-11 10:19:56 +09:00 committed by Muhammad Usama
parent a66f46e50c
commit a27b41fcc8
2 changed files with 21 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
doc/src/sgml/protocol.sgml
View File

@ -1506,10 +1506,10 @@ SELCT 1/0;<!-- this typo is intentional -->
<para> <para>
The frontend should also be prepared to handle an ErrorMessage The frontend should also be prepared to handle an ErrorMessage
response to SSLRequest from the server. This would only occur if response to SSLRequest from the server. The frontend should not display
the server predates the addition of <acronym>SSL</acronym> support this error message to the user/application, since the server has not been
to <productname>PostgreSQL</productname>. (Such servers are now very ancient, authenticated
and likely do not exist in the wild anymore.) (<ulink url="https://www.postgresql.org/support/security/CVE-2024-10977/">CVE-2024-10977</ulink>).
In this case the connection must In this case the connection must
be closed, but the frontend might choose to open a fresh connection be closed, but the frontend might choose to open a fresh connection
and proceed without requesting <acronym>SSL</acronym>. and proceed without requesting <acronym>SSL</acronym>.
@ -1619,12 +1619,13 @@ SELCT 1/0;<!-- this typo is intentional -->
<para> <para>
The frontend should also be prepared to handle an ErrorMessage The frontend should also be prepared to handle an ErrorMessage
response to GSSENCRequest from the server. This would only occur if response to GSSENCRequest from the server. The frontend should not display
the server predates the addition of <acronym>GSSAPI</acronym> encryption this error message to the user/application, since the server has not been
support to <productname>PostgreSQL</productname>. In this case the authenticated
connection must be closed, but the frontend might choose to open a fresh (<ulink url="https://www.postgresql.org/support/security/CVE-2024-10977/">CVE-2024-10977</ulink>).
connection and proceed without requesting <acronym>GSSAPI</acronym> In this case the connection must be closed, but the frontend might choose
encryption. to open a fresh connection and proceed without requesting
<acronym>GSSAPI</acronym> encryption.
</para> </para>
<para> <para>

34
src/interfaces/libpq/fe-connect.c
View File

@ -3512,22 +3512,12 @@ keep_going: /* We will come back to here until there is
{ {
/* /*
* Server failure of some sort, such as failure to * Server failure of some sort, such as failure to
* fork a backend process. We need to process and * fork a backend process. Don't bother retrieving
* report the error message, which might be formatted * the error message; we should not trust it as the
* according to either protocol 2 or protocol 3. * server has not been authenticated yet.
* 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.
*/ */
conn->status = CONNECTION_AWAITING_RESPONSE; libpq_append_conn_error(conn, "server sent an error response during SSL exchange");
goto error_return;
/*
* 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;
} }
else else
{ {
@ -3611,13 +3601,9 @@ keep_going: /* We will come back to here until there is
{ {
/* /*
* Server failure of some sort, possibly protocol * Server failure of some sort, possibly protocol
* version support failure. We need to process and * version support failure. Don't bother retrieving
* report the error message, which might be formatted * the error message; we should not trust it anyway as
* according to either protocol 2 or protocol 3. * the server has not authenticated yet.
* 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.
* *
* Note that unlike on an error response to * Note that unlike on an error response to
* SSLRequest, we allow falling back to SSL or * SSLRequest, we allow falling back to SSL or
@ -3626,8 +3612,8 @@ keep_going: /* We will come back to here until there is
* response might mean that we are connecting to a * response might mean that we are connecting to a
* pre-v12 server. * pre-v12 server.
*/ */
conn->status = CONNECTION_AWAITING_RESPONSE; libpq_append_conn_error(conn, "server sent an error response during GSS encryption exchange");
goto keep_going; CONNECTION_FAILED();
} }
/* mark byte consumed */ /* mark byte consumed */