FreshPorts - VuXML

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:

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:

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:

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

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

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

BugTraq reports:

PostgreSQL is prone to a buffer-overflow vulnerability because the application fails to perform adequate boundary checks on user-supplied data.

Attackers can exploit this issue to execute arbitrary code with elevated privileges or crash the affected application.

ge 7.4 lt 7.4.28

ge 8.0 lt 8.0.24

ge 8.1 lt 8.1.20

ge 8.2 lt 8.2.16

ge 8.3 lt 8.3.10

ge 8.4 lt 8.4.3

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

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

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:

PostgreSQL 7.4.x before 7.4.27, 8.0.x before 8.0.23, 8.1.x before 8.1.19, 8.2.x before 8.2.15, 8.3.x before 8.3.9, and 8.4.x before 8.4.2 does not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which (1) allows man-in-the-middle attackers to spoof arbitrary SSL-based PostgreSQL servers via a crafted server certificate issued by a legitimate Certification Authority, and (2) allows remote attackers to bypass intended client-hostname restrictions via a crafted client certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.

PostgreSQL 7.4.x before 7.4.27, 8.0.x before 8.0.23, 8.1.x before 8.1.19, 8.2.x before 8.2.15, 8.3.x before 8.3.9, and 8.4.x before 8.4.2 does not properly manage session-local state during execution of an index function by a database superuser, which allows remote authenticated users to gain privileges via a table with crafted index functions, as demonstrated by functions that modify (1) search_path or (2) a prepared statement, a related issue to CVE-2007-6600 and CVE-2009-3230.

ge 7.4 lt 7.4.27

ge 8.0 lt 8.0.23

ge 8.1 lt 8.1.19

ge 8.2 lt 8.2.15

ge 8.3 lt 8.3.9

ge 8.4 lt 8.4.2

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

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

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

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

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:

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

Multiple vulnerabilities had been reported in various versions of PostgreSQL:

• The EXECUTE restrictions can be bypassed by using the AGGREGATE function, which is missing a permissions check.
• A buffer overflow exists in gram.y which could allow an attacker to execute arbitrary code by sending a large number of arguments to a refcursor function, found in gram.y
• The intagg contributed module allows an attacker to crash the server (Denial of Service) by constructing a malicious crafted array.

ge 7.2 lt 7.2.7

ge 7.3 lt 7.3.9

ge 7.4 lt 7.4.7

ge 8.0.0 lt 8.0.1

The PL/PgSQL parser in postgresql is vulnerable to several buffer overflows. These could be exploited by a remote attacker to execute arbitrary code with the permissions of the postgresql server by running a specially crafted query.

< 7.3.9_1

gt 7.4.* lt 7.4.7_1

gt 8.* lt 8.0.1_1

John Heasman and others disovered that non-privileged users could use the LOAD extension to load arbitrary libraries into the postgres server process space. This could be used by non-privileged local users to execute arbitrary code with the privileges of the postgresql server.

< 7.3.9

gt 7.4.* lt 7.4.7

gt 8.* lt 8.0.1

le 8.0.1,1

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

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

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:

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

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

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:

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:

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:

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