libpq: reject extraneous data after SSL or GSS encryption handshake.
authorTom Lane <[email protected]>
Mon, 8 Nov 2021 16:14:56 +0000 (11:14 -0500)
committerTom Lane <[email protected]>
Mon, 8 Nov 2021 16:14:56 +0000 (11:14 -0500)
commite65d9c8cd15a86207f1da387a9c917c93c14ea11
tree03eaa1804a809c6ffe0e65125da5b2e31d5ebda7
parent9ae0f1112954989e955b4b29e4580216eccfcee4
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
doc/src/sgml/protocol.sgml
src/interfaces/libpq/fe-connect.c