Jump to: navigation, search

Difference between revisions of "OSSN/OSSN-0008"

(→‎Recommended Actions)
m (Reverted edits by Loveneet.singh (talk) to last revision by Lhinds)
 
(28 intermediate revisions by 5 users not shown)
Line 3: Line 3:
  
 
=== Summary ===
 
=== Summary ===
−
There is currently no limitation on the number of VNC sessions that can be established for a single user's VNC token. This enables one to cause a Denial of Service (DoS) style attack by establishing many VNC sessions against a single instance through a noVNC proxy. This can cause timeouts for other users who are trying to access the same instance through VNC.
+
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 & Havana
+
Horizon, Nova ,noVNC proxy, SPICE console, Grizzly, Havana
  
 
=== Discussion ===
 
=== Discussion ===
−
Once a user gets a token to access an instance's VNC console, there is no restriction on the frequency that the user can attempt to connect to the instance's VNC console using that token. There is also no restriction on the number of simultaneous VNC sessions that the user can establish against the instance using a single token. If many connection requests are made, any subsequent connection requests made by other users may time out. This could also impact other user's currently established VNC sessions to the instance. The overall responsiveness of other Nova services running on the noVNC host.
+
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 the lack of any VNC connection limiting, a single user could cause the noVNC proxy endpoint to be non-responsive or unreachable. This results in a DoS attack. It should be noted that there is no amplification effect.
+
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 ===
 
=== Recommended Actions ===
−
For current stable releases (Grizzly, Havana), 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].
+
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
 +
 
 +
Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections.
  
 
=== 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/nova/+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

Retrieved from "https://wiki.openstack.org/w/index.php?title=OSSN/OSSN-0008&oldid=175700"