[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091217152816.GA1641@janus.mylan>
Date: Thu, 17 Dec 2009 16:28:16 +0100
From: Sergei Golubchik <serg@...ql.com>
To: Tomas Hoger <thoger@...hat.com>
Cc: oss-security@...ts.openwall.com, coley@...us.mitre.org,
MySQL Security Team <security@...ql.com>
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/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@....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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
