Activity log for bug #1681465

Date Who What changed Old value New value Message
2017-04-10 14:40:43 Viet Tran bug added bug
2017-04-10 21:59:55 Jeremy Stanley description 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. This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. 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.
2017-04-10 22:00:29 Jeremy Stanley bug task added ossa
2017-04-10 22:01:25 Jeremy Stanley bug added subscriber Nova Core security contacts
2017-04-10 22:02:09 Jeremy Stanley ossa: status New Incomplete
2017-04-12 07:05:29 Viet Tran bug added subscriber Jose Castro Leon
2017-05-24 14:36:35 Jeremy Stanley description This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. 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. 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.
2017-05-24 14:36:43 Jeremy Stanley information type Private Security Public
2017-05-24 14:36:52 Jeremy Stanley tags security
2017-05-24 14:36:59 Jeremy Stanley ossa: status Incomplete Won't Fix
2017-05-24 15:58:33 Tim Bell bug added subscriber Tim Bell
2017-07-25 16:59:33 Sean Dague nova: status New Opinion
2017-07-25 16:59:36 Sean Dague nova: importance Undecided Wishlist
2017-09-28 22:53:28 Alejandro Comisario bug added subscriber Alejandro Comisario