Message-ID: <44734ABE.10802@postgresql.org>
Date: Tue, 23 May 2006 19:47:42 +0200
From: PostgreSQL Security <security@...tgresql.org>
To: bugtraq@...urityfocus.com
Subject: PostgreSQL security releases 8.1.4, 8.0.8, 7.4.13, 7.3.15


PostgreSQL versions 8.1.4, 8.0.8, 7.4.13 and 7.3.15 have been released 
fixing two security issues.


Details of vulnerability 1
--------------------------
Vulnerability type: SQL Injection
Remotely exploitable: Depends on client

Affected versions: PostgreSQL 8.1.0-8.1.3, 8.0.0-8.0.7,
                               7.4.0-7.4.12, 7.3.0-7.3.14
Fixed versions: PostgreSQL 8.1.4, 8.0.8, 7.4.13, 7.3.15

Affected platforms: All

CVE: CVE-2006-2313 
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2313)


Vulnerability description
-------------------------
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.


Details of vulnerability 2
--------------------------
Vulnerability type: SQL Injection
Remotely exploitable: Depends on client

Affected versions: PostgreSQL 8.1.0-8.1.3, 8.0.0-8.0.7,
                               7.4.0-7.4.12, 7.3.0-7.3.14
Fixed versions: PostgreSQL 8.1.4, 8.0.8, 7.4.13, 7.3.15

Affected platforms: All

CVE: CVE-2006-2314 
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2314)


Vulnerability description
-------------------------
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.  As of PostgreSQL versions 8.1.4, 8.0.8, 7.4.13 and 7.3.15, the 
server has been modified to reject "\'" when the client is using one of 
these encodings.
This does NOT in itself fix all variants of the problem, but it will 
make it obvious that such a client is broken and in need of repair.


More information is available on the PostgreSQL website at 
http://www.postgresql.org/docs/techdocs.52.



Solution
--------
Upgrade to version 8.1.4, 8.0.8, 7.4.13 or 7.3.15 respectively, 
available from http://www.postgresql.org/ftp/ in both source and binary 
  formats.


Mitigating factors
------------------
* If client_encoding is a single-byte encoding (e.g., one of the
   LATINx family), there is no vulnerability.

* If both client and server encoding is UTF8, there is no vulnerability.

* If application always sends untrusted strings as out-of-line
   parameters, instead of embedding them into SQL commands, it is not
   vulnerable. This is only available in PostgreSQL 7.4 or later.

* If application cannot pass invalidly encoded data to the server,
   there is no vulnerability (this probably includes all Java and .Net
   applications, for example, because of the platforms handling of
   Unicode strings).


Workarounds
-----------
* Changing to a non-multibyte client_encoding will protect against
   both vulnerabilities.

* Changing to UTF8 encoding and upgrading to a fixed version of
   PostgreSQL will protect the system without client side changes.


Credits
-------
The PostgreSQL Global Development Group thanks Akio Ishida and Yasuo 
Ohgaki for reporting these vulnerabilities.

Powered by blists - more mailing lists