FreshPorts - VuXML

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

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 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:

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

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:

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:

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:

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 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 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

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:

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:

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:

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:

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:

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:

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:

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:

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:

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

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:

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:

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:

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 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