I was wondering if we really took care of this one, as apparently a corner case was recently found and fixed : =========================================================== Ubuntu Security Notice USN-109-1 April 06, 2005 mysql-dfsg vulnerability CAN-2004-0957 =========================================================== [...] USN-32-1 fixed a database privilege escalation vulnerability; original advisory text: "If a user was granted privileges to a database with a name containing an underscore ("_"), the user also gained the ability to grant privileges to other databases with similar names. (CAN-2004-0957)" Recently a corner case was discovered where this vulnerability can still be exploited, so another update is necessary. =====================================================
You mean Bug 83163? I really hope this is fixed ;-) (it turned out to be actually phpmyadmin problem - Bug 83792)
I was just wondering why Debian, Ubuntu and Mandriva issued updated advisories saying they fixed it (like we did) but a new corner case was recently discovered so they re-fixed it (like we didn't). Maybe our MySQL is simply not affected by this, just keeping this open until someone can confirm it (probably by looking at the Debian/Ubuntu patches)
There definitely is something up here... http://packages.qa.debian.org/m/mysql-dfsg.html Debian released a mysql-dfsg_4.0.24-5 to fix this. http://dev.mysql.com/doc/mysql/en/news-4-0-25.html MySQL lists that bug in the not-yet-released 4.0.25 Changelog. I'll isolate the 4.0.24-5 patch from eth Debian thing so that our MySQL guys can have a look.
Created attachment 56533 [details, diff] mysql_CAN-2004-0957_new.patch Patch extracted from Debian's diffs...
I can't reproduce it on 4.0.24. Command sequence: # mysql -uroot -p.... > CREATE DATABASE something_com; Query OK, 1 row affected (0.01 sec) > GRANT SELECT ON something_com.* TO someone@localhost IDENTIFIED BY 'someo ne'; Query OK, 0 rows affected (0.00 sec) > QUIT; # mysql -usomeone -psomeone > CREATE DATABASE `something?com`; ERROR 1044: Access denied for user: 'someone@localhost' to database 'something?com' (and create table is properly secured as well). I also tested with the someone user just having the 'USAGE' privilege, and that doesn't even give them access to something_com, which is correct.
Closed as worksforyou then.
