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.

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.

PostgreSQL 8.1.0 through 8.1.2 allows authenticated database users to gain additional privileges via "knowledge of the backend protocol" using a crafted SET ROLE to other database users, a different vulnerability than CVE-2006-0678.

Any logged-in database user who has the ability to create tables and functions (which in most installations will be everybody) can acquire database superuser privilege, which means he can make the server process do whatever he wants.

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.

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