Skip to content

libpq: Bail out during SSL/GSS negotiation errors #1633

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
reshke wants to merge 3 commits into
base: main
Choose a base branch
from
+17 −19
Open

libpq: Bail out during SSL/GSS negotiation errors #1633

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c2569aa
libpq: Bail out during SSL/GSS negotiation errors
michaelpq Nov 11, 2024
1589ba7
Merge branch 'main' into cp_CVE_2024_10977
reshke Mar 23, 2026
5819468
Merge branch 'main' into cp_CVE_2024_10977
reshke Mar 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 11 additions & 10 deletions doc/src/sgml/protocol.sgml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1526,10 +1526,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>.
Expand Down Expand Up @@ -1603,12 +1603,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>
Expand Down
15 changes: 6 additions & 9 deletions src/interfaces/libpq/fe-connect.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3168,16 +3168,13 @@ PQconnectPoll(PGconn *conn)
{
/*
* 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;
goto keep_going;
appendPQExpBuffer(&conn->errorMessage,
libpq_gettext("server sent an error response during SSL exchange\n"));
goto error_return;
}
else
{
Expand Down
Loading