PostgreSQL 7.4 before 7.4.29, 8.0 before 8.0.25, 8.1 before 8.1.21, 8.2 before 8.2.17, 8.3 before 8.3.11, and 8.4 before 8.4.4 does not properly check privileges during certain RESET ALL operations, which allows remote authenticated users to remove arbitrary parameter settings via a (1) ALTER USER or (2) ALTER DATABASE statement.

An integer overflow flaw was found in the way postgresql used to calculate size for the hashtable for joined relations. An attacker could formulate a specially-crafted sql query, which once processed would lead to denial of service (postgresql daemon crash).

Upstream bug report: -------------------- [1] http://archives.postgresql.org/pgsql-bugs/2009-10/msg00277.php

References: ----------- [2] http://archives.postgresql.org/pgsql-bugs/2009-10/msg00287.php [3] http://archives.postgresql.org/pgsql-bugs/2009-10/msg00310.php [4] http://archives.postgresql.org/pgsql-bugs/2009-10/msg00289.php

Upstream patch: --------------- git clone git://git.postgresql.org/git/postgresql.git cd postgresql && git show 64b057e6823655fb6c5d1f24a28f236b94dd6c54

Credit: ------- Bernt Marius Johnsen

A flaw was found in the way the PostgreSQL enforced permission checks on scripts written in PL/Tcl. Once the PL/Tcl procedural language was registered on particular database, a remote, authenticated user, privileged to create databases, running a specially-crafted PL/Tcl script, could use this flaw to bypass intended PL/Tcl trusted mode restrictions, allowing them to run arbitrary Tcl scripts with the privileges of the database server.

References: [1] PostgreSQL PL/Tcl procedural language manual page: http://www.postgresql.org/docs/8.1/interactive/pltcl.html

Safe.pm 2.26 and earlier (except 2.20 through 2.23 if using a threads-enabled Perl), when used in Perl 5.10.0 and earlier, may allow attackers to break out of safe compartment in (1) Safe::reval or (2) Safe::rdo using subroutine references, whose execution is delayed to happen outside of the safe compartment. If a victim was tricked into running a specially-crafted Perl script, using Safe extension module, it could lead to intended Safe module restrictions bypass, if the returned subroutine reference was called from outside of the compartment. Different vulnerability than CVE-2010-1168.

Solution: Ugrade to Safe.pm v2.27 or higher.

References: [1] http://search.cpan.org/~rgarcia/Safe-2.27/Safe.pm

Acknowledgements:

Red Hat would like to thank Tim Bunce for responsibly reporting this flaw. Upstream credits also Rafaël Garcia-Suarez for discovering of this issue.

Intevydis reported a buffer overflow in PostgreSQL's implementation of substring() function when called with negative length argument:

http://intevydis.blogspot.com/2010/01/postgresql-8023-bitsubstr-overflow.html

Following query triggers overflow / crash:

select substring(B'10101010101010101010101010101010101010101010101',33,-15);

A flaw was found in the way the PostgreSQL enforced permission checks on scripts written in PL/Perl. Once the PL/Perl procedural language was registered on particular database, a remote, authenticated user, privileged to create databases, running a specially-crafted PL/Perl script, could use this flaw to bypass intended PL/Perl trusted mode restrictions, allowing them to run arbitrary Perl scripts with the privileges of the database server.

References: [1] PostgreSQL PL/Perl procedural language manual page: http://www.postgresql.org/docs/8.1/interactive/plperl.html [2] PostgreSQL Trusted and Untrusted PL/Perl mode manual page: http://www.postgresql.org/docs/8.1/interactive/plperl-trusted.html

Acknowledgements:

Red Hat would like to thank Tim Bunce for responsibly reporting this issue.

backend/tcop/postgres.c in PostgreSQL 8.1.x before 8.1.5 allows remote authenticated users to cause a denial of service (daemon crash) related to duration logging of V3-protocol Execute messages for (1) COMMIT and (2) ROLLBACK SQL statements.

backend/parser/parsecoerce.c in PostgreSQL 7.4.1 through 7.4.14, 8.0.x before 8.0.9, and 8.1.x before 8.1.5 allows remote authenticated users to cause a denial of service (daemon crash) via a coercion of an unknown element to ANYARRAY.

backend/parser/analyze.c in PostgreSQL 8.1.x before 8.1.5 allows remote authenticated users to cause a denial of service (daemon crash) via certain aggregate functions in an UPDATE statement, which are not properly handled during a "MIN/MAX index optimization."

PostgreSQL 8.1.x before 8.1.4, 8.0.x before 8.0.8, 7.4.x before 7.4.13, 7.3.x before 7.3.15, and earlier versions allows context-dependent attackers to bypass SQL injection protection methods in applications that use multibyte encodings that allow the "\" (backslash) byte 0x5c to be the trailing byte of a multibyte character, such as SJIS, BIG5, GBK, GB18030, and UHC, which cannot be handled correctly by a client that does not understand multibyte encodings, aka a second variant of "Encoding-Based SQL Injection." NOTE: it could be argued that this is a class of issue related to interaction errors between the client and PostgreSQL, but a CVE has been assigned since PostgreSQL is treating this as a preventative measure against this class of problem.

PostgreSQL 8.1.x before 8.1.4, 8.0.x before 8.0.8, 7.4.x before 7.4.13, 7.3.x before 7.3.15, and earlier versions allows context-dependent attackers to bypass SQL injection protection methods in applications via invalid encodings of multibyte characters, aka one variant of "Encoding-Based SQL Injection."

PostgreSQL 7.3.x before 7.3.14, 7.4.x before 7.4.12, 8.0.x before 8.0.7, and 8.1.x before 8.1.3, when compiled with Asserts enabled, allows local users to cause a denial of service (server crash) via a crafted SET SESSION AUTHORIZATION command, a different vulnerability than CVE-2006-0553.

The regular expression parser in TCL before 8.4.17, as used in PostgreSQL 8.2 before 8.2.6, 8.1 before 8.1.11, 8.0 before 8.0.15, and 7.4 before 7.4.19, allows context-dependent attackers to cause a denial of service (infinite loop) via a crafted regular expression.

PostgreSQL 8.1 and probably later versions, when the PL/pgSQL (plpgsql) language has been created, grants certain plpgsql privileges to the PUBLIC domain, which allows remote attackers to create and execute functions, as demonstrated by functions that perform local brute-force password guessing attacks, which may evade intrusion detection.

PostgreSQL 8.1 and probably later versions, when local trust authentication is enabled and the Database Link library (dblink) is installed, allows remote attackers to access arbitrary accounts and execute arbitrary SQL queries via a dblink host parameter that proxies the connection from 127.0.0.1.

The Database Link library (dblink) in PostgreSQL 8.1 implements functions via CREATE statements that map to arbitrary libraries based on the C programming language, which allows remote authenticated superusers to map and execute a function from any library, as demonstrated by using the system function in libc.so.6 to gain shell access.

+++ This bug was initially created as a clone of Bug #237680 +++

Quoting the PostgreSQL release notes: http://www.postgresql.org/docs/8.2/static/release-8-2-4.html

Support explicit placement of the temporary-table schema within searchpath, and disable searching it for functions and operators (Tom)

This is needed to allow a security-definer function to set a truly secure value of searchpath. Without it, an unprivileged SQL user can use temporary objects to execute code with the privileges of the security-definer function (CVE-2007-2138). See CREATE FUNCTION for more information.

This flaw also affects FC5 and FC7

The query planner in PostgreSQL before 8.0.11, 8.1 before 8.1.7, and 8.2 before 8.2.2 does not verify that a table is compatible with a "previously made query plan," which allows remote authenticated users to cause a denial of service (server crash) and possibly access database content via an "ALTER COLUMN TYPE" SQL statement, which can be leveraged to read arbitrary memory from the server.

PostgreSQL 7.3 before 7.3.13, 7.4 before 7.4.16, 8.0 before 8.0.11, 8.1 before 8.1.7, and 8.2 before 8.2.2 allows attackers to disable certain checks for the data types of SQL function arguments, which allows remote authenticated users to cause a denial of service (server crash) and possibly access database content.

A flaw was found in the way PostgreSQL handled SQL functions, created with SECURITY DEFINER keyword and implemented in PL/Perl or PL/Tcl languages. Once the PL/Perl or PL/Tcl procedural language was registered on particular database, a remote, authenticated user, running a specially-crafted PL/Perl or PL/Tcl script could use this flaw to bypass intended PostgreSQL SECURITY DEFINER function definition refinement / protection mechanism, allowing them to run particular PostgreSQL function under their effective user ID, potentially leading to escalation of their privileges.

References: [1] http://www.postgresql.org/docs/8.1/interactive/plperl.html [2] http://www.postgresql.org/docs/8.1/static/pltcl.html [3] http://www.postgresql.org/docs/8.1/interactive/sql-createfunction.html