Another quarter has passed and the PostgreSQL Global Development group has released the latest update to the community, crushing 40 bugs that had been previously disclosed. Critical security vulnerability CVE-2022-2625 has been announced and an associated remediation has been included in this quarter’s release. Administrators of the affected PostgreSQL versions 10-14 should be aware that CVE-2022-2625 has a Common Vulnerability Scoring System (CVSS) rating of 7.1 and should have your attention for the next few minutes. The following post will provide the needed background on the vulnerability and a few approaches to mitigating the threat that should help teams plan a path forward.
Understanding the vulnerability
The official security bulletin outlines that the affected versions of PostgreSQL include 10 through 14.
Extensions are the means to extend PostgreSQL functionality and a major factor in the database’s success, allowing native-like features on top of a solid datastore performance and scalability. Today there are over a thousand extensions available which is a sign of the incredible flexibility of the Postgres architecture and the various use cases it can satisfy. The use of extensions within an environment is almost a given, and this is where the threat comes into play.
Installing PostgreSQL extensions requires a superuser in instances where the extension is not marked as trusted or a user with CREATE permissions. Upon installation the execution of the CREATE EXTENSION command loads the extension and creates a number of data objects, including functions. The privilege model is applied to the objects created and managed by the extension. Sven Klem, who reported the vulnerability, found that extensions that used CREATE or REPLACE and happened to target an object that already existed were blindly adopted and inherited privileges of the new extension. This means an existing object that was not part of the developed extension gains the privileges of the new extension and its objects.
This privilege escalation isn’t problematic for objects already tied to extensions—replacing permissions on those objects is actually forbidden. However, in other cases the impact of this privilege escalation could be more troublesome.
There are very common scenarios where a user will have access to the database with the ability to create objects. This user could create an object that is used by an extension currently not installed, with the intent to escalate their privileges in the future. Said user could then request the installation of the extension, which upon the execution of CREATE EXTENSION would identify the planted object by the user and apply the permissions of the extension as if it were its own object, escalating permissions.
Another less likely, but possible, scenario involves malicious extensions. The vast majority of extensions being utilized today are open sourced, and available for use. Through extension popularity, an actor could reasonably predict objects to target and plant a malicious function or data object. Upon being adopted by the extension, it would receive the full permissions of the extension and its objects.
With the disclosure of CVE-2022-2625, organizations need to focus on mitigation efforts in order to determine if privileges have been granted to an object incorrectly as well as prevent the possibility of occurrence in the future.
Available mitigations
There are a number of mitigations to consider for this particular vulnerability. The first step to eliminate the vulnerability would be to update to the latest version of PostgreSQL released today, which has the patch. Many organizations may have a longer upgrade path, requiring potential development changes and regression testing. This means living with a vulnerable version of PostgreSQL. Organizations and individuals should take time to review the following steps to ensure existing extensions have been operating as expected with the additional advice below.
Knowing whether the vulnerability has been exploited should be an immediate priority. Let’s review this example script as a starting point for that exploration.
SELECT
e.extname as "Extension Name",
e.extowner::pg_catalog.regrole as "Extension Owner",
pg_catalog.pg_describe_object(d.classid, d.objid, 0) AS "Object",
s.refobjid::pg_catalog.regrole as "Object Owner"
FROM
pg_catalog.pg_depend d
JOIN pg_catalog.pg_shdepend s
ON s.dbid = (select datid from pg_stat_activity
where pid = pg_backend_pid())
AND d.classid = s.classid AND d.objid = s.objid
AND d.objsubid = s.objsubid
JOIN pg_catalog.pg_extension e
ON d.refobjid = e.oid
WHERE
d.refclassid = 'pg_catalog.pg_extension'::pg_catalog.regclass
AND d.deptype = 'e' AND s.deptype = 'o'
AND e.extowner != s.refobjid
ORDER BY 1;
- This script looks for the extension objects owned by a user other than the extension owner or bootstrap superuser.
- If any are found, further investigation should be conducted to understand how they may have been introduced.
- It’s possible any findings are there by happenstance or it could be from malicious activity.
Administrators also need to pay close attention to the extensions in use, as well as any introduced into the environment. Software supply chain management should already be a crucial practice and ensuring extensions are in-scope is equally as important. Reported in this year’s Verizon DBIR, 62% of intrusions in 2021 were related to supply chain attacks. This increasing trend has become a popular vector for bad actors and requires focus on the management of tools, code, and solutions introduced into your environment. While the likelihood of an extension that was developed with malicious intent is probably low today, with the public vulnerability disclosure there could be an increase over time.
In the context of CVE-2022-2625 organizations looking to manage their software supply chain should:
- Review the extension, its purpose and the code (if available) before it’s introduced
- Any updates should also be reviewed in a similar fashion
- Understand if the extension is actively maintained
- The use of Static Application Security Tools may identify issues in the future as researchers identify exploitation, but these tools are likely ineffective in surfacing these issues today
- When installing any new extensions, check what objects they will create and verify that none of those objects exist on your system already
- If any existing objects are found, it’s possible they were created by a malicious local user in anticipation of the extension being installed.
Aside from reviewing the software supply chain, it’s worth spending time on the layered controls around PostgreSQL. The primary concern surrounds a lower privileged user account, which the implementation of potential security controls across organizations may vary. Here are a few considerations for review:
- Audit the user accounts within the database
- Determine which credentials are managed within development pipelines and ensure those credentials have been properly secured
- Ensure unique credentials are being leveraged for each administrator, and that they are absolutely required for their role
- Shared accounts should be avoided, which makes traceability difficult
- Network access controls should limit ingress traffic from trusted sources, and egress traffic should also apply least-privileged traffic flows
- Rotate credentials that have not been properly secured
Organizations need to focus on ensuring there isn’t any existing exploitation in their initial response, meaning reviewing the database for objects that have had privileges escalated. If any are found, standard incident response processes should be engaged to investigate the source and impact of the finding. Assessing security controls and the software supply chain risks should follow.
Conclusion
Having a CVSS rating of 7.1 for most organizations will mean this should get attention but likely without the immediacy of CVE-2022-1552 disclosed last quarter. For organizations and individuals, knowing if exploitation has occurred is priority number, and planning the upgrade should ensure there is no or little impact to the organization. For those who have yet to focus on the software dependencies or applying additional controls within their environment, this should serve as a driver for starting these practices.
As always, thank you to the community contributors and to the EDB staff for their work on this quarter’s release. As a leading contributor to the Postgres project, we will continue to work with the other members of the PostgreSQL community to identify and address security issues as they are reported.