Skip to content
Permalink
Browse files Browse the repository at this point in the history
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
  • Loading branch information
tglsfdc committed Nov 8, 2021
1 parent 28e2412 commit 160c025
Show file tree
Hide file tree
Showing 2 changed files with 54 additions and 0 deletions.
28 changes: 28 additions & 0 deletions doc/src/sgml/protocol.sgml
Expand Up @@ -1477,6 +1477,20 @@ SELCT 1/0;<!-- this typo is intentional -->
and proceed without requesting <acronym>SSL</acronym>.
</para>

<para>
When <acronym>SSL</acronym> encryption can be performed, the server
is expected to send only the single <literal>S</literal> byte and then
wait for the frontend to initiate an <acronym>SSL</acronym> 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
(<ulink url="https://www.postgresql.org/support/security/CVE-2021-23222/">CVE-2021-23222</ulink>).
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.
</para>

<para>
An initial SSLRequest can also be used in a connection that is being
opened to send a CancelRequest message.
Expand Down Expand Up @@ -1539,6 +1553,20 @@ SELCT 1/0;<!-- this typo is intentional -->
encryption.
</para>

<para>
When <acronym>GSSAPI</acronym> encryption can be performed, the server
is expected to send only the single <literal>G</literal> byte and then
wait for the frontend to initiate a <acronym>GSSAPI</acronym> 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
(<ulink url="https://www.postgresql.org/support/security/CVE-2021-23222/">CVE-2021-23222</ulink>).
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.
</para>

<para>
An initial GSSENCRequest can also be used in a connection that is being
opened to send a CancelRequest message.
Expand Down
26 changes: 26 additions & 0 deletions src/interfaces/libpq/fe-connect.c
Expand Up @@ -3097,6 +3097,19 @@ PQconnectPoll(PGconn *conn)
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;
Expand Down Expand Up @@ -3196,6 +3209,19 @@ PQconnectPoll(PGconn *conn)
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;
Expand Down

0 comments on commit 160c025

Please sign in to comment.