Phishing opportunity via unvalidated text in GET request

Bug #1825549 reported by Mark T. Voelker on 2019-04-19
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
High
Unassigned
OpenStack Security Advisory
Undecided
Unassigned

Bug Description

Some pages in Horizon appear to not validate the source information when displaying data provided in parameters, leading to a potential opportunity for phishing. For example, here:

https://git.openstack.org/cgit/openstack/horizon/tree/horizon/templates/auth/_login_form.html#n37

Imagine this scenario: Alice logs into Horizon, works for a while, then checks her email. An attacker has emailed her asking to check out something in Horizon and provides a clickable link whose href is:

http://myhorizonurl.com/dashboard/auth/login/?next=Error!+Please+try+this+url+instead:%00http://www.malwaredomain.com/

Since Alice is already logged in to Horizon, when she clicks the link she will see a "proper-looking" message in Horizon pointing her to another site where she might be further exploited. This might be avoided if the source of the parameters in the GET request were validated.

Note that AFAIK it's not possible to do markup in the message (e.g. to turn malwaredomain.com into a clickable link on the Horizon page) or actually create a redirect with this approach. In this particular case it also only works if the user is logged in already (otherwise Alice will get punted to the login screen and will get a 404 error after providing credentials).

Jeremy Stanley (fungi) wrote :

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.

Changed in ossa:
status: New → Incomplete
description: updated
Jeremy Stanley (fungi) wrote :

This sounds like a classic "CWE-601: URL Redirection to Untrusted Site ('Open Redirect')" ( https://cwe.mitre.org/data/definitions/601.html ) so probably a class A vulnerability report per https://security.openstack.org/vmt-process.html#incident-report-taxonomy if it can be cleanly patched on all affected stable branches.

Ivan Kolodyazhny (e0ne) on 2019-05-22
Changed in horizon:
status: New → Confirmed
importance: Undecided → High
Jeremy Stanley (fungi) wrote :

In keeping with recent OpenStack vulnerability management policy changes, no report should remain under private embargo for more than 90 days. Because this report predates the change in policy, the deadline for public disclosure is being set to 90 days from today. If the report is not resolved within the next 90 days, it will revert to our public workflow as of 2020-05-27. Please see http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012721.html for further details.

description: updated
Jeremy Stanley (fungi) wrote :

It doesn't look like this report has seen any activity since my update two months ago, so consider this a friendly reminder:

The embargo for this report is due to expire one month from today, on May 27, and will be switched public on or shortly after that day if it is not already resolved sooner.

Thanks!

Jeremy Stanley (fungi) on 2020-05-19
description: updated
Jeremy Stanley (fungi) wrote :

The embargo for this report has expired and is now lifted, so it's acceptable to discuss further in public.

description: updated
information type: Private Security → Public Security
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers