Bug 58619 - postgresql-15: Multiple issues (5.2)
Summary: postgresql-15: Multiple issues (5.2)
Status: CLOSED FIXED
Alias: None
Product: UCS
Classification: Unclassified
Component: Security updates
Version: UCS 5.2
Hardware: All Linux
: P3 normal
Target Milestone: UCS 5.2-3-errata
Assignee: Quality Assurance
QA Contact: Dirk Wiesenthal
URL:
Keywords:
Depends on:
Blocks: 58696
  Show dependency treegraph
 
Reported: 2025-09-10 11:01 CEST by Quality Assurance
Modified: 2025-10-07 12:27 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Security Issue
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Customer ID:
Max CVSS v3 score: 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) NVD


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Quality Assurance univentionstaff 2025-09-10 11:01:26 CEST
New Debian postgresql-15 15.14-0+deb12u1A~5.2.3.202509101046 fixes:
This update addresses the following issues:
* postgresql: PostgreSQL quoting APIs miss neutralizing quoting syntax in  text that fails encoding validation (CVE-2025-1094)
* postgresql: PostgreSQL GB18030 encoding validation can read one byte past  end of allocation for text that fails validation (CVE-2025-4207)
15.14-0+deb12u1 (Wed, 13 Aug 2025 20:13:29 +0200)
* New upstream version 15.14. + Tighten security checks in planner estimation  functions (Dean Rasheed) The fix for CVE-2017-7484, plus followup fixes,  intended to prevent leaky functions from being applied to statistics data  for columns that the calling user does not have permission to read. Two  gaps in that protection have been found. One gap applies to partitioning  and inheritance hierarchies where RLS policies on the tables should  restrict access to statistics data, but did not. The other gap applies to  cases where the query accesses a table via a view, and the view owner has  permissions to read the underlying table but the calling user does not have  permissions on the view. The view owner's permissions satisfied the  security checks, and the leaky function would get applied to the underlying  table's statistics before we check the calling user's permissions on the  view. This has been fixed by making security checks on views occur at the  start of planning. That might cause permissions failures to occur earlier  than before. The PostgreSQL Project thanks Dean Rasheed for reporting this  problem. (CVE-2025-8713) + Prevent pg_dump scripts from being used to  attack the user running the restore (Nathan Bossart) Since dump/restore  operations typically involve running SQL commands as superuser, the target  database installation must trust the source server. However, it does not  follow that the operating system user who executes psql to perform the  restore should have to trust the source server. The risk here is that an  attacker who has gained superuser-level control over the source server  might be able to cause it to emit text that would be interpreted as psql  meta-commands. That would provide shell-level access to the restoring  user's own account, independently of access to the target database. To  provide a positive guarantee that this can't happen, extend psql with a  \restrict command that prevents execution of further meta-commands, and  teach pg_dump to issue that before any data coming from the source server.  The PostgreSQL Project thanks Martin Rakhmanov, Matthieu Denais, and RyotaK  for reporting this problem. (CVE-2025-8714) + Convert newlines to spaces in  names included in comments in pg_dump output (Noah Misch) Object names  containing newlines offered the ability to inject arbitrary SQL commands  into the output script. (Without the preceding fix, injection of psql  meta-commands would also be possible this way.) CVE-2012-0868 fixed this  class of problem at the time, but later work reintroduced several cases.  The PostgreSQL Project thanks Noah Misch for reporting this problem.  (CVE-2025-8715)
Comment 1 Quality Assurance univentionstaff 2025-09-10 12:00:20 CEST
--- mirror/ftp/pool/main/p/postgresql-15/postgresql-15_15.13-0+deb12u1A~5.2.1.202505191944.dsc
+++ apt/ucs_5.2-0-errata5.2-3/source/postgresql-15_15.14-0+deb12u1A~5.2.3.202509101046.dsc
@@ -1,7 +1,65 @@
-15.13-0+deb12u1A~5.2.1.202505191944 [Mon, 19 May 2025 19:44:36 -0000] Univention builddaemon <buildd@univention.de>:
+15.14-0+deb12u1A~5.2.3.202509101046 [Wed, 10 Sep 2025 11:01:35 -0000] Univention builddaemon <buildd@univention.de>:
 
   * UCS auto build. The following patches have been applied to the original source package
     00_version_bump.patch
+
+15.14-0+deb12u1 [Wed, 13 Aug 2025 20:13:29 +0200] Christoph Berg <myon@debian.org>:
+
+  * New upstream version 15.14.
+
+    + Tighten security checks in planner estimation functions (Dean Rasheed)
+
+      The fix for CVE-2017-7484, plus followup fixes, intended to prevent
+      leaky functions from being applied to statistics data for columns that
+      the calling user does not have permission to read.  Two gaps in that
+      protection have been found.  One gap applies to partitioning and
+      inheritance hierarchies where RLS policies on the tables should restrict
+      access to statistics data, but did not.
+
+      The other gap applies to cases where the query accesses a table via a
+      view, and the view owner has permissions to read the underlying table
+      but the calling user does not have permissions on the view. The view
+      owner's permissions satisfied the security checks, and the leaky
+      function would get applied to the underlying table's statistics before
+      we check the calling user's permissions on the view.  This has been
+      fixed by making security checks on views occur at the start of planning.
+      That might cause permissions failures to occur earlier than before.
+
+      The PostgreSQL Project thanks Dean Rasheed for reporting this problem.
+      (CVE-2025-8713)
+
+    + Prevent pg_dump scripts from being used to attack the user running the
+      restore (Nathan Bossart)
+
+      Since dump/restore operations typically involve running SQL commands as
+      superuser, the target database installation must trust the source
+      server.  However, it does not follow that the operating system user who
+      executes psql to perform the restore should have to trust the source
+      server.  The risk here is that an attacker who has gained
+      superuser-level control over the source server might be able to cause it
+      to emit text that would be interpreted as psql meta-commands. That would
+      provide shell-level access to the restoring user's own account,
+      independently of access to the target database.
+
+      To provide a positive guarantee that this can't happen, extend psql with
+      a \restrict command that prevents execution of further meta-commands,
+      and teach pg_dump to issue that before any data coming from the source
+      server.
+
+      The PostgreSQL Project thanks Martin Rakhmanov, Matthieu Denais, and
+      RyotaK for reporting this problem. (CVE-2025-8714)
+
+    + Convert newlines to spaces in names included in comments in pg_dump
+      output (Noah Misch)
+
+      Object names containing newlines offered the ability to inject arbitrary
+      SQL commands into the output script.  (Without the preceding fix,
+      injection of psql meta-commands would also be possible this way.)
+      CVE-2012-0868 fixed this class of problem at the time, but later work
+      reintroduced several cases.
+
+      The PostgreSQL Project thanks Noah Misch for reporting this problem.
+      (CVE-2025-8715)
 
 15.13-0+deb12u1 [Tue, 06 May 2025 17:55:19 +0200] Christoph Berg <myon@debian.org>:
 

<http://piuparts.knut.univention.de/5.2-3/#486902625726127726>
Comment 2 Dirk Wiesenthal univentionstaff 2025-09-11 17:55:17 CEST
OK: YAML
OK: Tests
OK: piuparts
Comment 3 Christian Castens univentionstaff 2025-09-17 14:09:11 CEST
<https://errata.software-univention.de/#/?erratum=5.2x208>