Your message dated Thu, 08 Jun 2006 23:47:10 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Fixed this bug
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
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
> <[EMAIL PROTECTED]> and Tom Lane <[EMAIL PROTECTED]> 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().
--- End Message ---
--- Begin Message ---
MySQL 3.23 and 4.0 were never vulnerable (see
[EMAIL PROTECTED]), 4.1 was fixed today in DSA 1092 and 5.0 had
already been uploaded.
bye,
-christian-
--- End Message ---
