VuXML ID | Description |
17f53c1d-2ae9-11db-a6e2-000e0c2e438a | postgresql -- encoding based SQL injection
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.
Discovery 2006-05-11 Entry 2006-08-13 postgresql
postgresql-server
ja-postgresql
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
18092
CVE-2006-2313
CVE-2006-2314
http://www.postgresql.org/docs/techdocs.50
|
486aff57-9ecd-11da-b410-000e0c2e438a | postgresql -- character conversion and tsearch2 vulnerabilities
The postgresql development team reports:
The more severe of the two errors is that the functions
that support client-to-server character set conversion
can be called from SQL commands by unprivileged users,
but these functions are not designed to be safe against
malicious choices of argument values. This problem exists
in PostgreSQL 7.3.* through 8.0.*. The recommended fix is
to disable public EXECUTE access for these functions. This
does not affect normal usage of the functions for character
set conversion, but it will prevent misuse.
The other error is that the contrib/tsearch2 module
misdeclares several functions as returning type "internal"
when they do not have any "internal" argument. This breaks
the type safety of "internal" by allowing users to
construct SQL commands that invoke other functions accepting
"internal" arguments. The consequences of this have not been
investigated in detail, but it is certainly at least possible
to crash the backend.
Discovery 2005-05-02 Entry 2006-02-16 postgresql
ge 7.2.0 lt 7.2.8
ge 7.3.0 lt 7.3.10
ge 7.4.0 lt 7.4.8
ge 8.0.0 lt 8.0.3
CAN-2005-1409
CAN-2005-1410
http://www.postgresql.org/about/news.315
|
51436b4c-1250-11dd-bab7-0016179b2dd5 | postgresql -- multiple vulnerabilities
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.
Discovery 2008-01-06 Entry 2008-04-24 postgresql
postgresql-server
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
CVE-2007-6600
CVE-2007-4772
CVE-2007-6067
CVE-2007-4769
CVE-2007-6601
27163
http://www.postgresql.org/about/news.905
|
5d425189-7a03-11d9-a9e7-0001020eed82 | postgresql -- privilege escalation vulnerability
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.
Discovery 2005-01-21 Entry 2005-02-08 postgresql
postgresql-server
ja-postgresql
< 7.3.9
gt 7.4.* lt 7.4.7
gt 8.* lt 8.0.1
postgresql-devel
le 8.0.1,1
12411
CVE-2005-0227
http://archives.postgresql.org/pgsql-announce/2005-02/msg00000.php
http://archives.postgresql.org/pgsql-bugs/2005-01/msg00269.php
|
65c8ecf9-2adb-11db-a6e2-000e0c2e438a | postgresql -- multiple vulnerabilities
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.
Discovery 2005-02-01 Entry 2006-08-13 postgresql
postgresql-server
ja-postgresql
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
CVE-2005-0244
CVE-2005-0245
CVE-2005-0246
http://secunia.com/advisories/12948
|
6b4b0b3f-8127-11d9-a9e7-0001020eed82 | postgresql -- multiple buffer overflows in PL/PgSQL parser
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.
Discovery 2005-02-07 Entry 2005-02-17 Modified 2005-02-19 postgresql
postgresql-server
ja-postgresql
< 7.3.9_1
gt 7.4.* lt 7.4.7_1
gt 8.* lt 8.0.1_1
CVE-2005-0247
http://archives.postgresql.org/pgsql-committers/2005-02/msg00049.php
|