Bug #1636 Privileges on one database are extended to other data bases on remote access
Submitted: 23 Oct 2003 10:21 Modified: 24 Oct 2003 14:06
Reporter: Dietrich Feist Email Updates:
Status: Closed Impact on me:
Category:MySQL Server Severity:S1 (Critical)
Version:4.1.0-alpha-standard OS:Solaris (Solaris 8)
Assigned to: Sergei Golubchik

[23 Oct 2003 10:21] Dietrich Feist
I have found a serious bug in version 4.1.0. So far, I have only verified it on Solaris 8 but it may be also present in other platforms. Due to this bug, the privileges that a user has on one database can be extended to other databases that have A NAME WITH THE SAME NUMBER OF CHARACTERS. The bug can be exploited locally as well as remotely. It is possible to gain remote root access this way.


You have three databases named 'aaa', 'bbb', 'ccc' on your server. If a user has access rights to the database 'aaa' (the first in alphabetical order, this is important!), he/she will have the same access rights to 'bbb' and 'ccc'. In fact, he/she will have the same access rights on all databases that have a name with exactly three characters. This only works if the user logs in through the TCP/IP port.

How to repeat:
I have only verified this on Solaris 8/Sparc:

- Install a fresh version of 4.1.0-alpha-standard and create the empty default data base with the mysql_install_db script.

- Log in as root and type in the following commands:

USE mysql;
GRANT ALL ON *.* TO 'root'@'localhost';
GRANT ALL ON `aaa`.* TO 'test'@'%';

This will create the three databases and a user 'test' that should only have access to 'aaa'. 

- Verify your actual access rights by connectin through the TCP/IP port. This also works remotely and with clients before MySQL 4.1:

----- Output from 'mysql -h <servername> -u test --password=""' -----
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5 to server version: 4.1.0-alpha-standard-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show grants for test@'%';
| Grants for test@%                             |
| GRANT USAGE ON *.* TO 'test'@'%'              |
| GRANT ALL PRIVILEGES ON `aaa`.* TO 'test'@'%' |
2 rows in set (0.00 sec)

mysql> show databases;
| Database |
| aaa      |
| bbb      |
| ccc      |
3 rows in set (0.00 sec)

[Note: we would only expect to see 'aaa' here!]
mysql> use bbb;
Database changed

mysql> CREATE TABLE illegal ( forbidden int );
Query OK, 0 rows affected (0.01 sec)

[Note: we should not even be able to use this data base!]
| Tables_in_bbb |
| illegal       |
1 row in set (0.00 sec)

mysql> INSERT INTO illegal VALUES( 123 ),( 456 ),( 789 );
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM illegal;
| forbidden |
|       123 |
|       456 |
|       789 |
3 rows in set (0.00 sec)

mysql> DROP TABLE illegal;
Query OK, 0 rows affected (0.01 sec)

mysql> exit
----- End of log file -----


- This does not work if the user has only privileges on 'bbb' or 'ccc'.
- If the user has no access rights on 'aaa', he/she will not be able to access any of the three databases through the TCP/IP port.
- If the user connects through 'localhost', everything works as expected.
- If the database had been called 'aaaaa' instead, the user would have had full access to the 'mysql' data base.

Suggested fix:
Sorry, no idea.
[24 Oct 2003 1:49] Dietrich Feist
One workaround is, of course, to turn off remote access completely. If you don't want to do that, make sure that all your databases with remote access enabled have names of different length. You should also make sure that none of these databases has a name that is 5 characters long, otherwise a a user would get the same access rights on the mysql database.
[24 Oct 2003 2:27] Alexander Keremidarski
We were able to repeat it, but only in some cases so it is not 100% repeatable. It looks like it depends on system configuration.
[24 Oct 2003 14:06] Sergei Golubchik
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at

fixed in 4.1.1
[27 Oct 2003 18:49] tony chen
Bug 242 ?
[31 Oct 2003 0:40] Alexander Keremidarski

Special thanks for pointung us this bug.