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.

USN-288-1 described a PostgreSQL client vulnerability in the way the >>'<< character is escaped in SQL queries. It was determined that the PostgreSQL backends of Exim, Dovecot, and Postfix used this unsafe escaping method.

For reference, these are the details of the original USN :

CVE-2006-2313: Akio Ishida and Yasuo Ohgaki discovered a weakness in the handling of invalidly-encoded multibyte text data. If a client application processed untrusted input without respecting its encoding and applied standard string escaping techniques (such as replacing a single quote >>'<< with >>\'<< or >>''<<), the PostgreSQL server could interpret the resulting string in a way that allowed an attacker to inject arbitrary SQL commands into the resulting SQL query. The PostgreSQL server has been modified to reject such invalidly encoded strings now, which completely fixes the problem for some 'safe' multibyte encodings like UTF-8.

CVE-2006-2314: However, there are some less popular and client-only multibyte encodings (such as SJIS, BIG5, GBK, GB18030, and UHC) which contain valid multibyte characters that end with the byte 0x5c, which is the representation of the backslash character >>\<< in ASCII. Many client libraries and applications use the non-standard, but popular way of escaping the >>'<< character by replacing all occurences of it with >>\'<<. If a client application uses one of the affected encodings and does not interpret multibyte characters, and an attacker supplies a specially crafted byte sequence as an input string parameter, this escaping method would then produce a validly-encoded character and an excess >>'<< character which would end the string. All subsequent characters would then be interpreted as SQL code, so the attacker could execute arbitrary SQL commands.

To fix this vulnerability end-to-end, client-side applications must be fixed to properly interpret multibyte encodings and use >>''<< instead of >>\'<<. However, as a precautionary measure, the sequence >>\'<< is now regarded as invalid when one of the affected client encodings is in use. If you depend on the previous behaviour, you can restore it by setting 'backslash_quote = on' in postgresql.conf. However, please be aware that this could render you vulnerable again.

This issue does not affect you if you only use single-byte (like SQL_ASCII or the ISO-8859-X family) or unaffected multibyte (like UTF-8) encodings.

Please see http://www.postgresql.org/docs/techdocs.50 for further details.

Note that Tenable Network Security has extracted the preceding description block directly from the Ubuntu security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

USN-288-1 fixed two vulnerabilities in Ubuntu 5.04 and Ubuntu 5.10.
This update fixes the same vulnerabilities for Ubuntu 6.06 LTS.

For reference, these are the details of the original USN :

CVE-2006-2313: Akio Ishida and Yasuo Ohgaki discovered a weakness in the handling of invalidly-encoded multibyte text data. If a client application processed untrusted input without respecting its encoding and applied standard string escaping techniques (such as replacing a single quote >>'<< with >>\'<< or >>''<<), the PostgreSQL server could interpret the resulting string in a way that allowed an attacker to inject arbitrary SQL commands into the resulting SQL query. The PostgreSQL server has been modified to reject such invalidly encoded strings now, which completely fixes the problem for some 'safe' multibyte encodings like UTF-8.

CVE-2006-2314: However, there are some less popular and client-only multibyte encodings (such as SJIS, BIG5, GBK, GB18030, and UHC) which contain valid multibyte characters that end with the byte 0x5c, which is the representation of the backslash character >>\<< in ASCII. Many client libraries and applications use the non-standard, but popular way of escaping the >>'<< character by replacing all occurences of it with >>\'<<. If a client application uses one of the affected encodings and does not interpret multibyte characters, and an attacker supplies a specially crafted byte sequence as an input string parameter, this escaping method would then produce a validly-encoded character and an excess >>'<< character which would end the string. All subsequent characters would then be interpreted as SQL code, so the attacker could execute arbitrary SQL commands.

To fix this vulnerability end-to-end, client-side applications must be fixed to properly interpret multibyte encodings and use >>''<< instead of >>\'<<. However, as a precautionary measure, the sequence >>\'<< is now regarded as invalid when one of the affected client encodings is in use. If you depend on the previous behaviour, you can restore it by setting 'backslash_quote = on' in postgresql.conf. However, please be aware that this could render you vulnerable again.

This issue does not affect you if you only use single-byte (like SQL_ASCII or the ISO-8859-X family) or unaffected multibyte (like UTF-8) encodings.

Please see http://www.postgresql.org/docs/techdocs.50 for further details.

Note that Tenable Network Security has extracted the preceding description block directly from the Ubuntu security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

1.7.11 : fbsql :

  - Fixed commit and rollback to specify the handle to be     used.

1.7.10 : mysqli :

  - Added a type map for BIT fields.

1.7.9 : sybase :

  - Added divide by zero error mapping.

    - Added a specific quoteFloat() implementation along the       same lines as fbsql.

    - Updated tableInfo() to cope with old versions of ASE       that don't have sp_helpindex.

1.7.8 : DB :

  - Added code to DB_result::numRows() to return correct     results when limit emulation is being used.

  - Added DB::getDSNString() to allow pretty-printing of     both string and array DSNs, thereby improving the output     of DB::connect() on error.

  - Added DB_common::nextQueryIsManip() to explicitly hint     that the next query is a manipulation query and     therefore ignore DB::isManip()

  - Changed all freeResult() methods to check that the     parameter is a resource before calling the native     function to free the result.

  - Fixed DB_result::fetch*() to only increment their     internal row_counters when a row number has not been     provided.

  - Fixed quoting of float values to always have the decimal     point as a point, rather than a comma, irrespective of     locale.

  - Silenced errors on ini_set calls.

    - Tweaked DB::isManip() to attempt to deal with SELECT       queries that include the word INTO in a non-keyword       context.

fbsql :

  - Fix DB_result::numRows() to return the correct value for     limit queries.

ibase :

  - Handled cases where ibase_prepare returns false.

ifx :

  - Altered simpleQuery() to treat EXECUTE queries as being     data-returning.

mssql :

  - Altered nextId() to use IDENT_CURRENT instead of     @@IDENTITY, thereby resolving problems with concurrent     nextId() calls.

mysqli :

  - Added the mysterious 246 data type to the type map.

    - Allowed the ssl option to be an integer

oci8 :

  - Added tracking of prepared queries to ensure that     last_query is set properly even when there are multiple     prepared queries at a given time.

    - Altered connect() to handle non-standard ports.

    - Altered numRows() to properly restore last_query       state.

pgsql :

  - Added schema support to _pgFieldFlags.

    - Updated pgsql escaping to use pg_escape_string when       available.

1.7.7 : DB :

  - added ability to specify port number when using unix     sockets in DB::parseDSN()

odbc(access) :

  - Tweak quoteSmart() to allows MS Access to wrap dates in     #'s.

dbase :

  - Added DB_dbase::freeResult().

ifx :

  - Added support for error codes as at Informix 10.

msql :

  - Fix error mapping in PHP 5.2.

mssql :

  - Use mssql_fetch_assoc() instead of mssql_fetch_array().

    - Fix issues with delimited identifiers in mssql       tableInfo().

    - Added support for some of the key error codes       introduced in SQL Server 2005.

mysql :

  - fixed handling of fully qualified table names in     tableInfo().

    - Added support for new error codes in MySQL 5.

mysqli :

  - worked around an issue in 'len' handling of tableInfo().
    There is a bug in ext/mysqli or the mysqli docs.

    - Added support for new error codes in MySQL 5.

oci8 :

  - Allowed old-style functions to use the database DSN     field if hostspec isn't provided.

pgsql :

  - When inserting to non-existent column, produce proper     error, 'no such field', instead of 'no such table'.

  - If connection is lost, raise DB_ERROR_CONNECT_FAILED     instead of the generic DB_ERROR.

  - Allow FETCH queries to return results.

sqlite :

  - Fix bug sqlite:///:memory: trys to open file.

    - Fix error mapping in PHP 5.2.

sybase :

  - Allow connecting without specifying db name.

    - Fix error mapping in PHP 5.2.

storage :

  - Eliminate 'Undefined index $vars' notice in store()

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

This update fixes a security problem that allowed attackers to inject SQL commands into queries (CVE-2006-2313, CVE-2006-2314).

Dovecot might have been affected by the multibyte character set SQL injection issues for instance described in CVE-2006-2314.

This patch fixes the MySQL and PostgreSQL backend to use the correct quoting methods when passing user-supplied strings.

Several encoding problems have been discovered in PostgreSQL, a popular SQL database. The Common Vulnerabilities and Exposures project identifies the following problems :

  - CVE-2006-2313     Akio Ishida and Yasuo Ohgaki discovered a weakness in     the handling of invalidly-encoded multibyte text data     which could allow an attacker to inject arbitrary SQL     commands.

  - CVE-2006-2314     A similar problem exists in client-side encodings (such     as SJIS, BIG5, GBK, GB18030, and UHC) which contain     valid multibyte characters that end with the backslash     character. An attacker could supply a specially crafted     byte sequence that is able to inject arbitrary SQL     commands.

  This issue does not affect you if you only use single-byte (like   SQL_ASCII or the ISO-8859-X family) or unaffected multibyte (like   UTF-8) encodings.

  psycopg and python-pgsql use the old encoding for binary data and   may have to be updated.

The old stable distribution (woody) is affected by these problems but we're unable to correct the package.

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.

The remote host is affected by the vulnerability described in GLSA-200607-04 (PostgreSQL: SQL injection)

    PostgreSQL contains a flaw in the string parsing routines that allows     certain backslash-escaped characters to be bypassed with some multibyte     character encodings. This vulnerability was discovered by Akio Ishida     and Yasuo Ohgaki.
  Impact :

    An attacker could execute arbitrary SQL statements on the PostgreSQL     server. Be aware that web applications using PostgreSQL as a database     back-end might be used to exploit this vulnerability.
  Workaround :

    There is no known workaround at this time.

Updated postgresql packages that fix several security vulnerabilities are now available for Red Hat Enterprise Linux 3 and 4.

This update has been rated as having important security impact by the Red Hat Security Response Team.

PostgreSQL is an advanced Object-Relational database management system (DBMS).

A bug was found in the way PostgreSQL's PQescapeString function escapes strings when operating in a multibyte character encoding. It is possible for an attacker to provide an application a carefully crafted string containing invalidly-encoded characters, which may be improperly escaped, allowing the attacker to inject malicious SQL.
While this update fixes how PQescapeString operates, the PostgreSQL server has also been modified to prevent such an attack occurring through unpatched clients. (CVE-2006-2313, CVE-2006-2314). More details about this issue are available in the linked PostgreSQL technical documentation.

An integer signedness bug was found in the way PostgreSQL generated password salts. The actual salt size is only half the size of the expected salt, making the process of brute forcing password hashes slightly easier. This update will not strengthen already existing passwords, but all newly assigned passwords will have the proper salt length. (CVE-2006-0591)

Users of PostgreSQL should upgrade to these updated packages containing PostgreSQL version 7.4.13, which corrects these issues.

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.' (CVE-2006-2313)

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. (CVE-2006-2314)

Packages have been patched or updated to correct these issues.

CVE-2006-2313: Akio Ishida and Yasuo Ohgaki discovered a weakness in the handling of invalidly-encoded multibyte text data. If a client application processed untrusted input without respecting its encoding and applied standard string escaping techniques (such as replacing a single quote >>'<< with >>\'<< or >>''<<), the PostgreSQL server could interpret the resulting string in a way that allowed an attacker to inject arbitrary SQL commands into the resulting SQL query. The PostgreSQL server has been modified to reject such invalidly encoded strings now, which completely fixes the problem for some 'safe' multibyte encodings like UTF-8.

CVE-2006-2314: However, there are some less popular and client-only multibyte encodings (such as SJIS, BIG5, GBK, GB18030, and UHC) which contain valid multibyte characters that end with the byte 0x5c, which is the representation of the backslash character >>\<< in ASCII. Many client libraries and applications use the non-standard, but popular way of escaping the >>'<< character by replacing all occurences of it with >>\'<<. If a client application uses one of the affected encodings and does not interpret multibyte characters, and an attacker supplies a specially crafted byte sequence as an input string parameter, this escaping method would then produce a validly-encoded character and an excess >>'<< character which would end the string.
All subsequent characters would then be interpreted as SQL code, so the attacker could execute arbitrary SQL commands.

To fix this vulnerability end-to-end, client-side applications must be fixed to properly interpret multibyte encodings and use >>''<< instead of >>\'<<. However, as a precautionary measure, the sequence >>\'<< is now regarded as invalid when one of the affected client encodings is in use. If you depend on the previous behaviour, you can restore it by setting 'backslash_quote = on' in postgresql.conf. However, please be aware that this could render you vulnerable again.

This issue does not affect you if you only use single-byte (like SQL_ASCII or the ISO-8859-X family) or unaffected multibyte (like UTF-8) encodings.

Please see http://www.postgresql.org/docs/techdocs.50 for further details.

The psycopg and python-pgsql packages have been updated to consistently use >>''<< for escaping quotes in strings.

Note that Tenable Network Security has extracted the preceding description block directly from the Ubuntu security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote host is running PostgreSQL, an open source relational database.  This version is vulnerable to a SQL Injection flaw when passed properly formatted SQL queries coupled with invalidly-encoded multibyte data.  An attacker exploiting this flaw would need to be able to send queries to the PostgreSQL server. As such, this exploit typically requires authentication.  Successful exploitation would result in the attacker executing arbitrary SQL commands on the database server. 

ID	Name	Product	Family	Severity
27859	Ubuntu 5.04 / 5.10 / 6.06 LTS : dovecot, exim4, postfix vulnerabilities (USN-288-3)	Nessus	Ubuntu Local Security Checks	high
27858	Ubuntu 6.06 LTS : postgresql-8.1 vulnerabilities (USN-288-2)	Nessus	Ubuntu Local Security Checks	high
27656	Fedora 7 : php-pear-DB-1.7.11-1.fc7 (2007-0249)	Nessus	Fedora Local Security Checks	high
27402	openSUSE 10 Security Update : postgresql-server (postgresql-server-1442)	Nessus	SuSE Local Security Checks	high
27400	openSUSE 10 Security Update : postgresql (postgresql-1443)	Nessus	SuSE Local Security Checks	high
27200	openSUSE 10 Security Update : dovecot (dovecot-1987)	Nessus	SuSE Local Security Checks	high
22629	Debian DSA-1087-1 : postgresql - programming error	Nessus	Debian Local Security Checks	high
22208	FreeBSD : postgresql -- encoding based SQL injection (17f53c1d-2ae9-11db-a6e2-000e0c2e438a)	Nessus	FreeBSD Local Security Checks	high
22011	GLSA-200607-04 : PostgreSQL: SQL injection	Nessus	Gentoo Local Security Checks	high
21905	CentOS 3 / 4 : postgresql (CESA-2006:0526)	Nessus	CentOS Local Security Checks	high
21670	Mandrake Linux Security Advisory : postgresql (MDKSA-2006:098)	Nessus	Mandriva Local Security Checks	high
21613	Ubuntu 5.04 / 5.10 : postgresql-7.4/-8.0, postgresql, psycopg, (USN-288-1)	Nessus	Ubuntu Local Security Checks	high
3632	PostgreSQL SQL Injection	Nessus Network Monitor	Database	high
21595	RHEL 3 / 4 : postgresql (RHSA-2006:0526)	Nessus	Red Hat Local Security Checks	high

Detections

Analytics

CVE-2006-2314

critical

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high

high

high

high