Bug 543619 (CVE-2008-7247) - CVE-2008-7247 MySQL: Intended access restrictions bypass
Summary: CVE-2008-7247 MySQL: Intended access restrictions bypass
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2008-7247
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://bugs.mysql.com/bug.php?id=39277
Whiteboard: impact=low,source=internet,reported=2...
Depends On: 549329
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-02 18:16 UTC by Jan Lieskovsky
Modified: 2019-06-08 12:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-29 10:06:48 UTC


Attachments (Terms of Use)

Description Jan Lieskovsky 2009-12-02 18:16:21 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2008-7247 to
the following vulnerability:

sql/sql_table.cc in MySQL 5.0.x through 5.0.88, 5.1.x through 5.1.41,
and 6.0 before 6.0.9-alpha, when the data home directory contains a
symlink to a different filesystem, allows remote authenticated users
to bypass intended access restrictions by calling CREATE TABLE with a
(1) DATA DIRECTORY or (2) INDEX DIRECTORY argument referring to a
subdirectory that requires following this symlink.

References:
-----------
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-7247
http://lists.mysql.com/commits/59711
http://marc.info/?l=oss-security&m=125908040022018&w=2
http://bugs.mysql.com/bug.php?id=39277

Upstream patch:
---------------
http://lists.mysql.com/commits/59711

Comment 2 Jan Lieskovsky 2009-12-02 18:21:35 UTC
This issue does NOT affect the versions of the mysql package, as shipped
with Red Hat Enterprise Linux 3, 4, or 5.

This issue does NOT affect the version of the mysql package, as shipped
with Fedora release of 10.

This issue affects the versions of the mysql package, as shipped with
Fedora release of 11 and 12.

Comment 3 Tom Lane 2009-12-02 18:23:30 UTC
So how would a symlink get in there?  This doesn't seem like a serious problem at first glance.

Comment 4 Tomas Hoger 2009-12-03 15:48:35 UTC
Can anyone help me understand what issue is really referred to using this CVE?

This is the description from MySQL changelogs:

  When the data directory contained a symbolic link to another file
  system, and the DATA DIRECTORY or INDEX DIRECTORY clause of a CREATE
  TABLE statement referred to a subdirectory of the data directory,
  this was accepted, when for security reasons it should be rejected.

I don't yet see a reason why "another file system" is relevant here, it seems any symlink out of datadir should do.

Otherwise, I read that description as:
- /var/lib/mysql contains a symlink e.g. foo pointing out of /var/lib/mysql
- /var/lib/mysql/foo is used as DATA or INDEX DIRECTORY for CREATE TABLE
- table creation is allowed while reject is expected

I'm not sure if the expectation is correct, given that realpath will return a path without symlinks which is out of datadir (/var/lib/mysql).  Anyway, this like an odd corner case that can only be hit if the symlink is created manually.


However, that description does not seem to match the initial description of the upstream bug, or the description of the upstream commit:

  http://lists.mysql.com/commits/91835

+      data_file_name and index_file_name include the table name without
+      extension. Mostly this does not refer to an existing file. When
+      comparing data_file_name or index_file_name against the data
+      directory, we try to resolve all symbolic links. On some systems,
+      we use realpath(3) for the resolution. This returns ENOENT if the
+      resolved path does not refer to an existing file. my_realpath()
+      does then copy the requested path verbatim, without symlink
+      resolution. Thereafter the comparison can fail even if the
+      requested path is within the data directory.

My testing with 5.0.77 (EL5) shows that data_file_name / index_file_name does *not* contain the table name when they are passed to test_if_data_home_dir(), table name is only appended after.  The code does look different in 5.1.x (and possibly later), but if test_if_data_home_dir() is called with parameter including table name, that should be a complete regression of CVE-2008-4098 fix in those versions.


Upstream bug also points out another interesting case, which does not seem to be addressed via the mentioned upstream patch - test case #2 in:

  http://bugs.mysql.com/file.php?id=10707&text=1

which allows user with CREATE/DROP privileges to any database to destroy tables in any other database using something like:

  mkdir /tmp/bad
  mysql> create table somedb.user (c1 int) data directory '/tmp/bad'
         index directory '/tmp/bad';
  rm -rf /tmp/bad
  ln -s /var/lib/mysql/mysql /tmp/bad
  mysql> drop table somedb.user;

This does seem to work fine on 5.0.77.

Comment 5 Tomas Hoger 2009-12-04 14:39:58 UTC
(In reply to comment #4)
> My testing with 5.0.77 (EL5) shows that data_file_name / index_file_name does
> *not* contain the table name when they are passed to test_if_data_home_dir(),
> table name is only appended after.  The code does look different in 5.1.x
> (and possibly later), but if test_if_data_home_dir() is called with parameter
> including table name, that should be a complete regression of CVE-2008-4098
> fix in those versions.

I did a re-test with 5.1.39 (F12) and test_if_data_home_dir() does indeed get called with table name without extension appended to the user-supplied path.  This sounds like a regression on CVE-2008-4098 to me and has nothing to do with symlinks inside the datadir, as any symlink will do (like /tmp/evil -> /var/lib/mysql/mysql).  But 5.1.39 does not allow overwriting of existing database files.

Comment 10 Tomas Hoger 2009-12-21 09:38:29 UTC
Note: this is not fixed in 5.1.41.

Comment 12 Tom Lane 2010-01-08 22:03:43 UTC
Per bug #553653, we've now disabled symlinks by default for F13 and EL6.  This doesn't fix the vulnerability for existing installations, but it should at least reduce our exposure to this type of issue in future.

Comment 15 Fedora Update System 2010-01-29 23:17:00 UTC
mysql-5.1.42-7.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mysql-5.1.42-7.fc12

Comment 16 Fedora Update System 2010-01-29 23:17:05 UTC
mysql-5.1.42-7.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mysql-5.1.42-7.fc11

Comment 17 Fedora Update System 2010-02-02 01:06:41 UTC
mysql-5.1.42-7.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2010-02-02 01:18:17 UTC
mysql-5.1.42-7.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


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