From tony at bakeyournoodle.com Wed Jul 1 01:43:00 2015 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 01 Jul 2015 01:43:00 -0000 Subject: [Openstack-security] [Bug 1461433] Re: Automatically generated admin password is not complex enough References: <20150603080018.10006.86026.malonedeb@wampee.canonical.com> Message-ID: <20150701014302.11207.45049.launchpad@soybean.canonical.com> ** Changed in: nova Importance: Undecided => Wishlist ** Changed in: nova Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1461433 Title: Automatically generated admin password is not complex enough Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: When performing actions such as create instances, evacuate instances, rebuild instances, rescue instances and update instances' admin password. When the user dose not provide admin password, generate_password() in utils.py is used to generate an admin password. Generate_password() now uses two password symbol groups: default and easier, the default symbol group contains numbers, upper case letters and small case letters. the easier symbol group contains only numbers and upper case letters. The generated password is not complex enough and can cause security problems. One possible solution is to add a new symbol group: STRONGER_PASSWORD_SYMBOLS which contains numbers, upper case letters, lower case letters and also special characters such as `~!@#$%^&*()-_=+ and space. Then adding a new option in configuration file: generate_strong_password = True, when this option is set, nova will generate password using STRONGER_PASSWORD_SYMBOLS symbol group and with longer password length. If this option is not set, the password will be generated using the default symbol group and default length. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1461433/+subscriptions From tony at bakeyournoodle.com Wed Jul 1 01:42:31 2015 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 01 Jul 2015 01:42:31 -0000 Subject: [Openstack-security] [Bug 1461431] Re: Enable admin password complexity verification References: <20150603073922.10444.48985.malonedeb@wampee.canonical.com> Message-ID: <20150701014233.7189.14749.launchpad@gac.canonical.com> ** Changed in: nova Importance: Undecided => Wishlist ** Changed in: nova Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1461431 Title: Enable admin password complexity verification Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: When performing actions such as create instances, evacuate instances, rebuild instances, rescue instances and update instances' admin password. The complexity of user provided admin password has not been verified. This can cause security problems. One solution will be adding a configuration option: using_complex_admin_password = True, if this option is set in configure file by administrator, then Nova will perform password complexity checks, the check standards can be set to following the IT industry general standard, if the provided admin password is not complex enough, an exception will be throw. If this option is not set in configure file, then the complexity check will be skipped. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1461431/+subscriptions From 1451931 at bugs.launchpad.net Wed Jul 1 23:00:35 2015 From: 1451931 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 01 Jul 2015 23:00:35 -0000 Subject: [Openstack-security] [Bug 1451931] Re: ironic password config not marked as secret References: <20150505164255.28640.31104.malonedeb@soybean.canonical.com> Message-ID: <20150701230035.4081.63618.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/194290 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=3b9ae165f7f93424b489bfb992f935d5d5e749f2 Submitter: Jenkins Branch: stable/juno commit 3b9ae165f7f93424b489bfb992f935d5d5e749f2 Author: Joe Gordon Date: Mon May 4 11:19:33 2015 -0700 Mark ironic credential config as secret Mark ironic credentials as secret so we don't log the values. Detected with bandit while testing out: I3026b81317f0a6322acfc94784899a7453af586f Change-Id: Icfd13b3294a9fa0881a5ab01f50864ebcbce393e Closes-Bug: #1451931 ** Changed in: nova/juno Status: New => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1451931 Title: ironic password config not marked as secret Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Committed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The ironic config option for the password and auth token are not marked as secret so the values will get logged during startup in debug mode. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1451931/+subscriptions From fungi at yuggoth.org Thu Jul 2 13:34:38 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 02 Jul 2015 13:34:38 -0000 Subject: [Openstack-security] [Bug 1470740] Re: swiftclient disclose token in debug logs References: <20150702071356.30766.53174.malonedeb@soybean.canonical.com> Message-ID: <20150702133438.18685.32502.malone@chaenomeles.canonical.com> Added the security tag to indicate a possible hardening opportunity. ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1470740 Title: swiftclient disclose token in debug logs Status in OpenStack Image Registry and Delivery Service (Glance): New Status in Python client library for Swift: New Bug description: Setup: juno. Nova, glance + swiftclient. glance-api.conf (important parts): [DEFAULT] debug = true logging_context_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s [%(request_id)s %(user)s %(tenant)s] logging_default_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d logging_exception_prefix=%(name)s[%(process)d]: TRACE %(instance)s default_store = swift use_syslog = True syslog_log_facility = LOG_LOCAL2 swift_store_auth_address = https://my.hand.disclosing.corporte.url:5000/v2.0 swift_store_user = tenant:user swift_store_key = sexgodqwerty123456love Result in remote syslog: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6f64276e2074726461650a6d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 Versions: ii python-swift 2.2.0-0ubuntu1~cloud0 all distributed virtual object store - Python libraries ii python-swiftclient 1:2.3.0-0ubuntu1~cloud0 all Client library for Openstack Swift API. ii glance-api 1:2014.2.3-0-ownbuild all OpenStack Image Registry and Delivery Service - API ii glance-common 1:2014.2.3-ownbuild all OpenStack Image Registry and Delivery Service - Common ii python-glance 1:2014.2.3-0ownbuild all OpenStack Image Registry and Delivery Service - Python library ii python-glance-store 0.1.8-1ubuntu2~cloud0 all OpenStack Image Service store library - Python 2.x ii python-glanceclient 1:0.14.0-0ubuntu1~cloud0 all Client library for Openstack glance server. Impact: 1) Unprivileged employee with access to logging facility may get access to glance images, including snapshots of the tenants. 2) Syslog transmitted unencrypted in UDP or TCP and it may be viewed by unauthorized person. Expected behavior: Complete or partial token masking in logs, f.e.: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6****************d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470740/+subscriptions From 1470740 at bugs.launchpad.net Thu Jul 2 13:49:20 2015 From: 1470740 at bugs.launchpad.net (Robert Clark) Date: Thu, 02 Jul 2015 13:49:20 -0000 Subject: [Openstack-security] [Bug 1470740] Re: swiftclient disclose token in debug logs References: <20150702071356.30766.53174.malonedeb@soybean.canonical.com> Message-ID: <20150702134920.9112.32455.launchpad@gac.canonical.com> ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1470740 Title: swiftclient disclose token in debug logs Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Notes: New Status in Python client library for Swift: New Bug description: Setup: juno. Nova, glance + swiftclient. glance-api.conf (important parts): [DEFAULT] debug = true logging_context_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s [%(request_id)s %(user)s %(tenant)s] logging_default_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d logging_exception_prefix=%(name)s[%(process)d]: TRACE %(instance)s default_store = swift use_syslog = True syslog_log_facility = LOG_LOCAL2 swift_store_auth_address = https://my.hand.disclosing.corporte.url:5000/v2.0 swift_store_user = tenant:user swift_store_key = sexgodqwerty123456love Result in remote syslog: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6f64276e2074726461650a6d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 Versions: ii python-swift 2.2.0-0ubuntu1~cloud0 all distributed virtual object store - Python libraries ii python-swiftclient 1:2.3.0-0ubuntu1~cloud0 all Client library for Openstack Swift API. ii glance-api 1:2014.2.3-0-ownbuild all OpenStack Image Registry and Delivery Service - API ii glance-common 1:2014.2.3-ownbuild all OpenStack Image Registry and Delivery Service - Common ii python-glance 1:2014.2.3-0ownbuild all OpenStack Image Registry and Delivery Service - Python library ii python-glance-store 0.1.8-1ubuntu2~cloud0 all OpenStack Image Service store library - Python 2.x ii python-glanceclient 1:0.14.0-0ubuntu1~cloud0 all Client library for Openstack glance server. Impact: 1) Unprivileged employee with access to logging facility may get access to glance images, including snapshots of the tenants. 2) Syslog transmitted unencrypted in UDP or TCP and it may be viewed by unauthorized person. Expected behavior: Complete or partial token masking in logs, f.e.: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6****************d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470740/+subscriptions From travis.mcpeak at hp.com Thu Jul 2 15:08:02 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Thu, 02 Jul 2015 15:08:02 -0000 Subject: [Openstack-security] [Bug 1470740] Re: swiftclient disclose token in debug logs References: <20150702071356.30766.53174.malonedeb@soybean.canonical.com> Message-ID: <20150702150803.18862.5862.malone@chaenomeles.canonical.com> So just to clarify, what we're basically saying is that logging credentials in DEBUG is not ideal but is also not a vulnerability? If that's the case I'll propose a more general OSSN that essentially says "all confidentiality bets are off when you run services with log level debug". -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1470740 Title: swiftclient disclose token in debug logs Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Notes: New Status in Python client library for Swift: New Bug description: Setup: juno. Nova, glance + swiftclient. glance-api.conf (important parts): [DEFAULT] debug = true logging_context_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s [%(request_id)s %(user)s %(tenant)s] logging_default_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d logging_exception_prefix=%(name)s[%(process)d]: TRACE %(instance)s default_store = swift use_syslog = True syslog_log_facility = LOG_LOCAL2 swift_store_auth_address = https://my.hand.disclosing.corporte.url:5000/v2.0 swift_store_user = tenant:user swift_store_key = sexgodqwerty123456love Result in remote syslog: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6f64276e2074726461650a6d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 Versions: ii python-swift 2.2.0-0ubuntu1~cloud0 all distributed virtual object store - Python libraries ii python-swiftclient 1:2.3.0-0ubuntu1~cloud0 all Client library for Openstack Swift API. ii glance-api 1:2014.2.3-0-ownbuild all OpenStack Image Registry and Delivery Service - API ii glance-common 1:2014.2.3-ownbuild all OpenStack Image Registry and Delivery Service - Common ii python-glance 1:2014.2.3-0ownbuild all OpenStack Image Registry and Delivery Service - Python library ii python-glance-store 0.1.8-1ubuntu2~cloud0 all OpenStack Image Service store library - Python 2.x ii python-glanceclient 1:0.14.0-0ubuntu1~cloud0 all Client library for Openstack glance server. Impact: 1) Unprivileged employee with access to logging facility may get access to glance images, including snapshots of the tenants. 2) Syslog transmitted unencrypted in UDP or TCP and it may be viewed by unauthorized person. Expected behavior: Complete or partial token masking in logs, f.e.: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6****************d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470740/+subscriptions From tdecacqu at redhat.com Thu Jul 2 15:23:12 2015 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Thu, 02 Jul 2015 15:23:12 -0000 Subject: [Openstack-security] [Bug 1470740] Re: swiftclient disclose token in debug logs References: <20150702071356.30766.53174.malonedeb@soybean.canonical.com> Message-ID: <20150702152312.8956.70571.malone@gac.canonical.com> That's it, DEBUG log aren't considered "secure". Seems like OSSN-0049 could cover all openstack services. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1470740 Title: swiftclient disclose token in debug logs Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Notes: New Status in Python client library for Swift: New Bug description: Setup: juno. Nova, glance + swiftclient. glance-api.conf (important parts): [DEFAULT] debug = true logging_context_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s [%(request_id)s %(user)s %(tenant)s] logging_default_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d logging_exception_prefix=%(name)s[%(process)d]: TRACE %(instance)s default_store = swift use_syslog = True syslog_log_facility = LOG_LOCAL2 swift_store_auth_address = https://my.hand.disclosing.corporte.url:5000/v2.0 swift_store_user = tenant:user swift_store_key = sexgodqwerty123456love Result in remote syslog: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6f64276e2074726461650a6d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 Versions: ii python-swift 2.2.0-0ubuntu1~cloud0 all distributed virtual object store - Python libraries ii python-swiftclient 1:2.3.0-0ubuntu1~cloud0 all Client library for Openstack Swift API. ii glance-api 1:2014.2.3-0-ownbuild all OpenStack Image Registry and Delivery Service - API ii glance-common 1:2014.2.3-ownbuild all OpenStack Image Registry and Delivery Service - Common ii python-glance 1:2014.2.3-0ownbuild all OpenStack Image Registry and Delivery Service - Python library ii python-glance-store 0.1.8-1ubuntu2~cloud0 all OpenStack Image Service store library - Python 2.x ii python-glanceclient 1:0.14.0-0ubuntu1~cloud0 all Client library for Openstack glance server. Impact: 1) Unprivileged employee with access to logging facility may get access to glance images, including snapshots of the tenants. 2) Syslog transmitted unencrypted in UDP or TCP and it may be viewed by unauthorized person. Expected behavior: Complete or partial token masking in logs, f.e.: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6****************d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470740/+subscriptions From 1470740 at bugs.launchpad.net Thu Jul 2 15:29:00 2015 From: 1470740 at bugs.launchpad.net (George Shuklin) Date: Thu, 02 Jul 2015 15:29:00 -0000 Subject: [Openstack-security] [Bug 1470740] Re: swiftclient disclose token in debug logs References: <20150702071356.30766.53174.malonedeb@soybean.canonical.com> Message-ID: <20150702152900.4628.51087.malone@wampee.canonical.com> I may agree that local logs with DEBUG is not a big deal, but if use_syslog=True enabled, than, yes, it can cause unexpected consequences. For example, in our real-world installation I just wanted to see debug logs from glance for short time, and I didn't expected to disclose them to low-clearance support personnel, and this was suddenly a BIG issue for our security department. I was forced to write down official explanation about accidental credential disclosure and perform in-house audit of all swift access logs to prove there were no attempts of unauthorized access to snapshots with sensitive data. OSSN is not enough, because it can be necessary to enable debug for service (like glance). Proposal: perform token masking only if logs are sent to syslog. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1470740 Title: swiftclient disclose token in debug logs Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Notes: New Status in Python client library for Swift: New Bug description: Setup: juno. Nova, glance + swiftclient. glance-api.conf (important parts): [DEFAULT] debug = true logging_context_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s [%(request_id)s %(user)s %(tenant)s] logging_default_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d logging_exception_prefix=%(name)s[%(process)d]: TRACE %(instance)s default_store = swift use_syslog = True syslog_log_facility = LOG_LOCAL2 swift_store_auth_address = https://my.hand.disclosing.corporte.url:5000/v2.0 swift_store_user = tenant:user swift_store_key = sexgodqwerty123456love Result in remote syslog: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6f64276e2074726461650a6d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 Versions: ii python-swift 2.2.0-0ubuntu1~cloud0 all distributed virtual object store - Python libraries ii python-swiftclient 1:2.3.0-0ubuntu1~cloud0 all Client library for Openstack Swift API. ii glance-api 1:2014.2.3-0-ownbuild all OpenStack Image Registry and Delivery Service - API ii glance-common 1:2014.2.3-ownbuild all OpenStack Image Registry and Delivery Service - Common ii python-glance 1:2014.2.3-0ownbuild all OpenStack Image Registry and Delivery Service - Python library ii python-glance-store 0.1.8-1ubuntu2~cloud0 all OpenStack Image Service store library - Python 2.x ii python-glanceclient 1:0.14.0-0ubuntu1~cloud0 all Client library for Openstack glance server. Impact: 1) Unprivileged employee with access to logging facility may get access to glance images, including snapshots of the tenants. 2) Syslog transmitted unencrypted in UDP or TCP and it may be viewed by unauthorized person. Expected behavior: Complete or partial token masking in logs, f.e.: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6****************d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470740/+subscriptions From fungi at yuggoth.org Thu Jul 2 16:05:45 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 02 Jul 2015 16:05:45 -0000 Subject: [Openstack-security] [Bug 1470740] Re: swiftclient disclose token in debug logs References: <20150702071356.30766.53174.malonedeb@soybean.canonical.com> Message-ID: <20150702160545.20498.51598.malone@soybean.canonical.com> As a general rule projects should try to mask/redact potentially sensitive information even for DEBUG-level logging, but there are still so many instances of this throughout OpenStack that we rely on recommendations like the red warning box you see at http://docs.openstack.org/developer/horizon/topics/deployment.html#logging to make sure deployers know that setting production service logging to DEBUG or sharing their logs of the same is potentially dangerous. If there is no general OSSN yet with similar recommendations, I agree it's a great addition. So yes I expect this is a bug, and should be fixed to improve the overall security posture of our software, but fixing it won't elicit a security advisory from the vulnerability management team and may not get backported to older releases unless it can be done very, very cleanly to avoid adverse operational impact. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1470740 Title: swiftclient disclose token in debug logs Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Notes: New Status in Python client library for Swift: New Bug description: Setup: juno. Nova, glance + swiftclient. glance-api.conf (important parts): [DEFAULT] debug = true logging_context_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s [%(request_id)s %(user)s %(tenant)s] logging_default_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d logging_exception_prefix=%(name)s[%(process)d]: TRACE %(instance)s default_store = swift use_syslog = True syslog_log_facility = LOG_LOCAL2 swift_store_auth_address = https://my.hand.disclosing.corporte.url:5000/v2.0 swift_store_user = tenant:user swift_store_key = sexgodqwerty123456love Result in remote syslog: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6f64276e2074726461650a6d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 Versions: ii python-swift 2.2.0-0ubuntu1~cloud0 all distributed virtual object store - Python libraries ii python-swiftclient 1:2.3.0-0ubuntu1~cloud0 all Client library for Openstack Swift API. ii glance-api 1:2014.2.3-0-ownbuild all OpenStack Image Registry and Delivery Service - API ii glance-common 1:2014.2.3-ownbuild all OpenStack Image Registry and Delivery Service - Common ii python-glance 1:2014.2.3-0ownbuild all OpenStack Image Registry and Delivery Service - Python library ii python-glance-store 0.1.8-1ubuntu2~cloud0 all OpenStack Image Service store library - Python 2.x ii python-glanceclient 1:0.14.0-0ubuntu1~cloud0 all Client library for Openstack glance server. Impact: 1) Unprivileged employee with access to logging facility may get access to glance images, including snapshots of the tenants. 2) Syslog transmitted unencrypted in UDP or TCP and it may be viewed by unauthorized person. Expected behavior: Complete or partial token masking in logs, f.e.: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6****************d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1470740/+subscriptions From gerrit2 at review.openstack.org Thu Jul 2 16:27:01 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 02 Jul 2015 16:27:01 +0000 Subject: [Openstack-security] [openstack/glance] SecurityImpact review request change I12be91db7b86e335a84c9ebed86dac3ba09051cb Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/197372 Log: commit 6ca3951454945bdd31b1e4c58a427a40b7e63c5f Author: Ian Cordasco Date: Tue Jun 30 18:32:13 2015 -0500 Change default digest_algorithm value to sha256 In I9236cc85f4e9881ac1aa35d69bc6761a59c1b6c8 it was promised that the default for digest_algorithm would change from sha1 to sha256. The sole purpose of this commit is to upgrade the default to sha256 as promised. DocImpact SecurityImpact Change-Id: I12be91db7b86e335a84c9ebed86dac3ba09051cb From nkinder at redhat.com Thu Jul 2 17:49:47 2015 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 02 Jul 2015 17:49:47 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <20150702174948.4319.21021.launchpad@wampee.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Travis McPeak (travis-mcpeak) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Incomplete Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From 1461154 at bugs.launchpad.net Fri Jul 3 02:53:14 2015 From: 1461154 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 03 Jul 2015 02:53:14 -0000 Subject: [Openstack-security] [Bug 1461154] Re: Cross-Frame Scripting (XFS) Clickjacking vulnerability with legacy browsers References: <20150602162757.6123.3584.malonedeb@wampee.canonical.com> Message-ID: <20150703025316.21113.39904.launchpad@soybean.canonical.com> ** Changed in: horizon Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1461154 Title: Cross-Frame Scripting (XFS) Clickjacking vulnerability with legacy browsers Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Security Advisories: Won't Fix Bug description: Vulnerability Details A Cross-Frame Scripting (XFS) vulnerability can allow an attacker to load the vulnerable application inside an HTML iframe tag on a malicious page. Impact An attacker could use XFS to devise a Clickjacking attack to conduct phishing, frame sniffing, social engineering or Cross-Site Request Forgery attacks. Recommendations Set the HTTP X-Frame-Options header to one of the following: DENY - deny any frames SAMEORIGIN - frames are only allowed from the same origin ALLOW-FROM - a list of allowable origin's Although many pages within Horizon 1.1 leverage the X-Frame-Options header with the recommended SAMEORIGIN policy, some (still popular) older browsers don’t support this setting. Namely, browsers older than IE 8 and Firefox 3.6.9 don’t recognize the header and are thus vulnerable to an attack known as ClickJacking unless an additional mitigating control is present. To support legacy browsers, a suggested best practice is to add a frame breaking script to the base/global template file. Based off of https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#Best- for-now_Legacy_Browser_Frame_Breaking_Script """ One way to defend against clickjacking is to include a "frame-breaker" script in each page that should not be framed. The following methodology will prevent a webpage from being framed even in legacy browsers, that do not support the X-Frame-Options-Header. In the document HEAD element, add the following: First apply an ID to the style element itself: And then delete that style by its ID immediately after in the script: This way, everything can be in the document HEAD and you only need one method/taglib in your API. """ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1461154/+subscriptions From gerrit2 at review.openstack.org Fri Jul 3 06:16:23 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 03 Jul 2015 06:16:23 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Icddc7e5cc1c11ab3d272f61a2ef623d3f750030c Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/160206 Log: commit 915af8a15dab45a7f7b6cd062699c74f04da6d43 Author: He Jie Xu Date: Mon Mar 2 08:42:11 2015 +0800 Remove db layer hard-code permission checks for quota_class_create/update This patch removes db layer hard-code permission checks for quota_class_create/update. For v2 API, this patch adds back-comptiable permission checks at REST API layer. For v2.1 API, this patch adds new rule for update method. Partially implements bp nova-api-policy-final-part SecurityImpact UpgradeImpact: Due to the db layer permission checks deleted, the policy rule "os_compute_api:os-quota-class-sets:update" was updated with a default that match the permission as before. Admin should be notified to update their policy configuration to keep permission as before. Change-Id: Icddc7e5cc1c11ab3d272f61a2ef623d3f750030c From gerrit2 at review.openstack.org Fri Jul 3 06:16:30 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 03 Jul 2015 06:16:30 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I02da6cc8c766e5f43689449ef63121122f537b5b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/160205 Log: commit eb40429b44f01ed6fed9e52ed4b84f96e8332d8f Author: He Jie Xu Date: Mon Mar 2 08:08:44 2015 +0800 Remove db layer hard-code permission checks for quota_class_get_all_by_name This patch removes the hard-code permission checks for db call quota_class_get_all_by_name. For v2 api, there already have same hard-code permission checks in REST API layer, so it is back-compatible. For v2.1 api, to distinguish show and update permission, this patch adds new rule for show method. Partially implements bp nova-api-policy-final-part SecurityImpact UpgradeImpact: Due to the db layer permission checks deleted, they need default policy rule instead of that. In this patch, "os_compute_api:os-quota-class-sets:show" was updated with a default rule. Admin will be notfied to update their policy configure file to keep the behavior as before. Change-Id: I02da6cc8c766e5f43689449ef63121122f537b5b From gerrit2 at review.openstack.org Fri Jul 3 07:51:15 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 03 Jul 2015 07:51:15 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ibddf3529a219cb9a0c1d4cfdb89327b53454c436 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/150710 Log: commit 4d6a50ab3e61e2ae550973fdcc110eff97847190 Author: ShaoHe Feng Date: Mon Mar 2 22:26:12 2015 +0800 Remove db layer hard-code permission checks for floating_ip_dns This patches removes db layer hard-code permission checks for floating_ip_dns. Partially implements bp nova-api-policy-final-part SecurityImpact UpgradeImpact: Due to the db layer permission checks are removed, we need to add default policy rule into policy file. In this patch, "os_compute_api:os-floating-ip-dns:domain:update" and "os_compute_api:os-floating-ip-dns:domain:delete" were updated with a default rule. Admin will be notfied to update their policy configure file to keep the behavior as before. Change-Id: Ibddf3529a219cb9a0c1d4cfdb89327b53454c436 From email at daviey.com Fri Jul 3 10:05:06 2015 From: email at daviey.com (Dave Walker) Date: Fri, 03 Jul 2015 10:05:06 -0000 Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not work References: <20140612080140.21505.11780.malonedeb@gac.canonical.com> Message-ID: <20150703100506.4078.85411.malone@wampee.canonical.com> @steve.westom: The OSSN task is assigned to you, are you still working on this? Thanks -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329214 Title: tgtadm iscsi chap does not work Status in Cinder: Fix Released Status in OpenStack Security Notes: In Progress Bug description: When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume has record chap user and chap passwd. By testing, I found that tgtadm iscsi chap does not work. Is it a security bug for iscsi_helper tgtadm? My detail test work is as follows. 1. Test details as follows without modify the source code: 1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191) 2) create a vm VM-A and a cinder volume VOLUME-A, attach VOLUME-A to VM-A 3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . iscsiadm -m discovery -t sendtargets -p 10.250.10.190 iscsiadm -m node -T iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login 2. Test details as follows with modify the source code: 1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. type, name, passwd = chap_auth.split() self._execute('tgtadm', '--lld', 'iscsi', '--mode', 'account', '--op', 'new', '--user', name, '--password', passwd) self._execute('tgtadm', '--lld', 'iscsi', '--mode', 'account', '--op', 'bind', '--tid', tid, '--user', name ) 2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows. root at devaio1:/etc/iscsi# iscsiadm -m node -T iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple) iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260]. iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure) iscsiadm: Could not log into all portals To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1329214/+subscriptions From 1447673 at bugs.launchpad.net Sun Jul 5 04:25:14 2015 From: 1447673 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Sun, 05 Jul 2015 04:25:14 -0000 Subject: [Openstack-security] [Bug 1447673] Re: session ID reusable? References: <20150423154006.13687.43783.malonedeb@wampee.canonical.com> Message-ID: <20150705042516.5836.53558.malone@loganberry.canonical.com> [Expired for Keystone because there has been no activity for 60 days.] ** Changed in: keystone Status: Incomplete => Expired -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1447673 Title: session ID reusable? Status in OpenStack Identity (Keystone): Expired Status in OpenStack Security Advisories: Won't Fix Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments. Reported via private E-mail from Anass ANNOUR: I had tested to reply the session ID and the token to a local environnent between to distinct IP, and it worked perfectly. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1447673/+subscriptions From gerrit2 at review.openstack.org Mon Jul 6 03:00:32 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 06 Jul 2015 03:00:32 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ic0780a0d1ccf96c14f1e0ad9c3e9b23e2b0db0ea Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/188235 Log: commit cd2efa37282fd623312b08441f7eb1a576340d6e Author: Eli Qiao Date: Thu Jun 4 10:05:33 2015 +0800 Add missing rules in polcy.json 'etc/nova/policy.json' is sample file for polcy configration. But there are a lot of rule missing in it. The user is hard to find out which rule can be used in nova. This patch adds the missing rule back to policy.json. Also adds a test case to veify the contents of policy. SecurityImpact UpgradeImpact: "os_compute_api:servers:create:forced_host" is missing in policy.json. That means it will be default rule. But actually it should be admin only API. After deployer should update their policy.json to match the original permission. Co-Authored-By: Alex Xu Closes-Bug: #1435390 Change-Id: Ic0780a0d1ccf96c14f1e0ad9c3e9b23e2b0db0ea From gerrit2 at review.openstack.org Mon Jul 6 03:01:44 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 06 Jul 2015 03:01:44 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ic0780a0d1ccf96c14f1e0ad9c3e9b23e2b0db0ea Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/188235 Log: commit 85fb9c5b21b2b3b090b07b24ad08dd366202ca45 Author: Eli Qiao Date: Thu Jun 4 10:05:33 2015 +0800 Add missing rules in polcy.json 'etc/nova/policy.json' is sample file for polcy configration. But there are a lot of rule missing in it. The user is hard to find out which rule can be used in nova. This patch adds the missing rule back to policy.json. Also adds a test case to veify the contents of policy. SecurityImpact UpgradeImpact: "os_compute_api:servers:create:forced_host" is missing in policy.json. That means it will be default rule. But actually it should be admin only API. This patch adds this rule back to policy.json and with correct rule. Deployer should update their policy.json to match the original permission also. Co-Authored-By: Alex Xu Closes-Bug: #1435390 Change-Id: Ic0780a0d1ccf96c14f1e0ad9c3e9b23e2b0db0ea From gerrit2 at review.openstack.org Mon Jul 6 06:08:19 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 06 Jul 2015 06:08:19 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Icddc7e5cc1c11ab3d272f61a2ef623d3f750030c Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/160206 Log: commit 9e8ed393a63ce12eb4a345d31c2dcbf1b3bb572d Author: He Jie Xu Date: Mon Mar 2 08:42:11 2015 +0800 Remove db layer hard-code permission checks for quota_class_create/update This patch removes db layer hard-code permission checks for quota_class_create/update. For v2 API, this patch adds back-comptiable permission checks at REST API layer. For v2.1 API, this patch adds new rule for update method. Partially implements bp nova-api-policy-final-part SecurityImpact UpgradeImpact: Due to the db layer permission checks deleted, the policy rule "os_compute_api:os-quota-class-sets:update" was updated with a default that match the permission as before. Admin should be notified to update their policy configuration to keep permission as before. Change-Id: Icddc7e5cc1c11ab3d272f61a2ef623d3f750030c From gerrit2 at review.openstack.org Mon Jul 6 21:16:25 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 06 Jul 2015 21:16:25 +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 3ce00ab55ad54e1a7fc901ce064fe06c7e9be66f Author: Daniel Genin Date: Thu Feb 5 09:28:16 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. Co-Authored-By: Joel Coffman Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From 1192966 at bugs.launchpad.net Tue Jul 7 00:19:59 2015 From: 1192966 at bugs.launchpad.net (John Dickinson) Date: Tue, 07 Jul 2015 00:19:59 -0000 Subject: [Openstack-security] [Bug 1192966] Re: Potentially insecure dependency loading References: <20130620132537.19232.33035.malonedeb@gac.canonical.com> Message-ID: <20150707002002.18499.74274.launchpad@chaenomeles.canonical.com> ** Changed in: swift Status: New => Invalid -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1192966 Title: Potentially insecure dependency loading Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy and Dhiru Kholia from Red Hat Product Security Team reported the following potential issue. This is actually a setuptools issue but which we may be able to workaround, if we end up being affected: --- A security flaw was found in the way Python Setuptools, a collection of enhancements to the Python distutils module, that allows more easily to build and distribute Python packages, performed integrity checks when loading external resources, previously extracted from zipped Python Egg archives(formerly if the timestamp and file size of a particular resource expanded from the archive matched the original values, the resource was successfully loaded). A local attacker, with write permission into the Python's EGG cache (directory) could use this flaw to provide a specially-crafted resource (in expanded form) that, when loaded in an application requiring that resource to (be able to) run, would lead to arbitrary code execution with the privileges of the user running the application. It seems to be pretty common for Python applications to do something like os.evironment['PYTHON_EGG_CACHE'] = /tmp, prior to importing dependencies. If the dependency contains a .so Python must unpack it into the cache directory to be able to load it. However if an attacker pre-emptively places a .so in the same location as long as the file has the same timestamp and file size it will be loaded. --- Glance and Swift both set PYTHON_EGG_CACHE to '/tmp' : ./glance/glance/cmd/control.py: os.environ['PYTHON_EGG_CACHE'] = '/tmp' ./swift/swift/common/manager.py: os.environ['PYTHON_EGG_CACHE'] = '/tmp' If we are immediately vulnerable to this (i.e. if stuff loaded from those commands contains an .so, if I understand correctly), we could workaround it by setting it to /tmp/secure-dir-XXXXXX/ until setuptools upstream fixes this. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1192966/+subscriptions From gerrit2 at review.openstack.org Tue Jul 7 05:59:15 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 07 Jul 2015 05:59:15 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/192986 Log: commit baa8688c9cac5b52b0335028b6be65c515f8b55c Author: abhishekkekane Date: Mon Jul 6 01:51:26 2015 -0700 libvirt: Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added new module instancejobtracker to libvirt driver which will add, remove or terminate the processes running against particular instances. Added callback methods to execute call which will store the pid of scp/rsync process in cache as a key: value pair and to remove the pid from the cache after process completion. Process id will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Closes-bug: #1387543 Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 From kevin.carter at rackspace.com Tue Jul 7 13:51:10 2015 From: kevin.carter at rackspace.com (Kevin Carter) Date: Tue, 07 Jul 2015 13:51:10 -0000 Subject: [Openstack-security] [Bug 1466216] Re: Upgrade to ansible 1.9.2 when released References: <20150617203545.4905.22166.malonedeb@wampee.canonical.com> Message-ID: <20150707135112.21113.81479.launchpad@soybean.canonical.com> ** Changed in: openstack-ansible/trunk Status: Fix Committed => Fix Released ** Changed in: openstack-ansible/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1466216 Title: Upgrade to ansible 1.9.2 when released Status in Ansible playbooks for deploying OpenStack: Fix Released Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible trunk series: Fix Released Bug description: Ansible 1.9.2 (unreleased) fixed a CVE-2015-3908 that affected usage of get_url. The vulnerability is related to allowing an HTTPS connection to be MITM'd. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1466216/+subscriptions From 1274034 at bugs.launchpad.net Tue Jul 7 17:19:32 2015 From: 1274034 at bugs.launchpad.net (Chet Burgess) Date: Tue, 07 Jul 2015 17:19:32 -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: <20150707171932.9699.41927.malone@gac.canonical.com> kevinbenton, Excellent! Thanks for the patch. Just to confirm it looks like your patch is a complete solution and the the previously merged pieces of jbrendel's work are not necessary for your fix? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From 1274034 at bugs.launchpad.net Tue Jul 7 22:32:54 2015 From: 1274034 at bugs.launchpad.net (Kevin Benton) Date: Tue, 07 Jul 2015 22:32:54 -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: <20150707223254.14154.84897.malone@wampee.canonical.com> Yes, this patch does not depend on the ebtables manager work because I wanted it to be able apply to older codebases. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From 1274034 at bugs.launchpad.net Wed Jul 8 20:40:13 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 08 Jul 2015 20:40:13 -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: <20150708204015.4578.39371.launchpad@gac.canonical.com> ** Changed in: neutron Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, 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): Fix Committed 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 email at daviey.com Wed Jul 8 21:04:06 2015 From: email at daviey.com (Dave Walker) Date: Wed, 08 Jul 2015 21:04:06 -0000 Subject: [Openstack-security] [Bug 1434034] Re: Disabling users & groups may not invalidate previously-issued tokens References: <20150319111325.13509.80712.malonedeb@wampee.canonical.com> Message-ID: <20150708210408.13862.74039.launchpad@soybean.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Dave Walker (davewalker) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1434034 Title: Disabling users & groups may not invalidate previously-issued tokens Status in OpenStack Identity (Keystone): In Progress Status in Keystone juno series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Confirmed Bug description: Even if the user is disabled, can use the last token is validated. 0. user foo is enable 1. get token (a) 2. user foo is disabled 3. foo can still use any APIs by token(a) that's all. This issue is not cache process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1434034/+subscriptions From email at daviey.com Wed Jul 8 21:41:10 2015 From: email at daviey.com (Dave Walker) Date: Wed, 08 Jul 2015 21:41:10 -0000 Subject: [Openstack-security] [Bug 1435530] Re: keystonemiddleware without TRL checking and default cache config can allow access after token revocation References: <20150323201925.7521.48815.malonedeb@chaenomeles.canonical.com> Message-ID: <20150708214112.13423.21754.launchpad@soybean.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Dave Walker (davewalker) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1435530 Title: keystonemiddleware without TRL checking and default cache config can allow access after token revocation Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: *** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call *** Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user). Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used. This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions From 1472331 at bugs.launchpad.net Thu Jul 9 10:21:05 2015 From: 1472331 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 09 Jul 2015 10:21:05 -0000 Subject: [Openstack-security] [Bug 1472331] Re: Trust id is not hidden in logs References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Message-ID: <20150709102105.14750.72118.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/199407 Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=8933765635d01c2bcc3f6679e0ab8c0b9e448a3b Submitter: Jenkins Branch: master commit 8933765635d01c2bcc3f6679e0ab8c0b9e448a3b Author: Lin Yang Date: Wed Jul 8 13:53:15 2015 +0800 Hide TrustId in log to tighten up security Current the value of TrustId is showed in plaintext in log when murano creates trustes and operates with data. So add 'trustid' in token_sanitizer to hide it like token and pass. Closes-Bug: #1472331 Change-Id: I1e9ea8298a7ffd9aa742cf73fada69db3a734712 ** Changed in: murano Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472331 Title: Trust id is not hidden in logs Status in Murano: Fix Committed Bug description: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1472331/+subscriptions From fungi at yuggoth.org Thu Jul 9 13:37:57 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 09 Jul 2015 13:37:57 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150709133757.15279.18291.malone@soybean.canonical.com> We normally don't increase upper bounds on requirements in stable branches. Does horizon 2014.2.x actually work with Django 1.8? If not, is it possible to modify it to work without significant risk of introducing new regressions and behavior changes? This is primarily a concern for people continuously deploying stable/juno from source. Any distributions which packaged 2014.2 will almost certainly have security fixes backported to the release of Django they're shipping rather than upgrading to a later Django release. Anyway, these are conversations which can be had in public now that we won't be disclosing the Django vulnerability by opening this bug report. ** 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, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From travis.mcpeak at hp.com Thu Jul 9 15:31:57 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Thu, 09 Jul 2015 15:31:57 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150709153157.13996.75395.malone@soybean.canonical.com> OSSN seems appropriate for this once we have guidance for a proper approach to mitigating this. ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From 1457551 at bugs.launchpad.net Thu Jul 9 15:47:30 2015 From: 1457551 at bugs.launchpad.net (Matthias Runge) Date: Thu, 09 Jul 2015 15:47:30 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150709154730.14391.16021.malone@wampee.canonical.com> We can not increase upper bounds here. I agree, Debian shipped 2014.2 with django-1.7, but e.g for Django- openstack-auth we just recently increased the upper cap to include django-1.7. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From 1274034 at bugs.launchpad.net Thu Jul 9 15:56:50 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 09 Jul 2015 15:56:50 -0000 Subject: [Openstack-security] [Bug 1274034] Fix proposed to neutron (feature/pecan) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150709155650.14915.37093.malone@wampee.canonical.com> Fix proposed to branch: feature/pecan Review: https://review.openstack.org/200163 -- You received this bug notification because you are a member of OpenStack Security, 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): Fix Committed Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From gerrit2 at review.openstack.org Thu Jul 9 17:12:32 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 09 Jul 2015 17:12:32 +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 64613426bc281c8adb3b203f83505d76a02d9e4c Author: Daniel Genin Date: Thu Feb 5 09:28:16 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. Co-Authored-By: Joel Coffman Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From 1472057 at bugs.launchpad.net Thu Jul 9 17:14:16 2015 From: 1472057 at bugs.launchpad.net (Dolph Mathews) Date: Thu, 09 Jul 2015 17:14:16 -0000 Subject: [Openstack-security] =?utf-8?q?=5BBug_1472057=5D_Re=3A_in_the_fun?= =?utf-8?q?ction_of_create=5Ftrust=2Cthe_judgment_for_=E2=80=9Cremaining?= =?utf-8?q?=5Fuses=E2=80=9D_can_be_deleted?= References: <20150707025110.4498.59793.malonedeb@wampee.canonical.com> Message-ID: <20150709171416.4815.39522.malone@gac.canonical.com> As in, remaining_uses is mutable? ** Information type changed from Public to Public Security ** Changed in: keystone Importance: Undecided => High ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472057 Title: in the function of create_trust,the judgment for “remaining_uses” can be deleted Status in OpenStack Identity (Keystone): Incomplete Bug description: In the function of create_trust (Corresponding file is:/keystone/trust/core.py),the judgment for “remaining_uses” can be deleted, because controller has registered a schema to validate a resource reference. if not redelegatable: trust['redelegation_count'] = requested_count = 0 remaining_uses = trust.get('remaining_uses') if remaining_uses is not None and remaining_uses <= 0: # i think this judgment redundancy msg = _('remaining_uses must be a positive integer or null.') raise exception.ValidationError(msg) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1472057/+subscriptions From 1472057 at bugs.launchpad.net Thu Jul 9 17:16:49 2015 From: 1472057 at bugs.launchpad.net (Dolph Mathews) Date: Thu, 09 Jul 2015 17:16:49 -0000 Subject: [Openstack-security] =?utf-8?q?=5BBug_1472057=5D_Re=3A_in_the_fun?= =?utf-8?q?ction_of_create=5Ftrust=2Cthe_judgment_for_=E2=80=9Cremaining?= =?utf-8?q?=5Fuses=E2=80=9D_can_be_deleted?= References: <20150707025110.4498.59793.malonedeb@wampee.canonical.com> Message-ID: <20150709171649.14426.62594.malone@wampee.canonical.com> Oh, I think I misunderstood this on the first read. You're just saying that this line: if remaining_uses is not None and remaining_uses <= 0: ... could be simplified? There doesn't seem to be any security implication with that. ** Information type changed from Public Security to Public ** Tags removed: security ** Changed in: keystone Importance: High => Low ** Changed in: keystone Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472057 Title: in the function of create_trust,the judgment for “remaining_uses” can be deleted Status in OpenStack Identity (Keystone): Incomplete Bug description: In the function of create_trust (Corresponding file is:/keystone/trust/core.py),the judgment for “remaining_uses” can be deleted, because controller has registered a schema to validate a resource reference. if not redelegatable: trust['redelegation_count'] = requested_count = 0 remaining_uses = trust.get('remaining_uses') if remaining_uses is not None and remaining_uses <= 0: # i think this judgment redundancy msg = _('remaining_uses must be a positive integer or null.') raise exception.ValidationError(msg) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1472057/+subscriptions From 1457551 at bugs.launchpad.net Thu Jul 9 18:55:46 2015 From: 1457551 at bugs.launchpad.net (Lin Hua Cheng) Date: Thu, 09 Jul 2015 18:55:46 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150709185546.28773.50828.malone@chaenomeles.canonical.com> @pkarikh: We don't support Django 1.8 yet, working on it on L release. @fungi: It might be too risky to backport the changes to stable branch. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From 1274034 at bugs.launchpad.net Thu Jul 9 20:03:02 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 09 Jul 2015 20:03:02 -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: <20150709200302.4778.56101.malone@gac.canonical.com> Reviewed: https://review.openstack.org/200163 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ec799c458976d5bdc03f36fa4bf56c8ca0160614 Submitter: Jenkins Branch: feature/pecan commit a0a022373b90835059b8949a57b097030bcbc37e Author: John Davidge Date: Tue Jul 7 17:00:01 2015 +0100 Fix issues with allocation pool generation for ::/64 cidr Passing a ::/64 cidr to certain netaddr functions without specifying the ip_version causes errors. Fix this by specifying ip_version. Change-Id: I31aaf9f5dabe4dd0845507f245387cd4186c410c Closes-Bug: 1472304 commit c28b6b0ef8606abea00eeea4fde96a4f646da952 Author: Brian Haley Date: Tue Jul 7 17:03:04 2015 -0400 Remove lingering traces of q_ The rename from Quantum to Neutron left a few q_ strings around, let's go ahead and clean them up. Change-Id: I06e6bdbd0c2f3a25bb90b5fa291009b9ec2d471d commit 5b6ca5ce898a2e9a810ec49a1712337a41822788 Author: armando-migliaccio Date: Tue Jul 7 11:13:41 2015 -0700 Make sure path_prefix is set during unit tests Change 18bc67d5 broke *-aas unit tests. This change ensures that mocking is done correctly, the same way it is done for the other plugin attributes Change-Id: I4167f18560e3a3aad652aae1ea9d3c6bc34dc796 Closes-bug: #1472361 commit 13b0f6f8e2fd1e84ff3580cd75bb879e18064da6 Author: Carl Baldwin Date: Tue Jul 7 16:41:03 2015 +0000 Add IP_ANY dict to ease choosing between IPv4 and IPv6 "any" address I'm working on a new patch that will add one more case where we need to choose between 0.0.0.0/0 and ::/0 based on the ip version. I thought I'd add a new constant and simplify a couple of existing uses. Change-Id: I376d60c7de4bafcaf2387685ddcc1d98978ce446 commit a863342caf7da9a1c0430549c1ea1e53408b34af Author: Cyril Roelandt Date: Tue Jul 7 14:25:06 2015 +0000 Python3: cast the result of zip() to list The result of get_sorts was a 'zip object' in Python 3, and it was later used as a list, which fails. Just cast the result to a list to fix this issue. Change-Id: I12017f79cad92b1da4fe5f9939b38436db7219eb Blueprint: neutron-python3 commit 8b13609edac2c136e1a0acbc05ad93059bb59fc1 Author: Pavel Bondar Date: Thu Jul 2 11:35:18 2015 +0300 Track allocation_pools in SubnetRequest To keep pluggable and non-pluggable ipam implementation consistent non-pluggable one has to be switched to track allocation_pools and gateway_ip using SubnetRequests. SubnetRequest requires allocation_pools to be list of IPRanges. Previously allocation_pools were tracked as list of dicts. So allocation_pools generating and validating was moved before SubnetRequest is created. Partially-Implements: blueprint neutron-ipam Change-Id: I8d2fec3013b302db202121f946b53a0610ae8321 commit 04197bc4bbf2bc611371060db839028c2686f87a Author: Kevin Benton Date: Mon Jun 29 21:05:08 2015 -0700 Add ARP spoofing protection for LinuxBridge agent This patch adds ARP spoofing protection for the Linux Bridge agent based on ebtables. This code was written to be minimally invasive with the intent of back-porting to Kilo. The protection is enabled and disabled with the same 'prevent_arp_spoofing' agent config flag added for the OVS agent in I7c079b779245a0af6bc793564fa8a560e4226afe. The protection works by setting up an ebtables chain for each port and jumping all ARP traffic to that chain. The port-specific chains have a default DROP policy and then have allow rules installed that only allow ARP traffic with a source CIDR that matches one of the port's fixed IPs or an allowed address pair. Closes-Bug: #1274034 Change-Id: I0b0e3b1272472385dff060897ecbd25e93fd78e7 commit 18bc67d56faef30a0f73429a5ee580e052858cb5 Author: armando-migliaccio Date: Thu Jul 2 12:56:24 2015 -0700 COMMON_PREFIXES cleanup - patch 5/5 Get rid of COMMON_PREFIXES, as now the prefix is a service's declaritive property. Change-Id: I3d306131df94188f75e69edb13d262721d10bee5 Depends-on: I0450d0b2bf409d470a3a87bfd96518939759a84e Depends-on: Ia34695967cbbec0a1cf0884dad82e096de8539b8 Depends-on: Ib9517b772fe426eaf0809c439aa3ba0448c7abaa commit f9e9de9f810f2752d295a379459b9a93aa01ee4d Author: Carl Baldwin Date: Tue Jun 30 20:22:46 2015 +0000 Refactor init_l3 to separate router port use case Future work will extend init_l3 with more code specific to router ports. It makes sense to separate these out in to one basic method with basic L3 and another for router port specific logic. Change-Id: Iec9a46cd0490c4f48bb306083711ff0c5e70ba87 Partially-Implements: blueprint address-scopes commit b510dd5c2e4eb6c33be1e047e00991ce51d6aec0 Author: Henry Gessau Date: Mon Jun 1 13:52:18 2015 -0400 Devref for out-of-tree plugin/driver contribution Change-Id: I6198acce97409e0e87520a31f2749b62d607e9c1 commit d269657089e93e304a33dcbc35b7c4abc6e9900d Author: Cyril Roelandt Date: Fri Jul 3 15:58:03 2015 +0000 Python3: do not add dict_values objects In Python 3, dict.values returns a dict_values object instead of a list. Change-Id: I83bc7718ac9bbb64187fefae57ce835fbe225829 Blueprint: neutron-python3 commit efa1f16706c9d44c654be411e9bf0c1c8f670801 Author: YAMAMOTO Takashi Date: Thu Jul 2 17:33:24 2015 +0900 portsecurity_db_common: Access db columns in a consistent way While db columns and api attribute happen to have same name here, it's still better to distinguish them. Change-Id: I6d6e649925a41d89fd74ca5e64290737c9baed9a commit a76090161fba69329389d4b8e3389f4797293ba9 Author: Cyril Roelandt Date: Wed Jul 1 22:29:12 2015 +0000 Python 3: do not index dict_keys objects This cannot be done in Python 3, where dict.keys() returns an iterator. We need to cast the result of dict.keys() to a list first. Change-Id: I28986aefb720b4513e3eee9ba0909f79d1dc9695 Blueprint: neutron-python3 commit 26f50761efaa5bc362e35a41f0adc458e0224296 Author: Kevin Benton Date: Fri Jun 26 10:00:42 2015 -0700 Update DVR agent to use get_vifs_by_id The new get_vifs_by_id function retrieves all of the VIFs for a port iteration at once to eliminate unnecessary multiple calls to OVSDB. Change-Id: If18557faead836121bfa3b4e6efccd0318ce72d3 Related-Bug: #1460233 commit 59ae35ba8fa6f4b79a1370c32faaa1ae4fce3f37 Author: armando-migliaccio Date: Thu Jul 2 12:06:05 2015 -0700 COMMON_PREFIXES cleanup - patch 1/5 This dictionary does not belong to the plugins directory as it captures API business, but practically speaking it does not even deserve to exist and can be removed altogether. This is patch one in a series that aims at addressing this monkey business. Change-Id: I95cd71dfc35e266f6f3cc5715ab8a0deb10058e7 commit 9aaa2befdece5036fb8a6c3bdee6290d3658745d Author: armando-migliaccio Date: Wed Jul 1 19:46:16 2015 -0700 Fall back on empty path if prefix is missing A missing entry causes a KeyError that leads the server to blow up during startup. We can fallback on an empty path (like some services do), in case the prefix is not specified. Furthermore, we can be declarative with this property, the same way we are with properties like aliases, bulk support, etc. Change-Id: I58a9b90a39d434f4808264aeb6f9ee5aceff7fbd commit 7a73c2d0f87bb269d0cced1847edce4d1e76179e Author: Carl Baldwin Date: Tue Jun 30 20:23:39 2015 +0000 Refactor IpRuleCommand to take more arguments The iproute2 rule command takes more arguments than the ones supported by this wrapper. Particularly, for address scopes, we're interested in iif and fwmark. Instead of adding these piecemeal, this change makes the wrapper flexible to pass any of them using kwargs. Callers of add / delete are updated to pass keyword arguments for table and priority since they are no longer required positional arguments. This looks better anyway. Change-Id: Ia93b086b787c34bd560961cb84e4a003cf359e7e Partially-Implements: blueprint address-scopes commit d06990b8a548a63df5e50e9e75b59a5bbe0ba5b0 Author: Ihar Hrachyshka Date: Thu Jul 2 18:42:07 2015 +0300 Start documenting potential API breakages in devref:neutron_api Change-Id: I2ceb9e347ea0687e93b766d58601cd86561d1e2b commit 23b5806932cf0c890a8ba665148abeb5dce53755 Author: Ihar Hrachyshka Date: Thu Jul 2 18:32:42 2015 +0300 devref: document API status for neutron.openstack.common.* Make sure we document the fact that neutron.openstack.common.* contents are not meant to be used by external repositories (except, temporarily, *aas repos). If I could bootstrap the oslo-incubator subtree from scratch, I would put it under neutron._openstack, to indicate that it's for internal usage only. But we can't do it now, so instead I update devref. Change-Id: I42252a7b0a07759c57995b2fc1f8d20ecba7d33b commit 1e5ef92f6af7b1a7c9d9221110a1e0accf2b4405 Author: Cyril Roelandt Date: Wed Jul 1 19:16:43 2015 +0000 Python3: do not use urllib.urlencode It has been moved in Python3. Use six.moves to have code that works with both Python 2 and 3. Change-Id: I5f286b1f784b3b7bb37852b00169a6c1227eb74b Blueprint: neutron-python3 commit e173a31e3b04daf6385813539a163ccb73e24efd Author: Oleg Bondarev Date: Thu Jul 2 12:18:47 2015 +0300 DVR: remove unused method Change-Id: I9d13993d899e2947c5f025100c98ee8934cc5c5d commit 55cb8e4026f025a351896909ba6fa05e3f882003 Author: Kevin Benton Date: Thu Jul 2 00:16:51 2015 -0700 OVS native DBListcommand if_exists support Add support for the if_exists flag to the OVS native db list command. Closes-Bug: #1470742 Closes-Bug: #1470894 Change-Id: Ife48d99c145cfab7f0f5523f4cdfd33492085355 commit 06d6012e3e379f774e190203f4f6f32c20704daa Author: Pavel Bondar Date: Thu Jun 25 16:32:22 2015 +0300 Collapse create_subnet into single method Previously create_subnet called different methods for subnet allocation with subnetpool and without it. _create_subnet_from_implicit_pool and _create_subnet_from_pool were collapsed into single method _create_subnet. This is intermediate step for supporting pluggable ipam. Partially-Implements: blueprint neutron-ipam Change-Id: Ia6cfc2c15e29f983a623772f5473166c075a20e4 commit 197aa10487d6cf8081099f33aae1ec7efe4f9545 Author: Kevin Benton Date: Thu Jul 2 01:45:46 2015 -0700 Downgrade log level for gone port on status update If a port is deleted immediately before a status update arrives from the L2 agent, the port will be missing from the DB. The current code was logging this at the warning level, but this occurs during normal operations so it should only be a debug event. Change-Id: I22af81e6807bfccb4c906ec0873fcbfca67b72df commit cbd95318ad6c44e72a3aa163f7a399353c8b4458 Author: vikram.choudhary Date: Tue Jun 9 19:55:59 2015 +0530 Support Basic Address Scope CRUD as extensions This patch adds the support for basic address scope CRUD. Subsequent patches will be added to use this address scope on subnet pools. DocImpact APIImpact Co-Authored-By: Ryan Tidwell Co-Authored-By: Numan Siddique Change-Id: Icabdd22577cfda0e1fbf6042e4b05b8080e54fdb Partially-implements: blueprint address-scopes commit 5e11769e498f210b1c84a6addaffecb7db9c5fed Author: armando-migliaccio Date: Wed Jul 1 18:01:10 2015 -0700 Use EXT_TO_SERVICE_MAPPING instead of ALLOWED_SERVICES We can derive the services from EXT_TO_SERVICE_MAPPING, therefore there is no need for duplicating the service labels into ALLOWED_SERVICES. Change-Id: If92e0ea3dea4480588141a2819ea4036c527c9bc commit f1771131a85a2fe633126f354364205554ef71d1 Author: Kevin Benton Date: Wed Jul 1 13:06:38 2015 -0700 Change the half of the bridge name used for ports The code to generate the names of the patch ports was based on a chunk of the bridge name starting from the beginning. With the long suffix, this ended up excluding all of the random characters in the name. (e.g. br-int374623235 would create an interface br-in-patch-tun). This meant that if two tests using patch interfaces ran together, they would have a name collision and one would fail. This patch updates the patch port name generation to use the randomized back portion of the name. Change-Id: I172e0b2c0b53e8c7151bd92f0915773ea62c0c6a Closes-Bug: #1470637 commit 49569327c20d8a10ba3d426833ff28d68b1b7a27 Author: armando-migliaccio Date: Wed Jul 1 12:00:14 2015 -0700 Fix log traces induced by retry decorator Patch 4e77442d5 added a retry decorator to the API layer to catch DB deadlock errors. However, when they occur, the retried operation ends up being ineffective because the original body has been altered, which leads the notification and validation layers to barf exceptions due to unrecognized/unserializable elements. This ultimately results to an error reported to the user. To address this, let's make a deep copy of the request body, before we pass it down to the lower layers. This allows the decorator to work on a pristine copy of the body on every attempt. The performance impact for this should be negligible. Closes-bug: #1470615 Change-Id: I82a2a002612d28fa8f97b0afbd4f7ba1e8830377 commit abb7124a518823616c22afbd6bb5fe412b395bcd Author: Assaf Muller Date: Mon Jun 29 14:02:29 2015 -0400 Remove unused linux bridge agent configuration options This is cruft left from the Linux bridge monolithic plugin, or from pre-Havana versions of the code. Change-Id: Id7bb7d7860859283b53f588a940ca21c94fd0e6a commit fc472397016c6958e7e02808ac3bc43216e21a62 Author: Pavel Bondar Date: Wed Jun 24 12:25:22 2015 +0300 Fixing indentation and typo in comments - Fix strange indentation - Fix typo in comment Change-Id: I70893bc751c16265a8c3b3214524ab2553f4f30f commit cf8c9e40c8720036bd0c06bd8370f88a472e3e6f Author: Fawad Khaliq Date: Tue Jun 30 02:17:19 2015 -0700 Update PLUMgrid plugin information README was quite oudated and created confusion among users. Updated the information after decomposition. Change-Id: I78bf8dec20ba2ceb644d4565035d29bbf53cb3b5 commit 7344e3ab8e3d4fd8af5b6f85184a0c093d88b6a4 Author: Robert Collins Date: Tue Jun 30 09:40:17 2015 +1200 Improve fixture usage. There were two broad issues with fixtures. Firstly, the 'SafeFixture' workaround for resource leaks in fixtures <1.3 is not needed if we depend on fixtures>=1.3.1. While testtools may raise a TypeError when trying to query a fixture that failed to setup, this is only ever a cascading failure - it will not cause tests to fail, cause leaks, or cause tests to incorrectly pass. That will be fixed in testtools soon to stop it happening (but as it cannot affect whether a test passes or fails or leaks happen there is no reason to wait for that). Leaks are seen with fixtures 1.3.0 still because eventlet raises a BaseException subclass rather than an Exception subclass, and fixtures 1.3.0 didn't handle that - 1.3.1 does. Secondly, some of the fixtures had race conditions where things were started and then cleanups scheduled. Where possible I've fixed those, but some of them require more significant work to fully address. Change-Id: I3290712f7274970defda19263f4955e3c78e5ed6 Depends-On: I8c01506894ec0a92b53bc0e4ad14767f2dd6a6b3 Closes-bug: #1453888 commit 3da491cf5fe629559281507f65f12a0e34eaedf7 Author: Assaf Muller Date: Tue Jun 30 13:22:17 2015 -0400 Disable pylint job Disabling pylint until it gets unbroken. Pylint 1.4.1 is using logilab-common, which had a release on the 30th, breaking pylint. Pylint developers are planning a logilab-common release tomorrow which should unbreak pylint once again, at which point I'll re-enable pylint. Change-Id: I5d8aaab8192168946c2a0b74abc1a56848ca51a2 Related-Bug: #1470186 commit 8dd8a7d93564168b98fa2350eedf56acede42b0f Author: Sean M. Collins Date: Tue Jun 30 12:06:07 2015 -0400 Remove bridge cleanup call Remove the bridge cleanup call to delete bridges, since we are seeing race conditions where bridges are deleted, then new interfaces are created and are attempting to plug into the bridge before it is recreated. Change-Id: I4ccc96566a5770384eacbbdc492bf09a514f5b31 Related-Bug: #1328546 commit 2bbfe6f8253659ebf6951b6426ffc446baacd420 Author: Russell Bryant Date: Tue May 26 17:07:37 2015 -0400 Move windows requirements to requirements.txt Commit 276028cca26af573c14938255e40c58358eabd4a added these requirements to setup.py from a custom build hook. These requirements can now be expressed in requirements.txt. We need to move them there so that the global requirements sync job can continue to keep setup.py in sync with the global version. Depends-on: I2369971d306c10dc39a1b89698cec95cf7551d07 Change-Id: I3c07c279d33f6aed46c3a97dd9ba81251e51429a commit 21ff82d9d33313bb88e5970c7b1829a65f195d33 Author: Rossella Sblendido Date: Fri Dec 5 17:34:23 2014 +0100 Adds base in-tree functional testing of the ovs_neutron_agent Base setup and utility methods for functional testing of the OVS L2 agent. Partially-Implements: blueprint restructure-l2-agent Co-Authored-By: Rossella Sblendido Change-Id: I5b3149b2b8502b9b9a36d3e20d909872cc17f8e8 commit 1ac7581c6b7d343d2ee22e6c562871c0465d9735 Author: Livnat Peer Date: Tue Jun 30 16:25:57 2015 +0300 fix spelling mistakes Change-Id: If063f111fa42a6644a1dadc7f0c0b9bbfb359294 commit 9b23617111706ef6a89e8ba45457238acaea26e2 Author: Kevin Benton Date: Mon Jun 29 22:24:22 2015 -0700 Increase ping count on ARP spoof test The other IPv4 tests all have a count of 2 to tolerate ping failures due to slow ARP response/interface setup/etc. This patch increases test_arp_spoof_allowed_address_pairs_0cidr to 2 to match. Closes-Bug: #1470234 Change-Id: I82bd8397672194f6162eef5392d4f19d57450552 commit 4dc68ea88bf4f07b13253bf9eeedffe22b1f8013 Author: Kevin Benton Date: Thu May 28 23:13:19 2015 -0700 Read vif port information in bulk During startup, the agent was making many calls per port to read information about the current VLAN, external ID, etc. This resulted in hundreds of calls just to read information about a relatively small number of ports. This patch addresses that by converting a few key functions to lookup information for all of the ports at once. Performance improvement on dev laptop for 250 ports from agent start to port ACTIVE status: before: 1m21s after: 1m06s Closes-Bug: #1460233 Change-Id: Ic80c85a07fee3e5651dc19819c6cebdc2048dda7 commit 6e693fc91dd79cfbf181e3b015a1816d985ad02c Author: Elena Ezhova Date: Thu Jun 18 10:42:57 2015 +0300 Switch to oslo.service oslo.service has graduated, so neutron should consume it. Closes-Bug: #1466851 Depends-On: Ie0fd63f969f954029c3c3cf31337fbe38f59331a Depends-On: I2093b37d411df9a26958fa50ff523c258bbe06ec Depends-On: I4823d344878fc97e66ddd8fdae25c13a34dede40 Change-Id: I0155b3d8b72f6d031bf6f855488f80acebfc25d4 commit b21a88603e369a113c8b73c3aebc05fedf8da9d3 Author: Eugene Nikanorov Date: Mon Jun 29 05:45:24 2015 +0400 Don't access mock's attribute directly especially when it's not needed Change-Id: I0df2f7110301c096762396fb23e49a081d051f3b commit 6d35f5fa91faf24694cf22bf9290f4743175b051 Author: Tomoaki Sato Date: Mon Jun 29 10:02:20 2015 +0900 Fix subnet updating failure on valid allocation pools Currently subnet updating with both allocation-pool and gateway_ip options is failing because of wrong parameter check. The check always checks gateway_ip against allocation pools in db, even when the allocation_pool parameter is given.The fix checks if given parameter of gateway_ip option doesn't conflict with given parameters of allocation-pool. Change-Id: Ia568aa1645b3160ab90a6010efd9a2b9b0d31ac8 Closes-Bug: #1469573 commit 604101ec58d8dd6e6af4aa61c0b2f0d382f89931 Author: Meenakshi Kaushik Date: Sun May 24 23:30:17 2015 -0700 Add documentation for Linux Bridge (previously missing) Change-Id: I092b609f43b37ed85d08bc80d1d048b945abe222 Closes-Bug: #1455979 commit e50e1a236983e0a59b9667bc546c92555c3d0e34 Author: Eugene Nikanorov Date: Tue May 5 18:18:28 2015 +0400 Add logging of agent heartbeats When troubleshooting problems with cluster it would be very convenient to have information about agent heartbeats logged with some searchable identifier which could create 1-to-1 mapping between events in agent's logs and server's logs. Currently agent's heartbeats are not logged at all on server side. Since on a large cluster that could create too much logging (even for troubleshooting cases), it might make sense to make this configurable both on neutron-server side and on agent-side. DocImpact Change-Id: I0a127ef274a84bba5de47395d47b62f48bd4be16 Closes-Bug: #1452582 commit 67658607cf69ad2274d8f32680042ca210c7db86 Author: Assaf Muller Date: Fri Jun 26 17:17:14 2015 -0400 Revert "Fix 'router_gateway' port status can't be updated" This patch breaks multinode fullstack tests and in my opinion is generally speaking wrong. I've added a comment to explain in the patch that's being reverted. This reverts commit with change ID: If428eadadfd36a9b19ea75920120e48ac49659f2 Change-Id: I73b7825ccc26847ef03d60d6154d544a9145f7e5 commit b9656509c178041f729cbaa6a1ca974f4b3c6f5d Author: Jakub Libosvar Date: Thu Jun 18 16:00:56 2015 +0000 RootHelperProcess: kill can consume signal number The kill() method now accepts a signal parameter. Change-Id: I2eb756a73565d93c979e62eaab358a3a519aa8dd commit b9e9cfb08bf0609dcfea46403c510607e858926a Author: Jakub Libosvar Date: Wed Jun 17 13:10:13 2015 +0000 Move NetcatTester to common/net_helpers The NetcatTester is a testing tool that can be used also in fullstack tests so I think it should go there to avoid imports in fullstack tests from functional. Tests for original helpers module was removed. Change-Id: I7229eba1dbc2ca3d524a1a021256b6202f4aecee commit b622e6538ae5a606c1bc9830a2afe816a92a2ca5 Author: Jakub Libosvar Date: Tue Jun 16 15:29:17 2015 +0000 ip_lib: Add flush() command to IpNeigh to clean arp cache Change-Id: I938974e3d67373cd18d8a9c6538f1f8b2d09e965 commit e2a99fa3c456a57e6e74e53ab04ad4899d1a9cf2 Author: Darragh O'Reilly Date: Tue Dec 2 18:28:38 2014 +0000 lb-agent: handle security group updates in main loop Patch I1574544734865506ff5383404516cc9349c16ec4 introduced deferring firewall refreshes to the main loop of the ovs-agent to improve performance. This patch enables the same on the linuxbridge agent. Change-Id: Ia8fe229910d2be718da52cb341be163b86ace571 Closes-Bug: #1368281 commit 481d9a4f356d325e60e4c208c93693d755097bcd Author: venkata anil Date: Wed Jun 24 07:33:09 2015 +0000 dhcp fails if extra_dhcp_opts for stateless subnet enabled vm on a network having IPv4 and IPv6 dhcpv6 stateless subnets, fails to get IPv4 address, when vm uses a port with extra_dhcp_opts. neutron creates entries in dhcp host file for each subnet of a port. Each of these entries will have same mac address as first field, and may have client_id, fqdn, ipv4/ipv6 address for dhcp/dhcpv6 stateful, or tag as other fields. For dhcpv6 stateless subnet with extra_dhcp_opts, host file will have only mac address and tag. If the last entry in host file for the port with extra_dhcp_opts, is for dhcpv6 stateless subnet, then dnsmasq tries to use this entry, (as dnsmasq reads the hosts file from EOF) to resolve dhcp request even for IPv4, treats as 'no address found' and fails to send DHCPOFFER. So we sort the fixed_ips, so that ipv6 subnets for the port are added first in host file, to avoid this issue. Change-Id: I3bea58d86a3508e49cbac1d03c6b640836b4a7a2 Closes-bug: #1466144 commit 0eb44ca1f23ee4d031ddf2e03a1ebc6a16428d3f Author: Gary Kotton Date: Thu May 28 02:17:52 2015 -0700 NSXv: update ini file to support dhcp_lease_time Add the variable to enable the admin to set the DHCP lease time. This was added in commit 7681e4c50afda18fd75fe7207352d1a26ee0755b DocImpact Change-Id: Ic37932c09d3b4c88363a7f1f38a687cd6e090c1f commit aaa070868e8fb891e6ab5f8355bb03ee3e837c9e Author: Pavel Bondar Date: Thu Jun 11 15:04:48 2015 +0300 Use sets to calculate added/original/removed ips Original algorithm to calculate added/removed ips had O(n^2) complexity. Using sets achieves O(n) for average case. After refactoring input is no longer affected, updated tests to reflect that. However, dataset is too small to get any significant performance improvement. Using sets requires additional preparation and post operations: - converting 'original_ips' and 'new_ips' to sets from ip_addresses - building map(dict) for storing reference from ip_address to 'ips' element - converting calculated add/orignal/remove sets back to list of dicts using map (dict of references). Partially-Implements: blueprint neutron-ipam Change-Id: Iecddc406f7b91cfdfb976882504113734e19b565 commit 9efa1fdeed86d249b2d3dde987a1fb98290140f0 Author: Oleg Bondarev Date: Thu Jun 11 15:40:33 2015 +0300 l3 agent: do router cleanup for unknown routers The patch adds cleanup on router delete for routers which are unknown to agent. This should cover the case when router is deleted during resync on agent init. Functional tests were updated and now handle 3 cases for l3 sync: - no routers were deleted during agent downtime, - some routers were deleted during agent downtime - some routers were deleted during agent resync Closes-Bug: #1464238 Change-Id: Id98111849fa88d6807f757864187b059c491aaac commit a391178c218f08b0c5e7580b5a4b79513ebffcc2 Author: Salvatore Orlando Date: Wed Jun 17 04:36:02 2015 -0700 Add policy files specific to NSX plugins This patch simply adds a 'policy' directory with a few json files into ./etc/neutron/plugins/vmware to provide default policies specific to the VMware NSX plugin family. These policy files can be loaded leveraging the policy_dirs configuration option. Change-Id: Icce41a6ee63715bc145694f27a2166a7fa884dba ** Tags added: in-feature-pecan -- You received this bug notification because you are a member of OpenStack Security, 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): Fix Committed 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 1472331 at bugs.launchpad.net Thu Jul 9 22:14:51 2015 From: 1472331 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 09 Jul 2015 22:14:51 -0000 Subject: [Openstack-security] [Bug 1472331] Re: Trust id is not hidden in logs References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Message-ID: <20150709221451.28171.73808.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/kilo Review: https://review.openstack.org/200286 ** Changed in: murano/kilo Status: New => In Progress ** Changed in: murano/kilo Assignee: (unassigned) => Kirill Zaitsev (kzaitsev) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472331 Title: Trust id is not hidden in logs Status in Murano: Fix Committed Status in murano kilo series: In Progress Bug description: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1472331/+subscriptions From vryzhenkin at mirantis.com Fri Jul 10 01:02:49 2015 From: vryzhenkin at mirantis.com (Victor Ryzhenkin) Date: Fri, 10 Jul 2015 01:02:49 -0000 Subject: [Openstack-security] [Bug 1472331] Re: Trust id is not hidden in logs References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Message-ID: <20150710010251.4232.89443.launchpad@gac.canonical.com> ** Changed in: murano/kilo Importance: Undecided => High ** Changed in: murano/kilo Milestone: None => 2015.1.1 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472331 Title: Trust id is not hidden in logs Status in Murano: Fix Committed Status in murano kilo series: In Progress Bug description: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1472331/+subscriptions From 1472331 at bugs.launchpad.net Fri Jul 10 15:12:27 2015 From: 1472331 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 10 Jul 2015 15:12:27 -0000 Subject: [Openstack-security] [Bug 1472331] Re: Trust id is not hidden in logs References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Message-ID: <20150710151227.20659.81446.malone@gac.canonical.com> Reviewed: https://review.openstack.org/200286 Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=484fc244c99968738eb53815174b90dbb8e93554 Submitter: Jenkins Branch: stable/kilo commit 484fc244c99968738eb53815174b90dbb8e93554 Author: Lin Yang Date: Wed Jul 8 13:53:15 2015 +0800 Hide TrustId in log to tighten up security Current the value of TrustId is showed in plaintext in log when murano creates trustes and operates with data. So add 'trustid' in token_sanitizer to hide it like token and pass. Closes-Bug: #1472331 Change-Id: I1e9ea8298a7ffd9aa742cf73fada69db3a734712 ** Changed in: murano/kilo Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472331 Title: Trust id is not hidden in logs Status in murano: Fix Committed Status in murano kilo series: Fix Committed Bug description: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1472331/+subscriptions From gerrit2 at review.openstack.org Fri Jul 10 16:48:03 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 10 Jul 2015 16:48:03 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ia0302ec43f96512c2e51a307c3091a2cee066610 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/200621 Log: commit 67f75f86afc6bba924cdf0441de7e1db00d82cb6 Author: abhishekkekane Date: Tue Mar 31 05:24:47 2015 -0700 Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added callback method to execute call which will store the pid of scp/rsync process in cache as a key: value pair which will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Co-authored-by: Nikola Đipanov Closes-bug: #1387543 Change-Id: Ia0302ec43f96512c2e51a307c3091a2cee066610 From gerrit2 at review.openstack.org Fri Jul 10 16:51:43 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 10 Jul 2015 16:51:43 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ia0302ec43f96512c2e51a307c3091a2cee066610 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/200621 Log: commit d6053139987e3a8e711504f779431ed80dd61447 Author: abhishekkekane Date: Tue Mar 31 05:24:47 2015 -0700 Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added callback method to execute call which will store the pid of scp/rsync process in cache as a key: value pair which will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Co-authored-by: Nikola Đipanov Closes-bug: #1387543 Change-Id: Ia0302ec43f96512c2e51a307c3091a2cee066610 From gerrit2 at review.openstack.org Fri Jul 10 16:58:42 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 10 Jul 2015 16:58:42 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ia0302ec43f96512c2e51a307c3091a2cee066610 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/200621 Log: commit 15dc8c9145262afada5410afae4e55b8a39dd6b2 Author: abhishekkekane Date: Tue Mar 31 05:24:47 2015 -0700 Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added callback method to execute call which will store the pid of scp/rsync process in cache as a key: value pair which will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Co-authored-by: Nikola Đipanov Closes-bug: #1387543 Change-Id: Ia0302ec43f96512c2e51a307c3091a2cee066610 From gerrit2 at review.openstack.org Fri Jul 10 17:48:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 10 Jul 2015 17:48:05 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ia0302ec43f96512c2e51a307c3091a2cee066610 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/200621 Log: commit 5cd1ade5c9fa52f8a6fa26abf899cce23c800421 Author: abhishekkekane Date: Tue Mar 31 05:24:47 2015 -0700 Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added callback method to execute call which will store the pid of scp/rsync process in cache as a key: value pair which will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Co-authored-by: Nikola Đipanov Closes-bug: #1387543 Change-Id: Ia0302ec43f96512c2e51a307c3091a2cee066610 From gerrit2 at review.openstack.org Fri Jul 10 18:08:41 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 10 Jul 2015 18:08:41 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ia0302ec43f96512c2e51a307c3091a2cee066610 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/200621 Log: commit ab2e31d399399a5012a9817d0d3142d4b49d3d8e Author: abhishekkekane Date: Tue Mar 31 05:24:47 2015 -0700 Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added callback method to execute call which will store the pid of scp/rsync process in cache as a key: value pair which will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Co-authored-by: Nikola Đipanov Closes-bug: #1387543 Change-Id: Ia0302ec43f96512c2e51a307c3091a2cee066610 From 1465922 at bugs.launchpad.net Fri Jul 10 19:01:30 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 10 Jul 2015 19:01:30 -0000 Subject: [Openstack-security] [Bug 1465922] Fix merged to keystone (master) References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150710190130.21109.9346.malone@gac.canonical.com> Reviewed: https://review.openstack.org/193703 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=c2c3a0ff86314bee3d62f69d30206ff7584f229f Submitter: Jenkins Branch: master commit c2c3a0ff86314bee3d62f69d30206ff7584f229f Author: Brant Knudson Date: Fri Jun 19 14:40:30 2015 -0500 Add test showing password logged There was no test that showed that the password is logged when a user is created or admin changes user password. Change-Id: I5ffa04e9ac359355cff47a622731f1bf6a27ea7b Partial-Bug: #1465922 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Mon Jul 13 19:47:15 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 13 Jul 2015 19:47:15 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150713194715.11407.76721.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/193695 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=fbdb100e656b19958589fa659bf9d95303e76ab8 Submitter: Jenkins Branch: master commit fbdb100e656b19958589fa659bf9d95303e76ab8 Author: Brant Knudson Date: Fri Jun 19 14:18:18 2015 -0500 Mask passwords in debug log on user password operations When a user is created, they change their password, or admin changes their password and debug logging is enabled, the value of the user's password was logged. The value should be masked. Change-Id: I07b7441378fb630f01204d6b656b218f6b94dd5a Closes-Bug: #1465922 ** Changed in: keystone Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Mon Jul 13 20:08:44 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 13 Jul 2015 20:08:44 -0000 Subject: [Openstack-security] [Bug 1465922] Fix proposed to keystone (stable/kilo) References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150713200844.11511.11832.malone@wampee.canonical.com> Fix proposed to branch: stable/kilo Review: https://review.openstack.org/201322 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Mon Jul 13 20:08:51 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 13 Jul 2015 20:08:51 -0000 Subject: [Openstack-security] [Bug 1465922] Fix proposed to keystone (stable/kilo) References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150713200851.10875.56363.malone@wampee.canonical.com> Fix proposed to branch: stable/kilo Review: https://review.openstack.org/201323 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Mon Jul 13 20:43:56 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 13 Jul 2015 20:43:56 -0000 Subject: [Openstack-security] [Bug 1465922] Fix proposed to keystone (stable/juno) References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150713204357.20025.89923.malone@soybean.canonical.com> Fix proposed to branch: stable/juno Review: https://review.openstack.org/201328 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Mon Jul 13 20:44:04 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 13 Jul 2015 20:44:04 -0000 Subject: [Openstack-security] [Bug 1465922] Fix proposed to keystone (stable/juno) References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150713204404.11540.73480.malone@wampee.canonical.com> Fix proposed to branch: stable/juno Review: https://review.openstack.org/201329 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From gerrit2 at review.openstack.org Tue Jul 14 12:43:41 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 14 Jul 2015 12:43:41 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Icddc7e5cc1c11ab3d272f61a2ef623d3f750030c Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/160206 Log: commit 725c54e60ac8b6e6c236fdcdc0d76be373337ecd Author: He Jie Xu Date: Mon Mar 2 08:42:11 2015 +0800 Remove db layer hard-code permission checks for quota_class_create/update This patch removes db layer hard-code permission checks for quota_class_create/update. For v2 API, this patch adds back-comptiable permission checks at REST API layer. For v2.1 API, this patch adds new rule for update method. Partially implements bp nova-api-policy-final-part SecurityImpact UpgradeImpact: Due to the db layer permission checks deleted, the policy rule "os_compute_api:os-quota-class-sets:update" was updated with a default that match the permission as before. Admin should be notified to update their policy configuration to keep permission as before. Change-Id: Icddc7e5cc1c11ab3d272f61a2ef623d3f750030c From gerrit2 at review.openstack.org Tue Jul 14 12:43:48 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 14 Jul 2015 12:43:48 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I02da6cc8c766e5f43689449ef63121122f537b5b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/160205 Log: commit 1dbb322813cfa26600ae4d1ce9c3880a56f29aca Author: He Jie Xu Date: Mon Mar 2 08:08:44 2015 +0800 Remove db layer hard-code permission checks for quota_class_get_all_by_name This patch removes the hard-code permission checks for db call quota_class_get_all_by_name. For v2 api, there already have same hard-code permission checks in REST API layer, so it is back-compatible. For v2.1 api, to distinguish show and update permission, this patch adds new rule for show method. Partially implements bp nova-api-policy-final-part SecurityImpact UpgradeImpact: Due to the db layer permission checks deleted, they need default policy rule instead of that. In this patch, "os_compute_api:os-quota-class-sets:show" was updated with a default rule. Admin will be notfied to update their policy configure file to keep the behavior as before. Change-Id: I02da6cc8c766e5f43689449ef63121122f537b5b From gerrit2 at review.openstack.org Tue Jul 14 16:21:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 14 Jul 2015 16:21:05 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I1f8311f1b9ae1be02afde3e9078e49c6da373a88 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/201650 Log: commit 9eaa0c3bca0f0a489f1cced72c4171f60996da5f Author: sridhargaddam Date: Tue Jul 14 16:18:06 2015 +0000 Add IPv6 Address Resolution protection Similar to IPv4 arp protection support, this patch adds the necessary OVS rules to prevent ports attached to agent from sending any icmpv6 neighbor advertisement messages that contain an IPv6 address not belonging to the port. For details please refer to "Figure 3. Attack against IPv6 Address Resolution" http://www.cisco.com/web/about/security/intelligence/ipv6_first_hop.html I've verified this patch locally and it works. I would like to seek feedback about this approach before proceeding with pending items. Pending items: Functional tests. Unit tests. Sanity check. DocImpact SecurityImpact Partial-Bug: #1274034 Change-Id: I1f8311f1b9ae1be02afde3e9078e49c6da373a88 From 1274034 at bugs.launchpad.net Tue Jul 14 16:21:01 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 14 Jul 2015 16:21:01 -0000 Subject: [Openstack-security] [Bug 1274034] Fix proposed to neutron (master) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150714162101.29961.71927.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/201650 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in neutron: Fix Committed Status in OpenStack Security Advisory: 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 1465922 at bugs.launchpad.net Tue Jul 14 19:13:35 2015 From: 1465922 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 14 Jul 2015 19:13:35 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150714191335.19642.678.launchpad@soybean.canonical.com> ** Also affects: keystone/kilo Importance: Undecided Status: New ** Also affects: keystone/juno Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in Keystone juno series: New Status in Keystone kilo series: New Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Tue Jul 14 20:17:21 2015 From: 1465922 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 14 Jul 2015 20:17:21 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150714201722.30403.62595.launchpad@gac.canonical.com> ** Changed in: keystone/juno Assignee: (unassigned) => Brant Knudson (blk-u) ** Changed in: keystone/kilo Assignee: (unassigned) => Brant Knudson (blk-u) ** Changed in: keystone/juno Status: New => In Progress ** Changed in: keystone/kilo Status: New => In Progress ** Changed in: keystone/juno Importance: Undecided => Medium ** Changed in: keystone/kilo Importance: Undecided => Medium ** Tags removed: keystone kilo-backport-potential -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in Keystone juno series: In Progress Status in Keystone kilo series: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Wed Jul 15 00:16:43 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 15 Jul 2015 00:16:43 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150715001643.30103.28731.malone@gac.canonical.com> Reviewed: https://review.openstack.org/201322 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=fba2d5c15e298e0936800a0e3d1ff7588235c359 Submitter: Jenkins Branch: stable/kilo commit fba2d5c15e298e0936800a0e3d1ff7588235c359 Author: Brant Knudson Date: Fri Jun 19 14:40:30 2015 -0500 Add test showing password logged There was no test that showed that the password is logged when a user is created or admin changes user password. Change-Id: I5ffa04e9ac359355cff47a622731f1bf6a27ea7b Partial-Bug: #1465922 (cherry picked from commit c2c3a0ff86314bee3d62f69d30206ff7584f229f) ** Tags added: in-stable-kilo ** Changed in: keystone/kilo Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in Keystone juno series: In Progress Status in Keystone kilo series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1465922 at bugs.launchpad.net Wed Jul 15 00:20:10 2015 From: 1465922 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 15 Jul 2015 00:20:10 -0000 Subject: [Openstack-security] [Bug 1465922] Fix merged to keystone (stable/kilo) References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150715002010.30337.56329.malone@gac.canonical.com> Reviewed: https://review.openstack.org/201323 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=c4dc1331e111f6fce070163129cef008a204e99f Submitter: Jenkins Branch: stable/kilo commit c4dc1331e111f6fce070163129cef008a204e99f Author: Brant Knudson Date: Fri Jun 19 14:18:18 2015 -0500 Mask passwords in debug log on user password operations When a user is created, they change their password, or admin changes their password and debug logging is enabled, the value of the user's password was logged. The value should be masked. Change-Id: I07b7441378fb630f01204d6b656b218f6b94dd5a Closes-Bug: #1465922 (cherry picked from commit fbdb100e656b19958589fa659bf9d95303e76ab8) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in Keystone juno series: In Progress Status in Keystone kilo series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From gerrit2 at review.openstack.org Thu Jul 16 06:28:14 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 16 Jul 2015 06:28:14 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/192986 Log: commit 9cd53cfd91abe2798760cb870f02d5fe3652bf9e Author: abhishekkekane Date: Mon Jul 6 01:51:26 2015 -0700 libvirt: Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added new module instancejobtracker to libvirt driver which will add, remove or terminate the processes running against particular instances. Added callback methods to execute call which will store the pid of scp/rsync process in cache as a key: value pair and to remove the pid from the cache after process completion. Process id will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Closes-bug: #1387543 Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 From 1457551 at bugs.launchpad.net Thu Jul 16 15:02:35 2015 From: 1457551 at bugs.launchpad.net (Lin Hua Cheng) Date: Thu, 16 Jul 2015 15:02:35 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150716150239.19996.22542.launchpad@soybean.canonical.com> ** Changed in: horizon Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From nkinder at redhat.com Thu Jul 16 16:56:00 2015 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 16 Jul 2015 16:56:00 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150716165600.25579.57969.malone@chaenomeles.canonical.com> There is not much we can recommend in an OSSN until we support running Django 1.8 with Horizon. I think we need to hold off on the OSSN until that time, unless there is some sort of external rate limiting that can be done to mitigate the issue. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From travis.mcpeak at hp.com Thu Jul 16 17:15:45 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Thu, 16 Jul 2015 17:15:45 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150716171545.26075.57733.malone@chaenomeles.canonical.com> Sessions fix was merged into 1.7.9 in Django unless I'm missing something? Horizon does support the 1.7.x branch, right? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From 1457551 at bugs.launchpad.net Thu Jul 16 19:02:20 2015 From: 1457551 at bugs.launchpad.net (Lin Hua Cheng) Date: Thu, 16 Jul 2015 19:02:20 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150716190220.30613.39360.malone@gac.canonical.com> Yes, horizon does support django 1.7.9. And in L working on: - support for Django 1.8. - dropping of Django 14, 1.5, 1.6 which django will stop supporting by end of L -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From 1457551 at bugs.launchpad.net Fri Jul 17 08:04:44 2015 From: 1457551 at bugs.launchpad.net (Matthias Runge) Date: Fri, 17 Jul 2015 08:04:44 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150717080444.26011.59804.malone@chaenomeles.canonical.com> Kilo supports django-1.7.x Horizon in Juno (and esp. django_openstack_auth) support only Django-1.6. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From travis.mcpeak at hp.com Fri Jul 17 14:00:41 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Fri, 17 Jul 2015 14:00:41 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150717140041.25914.26500.malone@chaenomeles.canonical.com> @nkinder - So we could write a security note describing the issue and recommending Django upgrades for Kilo deployments. We don't currently have any advice for Juno deployments. @all - Is this an accurate description of our current state? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From akarora at cisco.com Mon Jul 20 03:53:25 2015 From: akarora at cisco.com (Anshul Arora (akarora)) Date: Mon, 20 Jul 2015 03:53:25 +0000 Subject: [Openstack-security] Neutron: ARP responder and L-2 population Message-ID: Folks, I've a query related to APR configuration options and/or general OpenStack solution out of the box for DoS attacks. In the Neutron plugin.ini file, there are two parameters : L2 population and ARP responder. Based on the documentation it's not clear in which "use cases" these parameters are mandatory. For e.g. is it that VLAN/GRE configuration ? or VLAN based implementation? or both? must be configured with ARP responder to prevent broadcast storms? The confusion kicks in because ARP responder is an optional parameter that is turned off by default. Thanks, -Anshul -------------- next part -------------- An HTML attachment was scrubbed... URL: From aheczko at mirantis.com Mon Jul 20 09:57:13 2015 From: aheczko at mirantis.com (Adam Heczko) Date: Mon, 20 Jul 2015 11:57:13 +0200 Subject: [Openstack-security] Neutron: ARP responder and L-2 population In-Reply-To: References: Message-ID: Hi Anshul, I believe that both of these parameters are useful in DVR scenario. These parameters are more related to DVR virtual router functionality rather than to underlay/physical network architecture. In regards to DoS attack mitigation, I'm not sure if OpenStack has any functionality related. I believe that some metering and stats provided by Ceilometer might be useful for this purpose, but for as of now, DoS prevention is usually managed by external to OpenStack means (provider's network layer). That's my understanding, please correct me if I'm wrong. Regards, Adam On Mon, Jul 20, 2015 at 5:53 AM, Anshul Arora (akarora) wrote: > Folks, > > > > I’ve a query related to APR configuration options and/or general OpenStack > solution out of the box for DoS attacks. > > > > In the Neutron plugin.ini file, there are two parameters : L2 population > and ARP responder. Based on the documentation it’s not clear in which “use > cases” these parameters are mandatory. For e.g. is it that VLAN/GRE > configuration ? or VLAN based implementation? or both? must be configured > with ARP responder to prevent broadcast storms? > > > > The confusion kicks in because ARP responder is an optional parameter that > is turned off by default. > > > > Thanks, > > -Anshul > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -- Adam Heczko Security Engineer @ Mirantis Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.carter at rackspace.com Mon Jul 20 18:10:49 2015 From: kevin.carter at rackspace.com (Kevin Carter) Date: Mon, 20 Jul 2015 18:10:49 -0000 Subject: [Openstack-security] [Bug 1412393] Re: mariadb repo unnecessarily configured in all containers References: <20150119110012.23998.45109.malonedeb@gac.canonical.com> Message-ID: <20150720181050.29930.42158.launchpad@gac.canonical.com> ** Changed in: openstack-ansible/icehouse Status: Confirmed => Won't Fix ** Also affects: openstack-ansible/kilo Importance: Undecided Status: New ** Changed in: openstack-ansible/trunk Status: Invalid => New ** Changed in: openstack-ansible/kilo Status: New => Confirmed ** Changed in: openstack-ansible/kilo Importance: Undecided => Low ** Changed in: openstack-ansible/trunk Status: New => Confirmed ** Changed in: openstack-ansible/trunk Assignee: Kevin Carter (kevin-carter) => (unassigned) ** Changed in: openstack-ansible/trunk Milestone: next => None -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1412393 Title: mariadb repo unnecessarily configured in all containers Status in openstack-ansible: Confirmed Status in openstack-ansible icehouse series: Won't Fix Status in openstack-ansible juno series: Confirmed Status in openstack-ansible kilo series: Confirmed Status in openstack-ansible trunk series: Confirmed 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 gerrit2 at review.openstack.org Tue Jul 21 02:13:07 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 21 Jul 2015 02:13:07 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I383e0a5c55b7e79a02c78eb155f6d64d7d8a2ab6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/203852 Log: commit 84bf5736ce96e52927a61eb47e37c69f5436fee7 Author: Adam Young Date: Mon Jul 20 14:08:29 2015 -0400 Specify ID for Project or domain creation If a project or domain is deleted, this will allow the re-creation of the domain, or at least a reasonable facimile of it. The new domain or project can have the same ID as an existing one, an thus can be enabled, and a user can get a token scoped to that domain or project. SecurityImpact Closes-Bug: 1476264 Change-Id: I383e0a5c55b7e79a02c78eb155f6d64d7d8a2ab6 From gerrit2 at review.openstack.org Tue Jul 21 07:18:57 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 21 Jul 2015 07:18:57 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/192986 Log: commit cebcd3e914276b54a900a998c4aec8c8951653a9 Author: abhishekkekane Date: Mon Jul 6 01:51:26 2015 -0700 libvirt: Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added new module instancejobtracker to libvirt driver which will add, remove or terminate the processes running against particular instances. Added callback methods to execute call which will store the pid of scp/rsync process in cache as a key: value pair and to remove the pid from the cache after process completion. Process id will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Closes-bug: #1387543 Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 From 1464219 at bugs.launchpad.net Tue Jul 21 07:52:00 2015 From: 1464219 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 21 Jul 2015 07:52:00 -0000 Subject: [Openstack-security] [Bug 1464219] Re: [api] there are no checks of request tenant_id during abandoning of an environment References: <20150611110620.13354.78142.malonedeb@wampee.canonical.com> Message-ID: <20150721075200.30134.38413.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/203958 ** Changed in: murano Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464219 Title: [api] there are no checks of request tenant_id during abandoning of an environment Status in murano: In Progress Bug description: Looks like the code currently does not check, that a given env belongs to current requests tenant. Therefore it might be possible for users from different tenants to delete/deploy environments. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1464219/+subscriptions From gerrit2 at review.openstack.org Tue Jul 21 09:03:36 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 21 Jul 2015 09:03:36 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/192986 Log: commit 328775ea5346d9fd3259e82a147026b04a8923b2 Author: abhishekkekane Date: Mon Jul 6 01:51:26 2015 -0700 libvirt: Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added new module instancejobtracker to libvirt driver which will add, remove or terminate the processes running against particular instances. Added callback methods to execute call which will store the pid of scp/rsync process in cache as a key: value pair and to remove the pid from the cache after process completion. Process id will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Closes-bug: #1387543 Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 From gerrit2 at review.openstack.org Tue Jul 21 11:50:20 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 21 Jul 2015 11:50:20 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/192986 Log: commit 9c06b898a7b5c56e9527a92fcb8f7cb6df15e67b Author: abhishekkekane Date: Mon Jul 6 01:51:26 2015 -0700 libvirt: Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added new module instancejobtracker to libvirt driver which will add, remove or terminate the processes running against particular instances. Added callback methods to execute call which will store the pid of scp/rsync process in cache as a key: value pair and to remove the pid from the cache after process completion. Process id will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Depends-On: I8565ccb1572d3338eaf51fb3a439ce0b65f05065 Closes-bug: #1387543 Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 From travis.mcpeak at hp.com Tue Jul 21 19:09:33 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Tue, 21 Jul 2015 19:09:33 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <20150721190935.30370.59292.launchpad@gac.canonical.com> ** Changed in: ossn Status: Incomplete => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From 1447679 at bugs.launchpad.net Tue Jul 21 19:11:19 2015 From: 1447679 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 21 Jul 2015 19:11:19 -0000 Subject: [Openstack-security] [Bug 1447679] Re: service No-VNC (port 6080) doesn't require authentication References: <20150423154044.13260.70404.malonedeb@chaenomeles.canonical.com> Message-ID: <20150721191122.10811.65263.launchpad@wampee.canonical.com> ** Changed in: nova Assignee: Tony Breeds (o-tony) => Michael Still (mikalstill) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1447679 Title: service No-VNC (port 6080) doesn't require authentication Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: Reported via private E-mail from Anass ANNOUR: I found that the service No-VNC (port 6080) doesn't require authentication, if you know the URL (ex: http://192.168.198.164:6080/vnc_auto.html?token=3640a3c8-ad10-45da-a523-18d3793ef8ec) you can access the machine from any other computer without any authentication before the token expires. (or in the same time as user still use the console) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1447679/+subscriptions From travis.mcpeak at hp.com Tue Jul 21 20:04:10 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Tue, 21 Jul 2015 20:04:10 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <20150721200410.19579.17892.malone@soybean.canonical.com> OK - just to make sure I'm understanding the problem correctly (and can thus write a clear note) - this OSSN should document that: in some configurations (all Keystone v2, some configurations of Keystone v3, Nova, Neutron) the service accounts are full cloud admin users. This means that they can perform all actions including logging in to Horizon. Is this a fair assessment? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From travis.mcpeak at hp.com Tue Jul 21 20:05:09 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Tue, 21 Jul 2015 20:05:09 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <20150721200509.25914.48640.malone@chaenomeles.canonical.com> Also if ^ is correct- I'd rather just say "assume that service accounts have admin privileges and can do anything with your cloud". -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From nkinder at redhat.com Tue Jul 21 21:26:20 2015 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 21 Jul 2015 21:26:20 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <20150721212621.25641.99617.malone@chaenomeles.canonical.com> @travis-mcpeak With v3 of the Identity API, it's a matter of policy. In theory, roles and policies can be configured such that there is a 'services' role for token validation, and other special non-admin roles for operations such as the inter-service calls mentioned by @blk-u. I don't believe that anyone is actually defining their roles and policy in this way right now, but it is somethign that shoudl work and that we can recommend IMHO. For v2 of the Identity API, all we can do in an OSSN is raise awareness that service accounts are equivalent to admin accounts. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From 1464750 at bugs.launchpad.net Tue Jul 21 21:27:26 2015 From: 1464750 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 21 Jul 2015 21:27:26 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <20150721212726.20230.55553.malone@soybean.canonical.com> Kathleen: That's already possible as a deployer option, but it's certainly not the default per the policy.json files we see across OpenStack today. You're correct in that the root problem here is one of overly broad authorization ("admin" should be broken down into many more roles with more specific use cases). It's a problem that exists across OpenStack. If anyone has gone through the effort of defining more granular roles for each service in OpenStack, they have not shared that work, much less upstreamed the resulting policy.json files. Travis: The core issue here is not particularly relevant to keystone's v2 / v3 APIs, nor to Nova and Neutron. All services that I'm aware of use the concept of a "service" user which in most deployments receive overly broad "admin" level authorization (which should be clearly understood by everyone as being analogous to having "root" of the entire cloud). As I believe David Hill alluded in the bug description, those accounts generally have passwords just like regular users (and regular cloud operators) and can thus authenticate with keystone to generate tokens just as any other API user can. Given service user's "admin" authorization across OpenStack, they then have free reign to make any API calls they please. Whether or not Horizon is involved is entirely a non-issue, in my opinion. As Adam pointed out, the problem described in bug 968696 is tightly related to this one, if it's not a duplicate. The only difference here is that service users are generally deployed with that level of authorization, when they should not, and ultimately do not, require it. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From travis.mcpeak at hp.com Tue Jul 21 21:42:12 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Tue, 21 Jul 2015 21:42:12 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <20150721214212.11304.88750.malone@wampee.canonical.com> @ dolph, nkinder - got it, thank you for the summary. I'll start writing the note and loop Keystone folks in for the policy example guidance. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From gerrit2 at review.openstack.org Wed Jul 22 02:29:13 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 22 Jul 2015 02:29:13 +0000 Subject: [Openstack-security] [openstack/murano] SecurityImpact review request change Ia6c291261de8951dc779394b993e646ed0c0a9d9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/203958 Log: commit e25fb99e4c32536cb3921499bb2f0e1814b3de4e Author: leizhang Date: Tue Jul 21 15:11:46 2015 +0800 Check tenant id during abandoning of an env Add code to check whether current tenant matches the env's tentant Change-Id: Ia6c291261de8951dc779394b993e646ed0c0a9d9 Closes-Bug: #1464219 SecurityImpact From gerrit2 at review.openstack.org Wed Jul 22 03:22:54 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 22 Jul 2015 03:22:54 +0000 Subject: [Openstack-security] [openstack/murano] SecurityImpact review request change Ia6c291261de8951dc779394b993e646ed0c0a9d9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/203958 Log: commit b5b39becc0bc5f4cc2d59968930a4ea75a0b072d Author: leizhang Date: Tue Jul 21 15:11:46 2015 +0800 Check tenant id during abandoning of an env Add code to check whether current tenant matches the env's tentant Change-Id: Ia6c291261de8951dc779394b993e646ed0c0a9d9 Closes-Bug: #1464219 SecurityImpact From stanislaw.pitucha at hp.com Wed Jul 22 04:29:27 2015 From: stanislaw.pitucha at hp.com (Pitucha, Stanislaw Izaak) Date: Wed, 22 Jul 2015 04:29:27 +0000 Subject: [Openstack-security] [Anchor] Almost security-impact review - getting rid of openssl Message-ID: Hi all, I’d like to get people interested in Anchor development to look at a WIP patch I uploaded now: https://review.openstack.org/204368 It changes the backend of Anchor from relying on openssl (and all the issues that go with it) to using pyasn1/pycrypto to directly operate on the certificate/csr. While it’s not complete and I’m still waiting for some answers to enable extensions (http://stackoverflow.com/questions/31552798/parsing-x509-extensions-with-pyasn1), it’s functional. By definition – test_functional passes ;) It’s going to be a big change and take quite some time, so any feedback is appreciated early on. The original rationale for the change can be read at https://etherpad.openstack.org/p/Anchor_direct_asn1 and while there were some issues on the way, I believe that everything I expected to improve, improved a lot. What I’m most happy about is that the change gets rid of magic string parsing / output and memory management of openssl. Things like string and date manipulation either disappeared or got much shorter. Also many error checks are not needed anymore. I didn’t correct all function comments, so some of them may mention wrong types. But the interface stayed pretty much the same – higher level functionality like certificate_ops/signing has only cosmetic changes. So if you’re interested in Anchor, please have a look. Best Regards, Stanisław Pitucha -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3508 bytes Desc: not available URL: From Darren.Moffat at Oracle.COM Wed Jul 22 09:19:30 2015 From: Darren.Moffat at Oracle.COM (Darren J Moffat) Date: Wed, 22 Jul 2015 10:19:30 +0100 Subject: [Openstack-security] [Anchor] Almost security-impact review - getting rid of openssl In-Reply-To: References: Message-ID: <55AF6022.5060709@Oracle.COM> On 07/22/15 05:29, Pitucha, Stanislaw Izaak wrote: > Hi all, > I’d like to get people interested in Anchor development to look at a WIP patch I uploaded now: > https://review.openstack.org/204368 > > It changes the backend of Anchor from relying on openssl (and all the issues that go with it) to using pyasn1/pycrypto to directly operate on the certificate/csr. > While it’s not complete and I’m still waiting for some answers to enable extensions (http://stackoverflow.com/questions/31552798/parsing-x509-extensions-with-pyasn1), it’s functional. By definition – test_functional passes ;) I think this is the exact opposite of the direction we should be going in. pycrypto is old and not well featured. Other parts of OpenStack and dependent projects such as paramiko are moving to cryptography.io which is a modern Python layer over OpenSSL. Please do not add more dependencies on pycrypto. > It’s going to be a big change and take quite some time, so any feedback is appreciated early on. The original rationale for the change can be read at https://etherpad.openstack.org/p/Anchor_direct_asn1 and while there were some issues on the way, I believe that everything I expected to improve, improved a lot. What I’m most happy about is that the change gets rid of magic string parsing / output and memory management of openssl. Things like string and date manipulation either disappeared or got much shorter. Also many error checks are not needed anymore. > > I didn’t correct all function comments, so some of them may mention wrong types. But the interface stayed pretty much the same – higher level functionality like certificate_ops/signing has only cosmetic changes. > > So if you’re interested in Anchor, please have a look. > > Best Regards, > Stanisław Pitucha > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Darren J Moffat From robert.clark at hp.com Wed Jul 22 09:50:22 2015 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 22 Jul 2015 09:50:22 +0000 Subject: [Openstack-security] [Anchor] Almost security-impact review - getting rid of openssl In-Reply-To: <55AF6022.5060709@Oracle.COM> References: <55AF6022.5060709@Oracle.COM> Message-ID: I tend to agree with Darren. As it's quite a big change I think it should be discussed in a security-specification. -Rob On 22/07/2015 10:19, "Darren J Moffat" wrote: > > >On 07/22/15 05:29, Pitucha, Stanislaw Izaak wrote: >> Hi all, >> I'd like to get people interested in Anchor development to look at a >>WIP patch I uploaded now: >> https://review.openstack.org/204368 >> >> It changes the backend of Anchor from relying on openssl (and all the >>issues that go with it) to using pyasn1/pycrypto to directly operate on >>the certificate/csr. >> While it's not complete and I'm still waiting for some answers to >>enable extensions >>(http://stackoverflow.com/questions/31552798/parsing-x509-extensions-with >>-pyasn1), it's functional. By definition - test_functional passes ;) > >I think this is the exact opposite of the direction we should be going in. > >pycrypto is old and not well featured. Other parts of OpenStack and >dependent projects such as paramiko are moving to cryptography.io which >is a modern Python layer over OpenSSL. > >Please do not add more dependencies on pycrypto. > >> It's going to be a big change and take quite some time, so any feedback >>is appreciated early on. The original rationale for the change can be >>read at https://etherpad.openstack.org/p/Anchor_direct_asn1 and while >>there were some issues on the way, I believe that everything I expected >>to improve, improved a lot. What I'm most happy about is that the change >>gets rid of magic string parsing / output and memory management of >>openssl. Things like string and date manipulation either disappeared or >>got much shorter. Also many error checks are not needed anymore. >> >> I didn't correct all function comments, so some of them may mention >>wrong types. But the interface stayed pretty much the same - higher >>level functionality like certificate_ops/signing has only cosmetic >>changes. >> >> So if you're interested in Anchor, please have a look. >> >> Best Regards, >> Stanisław Pitucha >> >> >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > >-- >Darren J Moffat > >_______________________________________________ >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 Wed Jul 22 17:36:19 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 22 Jul 2015 17:36:19 +0000 Subject: [Openstack-security] [openstack/manila] SecurityImpact review request change If9241e6f6ba10592a64ca312cb479e8cea929913 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/204705 Log: commit 0c2a35725766603058ff5641b39a4c35e4dd36ea Author: Valeriy Ponomaryov Date: Wed Jul 22 20:30:42 2015 +0300 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). In order to maintain the backward compatibility, setting wsgi_keep_alive as True by default. Recommended is set it to False. This is port of Cinder change - [1] [1] Ic57b2aceb136e8626388cfe4df72b2f47cb0661c SecurityImpact Closes-Bug: #1361360 Change-Id: If9241e6f6ba10592a64ca312cb479e8cea929913 From 1361360 at bugs.launchpad.net Wed Jul 22 17:36:16 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 22 Jul 2015 17:36:16 -0000 Subject: [Openstack-security] [Bug 1361360] Fix proposed to manila (master) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150722173616.10775.1450.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/204705 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in Keystone: Fix Released Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in Manila: In Progress Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From travis.mcpeak at hp.com Wed Jul 22 19:30:41 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Wed, 22 Jul 2015 19:30:41 -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: <20150722193041.25579.48346.malone@chaenomeles.canonical.com> Since there is unlikely to ever be a patch for the slowloris side of this, I'm opening an OSSN task. ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in Keystone: Fix Released Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in Manila: In Progress Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From stanislaw.pitucha at hp.com Thu Jul 23 09:57:06 2015 From: stanislaw.pitucha at hp.com (Pitucha, Stanislaw Izaak) Date: Thu, 23 Jul 2015 09:57:06 +0000 Subject: [Openstack-security] [Anchor] Almost security-impact review - getting rid of openssl In-Reply-To: <55AF6022.5060709@Oracle.COM> References: <55AF6022.5060709@Oracle.COM> Message-ID: Hi, I really don't mind which implementation for signing is used. cryptography.io provides pkcs#1 signatures, so it can replace pycrypto. However I chose pycrypto because it's smaller and just an established library and doesn't require cffi - it only needs to provide that one function, so lack of functionality is not an issue. So really I'm happy to include either - it's very few lines of code affected. As Rob suggested, I'll submit a spec too. Best Regards, Stanisław Pitucha -----Original Message----- From: Darren J Moffat [mailto:Darren.Moffat at Oracle.COM] Sent: Wednesday, July 22, 2015 7:20 PM To: Pitucha, Stanislaw Izaak; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [Anchor] Almost security-impact review - getting rid of openssl On 07/22/15 05:29, Pitucha, Stanislaw Izaak wrote: > Hi all, > I’d like to get people interested in Anchor development to look at a WIP patch I uploaded now: > https://review.openstack.org/204368 > > It changes the backend of Anchor from relying on openssl (and all the issues that go with it) to using pyasn1/pycrypto to directly operate on the certificate/csr. > While it’s not complete and I’m still waiting for some answers to enable extensions (http://stackoverflow.com/questions/31552798/parsing-x509-extensions-with-pyasn1), it’s functional. By definition – test_functional passes ;) I think this is the exact opposite of the direction we should be going in. pycrypto is old and not well featured. Other parts of OpenStack and dependent projects such as paramiko are moving to cryptography.io which is a modern Python layer over OpenSSL. Please do not add more dependencies on pycrypto. > It’s going to be a big change and take quite some time, so any feedback is appreciated early on. The original rationale for the change can be read at https://etherpad.openstack.org/p/Anchor_direct_asn1 and while there were some issues on the way, I believe that everything I expected to improve, improved a lot. What I’m most happy about is that the change gets rid of magic string parsing / output and memory management of openssl. Things like string and date manipulation either disappeared or got much shorter. Also many error checks are not needed anymore. > > I didn’t correct all function comments, so some of them may mention wrong types. But the interface stayed pretty much the same – higher level functionality like certificate_ops/signing has only cosmetic changes. > > So if you’re interested in Anchor, please have a look. > > Best Regards, > Stanisław Pitucha > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Darren J Moffat -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3508 bytes Desc: not available URL: From gerrit2 at review.openstack.org Thu Jul 23 10:36:59 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 23 Jul 2015 10:36:59 +0000 Subject: [Openstack-security] [openstack/manila] SecurityImpact review request change If9241e6f6ba10592a64ca312cb479e8cea929913 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/204705 Log: commit 6871ef61b800a78aa6a4d4fb67d24aff955163d4 Author: Valeriy Ponomaryov Date: Wed Jul 22 20:30:42 2015 +0300 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). In order to maintain the backward compatibility, setting wsgi_keep_alive as True by default. Recommended is set it to False. This is port of Cinder change - [1] [1] Ic57b2aceb136e8626388cfe4df72b2f47cb0661c SecurityImpact Closes-Bug: #1361360 Change-Id: If9241e6f6ba10592a64ca312cb479e8cea929913 From gerrit2 at review.openstack.org Thu Jul 23 11:22:10 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 23 Jul 2015 11:22:10 +0000 Subject: [Openstack-security] [openstack/manila] SecurityImpact review request change If9241e6f6ba10592a64ca312cb479e8cea929913 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/204705 Log: commit e2278d030de44f011d9b3782add42d2b5e5652c2 Author: Valeriy Ponomaryov Date: Wed Jul 22 20:30:42 2015 +0300 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). In order to maintain the backward compatibility, setting wsgi_keep_alive as True by default. Recommended is set it to False. This is port of Cinder change - [1] [1] Ic57b2aceb136e8626388cfe4df72b2f47cb0661c SecurityImpact Closes-Bug: #1361360 Change-Id: If9241e6f6ba10592a64ca312cb479e8cea929913 From 1464219 at bugs.launchpad.net Thu Jul 23 13:06:44 2015 From: 1464219 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 23 Jul 2015 13:06:44 -0000 Subject: [Openstack-security] [Bug 1464219] Re: [api] there are no checks of request tenant_id during abandoning of an environment References: <20150611110620.13354.78142.malonedeb@wampee.canonical.com> Message-ID: <20150723130644.11540.85579.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/203958 Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=b5b39becc0bc5f4cc2d59968930a4ea75a0b072d Submitter: Jenkins Branch: master commit b5b39becc0bc5f4cc2d59968930a4ea75a0b072d Author: leizhang Date: Tue Jul 21 15:11:46 2015 +0800 Check tenant id during abandoning of an env Add code to check whether current tenant matches the env's tentant Change-Id: Ia6c291261de8951dc779394b993e646ed0c0a9d9 Closes-Bug: #1464219 SecurityImpact ** Changed in: murano Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464219 Title: [api] there are no checks of request tenant_id during abandoning of an environment Status in murano: Fix Committed Bug description: Looks like the code currently does not check, that a given env belongs to current requests tenant. Therefore it might be possible for users from different tenants to delete/deploy environments. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1464219/+subscriptions From 1442343 at bugs.launchpad.net Thu Jul 23 21:29:47 2015 From: 1442343 at bugs.launchpad.net (Alan Pevec) Date: Thu, 23 Jul 2015 21:29:47 -0000 Subject: [Openstack-security] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20150723212947.19486.68481.launchpad@soybean.canonical.com> ** Also affects: keystone/kilo Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in Keystone: Fix Released Status in Keystone kilo series: New Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From 1361360 at bugs.launchpad.net Thu Jul 23 21:29:51 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Thu, 23 Jul 2015 21:29:51 -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: <20150723212951.30580.18040.launchpad@gac.canonical.com> ** Also affects: keystone/kilo Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in Keystone: Fix Released Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in Keystone kilo series: New Status in Manila: In Progress Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1465922 at bugs.launchpad.net Thu Jul 23 21:56:33 2015 From: 1465922 at bugs.launchpad.net (Alan Pevec) Date: Thu, 23 Jul 2015 21:56:33 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150723215635.19961.88465.launchpad@soybean.canonical.com> ** Changed in: keystone/kilo Milestone: None => 2015.1.1 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Committed Status in Keystone juno series: In Progress Status in Keystone kilo series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1451931 at bugs.launchpad.net Thu Jul 23 21:57:51 2015 From: 1451931 at bugs.launchpad.net (Alan Pevec) Date: Thu, 23 Jul 2015 21:57:51 -0000 Subject: [Openstack-security] [Bug 1451931] Re: ironic password config not marked as secret References: <20150505164255.28640.31104.malonedeb@soybean.canonical.com> Message-ID: <20150723215753.30759.76642.launchpad@gac.canonical.com> ** Changed in: nova/kilo Milestone: None => 2015.1.1 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1451931 Title: ironic password config not marked as secret Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: The ironic config option for the password and auth token are not marked as secret so the values will get logged during startup in debug mode. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1451931/+subscriptions From 1442343 at bugs.launchpad.net Thu Jul 23 21:56:36 2015 From: 1442343 at bugs.launchpad.net (Alan Pevec) Date: Thu, 23 Jul 2015 21:56:36 -0000 Subject: [Openstack-security] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20150723215638.19855.22682.launchpad@soybean.canonical.com> ** Changed in: keystone/kilo Status: New => Fix Committed ** Changed in: keystone/kilo Milestone: None => 2015.1.1 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in Keystone: Fix Released Status in Keystone kilo series: Fix Committed Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From 1361360 at bugs.launchpad.net Thu Jul 23 21:56:43 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Thu, 23 Jul 2015 21:56:43 -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: <20150723215647.30716.65650.launchpad@gac.canonical.com> ** Changed in: keystone/kilo Status: New => Fix Committed ** Changed in: keystone/kilo Milestone: None => 2015.1.1 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in Keystone: Fix Released Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Committed Status in Manila: In Progress Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From stanislaw.pitucha at hp.com Fri Jul 24 00:06:38 2015 From: stanislaw.pitucha at hp.com (Pitucha, Stanislaw Izaak) Date: Fri, 24 Jul 2015 00:06:38 +0000 Subject: [Openstack-security] [Anchor] Almost security-impact review - getting rid of openssl In-Reply-To: References: <55AF6022.5060709@Oracle.COM> Message-ID: Now available at https://review.openstack.org/205328 Best Regards, Stanisław Pitucha -----Original Message----- From: Clark, Robert Graham Sent: Wednesday, July 22, 2015 7:50 PM To: Darren J Moffat; Pitucha, Stanislaw Izaak; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [Anchor] Almost security-impact review - getting rid of openssl I tend to agree with Darren. As it's quite a big change I think it should be discussed in a security-specification. -Rob On 22/07/2015 10:19, "Darren J Moffat" wrote: > > >On 07/22/15 05:29, Pitucha, Stanislaw Izaak wrote: >> Hi all, >> I'd like to get people interested in Anchor development to look at a >>WIP patch I uploaded now: >> https://review.openstack.org/204368 >> >> It changes the backend of Anchor from relying on openssl (and all the >>issues that go with it) to using pyasn1/pycrypto to directly operate on >>the certificate/csr. >> While it's not complete and I'm still waiting for some answers to >>enable extensions >>(http://stackoverflow.com/questions/31552798/parsing-x509-extensions-with >>-pyasn1), it's functional. By definition - test_functional passes ;) > >I think this is the exact opposite of the direction we should be going in. > >pycrypto is old and not well featured. Other parts of OpenStack and >dependent projects such as paramiko are moving to cryptography.io which >is a modern Python layer over OpenSSL. > >Please do not add more dependencies on pycrypto. > >> It's going to be a big change and take quite some time, so any feedback >>is appreciated early on. The original rationale for the change can be >>read at https://etherpad.openstack.org/p/Anchor_direct_asn1 and while >>there were some issues on the way, I believe that everything I expected >>to improve, improved a lot. What I'm most happy about is that the change >>gets rid of magic string parsing / output and memory management of >>openssl. Things like string and date manipulation either disappeared or >>got much shorter. Also many error checks are not needed anymore. >> >> I didn't correct all function comments, so some of them may mention >>wrong types. But the interface stayed pretty much the same - higher >>level functionality like certificate_ops/signing has only cosmetic >>changes. >> >> So if you're interested in Anchor, please have a look. >> >> Best Regards, >> Stanisław Pitucha >> >> >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > >-- >Darren J Moffat > >_______________________________________________ >Openstack-security mailing list >Openstack-security at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3508 bytes Desc: not available URL: From jzy99 at hotmail.com Fri Jul 24 00:33:55 2015 From: jzy99 at hotmail.com (=?gb2312?B?va/WvtPC?=) Date: Fri, 24 Jul 2015 08:33:55 +0800 Subject: [Openstack-security] unsubscribe Message-ID: unsubscribe -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Fri Jul 24 13:01:19 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 24 Jul 2015 13:01:19 +0000 Subject: [Openstack-security] [openstack/manila] SecurityImpact review request change If9241e6f6ba10592a64ca312cb479e8cea929913 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/204705 Log: commit 7cd29c83af5c81847b4609441f10f48f782b5410 Author: Valeriy Ponomaryov Date: Wed Jul 22 20:30:42 2015 +0300 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). In order to maintain the backward compatibility, setting wsgi_keep_alive as True by default. Recommended is set it to False. This is port of Cinder change - [1] [1] Ic57b2aceb136e8626388cfe4df72b2f47cb0661c SecurityImpact Closes-Bug: #1361360 Change-Id: If9241e6f6ba10592a64ca312cb479e8cea929913 From gerrit2 at review.openstack.org Mon Jul 27 12:02:52 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 27 Jul 2015 12:02:52 +0000 Subject: [Openstack-security] [openstack-dev/sandbox] SecurityImpact review request change Ifd7793b1c19048c81ebd70b70ec1793fd6873b99 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/206027 Log: commit c25265316322b9a2d05fd9882f99fcb9738aed4b Author: Melvin Hillsman Date: Mon Jul 27 02:09:44 2015 -0500 Brief description of the change being made < 50c This is a long description which can be a simple paragraph of at least three sentences or more. All lines starting with the long description should be wrapped at 72 characters. Things can be tabbed over to provide clarity via whitespace Starting over here is no problem as well DocImpact should be on a line by itself with a comment below on how documenation is impacted. APIImpact should be on a line by itself as well with a comment on how API is impacted. SecurityImpact indicates that review should be done by OpenStack Security Group. Finally but not least UpgradeImpact should be on a line by itself with a comment on why change impacts upgrades. DocImpact Closes-Bug: #0000000 Implements: blueprint some-random-blueprint Co-Authored-By: Another Author Change-Id: Ifd7793b1c19048c81ebd70b70ec1793fd6873b99 From gerrit2 at review.openstack.org Mon Jul 27 12:18:12 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 27 Jul 2015 12:18:12 +0000 Subject: [Openstack-security] [openstack-dev/sandbox] SecurityImpact review request change Ifd7793b1c19048c81ebd70b70ec1793fd6873b99 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/206027 Log: commit cc42df99e5b331091795c3565aa46f205055f599 Author: Melvin Hillsman Date: Mon Jul 27 02:09:44 2015 -0500 Add second file camel.txt This is a long description which can be a simple paragraph of at least three sentences or more. All lines starting with the long description should be wrapped at 72 characters. Things can be tabbed over to provide clarity via whitespace Starting over here is no problem as well DocImpact should be on a line by itself with a comment below on how documenation is impacted. APIImpact should be on a line by itself as well with a comment on how API is impacted. SecurityImpact indicates that review should be done by OpenStack Security Group. Finally but not least UpgradeImpact should be on a line by itself with a comment on why change impacts upgrades. DocImpact Closes-Bug: #0000000 Implements: blueprint some-random-blueprint Co-Authored-By: Another Author Change-Id: Ifd7793b1c19048c81ebd70b70ec1793fd6873b99 From gerrit2 at review.openstack.org Tue Jul 28 09:31:21 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Jul 2015 09:31:21 +0000 Subject: [Openstack-security] [openstack/manila] SecurityImpact review request change If9241e6f6ba10592a64ca312cb479e8cea929913 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/204705 Log: commit accb273c7aa369f624e8062137b356dc3e5589cf Author: Valeriy Ponomaryov Date: Wed Jul 22 20:30:42 2015 +0300 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). In order to maintain the backward compatibility, setting wsgi_keep_alive as True by default. Recommended is set it to False. This is port of Cinder change - [1] [1] Ic57b2aceb136e8626388cfe4df72b2f47cb0661c SecurityImpact Closes-Bug: #1361360 Change-Id: If9241e6f6ba10592a64ca312cb479e8cea929913 From 1361360 at bugs.launchpad.net Tue Jul 28 15:12:27 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 28 Jul 2015 15:12:27 -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: <20150728151227.30134.78608.malone@gac.canonical.com> Reviewed: https://review.openstack.org/204705 Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=accb273c7aa369f624e8062137b356dc3e5589cf Submitter: Jenkins Branch: master commit accb273c7aa369f624e8062137b356dc3e5589cf Author: Valeriy Ponomaryov Date: Wed Jul 22 20:30:42 2015 +0300 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). In order to maintain the backward compatibility, setting wsgi_keep_alive as True by default. Recommended is set it to False. This is port of Cinder change - [1] [1] Ic57b2aceb136e8626388cfe4df72b2f47cb0661c SecurityImpact Closes-Bug: #1361360 Change-Id: If9241e6f6ba10592a64ca312cb479e8cea929913 ** Changed in: manila Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in Keystone: Fix Released Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Committed Status in Manila: Fix Committed Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From doug at doughellmann.com Tue Jul 28 19:41:49 2015 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 28 Jul 2015 19:41:49 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <20150728194151.2625.39192.launchpad@chaenomeles.canonical.com> ** Changed in: horizon Milestone: liberty-2 => liberty-3 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Bug description: The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From doug at doughellmann.com Tue Jul 28 19:58:45 2015 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 28 Jul 2015 19:58:45 -0000 Subject: [Openstack-security] [Bug 1461154] Re: Cross-Frame Scripting (XFS) Clickjacking vulnerability with legacy browsers References: <20150602162757.6123.3584.malonedeb@wampee.canonical.com> Message-ID: <20150728195847.2689.92596.launchpad@chaenomeles.canonical.com> ** Changed in: horizon Status: Fix Committed => Fix Released ** Changed in: horizon Milestone: None => liberty-2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1461154 Title: Cross-Frame Scripting (XFS) Clickjacking vulnerability with legacy browsers Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Vulnerability Details A Cross-Frame Scripting (XFS) vulnerability can allow an attacker to load the vulnerable application inside an HTML iframe tag on a malicious page. Impact An attacker could use XFS to devise a Clickjacking attack to conduct phishing, frame sniffing, social engineering or Cross-Site Request Forgery attacks. Recommendations Set the HTTP X-Frame-Options header to one of the following: DENY - deny any frames SAMEORIGIN - frames are only allowed from the same origin ALLOW-FROM - a list of allowable origin's Although many pages within Horizon 1.1 leverage the X-Frame-Options header with the recommended SAMEORIGIN policy, some (still popular) older browsers don’t support this setting. Namely, browsers older than IE 8 and Firefox 3.6.9 don’t recognize the header and are thus vulnerable to an attack known as ClickJacking unless an additional mitigating control is present. To support legacy browsers, a suggested best practice is to add a frame breaking script to the base/global template file. Based off of https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#Best- for-now_Legacy_Browser_Frame_Breaking_Script """ One way to defend against clickjacking is to include a "frame-breaker" script in each page that should not be framed. The following methodology will prevent a webpage from being framed even in legacy browsers, that do not support the X-Frame-Options-Header. In the document HEAD element, add the following: First apply an ID to the style element itself: And then delete that style by its ID immediately after in the script: This way, everything can be in the document HEAD and you only need one method/taglib in your API. """ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1461154/+subscriptions From gerrit2 at review.openstack.org Wed Jul 29 03:54:14 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 29 Jul 2015 03:54:14 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change I305b2ae86415c8d256c641abb2795af663bee56a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/177948 Log: commit 88036d33cd5e5c4fae24aeb5e6fac5393a2523fe Author: Brianna Poulos Date: Mon Apr 27 15:35:51 2015 -0400 Image Signing and Verification Support This spec describes a means to support signing and signature validation of bootable images. DocImpact SecurityImpact Implements: blueprint encrypted-and-authenticated-image-support Change-Id: I305b2ae86415c8d256c641abb2795af663bee56a From gerrit2 at review.openstack.org Wed Jul 29 09:02:14 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 29 Jul 2015 09:02:14 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/192986 Log: commit 7ab75d5b0b75fc3426323bef19bf436a258b9707 Author: abhishekkekane Date: Mon Jul 6 01:51:26 2015 -0700 libvirt: Kill rsync/scp processes before deleting instance In the resize operation, during copying files from source to destination compute node scp/rsync processes are not aborted after the instance is deleted because linux kernel doesn't delete instance files physically until all processes using the file handle is closed completely. Hence rsync/scp process keeps on running until it transfers 100% of file data. Added new module instancejobtracker to libvirt driver which will add, remove or terminate the processes running against particular instances. Added callback methods to execute call which will store the pid of scp/rsync process in cache as a key: value pair and to remove the pid from the cache after process completion. Process id will be used to kill the process if it is running while deleting the instance. Instance uuid is used as a key in the cache and pid will be the value. SecurityImpact Closes-bug: #1387543 Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9 From gerrit2 at review.openstack.org Wed Jul 29 11:33:18 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 29 Jul 2015 11:33:18 +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 057bb52a6840dc97e52573eb247a1da8ecf72067 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 doug at doughellmann.com Wed Jul 29 14:40:19 2015 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 29 Jul 2015 14:40:19 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150729144022.9260.12122.launchpad@gac.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => liberty-2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Released Status in Keystone juno series: In Progress Status in Keystone kilo series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From travis.mcpeak at hp.com Wed Jul 29 14:45:07 2015 From: travis.mcpeak at hp.com (Travis McPeak) Date: Wed, 29 Jul 2015 14:45:07 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <20150729144507.9595.98036.malone@gac.canonical.com> Throwing back the note task - this should really be taken up by somebody with more domain experience than I have. ** Changed in: ossn Assignee: Travis McPeak (travis-mcpeak) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From efedorova at mirantis.com Tue Jul 7 16:35:33 2015 From: efedorova at mirantis.com (Ekaterina Chernova) Date: Tue, 07 Jul 2015 16:35:33 -0000 Subject: [Openstack-security] [Bug 1472331] [NEW] Trust id is not hidden in logs References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Message-ID: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Public bug reported: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token ** Affects: murano Importance: High Status: Confirmed ** Tags: low-hanging-fruit security ** Changed in: murano Milestone: 2014.2.3 => liberty-2 ** Tags added: security ** Tags added: low-hanging-fruit -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472331 Title: Trust id is not hidden in logs Status in Murano: Confirmed Bug description: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1472331/+subscriptions From lin.a.yang at intel.com Wed Jul 8 02:40:53 2015 From: lin.a.yang at intel.com (Lin Yang) Date: Wed, 08 Jul 2015 02:40:53 -0000 Subject: [Openstack-security] [Bug 1472331] Re: Trust id is not hidden in logs References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Message-ID: <20150708023457.14847.75071.launchpad@wampee.canonical.com> ** Changed in: murano Assignee: (unassigned) => Lin Yang (lin-a-yang) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472331 Title: Trust id is not hidden in logs Status in Murano: Confirmed Bug description: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1472331/+subscriptions From lin.a.yang at intel.com Wed Jul 8 05:55:39 2015 From: lin.a.yang at intel.com (Lin Yang) Date: Wed, 08 Jul 2015 05:55:39 -0000 Subject: [Openstack-security] [Bug 1472331] Re: Trust id is not hidden in logs References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Message-ID: <20150708054837.14391.94129.launchpad@wampee.canonical.com> ** Changed in: murano Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472331 Title: Trust id is not hidden in logs Status in Murano: In Progress Bug description: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1472331/+subscriptions From jokke at hp.com Thu Jul 9 09:20:53 2015 From: jokke at hp.com (Erno Kuvaja) Date: Thu, 09 Jul 2015 09:20:53 -0000 Subject: [Openstack-security] [Bug 1470740] Re: swiftclient disclose token in debug logs References: <20150702071356.30766.53174.malonedeb@soybean.canonical.com> Message-ID: <20150709091419.4544.52627.launchpad@gac.canonical.com> ** No longer affects: glance -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1470740 Title: swiftclient disclose token in debug logs Status in OpenStack Security Notes: New Status in Python client library for Swift: New Bug description: Setup: juno. Nova, glance + swiftclient. glance-api.conf (important parts): [DEFAULT] debug = true logging_context_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s [%(request_id)s %(user)s %(tenant)s] logging_default_format_string=%(name)s[%(process)d]: %(levelname)s %(instance)s%(message)s logging_debug_format_suffix=%(funcName)s %(pathname)s:%(lineno)d logging_exception_prefix=%(name)s[%(process)d]: TRACE %(instance)s default_store = swift use_syslog = True syslog_log_facility = LOG_LOCAL2 swift_store_auth_address = https://my.hand.disclosing.corporte.url:5000/v2.0 swift_store_user = tenant:user swift_store_key = sexgodqwerty123456love Result in remote syslog: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6f64276e2074726461650a6d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 Versions: ii python-swift 2.2.0-0ubuntu1~cloud0 all distributed virtual object store - Python libraries ii python-swiftclient 1:2.3.0-0ubuntu1~cloud0 all Client library for Openstack Swift API. ii glance-api 1:2014.2.3-0-ownbuild all OpenStack Image Registry and Delivery Service - API ii glance-common 1:2014.2.3-ownbuild all OpenStack Image Registry and Delivery Service - Common ii python-glance 1:2014.2.3-0ownbuild all OpenStack Image Registry and Delivery Service - Python library ii python-glance-store 0.1.8-1ubuntu2~cloud0 all OpenStack Image Service store library - Python 2.x ii python-glanceclient 1:0.14.0-0ubuntu1~cloud0 all Client library for Openstack glance server. Impact: 1) Unprivileged employee with access to logging facility may get access to glance images, including snapshots of the tenants. 2) Syslog transmitted unencrypted in UDP or TCP and it may be viewed by unauthorized person. Expected behavior: Complete or partial token masking in logs, f.e.: DEBUG REQ: curl -i https://my.hand.disclosing.corporte.url:8080/v1/OMG_47e02d5a461148ef9f9dab62ea0ba64b/region/6a66d8dc-5748-4cb5-9db5-b12ab0d1c698-00007 -X PUT -H "X-Auth-Token: 6****************d" http_log /usr/lib/python2.7/dist-packages/swiftclient/client.py:95 To manage notifications about this bug go to: https://bugs.launchpad.net/ossn/+bug/1470740/+subscriptions From pkarikh at mirantis.com Thu Jul 16 14:57:20 2015 From: pkarikh at mirantis.com (Paul Karikh) Date: Thu, 16 Jul 2015 14:57:20 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150716145720.25914.25353.malone@chaenomeles.canonical.com> I had a conversation with Lin Hua Cheng in IRC about this bug, and looks like we have nothing to do with this bug since it is a Django bug and since we cannot restrict user to use only exact version. As far as I understand, the only thing is should be done is to mention this bug and django version with fix in the security notes. So I set "won't fix" status for this bug in Horizon, if there is no objections. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From pkarikh at mirantis.com Thu Jul 16 15:00:27 2015 From: pkarikh at mirantis.com (Paul Karikh) Date: Thu, 16 Jul 2015 15:00:27 -0000 Subject: [Openstack-security] [Bug 1457551] Re: Another Horizon login page vulnerability to a DoS attack References: <20150521160741.5911.30892.malonedeb@gac.canonical.com> Message-ID: <20150716150027.25845.43718.malone@chaenomeles.canonical.com> Oh, looks like I have no permissions to set it to won't wix. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1457551 Title: Another Horizon login page vulnerability to a DoS attack Status in OpenStack Dashboard (Horizon): Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This bug is very similar to: https://bugs.launchpad.net/bugs/1394370 Steps to reproduce: 1) Setup Horizon to use db as session engine (using this doc: http://docs.openstack.org/admin-guide-cloud/content/dashboard-session-database.html). I've used MySQL. 2) Run 'for i in {1..100}; do curl -b "sessionid=aaaaa;" http://HORIZON__IP/auth/login/ &> /dev/null; done' from your terminal. I've got 100 rows in django_session after this. I've used devstack installation just with updated master branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1457551/+subscriptions From akarora at cisco.com Mon Jul 20 03:28:24 2015 From: akarora at cisco.com (Anshul Arora (akarora)) Date: Mon, 20 Jul 2015 03:28:24 +0000 Subject: [Openstack-security] ARP responder and L-2 population Message-ID: Folks, I've a query related to this topic. In the Neutron plugin.ini file, there are two parameters : L2 population and ARP responder. Based on the documentation it's not clear in which used cases these parameters are mandatory. For ex is it just for VLAN/GRE or VLAN based implementation must have them configured also to prevent broadcast storms. The confusion kicks in just because ARP responder is an option parameter that is not turned on by default. Thanks, -Anshul -------------- next part -------------- An HTML attachment was scrubbed... URL: From lei.a.zhang at intel.com Mon Jul 20 15:58:12 2015 From: lei.a.zhang at intel.com (Lei Zhang) Date: Mon, 20 Jul 2015 15:58:12 -0000 Subject: [Openstack-security] [Bug 1464219] Re: [api] there are no checks of request tenant_id during abandoning of an environment References: <20150611110620.13354.78142.malonedeb@wampee.canonical.com> Message-ID: <20150720155814.19673.62699.launchpad@soybean.canonical.com> ** Changed in: murano Assignee: (unassigned) => Lei Zhang (lei-a-zhang) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464219 Title: [api] there are no checks of request tenant_id during abandoning of an environment Status in murano: Confirmed Bug description: Looks like the code currently does not check, that a given env belongs to current requests tenant. Therefore it might be possible for users from different tenants to delete/deploy environments. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1464219/+subscriptions From kathleen.fischer at vencore.com Tue Jul 21 20:42:30 2015 From: kathleen.fischer at vencore.com (Kathleen Fischer) Date: Tue, 21 Jul 2015 20:42:30 -0000 Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used to login horizon References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com> Message-ID: <20150721204230.20188.22453.malone@soybean.canonical.com> This is something that definitely needs to be fixed. If Open Stack is to be approved for use by the Federal Gov't in any manner, all users and service accounts have to be able to abide by least privilege requirements and not be granted elevated privilege by default. A service account must be able to have access managed at the function of the service, not granted full cloud admin user rights. I am late into this conversation, hoping I am reading this wrong. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions From thierry.carrez+lp at gmail.com Tue Jul 28 09:11:03 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Tue, 28 Jul 2015 09:11:03 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150728091107.25878.72250.launchpad@chaenomeles.canonical.com> ** Changed in: sahara Milestone: liberty-2 => liberty-3 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in Keystone: Fix Released Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Committed Status in Manila: In Progress Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From thierry.carrez+lp at gmail.com Wed Jul 29 14:07:19 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 29 Jul 2015 14:07:19 -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: <20150729140724.8945.43709.launchpad@gac.canonical.com> ** Changed in: manila Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in Keystone: Fix Released Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Committed Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Wed Jul 29 17:55:31 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 29 Jul 2015 17:55:31 +0000 Subject: [Openstack-security] [openstack/ceilometer-specs] SecurityImpact review request change Id25d154eac90e14c5501f806e81e04a059f5a836 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/207141 Log: commit b48684596dfa3f372331bbaa260ccff390686f4d Author: Matthew Edmonds Date: Wed Jul 29 13:45:23 2015 -0400 Events RBAC via Policy OpenStack needs to support granular, customizable Role-Based Access Control (RBAC) for ceilometer events. Policy should be dependent on policy.json rather than simply hard-coded. APIImpact SecurityImpact UpgradeImpact Change-Id: Id25d154eac90e14c5501f806e81e04a059f5a836 From doug at doughellmann.com Wed Jul 29 18:57:53 2015 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 29 Jul 2015 18:57:53 -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: <20150729185757.28165.47921.launchpad@wampee.canonical.com> ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in neutron: Fix Released Status in OpenStack Security Advisory: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From gerrit2 at review.openstack.org Wed Jul 29 21:30:19 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 29 Jul 2015 21:30:19 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/207226 Log: commit 021aa2785f7dd3a16f1b063242a6ad92bc85ab1f Author: Brant Knudson Date: Wed Jul 29 16:29:42 2015 -0500 Config option for insecure reponses oslo.log's "debug" option was coopted to also indicate that the responses should include more information. A separate config option should be used instead so that deployers don't mistakenly expose themselves to security issues. SecurityImpact Change-Id: Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Closes-Bug: 1479523 From 1479523 at bugs.launchpad.net Wed Jul 29 21:30:18 2015 From: 1479523 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 29 Jul 2015 21:30:18 -0000 Subject: [Openstack-security] [Bug 1479523] Re: Stop using debug for insecure responses References: <20150729211446.8945.2269.malonedeb@gac.canonical.com> Message-ID: <20150729213018.2606.7273.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/207226 ** Changed in: keystone Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1479523 Title: Stop using debug for insecure responses Status in Keystone: In Progress Bug description: If you set debug=true in keystone.conf the server 1) logs at debug level, and 2) sends out insecure responses. Deployers might think that debug=true only does 1, not knowing about 2 since it's not documented in the sample config. The behaviors should be decoupled to improve security a bit. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1479523/+subscriptions From 1479523 at bugs.launchpad.net Wed Jul 29 21:44:03 2015 From: 1479523 at bugs.launchpad.net (Dolph Mathews) Date: Wed, 29 Jul 2015 21:44:03 -0000 Subject: [Openstack-security] [Bug 1479523] Re: Stop using debug for insecure responses References: <20150729211446.8945.2269.malonedeb@gac.canonical.com> Message-ID: <20150729214403.27969.71167.malone@wampee.canonical.com> Setting this to Wishlist because it should be included in release notes. ** Changed in: keystone Importance: Undecided => Wishlist -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1479523 Title: Stop using debug for insecure responses Status in Keystone: In Progress Bug description: If you set debug=true in keystone.conf the server 1) logs at debug level, and 2) sends out insecure responses. Deployers might think that debug=true only does 1, not knowing about 2 since it's not documented in the sample config. The behaviors should be decoupled to improve security a bit. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1479523/+subscriptions From 1465922 at bugs.launchpad.net Wed Jul 29 21:45:41 2015 From: 1465922 at bugs.launchpad.net (Alan Pevec) Date: Wed, 29 Jul 2015 21:45:41 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20150729214543.2720.17894.launchpad@chaenomeles.canonical.com> ** Changed in: keystone/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Released Status in Keystone juno series: In Progress Status in Keystone kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From 1451931 at bugs.launchpad.net Wed Jul 29 21:47:15 2015 From: 1451931 at bugs.launchpad.net (Alan Pevec) Date: Wed, 29 Jul 2015 21:47:15 -0000 Subject: [Openstack-security] [Bug 1451931] Re: ironic password config not marked as secret References: <20150505164255.28640.31104.malonedeb@soybean.canonical.com> Message-ID: <20150729214718.9595.31523.launchpad@gac.canonical.com> ** Changed in: nova/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1451931 Title: ironic password config not marked as secret Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: The ironic config option for the password and auth token are not marked as secret so the values will get logged during startup in debug mode. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1451931/+subscriptions From 1442343 at bugs.launchpad.net Wed Jul 29 21:45:44 2015 From: 1442343 at bugs.launchpad.net (Alan Pevec) Date: Wed, 29 Jul 2015 21:45:44 -0000 Subject: [Openstack-security] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20150729214548.2195.16696.launchpad@soybean.canonical.com> ** Changed in: keystone/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in Keystone: Fix Released Status in Keystone kilo series: Fix Released Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From 1361360 at bugs.launchpad.net Wed Jul 29 21:45:49 2015 From: 1361360 at bugs.launchpad.net (Alan Pevec) Date: Wed, 29 Jul 2015 21:45:49 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150729214556.28517.31733.launchpad@wampee.canonical.com> ** Changed in: keystone/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in Keystone: Fix Released Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Wed Jul 29 22:12:12 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 29 Jul 2015 22:12:12 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/207226 Log: commit c384523260754950be009e546a5c3cdd0c38ca2f Author: Brant Knudson Date: Wed Jul 29 16:29:42 2015 -0500 Config option for insecure responses oslo.log's "debug" option was coopted to also indicate that the responses should include more information. A separate config option should be used instead so that deployers don't mistakenly expose themselves to security issues. SecurityImpact Change-Id: Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Closes-Bug: 1479523 From gerrit2 at review.openstack.org Thu Jul 30 13:04:07 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 Jul 2015 13:04:07 +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 2a9c79f9ca2e94834b28afb06b82ad2f26c29276 Author: Daniel Genin Date: Thu Feb 5 09:28:16 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. Co-Authored-By: Joel Coffman Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From 1442787 at bugs.launchpad.net Fri Jul 31 20:37:25 2015 From: 1442787 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 31 Jul 2015 20:37:25 -0000 Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user attribute in k2k assertions with different domains References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com> Message-ID: <20150731203725.6297.64131.malone@gac.canonical.com> Reviewed: https://review.openstack.org/181007 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=e9aa2673928c265f6592334e737c2bbafeb0026b Submitter: Jenkins Branch: stable/kilo commit e9aa2673928c265f6592334e737c2bbafeb0026b Author: Rodrigo Duarte Sousa Date: Fri Apr 10 17:27:12 2015 -0300 Add openstack_user_domain to assertion Currently, a keystone IdP does not provide the domain of the user when generating SAML assertions. Since it is possible to have two users with the same username but in different domains, this patch adds an additional attribute called "openstack_user_domain" in the assertion to identify the domain of the user. Closes-Bug: 1442787 bp assertion-extra-attributes Change-Id: I65d5c02c0a21f4d4c1b54f8aa56e27950d20badd (cherry picked from commit ae2d7075ff58e426e324e2eac57c852ffd4bc804) ** Tags added: in-stable-kilo -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in Keystone: Fix Released Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions From jesse.pretorius at gmail.com Wed Jul 29 18:12:24 2015 From: jesse.pretorius at gmail.com (Jesse Pretorius) Date: Wed, 29 Jul 2015 18:12:24 -0000 Subject: [Openstack-security] [Bug 1412393] Re: mariadb repo unnecessarily configured in all containers References: <20150119110012.23998.45109.malonedeb@gac.canonical.com> Message-ID: <20150729181227.2823.67416.launchpad@chaenomeles.canonical.com> ** Changed in: openstack-ansible/juno Status: Confirmed => Won't Fix ** Changed in: openstack-ansible/kilo Status: Confirmed => Fix Released ** Changed in: openstack-ansible/trunk Status: Confirmed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1412393 Title: mariadb repo unnecessarily configured in all containers Status in openstack-ansible: Fix Released Status in openstack-ansible icehouse series: Won't Fix Status in openstack-ansible juno series: Won't Fix Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible trunk series: Fix Released 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