git: f3fe33710cee - main - security/vuxml: Add CVEs for PostreSQL
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 14 Nov 2024 16:31:38 UTC
The branch main has been updated by girgen:
URL: https://cgit.FreeBSD.org/ports/commit/?id=f3fe33710cee7d5ae2b852096b64f803d1d39e2d
commit f3fe33710cee7d5ae2b852096b64f803d1d39e2d
Author: Palle Girgensohn <girgen@FreeBSD.org>
AuthorDate: 2024-11-14 15:53:16 +0000
Commit: Palle Girgensohn <girgen@FreeBSD.org>
CommitDate: 2024-11-14 16:29:07 +0000
security/vuxml: Add CVEs for PostreSQL
---
security/vuxml/vuln/2024.xml | 241 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 241 insertions(+)
diff --git a/security/vuxml/vuln/2024.xml b/security/vuxml/vuln/2024.xml
index 26d525fd8766..47c386c1d48d 100644
--- a/security/vuxml/vuln/2024.xml
+++ b/security/vuxml/vuln/2024.xml
@@ -1,3 +1,244 @@
+ <vuln vid="a03636f4-a29f-11ef-af48-6cc21735f730">
+ <topic>PostgreSQL -- PL/Perl environment variable changes execute arbitrary code</topic>
+ <affects>
+ <package>
+ <name>postgresql17-plperl</name>
+ <range><lt>17.1</lt></range>
+ </package>
+ <package>
+ <name>postgresql16-plperl</name>
+ <range><lt>16.5</lt></range>
+ </package>
+ <package>
+ <name>postgresql15-plperl</name>
+ <range><lt>15.9</lt></range>
+ </package>
+ <package>
+ <name>postgresql14-plperl</name>
+ <range><lt>14.14</lt></range>
+ </package>
+ <package>
+ <name>postgresql13-plperl</name>
+ <range><lt>13.17</lt></range>
+ </package>
+ <package>
+ <name>postgresql12-plperl</name>
+ <range><lt>12.21</lt></range>
+ </package>
+ </affects>
+ <description>
+ <body xmlns="http://www.w3.org/1999/xhtml">
+ <p>PostgreSQL project reports:</p>
+ <blockquote cite="https://www.postgresql.org/support/security/CVE-2024-10979/">
+ <p>
+ Incorrect control of environment variables in PostgreSQL
+ PL/Perl allows an unprivileged database user to change
+ sensitive process environment variables (e.g. PATH).
+ That often suffices to enable arbitrary code execution,
+ even if the attacker lacks a database server operating
+ system user.
+ </p>
+ </blockquote>
+ </body>
+ </description>
+ <references>
+ <cvename>CVE-2024-10979</cvename>
+ <url>https://www.postgresql.org/support/security/CVE-2024-10979/</url>
+ </references>
+ <dates>
+ <discovery>2024-11-14</discovery>
+ <entry>2024-11-14</entry>
+ </dates>
+ </vuln>
+
+ <vuln vid="12e3feab-a29f-11ef-af48-6cc21735f730">
+ <topic>PostgreSQL -- SET ROLE, SET SESSION AUTHORIZATION reset to wrong user ID</topic>
+ <affects>
+ <package>
+ <name>postgresql17-server</name>
+ <range><lt>17.1</lt></range>
+ </package>
+ <package>
+ <name>postgresql16-server</name>
+ <range><lt>16.5</lt></range>
+ </package>
+ <package>
+ <name>postgresql15-server</name>
+ <range><lt>15.9</lt></range>
+ </package>
+ <package>
+ <name>postgresql14-server</name>
+ <range><lt>14.14</lt></range>
+ </package>
+ <package>
+ <name>postgresql13-server</name>
+ <range><lt>13.17</lt></range>
+ </package>
+ <package>
+ <name>postgresql12-server</name>
+ <range><lt>12.21</lt></range>
+ </package>
+ </affects>
+ <description>
+ <body xmlns="http://www.w3.org/1999/xhtml">
+ <p>PostgreSQL project reports:</p>
+ <blockquote cite="https://www.postgresql.org/support/security/CVE-2024-10978/">
+ <p>
+ Incorrect privilege assignment in PostgreSQL allows a
+ less-privileged application user to view or change
+ different rows from those intended. An attack requires
+ the application to use SET ROLE, SET SESSION
+ AUTHORIZATION, or an equivalent feature. The problem
+ arises when an application query uses parameters from
+ the attacker or conveys query results to the attacker.
+ If that query reacts to current_setting('role') or the
+ current user ID, it may modify or return data as though
+ the session had not used SET ROLE or SET SESSION
+ AUTHORIZATION. The attacker does not control which
+ incorrect user ID applies. Query text from
+ less-privileged sources is not a concern here, because
+ SET ROLE and SET SESSION AUTHORIZATION are not sandboxes
+ for unvetted queries
+ </p>
+ </blockquote>
+ </body>
+ </description>
+ <references>
+ <cvename>CVE-2024-10978</cvename>
+ <url>https://www.postgresql.org/support/security/CVE-2024-10978/</url>
+ </references>
+ <dates>
+ <discovery>2024-11-14</discovery>
+ <entry>2024-11-14</entry>
+ </dates>
+ </vuln>
+
+ <vuln vid="a61ef21b-a29e-11ef-af48-6cc21735f730">
+ <topic>PostgreSQL -- libpq retains an error message from man-in-the-middle</topic>
+ <affects>
+ <package>
+ <name>postgresql17-client</name>
+ <range><lt>17.1</lt></range>
+ </package>
+ <package>
+ <name>postgresql16-client</name>
+ <range><lt>16.5</lt></range>
+ </package>
+ <package>
+ <name>postgresql15-client</name>
+ <range><lt>15.9</lt></range>
+ </package>
+ <package>
+ <name>postgresql14-client</name>
+ <range><lt>14.14</lt></range>
+ </package>
+ <package>
+ <name>postgresql13-client</name>
+ <range><lt>13.17</lt></range>
+ </package>
+ <package>
+ <name>postgresql12-client</name>
+ <range><lt>12.21</lt></range>
+ </package>
+ </affects>
+ <description>
+ <body xmlns="http://www.w3.org/1999/xhtml">
+ <p>PostgreSQL project reports:</p>
+ <blockquote cite="https://www.postgresql.org/support/security/CVE-2024-10977/">
+ <p>
+ Client use of server error message in PostgreSQL allows
+ a server not trusted under current SSL or GSS settings
+ to furnish arbitrary non-NUL bytes to the libpq
+ application. For example, a man-in-the-middle attacker
+ could send a long error message that a human or
+ screen-scraper user of psql mistakes for valid query
+ results. This is probably not a concern for clients
+ where the user interface unambiguously indicates the
+ boundary between one error message and other text.
+ </p>
+ </blockquote>
+ </body>
+ </description>
+ <references>
+ <cvename>CVE-2024-10977</cvename>
+ <url>https://www.postgresql.org/support/security/CVE-2024-10977/</url>
+ </references>
+ <dates>
+ <discovery>2024-11-14</discovery>
+ <entry>2024-11-14</entry>
+ </dates>
+ </vuln>
+
+ <vuln vid="3831292b-a29d-11ef-af48-6cc21735f730">
+ <topic>PostgreSQL -- PostgreSQL row security below e.g. subqueries disregards user ID changes</topic>
+ <affects>
+ <package>
+ <name>postgresql17-server</name>
+ <range><lt>17.1</lt></range>
+ </package>
+ <package>
+ <name>postgresql16-server</name>
+ <range><lt>16.5</lt></range>
+ </package>
+ <package>
+ <name>postgresql15-server</name>
+ <range><lt>15.9</lt></range>
+ </package>
+ <package>
+ <name>postgresql14-server</name>
+ <range><lt>14.14</lt></range>
+ </package>
+ <package>
+ <name>postgresql13-server</name>
+ <range><lt>13.17</lt></range>
+ </package>
+ <package>
+ <name>postgresql12-server</name>
+ <range><lt>12.21</lt></range>
+ </package>
+ </affects>
+ <description>
+ <body xmlns="http://www.w3.org/1999/xhtml">
+ <p>PostgreSQL project reports:</p>
+ <blockquote cite="https://www.postgresql.org/support/security/CVE-2024-10976/">
+ <p>
+ Incomplete tracking in PostgreSQL of tables with row
+ security allows a reused query to view or change
+ different rows from those intended. CVE-2023-2455 and
+ CVE-2016-2193 fixed most interaction between row
+ security and user ID changes. They missed cases where a
+ subquery, WITH query, security invoker view, or
+ SQL-language function references a table with a
+ row-level security policy. This has the same
+ consequences as the two earlier CVEs. That is to say, it
+ leads to potentially incorrect policies being applied in
+ cases where role-specific policies are used and a given
+ query is planned under one role and then executed under
+ other roles. This scenario can happen under security
+ definer functions or when a common user and query is
+ planned initially and then re-used across multiple SET
+ ROLEs.
+
+ Applying an incorrect policy may permit a user to complete
+ otherwise-forbidden reads and modifications. This affects only databases
+ that have used CREATE POLICY to define a row security policy. An
+ attacker must tailor an attack to a particular application's pattern of
+ query plan reuse, user ID changes, and role-specific row security
+ policies.
+ </p>
+ </blockquote>
+ </body>
+ </description>
+ <references>
+ <cvename>CVE-2024-10976</cvename>
+ <url>https://www.postgresql.org/support/security/CVE-2024-10976/</url>
+ </references>
+ <dates>
+ <discovery>2024-11-14</discovery>
+ <entry>2024-11-14</entry>
+ </dates>
+ </vuln>
+
<vuln vid="6b591e05-971c-4077-8ae4-1310554971b7">
<topic>electron31 -- multiple vulnerabilities</topic>
<affects>