Bug 543619 - (CVE-2008-7247) CVE-2008-7247 MySQL: Intended access restrictions bypass
CVE-2008-7247 MySQL: Intended access restrictions bypass
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
http://bugs.mysql.com/bug.php?id=39277
impact=low,source=internet,reported=2...
: Security
Depends On: 549329
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-02 13:16 EST by Jan Lieskovsky
Modified: 2010-03-29 06:06 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-29 06:06:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2009-12-02 13:16:21 EST
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 13:21:35 EST
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 13:23:30 EST
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 10:48:35 EST
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 09:39:58 EST
(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 04:38:29 EST
Note: this is not fixed in 5.1.41.
Comment 12 Tom Lane 2010-01-08 17:03:43 EST
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 18:17:00 EST
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 18:17:05 EST
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-01 20:06:41 EST
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-01 20:18:17 EST
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.