MySQL Bugs: #32091: Partitions: Security Breach via directory changes

Bug #32091	Partitions: Security Breach via directory changes
Submitted:	4 Nov 2007 21:03	Modified:	15 Nov 2007 14:52
Reporter:	Peter Gulutzan	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Partitions	Severity:	S1 (Critical)
Version:	5.1.23-rc-debug	OS:	Linux (SUSE 10 64-bit)
Assigned to:	Mattias Jonsson	CPU Architecture:	Any

Description:
As root, I grant USAGE on test.* to joe@localhost.
As root, I create a table cuckoo in database k.
As joe@localhost, I create a table cuckoo in database test,
with partitioning, with DATA DIRECTORY and INDEX DIRECTORY
clauses pointing to '/usr/local/mysql/var/k'.
(The value of @@datadir is '/usr/local/mysql/var'.)
As joe@localhost, I remove the partitioning.
As joe@localhost, I insert '44' in test.cuckoo.
As root, I select from k.cuckoo.
The result is: '44'.

So anybody with privileges on test.* can change
any table in any database.

How to repeat:
As root, say:
SELECT @@datadir;
If this doesn't say /usr/local/mysql/var, then adjust
occurrence of '/usr/local/mysql/var' accordingly for
the subsequent instructions.

As root, say:
GRANT USAGE ON test.* TO joe@localhost;
CREATE DATABASE k;
USE k
CREATE TABLE cuckoo (s1 INT);

As joe@localhost, say:
USE test
CREATE TABLE cuckoo (s1 INT)
PARTITION BY LIST (s1)
(PARTITION p1 VALUES IN (1)
 DATA DIRECTORY '/usr/local/mysql/var/k'
 INDEX DIRECTORY '/usr/local/mysql/var/k');
ALTER TABLE cuckoo REMOVE PARTITIONING;
INSERT INTO cuckoo VALUES (44);

As root, say:
USE k
SELECT * FROM cuckoo;

The bug is that when reparsing the partitioning clause it sets the DATA and INDEX DIRECTORY for the table from the first partition.

I will probably remove the possibility to have DATA/INDEX DIR in BOTH the table clause AND the partitioning clause. (have to verify how this works, maybe disallow DATA/INDEX dir for the table clause at all, only allowing it for the partitioning clause when using partitions)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

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

ChangeSet@1.2605, 2007-11-06 18:09:21+01:00, mattiasj@mattiasj-laptop.(none) +3 -0
  Bug#32091: Security breach via directory changes
  
  Problem: the table's INDEX and DATA DIR was taken
    directly from the tables first partition,
    and opening for a rename attack similar to
    bug#32111 when ALTER TABLE REMOVE PARTITIONING
  
  Solution: Silently ignore (like some other storage
    engines) the INDEX/DATA DIR for the table.
    (Only use INDEX/DATA DIR for each partitions,
    not for the whole table)

IMHO we would be much better off if we would take DATA/INDEX DIRECTORY as an alternate root data directory. So that we append the database name as the last element of the final directory path for the files. In other words, handle it the same as the default data directory. But for compatibility reasons it's too late to change that now, I think.

What I wanted to add before: IMHO it is not correct that we do not check the permission for the final target of the files. If it is in a database directory, we should check permission for this database in addition to the usual checks. But I guess this is also a general MySQL behavior and not related to partitioning.

The security flaw with overwriting of symlinked files should be fixed in bug#32111 (that fixes this bug as well).

This bug also include that it uses the DATA/INDEX DIR from the first partition as the tables DATA/INDEX DIR. What the patch do is to avoid setting the tables DATA/INDEX DIR from the first partitions DATA/INDEX DIR. (with this patch it can not match a different DATA/INDEX DIR for the table, only the table's default database-dir)

When partitioning is used, the table's DATA/INDEX DIR is silently IGNORED (as it was before the patch). It is only the DATA/INDEX DIR specified in the PARTITION's clause (per partition) that is used. (so, the patch only disables that the table's DATA/INDEX DIR is taken from the first partition, leaving the table's DATA/INDEX DIR completely IGNORED for a partitioned table, both when CREATE TABLE and SHOW/ALTER/? TABLE)

Another hint --keep_files_on_create can also help to stop the reversed trick in MyISAM:
good user: use securedb; CREATE TABLE t1 DATA/INDEX DIR = '..var/test';
evil user: use test: CREATE TABLE t1;

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

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

ChangeSet@1.2605, 2007-11-09 17:48:52+01:00, mattiasj@mattiasj-laptop.(none) +3 -0
  Bug#32091: Security breach via directory changes
  
  Problem: the table's INDEX and DATA DIR was taken
    directly from the table's first partition.
    This allowed rename attack similar to
    bug#32111 when ALTER TABLE REMOVE PARTITIONING
  
  Solution: Silently ignore the INDEX/DATA DIR
    for the table. (Like some other storage engines
    do). 
    Partitioned tables do not support DATA/INDEX
    DIR on the table level, only on its partitions.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

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

ChangeSet@1.2605, 2007-11-09 23:22:00+01:00, mattiasj@mattiasj-laptop.(none) +3 -0
  Bug#32091: Security breach via directory changes
  
  Problem: the table's INDEX and DATA DIR was taken
    directly from the table's first partition.
    This allowed rename attack similar to
    bug#32111 when ALTER TABLE REMOVE PARTITIONING
  
  Solution: Silently ignore the INDEX/DATA DIR
    for the table. (Like some other storage engines
    do). 
    Partitioned tables do not support DATA/INDEX
    DIR on the table level, only on its partitions.

Patch reapproved after checking new test cases

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

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

ChangeSet@1.2606, 2007-11-10 14:56:21+01:00, mattiasj@mattiasj-laptop.(none) +2 -0
  Bug#32091: Security breach via directory changes
  
  small fix of test case (when running make test after
  merge, it did not substitute MYSQLTEST_VARDIR in
  the error)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

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

ChangeSet@1.2607, 2007-11-10 21:29:39+01:00, mattiasj@mattiasj-laptop.(none) +2 -0
  Bug#32091: Security breach via directory changes
  
  Changed test case from GRANT to CREATE USER

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

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

ChangeSet@1.2608, 2007-11-12 13:23:45+01:00, mattiasj@mattiasj-laptop.(none) +4 -0
  Bug#32091: Security breach via directory changes
  
  Merge fix
  
  partition_mgm did not require have_symlink.
  
  Moved the test case to partition_symlink, which
  require have_symlink, and should work on both *nix and
  Windows

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

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

ChangeSet@1.2613, 2007-11-13 10:51:32+01:00, mattiasj@mattiasj-laptop.(none) +3 -0
  Bug#32091: Security breach via directory changes
  
  Post pushbuild fix
  
  Disabled test on windows due to bug#30459
  (DATA/INDEX DIR for partitions not working on windows)

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

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

ChangeSet@1.2614, 2007-11-13 11:12:53+01:00, istruewing@stella.local +3 -0
  Bug#32091: Security breach via directory changes
  
  Post pushbuild fix
  
  Disabled test on windows due to bug#30459
  (DATA/INDEX DIR for partitions not working on windows)
  
  Patch from Mattias Jonsson.

Pushed into 6.0.4-alpha

Pushed into 5.1.23-rc

Pushed into 5.1 and 6.0 (now in main)

CVE-2007-5970

Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html

Documented in 5.1.23 and 6.0.4 changelogs as follows:

        Security Fix: It was possible, by creating a partitioned table
        using the DATA DIRECTORY and INDEX DIRECTORY options to gain
        privileges on other tables having the same name as the
        partitioned table. As a result of this fix, any table-level DATA
        DIRECTORY or INDEX DIRECTORY options are now ignored for
        partitioned tables.