Multiple security patches for PostgreSQL and related software were released today at 0930ET, 11 Nov. These patches affect all supported releases of PostgreSQL and EDB Advanced Postgres Server, from the current version 14, through to 9.6 and even earlier, since the vulnerabilities discovered are fairly old.
The severity of the main server patch is rated as 8.1 High on the CVSSv3 scale, so please be responsible and update your software in a reasonably prompt manner. If your software is earlier than version 9.6, please upgrade to later versions soon.
Both server and client software is affected, since the problem is in the way communication is handled when certain client software first contacts the PostgreSQL server to establish an SSL connection. This problem opens the possibility of a "man-in-the-middle" attack, in cases where the protocol travels across unsafe networks, such as cloud database servers where the traffic exits the cloud provider's network, and some "on-prem" deployments where the client and the database are not on a shared secured network. This type of attack is quite rightly identified as having a CVSS Attack Complexity of "High"; for many cases an attack may not be feasible at all because of protocol complexities or simply that the network isn't open enough to allow MITM attacks. This type of attack has been seen before in other, unrelated, software, where it was described as a "plaintext command injection".
How prone your communications are to MITM attack relies on network security choices that have little to do with PostgreSQL; we hope and expect that those choices are good ones and you may be perfectly safe. However, there is always some aspect of doubt there and we recommend that you upgrade your servers and clients soon.
EDB BigAnimal cloud is already patched against this vulnerability, and all other affected EDB software is already patched or is expected to be patched very soon.
This issue doesn't affect ALL drivers/client libraries and I stress that the FrontEnd-BackEnd protocol itself is not faulty - this is an implementation fault that affects some clients AND the server. Some commonly used clients such as the JDBC driver (java), node-postgres (NodeJs) and the Npgsql driver (.Net) do not have a known vulnerability. Many language drivers do have a dependency on the libpq client library and so will be affected. According to https://wiki.postgresql.org/wiki/List_of_drivers, the list of affected drivers would include ODBC, Python, perl, PHP, Ruby, C/C++, Tcl and R.
The PostgreSQL Security team controls security for the PostgreSQL server and the libpq client library, and also coordinates with security teams for related software. The known issues are these
- CVE-2021-23214 for PostgreSQL server
- CVE-2021-23222 for PostgreSQL client
Some derived software may not have a separate CVE. We will collect the CVE numbers for any related software and update this blog as new information arrives.
"MITM21" is not an official title, it's just a snappier name than "CVE-2021-23214".
PostgreSQL servers affected by CVE-2021-23214 are most vulnerable if they allow connections using "cert" authentication or "trust" authentication with a clientcert option set. These can be identified by running this SQL query on a potentially affected server to see if any valid access rules are vulnerable (works for PostgreSQL10+):
SELECT * FROM pg_hba_file_rules
WHERE (auth_method = 'cert' or
(auth_method = 'trust' and options::text like '%clientcert%'))
and type like 'host%' and error is null;
In those cases, the protocol flow can be understood enough to make an exploit feasible. Other types of authentication are thought to be much less vulnerable, or at least no known exploit has been reported to us by white hat security investigators.
The fix to this issue is now available. Importantly, should someone attempt a MITM attack the server will respond with a protocol violation error, which might also occur because of other software bugs. The libpq client will also report a protocol violation error, though some clients, such as the JDBC driver and npgpgsql clients don't report any issue at the present time.
There is no safe way for a client to know if the server it is communicating with is susceptible to attack by CVE-2021-23214. As a result, prudence would say that clients must also be updated, unless they have some external way of verifying that, e.g. a DBasS tech alert etc..
Needing to update PostgreSQL client software is rare and the trust that has been generated in the market is high. It is possible that many PostgreSQL users may be using very old software, and potentially have never updated their software. As a result, we understand that many people may notice this issue and worry about it, though we think the issue is manageable, with the right support and expert assistance.
For more info, watch the webinar and check out the FAQ.
The software patch commits related to these vulnerabilities are these:
commit 160c0258802d10b0600d7671b1bbea55d8e17d45
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon Nov 8 11:14:56 2021 -0500
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.
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
commit 28e24125541545483093819efae9bca603441951
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon Nov 8 11:01:43 2021 -0500
Reject extraneous data after SSL or GSS encryption handshake.
The server collects up to a bufferload of data whenever it reads data
from the client socket. When SSL or GSS encryption is requested
during startup, any additional data received with the initial
request message 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 be abused to send faked SQL commands to the server,
although that would only work if the server did not demand any
authentication data. (However, a server relying on SSL certificate
authentication might well not do so.)
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-23214
For more info, watch the webinar and check out the FAQ.