Glance allows user to create images and add other tenants as members (CVE-2013-4354)

I assume this behavior has been exploitable back at least as far as essex? When you say well-known, is the choice not to check tenant membership on these operations publically documented (not just buried in the source code or hinted at in mailing list archives)? Are there scenarios where this could reasonably compromise tenant security or is it simply a means of bypassing resource limits/restrictions? I'm basically trying to work out whether this warrants an advisory, and if so what risks it presents to whom.

Following an E-mail discussion with Flavio and Kurt from Red Hat, I'm making this bug public to expedite broader discussion and mitigation. Also, per Kurt, this affects at least Folsom, Grizzly and presumably Havana (no word yet on whether it extends back as far as Essex).

The trick here is that "fixing" this would significantly alter the behavior of Glance by preventing something that was always supported so far (and could be used for good reasons)... We could document the risk and address it in future API releases, but that would not address the "vulnerability". Thoughts ?

I think this bug has been well understood for some time.

We however could not *fix* it without breaking backwards compatibility in v1. Hence, we held off on memberships in v2.0, and then only added them in v2.1 when we were sure that we could prevent this kind of griefing/spamming.

In v2.1+, when you add a tenant id as a member to an image, the membership starts out in the "pending" state. "Pending" memberships can be viewed by users in that tenant by querying specifically for "membership-status=pending", however, they must be "accepted" before they show up in the default listing. This puts in place a two step solution that IMO generally resolves the security issue.

In addition, it is possible for deployers to limit image sharing to specific roles, in case more control is required.

So I'm not sure if this bug is "invalid", "fix released", or "wontfix" at this point.

It is true that this issue was fixed in v2.1 but it still exists in previous versions of the API. I agree on the fact that this behavior has been well understood for some time but I'm not sure people is aware of this vulnerability, though.

I agree with Thierry's idea of documenting the vulnerability somewhere without changing the way Glance works. I also prefer to keep Glance the way it is today, if we all agree that documenting this is enough to close this bug.

Thank you all!

This is what OSSNs (security notes) have been designed to solve -- informing the public of security best practices around OpenStack, when patching the code does not fully address all concerns.

My suggestion would be for an OSSN to mention the potential image sneaking in previous versions, and to encourage people to run havana glance with enable_v1_api=False if they can ?

Agree that an OSSN makes sense here, it'll be next week before I can get someone to work on it.

Is someone working on the OSSN for this?

I'll start preparing an OSSN for this.

I believe that this issue extends as far back as Diablo, which is when image sharing support was added to Glance:

    https://blueprints.launchpad.net/glance/+spec/shared-images

Glance allows sharing of images between projects without consumer project approval
---

### Summary ###
Glance allows images to be shared between projects. In certain API versions, images can be shared without the consumer project's approval. This allows potentially malicious images to show up in a project's image list.

### Affected Services / Software ###
Glance, Image Service, Diablo, Essex, Folsom, Grizzly, Havana

### Discussion ###
Since the OpenStack Diablo release, Glance allows images to be shared between projects. To share an image, the producer of the image adds the consumer project as a member of the image. When using the Image Service API v2.0 and earlier, the image producer is able to share an image with a consumer project without their approval. This results in the shared image showing up in the image list for the consumer project. This can mislead users with roles in the consumer project into running a potentially malicious image.

The Image Service API v2.1 makes image sharing a two-step process. An image producer must add a consumer as a member of the image, and the consumer must accept the shared image before it shows up in their image list. This additional approval process allows a consumer to control what images show up in their image list, thus preventing potentially malicious images being used without the consumers knowledge

### Recommended Actions ###
In the OpenStack Diablo, Essex, and Folsom releases, Glance supports image sharing using the Image Service API v2.0 or earlier. There is no way to require approval of a shared image by consumer projects. Users should be cautioned to be careful when using images from their image list, as they may be using an image that was shared with them without their knowledge.

In the OpenStack Grizzly and Havana releases, Glance supports the Image Service API v2.1 or later. Support is still provided for Image Service API v1, which allows image sharing between projects without consumer project approval. It is recommended to disable v1 of the Image Service API if possible. This can be done by setting the following directive in the glance-api.conf configuration file:

---- begin example glance-api.conf snippet ----
enable_v1_api = False
---- end example glance-api.conf snippet ----

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1226078
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1226078
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-4354

Does anyone have any feedback before I go ahead and publish the OSSN draft from comment#11?

This looks very good. I do, however, have one correction I would like to submit. In v2.0 of the images api, we simply did not include image sharing--so the vulnerability does not exist there. It is only part of the v1 series.

I'd like to see Mark's comment addressed. Otherwise, this looks good to me.

Thanks for the feedback Mark! Here is an updated draft that corrects the issue you pointed out. If this looks good to you and Bryan, I'll get it sent out.

Glance allows sharing of images between projects without consumer project approval
---

### Summary ###
Glance allows images to be shared between projects. In certain API versions, images can be shared without the consumer project's approval. This allows potentially malicious images to show up in a project's image list.

### Affected Services / Software ###
Glance, Image Service, Diablo, Essex, Folsom, Grizzly, Havana

### Discussion ###
Since the OpenStack Diablo release, Glance allows images to be shared between projects. To share an image, the producer of the image adds the consumer project as a member of the image. When using the Image Service API v1, the image producer is able to share an image with a consumer project without their approval. This results in the shared image showing up in the image list for the consumer project. This can mislead users with roles in the consumer project into running a potentially malicious image.

The Image Service API v2.1 makes image sharing a two-step process. An image producer must add a consumer as a member of the image, and the consumer must accept the shared image before it shows up in their image list. This additional approval process allows a consumer to control what images show up in their image list, thus preventing potentially malicious images being used without the consumers knowledge

### Recommended Actions ###
In the OpenStack Diablo, Essex, and Folsom releases, Glance supports image sharing using the Image Service API v1. There is no way to require approval of a shared image by consumer projects. Users should be cautioned to be careful when using images from their image list, as they may be using an image that was shared with them without their knowledge.

In the OpenStack Grizzly and Havana releases, Glance supports the Image Service API v2.1 or later. Support is still provided for Image Service API v1, which allows image sharing between projects without consumer project approval. It is recommended to disable v1 of the Image Service API if possible. This can be done by setting the following directive in the glance-api.conf configuration file:

---- begin example glance-api.conf snippet ----
enable_v1_api = False
---- end example glance-api.conf snippet ----

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1226078
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1226078
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-4354

I think it would be nice to mention that this is a non-issue in 2.0 b/c image sharing isn't available. Otherwise, people reading this may see v1 and v2.1 and not know what to do with v2.0.

This looks good, but I do agree with Bryan's suggestion. I suspect it could be added as a small clarification to the second paragraph of the discussion section (which looks to need a trailing period as well.)

This adds a clarification about API v2.0 to the second paragraph of the discussion section. It also corrects the missing period at the end of that paragraph.

-----------------------------------------------------------------

Glance allows sharing of images between projects without consumer project approval
---

### Summary ###
Glance allows images to be shared between projects. In certain API versions, images can be shared without the consumer project's approval. This allows potentially malicious images to show up in a project's image list.

### Affected Services / Software ###
Glance, Image Service, Diablo, Essex, Folsom, Grizzly, Havana

### Discussion ###
Since the OpenStack Diablo release, Glance allows images to be shared between projects. To share an image, the producer of the image adds the consumer project as a member of the image. When using the Image Service API v1, the image producer is able to share an image with a consumer project without their approval. This results in the shared image showing up in the image list for the consumer project. This can mislead users with roles in the consumer project into running a potentially malicious image.

The Image Service API v2.0 does not allow image sharing between projects, so a project is not susceptible to running unauthorized images shared by other projects. The Image Service API v2.1 allows image sharing using a two-step process. An image producer must add a consumer as a member of the image, and the consumer must accept the shared image before it shows up in their image list. This additional approval process allows a consumer to control what images show up in their image list, thus preventing potentially malicious images being used without the consumers knowledge.

### Recommended Actions ###
In the OpenStack Diablo, Essex, and Folsom releases, Glance supports image sharing using the Image Service API v1. There is no way to require approval of a shared image by consumer projects. Users should be cautioned to be careful when using images from their image list, as they may be using an image that was shared with them without their knowledge.

In the OpenStack Grizzly and Havana releases, Glance supports the Image Service API v2.1 or later. Support is still provided for Image Service API v1, which allows image sharing between projects without consumer project approval. It is recommended to disable v1 of the Image Service API if possible. This can be done by setting the following directive in the glance-api.conf configuration file:

---- begin example glance-api.conf snippet ----
enable_v1_api = False
---- end example glance-api.conf snippet ----

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1226078
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1226078
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: CVE-2013-4354

Great! Thanks. +2

Published on OpenStack and OpenStack-Dev mailing lists on 11 Dec 2013.