Bug 511020 - (CVE-2009-2446) CVE-2009-2446 MySQL: Format string vulnerability by manipulation with database instances (crash)
CVE-2009-2446 MySQL: Format string vulnerability by manipulation with databas...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 512196 512197 512198 512199 512200 512201 512255 512257
  Show dependency treegraph
Reported: 2009-07-13 05:48 EDT by Jan Lieskovsky
Modified: 2015-03-30 14:34 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2009-07-13 05:48:21 EDT
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

Comment 1 Tom Lane 2009-07-13 12:33:57 EDT
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.
Comment 2 Jan Lieskovsky 2009-07-13 13:22:34 EDT
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.

Comment 3 Vincent Danen 2009-07-14 18:16:13 EDT
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:


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.
Comment 30 Vincent Danen 2009-07-17 16:54:59 EDT
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:

Comment 35 Tom Lane 2009-08-02 22:38:42 EDT
I find that mysql 5.0.84 contains the fix for this, though they did not admit to it in the release notes.
Comment 36 errata-xmlrpc 2009-09-02 05:45:33 EDT
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
Comment 38 errata-xmlrpc 2009-09-23 17:39:04 EDT
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
Comment 39 errata-xmlrpc 2010-02-16 11:27:47 EST
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

Note You need to log in before you can comment on or make changes to this bug.