Debian Bug report logs - #369735
Security: SQL-injection with multibyte encoding

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Christian Hammers <ch@debian.org>
To: submit@bugs.debian.org
Subject: Security: SQL-injection with multibyte encoding
Date: Thu, 1 Jun 2006 00:48:20 +0200

package: mysql-server-4.1
severity: grave
justification: security hole

Just for reference, the DSA is already in preparation.

-christian-

On 2006-05-31 Joerg Bruehe wrote:
> Bugs fixed:
>     * Security fix: An SQL-injection security hole has been found in
>       multibyte encoding processing. The bug was in the server,
>       incorrectly parsing the string escaped with mysql_real_escape().
> 
>       This vulnerability was discovered and reported by Josh Berkus
>       <josh@postgresql.org> and Tom Lane <tgl@sss.pgh.pa.us> as part of
>       the inter-project security collaboration of the OSDB consortium.

> Discussion
> An SQL-injection security hole has been found in multibyte encoding
> processing. An SQL-injection security hole can include a situation
> whereby when inserting user supplied data into a database, the user
> might inject his own SQL statements that the server will execute.
> With regards to this vulnerability discovered, when character set
> unaware escaping is used (e.g., addslashes() in PHP), it is possible
> to bypass it in some multibyte character sets (e.g., SJIS, BIG5 and
> GBK). As a result, a function like addslashes() is not able to
> prevent SQL injection attacks. It is impossible to fix this on the
> server side. The best solution is for applications to use character
> set aware escaping offered in a function like mysql_real_escape().
> 
> However, a bug has been detected in how the server parses the output
> of mysql_real_escape(). As a result, even when the character set
> aware function mysql_real_escape() was used, SQL injection was
> possible. This bug has been fixed.
> 
> 
> Workarounds
> One can use NO_BACKSLASH_ESCAPES mode as a workaround for a bug in
> mysql_real_escape_string(), if you cannot upgrade your server for
> some reason. It will enable SQL standard compatibility mode, where
> backslash is not considered a special character. To set this mode,
> enter the follow SQL statement on the server:
> 
>     SET sql_mode='NO_BACKSLASH_ESCAPES';
> 
> You can also set it globally for all clients, using
>     SET GLOBAL sql_mode='NO_BACKSLASH_ESCAPES';
> 
> It can also be enabled automatically when the server starts by using the
> command-line option --sql-mode=NO_BACKSLASH_ESCAPES or by setting
> sql-mode=NO_BACKSLASH_ESCAPES in the server options file
> (e.g., my.cnf or my.ini, depending on your system).
> 
> Backslash then becomes an ordinary character like any other. The
> result will be that queries will fail.
> This mode was implemented in MySQL version 5.0.1.
> 
> 
> Solution
> This vulnerability of mysql_real_escape_string() is fixed in the
> latest certified binary releases of 4.1.16a and 5.0.17c, as well as in
> MySQL versions 4.1.20, 5.0.22, and 5.1.11-beta (not yet released).
> 
> A function which is unaware of character sets (e.g., addslashes() in
> PHP) should not be used for escaping. Rather, use one which is character
> set aware, like mysql_real_escape_string().

Message #16 received at 369735-done@bugs.debian.org (full text, mbox):

From: Christian Hammers <ch@debian.org>
To: 369754-done@bugs.debian.org, 369741-done@bugs.debian.org,
 369735-done@bugs.debian.org
Subject: Fixed this bug
Date: Thu, 08 Jun 2006 23:47:10 +0200

MySQL 3.23 and 4.0 were never vulnerable (see
packagers@lists.mysql.com), 4.1 was fixed today in DSA 1092 and 5.0 had
already been uploaded.

bye,

-christian-

Send a report that this bug log contains spam.