Glance

Comment 21 for bug 1990157

Revision history for this message

Brian Rosmaita (brian-rosmaita) wrote on 2022-09-26: Re: Malicious image data modification can happen when using COW

#21

Revisions to comment #19:

### Affected Services / Software ###
-Glance, all releases
-Nova, all releases
-Cinder, all releases
+Glance, all supported and extended-maintenance releases (Queens through Zed)

### Discussion ###
This note applies to you if you are operating an end-user-facing
@@ -67,19 +67,35 @@ is disabled in Glance, it is not possible to manipulate the locations
via the OpenStack Images API. It is worth mentioning, however, that
enabling 'show_image_direct_url' (which can be used by various OpenStack
services to consume images directly from the storage backend) leaks
-information about the backend to end users, which is never a good thing
-from a security point of view. We therefore recommend that OpenStack
-services that require exposure of the 'direct_url' image property
-be similarly configured to use an internal-only-facing glance-api.
-(End users who wish to download an image do not require access to the
-direct_url image property because they can simply use the image data
-download API call [3].)
+information about the backend to end users. What exactly that
+information consists of depends upon the backend in use and how it is
+configured, but in general, the safest course of action is not to expose
+it at all. Keep in mind that in any Glance/Nova/Cinder configuration
+where Nova and/or Cinder do copy-on-write directly in the image store,
+image data transfer takes place outside Glance's image data download
+path, and hence the os_hash_value is *not* checked. Thus, if the
+backend store is compromised, and image data is replaced directly in the
+backend, the substitution will *not* be detected. That's why it is
+important not to give malicious actors unnecessary hints about the image
+storage backend.
+
+We therefore recommend that OpenStack services that require exposure of
+the 'direct_url' image property be similarly configured to use an
+internal-only-facing glance-api. (End users who wish to download an
+image do not require access to the direct_url image property because
+they can simply use the image-data-download API call [3].)

### Recommended Actions ###
A glance-api service with 'show_multiple_locations' enabled should
-*never* be exposed directly to end users. This setting should only
-be enabled on an internal-only-facing glance-api that is used by
-OpenStack services that require access to image locations.
+*never* be exposed directly to end users. This setting should only be
+enabled on an internal-only-facing glance-api that is used by OpenStack
+services that require access to image locations. This could be done,
+for example, by running two glance-api services with different
+configuration files and using the appropriate configuration options for
+each service to specify the Image API endpoint to access, and making
+sure the special internal endpoint is firewalled in such a way that only
+the appropriate OpenStack services can contact it.

Revisions to comment #19:

### Affected Services / Software ###
-Glance, all releases
-Nova, all releases
-Cinder, all releases
+Glance, all supported and extended-maintenance releases (Queens through Zed)

### Discussion ###
 This note applies to you if you are operating an end-user-facing
@@ -67,19 +67,35 @@ is disabled in Glance, it is not possible to manipulate the locations
 via the OpenStack Images API.  It is worth mentioning, however, that
 enabling 'show_image_direct_url' (which can be used by various OpenStack
 services to consume images directly from the storage backend) leaks
-information about the backend to end users, which is never a good thing
-from a security point of view.  We therefore recommend that OpenStack
-services that require exposure of the 'direct_url' image property
-be similarly configured to use an internal-only-facing glance-api.
-(End users who wish to download an image do not require access to the
-direct_url image property because they can simply use the image data
-download API call [3].)
+information about the backend to end users.  What exactly that
+information consists of depends upon the backend in use and how it is
+configured, but in general, the safest course of action is not to expose
+it at all.  Keep in mind that in any Glance/Nova/Cinder configuration
+where Nova and/or Cinder do copy-on-write directly in the image store,
+image data transfer takes place outside Glance's image data download
+path, and hence the os_hash_value is *not* checked.  Thus, if the
+backend store is compromised, and image data is replaced directly in the
+backend, the substitution will *not* be detected.  That's why it is
+important not to give malicious actors unnecessary hints about the image
+storage backend.
+
+We therefore recommend that OpenStack services that require exposure of
+the 'direct_url' image property be similarly configured to use an
+internal-only-facing glance-api.  (End users who wish to download an
+image do not require access to the direct_url image property because
+they can simply use the image-data-download API call [3].)

### Recommended Actions ###
 A glance-api service with 'show_multiple_locations' enabled should
-*never* be exposed directly to end users.  This setting should only
-be enabled on an internal-only-facing glance-api that is used by
-OpenStack services that require access to image locations.
+*never* be exposed directly to end users.  This setting should only be
+enabled on an internal-only-facing glance-api that is used by OpenStack
+services that require access to image locations.  This could be done,
+for example, by running two glance-api services with different
+configuration files and using the appropriate configuration options for
+each service to specify the Image API endpoint to access, and making
+sure the special internal endpoint is firewalled in such a way that only
+the appropriate OpenStack services can contact it.