horizon auth switch redir DoS

Bug #1651679 reported by Bernhard M. Wiedemann on 2016-12-21
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Low
Unassigned
OpenStack Security Advisory
Undecided
Unassigned
django-openstack-auth
Undecided
Unassigned

Bug Description

It is possible to construct URLs and embed them in unrelated websites like this

<iframe width="95%" height="600" src="https://dashboard.cloud.suse.de/auth/switch/144e6d002e1541f2b1397814760f2e1e/?next=/auth/switch/144e6d002e1541f2b1397814760f2e1e/%3Fnext=/auth/switch/144e6d002e1541f2b1397814760f2e1e/%3Fnext=/auth/switch/144e6d002e1541f2b1397814760f2e1e/%3Fnext=/project/instances/567e5689-145a-4843-9ba0-4800ac9bb26b/"></iframe>

and when a logged-in user loads such a page (tested with Firefox), it generates load on the horizon server without being visible to the user.

I addition to the SSL overhead, this also creates one token per redirect. In Liberty this token was immediately revoked and in Newton it is not (so IMHO even worse).

This can slow the DB down until tokens expire and cron runs again
su keystone -s /bin/bash -c "/usr/bin/keystone-manage --config-file /etc/keystone/keystone.conf token_flush" || :

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.

description: updated
Changed in ossa:
status: New → Incomplete

Adding django_openstack_auth since it may be missing the @csrf_protect decorator for the switch view. @Horizon-coresec, please triage this bug report.

Jeremy Stanley (fungi) wrote :

Based on the description, it sounds like an unauthenticated actor can (through some manner of social engineering) compel an authenticated user to generate load on the server, but by design any authenticated malicious user could do this anyway even without the described bug?

If that's the case, pretty borderline but I'd lean toward this being either class C1 (an impractical vulnerability) or D (security hardening opportunity). https://security.openstack.org/vmt-process.html#incident-report-taxonomy I'm also subscribing the security note reviewers for input.

On 2017-03-20 15:30, Jeremy Stanley wrote:
> Based on the description, it sounds like an unauthenticated actor can
> (through some manner of social engineering) compel an authenticated user
> to generate load on the server, but by design any authenticated
> malicious user could do this anyway even without the described bug?

embedding an img or iframe URL on a website someone visits (e.g. through
advertisement networks) is not that far fetched and does not even need
social engineering.

and yes, authenticated users could do load themselves,
but it might be a private cloud behind a corporate firewall, so
generating load on those from outside the firewall is still some extra
power.

Jeremy Stanley (fungi) wrote :

Sure, and it seems worth fixing, but posting malicious Web ads in an attempt to induce some load on a firewalled Horizon server strikes me as an unlikely and low-enough risk vector so as to not need an advisory (much less one coordinated secretly under embargo).

I agree on that.

If there are no objections, let's switch this bug to public and close the OSSA task.

Jeremy Stanley (fungi) wrote :

There's been no input whatsoever from Horizon devs, but since the reporter already seems to have agreed in comment #7 and this has been open for over 5 months now let's just press forward.

description: updated
information type: Private Security → Public
tags: added: security
Changed in ossa:
status: Incomplete → Won't Fix
Rob Cresswell (robcresswell) wrote :

This seems familiar, although I can't find the bug I'm thinking of. Someone mentioned a bug a while back where you did a similar thing but put the ID's in an image, so that just visiting the page generated traffic.

I don't actually think this has any practical application though; if I'm reading that URL correctly, it's triggering a switch to a specific project ID, which I assume we use the existing token to auth against, so the only way this could feasibly be used to generate load is if the malicious actor already had a valid list of all the current project IDs (or at least 2, to swap between them). Otherwise Horizon would just kick you to the login page. As far as I can tell, the only way to really disable this would be to provide another mechanism for passing the ID when swapping project.

I think this is really very low priority, given the above.

Gary W. Smith (gary-w-smith) wrote :

Assigning importance to Low per Rob's comment

Changed in horizon:
importance: Undecided → Low
Ivan Kolodyazhny (e0ne) wrote :

It sounds more like a configuration issue rather than horizon issue

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers