Explaining CVE-2019-10164 + PostgreSQL Security Best Practices

The PostgreSQL Global Development Group provided an out-of-cycle update release for all supported to provide a fix for the CVE-2019-10164 vulnerability. This vulnerability only affects people running PostgreSQL 10, 11 or the 12 beta, and it is effectively remediated by simply upgrading all of your PostgreSQL installations to the latest versions.

What follows is some more insight about what this vulnerability is, the impact it can have in your environment, how to ensure you have patched all of your systems, and provide some PostgreSQL security best practices that could help mitigate the impact of this kind of vulnerability.

What is CVE-2019-10164?

CVE-2019-10164 states that a user authenticated to a PostgreSQL server could create a “stack-based buffer overflow by changing their own password to a purpose-crafted value.” In other words, a user that is authenticated to your system could come up with a password that at a minimum can crash your PostgreSQL server or, in the worst case, have the operating system user (e.g. postgres) that runs PostgreSQL execute arbitrary code.

Arbitrary code execution (aka “ACE”) is considered a significant security vulnerability as it leads to your system running untrusted code, which one of the reasons why the community decided to get the fix out sooner than the regularly scheduled release. Additionally, this fixes a potential denial-of-service (DoS) attack vector, as an authenticated user could repeatedly crash the server by sending one of these rogue passwords.

The good news: the attack can only be accomplished by a user who is already authenticated to your PostgreSQL server. Hopefully, you already have a certain level of trust of users who can directly access your databases, though, you should still install the upgrade as soon as possible.

These latest releases also fix a second attack that could occur using libpq, which contains the code used by many PostgreSQL clients (including psql). In this attack, a user connected to a rogue server using a libpq enabled software or driver (e.g. psql, pgAdmin4, psycopg2, etc.) could send a “crafted message” during the SCRAM authentication process that could cause the client to crash or, in the worst case, execute arbitrary code. In this case, the code would be executed by your client, and as such could carry out an attack on the connecting system, not the PostgreSQL server. However, note that the client could be your application (e.g. a web server) that is accessing PostgreSQL.

The good news: this attack can only be accomplished if you are connected to a rogue PostgreSQL server, which is highly unlikely if you have sufficiently secured your networking environment (though there have been a lot of recent examples of DNS flaws that have lead to successful attacks, so you should always keep checking the security of the various components that make up your environment).

The reason that CVE-2019-10164 only affects PostgreSQL 10 and above is that the vulnerability exploited how passwords use for SCRAM authentication are stored. Even if your system does not use SCRAM authentication, an authenticated user could still exploit this security vulnerability, which is why you still need to upgrade.

How Do I Protect My Systems from CVE-2019-10164?

Simple: upgrade! Ensure you are running either PostgreSQL 11.4 or PostgreSQL 10.9 for your server, and ensure the latest version of libpq is installed anywhere you have a PostgreSQL client.

For a list of clients that use libpq (including psql), the community maintains a list of drivers here:

https://wiki.postgresql.org/wiki/List_of_drivers

It is imperative that you ensure libpq is updated on any systems where drivers or other applications (e.g. pgAdmin4) utilize it in order to fix the libpq attack vector.

Some Best Practices To Mitigate Risk from CVE-2019-10164

Security best practices for managing your data with PostgreSQL could fill up a lengthy guide, so I wanted to focus on a few of them that are relevant to this latest CVE.

As a rule of thumb, you should run the latest minor releases of whichever version of PostgreSQL you are on, as they contain bug fixes and other improvements that help the overall stability of your database systems. Of course, please test your applications on the updates before you roll out the changes to your production systems.

You should only grant access to your PostgreSQL databases to people and applications that you have a fundamental level of trust.

If you are concerned about the possibility of your users connecting to rogue servers, you should use a strong client verification mode for server certificates, in particular verify-full, or an authentication protocol that always verifies both client and server against each other such as the GSSAPI (hat tip to Stephen Frost for the recommendation).

If you are using SCRAM authentication and want to secure against man-in-the-middle attacks. PostgreSQL 11 introduced channel binding for SCRAM, which ensures that SCRAM authentication endpoints are the same as when the client and server performed the initial SSL handshake. However, as it is a relatively new feature, you need to ensure that your connection driver supports channel binding.