mysql_install_db in MySQL 4.x before 4.0.12 and 5.x up to 5.0.4 creates the mysql_install_db.X file with a predictable filename and insecure permissions, which allows local users to execute arbitrary SQL commands by modifying the file's contents. More information is in the full-disclosure post: http://marc.theaimsgroup.com/?l=full-disclosure&m=111632686805498&w=2
This issue should also affect RHEL2.1 and RHEL3
Actually, if the report of versions affected is accurate, it *only* affects RHEL2.1 and RHEL3, since RHEL4 uses MySQL 4.1 and up. It's not clear from the report whether MySQL 3.x is affected, but I suppose we'd better take a look.
Well, evidently the report is not accurate, because 4.0.12 is a couple years old :-(. I suppose he is referring to 4.1.12 which was released last week. There is nothing about this in the 4.1.12 release notes, though. Perhaps that is MySQL's standard practice for security bugs? Seems odd.
Tom, I just did some poking around in mysql 4.1.12 and 4.0.24, neither seem to have any temp file handling in mysql_install_db.
I just finished diff'ing 4.1.11 and 4.1.12, and there *is* temp file usage in 4.1.11 which has been removed in 4.1.12, and the file change date coincides with the timeline mentioned in the advisory. So now we know: MySQB AB are willing to sneak undocumented security fixes into new releases. There is no temp file usage in mysql 3.x's version of this script, so we have no issue in RHEL2.1 or RHEL3, but the issue seems indeed to exist for RHEL4 and FC3 ... also FC4. However, having looked at the code I think the problem is pretty minor. The faulty code looks like tmp_file=/tmp/mysql_install_db.$$ ... echo "use mysql;" > $tmp_file cat $tmp_file $fill_help_tables | eval "$mysqld_install_cmd_line" so the exploit requires being able to alter the temp file between the echo and the immediately following cat, which is a pretty tiny time interval. My advice is to rate this as a low-impact problem and leave it to be fixed when we update to 4.1.12, which we already intended to do in RHEL4 U2.
Agreed, this can wait until U2. I'll mail MITRE with the correct version information.
Actually, wait a second. I was thinking that the echo would necessarily overwrite the temp file, but if the script were being executed as non-root then the attacker could set up a temp file in advance that's readable but not writable by the script user. So the risk is bigger than I first thought. Our mysql init script does execute mysql_install_db as root, so the risk is small again if you allow the init script to create the database for you, but there is risk for people who do manual database setup. Not sure if that's enough reason to make a security update or not. I'm still leaning to "not", but it's debatable.
We've currently rated this issue as "moderate". If it's a likely scenario that a non root user would be running mysql_install_db, then we should keep it moderate, but if this is something that is going to be very uncommon then I think we can safely call this low and wait to realease an update. If we keep this issue moderate we will want to roll an update in the near future.
AFAIK, we don't consider running with a non-default database to be a supported thing to do --- for starters, SELinux won't let you unless you alter the policy. So my bet is that everyone just uses the default database created by mysql's initscript, and thus it'd be reasonable to recategorize this as "low impact".
bug 164647 now covers RHEL3 and RHEL2.1.
I split the bug in error, this issue does not affect RHEL3 or RHEL2.1
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-685.html