MySQL addresses SQL injection vulnerability

The vulnerability was discovered by the PostgreSQL project and passed to MySQL via the Open Source Database Consortium. The vulnerability lies in the mysql_real_escape_string() function. When unsanitized user-supplied data, such as information taken from a Web form, is stored in a MySQL database, it’s possible for a malicious user to supply a malformed multibyte character that would cause MySQL to execute arbitrary code. According to the announcements:

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.

All releases in the 4.1 and 5.0 series prior to 4.1.20 and 5.0.22 are vulnerable. Users are advised to upgrade to 4.1.20 or 5.0.22 immediately if possible.

For users that are not able or willing to upgrade to MySQL 4.1.20 or 5.0.22, it’s possible to tell MySQL to use SQL standard compatibility mode with regard to backslashes. You can set this by using SET sql_mode='NO_BACKSLASH_ESCAPES'; while the MySQL server is running, by using the --sql-mode=NO_BACKSLASH_ESCAPES option when starting the MySQL server, or including this line in your MySQL configuration file:

sql-mode=NO_BACKSLASH_ESCAPES

The configuration file should be my.cnf on Linux systems. It’s found under /etc/mysql on Debian and Ubuntu systems, and under /etc on Red Hat and Fedora systems.

Updated packages are available from MySQL immediately, and Linux distributions should be issuing updated versions of MySQL soon.