Phishing opportunity via unvalidated text in GET request

[Mark T. Voelker]

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)]

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.

[Jeremy Stanley (fungi)]

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.

[Jeremy Stanley (fungi)]

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.

[Jeremy Stanley (fungi)]

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)]

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

[Jeremy Stanley (fungi)]

Does anyone know whether the fix for bug 1865026 has also solved this report?

[Jeremy Stanley (fungi)]

Also, after more carefully re-reading what Mark put in the bug description, I retract what I said in comment #2. This isn't a CWE-601 case as it doesn't allow to perform an actual redirect (or even support markup, so no embedded clickable link). Sounds like the most it can do is provide authentic-looking messages containing dubious instructions, so I would consider this a hardening opportunity.

[Jeremy Stanley (fungi)]

Turns out any URL provided in the next value will be followed automatically, so this is an open redirect (duplicate of bug 1865026).