VNC connection to VMs is unprotected

[Viet Tran]

Description:
============

OpenStack Nova does not provide any protection of VNC servers running on compute nodes by default. Any client that has access to management network can connect to the consoles of VMs running on compute node and obtains full access to VMs via the console (e.g. by rebooting VMs to single-user mode).

Steps to reproduce
==================
- Configuration: the management interface of the compute node has a public IP address and is not protected by firewalls
- Create a VM on the compute node
- Use a VNC client to connect directly to the IP of the compute node via port 590x from anywhere.

Expected result
===============
Connections refused. Only VNC connections from master node should be accepted. Other should connect using proxy on master node which does also authorization

Actual result
=============
Connection accepted. Anyone can use VNC client to connect directly to the console of VMs running on the compute node without any authentication/authorization

Discussion
===========

To be fair, most of examples in the OpenStack documentation have management networks private, so the network configuration in the examples are safe. However, OpenStack documentation only emphasizes the separation of management network from other networks (VM, data) and does not explicitly require (in a visible way) that the management networks must be protected (private networks, firewalls). The management network may be separated to another (public) network segment and the system is still vulnerable to the VNC attack.

Therefore, the VNC connection to compute nodes should be protected (password, iptables) by default, or the documentation should give explicit warning that the management network must be private or protected by firewalls.

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

Since this is working as designed and likely only indicates a need for improved documentation (therefore would not get a security advisory issued as there is no patch for downstream users to apply to automatically secure their deployments against the described scenario), I don't think we should bother to discuss it secretly under embargo. I also suspect this is very close to being a duplicate of bug 1435386 (at least in spirit) and ask that you evaluate its resulting documentation update at https://review.openstack.org/433321 to see whether that covers your concerns or could stand to be reiterated in other places in the admin guide, deployment documentation or security handbook.

[Viet Tran (viettran)]

For evaluating seriousness of this issue, the vulnerability has been exploited at a production OpenStack deployment. The attacker connected remotely to the console of a testing VM created on a freshly installed, newly added compute node, sent a 'SIGINT' through the TTY to reboot the VM to a single user mode session, created a new account 'setup', modified the sshd configuration to allow password authentication and used that account to mine a crypto-currency, abusing the local CPU resource.

Another big organization has reported the same vulnerability exists on its production OpenStack deployment. Fortunately, the organization has global organization firewall so the vulnerability is reduced only to intranet and is not exploited.

Single-NIC OpenStack deployments are potentially in risk because of public IPs on management network. The network monitoring is detecting active attempts to connect via port 590x from botnets.

[Tristan Cacqueray (tristan-cacqueray)]

As Jeremy said, this behavior is the actual design for VNC connections, though there are work in progress to add authentication and encryption, see: https://blueprints.launchpad.net/nova/+spec/websocket-proxy-to-host-security

Nevertheless, this seems to describe an insecure deployment and it should be reported to the deployment framework used, if any. Management network is considered trusted and access should be highly restricted as documented here: https://docs.openstack.org/security-guide/introduction/security-boundaries-and-threats.html#management

[Tristan Cacqueray (tristan-cacqueray)]

If nobody objects, I propose switching the report to public.

[Jeremy Stanley (fungi)]

I really don't see where keeping this report secret is helping anyone anyway, and given that the risk for this is already documented and there is known work underway to mitigate it in future releases I'm going ahead with switching it to public, as a potential hardening opportunity.

[Alejandro Comisario (alejandro-f)]

Guys, is there any workaround on this one ?
best.