August 2023 Advanced Server Security Update

On August 21st, 2023 a number of CVEs were disclosed impacting EDB Postgres Advanced Server. EDB identified the issues, and there have been no indications of active exploitation at the current time. This knowledge base article will go over the impact to the product and explain how to mitigate the issue with the required version update and patching tool.

EDB engineering has identified the following vulnerabilities that exist in all versions of EDB Postgres Advanced Server:

• EDB Postgres Advanced Server (EPAS) SECURITY DEFINER functions and procedures may be hijacked via search_path CVE-2023-41117
• EDB Postgres Advanced Server (EPAS) dbms_aq helper function may run arbitrary SQL as a superuser CVE-2023-41119
• EDB Postgres Advanced Server (EPAS) DBMS_PROFILER data may be removed without permission CVE-2023-41120
• EDB Postgres Advanced Server (EPAS) UTL_FILE permissions bypass via accesshistory() CVE-2023-41113
• EDB Postgres Advanced Server (EPAS) UTL_FILE permission bypass CVE-2023-41118
• EDB Postgres Advanced Server (EPAS) permission bypass for materialized views CVE-2023-41116
• EDB Postgres Advanced Server (EPAS) authenticated users may fetch any URL CVE-2023-41114
• EDB Postgres Advanced Server (EPAS) read permission bypass on large objects CVE-2023-41115

More details are available for these vulnerabilities on the EDB security advisory page, found here.

The first two vulnerabilities allow any user who is able to authenticate to an unpatched instance of Advanced Server to use a variety of techniques to obtain access to the database superuser account. The database superuser can bypass security controls within the database and obtain shell, file system, and network access as the OS user who runs the database processes.

The remaining six vulnerabilities similarly provide mechanisms for malicious actors to perform unintended actions.

Users must upgrade to a fixed version of EPAS and then patch existing database instance clusters using the new edb_sqlpatch tool. After upgrading to a fixed version of EPAS, new database clusters created using initdb will not be vulnerable; however, existing clusters will remain vulnerable until patched using edb_sqlpatch. Fixed versions are EPAS 15.4.0 or higher, EPAS 14.9.0 or higher, EPAS 13.12.17 or higher, EPAS 12.16.20 or higher, and EPAS 11.21.32 or higher.

edb_sqlpatch is a new command-line utility included in all fixed versions of EPAS. When run with no arguments, it will connect to the default database and provide a report indicating whether or not the database needs to be patched. For example:

$ edb_sqlpatch
* database edb
58 patches need to be applied to this database.

Use the -a option to connect to all databases that are part of a single instance, and the -f option to apply the necessary fixes. Thus, for most users, an existing database instance can be adequately secured using a command like this:

$ edb_sqlpatch -af
* database postgres
58 patches were successfully applied to this database.

* database template1
58 patches were successfully applied to this database.

* database template0
Skipping database "template0" because it does not allow connections.

* database app1
58 patches were successfully applied to this database.

As usual, if a connection string is required, it can be supplied to edb_sqlpatch as a command-line argument. Use edb_sqlpatch –help for a full list of command-line options. If some patches fail to apply for any reason, please contact EDB support for assistance. Note that patching a database using this tool is a very quick process and typically will have minimal effect on any running workload; nevertheless, EDB advises customers to perform the patching process during a maintenance window.

Because edb_sqlpatch modifies the definitions of system objects inside the database, some behavioral differences may be noticeable after applying these fixes. Confirm whether any of these fixes are likely to affect applications running against the database prior to applying them:

• Users making use of the UTL_MAIL package will now require EXECUTE permission on the UTL_SMTP and UTL_TCP packages in addition to EXECUTE permission on UTL_MAIL.
• Users making use of the UTL_SMTP package will now require EXECUTE permission on the UTL_TCP packages in addition to EXECUTE permission on UTL_SMTP.
• Public EXECUTE permission on the accesshistory() is revoked. Any non-superuser who needs access to this function must be granted EXECUTE permission on this function and on the UTL_FILE package.
• Public EXECUTE permission on the edb_get_url_as_text and edb_get_url_as_bytea functions is revoked. Any non-superuser who needs access to these functions must be granted that access explicitly.
• Public EXECUTE permission on various implementation functions internally used by UTL_FILE is revoked. These undocumented functions were never intended to be directly accessible by users, but were not secured against such access. If a non-superuser needs direct access to these functions, it will need to be granted explicitly. The functions affected are _fclose, _fclose_all, _fcopy, _fflush, _fopen, _fremove, _frename, _get_line, _get_nextline, _get_raw, _is_open, _new_line, _put, _put_line, _put_raw, and _putf.
• Profiling data gathered by DBMS_PROFILER will now include schema-qualification in some cases where it previously did not.

It can be seen from the sample output shown above, that edb_sqlpatch will typically not be able to patch the template0 database because that database typically does not allow connections. This is not normally an issue, because a database to which no one can connect is not a vulnerability. However, any databases created using template0 as a template would be vulnerable unless subsequently patched. If a user sometimes creates new databases from template0 rather than the default template database, template1, using commands such as createdb -template0 newdb or create database newdb template template0, the customer may wish to patch it, using these steps:

1. Using psql or another SQL client, allow connections to the database:

update pg_database set datallowconn = true where datname = 'template0';

2. From the command line, patch the database. If no non-default connection options are required, this can be done using the following command:

edb_sqlpatch -f template0

3. Freeze all tables in the template0 database, perhaps using a command like this, adjusted for any required connection options:

vacuumdb -F template0

4. Again disallow connections to the database. Connect to another database in the same instance, not to template0, and execute this command:

update pg_database set datallowconn = false where datname = 'template0';

If you are updating a PGD cluster deployed on EPAS, you will need to run edb_sqlpatch on each node including witness all nodes. edb_sqlpatch should not be run in a mixed version cluster. Each node should be fully upgraded to the latest minor release version of EPAS before any of the nodes have edb_sqlpatch run against them. In addition, edb_sqlpatch should only be run on a single node at a time. Do not run edb_sqlpatch against multiple nodes concurrently. If you would like help upgrading your PGD cluster, please reach out to EDB technical support.

EDB is committed to a security first approach, from the products we build and the platforms we operate, to the services we provide our customers. For more information about our program, review EDB’s Vulnerability disclosure policy. For additional information about the PostgreSQL and EPAS Vulnerabilities please visit our blog.