Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158688 - CAN-2005-1636 mysql insecure temporary file creation
Summary: CAN-2005-1636 mysql insecure temporary file creation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mysql
Version: 4.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Tom Lane
QA Contact: David Lawrence
URL:
Whiteboard: impact=low,public=20050517,reported=2...
Depends On:
Blocks: 156322
TreeView+ depends on / blocked
 
Reported: 2005-05-24 20:44 UTC by Josh Bressers
Modified: 2013-07-03 03:05 UTC (History)
1 user (show)

Fixed In Version: RHSA-2005-685
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-05 12:44:58 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:685 qe-ready SHIPPED_LIVE Low: mysql security update 2005-10-05 04:00:00 UTC

Description Josh Bressers 2005-05-24 20:44:38 UTC
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

Comment 1 Josh Bressers 2005-05-24 20:45:25 UTC
This issue should also affect RHEL2.1 and RHEL3

Comment 2 Tom Lane 2005-05-24 21:29:34 UTC
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 21:43:18 UTC
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 22:00:43 UTC
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.

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

Comment 6 Josh Bressers 2005-05-24 22:32:10 UTC
Agreed, this can wait until U2.

I'll mail MITRE with the correct version information.

Comment 7 Tom Lane 2005-05-24 22:42:16 UTC
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.

Comment 8 Josh Bressers 2005-06-08 17:34:21 UTC
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 18:39:20 UTC
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 16:52:19 UTC
bug 164647 now covers RHEL3 and RHEL2.1.

Comment 14 Josh Bressers 2005-07-29 16:54:06 UTC
I split the bug in error, this issue does not affect RHEL3 or RHEL2.1

Comment 15 Red Hat Bugzilla 2005-10-05 12:44:59 UTC
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



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