Stack adopt doesn't validate resource_data
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
Triaged
|
Medium
|
Kanagaraj Manickam | ||
OpenStack Security Advisory |
Invalid
|
Undecided
|
Unassigned |
Bug Description
I've been looking into the various issues with stack abandon/adopt, and there is an issue with the way adopt allows users to inject whatever they want into resource_data and resource_id, without any validation at all.
As mentioned in bug #1301314, one issue is that stack adopt will adopt any resources regardless of project, but if we fix that by comparing the context project_id with that in the adopt_data, we still have the following problems:
1. Every resource must validate the ID of the thing being adopted is actually in the correct project and that the user hasn't just changed the project_id in the adopt_data
2. Several resources contain ID's of things in resource_data, all of which must be validated
3. Stack domain project is not considered, as mentioned in bug #1300734, however if we fix that, then it could be possible for a maliciously crafted adopt_data to specify some wrong stack_user_
So to fix this I think we need to:
- Implement handle_adopt for every resource which references an underlying resource accessible via an API - we need to check that the thing exists, and that it's accessible with the scope of the context provided on adopt.
- In handle_adopt for resources which contain ID's in resource_data, validate in a similar way (in particular the StackUser base class)
That is a lot of work, but it's do-able, however I don't currently have a solution for (3), because once a stack is abandoned, we have no way of directly mapping the stack domain project to the project scope of the request on adopt (other than the name I guess).
I'm setting this private security for now, as although I don't have any working exploit, I'm worried that even without fixing bug #1300734 there might be a way to abuse this.
Changed in ossa: | |
status: | New → Incomplete |
information type: | Public Security → Public |
Changed in heat: | |
assignee: | nobody → Vijendar Komalla (vijendar-komalla) |
importance: | Undecided → Medium |
Changed in heat: | |
status: | New → Triaged |
tags: | added: abandon-adopt |
Changed in heat: | |
milestone: | none → no-priority-tag-bugs |
To clarify - there is currently no known way to exploit this, the security issue is how we fix bug #1300734 without opening a security hole ref point (3) above.
So it could be argued that this is not a vulnerability as such, due to the fact that the current implementation doesn't work.
If folks would prefer we can open this to public security, I just wanted to get some initial feedback as a precaution rather than assuming it should be public.