cinder-api reflects JavaScript input

[Adam Heczko]

cinder-api reflects JavaScript input which could be used to perform Cross-Site-Scripting attack on a browser which is visiting Horizon interface and working with cinder related gui items

[Adam Heczko (aheczko-mirantis)]

Bug tested and exists in vanilla MOS 5.1

[Dmitry Mescheryakov (dmitrymex)]

Horizon team, please investigate how severe the issue is. Probably it should be reported upstream as a security bug as well.

[Adam Heczko (aheczko-mirantis)]

Hi Dmitry, I believe that this bug is rather Cinder API related than Horizon related. So in my opinion it should be closed by the Cinder team. Maybe upstream.

[Timur Sufiev (tsufiev-x)]

Adam, could you please be more specific? What does 'reflects Javascript input' mean?

[Adam Heczko (aheczko-mirantis)]

Timur, trying to inject JavaScript into the API I've discovered that API response is too verbose, in fact it responds with the script included in the "original" request, or inother words, reflects original input.
Take a lookat the following request/response pair.
In the response code, everything below the "Connection: close" should be discarded / not printed out.

REQUEST:
<script>cross_site_scripting.nasl</script>

API RESPONSE :

HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Content-Length: 596
Date: Mon, 29 Dec 2014 09:50:52 GMT
Connection: close

File "/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 119, [...]
"URL fragments must start with / or http:// (you gave %r)" % url)
AssertionError: URL fragments must start with / or http:// (you gave '<s
cript>cross_site_scripting.nasl</script>')

[Timur Sufiev (tsufiev-x)]

Adam, in case the user inputs data via UI provided by Horizon, all data is sanitized thus making XSS impossible. In case you're providing it via Cinder API it's indeed out of scope Horizon team.

[Dmitry Mescheryakov (dmitrymex)]

Adam, lets reiterate in this bug and another similar one - https://bugs.launchpad.net/mos/+bug/1407093

So, for Cinder and Neutron APIs it is true that if user sends request containing javascript, he will receive response containing the same javascipt. There is no victim in that scenario. So, how that could be exploited?

[Adam Heczko (aheczko-mirantis)]

Dmitry, please consider that web services needs to ensure that output sent to clients is encoded to be consumed as data and not as scripts. This gets pretty important when web service clients use the output to render HTML pages either directly or indirectly using AJAX/JavaScript objects.
Receiving JavaScript in the browser (Horizon for example) in HTML/Ajax objects where only data is intended could cause damages.
OTOH we are going to implement automatic security scanning to MOS APIs, so besides above concerns, it will raise false-positives into vulnerability testing engines.

[Dmitry Mescheryakov (dmitrymex)]

Adam, ok, I think I understand your point. It is indeed improper for a service to return non-formatted response. But on the other side, I still fail to see how that can be used as attack. So, overall I think that is not a severe issue.

[Ivan Kolodyazhny (e0ne)]

Bug was reported to MOS 5.1(Icehouse). Need to test with Juno/Kilo (MOS 6.x/7.x)

[Ivan Kolodyazhny (e0ne)]

Can't reproduce with MOS 8:
I've created volume using the following command:
root@node-1:~# cinder create 1 --display-name='<alert>1</alert>dsds'

mysql> select display_name from volumes;
+----------------------+
| display_name |
+----------------------+
| <alert>1</alert>dsds |
| NULL |
+----------------------+
2 rows in set (0.00 sec)

mysql>

Horizon doesn't execute script.

[Ivan Kolodyazhny (e0ne)]

Oleksiy Butenko can't reproduce this issue with MOS 9 too.

[Dina Belova (dbelova)]

More than a month in the incomplete state, moving to Invalid. Please move back to Confirmed if the issue is still reproducible.

[Tristan Cacqueray (tristan-cacqueray)]

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.

Does horizon sanitize cinder-api message ?

[Lin Hua Cheng (lin-hua-cheng)]

horizon does not directly render the error message from the backend, due to the backend messages are not translatable. So we have low risk this is happening in horizon.

Even if we direct render the backend message, when we render the message on django template, we automatically escape the messages.

For example :

https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/_messages.html#L10

{{ messages }} automatically escape the string rendered, unless the string is explicit set as "safe" which don't normally do.

Marking as invalid for horizon.

[Tristan Cacqueray (tristan-cacqueray)]

Based on the above comment i've closed the OSSA task. I'm not sure about MOS affect, is it safe to also switch this bug report to public ?

[Jeremy Stanley (fungi)]

On second thought, I've added cinder to this bug and subscribed their core security reviewers just to confirm whether or not they want to limit/filter the inclusion of user input in their API error response messages. Regardless, since there's no known impact this should probably be worked in public from this point.

[Morgan Fainberg (mdrnstm)]

For what it's worth, Keystone had a similar bug that we simply said "wont fix" as sanitizing the response (don't render JSON as html) is largely the client's responsibility.

I believe this bug should be switched to public at this point.

[Grant Murphy (gmurphy)]

+1 for moving this to public.

[Tristan Cacqueray (tristan-cacqueray)]

I switch this bug to public based on above comments.

[Tristan Cacqueray (tristan-cacqueray)]

@cinder-coresec, could you check please comment #17 ? If that's ok for you, we'd like to close the OSSA task of this bug.

[Sean McGinnis (sean-mcginnis)]

I have to agree with Morgan's comment (comment #18). I don't see this as a vulnerability concern from the Cinder perspective.