mongodb guest instance allows any user to connect

[Craig Vyvial]

The risk on this i'd say is medium because its limited to the networks that the instance is created on.

So when you create a new mongodb single instance the default settings of mongo for security.authorization is disabled. I am not sure yet if this also applies to a mongodb clusters but its likely the same.

This means that you do not need to provide credentials to connect to the mongo instance to read/write data from any database on the instance. The reason i say this is low security issue is because you are only able to connect to the instance from a network that is attached on instance create. There is a potential of high risk here depending what type of network this mongo instance is created on.

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Craig Vyvial (cp16net)]

I've included to a patch to enable the mongodb authorization of users when connecting to the datastore.

I think we should disclose this patch to the other core members of trove for review.
I do not believe they are currently on this bug watch list.

[Jeremy Stanley (fungi)]

The trove-coresec group I subscribed includes four Trove core reviewers who have expressly volunteered to review and shepherd security fixes.

[Craig Vyvial (cp16net)]

@jeremy 3 out of the 4 people in the Trove core security group are no longer working on trove. Looks like we need to do some house keeping but i do not have admin rights. I'll talk with Nikhil.

[Amrith Kumar (amrith)]

I'm testing the fix proposed above.

[Amrith Kumar (amrith)]

I submit the patch 0002-enable-mongo-user-authorization.patch for consideration.

[Tristan Cacqueray (tristan-cacqueray)]

Before moving further with this bug report, can someone check default settings of others datastore (e.g. http://git.openstack.org/cgit/openstack/trove/tree/trove/guestagent/datastore/experimental ) ?

Would it makes sense to refine "security support" for a subset of these stores ?

[Craig Vyvial (cp16net)]

Looks like most of the datastores in trove outside of mysql and derivatives do not have user control settings. This means that mongo, redis, cassandra, couchbase, couchdb, db2 and postgresql may have similar issues.

If redis had root-enable with password then this would be a work around for the time being.
If we defaulted creating a password for redis instances then redis clustering would break.

I chatted with team member of trove to see how we handle situations like this with datastores that we call experimental. I plan on bringing this up at the next meeting as well to get more thoughts about it.
The 2 sides right now are:
1. Experimental datastores are experimental and expect issues similar to this security bug with them because they are not tested thoroughly in CI. (then we would have no embargo on this bug or others for the experimental datastores)
2. Experimental datastores code has been shipped and should be handled the same as any other security bug found in a stable datastore. (embargo the security bug)

If there is someone here that leans one way or another on this let me know.

The reason i added this as a private security issue is because i know there are people that have trove deployed with redis and mongo datastores even though they are considered experimental in the code currently.

[Tristan Cacqueray (tristan-cacqueray)]

So on one hand there are users of Trove mongo datastore that are affected by this lack of acl, and on the other hand, most experimental datastore (like redis, cassandra, postgresql, ...) do not have user control settings.

I would triage this as a B2 type of bug (according to https://security.openstack.org/vmt-process.html#incident-report-taxonomy). Basically, this is a vulnerability (lack of datastore user access control), there is no complete fix (only mongo is fixed in that case), and we better document this vulnerability with an Security Note (OSSN) instead.

[Jeremy Stanley (fungi)]

I basically agree with Tristan, though am proposing a new class B3 in our taxonomy to document vulnerabilities in experimental and debugging features: https://review.openstack.org/255476

[Amrith Kumar (amrith)]

Tristan, Jeremy, let's take a look at that and see what the effort would be to get it fixed in more of the datastores.

[Amrith Kumar (amrith)]

I believe that this patch addresses both the clustered and single node situations.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks Amrith for the patch. A couple of comment:

* Security fix needs to be proposed using git format-patch, (see: https://security.openstack.org/#how-to-propose-and-review-a-security-patch ). And it needs to be reviewed/approved here since this bug report is still private
* The fix you proposed seems to fix mongodb only, so I propose again to triage this as B3 in our taxonomy to document vulnerabilities in experimental features: https://security.openstack.org/vmt-process.html#incident-report-taxonomy

If you agree with such triage, we could remove the privacy settings and submit this change directly to gerrit.

[Amrith Kumar (amrith)]

Tristan, let me review and get back to you. Just wanted to confirm that I've seen your update.

[Amrith Kumar (amrith)]

Tristan, patch in the correct format attached now.

[Amrith Kumar (amrith)]

Tristan, regarding your second question about the triage as B3 etc., let me discuss with Craig and get back to you later today. Could not do it yesterday as it was a holiday in the US.

cp16net: we should discuss today and get this addressed.

[Amrith Kumar (amrith)]

I have deleted the patch, will re-attach it shortly.

[Amrith Kumar (amrith)]

corrected file

[Amrith Kumar (amrith)]

let's see if I can get it right this time ;)

[Craig Vyvial (cp16net)]

Nice. I'm running a test on it now. Hopefully I can get mongo to cooperate with me today and i will report findings.

Tristan, after chatting about this issue with Amrith we decided to keep this bug a B1 instead of changing it to a B3 because of the nature of the issue and knowing that people are running this datastore in production.

[Jeremy Stanley (fungi)]

So you're asserting that there's a need for a separate bug (or bugs) covering the lack of authentication with redis, cassandra, couchbase, couchdb, db2 and postgresql, and that this current bug will only cover mongodb? I guess that's the implication of the bug subject, though it leaves me wondering why an incomplete implementation in one of them is considered a production defect while the other incomplete implementations are still experimental.

Or are you also getting ready to attach fixes for all the other affected backends too?

[Craig Vyvial (cp16net)]

I've validated that this patch works for mongodb. Thanks @amrith for the patch!

@fungi it was mentioned that we should audit the other datastores in trove and i looked them over. While I believe we should look at fixing this across all the datastores this bug was representing just mongodb. But you bring up a good point. The concern was if we released this patch then there is a possibility of the other datastores being compromised if they are running in production.

There is a mild risk here if the instances are created on a shared network rather than a private user network though.

[Jeremy Stanley (fungi)]

Craig: My question was really more from the perspective of how the VMT categorizes this report, and then how we act on it. I'm having a hard time reconciling the argument that there is a list of backends with (likely) no authentication implemented, but one of them is considered a security vulnerability while the others are simply considered an incomplete/experimental feature implementation. Consistency would dictate that they're all security vulnerabilities (which we then need to fix and announce) or all incomplete features (which can just be fixed when convenient and some documentation published indicating that you shouldn't really rely on them in untrusted environments until a later release).

[Craig Vyvial (cp16net)]

Jermey: after thinking about this and talking with the other Trove members that are aware of this issue it makes the most sense to us to treat the other datastores where we see this issue as a B3 vulnerability that can be addressed publicly rather than privately.

[Tristan Cacqueray (tristan-cacqueray)]

I confirm the B3 class according to VMT taxonomy http://security.openstack.org/vmt-process.html#incident-report-taxonomy.
Craig, can you please switch this bug to public before submitting its fix ?

[Tristan Cacqueray (tristan-cacqueray)]

If nobody complains, let's open this bug by the end of the week.

[Amrith Kumar (amrith)]

Tristan, let me close the loop with Craig. I think there's a misunderstanding here.

At this time, let's NOT open this bug. I will update it within the day (tomorrow at the latest).

[Craig Vyvial (cp16net)]

Tristan, I meant that this issue for MongoDB will be considered a B1 class and the other issues for redis, cassandra, couchbase, couchdb, db2 and postgresql that were found will be created as a B3 class security issue.

I planned to create them after this fix was applied and released.

[Tristan Cacqueray (tristan-cacqueray)]

Amrith, Craig, any progress here ?

[Amrith Kumar (amrith)]

Tristan, the patch (attached) is good to go for MongoDB and a B1 class issue. For the others, this is B3 and once this fix is released (for MongoDB) I'd work on the B3's for the other databases.

Was there something else you were looking for me to do. Or put differently how do I get this change merged for B1/MongoDB?

[Tristan Cacqueray (tristan-cacqueray)]

Oh, I thought we were waiting for something before opening this bug. If patches are ready to go, then let's remove the privacy settings and submit them to gerrit.

[Amrith Kumar (amrith)]

Matthew will be submitting a change shortly.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit c653178e8f7c00d9c2c559c7c03758b723a9de3c
Author: Matt Van Dijk <email address hidden>
Date: Thu Mar 3 15:40:57 2016 -0500

    Secure mongodb instances and clusters by default

    MongoDB's default behaviour is to have the authorization rules disabled.
    This means any client can access the database without credentials. This
    is too large of a risk for default behaviour, so authorization needs to
    be enabled by default.

    This fix addresses the problem by setting the authorization parameter to
    enabled for standalone instances, and specifying key files for cluster
    instances to use.

    Change-Id: I5895ce66ec450c3efce7a7e0f126ac13ac4c1b12
    Closes-bug: #1507841

[Robert Clark (robert-clark)]

Hi all,

I see there's a fix released, I guess an OSSN is required in leu of an OSSA? Which version are affected?

[Amrith Kumar (amrith)]

Robert, this was fixed in Mitaka (released in RC1). The OSSN should be for Liberty. I can see a value in proposing this for a backport though.

[Amrith Kumar (amrith)]

Did that answer the question or am I misunderstanding what you asked.

[Robert Clark (robert-clark)]

Thanks Amrith, so is Liberty the only affected version?

[Michael Xin (michael-xin)]

Thanks Amrith, does this defect affect other versions before Liberty?

[Michael Xin (michael-xin)]

Per Amrith, "liberty is the only one (also kilo but that's going off support soon)".
"only mongoDB with this specific issue".

[Luke Hinds (lhinds)]

Just working on drafting a note now, and I wanted to clarify:

The original issue states "when you create a new mongodb single instance", and the fix introduces an arg 'cluster_secure'. Does this apply to a single instance of mongobd as well?

I am confused by the naming conventions of a secure cluster and single instance.

[Matthew Van Dijk (mvandijk)]

This secures both single instance and cluster mongodb deployments, they just have different code paths.

[Luke Hinds (lhinds)]

Thanks Matthew, I am almost there now.

Quick question, is cluster_secure arg rendered by a Horizon form / template for the user to select, or is just a CLI / API option?

[Matthew Van Dijk (mvandijk)]

It is a Trove configuration option - https://github.com/openstack/trove/blob/master/trove/common/cfg.py#L998-L1000. It is set by the operator and applies to all Trove instance/clusters.

[Luke Hinds (lhinds)]

oSSN-0066 released to wiki and mailing lists.