oss-sec mailing list archives

Re: mysql-5.1.41


From: Sergei Golubchik <serg () mysql com>
Date: Thu, 17 Dec 2009 16:28:16 +0100

Hi, Tomas!

On Dec 16, Tomas Hoger wrote:

Here are my comments on these issues, I'm happy to hear correction if
got some of these wrong.

Name: CVE-2008-7247

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.

I believe this description (and upstream description too) is
misleading.  I don't think the symlink needs to be *located* inside data
directory or point to a different *filesystem*.  What was actually fixed

right, this certainly doesn't look like having anything to do with
filesystems.

in http://lists.mysql.com/commits/59711 was the problem that
test_if_data_home_dir() got called with the path including the table
name without the extension.  Due to that, realpath returned ENOENT and
no resolution was made.  This should be a CVE-2008-4098 regression and
any symlink in the path should be good enough (e.g. /tmp/{link
-> /var/lib/mysql/mysql}) to trigger the problem.

I confirmed this happens on 5.1.x, but table name was not included in
the path passed to test_if_data_home_dir() when I tested with 5.0.77
(it's added right below the test_if_data_home_dir() calls).  Reading the
code in 5.0 bazaar branch, it should not be different in later 5.0.x
versions, so it seems all 5.0.x are unaffected.

So the best I can tell, this is 5.1.x+ CVE-2008-4098 regression with
probably lower impact due to some other changes introduced in the
CVE-2008-4098 fix (open-time checks).

Yes, one can create a table but not modify or read it.
 
Bug #39277 raises other issues that were not addressed by the mentioned
patch.  Separate bug for those issues -
http://bugs.mysql.com/bug.php?id=40980 - was marked as dupe of #32167,
which does not mention any fix for that issue.  Is it fixed already?

No, it's not. I've reopened the bug.
Thanks.
 
Name: CVE-2009-4028

The vio_verify_callback function in viosslfactories.c in MySQL 5.0.x
before 5.0.88 and 5.1.x before 5.1.41, when OpenSSL is used, accepts a
value of zero for the depth of X.509 certificates, which allows
man-in-the-middle attackers to spoof arbitrary SSL-based MySQL servers
via a crafted certificate, as demonstrated by a certificate presented
by a server linked against the yaSSL library.

I'm happy this says "as demonstrated by".  The bug suggest this only
happens with yaSSL servers, which is not true.  It's OpenSSL-using
client bug/feature causing all depth 0 SSL verification errors to be
ignored.  I've noted that in the upstream bug, and more details here:

  https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-4028#c2

okay, we'll probably need to change the bug description in the manual

Name: CVE-2009-4030

MySQL 5.1.x before 5.1.41 allows local users to bypass certain
privilege checks by calling CREATE TABLE on a MyISAM table with
modified (1) DATA DIRECTORY or (2) INDEX DIRECTORY arguments that are
originally associated with pathnames without symlinks, and that can
point to tables created at a future time at which a pathname is
modified to contain a symlink to a subdirectory of the MySQL data home
directory, related to incorrect calculation of the
mysql_unpacked_real_data_home value.  NOTE: this vulnerability exists
because of an incomplete fix for CVE-2008-4098 and CVE-2008-2079.

This problem is limited to situation where --datadir gets a relative
path not starting with '.' and current working directory is not
--basedir, right?

You mean the last problem in the bug report ?
Yes.
 
Regards / Mit vielen Grüßen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg () sun com>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
/_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München 161028
       <___/                  Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring


Current thread: