Jump to: navigation, search

Difference between revisions of "OSSN/OSSN-0008"

(Affected Services / Software)
(Recommended Actions)
Line 14: Line 14:
  
 
=== Recommended Actions ===
 
=== Recommended Actions ===
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].
+
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].
  
 
=== Contacts / References ===
 
=== Contacts / References ===

Revision as of 22:22, 7 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 who are trying to access the same instance through VNC.

Affected Services / Software

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

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.

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.

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

Contacts / References