Jump to: navigation, search

Difference between revisions of "OSSN/OSSN-0008"

(DoS style attack on noVNC server can lead to service interruption or disruption [WIP])
m (Reverted edits by Loveneet.singh (talk) to last revision by Lhinds)
 
(38 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 +
__NOTOC__
 
== DoS style attack on noVNC server can lead to service interruption or disruption ==
 
== DoS style attack on noVNC server can lead to service interruption or disruption ==
  
 
=== Summary ===
 
=== Summary ===
Currently, there is no limiting on the number of VNC sessions that can be created for a single user's VNC token which enables one to cause a DoS attack on noVNC browser proxy by requesting multiple server. This prevents subsequent access to VM's VNC console.
+
There is currently no limit to the number of noVNC or SPICE console sessions that can be established by a single user.  The console host has limited resources and an attacker launching many sessions may be able to exhaust the available resources, resulting in a Denial of Service (DoS) condition.
  
 
=== Affected Services / Software ===
 
=== Affected Services / Software ===
Horizon (VNC Console through browser), Nova (NoVNC proxy), Grizzly
+
Horizon, Nova ,noVNC proxy, SPICE console, Grizzly, Havana
  
 
=== Discussion ===
 
=== Discussion ===
NoVNC Proxy is explained well [http://docs.openstack.org/grizzly/openstack-compute/admin/content//getting-started-with-vnc-proxy.html here].
+
Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access.  Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness.
  
Once a user gets token to access a VM's VNC console, there is no restriction in the number of times the user can try connecting to the VNC console using the same token. If multiple connection requests are made, any subsequent request could timeout. This could impact users already connected to the VNC sessions, or other users trying to make new connection. This could also impact overall responsiveness of other nova services running in the novnc host.   
+
By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attackIt should be noted that there is no amplification effect.
  
Thus, a user could make the NoVNC proxy endpoint not responsive/ reachable, thereby resulting in a DoS attack. However, it is to be noted there is no amplification effect.
+
=== Recommended Actions ===
 +
For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service.  Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks.
 +
 
 +
For example, if you are using a proxy such as [http://www.openrepose.org/ '''Repose'''], enable the rate limiting feature by following these steps:
 +
 
 +
* https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter
  
=== Recommended Actions ===
+
Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections.
For current stable releases (Grizzly), users need to workaround this vulnerability by using rate-limiting proxies to cover access to NoVNC hosts.  Rate-limiting is a common mechanism to prevent DoS/ Brute-Force attacks. You can find more discussion on rate-limiting around OpenStack Networking Best practices [http://docs.openstack.org/security-guide/content/ch032_networking-best-practices.html here].
 
  
 
=== Contacts / References ===
 
=== Contacts / References ===
 +
* Author: Sriram Subramanian, CloudDon
 +
* Author: Nathan Kinder, Red Hat
 
* This OSSN : https://bugs.launchpad.net/ossn/+bug/1227575
 
* This OSSN : https://bugs.launchpad.net/ossn/+bug/1227575
* Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1227575
+
* Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575
 
* OpenStack Security ML : openstack-security@lists.openstack.org
 
* OpenStack Security ML : openstack-security@lists.openstack.org
 
* OpenStack Security Group : https://launchpad.net/~openstack-ossg
 
* OpenStack Security Group : https://launchpad.net/~openstack-ossg

Latest revision as of 14:44, 24 July 2020

DoS style attack on noVNC server can lead to service interruption or disruption

Summary

There is currently no limit to the number of noVNC or SPICE console sessions that can be established by a single user. The console host has limited resources and an attacker launching many sessions may be able to exhaust the available resources, resulting in a Denial of Service (DoS) condition.

Affected Services / Software

Horizon, Nova ,noVNC proxy, SPICE console, Grizzly, Havana

Discussion

Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness.

By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect.

Recommended Actions

For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks.

For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps:

Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections.

Contacts / References