On May 12th, 2022, new updates from the PostgreSQL Global Development group were released to the community, resolving more than 50 reported bugs disclosed over the last quarter. Included in this release is a critical fix for a newly disclosed security vulnerability CVE-2022-1552. Organizations using versions 10-14 are most likely affected, and, with a Common Vulnerability Scoring System (CVSS) rating of 8.8, this deserves immediate attention. This post will help you understand the vulnerability and assess whether it impacts your environment in just 10 minutes. At the end, we’ll also provide a few mitigation options for you and your organization’s security team.
Understanding the Vulnerability
As outlined in the official security bulletin, this CVE impacts the core server component of Postgres, affecting builds going back to version 10.
As seasoned database administrators know, Postgres has a database identity construct around users who own database objects such as tables. Tied to these objects are privileges, which come in types such as SELECT, INSERT, UPDATE or CREATE. Database administrators assign database user account privileges through roles, which have scoped access privileges to certain database objects. The goal of this method is to ensure that user accounts have the minimum possible access required to complete their required operations—also known as “accounts scoped for least privileged access.” Built into this access model is the assumption that privileges related to relation-enumerating and running functions verify that the database user has the appropriate authorization to perform the operation.
Alexander Lakhin, who reported the CVE-2022-1552, found that there is a flaw in the fundamental authorization process that allows for a set of operations to run as a superuser. While many of the affected commands had authorization checks in place, they were applied after the code execution, thus failing to provide the intended control on the operation.
Assessing the Environment
The vulnerability verification process is fairly straightforward for CVE-2022-1552; the conditions are as follows:
- Within the last 5 major releases, the minor release version of Postgres is older than 14.3, 13.7, 12.11, 11.16 and 10.21
- The database has an untrusted user with access to create non-temp objects in at least one schema, this can be any schema.
Available Vulnerability Mitigations
After determining that an environment is impacted, review the following mitigation approaches and determine if one or more of these paths make sense. In some situations, upgrading a database can not be done immediately, and understanding other mitigating security controls could help in assessing the immediate risk of this exposure.
The most obvious mitigation is to upgrade the version of Postgres that includes the latest fixes found in the May 12th release. Customers of EDB Postgres Advanced Server can update to the latest release to be patched. Contact EDB Support for more information, or EDB Professional Services for assistance with workarounds.
Customers willing to accept temporary but fairly quick performance degradation to the environment can opt to disable autovacuum and refrain from manually running REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW and CLUSTER on tables that have indexes that contain expressions or WHERE clauses, while at the same time preventing new indexes with expressions or WHERE clauses from being created. This is not a sensible long term approach to disable these permanently, or for a sustained length of time. In addition, not restoring a pg-dump output is also advised.
If preventative measures are not possible, detective logging controls present an opportunity to capture abuses by a compromised database user. pgAudit can be used to capture anomalous account activity as well as the events above. However, know that in some environments the transactional volume may be too much for a SIEM to cost effectively store and process the telemetry. Performance impacts on the database are another consideration for some environments; this option may not be viable for all objects, but it may be feasible if we restrict this logging to vulnerable indexes.
If an environment needs to maintain a vulnerable version while the upgrade is being planned and executed, take the following into consideration. Often during the disclosure of a vulnerability such as this, it's common to lose sight of the layers of security in place that could remove some immediate pressure. The bullets below are meant to highlight the extremes between implemented controls. Use these as guideposts in your thought process.
- Is the database on a flat network or in a well segmented network with ingress and egress defined with least privileged?
- Are there 100+ database accounts used by various applications and business intelligence tools or only scoped for a few well-managed applications?
- If user accounts are only scoped for managed applications, are the underlying hosts or containers managed with secure configurations and employ security monitoring to detect compromise? Or is the database and application on a single server that is largely unmanaged?
- Does the network have behavioral monitoring capabilities where anomalous traffic patterns can identify changes in volume or does the environment sit on a droplet in DigitalOcean?
While these are only a few examples, covering a subset of control domains, step through your environment’s controls and calibrate on if this CVE puts you above or below your risk appetite.
Conclusion
While every organization or Postgres user has a different set of risk drivers and appetite, vulnerabilities with a CVSS rating of 8.8 should never be left alone without consideration. Understanding how the vulnerability provides an attacker opportunities helps in determining your mitigation strategy. Knowing your environment and landscape and how controls are engineered will help guide risk management conversations and potentially provide the breathing room administrators need to perform safe upgrades.
Thank you to the EDB contributors for their work with this quarter's release. As a leading contributor to the Postgres project, we will continue to be by the community’s side.