[Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption
SriramHere
sriram at sriramhere.com
Thu Dec 19 19:09:51 UTC 2013
Please review and comment on the OSSN published for this: https://wiki.openstack.org/wiki/OSSN/1227575. Content reproduced below. I wanted to know if links to some rate-limiting frameworks such as Repose would help. Not sure if we can link 3rd party tools in OSSNs.
==================================================================================
DoS style attack on noVNC server can lead to service interruption or disruption
=== 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.
=== Affected Services / Software ===
Horizon (VNC Console through browser), Nova (NoVNC proxy), Grizzly
=== Discussion ===
NoVNC Proxy is explained well here.
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.
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 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 here.
=== Contacts / References ===
This OSSN : https://bugs.launchpad.net/ossn/+bug/1227575
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1227575
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
--
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1227575
Title:
DoS style attack on noVNC server can lead to service interruption or
disruption
Status in OpenStack Compute (Nova):
In Progress
Status in OpenStack Security Notes:
New
Bug description:
There is no limiting on the number of VNC sessions that can be created for a single user's VNC token.
Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server
results in many connection timeouts. Due to these connection timeout error, other users trying to access their
VM's VNC console cannot do so.
A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors
Script: http://paste.openstack.org/show/47254/
Script output.... connections get timed out after a while
-------------------
....
..
Creating Connection
Receiving...
Received 'RFB 003.008
'
Creating Connection
Receiving...
Received 'RFB 003.008
'
Creating Connection
Receiving...
Received 'RFB 003.008
'
Creating Connection
Receiving...
Received 'RFB 003.008
'
Creating Connection
Receiving...
Received 'RFB 003.008
'
Creating Connection
Receiving...
Received 'RFB 003.008
'
Creating Connection
Receiving...
timed out
Creating Connection
Receiving...
timed out
Creating Connection
Receiving...
timed out
Creating Connection
Receiving...
timed out
Creating Connection
Receiving...
timed out
--------------------
Impact:
1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail.
This can cause serious problems to users already having a running VNC session or trying to create new sessions.
2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol
also gets affected after the connection timeout errors.
For example:
Before running the sumulate thousands of connections program:
$ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc
+-------+---------------------------------------------------------------------------------+
| Type | Url |
+-------+---------------------------------------------------------------------------------+
| novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 |
+-------+---------------------------------------------------------------------------------+
real 0m0.751s
user 0m0.376s
sys 0m0.084s
rohit at precise-dev-102:~/tools/websocket-client-0.7.0$
After running the program, the response time is quite high:
$ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc
+-------+---------------------------------------------------------------------------------+
| Type | Url |
+-------+---------------------------------------------------------------------------------+
| novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 |
+-------+---------------------------------------------------------------------------------+
real 3m9.231s
user 0m0.424s
sys 0m0.108s
Possible solutions:
1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple
connections for the same token, and return an error code to the user.
2. Make the number of sessions allowed per instance configurable, limited by some count of sessions.
However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class,
which can lead to maintenance issues.
Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token
for reconnection. This would first need contribution to the websockify project code, and then update Nova.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions
More information about the Openstack-security
mailing list