From thingee at gmail.com Mon Feb 2 08:34:26 2015 From: thingee at gmail.com (Mike Perez) Date: Mon, 02 Feb 2015 08:34:26 -0000 Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC VMAX driver References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com> Message-ID: <20150202083428.28571.63317.launchpad@gac.canonical.com> ** Changed in: cinder Milestone: kilo-2 => 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/1372635 Title: MITM vulnerability with EMC VMAX driver Status in Cinder: In Progress 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 1376915 at bugs.launchpad.net Mon Feb 2 14:03:34 2015 From: 1376915 at bugs.launchpad.net (Eoghan Glynn) Date: Mon, 02 Feb 2015 14:03:34 -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: <20150202140337.7696.86231.launchpad@wampee.canonical.com> ** Changed in: ceilometer Milestone: kilo-2 => 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/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 Mon Feb 2 16:53:48 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 02 Feb 2015 16:53:48 +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 5a392f38ca5d578c225600ec448de92dcd35c928 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 SlickNik at gmail.com Tue Feb 3 09:23:40 2015 From: SlickNik at gmail.com (Nikhil Manchanda) Date: Tue, 03 Feb 2015 09:23:40 -0000 Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup strategies References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com> Message-ID: <20150203092344.11204.10432.launchpad@soybean.canonical.com> ** Changed in: trove Importance: Undecided => Medium ** Changed in: trove Status: New => Triaged -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1343657 Title: Shell Injection in backup strategies Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Openstack Database (Trove): Triaged Bug description: Trove uses subprocess.Popen with shell=True in trove/trove/guestagent/strategies/backup/base.py line 61: def run(self): self.process = subprocess.Popen(self.command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) self.pid = self.process.pid This could be used, maliciously or not, to inject arbitrary commands into a command line string. An example of this could be triggered is in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It is creating a MySQL string with single quote. If the password, either maliciously or just happens to contain another single quote, it will escape from the command and arbitrary data will be executed instead. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently- used-arguments To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1343657/+subscriptions From anish2good at yahoo.co.in Tue Feb 3 10:43:10 2015 From: anish2good at yahoo.co.in (ANish) Date: Tue, 03 Feb 2015 10:43:10 -0000 Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup strategies References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com> Message-ID: <20150203104310.7490.11929.malone@wampee.canonical.com> The access require root privileges,the security hardening and assumption on the root to damage with the malicious script is still there. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1343657 Title: Shell Injection in backup strategies Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Openstack Database (Trove): Triaged Bug description: Trove uses subprocess.Popen with shell=True in trove/trove/guestagent/strategies/backup/base.py line 61: def run(self): self.process = subprocess.Popen(self.command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) self.pid = self.process.pid This could be used, maliciously or not, to inject arbitrary commands into a command line string. An example of this could be triggered is in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It is creating a MySQL string with single quote. If the password, either maliciously or just happens to contain another single quote, it will escape from the command and arbitrary data will be executed instead. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently- used-arguments To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1343657/+subscriptions From gerrit2 at review.openstack.org Tue Feb 3 14:09:10 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Feb 2015 14:09:10 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idbe37922c5f944e3d567ce16913ce5d87af41fef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141485 Log: commit 5cff9287ecfc84adc95d148413e973d6d6ffa42d Author: Daniel Genin Date: Tue Jan 20 13:32:24 2015 -0500 libvirt: Disconnect dm-crypt on instance suspend/stop Strengthens protection provided by ephemeral storage encryption feature by disconnecting the dm-crypt device, which provides access to unencrypted disk, when an encrypted instance is suspended or stopped. Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From gerrit2 at review.openstack.org Wed Feb 4 18:13:45 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 04 Feb 2015 18:13:45 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ie03325a902ec882d340f1f1b017da546edb6815d Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/150580 Log: commit 7235d0dd2d5968222fe6b1fc70589a3d5727b19d Author: Matthew Gilliard Date: Tue Jan 27 20:45:32 2015 +0000 Adds ssl_overrides to glance client creation If3f88d8db4a726219573d0f1b65908408e3aa6a9 added a util method so that http clients created by nova can have per-client overrides for ssl options. This patch uses that util method in the glance client. DocImpact new configuation option CONF.glance.ssl_overrides, as described SecurityImpact Change-Id: Ie03325a902ec882d340f1f1b017da546edb6815d From gerrit2 at review.openstack.org Wed Feb 4 18:47:29 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 04 Feb 2015 18:47:29 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I7222712970e09e2807dc572d1bb922f2b3c4491d Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/143443 Log: commit 14c4a07843ca571aff12d69a6c1bf8113f8bcf21 Author: Matthew Gilliard Date: Mon Dec 22 13:56:39 2014 +0000 Adds ssl_overrides dict for keystone client configuration So that we can allow users to specify different values for ca_cert, cert and key for each https client which nova creates, we add an 'ssl_overrides' DictOpt for each one. This patch does so for the keystone client created in the ec2 api. DocImpact new config option CONF.ec2_ssl_overrides SecurityImpact Change-Id: I7222712970e09e2807dc572d1bb922f2b3c4491d From gerrit2 at review.openstack.org Wed Feb 4 20:34:00 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 04 Feb 2015 20:34:00 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idbe37922c5f944e3d567ce16913ce5d87af41fef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141485 Log: commit 3c3e8679003a7bb2d4f1dd68a0dee6238adae418 Author: Daniel Genin Date: Tue Jan 20 13:32:24 2015 -0500 libvirt: Disconnect dm-crypt on instance suspend/stop Strengthens protection provided by ephemeral storage encryption feature by disconnecting the dm-crypt device, which provides access to unencrypted disk, when an encrypted instance is suspended or stopped. Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From gerrit2 at review.openstack.org Wed Feb 4 21:17:47 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 04 Feb 2015 21:17:47 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ief37d1e29487bb03e612320f5cc06910cfd1c23a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/148574 Log: commit 86d3eb369c90e9f20e65af84eec5522086cbc625 Author: Alexander Tivelkov Date: Tue Jan 20 17:25:07 2015 +0300 Fix for CooperativeReader to properly process read length CooperativeReader, being an eventlet-friendly wrapper around the generator- based reader of image data, actually transforms chunk-by-chunk iteration into the readable stream. It is used when the image is being copied from the remote source: some generator-based image data representing the remote source acts as its underlying object, and the instance of CooperativeReader is passed as a data stream to the backend client which uses it to read the data. Before this patch, the CooperativeReader was ignoring the "length" parameter of the read method, always returning the whole chunk returned by the underlying generator (in case of HTTP source the size of this chunk is 16 M). This was causing problems for the clients attempting to read data from it, and - under some circumstances - the loss of data. For chunked storage of files in Swift a special class (ChunkReader, declared in the swift store driver) is used to reduce the requested read length so no extra data is read and transferred. However, this was not working as the CooperativeReader (which was the underlying stream for the ChunkReader) was ignoring the requested size. This was causing the data to be lost when reading behind the boundaries of the Chunks. This patchset introduces a buffer in the CooperativeReader to store the most recently fetched iterator chunk. The reads are independent from requests to iterator, so the CooperativeReader is able to return the exact requested amount of bytes and no data is lost due to extra-reads. SecurityImpact Change-Id: Ief37d1e29487bb03e612320f5cc06910cfd1c23a Closes-bug: #1412802 From 1187107 at bugs.launchpad.net Wed Feb 4 21:48:51 2015 From: 1187107 at bugs.launchpad.net (Kyle Mestery) Date: Wed, 04 Feb 2015 21:48:51 -0000 Subject: [Openstack-security] [Bug 1187107] Re: quantum-ns-metadata-proxy runs as root References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20150204214854.32422.62938.launchpad@wampee.canonical.com> ** Changed in: neutron Milestone: kilo-2 => 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/1187107 Title: quantum-ns-metadata-proxy runs as root Status in OpenStack Neutron (virtual network service): In Progress 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 ian.cordasco at RACKSPACE.COM Wed Feb 4 22:23:36 2015 From: ian.cordasco at RACKSPACE.COM (Ian Cordasco) Date: Wed, 4 Feb 2015 22:23:36 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ief37d1e29487bb03e612320f5cc06910cfd1c23a In-Reply-To: Message-ID: Hey all, The glance team was hoping to get some feedback from some OSSG members about this review. Specifically, there seems to be a concern about causing an Out of Memory error on the host (https://review.openstack.org/#/c/148574/4/glance/common/utils.py). We’d really appreciate your feedback. Cheers, Ian On 2/4/15, 15:17, "gerrit2 at review.openstack.org" wrote: > >Hi, I'd like you to take a look at this patch for potential >SecurityImpact. >https://review.openstack.org/148574 > >Log: >commit 86d3eb369c90e9f20e65af84eec5522086cbc625 >Author: Alexander Tivelkov >Date: Tue Jan 20 17:25:07 2015 +0300 > > Fix for CooperativeReader to properly process read length > > CooperativeReader, being an eventlet-friendly wrapper around the >generator- > based reader of image data, actually transforms chunk-by-chunk >iteration into > the readable stream. It is used when the image is being copied from >the remote > source: some generator-based image data representing the remote >source acts as > its underlying object, and the instance of CooperativeReader is >passed as a > data stream to the backend client which uses it to read the data. > > Before this patch, the CooperativeReader was ignoring the "length" >parameter of > the read method, always returning the whole chunk returned by the >underlying > generator (in case of HTTP source the size of this chunk is 16 M). >This was > causing problems for the clients attempting to read data from it, and >- under > some circumstances - the loss of data. > > For chunked storage of files in Swift a special class (ChunkReader, >declared in > the swift store driver) is used to reduce the requested read length >so no extra > data is read and transferred. However, this was not working as the > CooperativeReader (which was the underlying stream for the >ChunkReader) was > ignoring the requested size. This was causing the data to be lost >when reading > behind the boundaries of the Chunks. > > This patchset introduces a buffer in the CooperativeReader to store >the most > recently fetched iterator chunk. The reads are independent from >requests to > iterator, so the CooperativeReader is able to return the exact >requested amount > of bytes and no data is lost due to extra-reads. > > SecurityImpact > > Change-Id: Ief37d1e29487bb03e612320f5cc06910cfd1c23a > Closes-bug: #1412802 > > >_______________________________________________ >Openstack-security mailing list >Openstack-security at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From gerrit2 at review.openstack.org Thu Feb 5 11:24:45 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 05 Feb 2015 11:24:45 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ief37d1e29487bb03e612320f5cc06910cfd1c23a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/148574 Log: commit 270ec44a890f4bd2917310e2fcab9ad2bb9413b7 Author: Alexander Tivelkov Date: Tue Jan 20 17:25:07 2015 +0300 Fix for CooperativeReader to process read length CooperativeReader, being an eventlet-friendly wrapper around the generator- based reader of image data, actually transforms chunk-by-chunk iteration into the readable stream. It is used when the image is being copied from the remote source: some generator-based image data representing the remote source acts as its underlying object, and the instance of CooperativeReader is passed as a data stream to the backend client which uses it to read the data. Before this patch, the CooperativeReader was ignoring the "length" parameter of the read method, always returning the whole chunk returned by the underlying generator (in case of HTTP source the size of this chunk is 16 M). This was causing problems for the clients attempting to read data from it, and - under some circumstances - the loss of data. For chunked storage of files in Swift a special class (ChunkReader, declared in the swift store driver) is used to reduce the requested read length so no extra data is read and transferred. However, this was not working as the CooperativeReader (which was the underlying stream for the ChunkReader) was ignoring the requested size. This was causing the data to be lost when reading behind the boundaries of the Chunks. This patchset introduces a buffer in the CooperativeReader to store the most recently fetched iterator chunk. The reads are independent from requests to iterator, so the CooperativeReader is able to return the exact requested amount of bytes and no data is lost due to extra-reads. SecurityImpact Change-Id: Ief37d1e29487bb03e612320f5cc06910cfd1c23a Closes-bug: #1412802 From gerrit2 at review.openstack.org Thu Feb 5 14:29:06 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 05 Feb 2015 14:29:06 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idbe37922c5f944e3d567ce16913ce5d87af41fef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141485 Log: commit e0ff7d7c4fa1d77510eff73da3ae9cf5053fc44f Author: Daniel Genin Date: Thu Feb 5 09:28:16 2015 -0500 lilibvirt: Disconnect dm-crypt on instance suspend/stop Strengthens protection provided by ephemeral storage encryption feature by disconnecting the dm-crypt device, which provides access to unencrypted disk, when an encrypted instance is suspended or stopped. Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From thierry.carrez+lp at gmail.com Thu Feb 5 14:53:06 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 05 Feb 2015 14:53: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: <20150205145312.12244.44867.launchpad@gac.canonical.com> ** Changed in: neutron Status: Fix Committed => Fix Released ** Changed in: neutron Milestone: None => kilo-2 -- 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: New 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 Feb 5 15:55:52 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 05 Feb 2015 15:55:52 -0000 Subject: [Openstack-security] [Bug 1400872] Re: Show password feature should be configurable References: <20141209205525.24719.53334.malonedeb@wampee.canonical.com> Message-ID: <20150205155554.20545.44991.launchpad@chaenomeles.canonical.com> ** Changed in: horizon Status: Fix Committed => Fix Released ** Changed in: horizon Milestone: None => kilo-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1400872 Title: Show password feature should be configurable Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisories: Won't Fix Bug description: Horizon allows the password field to be displayed in plain text. This introduces a potential security risk. Imagine a user leaving their desktop unlock, if the user saved their password on the browser, a malicious user could go into the Login page and display the Openstack password. The show password feature should be made configurable for operators who wants a more secure deployment of Horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1400872/+subscriptions From chuck.short at canonical.com Thu Feb 5 17:36:19 2015 From: chuck.short at canonical.com (Chuck Short) Date: Thu, 05 Feb 2015 17:36:19 -0000 Subject: [Openstack-security] [Bug 1394988] Re: Hadoop with auto security group not working References: <20141121132920.28673.42565.malonedeb@wampee.canonical.com> Message-ID: <20150205173621.32206.26139.launchpad@wampee.canonical.com> ** Changed in: sahara/juno Milestone: 2014.2.2 => 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/1394988 Title: Hadoop with auto security group not working Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: In Progress 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 chuck.short at canonical.com Thu Feb 5 17:36:47 2015 From: chuck.short at canonical.com (Chuck Short) Date: Thu, 05 Feb 2015 17:36:47 -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: <20150205173648.32233.45103.launchpad@wampee.canonical.com> ** Changed in: sahara/juno Milestone: 2014.2.2 => 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/1391520 Title: Create CDH cluster with auto security group failed Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: In Progress 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 thierry.carrez+lp at gmail.com Thu Feb 5 20:11:51 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 05 Feb 2015 20:11:51 -0000 Subject: [Openstack-security] [Bug 1406191] Re: node-show discloses credentials as plain text in driver_info References: <20141229065345.16652.7904.malonedeb@soybean.canonical.com> Message-ID: <20150205201154.6605.78508.launchpad@soybean.canonical.com> ** Changed in: ironic 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/1406191 Title: node-show discloses credentials as plain text in driver_info Status in OpenStack Bare Metal Provisioning Service (Ironic): Fix Released Bug description: [root at rhel7-vm ~]# ironic node-show b0860248-bf1d-4803-bdc3-5bb42852841c +------------------------+--------------------------------------------------------------------------+ | Property | Value | +------------------------+--------------------------------------------------------------------------+ | instance_uuid | bdaf5cc9-de8f-407e-890a-d4b6c1e3e602 | | target_power_state | None | | properties | {u'memory_mb': u'1024', u'cpu_arch': u'x86_64', u'local_gb': u'10', | | | u'cpus': u'1'} | | maintenance | False | | driver_info | {u'pxe_deploy_ramdisk': u'503e88d9-637c-4369-b8e0-2b2531c0eeb2', | | | u'ipmi_terminal_port': u'1234', u'ipmi_username': u'username', | | | u'ipmi_address': u'9.9.9.9', u'ipmi_password': u'password', | | | u'pxe_deploy_kernel': u'1e676e34-1294-4a17-afba-cd5c358cd314'} | | extra | {} | | last_error | None | | created_at | 2014-12-19T07:13:50+00:00 | | target_provision_state | deploy complete | | driver | pxe_ipmitool | | updated_at | 2014-12-29T04:52:29+00:00 | | instance_info | {u'ramdisk': u'b30a4441-b975-432d-8878-573de2aba297', u'kernel': u | | | '490b7edd-dfe9-4842-80ed-033c788b37d1', u'root_gb': u'10', | | | u'image_source': u'8d860e96-61f9-4070-8b09-4c8037c104c7', u'deploy_key': | | | u'2AX7KT8DXGU395SOA06J676YAC7AVA60', u'swap_mb': u'0'} | | chassis_uuid | | | provision_state | wait call-back | | reservation | None | | power_state | power on | | console_enabled | False | | uuid | b0860248-bf1d-4803-bdc3-5bb42852841c | +------------------------+--------------------------------------------------------------------------+ [root at rhel7-vm ~]# Log file will not show the password - 'ipmi_password': '' So can we hide the password in ironic client side? To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1406191/+subscriptions From gerrit2 at review.openstack.org Thu Feb 5 20:53:59 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 05 Feb 2015 20:53:59 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I64859ad01120782fb17308aac3abb125597c3ea2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/115484 Log: commit 20fcf321ee6be51d49dd53c046a77b343e3b05e3 Author: Solly Ross Date: Tue Aug 19 19:21:52 2014 -0400 Add VeNCrypt (TLS/x509) Security Proxy Driver This adds support for using x509/TLS security between the compute node and websocket proxy when using websockify to proxy VNC traffic. In order to use this with x509, an operator would have to set up client keys and certificates, as well as CA certificates, and configure libvirt to pass the appropriate options to QEmu (this is configured globally for libvirt, not by Nova). This is process is documented on the libvirt website. Then, the operator would enable this driver and set the following options in /etc/nova/nova.conf: [console_proxy_tls] client_key = /path/to/client/keyfile client_cert = /path/to/client/cert.pem ca_certs = /path/to/ca/cert.pem SecurityImpact DocImpact Implements bp: websocket-proxy-to-host-security Change-Id: I64859ad01120782fb17308aac3abb125597c3ea2 From thierry.carrez+lp at gmail.com Thu Feb 5 21:57:09 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 05 Feb 2015 21:57:09 -0000 Subject: [Openstack-security] [Bug 1375857] Re: It's not possibile to pass the cacert to the swift store References: <20140930152151.17678.6371.malonedeb@chaenomeles.canonical.com> Message-ID: <20150205215712.12368.91676.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/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Glance backend store-drivers library (glance_store): Fix Committed Bug description: The swift store device defined in the glance store doesn't allow to pass the ca cert file. When the driver creates a connection via the swift client it is not possible to pass that value. That means that if we have swift running on TLS in some cases we have to set the insecure option equals to True as the client can't correctly complete the handshake as it fails on the verification of the cert. The fix I'd like to propose is to add a new parameter to define the ca cert file and pass this value when we create the connection via the swift client. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1375857/+subscriptions From 1348416 at bugs.launchpad.net Thu Feb 5 23:25:30 2015 From: 1348416 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Feb 2015 23:25:30 -0000 Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com> Message-ID: <20150205232530.12544.2374.malone@gac.canonical.com> Reviewed: https://review.openstack.org/149111 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=91f13964838fcd1937b6789f5e72bfd6fee9d440 Submitter: Jenkins Branch: master commit 91f13964838fcd1937b6789f5e72bfd6fee9d440 Author: Steve Lewis Date: Wed Jan 21 17:32:41 2015 -0800 Eliminate shell param from subprocesses in tests Of the calls to execute a subprocess performed in tests, none of them require a shell. Test utility method was modified to not use a shell, eliminating a discouraged practice. Change-Id: If2571ee8f4ea2fdf6e14416d5abe5de275d3a1c4 Closes-Bug: 1348416 ** 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/1348416 Title: Popen with shell=True Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed 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 Fri Feb 6 09:35:14 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Feb 2015 09:35:14 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ief37d1e29487bb03e612320f5cc06910cfd1c23a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/153502 Log: commit 4a414a0fa556e664358c53745f73408224057314 Author: Alexander Tivelkov Date: Tue Jan 20 18:25:07 2015 +0300 Fix for CooperativeReader to process read length CooperativeReader, being an eventlet-friendly wrapper around the generator- based reader of image data, actually transforms chunk-by-chunk iteration into the readable stream. It is used when the image is being copied from the remote source: some generator-based image data representing the remote source acts as its underlying object, and the instance of CooperativeReader is passed as a data stream to the backend client which uses it to read the data. Before this patch, the CooperativeReader was ignoring the "length" parameter of the read method, always returning the whole chunk returned by the underlying generator (in case of HTTP source the size of this chunk is 16 M). This was causing problems for the clients attempting to read data from it, and - under some circumstances - the loss of data. For chunked storage of files in Swift a special class (ChunkReader, declared in the swift store driver) is used to reduce the requested read length so no extra data is read and transferred. However, this was not working as the CooperativeReader (which was the underlying stream for the ChunkReader) was ignoring the requested size. This was causing the data to be lost when reading behind the boundaries of the Chunks. This patchset introduces a buffer in the CooperativeReader to store the most recently fetched iterator chunk. The reads are independent from requests to iterator, so the CooperativeReader is able to return the exact requested amount of bytes and no data is lost due to extra-reads. SecurityImpact Change-Id: Ief37d1e29487bb03e612320f5cc06910cfd1c23a Closes-bug: #1412802 (cherry picked from commit 270ec44) From gerrit2 at review.openstack.org Fri Feb 6 09:45:01 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Feb 2015 09:45:01 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ief37d1e29487bb03e612320f5cc06910cfd1c23a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/153502 Log: commit 1af7adc617a00ede5eab9bafc7260c626ec1d21d Author: Alexander Tivelkov Date: Tue Jan 20 18:25:07 2015 +0300 Fix for CooperativeReader to process read length CooperativeReader, being an eventlet-friendly wrapper around the generator- based reader of image data, actually transforms chunk-by-chunk iteration into the readable stream. It is used when the image is being copied from the remote source: some generator-based image data representing the remote source acts as its underlying object, and the instance of CooperativeReader is passed as a data stream to the backend client which uses it to read the data. Before this patch, the CooperativeReader was ignoring the "length" parameter of the read method, always returning the whole chunk returned by the underlying generator (in case of HTTP source the size of this chunk is 16 M). This was causing problems for the clients attempting to read data from it, and - under some circumstances - the loss of data. For chunked storage of files in Swift a special class (ChunkReader, declared in the swift store driver) is used to reduce the requested read length so no extra data is read and transferred. However, this was not working as the CooperativeReader (which was the underlying stream for the ChunkReader) was ignoring the requested size. This was causing the data to be lost when reading behind the boundaries of the Chunks. This patchset introduces a buffer in the CooperativeReader to store the most recently fetched iterator chunk. The reads are independent from requests to iterator, so the CooperativeReader is able to return the exact requested amount of bytes and no data is lost due to extra-reads. SecurityImpact Change-Id: Ief37d1e29487bb03e612320f5cc06910cfd1c23a Closes-bug: #1412802 (cherry picked from commit 270ec44a890f4bd2917310e2fcab9ad2bb9413b7) From gerrit2 at review.openstack.org Fri Feb 6 09:50:44 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 06 Feb 2015 09:50:44 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ief37d1e29487bb03e612320f5cc06910cfd1c23a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/153508 Log: commit de45f294dccaeb8e2d933ab17f9f001600da0b5e Author: Alexander Tivelkov Date: Tue Jan 20 18:25:07 2015 +0300 Fix for CooperativeReader to process read length CooperativeReader, being an eventlet-friendly wrapper around the generator- based reader of image data, actually transforms chunk-by-chunk iteration into the readable stream. It is used when the image is being copied from the remote source: some generator-based image data representing the remote source acts as its underlying object, and the instance of CooperativeReader is passed as a data stream to the backend client which uses it to read the data. Before this patch, the CooperativeReader was ignoring the "length" parameter of the read method, always returning the whole chunk returned by the underlying generator (in case of HTTP source the size of this chunk is 16 M). This was causing problems for the clients attempting to read data from it, and - under some circumstances - the loss of data. For chunked storage of files in Swift a special class (ChunkReader, declared in the swift store driver) is used to reduce the requested read length so no extra data is read and transferred. However, this was not working as the CooperativeReader (which was the underlying stream for the ChunkReader) was ignoring the requested size. This was causing the data to be lost when reading behind the boundaries of the Chunks. This patchset introduces a buffer in the CooperativeReader to store the most recently fetched iterator chunk. The reads are independent from requests to iterator, so the CooperativeReader is able to return the exact requested amount of bytes and no data is lost due to extra-reads. SecurityImpact Change-Id: Ief37d1e29487bb03e612320f5cc06910cfd1c23a Closes-bug: #1412802 (cherry picked from commit 270ec44a890f4bd2917310e2fcab9ad2bb9413b7) From kragniz at gmail.com Fri Feb 6 11:51:03 2015 From: kragniz at gmail.com (Louis Taylor) Date: Fri, 06 Feb 2015 11:51:03 -0000 Subject: [Openstack-security] [Bug 1370283] Re: python-glanceclient uses extremely insecure configurations of OpenSSL References: <20140916232429.32614.13519.malonedeb@gac.canonical.com> Message-ID: <20150206115104.7332.93227.launchpad@soybean.canonical.com> ** Changed in: python-glanceclient Status: New => In Progress ** Changed in: python-glanceclient Importance: Undecided => Medium ** Changed in: python-glanceclient Assignee: (unassigned) => Stuart McLaren (stuart-mclaren) ** Changed in: python-glanceclient Milestone: None => v0.16.0 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1370283 Title: python-glanceclient uses extremely insecure configurations of OpenSSL Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Glance: In Progress Bug description: glanceclient does not properly configure OpenSSL, which results in making TLS connections which allow extremely bad security settings. Specifically it allows SSLv2, and many insecure ciphersuites. From Ubuntu 14.04: >>> import pprint; import glanceclient.common.http; pprint.pprint(glanceclient.common.http.HTTPClient('https://', ssl_compression=False).session.get("https://www.howsmyssl.com/a/check").json()) {u'able_to_detect_n_minus_one_splitting': False, u'beast_vuln': False, u'ephemeral_keys_supported': True, u'given_cipher_suites': [u'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_AES_256_GCM_SHA384', u'TLS_RSA_WITH_AES_256_CBC_SHA256', u'TLS_RSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA', u'TLS_DHE_RSA_WITH_SEED_CBC_SHA', u'TLS_DHE_DSS_WITH_SEED_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_AES_128_GCM_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_SEED_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDHE_RSA_WITH_RC4_128_SHA', u'TLS_ECDHE_ECDSA_WITH_RC4_128_SHA', u'TLS_ECDH_RSA_WITH_RC4_128_SHA', u'TLS_ECDH_ECDSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_MD5', u'TLS_DHE_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_DSS_WITH_DES_CBC_SHA', u'TLS_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5', u'TLS_RSA_EXPORT_WITH_RC4_40_MD5', u'TLS_EMPTY_RENEGOTIATION_INFO_SCSV'], u'insecure_cipher_suites': {u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_DSS_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC4_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption']}, u'rating': u'Bad', u'session_ticket_supported': True, u'tls_compression_supported': False, u'tls_version': u'TLS 1.2', u'unknown_cipher_suite_supported': False} I *strongly* recommend just deleting all this code and using requests. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1370283/+subscriptions From gerrit2 at review.openstack.org Sat Feb 7 11:27:18 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 07 Feb 2015 11:27:18 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change Iad1682abb0f2f004f559090358a38a845908fdf4 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/153782 Log: commit a15434e9ec3ae1e958b66bdcd73a4844c1e5306f Author: Eric Harney Date: Sat Feb 7 12:19:19 2015 +0100 Revert "rtstool on Ubuntu installs in /usr/local/bin" This reverts commit c85bd876d3ae4b6e29bb040a49e43d3ba46b6039. cinder-rtstool is installed by setup.py/setup.cfg, the same way that cinder-api, cinder-volume, etc., are installed. If it is installing in /usr/local/bin/, that sounds like a packaging or deployment bug. The upstream Cinder package should not have a responsibility to cover /usr/local/bin/. (Ubuntu packages install this binary correctly in /usr/bin/ anyway per Ubuntu packaging rules, AFAICT.) SecurityImpact: rootwrap configuration Change-Id: Iad1682abb0f2f004f559090358a38a845908fdf4 From gerrit2 at review.openstack.org Sat Feb 7 11:28:01 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 07 Feb 2015 11:28:01 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change Iad1682abb0f2f004f559090358a38a845908fdf4 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/153782 Log: commit 1acd46e0ca50b5f4bcb3b2882c61ccfcf8ee9230 Author: Eric Harney Date: Sat Feb 7 12:19:19 2015 +0100 Revert "rtstool on Ubuntu installs in /usr/local/bin" This reverts commit c85bd876d3ae4b6e29bb040a49e43d3ba46b6039. cinder-rtstool is installed by setup.py/setup.cfg, the same way that cinder-api, cinder-volume, etc., are installed. If it is installing in /usr/local/bin/, that sounds like a packaging or deployment bug. The upstream Cinder package should not have a responsibility to cover /usr/local/bin/. (Ubuntu packages install this binary correctly in /usr/bin/ anyway per Ubuntu packaging rules, AFAICT.) Related-Bug: #1402076 SecurityImpact: rootwrap configuration Change-Id: Iad1682abb0f2f004f559090358a38a845908fdf4 From 1400443 at bugs.launchpad.net Sun Feb 8 04:18:08 2015 From: 1400443 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Sun, 08 Feb 2015 04:18:08 -0000 Subject: [Openstack-security] [Bug 1400443] Re: Keystone should support pre-hashed passwords References: <20141208182330.19434.7359.malonedeb@soybean.canonical.com> Message-ID: <20150208041809.26039.56644.malone@loganberry.canonical.com> [Expired for Keystone because there has been no activity for 60 days.] ** Changed in: keystone Status: Incomplete => Expired -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1400443 Title: Keystone should support pre-hashed passwords Status in OpenStack Identity (Keystone): Expired Status in OpenStack Security Advisories: Won't Fix Bug description: Passwords should be allowed to be pre-hashed upon user creation for better security. A user may want to store passwords in a script file, and it is much safer for these to be hashed beforehand so that the password is not in plaintext. This was implemented in keystone at one point https://git.openstack.org/cgit/openstack/keystone/commit/?id=e492bbc68ef41b276a0a18c6dbeda242d46b66f4 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1400443/+subscriptions From gerrit2 at review.openstack.org Mon Feb 9 07:10:14 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 09 Feb 2015 07:10:14 +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/130839 Log: commit a21880f7ced8a6bf49b01c00592cd1e9af216d4e 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 wsgi_keep_alive option (default=True). SecurityImpact Closes-Bug: #1361360 Change-Id: I93aaca24935a4f3096210233097dd6b8c5440176 From slukjanov at mirantis.com Mon Feb 9 10:54:07 2015 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Mon, 09 Feb 2015 10:54:07 -0000 Subject: [Openstack-security] [Bug 1394988] Re: Hadoop with auto security group not working References: <20141121132920.28673.42565.malonedeb@wampee.canonical.com> Message-ID: <20150209105409.12802.18849.launchpad@gac.canonical.com> ** Changed in: sahara/juno Milestone: None => 2014.2.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/1394988 Title: Hadoop with auto security group not working Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: In Progress 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 slukjanov at mirantis.com Mon Feb 9 10:51:48 2015 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Mon, 09 Feb 2015 10:51:48 -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: <20150209105150.12637.28580.launchpad@gac.canonical.com> ** Changed in: sahara/juno Milestone: None => 2014.2.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/1391520 Title: Create CDH cluster with auto security group failed Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: In Progress 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 Mon Feb 9 14:02:20 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 09 Feb 2015 14:02: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/130839 Log: commit af868c3eafc840a9625d0946a8c39851ac617ea7 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 wsgi_keep_alive option (default=True). SecurityImpact Closes-Bug: #1361360 Change-Id: I93aaca24935a4f3096210233097dd6b8c5440176 From gerrit2 at review.openstack.org Tue Feb 10 10:41:39 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Feb 2015 10:41:39 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I399b812f6d452226fd306c423de8dcea8520d2aa Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/138811 Log: 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) From gerrit2 at review.openstack.org Wed Feb 11 06:31:26 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Feb 2015 06:31:26 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ic529b1c2c1cfd914facb14941e4bb641db6a0e82 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/154761 Log: commit cefca3fadaa7cd41abe82c98094ddcd57d41254f Author: Rajesh Tailor Date: Thu Feb 5 02:57:59 2015 -0800 Delete instance files from dest host in revert-resize When revert-resize call is finished, it doesn't clear instance files from destination node for non-shared instance storage. The driver call, which is responsible for destroying destination host instance is not deleting instance files, because it finds that both source and destination host shares the same instance storage. The check_instance_shared_storage rpc-call had no host information, hence the manager call for check_instance_shared_storage was checking instance storage on destination host itself and returning True even if it is non-shared storage. Added host parameter to check_instance_shared_storage rpc-call, so that in manager call check_instance_shared_storage method get executed on source compute node and returns True/False based on shared/non-shared storage. SecurityImpact Closes-Bug: #1418855 Change-Id: Ic529b1c2c1cfd914facb14941e4bb641db6a0e82 From bknudson at us.ibm.com Wed Feb 11 16:23:12 2015 From: bknudson at us.ibm.com (Brant Knudson) Date: Wed, 11 Feb 2015 16:23:12 -0000 Subject: [Openstack-security] [Bug 1420863] [NEW] Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Public bug reported: 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 ** Affects: horizon 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/1420863 Title: Default setting should be secure Status in OpenStack Dashboard (Horizon): New 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 gerrit2 at review.openstack.org Wed Feb 11 16:40:55 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Feb 2015 16:40:55 +0000 Subject: [Openstack-security] [openstack/horizon] SecurityImpact review request change If2c3439cf23b11dd7829a4d7866d3b21409a7d69 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/154943 Log: commit 64ed56100ccbb4eeb16040b67d5417925aaabf0d Author: Brant Knudson Date: Wed Feb 11 10:38:58 2015 -0600 Set the password_autocomplete default to "off" It's safer to set the autocomplete option to "off" for passwords so that browsers get the hint to not save it. The default should be secure so that deployers need to make a conscious decision to be less-secure. This is for security hardening. SecurityImpact Change-Id: If2c3439cf23b11dd7829a4d7866d3b21409a7d69 From gerrit2 at review.openstack.org Wed Feb 11 16:41:39 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Feb 2015 16:41:39 +0000 Subject: [Openstack-security] [openstack/horizon] SecurityImpact review request change If2c3439cf23b11dd7829a4d7866d3b21409a7d69 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/154943 Log: commit 91c8f76fa8f7a5b20c03d75d855ef3ef1e5ab026 Author: Brant Knudson Date: Wed Feb 11 10:38:58 2015 -0600 Set the password_autocomplete default to "off" It's safer to set the autocomplete option to "off" for passwords so that browsers get the hint to not save it. The default should be secure so that deployers need to make a conscious decision to be less-secure. This is for security hardening. SecurityImpact Partial-Bug: #1420863 Change-Id: If2c3439cf23b11dd7829a4d7866d3b21409a7d69 From gerrit2 at review.openstack.org Wed Feb 11 16:47:07 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Feb 2015 16:47:07 +0000 Subject: [Openstack-security] [openstack/horizon] SecurityImpact review request change If2c3439cf23b11dd7829a4d7866d3b21409a7d69 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/154943 Log: commit 3c84fe305c83e3b9975ce585b405c26aed818248 Author: Brant Knudson Date: Wed Feb 11 10:38:58 2015 -0600 Set the password_autocomplete default to "off" It's safer to set the autocomplete option to "off" for passwords so that browsers get the hint to not save it. The default should be secure so that deployers need to make a conscious decision to be less-secure. This is for security hardening. SecurityImpact Closes-Bug: #1420863 Change-Id: If2c3439cf23b11dd7829a4d7866d3b21409a7d69 From gerrit2 at review.openstack.org Wed Feb 11 16:53:04 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Feb 2015 16:53:04 +0000 Subject: [Openstack-security] [openstack/horizon] SecurityImpact review request change If2c3439cf23b11dd7829a4d7866d3b21409a7d69 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/154943 Log: commit 7bd87acdd07f0718e32221525ff54a188f8cecb8 Author: Brant Knudson Date: Wed Feb 11 10:38:58 2015 -0600 Set the password_autocomplete default to "off" It's safer to set the autocomplete option to "off" for passwords so that browsers get the hint to not save it. The default should be secure so that deployers need to make a conscious decision to be less-secure. This is for security hardening. SecurityImpact Closes-Bug: 1420863 Change-Id: If2c3439cf23b11dd7829a4d7866d3b21409a7d69 From drfish at us.ibm.com Wed Feb 11 17:30:07 2015 From: drfish at us.ibm.com (Doug Fish) Date: Wed, 11 Feb 2015 17:30:07 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150211173007.25104.27343.launchpad@gac.canonical.com> ** Also affects: openstack-chef 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/1420863 Title: Default setting should be secure Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack + Chef: New 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 icordasc+launchpad at coglib.com Wed Feb 11 21:58:16 2015 From: icordasc+launchpad at coglib.com (Ian Cordasco) Date: Wed, 11 Feb 2015 21:58:16 -0000 Subject: [Openstack-security] [Bug 1420984] Re: [v1] User can change image owner to any other References: <20150211214029.5931.12162.malonedeb@soybean.canonical.com> Message-ID: <20150211215816.5899.12825.launchpad@soybean.canonical.com> ** 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/1420984 Title: [v1] User can change image owner to any other Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Only admin can change image owner, but everybody. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1420984/+subscriptions From 1391504 at bugs.launchpad.net Thu Feb 12 03:10:59 2015 From: 1391504 at bugs.launchpad.net (John Griffith) Date: Thu, 12 Feb 2015 03:10:59 -0000 Subject: [Openstack-security] [Bug 1391504] Re: Sample policies for Openstack References: <20141111130915.17341.22090.malonedeb@chaenomeles.canonical.com> Message-ID: <20150212031104.11958.79207.launchpad@wampee.canonical.com> ** Changed in: cinder Importance: Undecided => Wishlist -- 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): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): In Progress 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 1375857 at bugs.launchpad.net Thu Feb 12 13:54:44 2015 From: 1375857 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 12 Feb 2015 13:54:44 -0000 Subject: [Openstack-security] [Bug 1375857] Fix merged to glance (master) References: <20140930152151.17678.6371.malonedeb@chaenomeles.canonical.com> Message-ID: <20150212135444.24610.6815.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/145095 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=4a78e854266e83f0a074e2447ce2837ee37393c5 Submitter: Jenkins Branch: master commit 4a78e854266e83f0a074e2447ce2837ee37393c5 Author: Ian Cordasco Date: Mon Jan 5 17:54:03 2015 -0600 Add swift_store_cacert to config files and docs Change I5b356170ec82d033204e22f79c862201400a0a31 introduced a new swift_store configuration option. Prior to accepting that, it was determined that we needed to add it to the relevant configuration files and document the option. DocImpact Closes-bug: 1375857 Change-Id: I4cbfae3c1ac84d6c85875d34a58dd2a87ae85d6f -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Glance backend store-drivers library (glance_store): Fix Committed Bug description: The swift store device defined in the glance store doesn't allow to pass the ca cert file. When the driver creates a connection via the swift client it is not possible to pass that value. That means that if we have swift running on TLS in some cases we have to set the insecure option equals to True as the client can't correctly complete the handshake as it fails on the verification of the cert. The fix I'd like to propose is to add a new parameter to define the ca cert file and pass this value when we create the connection via the swift client. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1375857/+subscriptions From davanum at gmail.com Thu Feb 12 16:18:15 2015 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Thu, 12 Feb 2015 16:18:15 -0000 Subject: [Openstack-security] [Bug 1391504] Re: Sample policies for Openstack References: <20141111130915.17341.22090.malonedeb@chaenomeles.canonical.com> Message-ID: <20150212161815.5439.85444.malone@soybean.canonical.com> Removing "In Progress" status and assignee as change is abandoned. ** Changed in: nova Status: In Progress => Confirmed ** Changed in: nova 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): In Progress 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 1362343 at bugs.launchpad.net Fri Feb 13 15:57:29 2015 From: 1362343 at bugs.launchpad.net (Dolph Mathews) Date: Fri, 13 Feb 2015 15:57:29 -0000 Subject: [Openstack-security] [Bug 1362343] Re: weak digest algorithm for PKI References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com> Message-ID: <20150213155729.21020.58083.malone@gac.canonical.com> I'd suggest marking this as Won't Fix in keystone since pki_setup and ssl_setup are only really useful to developers. Production deployments should use real certificates. -- 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 1362343 at bugs.launchpad.net Fri Feb 13 16:10:34 2015 From: 1362343 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 13 Feb 2015 16:10:34 -0000 Subject: [Openstack-security] [Bug 1362343] Change abandoned on keystone (master) References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com> Message-ID: <20150213161034.17171.99473.malone@soybean.canonical.com> Change abandoned by Brant Knudson (bknudson at us.ibm.com) on branch: master Review: https://review.openstack.org/117366 Reason: Makes sense to tell people to use their own certs 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/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 1362343 at bugs.launchpad.net Fri Feb 13 16:10:44 2015 From: 1362343 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 13 Feb 2015 16:10:44 -0000 Subject: [Openstack-security] [Bug 1362343] Change abandoned on keystone (master) References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com> Message-ID: <20150213161044.17714.95189.malone@soybean.canonical.com> Change abandoned by Brant Knudson (bknudson at us.ibm.com) on branch: master Review: https://review.openstack.org/117367 Reason: Abandoned parent -- 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 sriram at sriramhere.com Sat Feb 14 17:31:48 2015 From: sriram at sriramhere.com (Sriram Subramanian) Date: Sat, 14 Feb 2015 09:31:48 -0800 Subject: [Openstack-security] Host and Network Intrusion detection In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E501026310F1@CERNXCHG41.cern.ch> References: <5D7F9996EA547448BC6C54C8C5AAF4E501026310F1@CERNXCHG41.cern.ch> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at nycresistor.com Sat Feb 14 23:17:18 2015 From: matt at nycresistor.com (matt) Date: Sat, 14 Feb 2015 18:17:18 -0500 Subject: [Openstack-security] Host and Network Intrusion detection In-Reply-To: References: <5D7F9996EA547448BC6C54C8C5AAF4E501026310F1@CERNXCHG41.cern.ch> Message-ID: 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Mon Feb 16 08:16:06 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Feb 2015 08:16:06 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ie03325a902ec882d340f1f1b017da546edb6815d Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/150580 Log: commit b5395f3b8b1c5a8c4fecc394f58ab7e1bf3c31da Author: Matthew Gilliard Date: Tue Jan 27 20:45:32 2015 +0000 Adds ssl_overrides to glance client creation If3f88d8db4a726219573d0f1b65908408e3aa6a9 added a util method so that http clients created by nova can have per-client overrides for ssl options. This patch uses that util method in the glance client. DocImpact new configuation option CONF.glance.ssl_overrides, as described SecurityImpact Change-Id: Ie03325a902ec882d340f1f1b017da546edb6815d From gerrit2 at review.openstack.org Mon Feb 16 08:50:12 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Feb 2015 08:50:12 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I7222712970e09e2807dc572d1bb922f2b3c4491d Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/143443 Log: commit f8509536e8a06f9ac728ea8a577337680191471f Author: Matthew Gilliard Date: Mon Dec 22 13:56:39 2014 +0000 Adds ssl_overrides dict for keystone client configuration So that we can allow users to specify different values for ca_cert, cert and key for each https client which nova creates, we add an 'ssl_overrides' DictOpt for each one. This patch does so for the keystone client created in the ec2 api. DocImpact new config option CONF.ec2_ssl_overrides SecurityImpact Change-Id: I7222712970e09e2807dc572d1bb922f2b3c4491d From gerrit2 at review.openstack.org Mon Feb 16 08:50:32 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Feb 2015 08:50:32 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ie03325a902ec882d340f1f1b017da546edb6815d Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/150580 Log: commit a353cc424d9a0314b872facc37d9dfa29fab2044 Author: Matthew Gilliard Date: Tue Jan 27 20:45:32 2015 +0000 Adds ssl_overrides to glance client creation If3f88d8db4a726219573d0f1b65908408e3aa6a9 added a util method so that http clients created by nova can have per-client overrides for ssl options. This patch uses that util method in the glance client. DocImpact new configuation option CONF.glance.ssl_overrides, as described SecurityImpact Change-Id: Ie03325a902ec882d340f1f1b017da546edb6815d From gerrit2 at review.openstack.org Mon Feb 16 12:31:48 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Feb 2015 12:31:48 +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 2fd61e22098009dd6352a0451e67ae5bc503475f 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 robert.clark at hp.com Mon Feb 16 15:35:19 2015 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 16 Feb 2015 15:35:19 +0000 Subject: [Openstack-security] Host and Network Intrusion detection In-Reply-To: References: <5D7F9996EA547448BC6C54C8C5AAF4E501026310F1@CERNXCHG41.cern.ch> Message-ID: Unfortunately all the solutions available at the moment are deployment specific, there aren’t any nicely documented “standard” ways of managing multi-tenant aware, compute-level IDS with OpenStack today. There are some options depending on technology choices. For example, in a deployment that uses Open vSwitch one could use an additional OVS instance on each compute host to act as a bump in the wire network tap between the hypervisor and the Neutron OVS instance – you can pretty much build any IPS infrastructure you like on top of that and with a little additional magic you can make your IDS system understand the multi tenant nature of the traffic being collected. -Rob From: Matt Joyce > Date: Saturday, 14 February 2015 23:17 To: Sriram Subramanian > Cc: "openstack-security at lists.openstack.org" > Subject: Re: [Openstack-security] Host and Network Intrusion detection 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 From gerrit2 at review.openstack.org Tue Feb 17 07:30:52 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Feb 2015 07:30:52 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ie389de6538a9b98dc51c7d781b81b3ab10b83842 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/156493 Log: commit 78b5b0a9575cd5e9c4543ec0e8fd6072af1f0ebb Author: abhishekkekane Date: Thu Feb 12 04:09:14 2015 -0800 Image data remains in backend for deleted image Trying to delete image created using task api (import-from) image gets deleted from the database, but image data remains in the backend. Import task does not update the location of the image and it remains None even image becomes active. Location entry is not added in the database in image_locations table. Added location information to the image before saving the image in the database. SecurityImpact Change-Id: Ie389de6538a9b98dc51c7d781b81b3ab10b83842 Closes-Bug: #1420696 From vkuklin at mirantis.com Tue Feb 17 11:32:30 2015 From: vkuklin at mirantis.com (Vladimir Kuklin) Date: Tue, 17 Feb 2015 11:32:30 -0000 Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com> Message-ID: <20150217113230.17073.35690.malone@soybean.canonical.com> This bug requires altering of reference architecture - Won't Fix for 6.0.x ** Also affects: fuel/6.0.x Importance: Undecided Status: New ** Changed in: fuel/6.0.x Status: New => Won't Fix ** Changed in: fuel/6.0.x Milestone: None => 6.0.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/1355509 Title: Better conductor deployment Status in Fuel: OpenStack installer that works: Triaged Status in Fuel for OpenStack 6.0.x series: Won't Fix Bug description: Here is several issues with how MOS deploys conductor. 1 By default all deployment variants assume deployments with conductor enabled. But this requires to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor. One of the reason for creating conductor service was to provide security level for nova. 2 by default it not possible to disable conductor using MOS tools. Customers who prefer performance over security should have this options. Conductor can introduce significant delay in all actions required database access. This two enchantments are tied together. The following actions are required to disable usage of conductor. On all compute nodes: 1 make use mysql port is accessible from compute nodes and all necessary grange are present. 2 add into nova.conf [DEFAULT] sql_connection = mysql://nova:password at mysqlhost/nova_db [conductor] use_local=true 3 service openstack-nova-compute restart 4 optionally stop conductor process on controllers Monitoring tuning may be required.. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1355509/+subscriptions From gerrit2 at review.openstack.org Tue Feb 17 11:43:27 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Feb 2015 11:43:27 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change Ie389de6538a9b98dc51c7d781b81b3ab10b83842 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/156553 Log: commit 25a722e614eacc47e4658f0bca6343fa52f7d03f Author: abhishekkekane Date: Thu Feb 12 04:09:14 2015 -0800 Image data remains in backend for deleted image Trying to delete image created using task api (import-from) image gets deleted from the database, but image data remains in the backend. Import task does not update the location of the image and it remains None even image becomes active. Location entry is not added in the database in image_locations table. Added location information to the image before saving the image in the database. SecurityImpact Conflicts: glance/common/scripts/image_import/main.py Change-Id: Ie389de6538a9b98dc51c7d781b81b3ab10b83842 Closes-Bug: #1420696 (cherry picked from commit 78b5b0a9575cd5e9c4543ec0e8fd6072af1f0ebb) From blp at nicira.com Tue Feb 17 23:12:33 2015 From: blp at nicira.com (Ben Pfaff) Date: Tue, 17 Feb 2015 15:12:33 -0800 Subject: [Openstack-security] criteria for downstream stakeholders? Message-ID: <20150217231233.GL25632@nicira.com> Hi. I'm a contributor to Open vSwitch. Over in OVS, we're forming a vulnerability management process, modeled on the one used in OpenStack described at https://wiki.openstack.org/wiki/Vulnerability_Management. We're trying to figure out what criteria to use for deciding what companies or organizations qualify as downstream stakeholders. Can anyone tell us what criteria or policy OpenStack uses? Thanks, Ben. From fungi at yuggoth.org Tue Feb 17 23:33:15 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 17 Feb 2015 23:33:15 +0000 Subject: [Openstack-security] criteria for downstream stakeholders? In-Reply-To: <20150217231233.GL25632@nicira.com> References: <20150217231233.GL25632@nicira.com> Message-ID: <20150217233315.GN2497@yuggoth.org> On 2015-02-17 15:12:33 -0800 (-0800), Ben Pfaff wrote: > Hi. I'm a contributor to Open vSwitch. Over in OVS, we're forming a > vulnerability management process, modeled on the one used in OpenStack > described at https://wiki.openstack.org/wiki/Vulnerability_Management. > > We're trying to figure out what criteria to use for deciding what > companies or organizations qualify as downstream stakeholders. Can > anyone tell us what criteria or policy OpenStack uses? It's mostly a self-selecting lot. The OpenStack VMT primarily expects requests for inclusion from public service providers and representatives from operating systems/distributions who are repackaging our software. The goal is to make sure that anyone who needs to prepare or integrate patches into their systems prior to public disclosure (so as to reduce the duration of risk to exposed systems) can safely do so while still minimizing the number of people who can possibly leak that same information. We don't really have an explicit policy around exactly who we can approve, since situations vary and we need to be flexible to accommodate them. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: Digital signature URL: From blp at nicira.com Tue Feb 17 23:45:12 2015 From: blp at nicira.com (Ben Pfaff) Date: Tue, 17 Feb 2015 15:45:12 -0800 Subject: [Openstack-security] criteria for downstream stakeholders? In-Reply-To: <20150217233315.GN2497@yuggoth.org> References: <20150217231233.GL25632@nicira.com> <20150217233315.GN2497@yuggoth.org> Message-ID: <20150217234512.GA8263@nicira.com> On Tue, Feb 17, 2015 at 11:33:15PM +0000, Jeremy Stanley wrote: > On 2015-02-17 15:12:33 -0800 (-0800), Ben Pfaff wrote: > > Hi. I'm a contributor to Open vSwitch. Over in OVS, we're forming a > > vulnerability management process, modeled on the one used in OpenStack > > described at https://wiki.openstack.org/wiki/Vulnerability_Management. > > > > We're trying to figure out what criteria to use for deciding what > > companies or organizations qualify as downstream stakeholders. Can > > anyone tell us what criteria or policy OpenStack uses? > > It's mostly a self-selecting lot. The OpenStack VMT primarily > expects requests for inclusion from public service providers and > representatives from operating systems/distributions who are > repackaging our software. The goal is to make sure that anyone who > needs to prepare or integrate patches into their systems prior to > public disclosure (so as to reduce the duration of risk to exposed > systems) can safely do so while still minimizing the number of > people who can possibly leak that same information. We don't really > have an explicit policy around exactly who we can approve, since > situations vary and we need to be flexible to accommodate them. Thanks. Have you run into any gray areas? Of the 11 requests we've had so far, 7 of them are from very big companies who should obviously be included. The remaining 4 are harder to judge because they are from companies that we have not heard of. They seem to check out at first glance, that is, they show up on Google and have websites that don't "look" fraudulent etc., but I have no way really to verify that. The risk here is notifying someone dishonest or careless a few days early. It sounds like that's not something you're too worried about? I don't know how to judge it, myself. Thanks, Ben. From fungi at yuggoth.org Tue Feb 17 23:57:29 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 17 Feb 2015 23:57:29 +0000 Subject: [Openstack-security] criteria for downstream stakeholders? In-Reply-To: <20150217234512.GA8263@nicira.com> References: <20150217231233.GL25632@nicira.com> <20150217233315.GN2497@yuggoth.org> <20150217234512.GA8263@nicira.com> Message-ID: <20150217235729.GO2497@yuggoth.org> On 2015-02-17 15:45:12 -0800 (-0800), Ben Pfaff wrote: > Have you run into any gray areas? [...] Yes, we've in the past had to ask people, "Who are you? We've never heard of you, sorry." > The risk here is notifying someone dishonest or careless a few days > early. It sounds like that's not something you're too worried about? > I don't know how to judge it, myself. We definitely care about it, I'm just not able to provide cut and dried acceptance criteria. It's unfortunately subjective and depends a lot on whether it's an entity we're aware of with some wide/public use of or redistribution of our software, whether the individual requesting access on their behalf can be vetted as actual representative of that organization, whether someone else from that same organization already has access making their request unnecessary/redundant, whether the organization has a track record of assisting our efforts at improving the software and security around it (reporting issues themselves, pointing out problems in patches we've not spotted ourselves)... So I don't have a simple answer--it depends a lot on your existing ties with your community. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: Digital signature URL: From 1406191 at bugs.launchpad.net Thu Feb 5 03:39:07 2015 From: 1406191 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Feb 2015 03:39:07 -0000 Subject: [Openstack-security] [Bug 1406191] Re: node-show discloses credentials as plain text in driver_info References: <20141229065345.16652.7904.malonedeb@soybean.canonical.com> Message-ID: <20150205033910.12938.92709.launchpad@gac.canonical.com> ** Changed in: ironic Assignee: Zhenzan Zhou (zhenzan-zhou) => Devananda van der Veen (devananda) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1406191 Title: node-show discloses credentials as plain text in driver_info Status in OpenStack Bare Metal Provisioning Service (Ironic): In Progress Bug description: [root at rhel7-vm ~]# ironic node-show b0860248-bf1d-4803-bdc3-5bb42852841c +------------------------+--------------------------------------------------------------------------+ | Property | Value | +------------------------+--------------------------------------------------------------------------+ | instance_uuid | bdaf5cc9-de8f-407e-890a-d4b6c1e3e602 | | target_power_state | None | | properties | {u'memory_mb': u'1024', u'cpu_arch': u'x86_64', u'local_gb': u'10', | | | u'cpus': u'1'} | | maintenance | False | | driver_info | {u'pxe_deploy_ramdisk': u'503e88d9-637c-4369-b8e0-2b2531c0eeb2', | | | u'ipmi_terminal_port': u'1234', u'ipmi_username': u'username', | | | u'ipmi_address': u'9.9.9.9', u'ipmi_password': u'password', | | | u'pxe_deploy_kernel': u'1e676e34-1294-4a17-afba-cd5c358cd314'} | | extra | {} | | last_error | None | | created_at | 2014-12-19T07:13:50+00:00 | | target_provision_state | deploy complete | | driver | pxe_ipmitool | | updated_at | 2014-12-29T04:52:29+00:00 | | instance_info | {u'ramdisk': u'b30a4441-b975-432d-8878-573de2aba297', u'kernel': u | | | '490b7edd-dfe9-4842-80ed-033c788b37d1', u'root_gb': u'10', | | | u'image_source': u'8d860e96-61f9-4070-8b09-4c8037c104c7', u'deploy_key': | | | u'2AX7KT8DXGU395SOA06J676YAC7AVA60', u'swap_mb': u'0'} | | chassis_uuid | | | provision_state | wait call-back | | reservation | None | | power_state | power on | | console_enabled | False | | uuid | b0860248-bf1d-4803-bdc3-5bb42852841c | +------------------------+--------------------------------------------------------------------------+ [root at rhel7-vm ~]# Log file will not show the password - 'ipmi_password': '' So can we hide the password in ironic client side? To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1406191/+subscriptions From 1406191 at bugs.launchpad.net Thu Feb 5 10:36:35 2015 From: 1406191 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Feb 2015 10:36:35 -0000 Subject: [Openstack-security] [Bug 1406191] Re: node-show discloses credentials as plain text in driver_info References: <20141229065345.16652.7904.malonedeb@soybean.canonical.com> Message-ID: <20150205103635.20514.54721.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/150688 Committed: https://git.openstack.org/cgit/openstack/ironic/commit/?id=efb321c71a709a6f5b33d9de62587117f0c29ba3 Submitter: Jenkins Branch: master commit efb321c71a709a6f5b33d9de62587117f0c29ba3 Author: Zhenzan Zhou Date: Wed Jan 28 13:10:02 2015 +0800 Add policy show_password to mask passwords in driver_info Ironic API already enforces admin role to run node-show. So a new policy show_password is added to control if plain text passwords in driver_info should be masked or not before sending back to API calls. The default is masking password for all cases. Change-Id: Icd3e6be049376bf7b4468f0c149a72a06643da32 Closes-Bug: #1406191 ** Changed in: ironic 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/1406191 Title: node-show discloses credentials as plain text in driver_info Status in OpenStack Bare Metal Provisioning Service (Ironic): Fix Committed Bug description: [root at rhel7-vm ~]# ironic node-show b0860248-bf1d-4803-bdc3-5bb42852841c +------------------------+--------------------------------------------------------------------------+ | Property | Value | +------------------------+--------------------------------------------------------------------------+ | instance_uuid | bdaf5cc9-de8f-407e-890a-d4b6c1e3e602 | | target_power_state | None | | properties | {u'memory_mb': u'1024', u'cpu_arch': u'x86_64', u'local_gb': u'10', | | | u'cpus': u'1'} | | maintenance | False | | driver_info | {u'pxe_deploy_ramdisk': u'503e88d9-637c-4369-b8e0-2b2531c0eeb2', | | | u'ipmi_terminal_port': u'1234', u'ipmi_username': u'username', | | | u'ipmi_address': u'9.9.9.9', u'ipmi_password': u'password', | | | u'pxe_deploy_kernel': u'1e676e34-1294-4a17-afba-cd5c358cd314'} | | extra | {} | | last_error | None | | created_at | 2014-12-19T07:13:50+00:00 | | target_provision_state | deploy complete | | driver | pxe_ipmitool | | updated_at | 2014-12-29T04:52:29+00:00 | | instance_info | {u'ramdisk': u'b30a4441-b975-432d-8878-573de2aba297', u'kernel': u | | | '490b7edd-dfe9-4842-80ed-033c788b37d1', u'root_gb': u'10', | | | u'image_source': u'8d860e96-61f9-4070-8b09-4c8037c104c7', u'deploy_key': | | | u'2AX7KT8DXGU395SOA06J676YAC7AVA60', u'swap_mb': u'0'} | | chassis_uuid | | | provision_state | wait call-back | | reservation | None | | power_state | power on | | console_enabled | False | | uuid | b0860248-bf1d-4803-bdc3-5bb42852841c | +------------------------+--------------------------------------------------------------------------+ [root at rhel7-vm ~]# Log file will not show the password - 'ipmi_password': '' So can we hide the password in ironic client side? To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1406191/+subscriptions From 1420863 at bugs.launchpad.net Wed Feb 11 16:41:35 2015 From: 1420863 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Feb 2015 16:41:35 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150211164137.5968.7297.launchpad@soybean.canonical.com> ** Changed in: horizon Status: New => In Progress ** Changed in: horizon Assignee: (unassigned) => Brant Knudson (blk-u) -- 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): In Progress 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 vanderwl at us.ibm.com Wed Feb 11 17:44:06 2015 From: vanderwl at us.ibm.com (Mark Vanderwiel) Date: Wed, 11 Feb 2015 17:44:06 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150211174407.5931.36143.launchpad@soybean.canonical.com> ** Tags added: dashboard ** Changed in: openstack-chef Assignee: (unassigned) => Mark Vanderwiel (vanderwl) ** Changed in: openstack-chef Importance: Undecided => High ** Changed in: openstack-chef Milestone: None => juno-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/1420863 Title: Default setting should be secure Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack + Chef: In Progress 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 1420863 at bugs.launchpad.net Wed Feb 11 17:48:43 2015 From: 1420863 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Feb 2015 17:48:43 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150211174843.5791.40129.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/154976 ** Changed in: openstack-chef 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/1420863 Title: Default setting should be secure Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack + Chef: In Progress 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 1420863 at bugs.launchpad.net Wed Feb 11 19:24:25 2015 From: 1420863 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Feb 2015 19:24:25 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150211192425.6163.80247.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/154943 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=7bd87acdd07f0718e32221525ff54a188f8cecb8 Submitter: Jenkins Branch: master commit 7bd87acdd07f0718e32221525ff54a188f8cecb8 Author: Brant Knudson Date: Wed Feb 11 10:38:58 2015 -0600 Set the password_autocomplete default to "off" It's safer to set the autocomplete option to "off" for passwords so that browsers get the hint to not save it. The default should be secure so that deployers need to make a conscious decision to be less-secure. This is for security hardening. SecurityImpact Closes-Bug: 1420863 Change-Id: If2c3439cf23b11dd7829a4d7866d3b21409a7d69 ** Changed in: horizon 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/1420863 Title: Default setting should be secure Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack + Chef: In Progress 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 flwang at catalyst.net.nz Wed Feb 11 23:55:12 2015 From: flwang at catalyst.net.nz (Fei Long Wang) Date: Wed, 11 Feb 2015 23:55:12 -0000 Subject: [Openstack-security] [Bug 1420984] Re: [v1] User can change image owner to any other References: <20150211214029.5931.12162.malonedeb@soybean.canonical.com> Message-ID: <20150211235513.5692.72946.malone@soybean.canonical.com> Just verified again, the problem has gone. So maybe is an environment issue. And I found this, https://github.com/openstack/glance/blob/master/glance/registry/api/v1/images.py#L460 so I think this bug is invalid. ** Changed in: glance Status: New => Invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1420984 Title: [v1] User can change image owner to any other Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Bug description: Only admin can change image owner, but everybody. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1420984/+subscriptions From 1420863 at bugs.launchpad.net Sun Feb 15 08:40:10 2015 From: 1420863 at bugs.launchpad.net (Akihiro Motoki) Date: Sun, 15 Feb 2015 08:40:10 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150215084012.21020.18640.launchpad@gac.canonical.com> ** Changed in: horizon Importance: Undecided => High ** 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/1420863 Title: Default setting should be secure Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack + Chef: In Progress 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 1420863 at bugs.launchpad.net Wed Feb 18 00:06:55 2015 From: 1420863 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 18 Feb 2015 00:06:55 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150218000655.20987.90407.malone@gac.canonical.com> Reviewed: https://review.openstack.org/154976 Committed: https://git.openstack.org/cgit/stackforge/cookbook-openstack-dashboard/commit/?id=9eed38ca508e3fb6cdb4390cf504ae211bc9a665 Submitter: Jenkins Branch: master commit 9eed38ca508e3fb6cdb4390cf504ae211bc9a665 Author: Mark Vanderwiel Date: Wed Feb 11 11:47:09 2015 -0600 Change the default for password_autocomplete to off For better default security, change the default to off for password autocomplete. Base openstack horizon is also making this change soon. Change-Id: Ie46dd5b5e5d65dd4bfa298a4c2d571cf13b94812 Closes-Bug: #1420863 ** Changed in: openstack-chef Status: In Progress => 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 Committed 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 dlambrig at redhat.com Wed Feb 18 01:11:43 2015 From: dlambrig at redhat.com (Dan Lambright) Date: Tue, 17 Feb 2015 20:11:43 -0500 (EST) Subject: [Openstack-security] Host and Network Intrusion detection In-Reply-To: References: Message-ID: <1146747248.4736114.1424221903274.JavaMail.zimbra@redhat.com> > Date: Mon, 16 Feb 2015 15:35:19 +0000 > From: "Clark, Robert Graham" > To: matt , Sriram Subramanian > > Cc: "openstack-security at lists.openstack.org" > > Subject: Re: [Openstack-security] Host and Network Intrusion detection > Message-ID: > Content-Type: text/plain; charset="Windows-1252" > > Unfortunately all the solutions available at the moment are deployment > specific, there aren?t any nicely documented ?standard? ways of managing > multi-tenant aware, compute-level IDS with OpenStack today. > > There are some options depending on technology choices. For example, in a > deployment that uses Open vSwitch one could use an additional OVS instance > on each compute host to act as a bump in the wire network tap between the > hypervisor and the Neutron OVS instance ? you can pretty much build any IPS > infrastructure you like on top of that and with a little additional magic > you can make your IDS system understand the multi tenant nature of the > traffic being collected. > I'm putting together some configurations of Snort + OpenStack (technically akin to what Rob described), and hope to publish something in Vancouver in May in a talk I've proposed. I'll keep this mailing list updated. Dan dlambrig at redhat.com From 1274034 at bugs.launchpad.net Wed Feb 18 18:18:42 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 18 Feb 2015 18:18:42 -0000 Subject: [Openstack-security] [Bug 1274034] Related fix proposed to neutron (master) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150218181842.24048.25659.malone@wampee.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/157097 -- 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 1274034 at bugs.launchpad.net Fri Feb 20 02:07:31 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 Feb 2015 02:07:31 -0000 Subject: [Openstack-security] [Bug 1274034] Related fix proposed to neutron (master) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150220020731.24495.10512.malone@wampee.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/157634 -- 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 gerrit2 at review.openstack.org Fri Feb 20 07:08:37 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 20 Feb 2015 07:08:37 +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 617af458937b9a724891cb801faffe97c81de693 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 Fri Feb 20 07:57:29 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 20 Feb 2015 07:57:29 +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/130839 Log: commit c2dcb32771df2e351cf2ebc41d0b6361a109d899 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 wsgi_keep_alive option (default=True). SecurityImpact Closes-Bug: #1361360 Change-Id: I93aaca24935a4f3096210233097dd6b8c5440176 From gerrit2 at review.openstack.org Fri Feb 20 09:16:39 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 20 Feb 2015 09:16:39 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I4f7d1aa103f4ce7abf4026e7097b9e76c24135fa Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157067 Log: commit a880c8e762e94b70c1e5d5692a3defcde734a601 Author: Mike Fedosin Date: Thu Sep 18 18:07:42 2014 +0400 Initiate deletion of image files if the import was interrupted If the image is deleted by appropriate API call while its content is still being uploaded in import task in v2, an exception is raised and it is not handled in the API code. This leads to the fact that the uploaded image file stays in a storage and clogs it. There existed code that safely removes image files if the exception occurs. SecurityImpact Conflicts: glance/common/scripts/image_import/main.py Closes-Bug: 1371118 Change-Id: I4f7d1aa103f4ce7abf4026e7097b9e76c24135fa (cherry picked from commit 7858d4d95154c8596720365e465cca7858cfec5c) From gerrit2 at review.openstack.org Fri Feb 20 11:37:08 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 20 Feb 2015 11:37:08 +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/130839 Log: 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 From gerrit2 at review.openstack.org Fri Feb 20 18:15:43 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 20 Feb 2015 18:15:43 +0000 Subject: [Openstack-security] [openstack/sahara-specs] SecurityImpact review request change I7b5b38b5b10f7e88893dca8792a298537b69cf05 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157432 Log: commit f36e74f835b247219931669b7e6b0e700776e1b3 Author: Michael McCune Date: Thu Feb 19 11:18:00 2015 -0500 Adding improved secret storage spec There are several secrets (for example passwords) that Sahara uses with respect to deployed frameworks which are currently stored in its database. This blueprint proposes the creation of a Barbican integration module that will allow Sahara to offload secret storage to that service. The initial focus of this offloading effort will focus on the storage of Swift credentials. SecurityImpact Change-Id: I7b5b38b5b10f7e88893dca8792a298537b69cf05 Partial-implements: bp improved-secret-storage From kevin.carter at rackspace.com Sun Feb 22 05:22:21 2015 From: kevin.carter at rackspace.com (Kevin Carter) Date: Sun, 22 Feb 2015 05:22:21 -0000 Subject: [Openstack-security] [Bug 1412393] Re: mariadb repo unnecessarily configured in all containers References: <20150119110012.23998.45109.malonedeb@gac.canonical.com> Message-ID: <20150222052221.23815.34121.malone@wampee.canonical.com> In master galera_client is now a dependent role within other roles that need to have it installed. This resolves this issue for master though we should determine if this functionality is something that we want to implement in Juno/Icehouse? ** Also affects: openstack-ansible/icehouse Importance: Undecided Status: New ** Also affects: openstack-ansible/trunk Importance: Low Status: Triaged ** Also affects: openstack-ansible/juno Importance: Undecided Status: New ** Changed in: openstack-ansible/trunk Assignee: (unassigned) => Kevin Carter (kevin-carter) ** Changed in: openstack-ansible/trunk Status: Triaged => Fix Committed ** Changed in: openstack-ansible/juno Status: New => Triaged ** Changed in: openstack-ansible/icehouse Status: New => Triaged ** Changed in: openstack-ansible/juno Importance: Undecided => Low ** Changed in: openstack-ansible/icehouse 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/1412393 Title: mariadb repo unnecessarily configured in all containers Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: Triaged Status in openstack-ansible juno series: Triaged Status in openstack-ansible trunk series: Fix Committed Bug description: The mariadb repo is unnecessarily configured on every host and in every container. The repo should only configured for containers and hosts that require access to the database. In order to provide a more secure-by-default installation, the /root/.my.cnf client configuration should only placed where necessary - the utility container is likely to be the only location that requires it as all DB access by services are done through explicit configuration with a restricted DB user. Another set of containers it should perhaps be placed into would be the galera containers themselves. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1412393/+subscriptions From 1370283 at bugs.launchpad.net Mon Feb 23 16:06:56 2015 From: 1370283 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 23 Feb 2015 16:06:56 -0000 Subject: [Openstack-security] [Bug 1370283] Re: python-glanceclient uses extremely insecure configurations of OpenSSL References: <20140916232429.32614.13519.malonedeb@gac.canonical.com> Message-ID: <20150223160656.24056.82684.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/122749 Committed: https://git.openstack.org/cgit/openstack/python-glanceclient/commit/?id=9dcf3f16ce1cb7e828ee3d1811bc0ebd44abb106 Submitter: Jenkins Branch: master commit 9dcf3f16ce1cb7e828ee3d1811bc0ebd44abb106 Author: Stuart McLaren Date: Fri Sep 19 14:25:10 2014 +0000 Reduce the set of supported client SSL ciphers python-glanceclient (like, for example, curl) can advertise the default set of supported OpenSSL ciphers in its ClientHello packet. This patches reduces that to a stronger subset. Change-Id: I7c30465e79d8a32f43458cd6253a98fcf067dc38 Closes-bug: #1370283 ** Changed in: python-glanceclient 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/1370283 Title: python-glanceclient uses extremely insecure configurations of OpenSSL Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Glance: Fix Committed Bug description: glanceclient does not properly configure OpenSSL, which results in making TLS connections which allow extremely bad security settings. Specifically it allows SSLv2, and many insecure ciphersuites. From Ubuntu 14.04: >>> import pprint; import glanceclient.common.http; pprint.pprint(glanceclient.common.http.HTTPClient('https://', ssl_compression=False).session.get("https://www.howsmyssl.com/a/check").json()) {u'able_to_detect_n_minus_one_splitting': False, u'beast_vuln': False, u'ephemeral_keys_supported': True, u'given_cipher_suites': [u'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_AES_256_GCM_SHA384', u'TLS_RSA_WITH_AES_256_CBC_SHA256', u'TLS_RSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA', u'TLS_DHE_RSA_WITH_SEED_CBC_SHA', u'TLS_DHE_DSS_WITH_SEED_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_AES_128_GCM_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_SEED_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDHE_RSA_WITH_RC4_128_SHA', u'TLS_ECDHE_ECDSA_WITH_RC4_128_SHA', u'TLS_ECDH_RSA_WITH_RC4_128_SHA', u'TLS_ECDH_ECDSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_MD5', u'TLS_DHE_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_DSS_WITH_DES_CBC_SHA', u'TLS_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5', u'TLS_RSA_EXPORT_WITH_RC4_40_MD5', u'TLS_EMPTY_RENEGOTIATION_INFO_SCSV'], u'insecure_cipher_suites': {u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_DSS_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC4_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption']}, u'rating': u'Bad', u'session_ticket_supported': True, u'tls_compression_supported': False, u'tls_version': u'TLS 1.2', u'unknown_cipher_suite_supported': False} I *strongly* recommend just deleting all this code and using requests. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1370283/+subscriptions From fungi at yuggoth.org Mon Feb 23 16:48:35 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 23 Feb 2015 16:48:35 -0000 Subject: [Openstack-security] [Bug 1414532] Re: asserts used in cache.py References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150223164836.27801.44467.launchpad@soybean.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/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): Triaged Status in OpenStack Security Advisories: Won't Fix 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 fungi at yuggoth.org Mon Feb 23 17:00:55 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 23 Feb 2015 17:00:55 -0000 Subject: [Openstack-security] [Bug 1424089] Re: Use SystemRandom rather than random References: <20150220225213.28004.475.malonedeb@soybean.canonical.com> Message-ID: <20150223170055.21406.80585.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/1424089 Title: Use SystemRandom rather than random Status in OpenStack Identity (Keystone): In Progress 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 gerrit2 at review.openstack.org Mon Feb 23 23:36:06 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 23 Feb 2015 23:36:06 +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 f42af53af1f1568dc9221754f611b0f16fee9889 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 not condition: raise AssertionError. 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 1274034 at bugs.launchpad.net Mon Feb 23 23:40:31 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 23 Feb 2015 23:40:31 -0000 Subject: [Openstack-security] [Bug 1274034] Fix proposed to neutron (master) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150223234031.24420.83149.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/158491 -- 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 nikhil.komawar at rackspace.com Tue Feb 24 05:55:42 2015 From: nikhil.komawar at rackspace.com (nikhil komawar) Date: Tue, 24 Feb 2015 05:55:42 -0000 Subject: [Openstack-security] [Bug 1370283] Re: python-glanceclient uses extremely insecure configurations of OpenSSL References: <20140916232429.32614.13519.malonedeb@gac.canonical.com> Message-ID: <20150224055544.27553.47291.launchpad@soybean.canonical.com> ** Changed in: python-glanceclient 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/1370283 Title: python-glanceclient uses extremely insecure configurations of OpenSSL Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Glance: Fix Released Bug description: glanceclient does not properly configure OpenSSL, which results in making TLS connections which allow extremely bad security settings. Specifically it allows SSLv2, and many insecure ciphersuites. From Ubuntu 14.04: >>> import pprint; import glanceclient.common.http; pprint.pprint(glanceclient.common.http.HTTPClient('https://', ssl_compression=False).session.get("https://www.howsmyssl.com/a/check").json()) {u'able_to_detect_n_minus_one_splitting': False, u'beast_vuln': False, u'ephemeral_keys_supported': True, u'given_cipher_suites': [u'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_AES_256_GCM_SHA384', u'TLS_RSA_WITH_AES_256_CBC_SHA256', u'TLS_RSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA', u'TLS_DHE_RSA_WITH_SEED_CBC_SHA', u'TLS_DHE_DSS_WITH_SEED_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_AES_128_GCM_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_SEED_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDHE_RSA_WITH_RC4_128_SHA', u'TLS_ECDHE_ECDSA_WITH_RC4_128_SHA', u'TLS_ECDH_RSA_WITH_RC4_128_SHA', u'TLS_ECDH_ECDSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_MD5', u'TLS_DHE_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_DSS_WITH_DES_CBC_SHA', u'TLS_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5', u'TLS_RSA_EXPORT_WITH_RC4_40_MD5', u'TLS_EMPTY_RENEGOTIATION_INFO_SCSV'], u'insecure_cipher_suites': {u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_DSS_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC4_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption']}, u'rating': u'Bad', u'session_ticket_supported': True, u'tls_compression_supported': False, u'tls_version': u'TLS 1.2', u'unknown_cipher_suite_supported': False} I *strongly* recommend just deleting all this code and using requests. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1370283/+subscriptions From gerrit2 at review.openstack.org Tue Feb 24 07:43:23 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 24 Feb 2015 07:43:23 +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 7a32d694aba272e65a47aa9d394b607e48b2f240 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 Tue Feb 24 22:02:53 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 24 Feb 2015 22:02:53 +0000 Subject: [Openstack-security] [openstack/sahara-specs] SecurityImpact review request change I7b5b38b5b10f7e88893dca8792a298537b69cf05 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157432 Log: commit 09ee2c572e712c607cf5e85a4fef4105c3773f23 Author: Michael McCune Date: Thu Feb 19 11:18:00 2015 -0500 Adding improved secret storage spec There are several secrets (for example passwords) that Sahara uses with respect to deployed frameworks which are currently stored in its database. This blueprint proposes the creation of a Barbican integration module that will allow Sahara to offload secret storage to that service. The initial focus of this offloading effort will focus on the storage of Swift credentials. SecurityImpact Change-Id: I7b5b38b5b10f7e88893dca8792a298537b69cf05 Partial-implements: bp improved-secret-storage From 1163569 at bugs.launchpad.net Tue Feb 24 22:39:44 2015 From: 1163569 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 24 Feb 2015 22:39:44 -0000 Subject: [Openstack-security] [Bug 1163569] Change abandoned on neutron (master) References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com> Message-ID: <20150224223944.32196.94204.malone@chaenomeles.canonical.com> Change abandoned by Kyle Mestery (mestery at mestery.com) on branch: master Review: https://review.openstack.org/109848 Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results. -- 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): In Progress 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 gerrit2 at review.openstack.org Wed Feb 25 02:49:12 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 25 Feb 2015 02:49:12 +0000 Subject: [Openstack-security] [openstack/sahara-specs] SecurityImpact review request change I7b5b38b5b10f7e88893dca8792a298537b69cf05 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157432 Log: commit 5e9a64d2abe652d8584a4d782a2bba435eac3cd4 Author: Michael McCune Date: Thu Feb 19 11:18:00 2015 -0500 Adding improved secret storage spec There are several secrets (for example passwords) that Sahara uses with respect to deployed frameworks which are currently stored in its database. This specification proposes the creation of a Barbican integration module that will allow Sahara to offload secret storage to that service. The initial focus of this offloading effort will focus on the storage of Swift credentials. SecurityImpact Change-Id: I7b5b38b5b10f7e88893dca8792a298537b69cf05 Partial-implements: bp improved-secret-storage From mathew.hodson at gmail.com Sun Feb 22 18:30:16 2015 From: mathew.hodson at gmail.com (Mathew Hodson) Date: Sun, 22 Feb 2015 18:30:16 -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: <20150222183018.21672.26524.launchpad@gac.canonical.com> ** Information type changed from Public 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/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: New 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 mathew.hodson at gmail.com Sun Feb 22 18:36:01 2015 From: mathew.hodson at gmail.com (Mathew Hodson) Date: Sun, 22 Feb 2015 18:36:01 -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: <20150222183603.23748.31418.launchpad@wampee.canonical.com> ** Information type changed from Public Security to Public -- 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: New 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 1369876 at bugs.launchpad.net Mon Feb 23 01:26:34 2015 From: 1369876 at bugs.launchpad.net (Christoph Dwertmann) Date: Mon, 23 Feb 2015 01:26:34 -0000 Subject: [Openstack-security] [Bug 1369876] Re: Missing HttpOnly Attribute in Session Cookie References: <20140916064453.32545.92390.malonedeb@gac.canonical.com> Message-ID: <20150223012634.27900.47105.malone@soybean.canonical.com> CSRF_COOKIE_HTTPONLY = True This setting fixes the issue for me on icehouse: Set-Cookie: csrftoken=PYvm2g1ms6sp1solX5h7Wsul82VNSasU; expires=Mon, 22-Feb-2016 01:25:14 GMT; httponly; Max-Age=31449600; Path=/; secure -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369876 Title: Missing HttpOnly Attribute in Session Cookie Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It is possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user. Causes: The web application sets session cookies without the HttpOnly attribute Recommend Fix: Add the 'HttpOnly' attribute to all session cookies. The Test Requests and Responses: 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 2014/9/12 504 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 Usage Overview - Cloud Management Dashboard