OpenStack Object Storage (swift)

Object GET on deleted account is successful

Bug #1381541 reported by Madhuri Kumari on 2014-10-15

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	OpenStack Object Storage (swift)	Confirmed	Wishlist	Madhuri Kumari
	OpenStack Security Advisory	Won't Fix	Undecided	Unassigned

Bug Description

In case, we delete an account and then perform GET operation on object of the same account, the operation is successful which should actually fail.

Actually what happens here during object GET, the container is HEAD for its existence which in turn HEAD account(if info is not found in memcache), then account returns 404 which result in empty container_info. But in GETorHEAD method of ObjectController the container_info is not being checked. Thus the request is forwarded to object service and object service returns success.

Madhuri Kumari (madhuri-rai07) on 2014-10-15

Changed in swift:
assignee:	nobody → Madhuri Kumari (madhuri-rai07)

Jeremy Stanley (fungi) on 2014-10-15

Changed in ossa:
status:	New → Incomplete

Revision history for this message

Jeremy Stanley (fungi) wrote on 2014-10-15:

I've added an incomplete security advisory task and subscribed the Swift core security reviewers to confirm or refute the implied security impact of this bug.

Are you saying the Swift service continues to serve orphaned objects after deletion of the owning account? If so, it's not immediately obvious to me how this might be exploited by an attacker.

Revision history for this message

Samuel Merritt (torgomatic) wrote on 2014-10-15:

I think this could be classified as either an enhancement to Swift or a bug (I don't care which), but I don't think it's a security vulnerability. Typically, deleting an account is an action taken by an administrator; they'll also go tell the auth system that the user in question is no longer valid.

This bug (or whatever it is) doesn't let any user gain access to objects they shouldn't have; it just extends the period of time for which they have access.

Revision history for this message

Thierry Carrez (ttx) wrote on 2014-10-16:

I agree it hardly feels like a vulnerability.

Revision history for this message

Madhuri Kumari (madhuri-rai07) wrote on 2014-10-16:

bug_1381541 Edit (581 bytes, text/plain)

Hi Jeremy, Samuel, Thierry,

If the issue is not a security vulnerability, the status can be changed.

Can I change the status?

And for the solution, I have thought of checking the existence in GETorHEAD of ObjectController which will return HTTPBadRequest if the account/container doesn't exists.

Please verify my understanding.

Revision history for this message

Tristan Cacqueray (tristan-cacqueray) wrote on 2014-10-16:

Thanks for the fix!

As "this bug doesn't let any user gain access to objects they shouldn't have" it is safe to change the status and fix this the usual way.

@Madhuri Feel free to submit your change to gerrit.

information type:	Private Security → Public
Changed in ossa:
status:	Incomplete → Won't Fix

Revision history for this message

Madhuri Kumari (madhuri-rai07) wrote on 2014-10-19:

But still the information may be obsolete for about 60 seconds(i.e recheck_account_existence time period) because the information stored in memcache would serve the HEAD request to the account, thus serving the request successfully on objects.

So I have one query here to ask, is the above case fine or we can delete the entry in memcache after deletion of account in DELETE method of account.py?

Could you please suggest?

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2015-01-06: Fix proposed to swift (master)

Fix proposed to branch: master
Review: https://review.openstack.org/145141

Changed in swift:
status:	New → In Progress

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2015-06-05: Change abandoned on swift (master)

Change abandoned by John Dickinson (<email address hidden>) on branch: master
Review: https://review.openstack.org/145141
Reason: Abandoning due to lack of activity since the last negative review. You can restore the change if you want to keep working on it.