service No-VNC (port 6080) doesn't require authentication

[Jeremy Stanley]

Reported via private E-mail from Anass ANNOUR:

I found that the service No-VNC (port 6080) doesn't require authentication, if you know the URL (ex: http://192.168.198.164:6080/vnc_auto.html?token=3640a3c8-ad10-45da-a523-18d3793ef8ec) you can access the machine from any other computer without any authentication before the token expires. (or in the same time as user still use the console)

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

[ANNOUR (anass-annour)]

To explain more this issue, any user (even unauthenticated) who can get the right url ( host:6080/vnc_auto.html?token=ABCD) can access the console of the machine without the need of any additional information.
You may think that obtaining the right token is complex, but it s not he case, the taken is already present in the URL (which can be obtained browser history, network sniffing, review the web proxy used in the company, ...) as the token remains valid.
Besides this, using a sort token (compared to Session ID in Horizon) into an exposed service may affect the security of Openstack.

[Andrew Laski (alaski)]

You are correct that a user who has the authentication token can gain access to the console. Whether or not that provides you useful access to the guest depends on whether or not there is still a logged in session there.

Because the token is present in the URL, which is something I'm not sure we can workaround due to how authentication is handled for websocket access, it would be best to offer that service over https to discourage network sniffing or web proxy logging. So outside of browser history or the ability to sniff a network I don't see a vulnerability here. And I'll have to defer to someone with more knowledge on the console sessions themselves to provide input on ways to further secure them.

[Solly Ross (sross-7)]

Using SSL should mitigate potential traffic sniffing issues.

Browser history is still a problem, however. One potential solution would be to make tokens returned by get-vnc-console usable only once -- once websockify retrieves the host:port combo, remove the token from the cache. This could potential cause a couple of minor inconveniences due to the way Horizon currently works, but should prevent a browser-history-based attack.

Essentially, the way things work is now is that the token is sent to the WebSocket proxy, which calls into the Nova consoleauth RPC API, which in turn retrieves the host:port combo from memcached. If we deleted the token after retrieving it, further uses of that token would cease to function.

[Tristan Cacqueray (tristan-cacqueray)]

Browser history should not be available to a potential attacker... I propose a class B2 or C1 (http://security.openstack.org/vmt-process.html#incident-report-taxonomy)

[Tony Breeds (o-tony)]

So we can mitigate the risk of packet sniffing by using https which leave browser history attacks.

We can define the lifetime of a token with the console_token_ttl config option, the default is 10mins we could make that seconds. While it doesn't completely remove the attack surface certainly makes it harder to hit. I'm not advocating for it but I have attached a patch (it needs tests) that adds a 'console_one_time_token' option so that a validated token is immediately removed from the memcache. This would (I suspect) in turn create an XSS DoS potential (stopping affected users from getting console access [via the web])

I'm not really certain this is an arms race we can win.

[Solly Ross (sross-7)]

Well, another option would be to submit tokens through POST or through a header instead of as query parameters in a GET request. The downside of this would be that users could not simply paste the results of get-vnc-console into their browser -- the API would only work through Horizon, or similar services that could make POST requests and adjust headers (for example, you could send normal keystone headers and authenticate based on those in websockify).

When Horizon is run in Apache, you could also place websockify behind an Apache proxy pass, so that browsers send cookie information along to websockify from Horizon. It would also be possible to host the actual noVNC source files as part of Horizon (since they are just CSS, JS, and HTML), and just proxy the websocket connection. Then, you could authenticate using data from the cookie. Similarly to the above option, an issue would be that a user could not simply paste the results of get-vnc-console into their browser -- it would *only* work through Horizon, or something else that could send the appropriate cookie data.

[Tony Breeds (o-tony)]

So I'm not against changing to POSTing the token but I think that's a discussion to be had, without embargo, with Horizon devs and operators.
I have no idea if taking away the ability to click the output from 'nova get-vnc-console' is a problem?

Right now do we want to do something like the config option as a quick way to reduce the attack surface.

operators could change the TTL so say 60seconds AND set one_time_token which I think is a reasonable mitigation for this bug.

I'd be happy to round up some people at the summit or write a spec for the bigger / longer term option

[Jeremy Stanley (fungi)]

Tristan: C1 probably. There is plenty an attacker can do if they have access to someone's browser history, and as already pointed out they would need to exploit it before the session validity expires (10 minutes by default). This falls squarely in the realm of impracticality.

I recommend we switch this to a normal bug report on Monday unless there are objections to the contrary before then.

[Tony Breeds (o-tony)]

@fungi I'm okay with that.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/182129

[Tristan Cacqueray (tristan-cacqueray)]

Description edited to remove the embargo header...

[Daniel Berrange (berrange)]

NB, with any discussion regarding consoles it is important to remember that SPICE consoles involve the opening of many TCP connections (as many as 10 separate connections). So if you make tokens single-use it will break SPICE, so I don't think that's really a viable approach.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Michael Still (<email address hidden>) on branch: master
Review: https://review.openstack.org/182129
Reason: This change has stalled. Please restore it if that's not the case.

[pandatt (pandatt)]

https://review.opendev.org/#/c/623120/
https://review.opendev.org/#/c/622336/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/623120
Committed: https://git.openstack.org/cgit/openstack/nova-specs/commit/?id=33a13a1aabee9d89a88c3b7e3e18244b2bd6a0c1
Submitter: Zuul
Branch: master

commit 33a13a1aabee9d89a88c3b7e3e18244b2bd6a0c1
Author: pandatt <[e-mail]>
Date: Thu Dec 6 10:31:58 2018 +0800

    Proposal for a safer remote console with password authentication

    The feature aims at providing a safer remote console with password
    authentication. End users can set console password for their instances.
    Any user trying to access the password-encrypted console of instance
    will get a locked window from web console prompting for ``password``
    input, and this provides almost the same experience as using VNC clients
    (e.g vncviewer) to access vnc servers that require password
    authentication.

    Blueprint: nova-support-webvnc-with-password-anthentication
    Related-bug: #1447679
    Change-Id: I8416ceb88b9e9e6498a81c678944bc5d96700fc3