diff options
| author | Tom Lane | 2021-11-08 16:14:56 +0000 |
|---|---|---|
| committer | Tom Lane | 2021-11-08 16:14:56 +0000 |
| commit | e65d9c8cd15a86207f1da387a9c917c93c14ea11 (patch) | |
| tree | 03eaa1804a809c6ffe0e65125da5b2e31d5ebda7 /doc/src/sgml | |
| parent | 9ae0f1112954989e955b4b29e4580216eccfcee4 (diff) | |
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
Diffstat (limited to 'doc/src/sgml')
| -rw-r--r-- | doc/src/sgml/protocol.sgml | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index 3a269640fcd..6a2d4a14fce 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1349,6 +1349,20 @@ </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. </para> |