Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Dec 2009 16:28:16 +0100
From: Sergei Golubchik <>
To: Tomas Hoger <>
  MySQL Security Team <>
Subject: Re: mysql-5.1.41

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/ 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

> in 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 -
> - 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.
> > 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:

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 ?
Regards / Mit vielen Grüßen,

   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <>
 / /|_/ / // /\ \/ /_/ / /__  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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ