| 2015-02-11 20:01:34 |
Paul McMillan |
bug |
|
|
added bug |
| 2015-02-11 20:03:20 |
Paul McMillan |
bug |
|
|
added subscriber Jason Hullinger |
| 2015-02-11 20:04:33 |
Paul McMillan |
bug |
|
|
added subscriber Jeremy Stanley |
| 2015-02-11 20:04:51 |
Paul McMillan |
bug |
|
|
added subscriber Dave McCowan |
| 2015-02-11 20:05:13 |
Paul McMillan |
bug |
|
|
added subscriber Tristan Cacqueray |
| 2015-02-11 20:18:50 |
Paul McMillan |
description |
This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459, where it was decided that the issues raised there were best practice hardening, but not practically exploitable.
The noVNC websocket token cookie is not set as secure-only. This is practically exploitable by an attacker who can read user traffic.
The setup is as follows:
Nova and horizon configured to serve from https. Nova is patched to resolve #1409142.
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 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 logs the request including the cookies, and responds with a blank page.
7) The attacker now has access to the auth token used to open the VNC socket (since the most recent one is sent in a cookie), and can stay connected to that socket indefinitely in any browser.
A clever attacker will cycle the iframe contents repeatedly, and steal every VNC socket a user opens as the token cookies change, rather than just the most recent one. As long as the attacker stays connected to the socket, the connection stays open indefinitely.
Fixing this is going to involve letting noVNC know when it is supposed to be behind TLS, and modifying cookie setting behavior accordingly. Django's documentation on this is a good starting place for a fairly standard approach to telling an application it is receiving HTTPS traffic:
https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header
-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. An attacker who can only read user traffic (without the ability to block or modify it) can usually become a full mitm by spoofing DNS responses.
[2] the attacker can actually do this step at any point in the process, even before step 1. |
This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459, where it was decided that the issues raised there were best practice hardening, but not practically exploitable.
The noVNC websocket token cookie is not set as secure-only. This is practically exploitable by an attacker who can read user traffic.
The setup is as follows:
Nova and horizon configured to serve from https. Nova is patched to resolve #1409142.
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 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 logs the request including the cookies, and responds with a blank page.
7) The attacker now has access to the auth token used to open the VNC socket (since the most recent one is sent in a cookie), and can stay connected to that socket indefinitely in any browser.
A clever attacker will cycle the iframe contents repeatedly, and steal every VNC socket a user opens as the token cookies change, rather than just the most recent one. As long as the attacker stays connected to the socket, the connection stays open indefinitely.
Note that the above attack does not involve the user clicking through any TLS warnings, and does not involve them actively clicking phishing links or anything similar.
Fixing this is going to involve letting noVNC know when it is supposed to be behind TLS, and modifying cookie setting behavior accordingly. Django's documentation on this is a good starting place for a fairly standard approach to telling an application it is receiving HTTPS traffic:
https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header
-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. An attacker who can only read user traffic (without the ability to block or modify it) can usually become a full mitm by spoofing DNS responses.
[2] the attacker can actually do this step at any point in the process, even before step 1. |
|
| 2015-02-11 20:44:54 |
Jeremy Stanley |
bug |
|
|
added subscriber Nova Core security contacts |
| 2015-02-11 20:45:04 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2015-02-11 20:45:14 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2015-02-11 20:45:58 |
Jeremy Stanley |
description |
This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459, where it was decided that the issues raised there were best practice hardening, but not practically exploitable.
The noVNC websocket token cookie is not set as secure-only. This is practically exploitable by an attacker who can read user traffic.
The setup is as follows:
Nova and horizon configured to serve from https. Nova is patched to resolve #1409142.
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 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 logs the request including the cookies, and responds with a blank page.
7) The attacker now has access to the auth token used to open the VNC socket (since the most recent one is sent in a cookie), and can stay connected to that socket indefinitely in any browser.
A clever attacker will cycle the iframe contents repeatedly, and steal every VNC socket a user opens as the token cookies change, rather than just the most recent one. As long as the attacker stays connected to the socket, the connection stays open indefinitely.
Note that the above attack does not involve the user clicking through any TLS warnings, and does not involve them actively clicking phishing links or anything similar.
Fixing this is going to involve letting noVNC know when it is supposed to be behind TLS, and modifying cookie setting behavior accordingly. Django's documentation on this is a good starting place for a fairly standard approach to telling an application it is receiving HTTPS traffic:
https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header
-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. An attacker who can only read user traffic (without the ability to block or modify it) can usually become a full mitm by spoofing DNS responses.
[2] the attacker can actually do this step at any point in the process, even before step 1. |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments.
This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459, where it was decided that the issues raised there were best practice hardening, but not practically exploitable.
The noVNC websocket token cookie is not set as secure-only. This is practically exploitable by an attacker who can read user traffic.
The setup is as follows:
Nova and horizon configured to serve from https. Nova is patched to resolve #1409142.
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 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 logs the request including the cookies, and responds with a blank page.
7) The attacker now has access to the auth token used to open the VNC socket (since the most recent one is sent in a cookie), and can stay connected to that socket indefinitely in any browser.
A clever attacker will cycle the iframe contents repeatedly, and steal every VNC socket a user opens as the token cookies change, rather than just the most recent one. As long as the attacker stays connected to the socket, the connection stays open indefinitely.
Note that the above attack does not involve the user clicking through any TLS warnings, and does not involve them actively clicking phishing links or anything similar.
Fixing this is going to involve letting noVNC know when it is supposed to be behind TLS, and modifying cookie setting behavior accordingly. Django's documentation on this is a good starting place for a fairly standard approach to telling an application it is receiving HTTPS traffic:
https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header
-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. An attacker who can only read user traffic (without the ability to block or modify it) can usually become a full mitm by spoofing DNS responses.
[2] the attacker can actually do this step at any point in the process, even before step 1. |
|
| 2015-02-17 18:06:08 |
Jeremy Stanley |
bug |
|
|
added subscriber OSSG CoreSec |
| 2015-02-17 18:06:23 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
| 2015-02-17 18:09:04 |
Jeremy Stanley |
description |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments.
This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459, where it was decided that the issues raised there were best practice hardening, but not practically exploitable.
The noVNC websocket token cookie is not set as secure-only. This is practically exploitable by an attacker who can read user traffic.
The setup is as follows:
Nova and horizon configured to serve from https. Nova is patched to resolve #1409142.
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 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 logs the request including the cookies, and responds with a blank page.
7) The attacker now has access to the auth token used to open the VNC socket (since the most recent one is sent in a cookie), and can stay connected to that socket indefinitely in any browser.
A clever attacker will cycle the iframe contents repeatedly, and steal every VNC socket a user opens as the token cookies change, rather than just the most recent one. As long as the attacker stays connected to the socket, the connection stays open indefinitely.
Note that the above attack does not involve the user clicking through any TLS warnings, and does not involve them actively clicking phishing links or anything similar.
Fixing this is going to involve letting noVNC know when it is supposed to be behind TLS, and modifying cookie setting behavior accordingly. Django's documentation on this is a good starting place for a fairly standard approach to telling an application it is receiving HTTPS traffic:
https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header
-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. An attacker who can only read user traffic (without the ability to block or modify it) can usually become a full mitm by spoofing DNS responses.
[2] the attacker can actually do this step at any point in the process, even before step 1. |
This is a follow-on to https://bugs.launchpad.net/nova/+bug/1197459, where it was decided that the issues raised there were best practice hardening, but not practically exploitable.
The noVNC websocket token cookie is not set as secure-only. This is practically exploitable by an attacker who can read user traffic.
The setup is as follows:
Nova and horizon configured to serve from https. Nova is patched to resolve #1409142.
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 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 logs the request including the cookies, and responds with a blank page.
7) The attacker now has access to the auth token used to open the VNC socket (since the most recent one is sent in a cookie), and can stay connected to that socket indefinitely in any browser.
A clever attacker will cycle the iframe contents repeatedly, and steal every VNC socket a user opens as the token cookies change, rather than just the most recent one. As long as the attacker stays connected to the socket, the connection stays open indefinitely.
Note that the above attack does not involve the user clicking through any TLS warnings, and does not involve them actively clicking phishing links or anything similar.
Fixing this is going to involve letting noVNC know when it is supposed to be behind TLS, and modifying cookie setting behavior accordingly. Django's documentation on this is a good starting place for a fairly standard approach to telling an application it is receiving HTTPS traffic:
https://docs.djangoproject.com/en/1.7/ref/settings/#secure-proxy-ssl-header
-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. An attacker who can only read user traffic (without the ability to block or modify it) can usually become a full mitm by spoofing DNS responses.
[2] the attacker can actually do this step at any point in the process, even before step 1. |
|
| 2015-02-17 18:09:28 |
Jeremy Stanley |
nova: status |
New |
Invalid |
|
| 2015-02-18 14:56:58 |
Tristan Cacqueray |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778618 |
|
| 2015-02-18 14:56:58 |
Tristan Cacqueray |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1193451 |
|
| 2015-03-02 19:42:14 |
Paul McMillan |
bug |
|
|
added subscriber Thomas Goirand |
| 2015-03-02 21:27:16 |
Nathan Kinder |
information type |
Private Security |
Public Security |
|
| 2015-03-02 21:27:43 |
Nathan Kinder |
bug task added |
|
ossn |
|
| 2015-03-02 21:28:31 |
Nathan Kinder |
ossn: status |
New |
Fix Released |
|
| 2015-03-02 21:28:31 |
Nathan Kinder |
ossn: assignee |
|
Paul McMillan (paul-mcmillan) |
|
