Users of Glance may be able to replace active image data
---
### Summary ###
When Glance has been configured with the "show_multiple_locations"
option enabled it is possible for a non-admin user to replace active
image data.
As a convenience to operators, Glance has a multiple location feature,
disabled by default, that allows a single image to be stored in multiple
places. This is intended to offer an extra degree of resilience by
improving the availability of Glance images. This feature involves a
user setting a new entry in an image's 'locations' list, not visible to
users by default, via the Glance API. However, this process does not
involve taking a checksum of the data in a newly created image location,
and hence does not involve comparing the 'checksum' field of the image
(which is always visible to users) with the checksum of any added
locations. This design opens the possibility that a malicious user
could create an image in Glance, set an additional location on that
image pointing to an altered image, then delete the original location,
so that consumers of the original image would unwittingly be using the
malicious image. Note, however, that this attack vector cannot change
the original image's checksum, and it is limited to images that are
owned by the attacker.
### Recommended Actions ###
The reach of this attack depends upon how broadly usage of the original
image is spread among consumers who do not checksum images before they
are consumed. Glance enables three ways for an image to be made
available to other users:
1 Making an image "public". This makes an image available to all users
of a cloud. The ability to do this is governed by the
'publicize_image' policy, which is restricted to the admin role by
default since the Juno release.
2 Making an image "community". *This feature is only available since
Otaca.* This makes an image available to all users of a cloud, but
unlike a "public" image, it does not appear in the default image-list
response of any user (other than the owner). It is governed by the
'communitize_image' policy, which is unrestricted by default.
3 Making an image "shared". Glance allows project-to-project image
sharing, in which a user in project A shares an image with project B
by making project B a *member* of the image. The ability to do this
is governed by the 'add_member' policy, which is unrestricted by
default.
* Project-to-project sharing is the default, based on the
'owner_is_tenant' configuration setting in Glance. In a cloud
configured so that 'owner_is_tenant' is false, image sharing is
user-to-user. This is a cloud-wide configuration, users may not
determine whether sharing is project-to-project or owner-to-owner.
Note that what has been discussed so far is independent of the specific
vulnerablity discussed in this notice. We encourage cloud operators to
review their current settings for the policies mentioned above. In
particular, we recommend that the 'publicize_image' policy be restricted
to admins (as it has been by default since the Juno release) so that
users can rely on the trustworthiness of a "public" image.
With respect to the image location vulnerablity described above, we
recommend that operators review the settings of the following
configuration options and policies:
* The configuration option 'show_multiple_locations'. If this is set to
False, this attack vector is not available.
* The policy 'set_image_location'. When 'show_multiple_locations' is
set to True, we recommend that this policy be restricted to
administrators, and if necessary, to trusted users. It is currently
unrestricted by default.
* The policies 'get_image_location' and 'delete_image_location'. These
policies are unrestricted by default (but note that if
'show_multiple_locations' is False, they do not come into play).
Additionally, image consumers should be encouraged to checksum images
they consume and compare the result to the 'checksum' field in the
response from the Images API.
Finally, in addition to reviewing the specific location policy targets
mentioned above, we encourage operators to review the 'default' target
in their Glance policy.json file. This target is used when the software
references a policy target that is not specifically defined in the
policy.json file, as may happen when new targets are introduced in the
software but the policy file being used is from a prior release. Since
Newton, Glance has shipped with "default":"role:admin", but prior to
that, Glance shipped with "default":"", which would make any target not
specifically mentioned in the file unrestricted.
Users of Glance may be able to replace active image data locations"
---
### Summary ###
When Glance has been configured with the "show_multiple_
option enabled it is possible for a non-admin user to replace active
image data.
### Affected Services / Software ###
Glance, Havana, Icehouse, Juno, Kilo, Liberty, Mitaka, Newton, Ocata
### Discussion ###
As a convenience to operators, Glance has a multiple location feature,
disabled by default, that allows a single image to be stored in multiple
places. This is intended to offer an extra degree of resilience by
improving the availability of Glance images. This feature involves a
user setting a new entry in an image's 'locations' list, not visible to
users by default, via the Glance API. However, this process does not
involve taking a checksum of the data in a newly created image location,
and hence does not involve comparing the 'checksum' field of the image
(which is always visible to users) with the checksum of any added
locations. This design opens the possibility that a malicious user
could create an image in Glance, set an additional location on that
image pointing to an altered image, then delete the original location,
so that consumers of the original image would unwittingly be using the
malicious image. Note, however, that this attack vector cannot change
the original image's checksum, and it is limited to images that are
owned by the attacker.
### Recommended Actions ###
The reach of this attack depends upon how broadly usage of the original
image is spread among consumers who do not checksum images before they
are consumed. Glance enables three ways for an image to be made
available to other users:
1 Making an image "public". This makes an image available to all users
of a cloud. The ability to do this is governed by the
'publicize_image' policy, which is restricted to the admin role by
default since the Juno release.
2 Making an image "community". *This feature is only available since image' policy, which is unrestricted by default.
Otaca.* This makes an image available to all users of a cloud, but
unlike a "public" image, it does not appear in the default image-list
response of any user (other than the owner). It is governed by the
'communitize_
3 Making an image "shared". Glance allows project-to-project image
sharing, in which a user in project A shares an image with project B
by making project B a *member* of the image. The ability to do this
is governed by the 'add_member' policy, which is unrestricted by
default.
* Project-to-project sharing is the default, based on the is_tenant' configuration setting in Glance. In a cloud
'owner_
configured so that 'owner_is_tenant' is false, image sharing is
user-to-user. This is a cloud-wide configuration, users may not
determine whether sharing is project-to-project or owner-to-owner.
Note that what has been discussed so far is independent of the specific
vulnerablity discussed in this notice. We encourage cloud operators to
review their current settings for the policies mentioned above. In
particular, we recommend that the 'publicize_image' policy be restricted
to admins (as it has been by default since the Juno release) so that
users can rely on the trustworthiness of a "public" image.
With respect to the image location vulnerablity described above, we
recommend that operators review the settings of the following
configuration options and policies:
* The configuration option 'show_multiple_ locations' . If this is set to
False, this attack vector is not available.
* The policy 'set_image_ location' . When 'show_multiple_ locations' is
set to True, we recommend that this policy be restricted to
administrators, and if necessary, to trusted users. It is currently
unrestricted by default.
* The policies 'get_image_ location' and 'delete_ image_location' . These multiple_ locations' is False, they do not come into play).
policies are unrestricted by default (but note that if
'show_
Additionally, image consumers should be encouraged to checksum images
they consume and compare the result to the 'checksum' field in the
response from the Images API.
Finally, in addition to reviewing the specific location policy targets :"role: admin", but prior to
mentioned above, we encourage operators to review the 'default' target
in their Glance policy.json file. This target is used when the software
references a policy target that is not specifically defined in the
policy.json file, as may happen when new targets are introduced in the
software but the policy file being used is from a prior release. Since
Newton, Glance has shipped with "default"
that, Glance shipped with "default":"", which would make any target not
specifically mentioned in the file unrestricted.
### Contacts / References ### /launchpad. net/~openstack- ossg /blueprints. launchpad. net/glance/ +spec/multiple- image-locations
This OSSN : <link to OSSN on wiki>
Original LaunchPad Bug : <link to launchpad bug for affected project/service>
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https:/
Multiple Image Location BP : https:/
CVE: <CVE number if one was filed>