Cause conflicts within glance public metadefs

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.

The two fixes that need to be in place are:
1. The not allowing to create two namespaces with the same name.
2. Adding a policy to disallow non-admins publicizing namespaces.

Niall, are you working on solution for this?

OpenStack Vulnerability team: I would like to add Travis Tripp to subscribers as he is most familiar with metadef use cases and would like a solution proposal from him.

Nikhil, I am not currently working on this, however I would be happy to.

Verified the issue. Seems like duplicate namespaces are getting created which was not the case before. Will have to verify the db code.

This bug has a fix that was submitted back in June: https://review.openstack.org/#/c/195820/

Thanks Wayne. Did not click then!

On 8/7/15 2:14 PM, Wayne wrote:
> This bug has a fix that was submitted back in June:
> https://review.openstack.org/#/c/195820/
>

--

Thanks,
Nikhil

There is a previous bug/patch for this:

https://review.openstack.org/#/c/195820

but I'm not sure if the security aspect of it was covered.

From my -- fairly limited -- understanding of metadefs it does seem like there is a vulnerability here: a DOS of the metadefs API.

Is there others side effects beside the metadata API not being available ? For example, in a Kilo devstack setup, having the metadef API unavailable (returning 500) does not prevents instances to start or the image list to be displayed in Horizon.

I'm not familiar with that feature, is there a configuration option to enable its use by the others API ?

Assuming this was introduced in Juno, here is the impact description draft #1:

Title: Glance metadata v2 API DoS through duplicate namespaces
Reporter: Niall Bunting (HP)
Products: Glance
Affects: 2014.2 versions through 2014.2.3 and 2015.1.0 versions through 2015.1.1

Description:
Niall Buntin from HP reported a vulnerability in the Glance metadata v2 API. By creating duplicated namespaces, an authenticated user may crash the Glance metadata v2 API, resulting in a denial of services. Only setups using the Glance V2 API are affected by this flaw.

Hi Tristan,

Thanks for the draft.

> Title: Glance metadata v2 API DoS through duplicate namespaces

I'd suggest changing "metadata" here to "metadefs". I think that makes it clearer that we're talking about the /v2/metadefs resource

Description: typo: Niall Buntin -> Niall Bunting

@Niall

Is the original metadef description recoverable after a user has written over it? Or has it been lost?

@Stuart

It's not lost its still in the database. However its just accessible through the API, with control over the database you could delete the other interfering entry.

Thanks for the review, here is the updated impact description draft #2:

Title: Glance metadefs v2 API DoS through duplicate namespaces
Reporter: Niall Bunting (HP)
Products: Glance
Affects: 2014.2 versions through 2014.2.3 and 2015.1.0 versions through 2015.1.1

Description:
Niall Bunting from HP reported a vulnerability in the Glance metadata v2 API. By creating duplicated namespaces, an authenticated user may crash the Glance metadata v2 API, resulting in a denial of services. Only setups using the Glance V2 API are affected by this flaw.

The fix https://review.openstack.org/#/c/195820/ does not applies properly to stable/juno at least.

Since it's already public, backports could be pushed to gerrit (referencing bug 1468946) while we keep this bug private to finalize the advisory side.

I've subscribed the OSSG core security reviewers too.

I'm dubious about keeping this bug private. At this point bug 1468946 is public and mostly explains the risk (without explicitly calling it a denial of service). The fix is public in master and seems very close to being approved. Making this bug public will also make it a lot easier to explain to the stable branch reviewers why the backports are urgent and can hopefully speed up resolution there.

Unless there are serious objections, I want to switch this bug to public security this Wednesday, August 19.

Given the circumstances, I agree with Jeremy's proposed path of action (OSSG CoreSec)

+1 - enough of the issue is already public. It's a simple jump to go from what's listed in 1468946 to DoS.

The fix for master included a database schema migration, which is usually out of bounds for a stable backport (stable branches are a source of safe and automated fixes -- we need people to be able to upgrade without manual risky or lengthy steps like a database migration).

Is there any other way to fix the issue that does not involve database schema changes ?

I don't think there is a better way than to have the database system reject duplicates automatically. Otherwise, will have to introduce code to check before inserting rows that each record's keys don't already exist. This would be redundant to what the unique constraints do.

Also, not running the migration won't get the user out of the DOS against a duplicate namespace.

If this can't be backported, then we'll have to make this a class B1 ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ).

@ossg-coresec, thought about OSSA vs OSSN here ?

How about back-porting the input validation solutions to the branches where we don't want to do database migration?

My concern with a note is that I'm not sure what we would advise deployers to do. If we're fairly comfortable recommending the policy change mentioned by Niall in comment #2, a note around that advice seems appropriate.

@Travis We can't really advice what I mentioned due to the fact that there is no policy that will disallow publicizing images. The only other thing we could do is advise them to implement the fix.

Until this can be safely backported, the OSSA task is switched to Won't fix.