Possible incomplete fix for OSSA-2015-005

[Grant Murphy]

Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete.

https://bugs.launchpad.net/nova/+bug/1409142/comments/146
https://bugs.launchpad.net/nova/+bug/1409142/comments/149

Further investigation is needed.

[Dave McCowan (dave-mccowan)]

I believe the fix is valid and complete. I know how to recreate the exploit and have seen the patch block the attempt. Let me know how I can help with the research to verify that this fix is indeed complete.

[Rui Yuan Dou (ry-dou)]

@Dave, here's my steps:
1. start a localhost web server with python
2. create a index.html file for localhost which has a <iframe> with an effective url of openstack web console page
3. open the http://localhost page in browser and the web console is shown normally

I tested with firefox38.3.0, chrome46.0, but can not find the Origin header in the get request of iframe, even I change the <iframe> to <a>, Please correct me if the steps are wrong.

[Tristan Cacqueray (tristan-cacqueray)]

@Dave, can you test the procedure above ?
Isn't there special trickery for http://localhost domain ?

[Rui Yuan Dou (ry-dou)]

Any progress on this? Or you can paste your test steps here and let me try it in our envs.

[Tony Breeds (o-tony)]

@Rui Yuan Dou (rydou) where "localhost" above is a physically different system than where you're running the websocketproxy. right?

[Rui Yuan Dou (ry-dou)]

@Tony, yes, "localhost" is a web server running in my own laptop, and openstack is running in datacenter.

[Grant Murphy (gmurphy)]

@Tony do have any further input on this? I suspect that the header isn't being sent for the localhost in the testing scenario but need to confirm. Would like to move this bug along regardless.

[Tony Breeds (o-tony)]

So I have recreated this report and Yes the Origin Header is *not* being sent.

we could enhance the code to look at the Referer header if the origin Header is absent.

@Dave where did you see the Origin header being used?

[Tony Breeds (o-tony)]

Ahh okay I understand things a little better now, the Referer check isn't something we can do in nova. We'd need to do it in websockify. I'll look at the original bug tomorrow.

[Tony Breeds (o-tony)]

So I'm not certain this represents a security issue. From comment 2:

 1. start a localhost web server with python
 2. create a index.html file for localhost which has a <iframe> with an effective url of openstack web console page
 3. open the http://localhost page in browser and the web console is shown normally

In step 2 I created the index.html to look like:
<iframe src=http://$MY_CLOUD_IP:6080/vnc_auto.html?token=$INSTANCE_TOKEN></iframe>

With this in place yes I can visit http://localhost/ and get a VNC console in my instance but this differs from the original bug in several ways
1. I can't find a way to read the token/cookie in my browser and have it populate across domains
2. The upgrade from http:// -> ws:// is all happening within the infrastructure of the (albeit small) cloud. and therefore is valid as far as the Origin: Header is concerned.

 If we can do either

1. host vnc_auto.html on localhost, and stull get access to the console ; or
2. Read the token/cookie from the browser from a domain NOT associated with $MY_CLOUD

Then I agree we have an issue.

[Dave McCowan (dave-mccowan)]

@tony, correct.

The procedure in step 2 does not recreate the original bug. By putting the link to src=http://$MY_CLOUD_IP:6080/vnc_auto.html?token=$INSTANCE_TOKEN> in the frame, the VNC code will be loaded from $MY_CLOUD and the origin header will show $MY_CLOUD.

To recreate the bug, you need to install the VNC package on your local host (or another host), and then link to http://localhost/noVNC/vnc.html. After entering $MY_CLOUD_IP in the served console page, a request will be made from the browser to $MY_CLOUD.

This request will be GET $MY_CLOUD_IP/websockify. The origin header on this request will be null, indicating the script came from the local host. The origin header will show $MY_CLOUD_IP on an acceptable request. It will show attacker.example.com on a truly malicious request.

[Grant Murphy (gmurphy)]

Given this analysis I propose we close this as notabug and remove the OSSA task. Any objections?

[Grant Murphy (gmurphy)]

Removed the OSSA task and marking invalid.