Jump to: navigation, search

Difference between revisions of "OSSN/OSSN-0008"

(→‎Discussion)
(→‎Recommended Actions)
Line 16: Line 16:
 
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.  
 
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.  
  
−
For example, if you are using proxy such as [http://www.openrepose.org/ '''Repose'''], one can enable rate limiting feature by following these [https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter steps].  
+
For example, if you are using a proxy such as [http://www.openrepose.org/ '''Repose'''], one can enable rate limiting feature by following these [https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter steps].  
−
 
+
Additional information on rate limiting is available in the OpenStack Security Guide at  [http://docs.openstack.org/security-guide/content/ch032_networking-best-practices.html%20 rate-limiting].
−
One 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 ===

Revision as of 01:04, 8 March 2014

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

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 attempting to connect to the same instance and general service response degradation on the noVNC host.

Affected Services / Software

Horizon (VNC Console through browser), Nova (noVNC proxy), Grizzly & Havana

Discussion

Currently with a single user token, no restrictions are enforced on the number of noVNC or SPICE console sessions that may be established to the user's virtual machine instance (going forward referred to as instance). Nor is there any restriction on the frequency of access to same. While an user can only access their own virtual machines, by creating an excessive number of simultaneous console sessions, resources can be exhausted on the console host, resulting in subsequent connection requests to instances on the same host getting timed-out. Not only will this prevent access to the user's instance, but other legitimate users will also be deprived access to their instances. Further, responsiveness of other Nova services running on the host also degrade.

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

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.

For example, if you are using a proxy such as Repose, one can enable rate limiting feature by following these steps. Additional information on rate limiting is available in the OpenStack Security Guide at rate-limiting.

Contacts / References

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