FreshPorts - VuXML

PostgreSQL Project reports:

While modifying certain SQL array values, missing overflow checks let authenticated database users write arbitrary bytes to a memory area that facilitates arbitrary code execution. Missing overflow checks also let authenticated database users read a wide area of server memory. The CVE-2021-32027 fix covered some attacks of this description, but it missed others.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports:

Certain aggregate function calls receiving "unknown"-type arguments could disclose bytes of server memory from the end of the "unknown"-type value to the next zero byte. One typically gets an "unknown"-type value via a string literal having no type designation. We have not confirmed or ruled out viability of attacks that arrange for presence of notable, confidential information in disclosed bytes.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports

This enabled an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. Database owners have that right by default, and explicit grants may extend it to other users.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

PostgreSQL Project reports:

While modifying certain SQL array values, missing overflow checks let authenticated database users write arbitrary bytes to a memory area that facilitates arbitrary code execution. Missing overflow checks also let authenticated database users read a wide area of server memory. The CVE-2021-32027 fix covered some attacks of this description, but it missed others.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports:

While modifying certain SQL array values, missing overflow checks let authenticated database users write arbitrary bytes to a memory area that facilitates arbitrary code execution. Missing overflow checks also let authenticated database users read a wide area of server memory. The CVE-2021-32027 fix covered some attacks of this description, but it missed others.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports

This enabled an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. Database owners have that right by default, and explicit grants may extend it to other users.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

PostgreSQL Project reports

While CVE-2016-2193 fixed most interaction between row security and user ID changes, it missed a scenario involving function inlining. This 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.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

PostgreSQL Project reports:

Certain aggregate function calls receiving "unknown"-type arguments could disclose bytes of server memory from the end of the "unknown"-type value to the next zero byte. One typically gets an "unknown"-type value via a string literal having no type designation. We have not confirmed or ruled out viability of attacks that arrange for presence of notable, confidential information in disclosed bytes.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports:

Documentation says the pg_cancel_backend role cannot signal "a backend owned by a superuser". On the contrary, it can signal background workers, including the logical replication launcher. It can signal autovacuum workers and the autovacuum launcher. Signaling autovacuum workers and those two launchers provides no meaningful exploit, so exploiting this vulnerability requires a non-core extension with a less-resilient background worker. For example, a non-core background worker that does not auto-restart would experience a denial of service with respect to that particular background worker.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports

PostgreSQL 15 introduced the MERGE command, which fails to test new rows against row security policies defined for UPDATE and SELECT. If UPDATE and SELECT policies forbid some row that INSERT policies do not forbid, a user could store such rows. Subsequent consequences are application-dependent. This affects only databases that have used CREATE POLICY to define a row security policy.

< 15.4

PostgreSQL Project reports:

One step of a concurrent refresh command was run under weak security restrictions. If a materialized view's owner could persuade a superuser or other high-privileged user to perform a concurrent refresh on that view, the view's owner could control code executed with the privileges of the user running REFRESH. The fix for the vulnerability makes is so that all user-determined code is run as the view's owner, as expected.

< 15.6

< 14.11

< 13.14

< 12.18

PostgreSQL Project reports

While CVE-2016-2193 fixed most interaction between row security and user ID changes, it missed a scenario involving function inlining. This 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.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

The PostgreSQL developers report:

PostgreSQL allows users to create indexes on the results of user-defined functions, known as "expression indexes". This provided two vulnerabilities to privilege escalation: (1) index functions were executed as the superuser and not the table owner during VACUUM and ANALYZE, and (2) that SET ROLE and SET SESSION AUTHORIZATION were permitted within index functions. Both of these holes have now been closed.

PostgreSQL allowed malicious users to initiate a denial-of-service by passing certain regular expressions in SQL queries. First, users could create infinite loops using some specific regular expressions. Second, certain complex regular expressions could consume excessive amounts of memory. Third, out-of-range backref numbers could be used to crash the backend.

DBLink functions combined with local trust or ident authentication could be used by a malicious user to gain superuser privileges. This issue has been fixed, and does not affect users who have not installed DBLink (an optional module), or who are using password authentication for local access. This same problem was addressed in the previous release cycle, but that patch failed to close all forms of the loophole.

ge 7.3 lt 7.3.21

ge 7.4 lt 7.4.19

ge 8.0 lt 8.0.15

ge 8.1 lt 8.1.11

ge 8.2 lt 8.2.6

PostgreSQL Project reports:

Documentation says the pg_cancel_backend role cannot signal "a backend owned by a superuser". On the contrary, it can signal background workers, including the logical replication launcher. It can signal autovacuum workers and the autovacuum launcher. Signaling autovacuum workers and those two launchers provides no meaningful exploit, so exploiting this vulnerability requires a non-core extension with a less-resilient background worker. For example, a non-core background worker that does not auto-restart would experience a denial of service with respect to that particular background worker.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports:

Certain aggregate function calls receiving "unknown"-type arguments could disclose bytes of server memory from the end of the "unknown"-type value to the next zero byte. One typically gets an "unknown"-type value via a string literal having no type designation. We have not confirmed or ruled out viability of attacks that arrange for presence of notable, confidential information in disclosed bytes.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports

This enabled an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. Database owners have that right by default, and explicit grants may extend it to other users.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

PostgreSQL Project reports

An extension script is vulnerable if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). No bundled extension is vulnerable. Vulnerable uses do appear in a documentation example and in non-bundled extensions. Hence, the attack prerequisite is an administrator having installed files of a vulnerable, trusted, non-bundled extension. Subject to that prerequisite, this enables an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. PostgreSQL will block this attack in the core server, so there's no need to modify individual extensions.

< 11.21

< 12.16

< 13.12

< 14.9

< 15.4

PostgreSQL Project reports:

One step of a concurrent refresh command was run under weak security restrictions. If a materialized view's owner could persuade a superuser or other high-privileged user to perform a concurrent refresh on that view, the view's owner could control code executed with the privileges of the user running REFRESH. The fix for the vulnerability makes is so that all user-determined code is run as the view's owner, as expected.

< 15.6

< 14.11

< 13.14

< 12.18

PostgreSQL Project reports:

While modifying certain SQL array values, missing overflow checks let authenticated database users write arbitrary bytes to a memory area that facilitates arbitrary code execution. Missing overflow checks also let authenticated database users read a wide area of server memory. The CVE-2021-32027 fix covered some attacks of this description, but it missed others.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports:

While modifying certain SQL array values, missing overflow checks let authenticated database users write arbitrary bytes to a memory area that facilitates arbitrary code execution. Missing overflow checks also let authenticated database users read a wide area of server memory. The CVE-2021-32027 fix covered some attacks of this description, but it missed others.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports

An extension script is vulnerable if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). No bundled extension is vulnerable. Vulnerable uses do appear in a documentation example and in non-bundled extensions. Hence, the attack prerequisite is an administrator having installed files of a vulnerable, trusted, non-bundled extension. Subject to that prerequisite, this enables an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. PostgreSQL will block this attack in the core server, so there's no need to modify individual extensions.

< 11.21

< 12.16

< 13.12

< 14.9

< 15.4

PostgreSQL Project reports:

This update fixes CVE-2014-0060, in which PostgreSQL did not properly enforce the WITH ADMIN OPTION permission for ROLE management. Before this fix, any member of a ROLE was able to grant others access to the same ROLE regardless if the member was given the WITH ADMIN OPTION permission. It also fixes multiple privilege escalation issues, including: CVE-2014-0061, CVE-2014-0062, CVE-2014-0063, CVE-2014-0064, CVE-2014-0065, and CVE-2014-0066. More information on these issues can be found on our security page and the security issue detail wiki page.

With this release, we are also alerting users to a known security hole that allows other users on the same machine to gain access to an operating system account while it is doing "make check": CVE-2014-0067. "Make check" is normally part of building PostgreSQL from source code. As it is not possible to fix this issue without causing significant issues to our testing infrastructure, a patch will be released separately and publicly. Until then, users are strongly advised not to run "make check" on machines where untrusted users have accounts.

< 8.4.20

ge 9.0.0 lt 9.0.16

ge 9.1.0 lt 9.1.12

ge 9.2.0 lt 9.2.7

ge 9.3.0 lt 9.3.3

PostgreSQL Project reports:

One step of a concurrent refresh command was run under weak security restrictions. If a materialized view's owner could persuade a superuser or other high-privileged user to perform a concurrent refresh on that view, the view's owner could control code executed with the privileges of the user running REFRESH. The fix for the vulnerability makes is so that all user-determined code is run as the view's owner, as expected.

< 15.6

< 14.11

< 13.14

< 12.18

PostgreSQL Project reports:

Documentation says the pg_cancel_backend role cannot signal "a backend owned by a superuser". On the contrary, it can signal background workers, including the logical replication launcher. It can signal autovacuum workers and the autovacuum launcher. Signaling autovacuum workers and those two launchers provides no meaningful exploit, so exploiting this vulnerability requires a non-core extension with a less-resilient background worker. For example, a non-core background worker that does not auto-restart would experience a denial of service with respect to that particular background worker.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports:

One step of a concurrent refresh command was run under weak security restrictions. If a materialized view's owner could persuade a superuser or other high-privileged user to perform a concurrent refresh on that view, the view's owner could control code executed with the privileges of the user running REFRESH. The fix for the vulnerability makes is so that all user-determined code is run as the view's owner, as expected.

< 15.6

< 14.11

< 13.14

< 12.18

PostgreSQL Project reports

While CVE-2016-2193 fixed most interaction between row security and user ID changes, it missed a scenario involving function inlining. This 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.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

PostgreSQL Project reports:

Documentation says the pg_cancel_backend role cannot signal "a backend owned by a superuser". On the contrary, it can signal background workers, including the logical replication launcher. It can signal autovacuum workers and the autovacuum launcher. Signaling autovacuum workers and those two launchers provides no meaningful exploit, so exploiting this vulnerability requires a non-core extension with a less-resilient background worker. For example, a non-core background worker that does not auto-restart would experience a denial of service with respect to that particular background worker.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports

While CVE-2016-2193 fixed most interaction between row security and user ID changes, it missed a scenario involving function inlining. This 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.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

The PostgreSQL development team reports:

An attacker able to submit crafted strings to an application that will embed those strings in SQL commands can use invalidly-encoded multibyte characters to bypass standard string-escaping methods, resulting in possible injection of hostile SQL commands into the database. The attacks covered here work in any multibyte encoding.

The widely-used practice of escaping ASCII single quote "'" by turning it into "\'" is unsafe when operating in multibyte encodings that allow 0x5c (ASCII code for backslash) as the trailing byte of a multibyte character; this includes at least SJIS, BIG5, GBK, GB18030, and UHC. An application that uses this conversion while embedding untrusted strings in SQL commands is vulnerable to SQL-injection attacks if it communicates with the server in one of these encodings. While the standard client libraries used with PostgreSQL have escaped "'" in the safe, SQL-standard way of "''" for some time, the older practice remains common.

ge 7.3 lt 7.3.15

ge 7.4 lt 7.4.13

ge 8.0.0 lt 8.0.8

ge 8.1.0 lt 8.1.4

PostgreSQL Project reports:

Certain aggregate function calls receiving "unknown"-type arguments could disclose bytes of server memory from the end of the "unknown"-type value to the next zero byte. One typically gets an "unknown"-type value via a string literal having no type designation. We have not confirmed or ruled out viability of attacks that arrange for presence of notable, confidential information in disclosed bytes.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports:

While modifying certain SQL array values, missing overflow checks let authenticated database users write arbitrary bytes to a memory area that facilitates arbitrary code execution. Missing overflow checks also let authenticated database users read a wide area of server memory. The CVE-2021-32027 fix covered some attacks of this description, but it missed others.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports

An extension script is vulnerable if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). No bundled extension is vulnerable. Vulnerable uses do appear in a documentation example and in non-bundled extensions. Hence, the attack prerequisite is an administrator having installed files of a vulnerable, trusted, non-bundled extension. Subject to that prerequisite, this enables an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. PostgreSQL will block this attack in the core server, so there's no need to modify individual extensions.

< 11.21

< 12.16

< 13.12

< 14.9

< 15.4

PostgreSQL Project reports:

Documentation says the pg_cancel_backend role cannot signal "a backend owned by a superuser". On the contrary, it can signal background workers, including the logical replication launcher. It can signal autovacuum workers and the autovacuum launcher. Signaling autovacuum workers and those two launchers provides no meaningful exploit, so exploiting this vulnerability requires a non-core extension with a less-resilient background worker. For example, a non-core background worker that does not auto-restart would experience a denial of service with respect to that particular background worker.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports

An extension script is vulnerable if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). No bundled extension is vulnerable. Vulnerable uses do appear in a documentation example and in non-bundled extensions. Hence, the attack prerequisite is an administrator having installed files of a vulnerable, trusted, non-bundled extension. Subject to that prerequisite, this enables an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. PostgreSQL will block this attack in the core server, so there's no need to modify individual extensions.

< 11.21

< 12.16

< 13.12

< 14.9

< 15.4

PostgreSQL Project reports

This enabled an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. Database owners have that right by default, and explicit grants may extend it to other users.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

PostgreSQL Project reports

This enabled an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. Database owners have that right by default, and explicit grants may extend it to other users.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

PostgreSQL Project reports:

Certain aggregate function calls receiving "unknown"-type arguments could disclose bytes of server memory from the end of the "unknown"-type value to the next zero byte. One typically gets an "unknown"-type value via a string literal having no type designation. We have not confirmed or ruled out viability of attacks that arrange for presence of notable, confidential information in disclosed bytes.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports

An extension script is vulnerable if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, '', or ""). No bundled extension is vulnerable. Vulnerable uses do appear in a documentation example and in non-bundled extensions. Hence, the attack prerequisite is an administrator having installed files of a vulnerable, trusted, non-bundled extension. Subject to that prerequisite, this enables an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. PostgreSQL will block this attack in the core server, so there's no need to modify individual extensions.

< 11.21

< 12.16

< 13.12

< 14.9

< 15.4

PostgreSQL Project reports

While CVE-2016-2193 fixed most interaction between row security and user ID changes, it missed a scenario involving function inlining. This 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.

< 15.3

< 14.8

< 13.11

< 12.15

< 11.20

PostgreSQL Project reports:

Documentation says the pg_cancel_backend role cannot signal "a backend owned by a superuser". On the contrary, it can signal background workers, including the logical replication launcher. It can signal autovacuum workers and the autovacuum launcher. Signaling autovacuum workers and those two launchers provides no meaningful exploit, so exploiting this vulnerability requires a non-core extension with a less-resilient background worker. For example, a non-core background worker that does not auto-restart would experience a denial of service with respect to that particular background worker.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22

PostgreSQL Project reports:

Certain aggregate function calls receiving "unknown"-type arguments could disclose bytes of server memory from the end of the "unknown"-type value to the next zero byte. One typically gets an "unknown"-type value via a string literal having no type designation. We have not confirmed or ruled out viability of attacks that arrange for presence of notable, confidential information in disclosed bytes.

< 16.1

< 15.5

< 14.10

< 13.13

< 12.17

< 11.22