Bug 158688 - CAN-2005-1636 mysql insecure temporary file creation
CAN-2005-1636 mysql insecure temporary file creation
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mysql (Show other bugs)
All Linux
medium Severity low
: ---
: ---
Assigned To: Tom Lane
David Lawrence
: Security
Depends On:
Blocks: 156322
  Show dependency treegraph
Reported: 2005-05-24 16:44 EDT by Josh Bressers
Modified: 2013-07-02 23:05 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHSA-2005-685
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-05 08:44:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:685 qe-ready SHIPPED_LIVE Low: mysql security update 2005-10-05 00:00:00 EDT

  None (edit)
Description Josh Bressers 2005-05-24 16:44:38 EDT
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:
Comment 1 Josh Bressers 2005-05-24 16:45:25 EDT
This issue should also affect RHEL2.1 and RHEL3
Comment 2 Tom Lane 2005-05-24 17:29:34 EDT
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.
Comment 3 Tom Lane 2005-05-24 17:43:18 EDT
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.
Comment 4 Josh Bressers 2005-05-24 18:00:43 EDT

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.
Comment 5 Tom Lane 2005-05-24 18:29:28 EDT
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

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.
Comment 6 Josh Bressers 2005-05-24 18:32:10 EDT
Agreed, this can wait until U2.

I'll mail MITRE with the correct version information.
Comment 7 Tom Lane 2005-05-24 18:42:16 EDT
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 
Comment 8 Josh Bressers 2005-06-08 13:34:21 EDT
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.
Comment 9 Tom Lane 2005-06-08 14:39:20 EDT
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".
Comment 13 Josh Bressers 2005-07-29 12:52:19 EDT
bug 164647 now covers RHEL3 and RHEL2.1.
Comment 14 Josh Bressers 2005-07-29 12:54:06 EDT
I split the bug in error, this issue does not affect RHEL3 or RHEL2.1
Comment 15 Red Hat Bugzilla 2005-10-05 08:44:59 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.