About one vulnerability that is not

At the end of March 2019, the American company Trustwave, which is engaged in cybersecurity and threat protection services, published a message about a vulnerability in the PostgreSQL DBMS, which is present in all versions starting from PostgreSQL 9.3 to version 11.2. This vulnerability was registered in the CVE (Common Vulnerabilities and Exposures) information security vulnerability database under the number CVE-2019-9193 . This message caused a big stir, because according to the CVSS (Common Vulnerability Scoring System) vulnerability rating system, this vulnerability was rated 9.0 on a 10-point scale.

The vulnerabilities were assigned the following characteristics:

• Confidentiality Impact (influence on confidentiality) - full disclosure of information, leads to the disclosure of all system files.
• Integrity Impact (impact on integrity) - a complete loss of system protection, as a result, the entire system becomes compromised.
• Availability Impact - the availability of a resource is completely unavailable.
• Access Complexity is low. Use requires very little knowledge or skills.
• Authentication - requires an attacker to log into the system, for example, through the command line or through a desktop session or web interface.
• Gained Access - no.
• Vulnerability Type (s) (type of vulnerability) - code execution.

Now let's figure out what really happens.

In 2013, back in PostgreSQL 9.3, a commit was added, which, by analogy with the \ copy meta command in psql, allows you to move data between PostgreSQL tables and regular files in the file system. COPY TO copies the contents of the table to the file, and COPY FROM - from the file to the table (adds data to those already in the table). Unlike the \ copy meta-command, which is implemented on the client, the COPY..TO / FROM command is implemented on the server side. The COPY command has an optional PROGRAM parameter 'command', which allows the server to execute the 'command' and pass standard output to the PostgreSQL server or vice versa. It was this parameter that caused the panic and the message about the vulnerability, since according to Trustwave, this command allows you to execute arbitrary code in the context of the user of the operating system. However, this is exactly what the developers intended! On this occasion it wasan official post by the PostgreSQL Global Development Group (PGDG), as well as correspondence in the pgsql-general email list (CVE-2019-9193 about COPY FROM / TO PROGRAM ) and comments by leading developers such as Magnus Hagander on his blog .

But to understand the essence, the details are important. Here’s what’s written in the documentation about this: “ Note that the command is launched through the command shell, so if you want to pass any arguments to this command from an untrusted source, you must carefully get rid of all special characters that have special meaning in the shell, or to screen them. For security reasons, it’s better to limit yourself to a fixed command line or at least not allow users to enter arbitrary content into it . ”

In addition, the documentation says that only database superusers are allowed to execute a COPY command with a file or an external command, or (in version 11 appeared) members of the built-in roles pg_read_server_files, pg_write_server_files or pg_execute_server_program, since this allows you to read / write any files and run any programs that the server has access to. The execution of a command in PROGRAM can be limited by other access control mechanisms operating in the OS, for example SELinux.

Structurally, there is no security boundary between the database superuser and the user of the operating system on whose behalf the server process of the server is running. The functions for COPY ... PROGRAM added in PostgreSQL 9.3 did not change any of the above, but added a new command within the same security boundaries that already existed. Therefore, the PostgreSQL server cannot run as the superuser of the operating system (for example, root).

The COPY..TO / FROM ... PROGRAM functionality itself provides unlimited possibilities for data manipulation, data post-processing, on-the-fly data compression and so on. And to prohibit the use of such useful tools would be wrong. Examples of the COPY..TO / FROM ... PROGRAM construct are given on Michael Paquier's blog .

An important conclusion that follows from this story is that when designing and creating databases, it is necessary to remember not only the functional characteristics, but also information security and follow the following rules:

• When creating ordinary users in the database, do not give them superuser permissions, only the user of the postgres operating system, on behalf of which the server is started, act in the database as superuser. In this case, there is no escalation of privileges. If you give superuser permission to an ordinary database user, this will be equivalent to issuing to the user the permissions that the postgres user has in the operating system.
• Use the capabilities of pg_hba.conf to ensure that no superuser can log in remotely.
  If there are no previous lines with “host” in the pg_hba.conf file, the following entry prohibits the postgres user from connecting to any database from any address using the tcp / ip protocol.
  
  

  # TYPE  DATABASE        USER            ADDRESS                 METHOD
  host    all             postgres        0.0.0.0/0               reject

• Use advanced information security techniques in PostgresSQL, such as the CIS PostgreSQL Benchmark and the PostgreSQL Security Technical Implementation Guide (STIG) .
• Use certified products for which compliance with the functional requirements for information security and the level of trust in information security tools have been confirmed.

Thus, we figured out that CVE-2019-9193 is not a vulnerability. But you should not relax. Do not miss information about updates and new minor releases that correct identified vulnerabilities , without which not a single large project can do.