[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 11 Nov 2009 19:16:18 +0100
From: Sergei Golubchik <serg@...ql.com>
To: Josh Bressers <bressers@...hat.com>
Cc: oss-security <oss-security@...ts.openwall.com>, coley <coley@...re.org>
Subject: Re: CVE assignment and second opinion needed
Hi, Josh!
On Nov 11, Josh Bressers wrote:
> Hi Steve,
>
> So this one is a bit tricky.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555626
>
> There are almost two flaws here, certainly one. The issue really boils
> down to if /var/lib/mysql is world readable, it's possible for a local
> user who also has database access, and can guess a future database
> table name, could ensure that table will be a world writable file.
> That's an impressive runon sentence.
>
> So The question I have with respect to CVE assignment, is which part
> of this is worth of the ID. I'm thinking the directory permissions are
> possibly an issue, but by itself, isn't really a security flaw.
Right, not really. At most, it's a minor (?) information leak - one can
see database and table names that he would not be able otherwise.
It is a problem - for example by a user demand we've added
--skip-show-databases command-line switch which basically hijacks normal
privilege checks and does not allow normal users to see the list of
databases (without it one can see databases he has any privileges on).
I mean, we've added this because users repeatedly requested it.
Still, I don't think it deserves a CVE ID on itself.
> The CREATE TABLE not fixing permissions if the file already exists is
> probably closer to the real problem. Being able to do a select into an
> outfile anywhere by default may also be an issue.
Not anywhere, it's done my mysqld daemon, as mysql user. Filesystem
permissions still apply and limit where mysql user can write to.
Also, SELECT ... OUTFILE never overwrite existing files.
And in the default install only MySQL root user has FILE privilege
necessary for SELECT ... OUTFILE.
> Also, Sergei, do you folks have a fix for this yet? I'm curious to see
> what you're fixing, which may help decide CVE assignment.
No we don't. It's considered a relatively minor issue with a simple
workaround (fix datadir permissions, use --secure-file-priv). On a
properly configured system it should never be an issue - I was surprised
to know that Debian creates these directories world-readable.
And anyway this is limited to users with MySQL FILE privilege - and
MySQL manual explicitly says that it's a powerful privilege that can be
easily abused and should not be granted to just anybody.
We're fixing the permission problem. The desired behavior - after CREATE
TABLE t1 all the files (t1.frm, t1.MYI, t1.MYD) have identical
permissions, as if all the three were created anew. Even if
some of these files existed before and had different permissions.
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.
