MySQL privilege elevation Exploit
This exploit adds a new admin user.
By Kingcope

Tested on
* Debian Lenny (mysql-5.0.51a)
* OpenSuSE 11.4 (5.1.53-log)

How it works:
This exploit makes use of several things:
*The attacker is in possession of a mysql user with 'file' privileges for the target
*So the attacker can create files on the system with this user (owned by user 'mysql')
*So the attacker is able to create TRIGGER files for a mysql table
triggers can be used to trigger an event when a mysql command is executed by the user,
normally triggers are 'attached' to a user and will be executed with this users privilege.
because we can write any contents into the TRG file (the actual trigger file), we write the entry
describing the attached user for the trigger as "root@localhost" what is the default admin user.
* We make use of the stack overrun priorly discovered to flush the server config so the trigger file is recognized.
This step is really important, without crashing the mysql server instance and reconnecting (the server will respawn)
the trigger file would not be recognized.

So what the exploit does is:
* Connect to the MySQL Server
* Create a table named rootme for the trigger
* Create the trigger file in /var/lib/mysql//rootme.TRG
* Crash the MySQL Server to force it to respawn and recognize the trigger file (by triggering the stack overrun)
* INSERT a value into the table so the trigger event gets executed
* The trigger now sets all privileges of the current connecting user in the mysql.user table to enabled.
* Crash the MySQL Server again to force it reload the user configuration
* Create a new mysql user with all privileges set to enabled
* Crash again to reload configuration
* Connect by using the newly created user
* The new connection has ADMIN access now to all databases in mysql
* The user and password hashes in the mysql.user table are dumped for a convinient way to show the exploit succeeded
* As said the user has FULL ACCESS to the database now

Respawning of mysqld is done by mysqld_safe so this is not an issue in any configuration I've seen.
-cut

-for comment

user created for testing (file privs will minor privileges to only one database):

$dbh->do("CREATE USER '$newuser'\@'%' IDENTIFIED BY '$newuserpass';");
$dbh->do("GRANT ALL PRIVILEGES ON *.* TO '$newuser'\@'%' WITH GRANT OPTION;");
$dbh->do("grant all on $a.* to 'user'\@'%' identified by 'secret';");