FreshPorts - VuXML

The PostgreSQL project reports:

Versions Affected: 9.4 - 11

Given a suitable `SECURITY DEFINER` function, an attacker can execute arbitrary SQL under the identity of the function owner. An attack requires `EXECUTE` permission on the function, which must itself contain a function call having inexact argument type match. For example, `length('foo'::varchar)` and `length('foo')` are inexact, while `length('foo'::text)` is exact. As part of exploiting this vulnerability, the attacker uses `CREATE DOMAIN` to create a type in a `pg_temp` schema. The attack pattern and fix are similar to that for CVE-2007-2138.

Writing `SECURITY DEFINER` functions continues to require following the considerations noted in the documentation:

https://www.postgresql.org/docs/devel/sql-createfunction.html#SQL-CREATEFUNCTION-SECURITY

Versions Affected: 11

In a database containing hypothetical, user-defined hash equality operators, an attacker could read arbitrary bytes of server memory. For an attack to become possible, a superuser would need to create unusual operators. It is possible for operators not purpose-crafted for attack to have the properties that enable an attack, but we are not aware of specific examples.

< 11.5

< 10.10

< 9.6.15

< 9.5.19

< 9.4.24

The PostgreSQL project reports:

CVE-2018-16850: SQL injection in pg_upgrade and pg_dump, via CREATE TRIGGER ... REFERENCING.

Using a purpose-crafted trigger definition, an attacker can run arbitrary SQL statements with superuser privileges when a superuser runs pg_upgrade on the database or during a pg_dump dump/restore cycle. This attack requires a CREATE privilege on some non-temporary schema or a TRIGGER privilege on a table. This is exploitable in the default PostgreSQL configuration, where all users have CREATE privilege on public schema.

< 10.6

< 9.6.11

< 9.5.15

< 9.4.20

< 9.3.25

The PostgreSQL project reports:

PostgreSQL maintains statistics for tables by sampling data available in columns; this data is consulted during the query planning process. Prior to this release, a user able to execute SQL queries with permissions to read a given column could craft a leaky operator that could read whatever data had been sampled from that column. If this happened to include values from rows that the user is forbidden to see by a row security policy, the user could effectively bypass the policy. This is fixed by only allowing a non-leakproof operator to use this data if there are no relevant row security policies for the table.

< 11.3

< 10.8

< 9.6.13

< 9.5.17