1
0
mirror of https://github.com/postgres/postgres.git synced 2025-10-19 15:49:24 +03:00
Files
postgres/doc/src/sgml
Tom Lane 30547d7913 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
2021-11-08 11:14:56 -05:00
..
2020-07-05 15:37:57 +02:00
2020-09-10 14:15:26 +02:00
2021-07-16 12:39:23 +02:00
2020-10-26 19:17:05 -04:00
2021-09-29 11:56:36 +09:00
2021-09-29 11:56:36 +09:00
2020-02-26 13:05:30 -08:00
2020-03-29 11:15:11 +02:00
2021-01-29 14:09:41 +13:00
2019-09-08 10:27:29 +02:00
2021-09-26 19:18:23 +09:00
2020-07-18 22:43:35 +09:00
2021-04-07 13:52:26 +02:00
2020-10-19 13:48:00 +02:00
2020-06-07 13:18:36 +02:00
2021-07-05 09:38:17 +05:30
2021-07-29 21:39:40 +02:00
2020-07-18 22:43:35 +09:00
2021-07-05 09:38:17 +05:30
2019-10-25 20:39:41 +02:00
2021-07-16 12:39:23 +02:00
2020-07-18 22:43:35 +09:00
2020-10-19 19:28:54 +03:00
2021-07-16 12:39:23 +02:00
2021-01-02 13:06:25 -05:00
2019-09-08 10:27:29 +02:00
2021-09-19 11:36:53 -04:00
2021-07-16 12:39:23 +02:00
2021-01-05 14:26:37 -05:00
2020-08-28 08:19:12 +02:00
2021-07-16 12:39:23 +02:00
2020-12-23 09:33:20 -05:00
2021-07-05 09:38:17 +05:30
2020-06-07 17:16:30 -04:00
2021-08-06 20:56:18 +02:00
2019-09-08 10:27:29 +02:00
2021-09-29 11:56:36 +09:00
2021-07-16 12:39:23 +02:00
2019-09-08 10:27:29 +02:00

<!-- doc/src/sgml/README.links -->

Linking within DocBook documents can be confusing, so here is a summary:


Intra-document Linking
----------------------

<xref>
	use to get chapter/section number from the title of the target
	link, or xreflabel if defined at the target, or refentrytitle if target
        is a refentry;  has no close tag
	http://www.oasis-open.org/docbook/documentation/reference/html/xref.html

linkend=
	controls the target of the link/xref, required

endterm=
	for <xref>, allows the text of the link/xref to be taken from a
	different link target title

<link>
	use to supply text for the link, only uses linkend, requires </link>
	http://www.oasis-open.org/docbook/documentation/reference/html/link.html
	can be embedded inside of <command>, unlike <xref>


External Linking
----------------

<ulink>
	like <link>, but uses a URL (not a document target);  requires
	</ulink>; if no text is specified, the URL appears as the link
	text
	http://www.oasis-open.org/docbook/documentation/reference/html/ulink.html

url=
	used by <ulink> to specify the URL, required


Guidelines
----------

- For an internal link, if you want to supply text, use <link>, else
  <xref>.

- Specific nouns like GUC variables, SQL commands, and contrib modules
  usually have xreflabels.

- For an external link, use <ulink>, with or without link text.

- xreflabels added to tags prevent the chapter/section for id's from being
  referenced;  only the xreflabel is accessible.  Therefore, use xreflabels
  only when linking is common, and chapter/section information is unneeded.