Glance

Comment 67 for bug 1546507

Revision history for this message

Brian Rosmaita (brian-rosmaita) wrote on 2016-11-07: Re: Regular user can delete any image file

#67

My opinion is that we need to move on this. As Erno pointed out, even though exploiting this vulnerability requires the use of non-default config option settings, you can't efficiently use RBD unless you use the problematic setings. Further, there are a large number of deployments using RBD and hence vulnerable to this.

I agree with Erno and Fei Long about needing to handle the "incurred" locations, because it's possible that someone could do this without bad intent (for example, if an end user wanted a more descriptive name or more detailed metadata on a public image, the end user might create a new image with all the detailed info and set the location to the public image data). So there could be a bunch of these things sitting around in a deployment, and they won't be noticed until an end user deletes one because s/he doesn't need it anymore.

Two questions:
(1) For glance coresec members: Please review my assessment of the affected stores and indicate what unknown info you can fill in. Please respond within 24 hours, that is, by 22:00 UTC tomorrow, Tuesday 8 November 2016.

(2) For OpenStack VMT: I need some advice about how to deal with this situation, that is, the bug may apply to more stores than just RBD. For example, efficient use of the Cinder backend would entail using the same non-default config options. The other issue is whether the proposed fix would break common non-default deployments of the other stores. My questions are (a) is it OK to add all driver maintainers to this bug (see http://docs.openstack.org/developer/glance_store/drivers/ for the list; we're talking 3 people not already on the bug), and (b) what do we do if the other driver maintainers don't respond in a timely manner? (I'm worried about releasing a fix for RBD that broadcasts knowledge of the vulnerability for the other unfixed backends.)

Store: Status, Is a Test Backend Available?
Filesystem: not affected (can't set location?), yes (devstack)
HTTP: not affected (HTTP store is read-only), N/A
RBD: affected in common non-default configuration, unknown
Cinder: affected if common non-default RBD configuration is used, yes (devstack)
Swift: could be affected if you exposed image locations (though there is no reason to expose them, in fact it's a really bad idea), yes (devstack)
VMware: unknown, unknown
Sheepdog: unknown, unknown

My opinion is that we need to move on this.  As Erno pointed out, even though exploiting this vulnerability requires the use of non-default config option settings, you can't efficiently use RBD unless you use the problematic setings.  Further, there are a large number of deployments using RBD and hence vulnerable to this.

I agree with Erno and Fei Long about needing to handle the "incurred" locations, because it's possible that someone could do this without bad intent (for example, if an end user wanted a more descriptive name or more detailed metadata on a public image, the end user might create a new image with all the detailed info and set the location to the public image data).  So there could be a bunch of these things sitting around in a deployment, and they won't be noticed until an end user deletes one because s/he doesn't need it anymore.

Two questions:
(1) For glance coresec members: Please review my assessment of the affected stores and indicate what unknown info you can fill in.  Please respond within 24 hours, that is, by 22:00 UTC tomorrow, Tuesday 8 November 2016.

(2) For OpenStack VMT: I need some advice about how to deal with this situation, that is, the bug may apply to more stores than just RBD.  For example, efficient use of the Cinder backend would entail using the same non-default config options.  The other issue is whether the proposed fix would break common non-default deployments of the other stores.  My questions are (a) is it OK to add all driver maintainers to this bug (see http://docs.openstack.org/developer/glance_store/drivers/ for the list; we're talking 3 people not already on the bug), and (b) what do we do if the other driver maintainers don't respond in a timely manner? (I'm worried about releasing a fix for RBD that broadcasts knowledge of the vulnerability for the other unfixed backends.)