A format string vulnerability was found in the way MySQL server used to log user commands, performed by creation and deletion of a database. A valid MySQL user could formulate a specially-crafted SQL command, which would lead to denial of service (mysqld crash) or, potentially execute arbitrary code, with the privileges of the mysql client, when processed by the mysqld daemon. References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536726 http://seclists.org/fulldisclosure/2009/Jul/0058.html
Sweet :-(. The original report is much too conservative about the range of versions exhibiting the bug. I find the same code from 3.23.58 up through 5.0.83. It's also in 5.1.36, although now inside an "#ifdef REMOVED" so I presume the bug is no longer relevant for 5.1.x. Still, that means we have to fix F-10 as well as every active RHEL version. I think the claim of arbitrary code execution is unfounded though. AFAICS the most you could do is get the print function to try to indirect through a pointer (which you don't control) and print the null-terminated string found there. If you were really lucky this might print some data you shouldn't get to see ... except it's going to a system log file that untrusted users shouldn't be allowed to read anyway. So I think denial of service via crashing mysqld is about the most that this could realistically be exploited for. It's also worth noting that you need to be able to connect to the server with "legacy" (3.x era) client-side code, which would likely be a hindrance to someone who hasn't got software installation privileges on the machine he's launching the attack from.
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-2446 to the following vulnerability: Multiple format string vulnerabilities in the dispatch_command function in libmysqld/sql_parse.cc in mysqld in MySQL 4.0.0 through 5.0.83 allow remote authenticated users to cause a denial of service (daemon crash) and possibly have unspecified other impact via format string specifiers in a database name in a (1) COM_CREATE_DB or (2) COM_DROP_DB request. NOTE: some of these details are obtained from third party information. References: ----------- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2446 http://www.securityfocus.com/archive/1/archive/1/504799/100/0/threaded http://archives.neohapsis.com/archives/fulldisclosure/2009-07/0058.html http://www.securityfocus.com/bid/35609 http://www.osvdb.org/55734 http://securitytracker.com/id?1022533 http://secunia.com/advisories/35767 http://xforce.iss.net/xforce/xfdb/51614
Also note you have to have non-default configuration options as well, and a user with privileges to create databases. In /etc/my.cnf you must set: [mysqld] log=/var/log/mysql.log or something similar and you must pre-create the log file. Then you need to be able to connect as a user with privileges to create other databases (i.e. a trusted or semi-trusted user), with authentication. The proof-of-concept noted in the FD posting works if all of those conditions are met. This issue affects Red Hat Enterprise Linux 4 and 5 (I'm assuming version 3 as well but am unable to verify). It also affects Fedora 10. This issue does not affect Fedora 11.
There are a few specific conditions that need to be met before this can become any kind of an issue: 1) An authenticated MySQL user is required with higher-than-typical privileges to CREATE and DROP databases 2) User-command logging must be enabled in /etc/my.conf using "log=/var/log/mysql.log" or similar; this change is not default and must be enabled by an administrator 3) The authenticated MySQL user must connect to the database with some "legacy" client-side code (3.x era) as the vulnerable functions are deprecated and not typically used (COM_CREATE_DB and COM_DROP_DB) If all of these conditions are met, MySQL uses its own minimalist printf function, so only a few format-string specifiers would cause a crash, which would likely terminate all active connections. However, mysqld itself does not crash and will continue to accept subsequent connections. The Red Hat Security Response Team has rated this issue as having low security impact, a future MySQL package update may address this flaw in Red Hat Enterprise Linux 3, 4 and 5, as well as Stacks v2. More information regarding issue severity can be found here: http://www.redhat.com/security/updates/classification/
I find that mysql 5.0.84 contains the fix for this, though they did not admit to it in the release notes.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1289 https://rhn.redhat.com/errata/RHSA-2009-1289.html
This issue has been addressed in following products: Red Hat Web Application Stack for RHEL 5 Via RHSA-2009:1461 https://rhn.redhat.com/errata/RHSA-2009-1461.html
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2010:0110 https://rhn.redhat.com/errata/RHSA-2010-0110.html