database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code 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:52 +09:00
parent 5d4298e75f
commit bf8835ea97
3 changed files with 22 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
doc/src/sgml/protocol.sgml
View 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>