New user wrongly given access permissions to databases

[Martin Paulo]

Running the trove client against the Icehouse service I have encountered the following odd situation:

Create a datastore instance with, say two databases and a user:

$ trove create nextTestdb 1 --size 1 --databases DbOne DbTwo --users Bob:AVeryBadPassw0rd
+-------------------+--------------------------------------+
| Property | Value |
+-------------------+--------------------------------------+
| created | 2014-10-14T03:14:46 |
| datastore | MySQL |
| datastore_version | 5.5 |
| flavor | 1 |
| hostname | cqhuwzshhzz.db.cloud.unimelb.edu.au |
| id | 66d95162-6d60-499b-a797-72955acaf165 |
| name | nextTestdb |
| status | BUILD |
| updated | 2014-10-14T03:14:46 |
| volume | 1 |
+-------------------+--------------------------------------+

Then change the user Bob's name:
$ trove user-update-attributes 66d95162-6d60-499b-a797-72955acaf165 Bob --new_name VaderJakob

Just to show the ordinary permissions for a new user, create one called, say, Ben:
$ trove user-create 66d95162-6d60-499b-a797-72955acaf165 Ben ADifferentBadPassword

$ trove user-list 66d95162-6d60-499b-a797-72955acaf165
+------------+------+--------------+
| Name | Host | Databases |
+------------+------+--------------+
| Ben | % | |
| VaderJakob | % | DbOne, DbTwo |
+------------+------+--------------+

Now create a new user, named Bob:
$ trove user-create 66d95162-6d60-499b-a797-72955acaf165 Bob AnotherBadPassword

$ trove user-list 66d95162-6d60-499b-a797-72955acaf165
+------------+------+--------------+
| Name | Host | Databases |
+------------+------+--------------+
| Ben | % | |
| Bob | % | DbOne, DbTwo |
| VaderJakob | % | DbOne, DbTwo |
+------------+------+--------------+

And it can be seen that Bob has picked up access rights to the databases that the old user Bob used to have before he/she/it was renamed to VaderJakob. Which is, IMHO wrong. I did a search and didn't find a bug report along these lines.

Although a very minor hole, I've taken the liberty of checking the security vulnerability flag, as I think that a user accidentally finding themselves with access to a database that they weren't supposed to see might cause some pain in someone's life.

[Grant Murphy (gmurphy)]

Hi Martin,

Thanks for your bug report. I agree. It looks like this could have security implications. I've added an OSSA task to the bug and marked it incomplete pending confirmation from a member of the Trove coresec team.

[Nikhil Manchanda (slicknik)]

Looks like it is a valid trove issue that I was able to reproduce. The crux of the issue is that when renaming a mysql db user, the grants that are associated with the previous username are preserved, so when the owner of the instance creates a new user with the old name — this new user inherits the grants that existed previously.

Imo it's more of a minor bug that's a surprising corner case only for mysql, and less of a concerning security issue for a few reasons:
- You need to have access to the (valid) trove creds that created the instance, and the first user in order to create the second user.
- The previously created user needs to be renamed to a different user name.
- The second user MUST have the same name as the previously created user.

[Tristan Cacqueray (tristan-cacqueray)]

Considering the attack vector is quite unrealistic, we are willing to mark this bug public security and remove the OSSA task next wednesday (2014/10/29) unless someone raises a concern.

[Martin Paulo (martin-paulo)]

Yeah: I don't think that its a major bug either. Mind you, when I discussed it with the database people at work they were horrified...

[Tristan Cacqueray (tristan-cacqueray)]

Marking this bug public security and removing the OSSA task...

[Martin Paulo (martin-paulo)]

Whilst I agree that it might not be a major security bug, I'm somewhat surprised that you've marked this as a "won't fix". MySQL is probably the database that is most likely to be deployed (does it also affect MariaDB?) Although unlikely, having new users potentially granted the rights of older users is one of those edge cases that might cause a lot of pain if triggered :(

[Jeremy Stanley (fungi)]

The security advisory task is marked "won't fix" but the bug is still open against Trove and triaged as "high" priority.

[Martin Paulo (martin-paulo)]

Ah: My misunderstanding. Apologies - and thanks for the clarification!

On 18 November 2014 11:23, Jeremy Stanley <email address hidden> wrote:

> The security advisory task is marked "won't fix" but the bug is still
> open against Trove and triaged as "high" priority.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1380880
>
> Title:
> New user wrongly given access permissions to databases
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ossa/+bug/1380880/+subscriptions
>

--
=================================================================

Martin Paulo, BSc.
Software Developer

Tel : [phone] (Home)
Tel : [phone] (Mobile)
Site: http://www.thepaulofamily.net

"Nobody goes there any more. It's too crowded" - Yogi Berra.

[Sushil Kumar (sushil-kumar2)]

same is the problem if u try to update the host for a give user and recreate the older combination of user and host.

[Sushil Kumar (sushil-kumar2)]

the reason this problem is occurring is because in order to update a user's name or host we are updating the mysql.user table.
However for every database access there goes a record in mysq.db which is left behind when we are updating the user info in mysql.user.

So, basically the mysql.db also needs a cleanup while updating mysql.user for username or hostname.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/137942

[Amrith Kumar (amrith)]

Sushil, do you have an update on a fix for this?

[OpenStack Infra (hudson-openstack)]

Change abandoned by amrith (<email address hidden>) on branch: master
Review: https://review.openstack.org/137942
Reason: abandoning for inactivity. Please reinstate if you are still working on this and address earlier comments.

[Martin Paulo (martin-paulo)]

So a fix for a security hole (albeit a minor one) is being abandoned? Sad.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/343920
Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=dc7ccce006980cc3b6c908eb381088f61b0d8a5d
Submitter: Jenkins
Branch: master

commit dc7ccce006980cc3b6c908eb381088f61b0d8a5d
Author: Petr Malik <email address hidden>
Date: Mon Jul 18 16:23:23 2016 -0400

    Use proper queries to update user properties

    Bug 1380880 occurs when a user gets renamed
    and another one gets created wit its original name.

    It turns out that the new user wrongly inherits
    access rights of the original user.

    MySQL guest currently updates user properties by
    changing fields in the internal 'mysql' database.

    This patch set replaces the UPDATE with more generic
    SET PASSWORD and RENAME statements that should work on
    all MySQL versions.

    We no longer need to transfer privileges on a user name/host
    change since the RENAME statement does it for us under the covers.

    As an additional benefit this solution is also fully compatible
    with MySQL 5.7 which has changed the definition of the
    internal 'user' table and the current code no longer works.

    Closes-Bug: 1380880
    Change-Id: I37fdec77184715ed889d8ea6d446282c98903258

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/trove 6.0.0.0b3 development milestone.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/trove 6.0.0.0b3 development milestone.