Stack adopt doesn't validate resource_data

[Steven Hardy]

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_project_id, then create User/AccessKey resources via stack-update to allow access to stacks in other projects.

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.

[Steven Hardy (shardy)]

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.

[Jeremy Stanley (fungi)]

If this isn't exploitable or is only exploitable on the master branch (not in any released version) then the VMT will generally not issue an advisory. Since it sounds like this is the case, I agree it's better opened as soon as possible so as to expedite a secure resolution to the problem.

[Steven Hardy (shardy)]

@Jeremy Stanley: OK, thanks for the feedback - I'll open the bug and we can try to get a fix in before the Icehouse release is declared final.

[Steven Hardy (shardy)]

Some additional issues as discussed with therve on IRC:

- Pre-signed URLs can never work and will be invalidated because the stack ID changes on adopt
- All URLs deployed in instance for native auth will have to only specify the name and get the client to do stacks:lookup or the calls will fail even when we stop deleting the stack domain project

Still trying to figure out a solution for how we validate the stack domain project on adopt.

[Kanagaraj Manickam (kanagaraj-manickam)]

Hi Vijendar Komalla, I submitted a blue-print to do resource leve abandon/adopt simliar to stack and this bug became an dependency for it. And In IRC discussion with Steven hardy, i came to know that you are very busy and couldn't find time to work on this defect. so So I am planning to work on this defect. let me know your input? Thanks

More details on the blueprint https://review.openstack.org/124707

[Kanagaraj Manickam (kanagaraj-manickam)]

Assigning to me !