Comment 31 for bug 1409142

@Tristan: Happy to describe in more detail, these things are extremely non-intuitive if you haven't spent a while thinking about them.

Our scenario involves a setup as follows:

Nova and horizon configured to serve from https. Nova is patched with the current proposed patch.

User is accessing the cloud through a man in the middle who controls all traffic to and from the user. [1]

user -> attacker -> cloud(https)

Here's what happens:
1) User logs into cloud securely via https://yourcloud.com/
2) User securely accesses a server via websocket VNC and logs in. User (optionally) closes this window.
3) User opens a new browser tab to an insecure site (it really can be any insecure site at all)
4) On receiving the request for the insecure site, the attacker fetches it from the source, and rewrites it to include an invisible attack iframe before serving it to the user. [2]
5) The attack iframe directs the user's browser to open http://yourcloud.com:6080 inside the hidden iframe (even if you don't serve that site insecurely)
6) When the user's browser requests http://yourcloud.com:6080, the attacker intercepts this request.
7) Rather than serving the expected content, the attacker serves javascript which instructs the user's browser to re-connect to the secure websocket that was previously used for VNC.
8) When the user's browser sends this request to your secure websocket, it sends the cookies associated with the secure domain, even though the javascript which triggered this request (and controls the resulting websocket) did not come from a secure domain. The attacker can't see these cookies, but the user's browser does send them.
9) The secure server inspects the origin header. Since the origin for this websocket request is http://yourcloud:6080, the current patch allows the request (since the origin domain and port match the HOST header). Then the server checks the cookies (which are correct, since they are the users legit cookies from the earlier session) and the server allows the request.
10) Now the attacker controls a websocket which has been opened with the user's credentials. If the user left the VNC session logged in (very common when you're fixing something like broken networking, since closing the VNC terminal doesn't log the user out of the terminal), the attacker has full control over the VM and will proceed to install a permanent backdoor as quickly as possible.

Without the current patch, the attacker doesn't have to bother with the MITM, and can just open the websocket from any webpage they control. It's counter intuitive, but browsers don't prevent this kind of connection and even when the socket is opened from a foreign page, it comes with the secret cookies related to the target page, granting access.

Hopefully that helps you understand how this attack works. It does require a different attack setup than the plain CSRF scenario, but it produces similar end results. I agree with you that the current patch is a major improvement, and if it's going to take a significant delay to implement a fix for this issue, we should put out the current patch and deal with this one separately.

-Paul

[1] As a practical aside, it is easy to become this mitm on most local network segments, so users who connect to any network with any untrusted users are vulnerable.
[2] the attacker can actually do this step at any point in the process, even before step 1.