Potential XSS in image create modal or angular table

[Daniel Castellanos]

The Image Create modal allows you to create an image sending unencoded HTML and JavaScript. This could lead to a potential XSS attack

Steps to reproduce:

1. Go to project>images
2. Click on "Create image"
3. In the "Image Name" input enter some HTML code or script code (i.e <h1>This is bad</h1>, <script>alert('This is bad');</script>)
4. Fill in other required fields
5. Click on 'Create Image'

Expected Result:
The image is created but the name is safely encoded and it's shown in the table as it was written

Actual Result:
The image name is not encoded an therefore is being rendered as HTML by the browser.

[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.

[Grant Murphy (gmurphy)]

I reproduced this on devstack.

[Richard Jones (r1chardj0n3s)]

Verified and patch to fix is attached.

[Rob Cresswell (robcresswell-deactivatedaccount)]

Patch works correctly, thanks Richard. Need a second review then we can merge ASAP.

This code was added in https://github.com/openstack/horizon/commit/146256f8c71d209c2ead178d3d5c0d902c5e8846 (July 5th) so shouldn't need a backport.

[Tristan Cacqueray (tristan-cacqueray)]

Since this isn't affecting any release (and it seems it isn't since the offending commit is only in 10.0.0.0b2 and 10.0.0.0b3 tags), then there is no need for embargo. Feel free to open this bug report, submit the patch directly to gerrit and request for a Newton FFE.

Thank you for the fast feedback.

[Rob Cresswell (robcresswell-deactivatedaccount)]

Despite this not being in formally released code, I would not open this. Some teams run fairly close to master, and since we have a valid patch, we may as well keep it hidden until said patch is merged, no?

I realise that isn't strictly the policy, but it just seems a sensible course of action.

[Jeremy Stanley (fungi)]

Fair enough, though it should be switched to public shortly before the fix mentioning this bug is pushed into public code review. Also the OpenStack VMT as policy doesn't request CVE assignment nor publish security advisories for vulnerabilities in unreleased software so I'm switching the OSSA task to won't fix... class Y (Vulnerability only found in development release) in our report taxonomy: https://security.openstack.org/vmt-process.html#incident-report-taxonomy

[David Lyle (david-lyle)]

+2 on #3 from me. Verified and is a clean fix.

[Richard Jones (r1chardj0n3s)]

As I understand the process, not getting a CVE means we just skip that step and go straight to opening the bug and getting the patch up to merge.

[Tristan Cacqueray (tristan-cacqueray)]

Rob, the patch alone seems enough to understand the security issue so I'm in favor of switching this report to public as the patch is submitted to public gerrit. This will make the "Closes-Bug" commit message reference to properly update the launchpad report and it'll probably be easier to fast-track the FFE like that.

[Richard Jones (r1chardj0n3s)]

The fix has been merged as https://review.openstack.org/#/c/369779/

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/horizon 10.0.0.0rc1 release candidate.