In this post, we discuss a security vulnerability in PostgreSQL - CVE-2024-10976 - that stems from incomplete tracking of tables with row security, allowing a reused query to view or change different rows than the ones intended. Previous vulnerabilities, namely CVE-2023-2455 and CVE-2016-2193, were fixed for the most part but neglected cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy. The consequences of this vulnerability are the same as the two earlier CVEs, leading to incorrect policies being applied, which could allow unauthorized users to read and modify rows.
Affected Versions
PostgreSQL versions prior to PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected by this vulnerability.
Exploit Details
Exploiting CVE-2024-10976 requires an attacker to tailor an attack specifically to the target application's pattern of query plan reuse, user ID changes, and role-specific row security policies. To clarify, this affects only databases that have used CREATE POLICY to define a row security policy.
`
2. A subquery, WITH query, security invoker view, or SQL-language function references the table with the row security policy:
`
In the above scenario, if a query is planned under one role and then executed under other roles – for example, using security definer functions or when a common user and query is initially planned and reused across multiple SET ROLEs – an incorrect policy may be applied. As a result, an attacker could exploit this to perform unauthorized reads and modifications.
Original References
1. PostgreSQL Security Advisory: CVE-2024-10976
2. CVE-2024-10976: Incomplete tracking in PostgreSQL of tables with row security
3. PostgreSQL Documentation on Row Security
Conclusion
CVE-2024-10976 is a security vulnerability in PostgreSQL affecting versions prior to 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21. It is caused by incomplete tracking of tables with row security, potentially leading to unauthorized access to rows. To mitigate the risk, ensure that your PostgreSQL installations are updated to the latest version, and carefully review your applications for patterns of query plan reuse and user ID changes that could potentially make them susceptible to this vulnerability.
Timeline
Published on: 11/14/2024 13:00:01 UTC