oss-sec mailing list archives
Re: CVE assignment and second opinion needed
From: Sergei Golubchik <serg () mysql com>
Date: Wed, 11 Nov 2009 19:16:18 +0100
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 () sun 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
Current thread:
- CVE assignment and second opinion needed Josh Bressers (Nov 11)
- Re: CVE assignment and second opinion needed Sergei Golubchik (Nov 11)