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).
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
<firstname.lastname@example.org>and Tom Lane
<email@example.com>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
However, a bug was detected in how the MySQL server parses the output of
mysql_real_escape_string(). As a result, even when the character set-aware function
mysql_real_escape_string()was used, SQL injection was possible. This bug has been fixed.
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_ESCAPESSQL mode as a workaround. (This mode was introduced in MySQL 5.0.1.)
NO_BACKSLASH_ESCAPESenables 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:
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_ESCAPESor by setting
sql-mode=NO_BACKSLASH_ESCAPESin the server option file (for example,
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)
The client libraries were not compiled for position-independent code on Solaris-SPARC and AMD x86_64 platforms. (Bug #18091, Bug #13159, Bug #14202)
Running myisampack followed by myisamchk with the
--unpackoption would corrupt the
AUTO_INCREMENTkey. (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