Hello, Just take a look on mysql_install_db line 14 tmp_file=/tmp/mysql_install_db.$$ Then on : 226 echo "use mysql;" > $tmp_file 227 cat $tmp_file $fill_help_tables | eval "$mysqld_install_cmd_line" 228 res=$? 229 rm $tmp_file It's possible to run a TOCTOU, or race condition, that permit to a malicious local user to inject SQL code into the mysql installation. For exemple : creating a user with ALL rights. What you think about ? Regards. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: tmp_file=/tmp/mysql_install_db.$$ don't use mktemp and umask Expected Results: tmp_file=/tmp/mysql_install_db.$$ shoudl use mktemp and unmask
Auditors please advise.
What version of mysql have you found this in? Latest available is 4.0.24 and I don't see it there, and the only one more recent is 4.1.8 which is ~arch and package.mask'd.
Hello, Yes, is 4.1.8 how is considered stable by mysql since q long time :) Regards.
TOCTOU (time of check to time of use) I've checked /usr/bin/mysql_install_db from mysql-5.0.4_beta probably it's the same for all the other versions. The TOCTOU it's not possible because only the name of the tmp file is defined early. >>>echo "use mysql;" > $tmp_file"<<< This line write/overwrite the temp file, immediately after the temp file is used to create the db's. ---> no time from "check" to "use" please close as INVALID
Hello, it's still possible to inject SQL code in the temporary file how is not created securely. This is maybe not a TOCTOU but a race condition. Regards.
Francesco: You're correct, this is not a TOCTOU bug, however it does appear to be an insecure tmp handling bug, pid's are easily guessed on most systems, and an attacker could use a linking attack to overwrite or create a file with the permissions of the user running the script, or if he controls the file there is a race condition where he can insert arbitrary mysql commands into the script prior to it being piped into mysql. I've confirmed this in 4.1.8, does not seem to appear in 4.0.24.
Hello, I confirm the vulnerability in mysql 4.1.11 the last mysql release avaible from MySQL web site. Regards.
Upstream informed. Mysql do you prefer to wait for an upstream fix or patch yourself?
Created attachment 58346 [details, diff] mysql_emktemp-4.1.11.patch Please try and comment the attached patch, it can be applied both at build time (modifying the ebuild) or to an already installed /usr/bin/mysql_install_db. Never tested.
Hello, I have patch the original file, work great. The installation test like this mysql_install_db --datadir=/tmp/mysql works, the right are good applied Tomorrow i will test it on a running mysql server. Regards.
Hello again, This files stay's in the /tmp -rw------- 1 root root 0 May 8 15:29 tmp.XXXX1v9b6p -rw------- 1 root root 11 May 8 15:29 tmp.XXXX6sbldZ -rw------- 1 root root 0 May 8 15:31 tmp.XXXXBI2pxY tmp="${topdir}/tmp.${RANDOM}.${RANDOM}.${RANDOM}" the first ${RANDOM} is not applied and the date are strange :) Regards.
Created attachment 58452 [details, diff] mysql-4.1.11-install_db_tmp.patch This instead is the MySQL patch, expect a new version at bug 83011 before tomorrow (with this one)
Answer from upstream: http://mysql.bkbits.net:8080/mysql-4.1/cset@1.2250?nav=index.html|ChangeSet@-1d The fix will be part of the upcoming 4.1.12 and 5.0.6 releases.
4.1.12 is in the tree now (hard-masked as previous 4.1 releases)
Hi, In the changelog : scripts/mysql_install_db.sh 1.72 05/05/09 09:21:49 serg@sergbook.mylan +1 -4 don't use tmp file for such a triviality Regards.
Hello, MySQL 5.0.x still vulnerable. Published under : http://www.zataz.net/adviso/mysql-05172005.txt Regards.
Robin any ETA on when this can be unmasked as ~? Romang did you inform upstream, or should I inform them that MySQL 5 is still vulnerable?
Robin, just saw your mail. 20th of May is planned unmask date.
jaervosz: I think you mis-read the email. 4.0.24-r2 will go ~arch on 20 May. 4.1* has never been out of the hard-mask yet. This might happen in early June, depending how well the larger scale testing goes. 5.0* isn't even in the tree.
Thx for clearing that up Robin. Then we're ready to close.
