[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091216162231.2c1c39ef@redhat.com>
Date: Wed, 16 Dec 2009 16:22:31 +0100
From: Tomas Hoger <thoger@...hat.com>
To: oss-security@...ts.openwall.com
Cc: coley@...us.mitre.org, MySQL Security Team <security@...ql.com>
Subject: Re: mysql-5.1.41
Hi!
On Mon, 30 Nov 2009 11:55:48 -0500 (EST) "Steven M. Christey"
<coley@...us.mitre.org> wrote:
> Here are the latest CVE assignments. Because the symlink issues were not
> completely fixed in earlier versions, they get new CVE IDs for later
> versions. (Downstream vendors might have fixed one issue, but not the
> other.)
Re-using same CVE for additional fixes to some flaw makes it hard for
downstreams and users to know whether they have a complete fix.
> Let me know if we've missed anything.
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
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).
My notes on this:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-7247#c4
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?
> 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
> 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?
--
Tomas Hoger / Red Hat Security Response Team
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.
