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.

So how would a symlink get in there?  This doesn't seem like a serious problem at first glance.

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.

(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.

Note: this is not fixed in 5.1.41.

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.

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

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

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.

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.