77 Changes in MySQL 5.0.22 (2006-05-24)

This is a security fix release for the previous production release
family.

This section documents all changes and bug fixes that have been applied since the last official MySQL release. If you would like to receive more fine-grained and personalized update alerts about fixes that are relevant to the version and features you use, please consider subscribing to MySQL Enterprise (a commercial MySQL offering). For more details, please see (http://www.mysql.com/products/enterprise).

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 the
mysql_real_escape_string() C API
function.

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. For more
information about SQL injection, please see the following text.

Discussion.
An SQL injection security hole has been found in multibyte
encoding processing. An SQL injection security hole can
include a situation whereby when a user supplied data to be
inserted into a database, the user might inject SQL statements
into the data that the server will execute. With regards to
this vulnerability, when character set-unaware escaping is
used (for example, addslashes() in PHP), it
is possible to bypass the escaping in some multibyte character
sets (for example, SJIS, BIG5 and GBK). As a result, a
function such as 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 by a function such
mysql_real_escape_string().

Workarounds.
If you are unable to upgrade MySQL to a version that includes
the fix for the bug in
mysql_real_escape_string()
parsing, but run MySQL 5.0.1 or higher, you can use the
NO_BACKSLASH_ESCAPES SQL
mode as a workaround. (This mode was introduced in MySQL
5.0.1.) NO_BACKSLASH_ESCAPES
enables an SQL standard compatibility mode, where backslash is
not considered a special character. The result will be that
queries will fail.

To set this mode for the current connection, enter the following
SQL statement:

SET sql_mode='NO_BACKSLASH_ESCAPES';

You can also set the mode globally for all clients:

SET GLOBAL sql_mode='NO_BACKSLASH_ESCAPES';

This SQL mode also can 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 option file (for example,
my.cnf or my.ini,
depending on your system).
(Bug #8378, CVE-2006-2753)

References: See also: Bug #8303.

Replication:
The dropping of a temporary table whose name contained a
backtick ('`') character was not correctly
written to the binary log, which also caused it not to be
replicated correctly.
(Bug #19188)

Running myisampack followed by
myisamchk with the
--unpack option would corrupt
the AUTO_INCREMENT key.
(Bug #12633)

The patch for Bug #8303 broke the fix for Bug #8378 and was
reverted.

In string literals with an escape character
(\) followed by a multibyte character that
had (\) as its second byte, the literal was
not interpreted correctly. Now only next byte now is escaped,
and not the entire multibyte character. This means it is a
strict reverse of the
mysql_real_escape_string()
function.