postgresql-17.3

[Bruce Dubbs]

New minor version.

[Douglas R. Reno]

This update is going to be a little bit complicated regarding timing.

First, for context, it's an emergency update to fix CVE-2025-1094. It allows for SQL Injection and arbitrary code execution, and was used to compromise the United States Treasury - ​https://www.securityweek.com/rapid7-flags-new-postgresql-zero-day-connected-to-beyondtrust-exploitation/

Note that BeyondTrust is a product that is used for remote support, and uses PostgreSQL for it's database. The vulnerability was discovered in PostgreSQL through the usage of that product.

Rapid7 has an advisory here, as they were the ones who discovered it: ​https://www.rapid7.com/blog/post/2025/02/13/cve-2025-1094-postgresql-psql-sql-injection-fixed/

CVE-2025-1094 arises from an incorrect assumption that when attacker-controlled 
untrusted input has been safely escaped via PostgreSQL's string escaping routines, it 
cannot be leveraged to generate a successful SQL injection attack. Rapid7 found that SQL 
injection is, in fact, still possible in a certain scenario when escaped untrusted input 
is included as part of a SQL statement executed by the interactive psql tool.

Because of how PostgreSQL string escaping routines handle invalid UTF-8 characters, in 
combination with how invalid byte sequences within the invalid UTF-8 characters are 
processed by psql, an attacker can leverage CVE-2025-1094 to generate a SQL injection.

An attacker who can generate a SQL injection via CVE-2025-1094 can then achieve 
arbitrary code execution (ACE) by leveraging the interactive tool’s ability to run meta-
commands. Meta-commands extend the interactive tools functionality, by providing a wide 
variety of additional operations that the interactive tool can perform. The meta-
command, identified by the exclamation mark symbol, allows for an operating system shell 
command to be executed. An attacker can leverage CVE-2025-1094 to perform this meta-
command, thus controlling the operating system shell command that is executed.

Alternatively, an attacker who can generate a SQL injection via CVE-2025-1094 can 
execute arbitrary attacker-controlled SQL statements.

This would allow attackers who have compromised a PostgreSQL database to be able to execute shell commands, as well as execute SQL statements.

The vulnerability was rated by upstream as High (CVSS score of 8.1)

However, a regression was found - and upstream does not plan on fixing it until February 20th: ​https://www.postgresql.org/about/news/out-of-cycle-release-scheduled-for-february-20-2025-3016/

This adds a bit of a twist here for package freeze, as we really should update to PostgreSQL 17.3 to fix that vulnerability. For most users, this isn't a problem, but some users running database servers (not using just the client as a build dependency) could be impacted, and very severely depending on the context.

The problem with having to update this package *again* to fix that regression is that it's used in the following places, which would have to be rechecked:

general/prog/php.xml:      <xref linkend="postgresql"/>,
general/genlib/apr-util.xml:      <xref linkend="postgresql"/>,
general/sysutils/redland.xml:      <xref linkend="postgresql"/>,
postlfs/security/cyrus-sasl.xml:      <xref linkend="postgresql"/>,
server/other/openldap.xml:        <xref linkend="postgresql"/> or
server/major/kea.xml:      <xref linkend="postgresql"/>
server/major/proftpd.xml:      <xref linkend="postgresql"/>, and
server/mail/postfix.xml:      <xref linkend="postgresql"/>,
server/mail/exim.xml:      <xref linkend="postgresql"/>,
server/mail/dovecot.xml:      <xref linkend="postgresql"/>,
x/lib/qt6.xml:      <xref linkend="postgresql"/>,
xsoft/office/libreoffice.xml:      <xref linkend="postgresql"/>,

[thomas]

I don't think we should suspend the psql upgrade when we have a serious CVE to fix. All the pkgs which seem to use psql are 'heavy' ones which i think we do check in detail and tag them later anyhow.

Complexity in psql upgrade increases only when the binary format of the data files needs to be changed which is most likely not the case right now (but i've not checked the docs). If they change, then additional steps are required, if they do not change, its just a CMMI+restart.

[Bruce Dubbs]

Replying to thomas:

I don't think we should suspend the psql upgrade when we have a serious CVE to fix.

Yes, we will update and tag at the same time. That's why it's in the 12.3 milestone.

[thomas]

Fixed at [c2a617543f]

[Douglas R. Reno]

SA-12.2-088 issued