glance-manage db purge breaks image immutability promise

[Erno Kuvaja]

Using glance-manage db purge command opens possibility to recycle image-IDs.

When the row is deleted from the database the ID is not known by glance anymore and thus it's not unique during the deployment lifecycle. This opens possibility to following scenario:

1) End user boots VM from private/public/shared image.
2) Image owner deletes the image.
3) glance-manage db purge gets ran which deletes record that image has ever existed.
4) Either malicious user or someone unintentionally creates new image with same ID (being same user so having access to the image by owning it or it becoming public/shared(/possbly community at some point))
5) Same end user boots either snapshot from the original image or nova needs to migrate the VM to another host. Now the user's VM will be rebuilt on top of the new image. Worst case scenario the user had no idea that the image data changed in between.

This behavior breaks Glance image immutability promise that has bee stated that the data related to image ID that has gone active will never change.

We have two solutions for this. Either we introduce table to track the deleted image-IDs and get glance to cross check that during the image create or we leave it as is but issue notice/documentation what are the implications if the purge is used transferring the responsibility to the cloud operators.

This was partially discussed in the virtual glance midcycle meetup so it might not be justified to leave this as private but I wanted to leave that decision to VMT.

[Erno Kuvaja (jokke)]

I added Brian as we discussed about this yesterday and he is part of glance-coresec but did not have access to the bug.

[Brian Rosmaita (brian-rosmaita)]

This is a good summary of the problem.

One thing we thought about was restricting the ability to specify an image_id at the time of image creation to admins by policy, so that this feature couldn't be abused. An objection to that strategy is that for hybrid clouds, it would be convenient for regular users to use the same id for the same image in each cloud.

[Jeremy Stanley (fungi)]

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.

[Jeremy Stanley (fungi)]

If this was discussed in a public venue (I can't find mention of it in IRC logs so presumably it happened in voice chat instead?) then there's not a lot of point in maintaining an embargo. Also if the fix ends up just being a change to documentation or happens only in master (adding database tables doesn't seem likely to pass muster for a stable backport) then this would at most be a security note and not an advisory anyway.

It also seems like exploitation would be hard to target unless the operator is routinely purging Glance's DB.

[Brian Rosmaita (brian-rosmaita)]

The discussion was in the virtual mid-cycle meeting in bluejeans and I believe a recording is available.

Just one thing about the exploit -- combine this with https://bugs.launchpad.net/glance/+bug/1545092, and a bad actor could put the DB in a situation where it needs to be purged right away.

I don't think bug 1545092 has been publicized yet (there was going to be a combined security note about a few issues, iirc), maybe the recommendation for this bug could be rolled into that.

[Erno Kuvaja (jokke)]

The recording is not yet available and if we want to keep this private, I can withold that part from the recording. (I need to edit it to avoid publishing sensitive info like phone numbers anyways).

[Erno Kuvaja (jokke)]

so the audience on that call was ~7 people which of at least 3 belongs to the glance sec group Brian, Nikhil and Hemanth, the 4th would be me so we do not have too many people yet this has been going out.

[Nikhil Komawar (nikhil-komawar)]

We haven't published the recordings so I agree that having this in a private bug is okay.

Please note that this issue exists at least since Liberty. The commit that introduced this feature and hence a vulnerability along with it is:

commit 9a6823326b43c01562a736d417f6e5f7f68e44cf
Author: Martin Mágr <email address hidden>
Date: Mon Aug 24 13:37:54 2015 +0200

    Add db purge command

    This patch adds "db purge" to glance-manage for deleting soft deleted
    images, tasks.

    Change-Id: I5b609292aa15f8133d0d785fcf9143825bed8073
    Implements: blueprint database-purge

I can confirm that this is a real issue.

Also, I think this vulnerability can exist irrespective of the existence of the db-purge utility as a individual operator can choose to hard-delete the soft-deleted old rows on their deployment.

There is a problem with introducing a new table due the growth in the size of the DB over period of time. This was one of the major reason why the db-purge utility was introduced. I think this bug is subject to further discussion on the best possible solution. I, however, find it in the best interest to send a CVE note with a advice on not deleting soft-deleted images. It should be left to the operator to decide which images are safe to be removed from the database once their deployment is assured of non-existence of such -- like no tracking of that image id in Nova, Cinder, Ironic, Heat, etc.

[Jeremy Stanley (fungi)]

The VMT doesn't request CVE assignment for bugs which aren't going to have fixes backported, though that doesn't stop someone else from requesting a CVE once this is public. However, the point of a CVE is to be able to track whether a given deployment is vulnerable, and if there's no patch or configuration change which makes deployments no longer at risk of this then there's not much point to having a CVE assigned for it anyway in my opinion.

[Jeremy Stanley (fungi)]

By "note" there I'm going to assume you meant OSSN, and I agree that's likely warranted. I'm subscribing the Security team reviewers for further input.

[Nikhil Komawar (nikhil-komawar)]

Thanks Jeremy.

Without going into the technical details about the kind of notes we want to make available to the audience, I think a good security/email documentation with availability for reference (link or number) will help us resolve the communication gap around where we see this being an issue for some of the operators who have chosen to use the db-purge utility since Liberty. Nevertheless, this being a issue for all operators irrespective of who has chosen to use the upstream utility, I think an email to the wider audience is necessary.

Also, I think we need a best practice on this kind of behavior. Maintaining the list of image-ids ever used may be a good amount of trouble for some of the ops, but I'd like to hear some feedback from the glance-core-sec before taking further action.

[Hemanth Makkapati (hemanth-makkapati)]

I didn't get a chance yet to replicate this on devstack but this certainly sounds like a real issue.

I like the idea of creating a separate table that keeps track of all the deleted IDs. Doing this will at least isolate the performance issues to one operation, image create (that too only when an ID is provided). On the other hand, the no-purge strategy won't be practical for big clouds and it will impact performance of many image operations. Like Nikhil said, even if we get rid of the purge utility, there is no guarantee that operators themselves won't prune the database. So, I'm inclining towards educating the operators about the risks involved and maybe also provide a way to control or completely disable image creation by id with a policy and/or configuration. That way, the operators can take a call themselves based on their respective business case.

[Travis McPeak (travis-mcpeak)]

Agreed, this seems like a good target for an OSSN.

[Travis McPeak (travis-mcpeak)]

(added)

[Travis McPeak (travis-mcpeak)]

I'm working on the note for this now. What's the best recommendation we can give? It seems like we don't have the ability to either:

 - disable image creation by ID
 - track previously assigned image IDs

So what's the best recommendation we can give?

[Erno Kuvaja (jokke)]

Travis,

I think the best recommendation we can give at this stage is to not use purge on any system that does not have image creation limited to trusted users.

[Brian Rosmaita (brian-rosmaita)]

I agree with Erno. I don't know how much info is usually included in this kind of note, but it might be worth mentioning that if an operator absolutely must do some trimming, the key thing is not to delete the soft-deleted rows in the 'images' table. It should be OK to hard delete the associated rows in the image_members, image_properties, image_tags, and image_locations tables.

[Travis McPeak (travis-mcpeak)]

Thanks Erno and Brian. I'm working on a draft of the note now. I'll post here soon.

[Travis McPeak (travis-mcpeak)]

How does this look?

Deleted Glance image IDs may be reassigned
---

### Summary ###
It is possible for image IDs from deleted images to be reassigned to
other images. This creates the possibility that:

 - Alice creates a VM that boots from image ID X
 - Bob (image X's owner) deletes the image
 - Mallory creates a new image and specifies that the ID should be X
 - Alice boots her VM without realizing that the image has changed

### Affected Services / Software ###
Glance, Liberty, Mitaka

### Discussion ###
Glance's image table doesn't maintain a list of previously used image
IDs. Previously assigned image IDs will be listed in the image table
as deleted, but these records may be removed (for performance reasons)
with the `glance db purge` utility or manually by an administrator.

If these records are removed a malicious user may intentionally upload
a new image using the same ID (Glance allows an image creator to
optionally specify the image ID). This would cause any victim
instances referencing the ID to use an attacker supplied image.

### Recommended Actions ###
The combination of purged Glance database entries and non-admin image
upload is dangerous. In environments where normal users are permitted
to upload images, the `images` table should not be purged.

### Contacts / References ###
Author: Travis McPeak, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0075
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1593799/
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg

[Brian Rosmaita (brian-rosmaita)]

Thanks, Travis. Sorry to be so long getting to this.

I hate to be pedantic (but I used to be a professor, so I can't help it). Two comments:

(1) The scenario in your "Summary" isn't quite right. For that exact scenario to work you'd also have to have one of the following:

(A) Mallory has permission to "publicize" images (limited to admins by default policy). Otherwise, Alice can't access the "new" image X uploaded by Mallory.

(B) Mallory doesn't have permission to "publicize" images, but knows Alice's project ID, and shares the image with Alice. (If we assume that the original image X was shared by Bob, since Mallory didn't own the original image X, she couldn't see the full member list of everyone Bob had shared it with, so she'd have to guess or do some social engineering.)

I guess what I'm really getting at here is that the most likely scenario for this to work is that either Bob and Mallory are the same person or are in cahoots. But after writing all that down, in the long run, it doesn't matter, it *is* possible for this to happen, so maybe your summary is sufficient after all.

(2) If a deployer wants to purge the database for space reasons, it would be OK to manually remove the soft-deleted rows from the image_properties, image_tags, image_members, and image_locations tables. (You do say "don't delete rows from the images table", but maybe it's worth saying that it's OK to delete rows from these other tables.) I haven't read a lot of security notes, so ignore this suggestion if it's a dumb idea or inconsistent with the usual practice.

Otherwise, the note LGTM.

[Travis McPeak (travis-mcpeak)]

Brian - thanks for the clarity, and this isn't pedantic. We shoot for being precise in these notes. I'll update the note to reflect these points.

[Travis McPeak (travis-mcpeak)]

Everybody happy with this?

Deleted Glance image IDs may be reassigned
---

### Summary ###
It is possible for image IDs from deleted images to be reassigned to
other images. This creates the possibility that:

 - Alice creates a VM that boots from image ID X
 - Bob (image X's owner) deletes the image
 - Mallory creates a new image and specifies that the ID should be X
 - Alice boots her VM without realizing that the image has changed

It's worth noting that in this scenario Mallory needs to know Alice's
project ID to share the new image with Alice. This isn't enough to
mitigate the issue as project IDs weren't designed to be confidential.

### Affected Services / Software ###
Glance, Liberty, Mitaka

### Discussion ###
Glance's image table doesn't maintain a list of previously used image
IDs. Previously assigned image IDs will be listed in the image table
as deleted, but these records may be removed (for performance reasons)
with the `glance db purge` utility or manually by an administrator.

If these records are removed a malicious user may intentionally upload
a new image using the same ID (Glance allows an image creator to
optionally specify the image ID). This would cause any victim
instances referencing the ID to use an attacker supplied image.

### Recommended Actions ###
The combination of purged Glance database entries and non-admin image
upload is dangerous. In environments where normal users are permitted
to upload images, the `images` table should not be purged. It is
however safe to delete rows from `image_properties`, `image_tags`,
`image_members`, and `image_locations` tables.

### Contacts / References ###
Author: Travis McPeak, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0075
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1593799/
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg

[Nikhil Komawar (nikhil-komawar)]

Thanks the note looks mostly clean.

A few things to note:

* Affected Services will include Newton as we haven't removed the purge utility yet and don't plan on removing in Newton.

* Attack scenario is not very clear, not sure if that's intended. If you would like -- some more inline suggestions:
 - Alice creates a VM that boots from image ID X "shared with her by trusted individual Bob"
 - Bob (image X's owner) deletes the image "and as per design no notification is sent to Alice"
 - Mallory creates a new image and specifies that the ID should be X "and shares it with Alice, again Alice is not aware of this update."
 - Alice boots her VM without realizing that the image has changed

* Another possible scenario involves Mallory having the ability to publicize the image in which case sharing isn't required in the above case.

As a courtesy, please make sure to give 24 hours to the glance-core-sec team as people are in different parts of the world before publishing note.

[Travis McPeak (travis-mcpeak)]

Thanks, latest:

Deleted Glance image IDs may be reassigned
---

### Summary ###
It is possible for image IDs from deleted images to be reassigned to
other images. This creates the possibility that:

 - Alice creates a VM that boots from image ID X which has been shared
 with her by a trusted party, Bob.
 - Bob (image X's owner) deletes the image. As per design, Alice
 receives no notification this happened.
 - Mallory creates a new image and specifies that the ID should be X.
 - Mallory shares image X with Alice. Again, per design, Alice is not
 notified of this change.
 - Alice boots her VM without realizing that the image has changed.

It's worth noting that in this scenario Mallory needs to know Alice's
project ID to share the new image with Alice. This isn't enough to
mitigate the issue as project IDs weren't designed to be confidential.

### Affected Services / Software ###
Glance, Liberty, Mitaka, Newton

### Discussion ###
Glance's image table doesn't maintain a list of previously used image
IDs. Previously assigned image IDs will be listed in the image table
as deleted, but these records may be removed (for performance reasons)
with the `glance db purge` utility or manually by an administrator.

If these records are removed a malicious user may intentionally upload
a new image using the same ID (Glance allows an image creator to
optionally specify the image ID). This would cause any victim
instances referencing the ID to use an attacker supplied image.

### Recommended Actions ###
The combination of purged Glance database entries and non-admin image
upload is dangerous. In environments where normal users are permitted
to upload images, the `images` table should not be purged. It is
however safe to delete rows from `image_properties`, `image_tags`,
`image_members`, and `image_locations` tables.

### Contacts / References ###
Author: Travis McPeak, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0075
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1593799/
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg

[Nikhil Komawar (nikhil-komawar)]

A nit, otherwise looks good.

Worth mentioning that:-

Mallory and(or) Bob doesn't need to use the sharing workflow if "publicizing" images is allowed by policy in the cloud deployment.

Thanks for working with us patiently on this, Travis!

[Travis McPeak (travis-mcpeak)]

Good point (and my pleasure about working with you on the note!)

Deleted Glance image IDs may be reassigned
---

### Summary ###
It is possible for image IDs from deleted images to be reassigned to
other images. This creates the possibility that:

 - Alice creates a VM that boots from image ID X which has been shared
 with her by a trusted party, Bob.
 - Bob (image X's owner) deletes the image. As per design, Alice
 receives no notification this happened.
 - Mallory creates a new image and specifies that the ID should be X.
 - Mallory shares image X with Alice. Again, per design, Alice is not
 notified of this change.
 - Alice boots her VM without realizing that the image has changed.

It's worth noting that in this scenario Mallory needs to know Alice's
project ID to share the new image with Alice. This isn't enough to
mitigate the issue as project IDs weren't designed to be confidential.

If the environment allows non-administrators to publish images Mallory
doesn't have to explicitly share with Alice or know her project ID.

### Affected Services / Software ###
Glance, Liberty, Mitaka, Newton

### Discussion ###
Glance's image table doesn't maintain a list of previously used image
IDs. Previously assigned image IDs will be listed in the image table
as deleted, but these records may be removed (for performance reasons)
with the `glance db purge` utility or manually by an administrator.

If these records are removed a malicious user may intentionally upload
a new image using the same ID (Glance allows an image creator to
optionally specify the image ID). This would cause any victim
instances referencing the ID to use an attacker supplied image.

### Recommended Actions ###
The combination of purged Glance database entries and non-admin image
upload is dangerous. In environments where normal users are permitted
to upload images, the `images` table should not be purged. It is
however safe to delete rows from `image_properties`, `image_tags`,
`image_members`, and `image_locations` tables.

### Contacts / References ###
Author: Travis McPeak, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0075
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1593799/
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg

[Nikhil Komawar (nikhil-komawar)]

This sentence looks rather incomplete:

"If the environment allows non-administrators to publish images Mallory
doesn't have to explicitly share with Alice or know her project ID."

was it intentional?

[Travis McPeak (travis-mcpeak)]

Good catch, how about this?

Deleted Glance image IDs may be reassigned
---

### Summary ###
It is possible for image IDs from deleted images to be reassigned to
other images. This creates the possibility that:

 - Alice creates a VM that boots from image ID X which has been shared
 with her by a trusted party, Bob.
 - Bob (image X's owner) deletes the image. As per design, Alice
 receives no notification this happened.
 - Mallory creates a new image and specifies that the ID should be X.
 - Mallory shares image X with Alice. Again, per design, Alice is not
 notified of this change.
 - Alice boots her VM without realizing that the image has changed.

It's worth noting that in this scenario Mallory needs to know Alice's
project ID to share the new image with Alice. This isn't enough to
mitigate the issue as project IDs weren't designed to be confidential.

Also, if the environment allows non-administrators to publish images,
Mallory doesn't have to explicitly share with Alice or know her project
ID to perform this attack.

### Affected Services / Software ###
Glance, Liberty, Mitaka, Newton

### Discussion ###
Glance's image table doesn't maintain a list of previously used image
IDs. Previously assigned image IDs will be listed in the image table
as deleted, but these records may be removed (for performance reasons)
with the `glance db purge` utility or manually by an administrator.

If these records are removed a malicious user may intentionally upload
a new image using the same ID (Glance allows an image creator to
optionally specify the image ID). This would cause any victim
instances referencing the ID to use an attacker supplied image.

### Recommended Actions ###
The combination of purged Glance database entries and non-admin image
upload is dangerous. In environments where normal users are permitted
to upload images, the `images` table should not be purged. It is
however safe to delete rows from `image_properties`, `image_tags`,
`image_members`, and `image_locations` tables.

### Contacts / References ###
Author: Travis McPeak, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0075
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1593799/
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg

[Brian Rosmaita (brian-rosmaita)]

This looks good to me, Travis. Thanks!

[Erno Kuvaja (jokke)]

### Discussion ###
Glance's image table doesn't maintain a list of previously used image
IDs. Previously assigned image IDs will be listed in the image table
as deleted, but these records may be removed (for performance reasons)
with the `glance db purge` utility or manually by an administrator.

`glance-manage db purge` This is not functionality of python-glanceclient but glance-manage admin tool.

Other than that looks good to me on latest rev.

[Brian Rosmaita (brian-rosmaita)]

Erno is completely correct, the command should be 'glance-manage db purge'. With that correction, I think the proposed text is fine.

[Nikhil Komawar (nikhil-komawar)]

Good catch Erno.

On a second or may be third thought :) --

"""
### Affected Services / Software ###
Glance, Liberty, Mitaka, Newton
"""

I wonder if we should have this as :-

"""
### Affected Services / Software ###
Glance, Liberty onward.

Glance team isn't planning on removing this purge feature yet. If you would like to see it removed please propose the same to the developers or if you are monitoring if this is (will be) removed, then please read the release notes of that release.
"""

The reason is, if we simply list out releases "Glance, Liberty, Mitaka, Newton" then this note will / may become outdated in Ocata.

Thoughts?

[Nikhil Komawar (nikhil-komawar)]

Move up the level to critical -- as per the latest description the issue is pretty convoluted.

[Travis McPeak (travis-mcpeak)]

Thanks Nikhil. I've listed them this way because it's our standard format for notes, although you're right about the issue where notes become outdated :|

[Travis McPeak (travis-mcpeak)]

(hopefully) last version:

Deleted Glance image IDs may be reassigned
---

### Summary ###
It is possible for image IDs from deleted images to be reassigned to
other images. This creates the possibility that:

 - Alice creates a VM that boots from image ID X which has been shared
 with her by a trusted party, Bob.
 - Bob (image X's owner) deletes the image. As per design, Alice
 receives no notification this happened.
 - Mallory creates a new image and specifies that the ID should be X.
 - Mallory shares image X with Alice. Again, per design, Alice is not
 notified of this change.
 - Alice boots her VM without realizing that the image has changed.

It's worth noting that in this scenario Mallory needs to know Alice's
project ID to share the new image with Alice. This isn't enough to
mitigate the issue as project IDs weren't designed to be confidential.

Also, if the environment allows non-administrators to publish images,
Mallory doesn't have to explicitly share with Alice or know her project
ID to perform this attack.

### Affected Services / Software ###
Glance, Liberty, Mitaka, Newton

### Discussion ###
Glance's image table doesn't maintain a list of previously used image
IDs. Previously assigned image IDs will be listed in the image table
as deleted, but these records may be removed (for performance reasons)
with the `glance-manage db purge` utility or manually by an
administrator.

If these records are removed a malicious user may intentionally upload
a new image using the same ID (Glance allows an image creator to
optionally specify the image ID). This would cause any victim
instances referencing the ID to use an attacker supplied image.

### Recommended Actions ###
The combination of purged Glance database entries and non-admin image
upload is dangerous. In environments where normal users are permitted
to upload images, the `images` table should not be purged. It is
however safe to delete rows from `image_properties`, `image_tags`,
`image_members`, and `image_locations` tables.

### Contacts / References ###
Author: Travis McPeak, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0075
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1593799/
OpenStack Security ML : <email address hidden>
OpenStack Security Group : https://launchpad.net/~openstack-ossg

[Brian Rosmaita (brian-rosmaita)]

LGTM! Thanks, Travis.

[Travis McPeak (travis-mcpeak)]

Cool - I'll get with VMT later today for a refresher on how to send this out :)

[Nikhil Komawar (nikhil-komawar)]

Thanks, this works for me too.

Great work and thanks for your patience Travis!

[Erno Kuvaja (jokke)]

LGTM, Thanks Travis!

[Nikhil Komawar (nikhil-komawar)]

Added Stuart as he wants to pitch in. Please hold off on sending note until we get his vetted advice.

[Brian Rosmaita (brian-rosmaita)]

+1 to adding Stuart, it will be worth the wait.

[Travis McPeak (travis-mcpeak)]

Sorry guys, I thought this was ready to go. I already sent a copy to stakeholders. We've got an embargo date of 9/13.

[Brian Rosmaita (brian-rosmaita)]

Well, you did have three +2s on your proposed text! Still curious to hear Stuart's thoughts, though.

[Nikhil Komawar (nikhil-komawar)]

No worries Travis (+1 to what Brian said in comment #43).

[Stuart McLaren (stuart-mclaren)]

This is a good catch (kicking myself I didn't see it).

We probably don't want a major rewrite of the wording at this point.

If it's possible to make one change I think "publish" in this sentence is not well defined:

 "if the environment allows non-administrators to publish images"

Really, we want "publicize" or "create public images" here, because some people will probably interpret "publish" as regular create or upload. I'd like to see this changed if it's possible.

Less importantly, image sharing is also controlled by policy (we actually disable it by default) so if you also have it disabled you're unaffected. We could add an equivalent "if the environment allows image sharing". (Though this is probably fairly obvious).

For any future notifications it may be good practice to explicitly name the various policies ("publicize_image"/"add_member") we may be implying.

Would it be worthwhile to update the db purge code? (If so, I may be able to find a volunteer.)

Thanks.

[Stuart McLaren (stuart-mclaren)]

Clarification: "we actually disable it by default": By "we" here I meant HPE -- the upstream default is for sharing to be enabled.

[Nikhil Komawar (nikhil-komawar)]

>> Would it be worthwhile to update the db purge code? (If so, I may be able to find a volunteer.)

I think having some changes done would be a good addition. However, what those changes are and the effects/side-effects of the same may need to be discussed with some operators who were strongly pro this db purge feature. I believe a spec is a good starting point.

[Nikhil Komawar (nikhil-komawar)]

(thanks for the review and input, Stuart)

[Travis McPeak (travis-mcpeak)]

Cool, we can easily modify the contents of the note once it is out of embargo September 13th. I didn't understand the publish/publicize differences, learn something new e'ryday :) .

[Luke Hinds (lhinds)]

OSSN-0075 released:

https://wiki.openstack.org/wiki/OSSN/OSSN-0075

Is everyone ok if we make this bug public now?

[Jeremy Stanley (fungi)]

Yes, ideally it should have been switched to public (and a bug tag of "security" added) prior to distributing the OSSN, so that those reading it could make use of the bug link it contained.

I'll go ahead and do that now.

[Luke Hinds (lhinds)]

Thanks Jeremy, I have this noted for next time.

[Brian Rosmaita (brian-rosmaita)]

The fix is in Rocky:

spec: https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/mitigate-ossn-0075.html

code: http://git.openstack.org/cgit/openstack/glance/commit/?h=stable/rocky&id=5cc9d999352c21d3f4b5c39d3ea9d4378ca86544

docs: http://git.openstack.org/cgit/openstack/glance/commit/?h=stable/rocky&id=23d4e0e9c07f1ff6646e2f6236ee9625abd2a5cb