Re: mysql-5.1.41

[Tomas Hoger <thoger () redhat com>]

Hi!

On Mon, 30 Nov 2009 11:55:48 -0500 (EST) "Steven M. Christey"
<coley () linus 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