Hi,
MySQL 4.1.20, a new version of the popular Open Source Database
Management System, has been released. The Community Edition is now
available in source and binary form for a number of platforms from our
download pages at
http://dev.mysql.com/downloads/ and mirror sites.
Note that not all mirror sites may be up to date at this point in time -
if you can't find this version on some mirror, please try again later or
choose another download site.
This is a security fix release for the recent production release family.
This release 4.1.20 only includes the security fix described below --
but no other changes and bug fixes relative to the last official MySQL
release 4.1.19. If you would like to receive more fine-grained and
personalised update alerts about fixes that are relevant to the version
and features you use, please consider subscribing to MySQL Network (a
commercial MySQL offering). For more details please see
http://www.mysql.com/network/advisors.html.
We welcome and appreciate your feedback!
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.
For more information about SQL-injection, please see the text below.
Enjoy!
Joerg
---------------------------
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().
--
Joerg Bruehe, Senior Production Engineer
MySQL AB, www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
