From 1129748 at bugs.launchpad.net Tue Mar 1 03:27:32 2016 From: 1129748 at bugs.launchpad.net (Rodney Beede) Date: Tue, 01 Mar 2016 03:27:32 -0000 Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should not be world-readable References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com> Message-ID: <20160301032732.1528.61723.malone@chaenomeles.canonical.com> This would be a good hardening opportunity. One use case is you may have unprivileged user accounts that are used for services like monitoring or OS backups unrelated to the OpenStack images themselves. Especially for monitoring these accounts may have basic remote login capability. Not allowing the unprivileged accounts access via the world read/x bits would be useful. So perhaps a hardening option that ideally the code would follow a more secure UMASK as well. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Won't Fix Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions From 1549547 at bugs.launchpad.net Tue Mar 1 19:57:13 2016 From: 1549547 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 01 Mar 2016 19:57:13 -0000 Subject: [Openstack-security] [Bug 1549547] Re: LBaaS leaking password in DEBUG logs References: <20160225002843.1623.41446.malonedeb@wampee.canonical.com> Message-ID: <20160301195713.2130.21311.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/285524 Committed: https://git.openstack.org/cgit/openstack/neutron-lbaas/commit/?id=58e78d50136d7ac498faaace53f52e26b7164a2f Submitter: Jenkins Branch: stable/liberty commit 58e78d50136d7ac498faaace53f52e26b7164a2f Author: James Arendt Date: Wed Feb 24 16:23:45 2016 -0800 Neutron LBaaS leaking admin_password into logs Current code leaks the keystone admin_password in the cfg into log files. Example from DevStack q-svc.log: service_auth.admin_password = password Issue is that the cfg.StrOpt for admin_password did not set 'secret=True", which would give: service_auth.admin_password = **** Change-Id: I24410641ad48b2e86984b383b144e29478a94344 Closes-Bug: #1549547 (cherry picked from commit 182dd4238f6f9c3f238fe4aba8017437a52d3a7b) ** Tags added: in-stable-liberty -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1549547 Title: LBaaS leaking password in DEBUG logs Status in neutron: New Status in OpenStack Security Advisory: Won't Fix Bug description: Current code leaks the keystone admin_password in the cfg into log files: Example from DevStack q-svc.log: [00;32mDEBUG oslo_service.service [^[[00;36m-^[[00;32m] ^[[01;35m^[[00;32mservice_auth.admin_password = password Issue is that the cfg.StrOpt for admin_password did not set 'secret=True", which would give: service_auth.admin_password = **** To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1549547/+subscriptions From 832507 at bugs.launchpad.net Wed Mar 2 14:53:32 2016 From: 832507 at bugs.launchpad.net (Daniel Berrange) Date: Wed, 02 Mar 2016 14:53:32 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20160302145332.32746.59283.malone@wampee.canonical.com> Patches are ready to solve this entirely in the libvirt layer one & for all. It'll be fixed with libvirt 1.3.3 https://www.redhat.com/archives/libvir-list/2016-February/msg01449.html -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (nova): Confirmed Status in OpenStack Security Advisory: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From morgan.fainberg at gmail.com Wed Mar 2 16:34:16 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 02 Mar 2016 16:34:16 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <20160302163418.2054.79319.launchpad@wampee.canonical.com> ** Changed in: keystone Status: New => Triaged -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): Triaged Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From morgan.fainberg at gmail.com Wed Mar 2 16:41:02 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 02 Mar 2016 16:41:02 -0000 Subject: [Openstack-security] [Bug 1071815] Re: auth_token middleware does not check if an endpoint is in the service catalog References: <20121026164130.13962.23200.malonedeb@gac.canonical.com> Message-ID: <20160302164105.1816.68309.launchpad@wampee.canonical.com> ** Project changed: keystone => keystonemiddleware -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1071815 Title: auth_token middleware does not check if an endpoint is in the service catalog Status in keystonemiddleware: Triaged Bug description: We include the catalog in the token, but it is not checked. Thus, a token that is intended for a subset of the endpoints can be used on additional endpoints. This prevents a user from creating a token specific to an endpoint. The comparable mechanism is service tickets in Kerberos. If a rogue service gets a ticket in Kerberos, it cannot reuse that ticket elsewhere. WIth the current token scheme, all tokens on a compromised server are at risk of being abused throughout an openstack deployment. To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1071815/+subscriptions From morgan.fainberg at gmail.com Wed Mar 2 20:57:18 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 02 Mar 2016 20:57:18 -0000 Subject: [Openstack-security] [Bug 1534284] Re: keystoneclient should not use etree XML parsing References: <20160114194930.29365.34205.malonedeb@chaenomeles.canonical.com> Message-ID: <20160302205720.1793.11794.malone@chaenomeles.canonical.com> Marking this as "wont fix" against KSC as it shouldn't be needed long term (Session, AuthPlugins, and CLI are all being removed soon/are deprecated) ** Changed in: python-keystoneclient 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/1534284 Title: keystoneclient should not use etree XML parsing Status in keystoneauth: Triaged Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: Won't Fix Bug description: XML parsing is surprisingly difficult and fraught with danger, for example entity expansion makes it easy to cause a lot of memory to be used and therefore crash your system. keystoneclient is using etree parsing which has these potential issues, although in the case of keystoneclient it's the response from the IdP which I think is generally trusted. This is in python- keystoneclient/keystoneclient/contrib/auth/v3/saml2.py There's a defusedxml parser that has protections against these attacks and should therefore be used instead if possible - https://pypi.python.org/pypi/defusedxml - the docs for this page also include some examples of other possible attacks. This was caught by bandit 0.17.0. I'm going to start this out as private security so we can think about it some more before it goes public, even though it's probably not something that needs an issue since I think the source is generally trusted. If you can't trust your IdP then who can you trust? To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1534284/+subscriptions From morgan.fainberg at gmail.com Wed Mar 2 21:30:26 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 02 Mar 2016 21:30:26 -0000 Subject: [Openstack-security] [Bug 1268751] Re: Potential token revocation abuse via group membership References: <20140113215431.25014.35474.malonedeb@chaenomeles.canonical.com> Message-ID: <20160302213028.1707.98785.launchpad@gac.canonical.com> ** Changed in: keystone Importance: High => Low ** Changed in: keystone Importance: Low => Wishlist -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1268751 Title: Potential token revocation abuse via group membership Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: If a group is deleted, all tokens for all users that are a member of that group are revoked. This leads to potential abuse: 1. A group admin adds a user to a group without users knowledge 2. User creates token 3. Admin deletes group. 4. All of the users tokens are revoked. Admittedly, this abuse must be instigated by a group admin, which is the global admin in the default policy file, but an alternative policy file could allow for the delegation of "add user to group" behavior. In such a system, this could act as a denial of service attack for a set of users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1268751/+subscriptions From 1268751 at bugs.launchpad.net Wed Mar 2 21:32:24 2016 From: 1268751 at bugs.launchpad.net (Adam Young) Date: Wed, 02 Mar 2016 21:32:24 -0000 Subject: [Openstack-security] [Bug 1268751] Re: Potential token revocation abuse via group membership References: <20140113215431.25014.35474.malonedeb@chaenomeles.canonical.com> Message-ID: <20160302213224.1884.79885.malone@gac.canonical.com> This is only a problem when using revoke by ID. It will get cleaned up as a side effect of going to Fernet and using revocation events. Since it has hit no-one in the wild, lowering the priority. ** Changed in: keystone Importance: Wishlist => Low -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1268751 Title: Potential token revocation abuse via group membership Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: If a group is deleted, all tokens for all users that are a member of that group are revoked. This leads to potential abuse: 1. A group admin adds a user to a group without users knowledge 2. User creates token 3. Admin deletes group. 4. All of the users tokens are revoked. Admittedly, this abuse must be instigated by a group admin, which is the global admin in the default policy file, but an alternative policy file could allow for the delegation of "add user to group" behavior. In such a system, this could act as a denial of service attack for a set of users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1268751/+subscriptions From morgan.fainberg at gmail.com Wed Mar 2 21:38:49 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 02 Mar 2016 21:38:49 -0000 Subject: [Openstack-security] [Bug 1305566] Re: the token still can be used if the EC2 credential has been deleted References: <20140410083249.25765.8738.malonedeb@soybean.canonical.com> Message-ID: <20160302213852.1623.12480.launchpad@wampee.canonical.com> ** Changed in: keystone Importance: Medium => Low -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1305566 Title: the token still can be used if the EC2 credential has been deleted Status in OpenStack Identity (keystone): Confirmed Bug description: Currently, the associated tokens are not deleted when deleting ec2 credential. So, the token got before can still be used. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1305566/+subscriptions From vryzhenkin at mirantis.com Wed Mar 2 22:10:13 2016 From: vryzhenkin at mirantis.com (Victor Ryzhenkin) Date: Wed, 02 Mar 2016 22:10:13 -0000 Subject: [Openstack-security] [Bug 1552291] Re: User with permissions can not set 'unshared' Murano package to 'shared' References: <20160302155143.1515.80235.malonedeb@soybean.canonical.com> Message-ID: <20160302221014.2202.69908.launchpad@wampee.canonical.com> ** Information type changed from Public to Private Security ** Tags added: liberty-backport-potential security ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1552291 Title: User with permissions can not set 'unshared' Murano package to 'shared' Status in Murano: Triaged Status in Murano liberty series: Triaged Status in Murano mitaka series: Triaged Bug description: Hello, Please take a look at the issue below. Globally the problem is that user with permissions can't update Murano package. My env is: MOS 8.0 with ISO:589 (HA with vlan, murano, cinder and disabled SSL: 2x controllers; 3x compute,cinder) Actions performed from controller: 1) OK - Perform actions as admin user: # . openrc 2) OK - Create new role: # openstack role create 'can_publicize_packages' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 3) OK - List roles: # openstack role list +----------------------------------+------------------------+ | ID | Name | +----------------------------------+------------------------+ . . . . | cdb2bf1c7cba4c188792481e9bfdf449 | can_publicize_packages | +----------------------------------+------------------------+ 4) OK - Create new user inside 'services' project: # openstack user create '_test_user' --password 'password' --project 'services' +------------+----------------------------------+ | Field | Value | +------------+----------------------------------+ | email | None | | enabled | True | | id | e9783de276d64c0189df2c5a5ff79a63 | | name | _test_user | | project_id | fa38dcb711a24e979f1cd88486a9965e | | username | _test_user | +------------+----------------------------------+ 5) OK - Assign new role to the new user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 6) NOK - Check new role for : # openstack user role list '_test_user' {empty output} \\ I suppose it is expected to have some output here. 7) OK - Try to assign again the same role to the same user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' Conflict occurred attempting to store role grant - User e9783de276d64c0189df2c5a5ff79a63 already has role cdb2bf1c7cba4c188792481e9bfdf449 in tenant fa38dcb711a24e979f1cd88486a9965e (HTTP 409) (Request-ID: req-90460dca-6001-4c1d-90de-212aec294942) \\ So, seems, that role was actually assigned to the user. 5) OK - On all two controllers add new role to /etc/murano/policy.json: # cp /etc/murano/policy.json /etc/murano/policy.json_orig # vim /etc/murano/policy.json from: "publicize_package": "rule:admin_api", to: "publicize_package": "rule:admin_api or role:can_publicize_packages", ### The same with: "publicize_package": ["rule:admin_api", "role:can_publicize_packages"], 6) OK - On all two controllers restart some Murano services: # service murano-api restart ; service murano-engine restart murano-api stop/waiting murano-api start/running, process 5597 murano-engine stop/waiting murano-engine start/running, process 5627 6) OK - Change env to '_test_user' and 'services' project: # export OS_TENANT_NAME='services' ; export OS_PROJECT_NAME='services' ; export OS_USERNAME='_test_user' ; export OS_PASSWORD='password' 7) OK - As a '_test_user' import Murano pkg: # murano --murano-repo-url=http://storage.apps.openstack.org package-import 'io.murano.apps.docker.Interfaces' Package file 'io.murano.apps.docker.Interfaces' does not exist, attempting to download Importing package io.murano.apps.docker.Interfaces +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | ID | Name | FQN | Author | Is Public | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | 90fee6d0e41b441f9e8c4b29d89497aa | Core library | io.murano | murano.io | True | | 6c36dc3f149744ca8b18c5e1527b74ef | Docker Interface Library | io.murano.apps.docker.Interfaces | Mirantis, Inc | | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ 8) NOK - As a '_test_user' update imported pkg with Public=TRUE: # murano package-update '6c36dc3f149744ca8b18c5e1527b74ef' --is-public true 403 Forbidden: Access was denied to this resource. (HTTP 403) \\ After step (5) it is expected for a new user to have ability to update imported packages. Please find logs for the last step (8) attached. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1552291/+subscriptions From 1552291 at bugs.launchpad.net Wed Mar 2 22:22:13 2016 From: 1552291 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 02 Mar 2016 22:22:13 -0000 Subject: [Openstack-security] [Bug 1552291] Re: User with permissions can not set 'unshared' Murano package to 'shared' References: <20160302155143.1515.80235.malonedeb@soybean.canonical.com> Message-ID: <20160302222214.1518.79223.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/287480 ** Changed in: murano Status: Triaged => In Progress ** Changed in: murano 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/1552291 Title: User with permissions can not set 'unshared' Murano package to 'shared' Status in Murano: In Progress Status in Murano liberty series: Triaged Status in Murano mitaka series: In Progress Bug description: Hello, Please take a look at the issue below. Globally the problem is that user with permissions can't update Murano package. My env is: MOS 8.0 with ISO:589 (HA with vlan, murano, cinder and disabled SSL: 2x controllers; 3x compute,cinder) Actions performed from controller: 1) OK - Perform actions as admin user: # . openrc 2) OK - Create new role: # openstack role create 'can_publicize_packages' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 3) OK - List roles: # openstack role list +----------------------------------+------------------------+ | ID | Name | +----------------------------------+------------------------+ . . . . | cdb2bf1c7cba4c188792481e9bfdf449 | can_publicize_packages | +----------------------------------+------------------------+ 4) OK - Create new user inside 'services' project: # openstack user create '_test_user' --password 'password' --project 'services' +------------+----------------------------------+ | Field | Value | +------------+----------------------------------+ | email | None | | enabled | True | | id | e9783de276d64c0189df2c5a5ff79a63 | | name | _test_user | | project_id | fa38dcb711a24e979f1cd88486a9965e | | username | _test_user | +------------+----------------------------------+ 5) OK - Assign new role to the new user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 6) NOK - Check new role for : # openstack user role list '_test_user' {empty output} \\ I suppose it is expected to have some output here. 7) OK - Try to assign again the same role to the same user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' Conflict occurred attempting to store role grant - User e9783de276d64c0189df2c5a5ff79a63 already has role cdb2bf1c7cba4c188792481e9bfdf449 in tenant fa38dcb711a24e979f1cd88486a9965e (HTTP 409) (Request-ID: req-90460dca-6001-4c1d-90de-212aec294942) \\ So, seems, that role was actually assigned to the user. 5) OK - On all two controllers add new role to /etc/murano/policy.json: # cp /etc/murano/policy.json /etc/murano/policy.json_orig # vim /etc/murano/policy.json from: "publicize_package": "rule:admin_api", to: "publicize_package": "rule:admin_api or role:can_publicize_packages", ### The same with: "publicize_package": ["rule:admin_api", "role:can_publicize_packages"], 6) OK - On all two controllers restart some Murano services: # service murano-api restart ; service murano-engine restart murano-api stop/waiting murano-api start/running, process 5597 murano-engine stop/waiting murano-engine start/running, process 5627 6) OK - Change env to '_test_user' and 'services' project: # export OS_TENANT_NAME='services' ; export OS_PROJECT_NAME='services' ; export OS_USERNAME='_test_user' ; export OS_PASSWORD='password' 7) OK - As a '_test_user' import Murano pkg: # murano --murano-repo-url=http://storage.apps.openstack.org package-import 'io.murano.apps.docker.Interfaces' Package file 'io.murano.apps.docker.Interfaces' does not exist, attempting to download Importing package io.murano.apps.docker.Interfaces +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | ID | Name | FQN | Author | Is Public | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | 90fee6d0e41b441f9e8c4b29d89497aa | Core library | io.murano | murano.io | True | | 6c36dc3f149744ca8b18c5e1527b74ef | Docker Interface Library | io.murano.apps.docker.Interfaces | Mirantis, Inc | | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ 8) NOK - As a '_test_user' update imported pkg with Public=TRUE: # murano package-update '6c36dc3f149744ca8b18c5e1527b74ef' --is-public true 403 Forbidden: Access was denied to this resource. (HTTP 403) \\ After step (5) it is expected for a new user to have ability to update imported packages. Please find logs for the last step (8) attached. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1552291/+subscriptions From morgan.fainberg at gmail.com Thu Mar 3 07:17:59 2016 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Thu, 03 Mar 2016 07:17:59 -0000 Subject: [Openstack-security] [Bug 1534284] Re: keystoneauth auth plugins should not use etree XML parsing References: <20160114194930.29365.34205.malonedeb@chaenomeles.canonical.com> Message-ID: <20160303071800.1485.69800.launchpad@gac.canonical.com> ** Summary changed: - keystoneclient should not use etree XML parsing + keystoneauth auth plugins should not use etree XML parsing -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534284 Title: keystoneauth auth plugins should not use etree XML parsing Status in keystoneauth: Triaged Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: Won't Fix Bug description: XML parsing is surprisingly difficult and fraught with danger, for example entity expansion makes it easy to cause a lot of memory to be used and therefore crash your system. keystoneclient is using etree parsing which has these potential issues, although in the case of keystoneclient it's the response from the IdP which I think is generally trusted. This is in python- keystoneclient/keystoneclient/contrib/auth/v3/saml2.py There's a defusedxml parser that has protections against these attacks and should therefore be used instead if possible - https://pypi.python.org/pypi/defusedxml - the docs for this page also include some examples of other possible attacks. This was caught by bandit 0.17.0. I'm going to start this out as private security so we can think about it some more before it goes public, even though it's probably not something that needs an issue since I think the source is generally trusted. If you can't trust your IdP then who can you trust? To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1534284/+subscriptions From thierry.carrez+lp at gmail.com Thu Mar 3 10:04:37 2016 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 03 Mar 2016 10:04:37 -0000 Subject: [Openstack-security] [Bug 1549547] Fix included in openstack/neutron-lbaas 8.0.0.0b3 References: <20160225002843.1623.41446.malonedeb@wampee.canonical.com> Message-ID: <20160303100437.1847.10503.malone@gac.canonical.com> This issue was fixed in the openstack/neutron-lbaas 8.0.0.0b3 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1549547 Title: LBaaS leaking password in DEBUG logs Status in neutron: New Status in OpenStack Security Advisory: Won't Fix Bug description: Current code leaks the keystone admin_password in the cfg into log files: Example from DevStack q-svc.log: [00;32mDEBUG oslo_service.service [^[[00;36m-^[[00;32m] ^[[01;35m^[[00;32mservice_auth.admin_password = password Issue is that the cfg.StrOpt for admin_password did not set 'secret=True", which would give: service_auth.admin_password = **** To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1549547/+subscriptions From 1552291 at bugs.launchpad.net Thu Mar 3 13:49:57 2016 From: 1552291 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 03 Mar 2016 13:49:57 -0000 Subject: [Openstack-security] [Bug 1552291] Re: User with permissions can not set 'unshared' Murano package to 'shared' References: <20160302155143.1515.80235.malonedeb@soybean.canonical.com> Message-ID: <20160303134957.1554.33169.malone@soybean.canonical.com> Fix proposed to branch: stable/liberty Review: https://review.openstack.org/287803 ** Changed in: murano/liberty Status: Triaged => In Progress ** Changed in: murano/liberty 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/1552291 Title: User with permissions can not set 'unshared' Murano package to 'shared' Status in Murano: In Progress Status in Murano liberty series: In Progress Status in Murano mitaka series: In Progress Bug description: Hello, Please take a look at the issue below. Globally the problem is that user with permissions can't update Murano package. My env is: MOS 8.0 with ISO:589 (HA with vlan, murano, cinder and disabled SSL: 2x controllers; 3x compute,cinder) Actions performed from controller: 1) OK - Perform actions as admin user: # . openrc 2) OK - Create new role: # openstack role create 'can_publicize_packages' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 3) OK - List roles: # openstack role list +----------------------------------+------------------------+ | ID | Name | +----------------------------------+------------------------+ . . . . | cdb2bf1c7cba4c188792481e9bfdf449 | can_publicize_packages | +----------------------------------+------------------------+ 4) OK - Create new user inside 'services' project: # openstack user create '_test_user' --password 'password' --project 'services' +------------+----------------------------------+ | Field | Value | +------------+----------------------------------+ | email | None | | enabled | True | | id | e9783de276d64c0189df2c5a5ff79a63 | | name | _test_user | | project_id | fa38dcb711a24e979f1cd88486a9965e | | username | _test_user | +------------+----------------------------------+ 5) OK - Assign new role to the new user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 6) NOK - Check new role for : # openstack user role list '_test_user' {empty output} \\ I suppose it is expected to have some output here. 7) OK - Try to assign again the same role to the same user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' Conflict occurred attempting to store role grant - User e9783de276d64c0189df2c5a5ff79a63 already has role cdb2bf1c7cba4c188792481e9bfdf449 in tenant fa38dcb711a24e979f1cd88486a9965e (HTTP 409) (Request-ID: req-90460dca-6001-4c1d-90de-212aec294942) \\ So, seems, that role was actually assigned to the user. 5) OK - On all two controllers add new role to /etc/murano/policy.json: # cp /etc/murano/policy.json /etc/murano/policy.json_orig # vim /etc/murano/policy.json from: "publicize_package": "rule:admin_api", to: "publicize_package": "rule:admin_api or role:can_publicize_packages", ### The same with: "publicize_package": ["rule:admin_api", "role:can_publicize_packages"], 6) OK - On all two controllers restart some Murano services: # service murano-api restart ; service murano-engine restart murano-api stop/waiting murano-api start/running, process 5597 murano-engine stop/waiting murano-engine start/running, process 5627 6) OK - Change env to '_test_user' and 'services' project: # export OS_TENANT_NAME='services' ; export OS_PROJECT_NAME='services' ; export OS_USERNAME='_test_user' ; export OS_PASSWORD='password' 7) OK - As a '_test_user' import Murano pkg: # murano --murano-repo-url=http://storage.apps.openstack.org package-import 'io.murano.apps.docker.Interfaces' Package file 'io.murano.apps.docker.Interfaces' does not exist, attempting to download Importing package io.murano.apps.docker.Interfaces +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | ID | Name | FQN | Author | Is Public | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | 90fee6d0e41b441f9e8c4b29d89497aa | Core library | io.murano | murano.io | True | | 6c36dc3f149744ca8b18c5e1527b74ef | Docker Interface Library | io.murano.apps.docker.Interfaces | Mirantis, Inc | | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ 8) NOK - As a '_test_user' update imported pkg with Public=TRUE: # murano package-update '6c36dc3f149744ca8b18c5e1527b74ef' --is-public true 403 Forbidden: Access was denied to this resource. (HTTP 403) \\ After step (5) it is expected for a new user to have ability to update imported packages. Please find logs for the last step (8) attached. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1552291/+subscriptions From 1552291 at bugs.launchpad.net Thu Mar 3 14:21:45 2016 From: 1552291 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 03 Mar 2016 14:21:45 -0000 Subject: [Openstack-security] [Bug 1552291] Re: User with permissions can not set 'unshared' Murano package to 'shared' References: <20160302155143.1515.80235.malonedeb@soybean.canonical.com> Message-ID: <20160303142145.2214.16874.malone@gac.canonical.com> Reviewed: https://review.openstack.org/287480 Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=53845d84e79ebc7f34745d21da58cab6b8276fac Submitter: Jenkins Branch: master commit 53845d84e79ebc7f34745d21da58cab6b8276fac Author: Kirill Zaitsev Date: Thu Mar 3 01:15:33 2016 +0300 Add roles to RequestContext.to_dict if they're not there Old versions of oslo_context do not include rules in to_dict() However roles are required for newer versions of oslo_policy to operate and resolve 'role:xxx' rules. Since minimal version for oslo_context is 0.2.0 and commit, that adds roles has been added only in 2.2.0 we should support old versions of oslo_context with newer version. Change-Id: If35726613bec5d342bad72b542215ec8e5c096a2 Closes-Bug: #1552291 ** Changed in: murano Status: In Progress => 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/1552291 Title: User with permissions can not set 'unshared' Murano package to 'shared' Status in Murano: Fix Released Status in Murano liberty series: In Progress Status in Murano mitaka series: Fix Released Bug description: Hello, Please take a look at the issue below. Globally the problem is that user with permissions can't update Murano package. My env is: MOS 8.0 with ISO:589 (HA with vlan, murano, cinder and disabled SSL: 2x controllers; 3x compute,cinder) Actions performed from controller: 1) OK - Perform actions as admin user: # . openrc 2) OK - Create new role: # openstack role create 'can_publicize_packages' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 3) OK - List roles: # openstack role list +----------------------------------+------------------------+ | ID | Name | +----------------------------------+------------------------+ . . . . | cdb2bf1c7cba4c188792481e9bfdf449 | can_publicize_packages | +----------------------------------+------------------------+ 4) OK - Create new user inside 'services' project: # openstack user create '_test_user' --password 'password' --project 'services' +------------+----------------------------------+ | Field | Value | +------------+----------------------------------+ | email | None | | enabled | True | | id | e9783de276d64c0189df2c5a5ff79a63 | | name | _test_user | | project_id | fa38dcb711a24e979f1cd88486a9965e | | username | _test_user | +------------+----------------------------------+ 5) OK - Assign new role to the new user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 6) NOK - Check new role for : # openstack user role list '_test_user' {empty output} \\ I suppose it is expected to have some output here. 7) OK - Try to assign again the same role to the same user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' Conflict occurred attempting to store role grant - User e9783de276d64c0189df2c5a5ff79a63 already has role cdb2bf1c7cba4c188792481e9bfdf449 in tenant fa38dcb711a24e979f1cd88486a9965e (HTTP 409) (Request-ID: req-90460dca-6001-4c1d-90de-212aec294942) \\ So, seems, that role was actually assigned to the user. 5) OK - On all two controllers add new role to /etc/murano/policy.json: # cp /etc/murano/policy.json /etc/murano/policy.json_orig # vim /etc/murano/policy.json from: "publicize_package": "rule:admin_api", to: "publicize_package": "rule:admin_api or role:can_publicize_packages", ### The same with: "publicize_package": ["rule:admin_api", "role:can_publicize_packages"], 6) OK - On all two controllers restart some Murano services: # service murano-api restart ; service murano-engine restart murano-api stop/waiting murano-api start/running, process 5597 murano-engine stop/waiting murano-engine start/running, process 5627 6) OK - Change env to '_test_user' and 'services' project: # export OS_TENANT_NAME='services' ; export OS_PROJECT_NAME='services' ; export OS_USERNAME='_test_user' ; export OS_PASSWORD='password' 7) OK - As a '_test_user' import Murano pkg: # murano --murano-repo-url=http://storage.apps.openstack.org package-import 'io.murano.apps.docker.Interfaces' Package file 'io.murano.apps.docker.Interfaces' does not exist, attempting to download Importing package io.murano.apps.docker.Interfaces +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | ID | Name | FQN | Author | Is Public | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | 90fee6d0e41b441f9e8c4b29d89497aa | Core library | io.murano | murano.io | True | | 6c36dc3f149744ca8b18c5e1527b74ef | Docker Interface Library | io.murano.apps.docker.Interfaces | Mirantis, Inc | | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ 8) NOK - As a '_test_user' update imported pkg with Public=TRUE: # murano package-update '6c36dc3f149744ca8b18c5e1527b74ef' --is-public true 403 Forbidden: Access was denied to this resource. (HTTP 403) \\ After step (5) it is expected for a new user to have ability to update imported packages. Please find logs for the last step (8) attached. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1552291/+subscriptions From doug at doughellmann.com Thu Mar 3 14:42:44 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 03 Mar 2016 14:42:44 -0000 Subject: [Openstack-security] [Bug 1534299] Fix included in openstack/keystoneauth 1.1.2 References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com> Message-ID: <20160303144245.2253.53474.malone@gac.canonical.com> This issue was fixed in the openstack/keystoneauth 1.1.2 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534299 Title: keystoneclient needs to mark secret config options Status in keystoneauth: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: Fix Released Bug description: oslo_config allows marking config options such as password as "secret", such that when/if the config options are logged they're masked out of the logs. keystoneclient defines several options for auth plugins that should be secret but are not, such as the user's password in the identity, oidc, and saml2 plugins. I don't know if these really need to be private security but might as well start out that way. To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1534299/+subscriptions From doug at doughellmann.com Thu Mar 3 14:43:17 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 03 Mar 2016 14:43:17 -0000 Subject: [Openstack-security] [Bug 1534299] Fix included in openstack/python-keystoneclient 1.7.4 References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com> Message-ID: <20160303144317.1904.84316.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/python-keystoneclient 1.7.4 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534299 Title: keystoneclient needs to mark secret config options Status in keystoneauth: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: Fix Released Bug description: oslo_config allows marking config options such as password as "secret", such that when/if the config options are logged they're masked out of the logs. keystoneclient defines several options for auth plugins that should be secret but are not, such as the user's password in the identity, oidc, and saml2 plugins. I don't know if these really need to be private security but might as well start out that way. To manage notifications about this bug go to: https://bugs.launchpad.net/keystoneauth/+bug/1534299/+subscriptions From doug at doughellmann.com Thu Mar 3 22:50:43 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 03 Mar 2016 22:50:43 -0000 Subject: [Openstack-security] [Bug 1552291] Fix included in openstack/murano 2.0.0.0b3 References: <20160302155143.1515.80235.malonedeb@soybean.canonical.com> Message-ID: <20160303225043.12722.15863.malone@wampee.canonical.com> This issue was fixed in the openstack/murano 2.0.0.0b3 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1552291 Title: User with permissions can not set 'unshared' Murano package to 'shared' Status in Murano: Fix Released Status in Murano liberty series: In Progress Status in Murano mitaka series: Fix Released Bug description: Hello, Please take a look at the issue below. Globally the problem is that user with permissions can't update Murano package. My env is: MOS 8.0 with ISO:589 (HA with vlan, murano, cinder and disabled SSL: 2x controllers; 3x compute,cinder) Actions performed from controller: 1) OK - Perform actions as admin user: # . openrc 2) OK - Create new role: # openstack role create 'can_publicize_packages' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 3) OK - List roles: # openstack role list +----------------------------------+------------------------+ | ID | Name | +----------------------------------+------------------------+ . . . . | cdb2bf1c7cba4c188792481e9bfdf449 | can_publicize_packages | +----------------------------------+------------------------+ 4) OK - Create new user inside 'services' project: # openstack user create '_test_user' --password 'password' --project 'services' +------------+----------------------------------+ | Field | Value | +------------+----------------------------------+ | email | None | | enabled | True | | id | e9783de276d64c0189df2c5a5ff79a63 | | name | _test_user | | project_id | fa38dcb711a24e979f1cd88486a9965e | | username | _test_user | +------------+----------------------------------+ 5) OK - Assign new role to the new user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 6) NOK - Check new role for : # openstack user role list '_test_user' {empty output} \\ I suppose it is expected to have some output here. 7) OK - Try to assign again the same role to the same user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' Conflict occurred attempting to store role grant - User e9783de276d64c0189df2c5a5ff79a63 already has role cdb2bf1c7cba4c188792481e9bfdf449 in tenant fa38dcb711a24e979f1cd88486a9965e (HTTP 409) (Request-ID: req-90460dca-6001-4c1d-90de-212aec294942) \\ So, seems, that role was actually assigned to the user. 5) OK - On all two controllers add new role to /etc/murano/policy.json: # cp /etc/murano/policy.json /etc/murano/policy.json_orig # vim /etc/murano/policy.json from: "publicize_package": "rule:admin_api", to: "publicize_package": "rule:admin_api or role:can_publicize_packages", ### The same with: "publicize_package": ["rule:admin_api", "role:can_publicize_packages"], 6) OK - On all two controllers restart some Murano services: # service murano-api restart ; service murano-engine restart murano-api stop/waiting murano-api start/running, process 5597 murano-engine stop/waiting murano-engine start/running, process 5627 6) OK - Change env to '_test_user' and 'services' project: # export OS_TENANT_NAME='services' ; export OS_PROJECT_NAME='services' ; export OS_USERNAME='_test_user' ; export OS_PASSWORD='password' 7) OK - As a '_test_user' import Murano pkg: # murano --murano-repo-url=http://storage.apps.openstack.org package-import 'io.murano.apps.docker.Interfaces' Package file 'io.murano.apps.docker.Interfaces' does not exist, attempting to download Importing package io.murano.apps.docker.Interfaces +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | ID | Name | FQN | Author | Is Public | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | 90fee6d0e41b441f9e8c4b29d89497aa | Core library | io.murano | murano.io | True | | 6c36dc3f149744ca8b18c5e1527b74ef | Docker Interface Library | io.murano.apps.docker.Interfaces | Mirantis, Inc | | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ 8) NOK - As a '_test_user' update imported pkg with Public=TRUE: # murano package-update '6c36dc3f149744ca8b18c5e1527b74ef' --is-public true 403 Forbidden: Access was denied to this resource. (HTTP 403) \\ After step (5) it is expected for a new user to have ability to update imported packages. Please find logs for the last step (8) attached. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1552291/+subscriptions From doug at doughellmann.com Thu Mar 3 22:51:17 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Thu, 03 Mar 2016 22:51:17 -0000 Subject: [Openstack-security] [Bug 1532317] Fix included in openstack/murano 2.0.0.0b3 References: <20160108202404.8643.13925.malonedeb@wampee.canonical.com> Message-ID: <20160303225117.6001.53007.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/murano 2.0.0.0b3 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1532317 Title: Only ingress rules are supported in security groups Status in Murano: Fix Released Status in Murano kilo series: Fix Released Status in Murano liberty series: Fix Released Status in Murano mitaka series: Fix Released Bug description: There is no way to specify in which direction security rule should be applied, only ingress is supported. Also there should be an optional key in existing parameter specifying rule IP protocol version (IPv4/IPv6) https://github.com/openstack/murano/blob/master/meta/io.murano/Classes/system/NeutronSecurityGroupManager.yaml#L56 https://github.com/openstack/heat/blob/stable/kilo/heat/engine/resources/openstack/neutron/security_group.py#L50 To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1532317/+subscriptions From swann at oopss.org Wed Mar 2 11:09:24 2016 From: swann at oopss.org (Swann Croiset) Date: Wed, 02 Mar 2016 11:09:24 -0000 Subject: [Openstack-security] [Bug 1552182] [NEW] LMA toolchain should alert when packages upgrade is available Message-ID: <20160302110924.1571.6249.malonedeb@chaenomeles.canonical.com> Public bug reported: Mainly for security reason, the LMA toolchain should alert when packages upgrade is highly recommended. For example, the package nagios-plugins-basic [0] provides the command: check_apt ==================================================== root at node-23:~# /usr/lib/nagios/plugins/check_apt APT CRITICAL: 3 packages available for upgrade (2 critical updates). |available_upgrades=3;;;0 critical_updates=2;;;0 root at node-23:~# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: libssl1.0.0 openssl The following packages will be DOWNGRADED: python-urllib3 2 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. Need to get 1,443 kB of archives. After this operation, 124 kB of additional disk space will be used. Do you want to continue? [Y/n] ==================================================== [0] http://packages.ubuntu.com/trusty/nagios-plugins-basic ** Affects: lma-toolchain Importance: Undecided Status: New ** Tags: security ** Description changed: Mainly for security reason, the LMA toolchain should alert when packages upgrade is highly recommended. For example, the package nagios-plugins-basic [0] provides the command: check_apt + ==================================================== root at node-23:~# /usr/lib/nagios/plugins/check_apt APT CRITICAL: 3 packages available for upgrade (2 critical updates). |available_upgrades=3;;;0 critical_updates=2;;;0 + root at node-23:~# apt-get upgrade + Reading package lists... Done + Building dependency tree + Reading state information... Done + Calculating upgrade... Done + The following packages will be upgraded: + libssl1.0.0 openssl + The following packages will be DOWNGRADED: + python-urllib3 + 2 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. + Need to get 1,443 kB of archives. + After this operation, 124 kB of additional disk space will be used. + Do you want to continue? [Y/n] + ==================================================== [0] http://packages.ubuntu.com/trusty/nagios-plugins-basic -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1552182 Title: LMA toolchain should alert when packages upgrade is available Status in LMA Toolchain: New Bug description: Mainly for security reason, the LMA toolchain should alert when packages upgrade is highly recommended. For example, the package nagios-plugins-basic [0] provides the command: check_apt ==================================================== root at node-23:~# /usr/lib/nagios/plugins/check_apt APT CRITICAL: 3 packages available for upgrade (2 critical updates). |available_upgrades=3;;;0 critical_updates=2;;;0 root at node-23:~# apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: libssl1.0.0 openssl The following packages will be DOWNGRADED: python-urllib3 2 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. Need to get 1,443 kB of archives. After this operation, 124 kB of additional disk space will be used. Do you want to continue? [Y/n] ==================================================== [0] http://packages.ubuntu.com/trusty/nagios-plugins-basic To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1552182/+subscriptions From 1321785 at bugs.launchpad.net Fri Mar 4 13:08:53 2016 From: 1321785 at bugs.launchpad.net (Daniel Berrange) Date: Fri, 04 Mar 2016 13:08:53 -0000 Subject: [Openstack-security] [Bug 1321785] Re: RFE: block_device_info dict should have a password key rather than clear password References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com> Message-ID: <20160304130853.5962.94643.malone@chaenomeles.canonical.com> The ovo change merely added a new SensitiveString field type. We still have to actually convert Nova to use that new field type where needed ** Changed in: nova Status: Fix Released => Confirmed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1321785 Title: RFE: block_device_info dict should have a password key rather than clear password Status in OpenStack Compute (nova): Confirmed Status in oslo.versionedobjects: Fix Released Bug description: See bug 1319943 and the related patch https://review.openstack.org/#/c/93787/ for details, but right now the block_device_info dict passed around in the nova virt driver can contain a clear text password for the auth_password key. That bug and patch are masking the password when logged in the immediate known locations, but this could continue to crop up so we should change the design such that the block_device_info dict doesn't contain the password but rather a key to a store that nova can retrieve the password for use. Comment from Daniel Berrange in the patch above: "Long term I think we need to figure out a way to remove the passwords from any data dicts we pass around. Ideally the block device info would merely contain something like a UUID to identify a password, which Nova could use to fetch the actual password from a secure password manager service at time of use. Thus we wouldn't have to worry about random objects/dicts containing actual passwords. Obviously this isn't something we can do now, but could you file an RFE to address this from a design POV, because masking passwords at time of logging call is not really a viable long term strategy IMHO." To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1321785/+subscriptions From mriedem at us.ibm.com Sat Mar 5 18:24:27 2016 From: mriedem at us.ibm.com (Matt Riedemann) Date: Sat, 05 Mar 2016 18:24:27 -0000 Subject: [Openstack-security] [Bug 1321785] Re: RFE: block_device_info dict should have a password key rather than clear password References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com> Message-ID: <20160305182429.6111.38235.launchpad@chaenomeles.canonical.com> ** Changed in: nova Importance: Wishlist => Medium ** Changed in: nova Assignee: (unassigned) => Matt Riedemann (mriedem) ** Tags added: unified-objects -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1321785 Title: RFE: block_device_info dict should have a password key rather than clear password Status in OpenStack Compute (nova): Confirmed Status in oslo.versionedobjects: Fix Released Bug description: See bug 1319943 and the related patch https://review.openstack.org/#/c/93787/ for details, but right now the block_device_info dict passed around in the nova virt driver can contain a clear text password for the auth_password key. That bug and patch are masking the password when logged in the immediate known locations, but this could continue to crop up so we should change the design such that the block_device_info dict doesn't contain the password but rather a key to a store that nova can retrieve the password for use. Comment from Daniel Berrange in the patch above: "Long term I think we need to figure out a way to remove the passwords from any data dicts we pass around. Ideally the block device info would merely contain something like a UUID to identify a password, which Nova could use to fetch the actual password from a secure password manager service at time of use. Thus we wouldn't have to worry about random objects/dicts containing actual passwords. Obviously this isn't something we can do now, but could you file an RFE to address this from a design POV, because masking passwords at time of logging call is not really a viable long term strategy IMHO." To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1321785/+subscriptions From 1321785 at bugs.launchpad.net Sat Mar 5 18:44:40 2016 From: 1321785 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 05 Mar 2016 18:44:40 -0000 Subject: [Openstack-security] [Bug 1321785] Re: RFE: block_device_info dict should have a password key rather than clear password References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com> Message-ID: <20160305184440.20568.82520.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/288927 ** Changed in: nova 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/1321785 Title: RFE: block_device_info dict should have a password key rather than clear password Status in OpenStack Compute (nova): In Progress Status in oslo.versionedobjects: Fix Released Bug description: See bug 1319943 and the related patch https://review.openstack.org/#/c/93787/ for details, but right now the block_device_info dict passed around in the nova virt driver can contain a clear text password for the auth_password key. That bug and patch are masking the password when logged in the immediate known locations, but this could continue to crop up so we should change the design such that the block_device_info dict doesn't contain the password but rather a key to a store that nova can retrieve the password for use. Comment from Daniel Berrange in the patch above: "Long term I think we need to figure out a way to remove the passwords from any data dicts we pass around. Ideally the block device info would merely contain something like a UUID to identify a password, which Nova could use to fetch the actual password from a secure password manager service at time of use. Thus we wouldn't have to worry about random objects/dicts containing actual passwords. Obviously this isn't something we can do now, but could you file an RFE to address this from a design POV, because masking passwords at time of logging call is not really a viable long term strategy IMHO." To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1321785/+subscriptions From davanum at gmail.com Sun Mar 6 15:09:56 2016 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Sun, 06 Mar 2016 15:09:56 -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: <20160306150958.20875.6842.launchpad@soybean.canonical.com> ** Changed in: nova Assignee: Michael Still (mikalstill) => (unassigned) ** Changed in: nova Status: In Progress => Confirmed -- 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): Confirmed 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 1498726 at bugs.launchpad.net Sun Mar 6 18:16:21 2016 From: 1498726 at bugs.launchpad.net (Jimmy McCrory) Date: Sun, 06 Mar 2016 18:16:21 -0000 Subject: [Openstack-security] [Bug 1498726] Re: Specify ciphers with HAProxy SSL frontends References: <20150923022208.8903.73759.malonedeb@gac.canonical.com> Message-ID: <20160306181623.5925.31699.launchpad@chaenomeles.canonical.com> ** Changed in: openstack-ansible 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/1498726 Title: Specify ciphers with HAProxy SSL frontends Status in openstack-ansible: Fix Released Bug description: For increased security, a specific cipher suite should be specified when configuring HAProxy SSL frontends. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1498726/+subscriptions From gerrit2 at review.openstack.org Mon Mar 7 10:47:48 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 07 Mar 2016 10:47:48 +0000 Subject: [Openstack-security] [openstack/oslo.middleware] SecurityImpact review request change I50a70d477613025d3e54e4ee773bbb1d6fcf2e68 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/283052 Log: commit f62c3a74c07238d91efb17e9ac64373f08894490 Author: Juan Antonio Osorio Robles Date: Mon Feb 22 14:07:50 2016 +0200 Disable http_proxy_to_wsgi middleware by default Having this middleware as default is very convenient for deployments, since this enables the application to handle the appropriate headers correctly in order to deal with SSL, which is nice to have out of the box. Heat, for instance, has already taken this middleware as default. However, having this act on the headers by default may not be so desirable, as the application may not be in front of a proxy, and thus will have nothing that parses or strips the X-Forwarded-* headers. Which can lead to security problems. Thus, this patch proposes the enabling of this functionality through a configuration option. This will enable more projects to take this middleware into use by default, and the deployer would only need to change one configuration file; while leaving the paste configuration intact. Change-Id: I50a70d477613025d3e54e4ee773bbb1d6fcf2e68 SecurityImpact From grant.murphy at hp.com Mon Mar 7 15:09:02 2016 From: grant.murphy at hp.com (Grant Murphy) Date: Mon, 07 Mar 2016 15:09:02 -0000 Subject: [Openstack-security] [Bug 1511541] Re: Possible incomplete fix for OSSA-2015-005 References: <20151029214642.13606.53636.malonedeb@wampee.canonical.com> Message-ID: <20160307150902.6111.670.malone@chaenomeles.canonical.com> Removed the OSSA task and marking invalid. ** Changed in: ossa Status: Incomplete => Invalid ** No longer affects: ossa ** Changed in: nova Status: Incomplete => Invalid -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1511541 Title: Possible incomplete fix for OSSA-2015-005 Status in OpenStack Compute (nova): Invalid Bug description: Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete. https://bugs.launchpad.net/nova/+bug/1409142/comments/146 https://bugs.launchpad.net/nova/+bug/1409142/comments/149 Further investigation is needed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1511541/+subscriptions From 1493448 at bugs.launchpad.net Mon Mar 7 19:31:19 2016 From: 1493448 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 07 Mar 2016 19:31:19 -0000 Subject: [Openstack-security] [Bug 1493448] Related fix merged to glance (master) References: <20150908163321.8816.82829.malonedeb@wampee.canonical.com> Message-ID: <20160307193119.5824.18877.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/237742 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=80fef06497c2a1f2e5c7bae4a0e04ab426ec70f7 Submitter: Jenkins Branch: master commit 80fef06497c2a1f2e5c7bae4a0e04ab426ec70f7 Author: Mike Fedosin Date: Fri Feb 12 19:43:13 2016 +0300 Deprecate use_user_token parameter Parameter 'use_user_token' in glance-api.conf was considered as harmful and not acceptable for real deployments, because if it's disabled, it changes system behaviour and allows any regular user to perform requests with admin credentials. In functional tests the default value was set to True to prevent possible failures in the future. Besides, several admin authN parameters were deprecated as well, because they are useless without 'use_user_token'. All required information was added to related documentation sections, sample config file was updated as well. https://wiki.openstack.org/wiki/OSSN/OSSN-0060 Change-Id: Icfef49d787fa58e2af2e60e4fdc96633c5f0c010 Related-bug: #1493448 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1493448 Title: All operations are perfomed with admin priveleges when 'use_user_token' is False Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: In glance-api.conf we have a param called 'use_user_token' which is enabled by default. It was introduced to allow for reauthentication when tokens expire and prevents requests from silently failing. https://review.openstack.org/#/c/29967/ Unfortunately disabling this parameter leads to security issues and allows a regular user to perform any operation with admin rights. Steps to reproduce on devstack: 1. Change /etc/glance/glance-api.conf parameters and restart glance-api: # Pass the user's token through for API requests to the registry. # Default: True use_user_token = False # If 'use_user_token' is not in effect then admin credentials # can be specified. Requests to the registry on behalf of # the API will use these credentials. # Admin user name admin_user = glance # Admin password admin_password = nova # Admin tenant name admin_tenant_name = service # Keystone endpoint auth_url = http://127.0.0.1:5000/v2.0 (for v2 api it's required to enable registry service, too: data_api = glance.db.registry.api) 2. Create a private image with admin user: source openrc admin admin glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | | virtual_size | None | +------------------+--------------------------------------+ 3. Check the image list with admin user: glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 4. Enable demo user and get the image list: source openrc demo demo glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 5. Try to get access to admin's private image with demo user: glance --os-image-api-version 1 image-show private +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | +------------------+--------------------------------------+ The same happens when demo user wants to create/update/delete any image. v2 with enabled registry backend is affected too. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1493448/+subscriptions From gerrit2 at review.openstack.org Tue Mar 8 15:02:19 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 08 Mar 2016 15:02:19 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/289957 Log: commit 116b1210ab772c55d1ed1f715687d83877c92701 Author: Lee Yarwood Date: Wed Feb 24 11:23:22 2016 +0000 libvirt: Always copy or recreate disk.info during a migration The disk.info file contains the path and format of any image, config or ephermal disk associated with an instance. When using RAW images and migrating an instance this file should always be copied or recreated. This avoids the Raw imagebackend reinspecting the format of these disks when spawning the instance on the destination host. By not copying or recreating this disk.info file, a malicious image written to an instance disk on the source host will cause Nova to reinspect and record a different format for the disk on the destination. This format then being used incorrectly when finally spawning the instance on the destination. SecurityImpact Closes-bug: #1548450 Change-Id: Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 From gerrit2 at review.openstack.org Tue Mar 8 15:03:58 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 08 Mar 2016 15:03:58 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/289958 Log: commit 8d5ba34751c0ae8093f987d74348dffd8ca0b61c Author: Lee Yarwood Date: Wed Feb 24 11:23:22 2016 +0000 libvirt: Always copy or recreate disk.info during a migration The disk.info file contains the path and format of any image, config or ephermal disk associated with an instance. When using RAW images and migrating an instance this file should always be copied or recreated. This avoids the Raw imagebackend reinspecting the format of these disks when spawning the instance on the destination host. By not copying or recreating this disk.info file, a malicious image written to an instance disk on the source host will cause Nova to reinspect and record a different format for the disk on the destination. This format then being used incorrectly when finally spawning the instance on the destination. SecurityImpact Closes-bug: #1548450 Change-Id: Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 From gerrit2 at review.openstack.org Tue Mar 8 15:06:02 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 08 Mar 2016 15:06:02 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/289960 Log: commit f302bf04ab5dda89cf8ceaeed309006da90c0666 Author: Lee Yarwood Date: Wed Feb 24 11:23:22 2016 +0000 libvirt: Always copy or recreate disk.info during a migration The disk.info file contains the path and format of any image, config or ephermal disk associated with an instance. When using RAW images and migrating an instance this file should always be copied or recreated. This avoids the Raw imagebackend reinspecting the format of these disks when spawning the instance on the destination host. By not copying or recreating this disk.info file, a malicious image written to an instance disk on the source host will cause Nova to reinspect and record a different format for the disk on the destination. This format then being used incorrectly when finally spawning the instance on the destination. Conflicts: nova/tests/unit/virt/libvirt/test_driver.py nova/virt/libvirt/driver.py SecurityImpact Closes-bug: #1548450 Change-Id: Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 From mzoeller at de.ibm.com Tue Mar 8 19:52:59 2016 From: mzoeller at de.ibm.com (Markus Zoeller (markus_z)) Date: Tue, 08 Mar 2016 19:52:59 -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: <20160308195300.13036.71095.malone@wampee.canonical.com> This bug report is specifically about the log into Horizon with a nova service user. That the nova user has the admin rights is covered in bug 1445199. That the admin role is not properly scoped is handled in bug 968696. Nova cannot prevent/influence log ins to Horizon. => Invalid for Nova ** Changed in: nova Status: Incomplete => Invalid -- 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 Compute (nova): Invalid Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released 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 1552291 at bugs.launchpad.net Wed Mar 9 15:34:45 2016 From: 1552291 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 09 Mar 2016 15:34:45 -0000 Subject: [Openstack-security] [Bug 1552291] Re: User with permissions can not set 'unshared' Murano package to 'shared' References: <20160302155143.1515.80235.malonedeb@soybean.canonical.com> Message-ID: <20160309153445.32265.94786.malone@gac.canonical.com> Reviewed: https://review.openstack.org/287803 Committed: https://git.openstack.org/cgit/openstack/murano/commit/?id=7f25fdff2a1f1a0f48c5d771b5b268605ceb3db3 Submitter: Jenkins Branch: stable/liberty commit 7f25fdff2a1f1a0f48c5d771b5b268605ceb3db3 Author: Kirill Zaitsev Date: Thu Mar 3 01:15:33 2016 +0300 Add roles to RequestContext.to_dict if they're not there Old versions of oslo_context do not include rules in to_dict() However roles are required for newer versions of oslo_policy to operate and resolve 'role:xxx' rules. Since minimal version for oslo_context is 0.2.0 and commit, that adds roles has been added only in 2.2.0 we should support old versions of oslo_context with newer version. Change-Id: If35726613bec5d342bad72b542215ec8e5c096a2 Closes-Bug: #1552291 ** Changed in: murano/liberty 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/1552291 Title: User with permissions can not set 'unshared' Murano package to 'shared' Status in Murano: Fix Released Status in Murano liberty series: Fix Committed Status in Murano mitaka series: Fix Released Bug description: Hello, Please take a look at the issue below. Globally the problem is that user with permissions can't update Murano package. My env is: MOS 8.0 with ISO:589 (HA with vlan, murano, cinder and disabled SSL: 2x controllers; 3x compute,cinder) Actions performed from controller: 1) OK - Perform actions as admin user: # . openrc 2) OK - Create new role: # openstack role create 'can_publicize_packages' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 3) OK - List roles: # openstack role list +----------------------------------+------------------------+ | ID | Name | +----------------------------------+------------------------+ . . . . | cdb2bf1c7cba4c188792481e9bfdf449 | can_publicize_packages | +----------------------------------+------------------------+ 4) OK - Create new user inside 'services' project: # openstack user create '_test_user' --password 'password' --project 'services' +------------+----------------------------------+ | Field | Value | +------------+----------------------------------+ | email | None | | enabled | True | | id | e9783de276d64c0189df2c5a5ff79a63 | | name | _test_user | | project_id | fa38dcb711a24e979f1cd88486a9965e | | username | _test_user | +------------+----------------------------------+ 5) OK - Assign new role to the new user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' +-------+----------------------------------+ | Field | Value | +-------+----------------------------------+ | id | cdb2bf1c7cba4c188792481e9bfdf449 | | name | can_publicize_packages | +-------+----------------------------------+ 6) NOK - Check new role for : # openstack user role list '_test_user' {empty output} \\ I suppose it is expected to have some output here. 7) OK - Try to assign again the same role to the same user: # openstack role add 'can_publicize_packages' --user '_test_user' --project 'services' Conflict occurred attempting to store role grant - User e9783de276d64c0189df2c5a5ff79a63 already has role cdb2bf1c7cba4c188792481e9bfdf449 in tenant fa38dcb711a24e979f1cd88486a9965e (HTTP 409) (Request-ID: req-90460dca-6001-4c1d-90de-212aec294942) \\ So, seems, that role was actually assigned to the user. 5) OK - On all two controllers add new role to /etc/murano/policy.json: # cp /etc/murano/policy.json /etc/murano/policy.json_orig # vim /etc/murano/policy.json from: "publicize_package": "rule:admin_api", to: "publicize_package": "rule:admin_api or role:can_publicize_packages", ### The same with: "publicize_package": ["rule:admin_api", "role:can_publicize_packages"], 6) OK - On all two controllers restart some Murano services: # service murano-api restart ; service murano-engine restart murano-api stop/waiting murano-api start/running, process 5597 murano-engine stop/waiting murano-engine start/running, process 5627 6) OK - Change env to '_test_user' and 'services' project: # export OS_TENANT_NAME='services' ; export OS_PROJECT_NAME='services' ; export OS_USERNAME='_test_user' ; export OS_PASSWORD='password' 7) OK - As a '_test_user' import Murano pkg: # murano --murano-repo-url=http://storage.apps.openstack.org package-import 'io.murano.apps.docker.Interfaces' Package file 'io.murano.apps.docker.Interfaces' does not exist, attempting to download Importing package io.murano.apps.docker.Interfaces +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | ID | Name | FQN | Author | Is Public | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ | 90fee6d0e41b441f9e8c4b29d89497aa | Core library | io.murano | murano.io | True | | 6c36dc3f149744ca8b18c5e1527b74ef | Docker Interface Library | io.murano.apps.docker.Interfaces | Mirantis, Inc | | +----------------------------------+--------------------------+----------------------------------+---------------+-----------+ 8) NOK - As a '_test_user' update imported pkg with Public=TRUE: # murano package-update '6c36dc3f149744ca8b18c5e1527b74ef' --is-public true 403 Forbidden: Access was denied to this resource. (HTTP 403) \\ After step (5) it is expected for a new user to have ability to update imported packages. Please find logs for the last step (8) attached. Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1552291/+subscriptions From 1321785 at bugs.launchpad.net Thu Mar 10 14:22:49 2016 From: 1321785 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Mar 2016 14:22:49 -0000 Subject: [Openstack-security] [Bug 1321785] Re: RFE: block_device_info dict should have a password key rather than clear password References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com> Message-ID: <20160310142249.31550.48796.malone@gac.canonical.com> Reviewed: https://review.openstack.org/288927 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=db50aaca0acdf7814a8d6673545db94738907131 Submitter: Jenkins Branch: master commit db50aaca0acdf7814a8d6673545db94738907131 Author: Matt Riedemann Date: Sat Mar 5 13:40:52 2016 -0500 Use SensitiveStringField for BlockDeviceMapping.connection_info bd977f400a1192d5cf7c2b52ef91615c0828813c added the SensitiveStringField to oslo.versionedobjects. SensitiveStringField is a StringField, which is what BlockDeviceMapping.connection_info was already using. The difference is that a SensitiveStringField masks passwords in the 'stringify' method, which is what's used when __repr__ is called on the object. Since BDM.connection_info can contain credentials, and the connection_info dict gets passed around quite a bit in the compute manager and virt drivers, it has from time to time gotten logged without first masking passwords. This makes the object handle masking the password so we don't have to do it explicitly anymore. There is no version bump on the BlockDeviceMapping object since nothing has functionally changed. Change-Id: I66a0b5f6834034e2fcbefc4510e3aa018edec310 Closes-Bug: #1321785 ** Changed in: nova Status: In Progress => 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/1321785 Title: RFE: block_device_info dict should have a password key rather than clear password Status in OpenStack Compute (nova): Fix Released Status in oslo.versionedobjects: Fix Released Bug description: See bug 1319943 and the related patch https://review.openstack.org/#/c/93787/ for details, but right now the block_device_info dict passed around in the nova virt driver can contain a clear text password for the auth_password key. That bug and patch are masking the password when logged in the immediate known locations, but this could continue to crop up so we should change the design such that the block_device_info dict doesn't contain the password but rather a key to a store that nova can retrieve the password for use. Comment from Daniel Berrange in the patch above: "Long term I think we need to figure out a way to remove the passwords from any data dicts we pass around. Ideally the block device info would merely contain something like a UUID to identify a password, which Nova could use to fetch the actual password from a secure password manager service at time of use. Thus we wouldn't have to worry about random objects/dicts containing actual passwords. Obviously this isn't something we can do now, but could you file an RFE to address this from a design POV, because masking passwords at time of logging call is not really a viable long term strategy IMHO." To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1321785/+subscriptions From 832507 at bugs.launchpad.net Thu Mar 10 15:32:38 2016 From: 832507 at bugs.launchpad.net (Daniel Berrange) Date: Thu, 10 Mar 2016 15:32:38 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20160310153238.32339.86874.malone@gac.canonical.com> Libvirt releases once a month, and QEMU is in feature freeze for its next release. So this will easily be ready before Newton -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (nova): Confirmed Status in OpenStack Security Advisory: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From kevin.carter at rackspace.com Fri Mar 11 18:26:51 2016 From: kevin.carter at rackspace.com (Kevin Carter) Date: Fri, 11 Mar 2016 18:26:51 -0000 Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has incorrect ownership References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160311182652.17021.82480.launchpad@wampee.canonical.com> ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Confirmed Status in openstack-ansible liberty series: Confirmed Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From jesse.pretorius at gmail.com Fri Mar 11 18:28:32 2016 From: jesse.pretorius at gmail.com (Jesse Pretorius) Date: Fri, 11 Mar 2016 18:28:32 -0000 Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has incorrect ownership References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160311182832.1270.39734.launchpad@gac.canonical.com> ** Also affects: openstack-ansible/kilo Importance: Undecided Status: New ** Also affects: openstack-ansible/liberty Importance: Undecided Status: New ** Also affects: openstack-ansible/trunk Importance: Undecided Assignee: Travis Truman (travis-truman) Status: New ** Changed in: openstack-ansible/kilo Milestone: None => 11.2.11 ** Changed in: openstack-ansible/liberty Milestone: None => 12.0.8 ** Changed in: openstack-ansible/trunk Milestone: None => 13.0.0 ** Changed in: openstack-ansible/kilo Importance: Undecided => Critical ** Changed in: openstack-ansible/trunk Importance: Undecided => Critical ** Changed in: openstack-ansible/kilo Status: New => Confirmed ** Changed in: openstack-ansible/liberty Importance: Undecided => Critical ** Changed in: openstack-ansible/liberty Status: New => Confirmed ** Changed in: openstack-ansible/trunk Status: New => Fix Committed ** Changed in: openstack-ansible/liberty Assignee: (unassigned) => Travis Truman (travis-truman) ** Changed in: openstack-ansible/kilo Assignee: (unassigned) => Travis Truman (travis-truman) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Confirmed Status in openstack-ansible liberty series: Confirmed Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From kevin.carter at rackspace.com Fri Mar 11 18:40:48 2016 From: kevin.carter at rackspace.com (Kevin Carter) Date: Fri, 11 Mar 2016 18:40:48 -0000 Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has incorrect ownership References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160311184048.17134.35345.malone@wampee.canonical.com> Mitigation while waiting on patches to land: Mitigation for Nova: ansible nova_all -m shell -a 'chown root:root /etc/nova/rootwrap.conf' ansible nova_all -m shell -a 'chown -R root:root /etc/nova/rootwrap.d' Mitigation for Neutron: ansible nova_all -m shell -a 'chown root:root /etc/neutron/rootwrap.conf' ansible nova_all -m shell -a 'chown root:root /etc/neutron/rootwrap.d' Mitigation for Cinder: ansible nova_all -m shell -a 'chown root:root /etc/cinder/rootwrap.conf' ansible nova_all -m shell -a 'chown root:root /etc/cinder/rootwrap.d' Mitigation for Ceilometer: ansible nova_all -m shell -a 'chown root:root /etc/ceilometer/rootwrap.conf' ansible nova_all -m shell -a 'chown root:root /etc/ceilometer/rootwrap.d' -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Confirmed Status in openstack-ansible liberty series: In Progress Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From 1556231 at bugs.launchpad.net Fri Mar 11 18:44:58 2016 From: 1556231 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 11 Mar 2016 18:44:58 -0000 Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has incorrect ownership References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160311184459.1122.97049.malone@gac.canonical.com> Fix proposed to branch: liberty Review: https://review.openstack.org/291858 ** Changed in: openstack-ansible/liberty 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/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Confirmed Status in openstack-ansible liberty series: In Progress Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From 1556231 at bugs.launchpad.net Fri Mar 11 19:15:16 2016 From: 1556231 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 11 Mar 2016 19:15:16 -0000 Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has incorrect ownership References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160311191516.17169.89642.malone@wampee.canonical.com> Fix proposed to branch: kilo Review: https://review.openstack.org/291868 ** Changed in: openstack-ansible/kilo 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/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: In Progress Status in openstack-ansible liberty series: In Progress Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From kevin.carter at rackspace.com Fri Mar 11 19:34:58 2016 From: kevin.carter at rackspace.com (Kevin Carter) Date: Fri, 11 Mar 2016 19:34:58 -0000 Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has incorrect ownership References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160311193459.16819.6677.malone@wampee.canonical.com> Correction for Manual Mitigation: Mitigation for Nova: ansible nova_all -m shell -a 'chown root:root /etc/nova/rootwrap.conf' ansible nova_all -m shell -a 'chown -R root:root /etc/nova/rootwrap.d' Mitigation for Neutron: ansible neutron_all -m shell -a 'chown root:root /etc/neutron/rootwrap.conf' ansible neutron_all -m shell -a 'chown -R root:root /etc/neutron/rootwrap.d' Mitigation for Cinder: ansible cinder_all -m shell -a 'chown root:root /etc/cinder/rootwrap.conf' ansible cinder_all -m shell -a 'chown -R root:root /etc/cinder/rootwrap.d' Mitigation for Ceilometer: ansible ceilometer_all -m shell -a 'chown root:root /etc/ceilometer/rootwrap.conf' ansible ceilometer_all -m shell -a 'chown -R root:root /etc/ceilometer/rootwrap.d' -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: In Progress Status in openstack-ansible liberty series: In Progress Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From 1556231 at bugs.launchpad.net Fri Mar 11 21:19:39 2016 From: 1556231 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 11 Mar 2016 21:19:39 -0000 Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has incorrect ownership References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160311211939.26804.36578.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/291858 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=ec2cae8a3706159eb8a4c7c26150ab463a07cddd Submitter: Jenkins Branch: liberty commit ec2cae8a3706159eb8a4c7c26150ab463a07cddd Author: Travis Truman Date: Fri Mar 11 13:42:00 2016 -0500 rootwrap configuration must be owned by root See https://wiki.openstack.org/wiki/Rootwrap#Security_model for details Backport of changes: * I5b4354f6cc834bae2ba8962b5a283831d7ff9e4f * I2f45cc628fef706cae323840bf65645a61a26b6d * I349cafcef8e897db6e8e94e47aa6f55ae20f6f82 * I0a31173cf96b6e1bf4c19bee95702aae0c04042c Change-Id: Id72ed598bbd0b6546e8cb0eb5b45ded607ed90e9 Closes-Bug: #1556231 ** Changed in: openstack-ansible/liberty Status: In Progress => Fix Committed ** Changed in: openstack-ansible/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/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Fix Committed Status in openstack-ansible liberty series: Fix Committed Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From 1556231 at bugs.launchpad.net Fri Mar 11 21:20:00 2016 From: 1556231 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 11 Mar 2016 21:20:00 -0000 Subject: [Openstack-security] [Bug 1556231] Fix merged to openstack-ansible (kilo) References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160311212000.20945.42723.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/291868 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=3c54d097ab8549c6b275351255606b452d71f252 Submitter: Jenkins Branch: kilo commit 3c54d097ab8549c6b275351255606b452d71f252 Author: Travis Truman Date: Fri Mar 11 13:42:00 2016 -0500 rootwrap configuration must be owned by root See https://wiki.openstack.org/wiki/Rootwrap#Security_model for details Backport of changes: * I5b4354f6cc834bae2ba8962b5a283831d7ff9e4f * I2f45cc628fef706cae323840bf65645a61a26b6d * I349cafcef8e897db6e8e94e47aa6f55ae20f6f82 * I0a31173cf96b6e1bf4c19bee95702aae0c04042c Change-Id: Id72ed598bbd0b6546e8cb0eb5b45ded607ed90e9 Closes-Bug: #1556231 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Fix Committed Status in openstack-ansible liberty series: Fix Committed Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From 1163569 at bugs.launchpad.net Sat Mar 12 00:53:29 2016 From: 1163569 at bugs.launchpad.net (Armando Migliaccio) Date: Sat, 12 Mar 2016 00:53:29 -0000 Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work with LBaaS vip and ovs plugin References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com> Message-ID: <20160312005330.26804.14990.malone@chaenomeles.canonical.com> Can't be triaged. ** Changed in: neutron Status: Confirmed => Incomplete ** Changed in: neutron Importance: High => Undecided -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1163569 Title: security groups don't work with LBaaS vip and ovs plugin Status in neutron: Incomplete Status in OpenStack Security Notes: Won't Fix Bug description: http://codepad.org/xU8G4s00 I pinged nachi and he suggested to try using: interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver But after setting this it seems like the vip does not work at all. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1163569/+subscriptions From thierry.carrez+lp at gmail.com Wed Mar 16 18:03:34 2016 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 16 Mar 2016 18:03:34 -0000 Subject: [Openstack-security] [Bug 1321785] Fix included in openstack/nova 13.0.0.0rc1 References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com> Message-ID: <20160316180334.17973.62690.malone@gac.canonical.com> This issue was fixed in the openstack/nova 13.0.0.0rc1 release candidate. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1321785 Title: RFE: block_device_info dict should have a password key rather than clear password Status in OpenStack Compute (nova): Fix Released Status in oslo.versionedobjects: Fix Released Bug description: See bug 1319943 and the related patch https://review.openstack.org/#/c/93787/ for details, but right now the block_device_info dict passed around in the nova virt driver can contain a clear text password for the auth_password key. That bug and patch are masking the password when logged in the immediate known locations, but this could continue to crop up so we should change the design such that the block_device_info dict doesn't contain the password but rather a key to a store that nova can retrieve the password for use. Comment from Daniel Berrange in the patch above: "Long term I think we need to figure out a way to remove the passwords from any data dicts we pass around. Ideally the block device info would merely contain something like a UUID to identify a password, which Nova could use to fetch the actual password from a secure password manager service at time of use. Thus we wouldn't have to worry about random objects/dicts containing actual passwords. Obviously this isn't something we can do now, but could you file an RFE to address this from a design POV, because masking passwords at time of logging call is not really a viable long term strategy IMHO." To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1321785/+subscriptions From james.arendt at hp.com Fri Mar 11 00:16:11 2016 From: james.arendt at hp.com (James Arendt) Date: Fri, 11 Mar 2016 00:16:11 -0000 Subject: [Openstack-security] [Bug 1549547] Re: LBaaS leaking password in DEBUG logs References: <20160225002843.1623.41446.malonedeb@wampee.canonical.com> Message-ID: <20160311001613.6378.70906.launchpad@chaenomeles.canonical.com> ** Changed in: neutron 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/1549547 Title: LBaaS leaking password in DEBUG logs Status in neutron: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: Current code leaks the keystone admin_password in the cfg into log files: Example from DevStack q-svc.log: [00;32mDEBUG oslo_service.service [^[[00;36m-^[[00;32m] ^[[01;35m^[[00;32mservice_auth.admin_password = password Issue is that the cfg.StrOpt for admin_password did not set 'secret=True", which would give: service_auth.admin_password = **** To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1549547/+subscriptions From cdiep at us.ibm.com Mon Mar 14 22:28:11 2016 From: cdiep at us.ibm.com (Catherine Cuong Diep) Date: Mon, 14 Mar 2016 14:28:11 -0800 Subject: [Openstack-security] [OpenStack-DefCore][Security] List Users in RefStack Message-ID: <201603142228.u2EMSFjH020843@d01av02.pok.ibm.com> The RefStack team would appreciate guidance and recommendation on the following: Should any RefStack authenticated user be able to list the users registered in RefStack? If the answer is yes, which user information should be returned (full name, email, OpenID)? Or ONLY OpenStack Foundation members can list the users in RefStack? Back ground information: When a user registers at RefStack, RefStack does not request any user information input from the user, Instead, RefStack redirects the registration process to OpenstackId Identity Provider ( https://openstackid.org/ ) and obtains three pieces of user information ( full name, email, OpenID ) from the OpenstackId Identity Provider. OpenstackId Identity Provider ( https://openstackid.org/ ) treats email as private information. You will not find email or OpenID information on any member's public profile on https://www.openstack.org/community/members/ . Furthermore, if you look at your own profile on https://www.openstack.org/profile/ , you will find that email information is listed under the "private information" section. Since OpenstackId Identity Provider is the source of the user information of RefStack, RefStack should respect and not relax the privacy policy set by its source . Note: The user information for review.openstack.org seems to be set in https://review.openstack.org/#/settings/web-identities and not from OpenstackId Identity Provider. Catherine Diep RefStack Project PTL IBM Silicon Valley Laboratory, San Jose, California 95141 cdiep at us.ibm.com, Tel: (408) 463-4352 T/L: 543-4352 -------------- next part -------------- An HTML attachment was scrubbed... URL: From davanum at gmail.com Fri Mar 18 10:47:22 2016 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Fri, 18 Mar 2016 10:47:22 -0000 Subject: [Openstack-security] [Bug 1556231] Fix included in openstack/openstack-ansible 11.2.11 References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160318104722.414.65648.malone@soybean.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.11 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Committed Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From davanum at gmail.com Fri Mar 18 10:49:38 2016 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Fri, 18 Mar 2016 10:49:38 -0000 Subject: [Openstack-security] [Bug 1498726] Fix included in openstack/openstack-ansible 11.2.11 References: <20150923022208.8903.73759.malonedeb@gac.canonical.com> Message-ID: <20160318104938.837.930.malone@soybean.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.11 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1498726 Title: Specify ciphers with HAProxy SSL frontends Status in openstack-ansible: Fix Released Bug description: For increased security, a specific cipher suite should be specified when configuring HAProxy SSL frontends. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1498726/+subscriptions From jesse.pretorius at gmail.com Fri Mar 18 10:54:23 2016 From: jesse.pretorius at gmail.com (Jesse Pretorius) Date: Fri, 18 Mar 2016 10:54:23 -0000 Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has incorrect ownership References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160318105424.18507.92191.launchpad@gac.canonical.com> ** 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/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Committed Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From davanum at gmail.com Fri Mar 18 10:52:52 2016 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Fri, 18 Mar 2016 10:52:52 -0000 Subject: [Openstack-security] [Bug 1466216] Fix included in openstack/openstack-ansible 11.2.11 References: <20150617203545.4905.22166.malonedeb@wampee.canonical.com> Message-ID: <20160318105252.20814.15657.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.11 release. -- 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 openstack-ansible: 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 doug at doughellmann.com Fri Mar 18 12:47:33 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 18 Mar 2016 12:47:33 -0000 Subject: [Openstack-security] [Bug 1556231] Fix included in openstack/openstack-ansible 12.0.8 References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160318124733.617.70235.malone@soybean.canonical.com> This issue was fixed in the openstack/openstack-ansible 12.0.8 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Released Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From jesse.pretorius at gmail.com Fri Mar 18 12:48:46 2016 From: jesse.pretorius at gmail.com (Jesse Pretorius) Date: Fri, 18 Mar 2016 12:48:46 -0000 Subject: [Openstack-security] [Bug 1556231] Re: Rootwrap configuration has incorrect ownership References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160318124848.18388.30216.launchpad@wampee.canonical.com> ** Changed in: openstack-ansible/liberty 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/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Released Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From 1559920 at bugs.launchpad.net Mon Mar 21 09:21:34 2016 From: 1559920 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 21 Mar 2016 09:21:34 -0000 Subject: [Openstack-security] [Bug 1559920] Re: Flows per in_port are deleted after SG rules are applied References: <20160321081847.18388.10417.malonedeb@wampee.canonical.com> Message-ID: <20160321092134.18924.75271.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/295154 ** Changed in: neutron 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/1559920 Title: Flows per in_port are deleted after SG rules are applied Status in neutron: In Progress Bug description: During the creation of a new port in the integration bridge (br-int), first the firewall rules are applied and then all flows matching this input port are deleted: if cur_tag != lvm.vlan: self.int_br.delete_flows(in_port=port.ofport) This happens only when the port is created (or the vlan tag changes). If any firewall rule is applied using the in_port as a condition, during the initialization of the firewall for this port, this rule is deleted. Instead of that, this security action should be moved to the previous function, "_add_port_tag_info", in order to avoid any firewall rule deletion and maintaining the same security level during the port creation; that means the ports doesn't allow any kind of traffic until the firewall rules are applied. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1559920/+subscriptions From 1559920 at bugs.launchpad.net Mon Mar 21 09:22:26 2016 From: 1559920 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 21 Mar 2016 09:22:26 -0000 Subject: [Openstack-security] [Bug 1559920] Fix proposed to neutron (stable/liberty) References: <20160321081847.18388.10417.malonedeb@wampee.canonical.com> Message-ID: <20160321092227.21204.39255.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/liberty Review: https://review.openstack.org/295155 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1559920 Title: Flows per in_port are deleted after SG rules are applied Status in neutron: In Progress Bug description: During the creation of a new port in the integration bridge (br-int), first the firewall rules are applied and then all flows matching this input port are deleted: if cur_tag != lvm.vlan: self.int_br.delete_flows(in_port=port.ofport) This happens only when the port is created (or the vlan tag changes). If any firewall rule is applied using the in_port as a condition, during the initialization of the firewall for this port, this rule is deleted. Instead of that, this security action should be moved to the previous function, "_add_port_tag_info", in order to avoid any firewall rule deletion and maintaining the same security level during the port creation; that means the ports doesn't allow any kind of traffic until the firewall rules are applied. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1559920/+subscriptions From swann at oopss.org Tue Mar 22 16:44:36 2016 From: swann at oopss.org (Swann Croiset) Date: Tue, 22 Mar 2016 16:44:36 -0000 Subject: [Openstack-security] [Bug 1550330] Re: Elasticsearch plugin fails to build - ca-certificates package update References: <20160226125220.1549.82312.malonedeb@wampee.canonical.com> Message-ID: <20160322164438.25053.75870.launchpad@gac.canonical.com> ** Changed in: lma-toolchain/0.8 Importance: Undecided => High ** Changed in: lma-toolchain/0.9 Importance: Undecided => High -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1550330 Title: Elasticsearch plugin fails to build - ca-certificates package update Status in LMA Toolchain: Fix Committed Status in LMA Toolchain 0.8 series: Fix Committed Status in LMA Toolchain 0.9 series: Fix Committed Bug description: the following package is not more available: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20141019ubuntu0.14.04.1_all.deb Needs to use: http://security.ubuntu.com/ubuntu/pool/main/c/ca-certificates/ca-certificates_20160104ubuntu0.14.04.1_all.deb To manage notifications about this bug go to: https://bugs.launchpad.net/lma-toolchain/+bug/1550330/+subscriptions From mzoeller at de.ibm.com Tue Mar 22 19:08:56 2016 From: mzoeller at de.ibm.com (Markus Zoeller (markus_z)) Date: Tue, 22 Mar 2016 19:08:56 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20160322190856.24859.57393.malone@gac.canonical.com> Blueprint "libvirt-virtlogd" [1] intents to make use of the libvirt feature Daniel mentioned in comment #51. [1] https://blueprints.launchpad.net/nova/+spec/libvirt-virtlogd ** Changed in: nova Assignee: Tony Breeds (o-tony) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (nova): Confirmed Status in OpenStack Security Advisory: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From 1561796 at bugs.launchpad.net Fri Mar 25 00:05:44 2016 From: 1561796 at bugs.launchpad.net (Devananda van der Veen) Date: Fri, 25 Mar 2016 00:05:44 -0000 Subject: [Openstack-security] [Bug 1561796] [NEW] ironic driver does not support ssl cafile Message-ID: <20160325000544.30735.22681.malonedeb@gac.canonical.com> Public bug reported: Even though Ironic's python client supports SSL encrypted connections to the ironic service, and securing intra-service connections is a recommended practice, the nova.virt.Ironic driver currently lacks an option to specify a custom CA Certificate for validating the SSL connection to the Ironic service. On the other hand, other OpenStack services which Nova connects to (eg, Glance, Neutron...) have support for this via a service-specific "cafile" config option. ** Affects: nova Importance: Undecided Assignee: Devananda van der Veen (devananda) Status: In Progress ** Tags: ironic security ** Tags added: ironic ** 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/1561796 Title: ironic driver does not support ssl cafile Status in OpenStack Compute (nova): In Progress Bug description: Even though Ironic's python client supports SSL encrypted connections to the ironic service, and securing intra-service connections is a recommended practice, the nova.virt.Ironic driver currently lacks an option to specify a custom CA Certificate for validating the SSL connection to the Ironic service. On the other hand, other OpenStack services which Nova connects to (eg, Glance, Neutron...) have support for this via a service-specific "cafile" config option. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1561796/+subscriptions From 1561796 at bugs.launchpad.net Fri Mar 25 00:06:51 2016 From: 1561796 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 25 Mar 2016 00:06:51 -0000 Subject: [Openstack-security] [Bug 1561796] Re: ironic driver does not support ssl cafile References: <20160325000544.30735.22681.malonedeb@gac.canonical.com> Message-ID: <20160325000651.3498.90604.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/297467 ** Changed in: nova Status: New => In Progress ** Changed in: nova Assignee: (unassigned) => Devananda van der Veen (devananda) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1561796 Title: ironic driver does not support ssl cafile Status in OpenStack Compute (nova): In Progress Bug description: Even though Ironic's python client supports SSL encrypted connections to the ironic service, and securing intra-service connections is a recommended practice, the nova.virt.Ironic driver currently lacks an option to specify a custom CA Certificate for validating the SSL connection to the Ironic service. On the other hand, other OpenStack services which Nova connects to (eg, Glance, Neutron...) have support for this via a service-specific "cafile" config option. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1561796/+subscriptions From 1450798 at bugs.launchpad.net Fri Mar 25 15:03:34 2016 From: 1450798 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 25 Mar 2016 15:03:34 -0000 Subject: [Openstack-security] [Bug 1450798] Change abandoned on nova (master) References: <20150501135051.16168.63595.malonedeb@gac.canonical.com> Message-ID: <20160325150334.24886.34826.malone@soybean.canonical.com> Change abandoned by Gleb Stepanov (gstepanov at mirantis.com) on branch: master Review: https://review.openstack.org/276751 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1450798 Title: Multiple command injection vulns in schema_diff tool Status in OpenStack Compute (nova): Invalid Status in OpenStack Security Advisory: Won't Fix Bug description: These lines in the latest Nova (as of May 1, 2015) are vulnerable to command injection https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86 https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103 https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117 In this case (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86 ), if a malicious filename such as "; rm -rf /etc" is provided, the /etc directory will be removed with the privileges of the user running this script. In this case (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103), if either a malicious name or filename are provided, the command will be executed with the privileges of the running user. In this case(https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117), if either a malicious name or filename are provided, the command will be executed with the privileges of the running user. I'm not familiar enough with the usage of this module to know all of the places these inputs can come from, but presumably it can be used in automation, potentially with elevated privileges. I'm sure the idea of this script is to allow certain functionality, not unrestricted commands. The way this has been developed allows unrestricted command execution by tampering with any of the above mentioned inputs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1450798/+subscriptions From doug at doughellmann.com Fri Mar 25 16:30:33 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 25 Mar 2016 16:30:33 -0000 Subject: [Openstack-security] [Bug 1556231] Fix included in openstack/openstack-ansible 11.2.12 References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160325163033.3850.18521.malone@wampee.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.12 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Released Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions From doug at doughellmann.com Fri Mar 25 16:32:39 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 25 Mar 2016 16:32:39 -0000 Subject: [Openstack-security] [Bug 1498726] Fix included in openstack/openstack-ansible 11.2.12 References: <20150923022208.8903.73759.malonedeb@gac.canonical.com> Message-ID: <20160325163239.30523.86855.malone@gac.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.12 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1498726 Title: Specify ciphers with HAProxy SSL frontends Status in openstack-ansible: Fix Released Bug description: For increased security, a specific cipher suite should be specified when configuring HAProxy SSL frontends. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1498726/+subscriptions From doug at doughellmann.com Fri Mar 25 16:35:37 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 25 Mar 2016 16:35:37 -0000 Subject: [Openstack-security] [Bug 1466216] Fix included in openstack/openstack-ansible 11.2.12 References: <20150617203545.4905.22166.malonedeb@wampee.canonical.com> Message-ID: <20160325163537.30383.22713.malone@gac.canonical.com> This issue was fixed in the openstack/openstack-ansible 11.2.12 release. -- 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 openstack-ansible: 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 sbauza at free.fr Tue Mar 29 10:08:14 2016 From: sbauza at free.fr (Sylvain Bauza) Date: Tue, 29 Mar 2016 10:08:14 -0000 Subject: [Openstack-security] [Bug 1561796] Re: ironic driver does not support ssl cafile References: <20160325000544.30735.22681.malonedeb@gac.canonical.com> Message-ID: <20160329100816.30768.64957.launchpad@gac.canonical.com> ** Changed in: nova Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1561796 Title: ironic driver does not support ssl cafile Status in OpenStack Compute (nova): In Progress Bug description: Even though Ironic's python client supports SSL encrypted connections to the ironic service, and securing intra-service connections is a recommended practice, the nova.virt.Ironic driver currently lacks an option to specify a custom CA Certificate for validating the SSL connection to the Ironic service. On the other hand, other OpenStack services which Nova connects to (eg, Glance, Neutron...) have support for this via a service-specific "cafile" config option. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1561796/+subscriptions From 1561796 at bugs.launchpad.net Tue Mar 29 11:19:36 2016 From: 1561796 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 29 Mar 2016 11:19:36 -0000 Subject: [Openstack-security] [Bug 1561796] Re: ironic driver does not support ssl cafile References: <20160325000544.30735.22681.malonedeb@gac.canonical.com> Message-ID: <20160329111936.30307.42319.malone@gac.canonical.com> Reviewed: https://review.openstack.org/297467 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=0230edd708eb961ad6f9afb88a778fe03320bf3e Submitter: Jenkins Branch: master commit 0230edd708eb961ad6f9afb88a778fe03320bf3e Author: Devananda van der Veen Date: Thu Mar 24 17:00:26 2016 -0700 Allow ironic driver to specify cafile This patch adds a config option to the [ironic] group, allowing the operator to specify a cacert file with which to connect to the ironic-api service. This corresponds with the way encrypted connections to other OpenStack services are configured. Change-Id: Ice1d6c3f6fc911c4f35fe0283e3d1e9dd8b0e1a7 Closes-bug: #1561796 ** Changed in: nova Status: In Progress => 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/1561796 Title: ironic driver does not support ssl cafile Status in OpenStack Compute (nova): Fix Released Bug description: Even though Ironic's python client supports SSL encrypted connections to the ironic service, and securing intra-service connections is a recommended practice, the nova.virt.Ironic driver currently lacks an option to specify a custom CA Certificate for validating the SSL connection to the Ironic service. On the other hand, other OpenStack services which Nova connects to (eg, Glance, Neutron...) have support for this via a service-specific "cafile" config option. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1561796/+subscriptions From fungi at yuggoth.org Tue Mar 29 15:40:26 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 29 Mar 2016 15:40:26 -0000 Subject: [Openstack-security] [Bug 1554288] Re: [FG-VD-16-015] Openstack Glance Authenticated User DoS Vulnerability Notification References: <20160308012033.21213.8906.malonedeb@soybean.canonical.com> Message-ID: <20160329154026.24699.8904.malone@soybean.canonical.com> Since there are no objections, I'm switching this to public and marking as a hardening opportunity. ** Changed in: ossa Status: Incomplete => Won't Fix ** 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/1554288 Title: [FG-VD-16-015] Openstack Glance Authenticated User DoS Vulnerability Notification Status in Glance: New Status in OpenStack Security Advisory: 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 to the bug as attachments. -- Vulnerability Notification March 7, 2016 Tracking Case #: FG-VD-16-015 Dear Openstack, The following information pertains to information discovered by Fortinet's FortiGuard Labs. It has been determined that a vulnerability exists in Openstack Glance module. To streamline the disclosure process, we have created a preliminary advisory which you can find below. This upcoming advisory is purely intended as a reference, and does not contain sensitive information such as proof of concept code. As a mature corporation involved in security research, we strive to responsibly disclose vulnerability information. We will not post an advisory until we determine it is appropriate to do so in co- ordination with the vendor unless a resolution cannot be reached. We will not disclose full proof of concept, only details relevant to the advisory. We look forward to working closely with you to resolve this issue, and kindly ask for your co-operation during this time. Please let us know if you have any further questions, and we will promptly respond to address any issues. If this message is not encrypted, it is because we could not find your key to do so. If you have one available for use, please notify us and we will ensure that this is used in future correspondence. We ask you use our public PGP key to encrypt and communicate any sensitive information with us. You may find the key on our FortiGuard center at: http://www.fortiguard.com/pgp_key.html. Type of Vulnerability & Repercussions:   DoS Affected Software:   Ubuntu 14.04.3 with latest repository installed   # apt-get install software-properties-common   # add-apt-repository cloud-archive:liberty Upcoming Advisory Reference:   http://www.fortiguard.com/advisory/UpcomingAdvisories.html Credits:   This vulnerability was discovered by Fortinet's FortiGuard Labs. Proof of Concept/How to Reproduce:   1. Run script "sh curl_get_token_demo_work.txt" to get a valid non-admin or admin user token. Need to replace "tenantName", "username", "password" with your Openstack credential.   2. Open script glance_DoS.py, and replace the line 30 "x-auth-token" value with the above token value, also replace the IP in url "http://10.0.0.11:9191/images" with your Openstack control node IP address.   3. Run script glance_DoS.py which will keep running forever. You can check the images added by the script using console command "glance image-list" or clicking Dashboard images column. You will notice you cannnot delete the images added by the script. It prompts failure. Refer to the screenshots glance_cli_delete_fail.png and dashboard_delete_garbage_image_fail.png.   4. Because either non-admin or admin user cannot delete the garbage images, with the above PoC running forever, more and more garbage images are added. So finally DoS can be caused because resource is exhausted or glance database query is very very slow.  Notes:      1) Run the PoC glance_DoS.py in Windows 7.  Additional Information: To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1554288/+subscriptions From tdecacqu at redhat.com Tue Mar 29 16:14:40 2016 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Tue, 29 Mar 2016 16:14:40 -0000 Subject: [Openstack-security] [Bug 1556023] Re: Direct v1 registry access can bypass Glance's policies References: <20160311102718.26376.66950.malonedeb@chaenomeles.canonical.com> Message-ID: <20160329161440.3920.67679.malone@wampee.canonical.com> Since there are no objections, I'm switching this to public and marking as a hardening opportunity. ** 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/1556023 Title: Direct v1 registry access can bypass Glance's policies Status in Glance: New Status in OpenStack Security Advisory: Won't Fix Bug description: If a non-admin user can access the registry directly, then they can bypass Glance's policies. Here, for example, is a registry request which bypasses both the policy to mark an image as public, and to set the image location directly:  PUT /images/37d89430-8bf2-433a-843e-909c752866df HTTP/1.1.  Host: 127.0.0.1:9191.  Content-Length: 606.  Accept-Encoding: gzip, deflate.  Accept: application/json.  x-auth-token: dc9e09e4954d4b42983784b3c4642bd9.  Connection: keep-alive.  User-Agent: restfuzz-0.1.0.  Content-Type: application/json.  .  {"image": {"status": "active", "deleted": false, "name": "testpublic", "container_format": "bare", "min_ram": 2147483647, "disk_format": "qcow2", "id": "37d89430-8bf2-433a-843e-909c752866df", "owner": "48c21395db63405d94aee1f965615d1c", "min_disk": 2147483647, "is_public": true, "properties": {"image_type": "snapshot", "instance_uuid": "7df74ad1-1caf-44ac-8f4b-4313f5fda5ed", "user_id": "76b4ded518594216832e06c261523074' or 1=1--", "base_image_ref": "1c8c3ba8-3a2f-4d06-b1ba-ac1791b599d8"}, "size": 6599958588555, "virtual_size": 6599958588551, "min_disk": 2147483647, "location":"http://google.com"}} Note that deployments should firewall the registry off; typical users should only have access to the Glance API endpoint. However, users such as a Swift administrator who does not have Glance admin powers but is able to access the 'private' network can bypass Glance's policies. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1556023/+subscriptions From gerrit2 at review.openstack.org Tue Mar 29 17:16:20 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 29 Mar 2016 17:16:20 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/115483 Log: commit 8bf63441abdcc0c2daa4088abb913c3f2782a93b Author: Solly Ross Date: Tue Aug 19 18:48:00 2014 -0400 Introduce VNC Security Proxy Framework This commit introduces the security proxying framework for VNC. Which class is being used to do the security proxying can be set on a per-traffic-type basis by pointing the appropriate configuration option to an appropriate subclass. Currently, only VNC is supported, via the configuration option 'novncproxy_security_driver'. The workflow for adding a new VNC security proxy driver is to subclass the traffic-type-specific security proxy base classes (e.g. RFBSecurityProxyHelper), and implement the `choose_security_type` and `security_handshake` methods. DocImpact SecurityImpact Implements bp: websocket-proxy-to-host-security Change-Id: Id586b2558fd4c7ed0eda3d3555d51fcd019eb414 From gerrit2 at review.openstack.org Tue Mar 29 17:16:32 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 29 Mar 2016 17:16:32 +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 d997f86253cb234594220968b5aa0217582bf34c 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 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 fungi at yuggoth.org Tue Mar 29 17:39:27 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 29 Mar 2016 17:39:27 -0000 Subject: [Openstack-security] [Bug 1554288] Re: [FG-VD-16-015] Openstack Glance Authenticated User DoS Vulnerability Notification References: <20160308012033.21213.8906.malonedeb@soybean.canonical.com> Message-ID: <20160329173928.3955.35406.launchpad@wampee.canonical.com> ** Description changed: - 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 to the bug as - attachments. - - -- - Vulnerability Notification March 7, 2016 Tracking Case #: FG-VD-16-015 Dear Openstack, The following information pertains to information discovered by Fortinet's FortiGuard Labs. It has been determined that a vulnerability exists in Openstack Glance module. To streamline the disclosure process, we have created a preliminary advisory which you can find below. This upcoming advisory is purely intended as a reference, and does not contain sensitive information such as proof of concept code. As a mature corporation involved in security research, we strive to responsibly disclose vulnerability information. We will not post an advisory until we determine it is appropriate to do so in co-ordination with the vendor unless a resolution cannot be reached. We will not disclose full proof of concept, only details relevant to the advisory. We look forward to working closely with you to resolve this issue, and kindly ask for your co-operation during this time. Please let us know if you have any further questions, and we will promptly respond to address any issues. If this message is not encrypted, it is because we could not find your key to do so. If you have one available for use, please notify us and we will ensure that this is used in future correspondence. We ask you use our public PGP key to encrypt and communicate any sensitive information with us. You may find the key on our FortiGuard center at: http://www.fortiguard.com/pgp_key.html. Type of Vulnerability & Repercussions:   DoS Affected Software:   Ubuntu 14.04.3 with latest repository installed   # apt-get install software-properties-common   # add-apt-repository cloud-archive:liberty Upcoming Advisory Reference:   http://www.fortiguard.com/advisory/UpcomingAdvisories.html Credits:   This vulnerability was discovered by Fortinet's FortiGuard Labs. Proof of Concept/How to Reproduce:   1. Run script "sh curl_get_token_demo_work.txt" to get a valid non-admin or admin user token. Need to replace "tenantName", "username", "password" with your Openstack credential.   2. Open script glance_DoS.py, and replace the line 30 "x-auth-token" value with the above token value, also replace the IP in url "http://10.0.0.11:9191/images" with your Openstack control node IP address.   3. Run script glance_DoS.py which will keep running forever. You can check the images added by the script using console command "glance image-list" or clicking Dashboard images column. You will notice you cannnot delete the images added by the script. It prompts failure. Refer to the screenshots glance_cli_delete_fail.png and dashboard_delete_garbage_image_fail.png.   4. Because either non-admin or admin user cannot delete the garbage images, with the above PoC running forever, more and more garbage images are added. So finally DoS can be caused because resource is exhausted or glance database query is very very slow.  Notes:      1) Run the PoC glance_DoS.py in Windows 7.  Additional Information: -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1554288 Title: [FG-VD-16-015] Openstack Glance Authenticated User DoS Vulnerability Notification Status in Glance: New Status in OpenStack Security Advisory: Won't Fix Bug description: Vulnerability Notification March 7, 2016 Tracking Case #: FG-VD-16-015 Dear Openstack, The following information pertains to information discovered by Fortinet's FortiGuard Labs. It has been determined that a vulnerability exists in Openstack Glance module. To streamline the disclosure process, we have created a preliminary advisory which you can find below. This upcoming advisory is purely intended as a reference, and does not contain sensitive information such as proof of concept code. As a mature corporation involved in security research, we strive to responsibly disclose vulnerability information. We will not post an advisory until we determine it is appropriate to do so in co- ordination with the vendor unless a resolution cannot be reached. We will not disclose full proof of concept, only details relevant to the advisory. We look forward to working closely with you to resolve this issue, and kindly ask for your co-operation during this time. Please let us know if you have any further questions, and we will promptly respond to address any issues. If this message is not encrypted, it is because we could not find your key to do so. If you have one available for use, please notify us and we will ensure that this is used in future correspondence. We ask you use our public PGP key to encrypt and communicate any sensitive information with us. You may find the key on our FortiGuard center at: http://www.fortiguard.com/pgp_key.html. Type of Vulnerability & Repercussions:   DoS Affected Software:   Ubuntu 14.04.3 with latest repository installed   # apt-get install software-properties-common   # add-apt-repository cloud-archive:liberty Upcoming Advisory Reference:   http://www.fortiguard.com/advisory/UpcomingAdvisories.html Credits:   This vulnerability was discovered by Fortinet's FortiGuard Labs. Proof of Concept/How to Reproduce:   1. Run script "sh curl_get_token_demo_work.txt" to get a valid non-admin or admin user token. Need to replace "tenantName", "username", "password" with your Openstack credential.   2. Open script glance_DoS.py, and replace the line 30 "x-auth-token" value with the above token value, also replace the IP in url "http://10.0.0.11:9191/images" with your Openstack control node IP address.   3. Run script glance_DoS.py which will keep running forever. You can check the images added by the script using console command "glance image-list" or clicking Dashboard images column. You will notice you cannnot delete the images added by the script. It prompts failure. Refer to the screenshots glance_cli_delete_fail.png and dashboard_delete_garbage_image_fail.png.   4. Because either non-admin or admin user cannot delete the garbage images, with the above PoC running forever, more and more garbage images are added. So finally DoS can be caused because resource is exhausted or glance database query is very very slow.  Notes:      1) Run the PoC glance_DoS.py in Windows 7.  Additional Information: To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1554288/+subscriptions From doug at doughellmann.com Tue Mar 29 17:49:55 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 29 Mar 2016 17:49:55 -0000 Subject: [Openstack-security] [Bug 1549547] Fix included in openstack/neutron-lbaas 7.0.4 References: <20160225002843.1623.41446.malonedeb@wampee.canonical.com> Message-ID: <20160329174955.3669.76856.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/neutron-lbaas 7.0.4 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1549547 Title: LBaaS leaking password in DEBUG logs Status in neutron: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: Current code leaks the keystone admin_password in the cfg into log files: Example from DevStack q-svc.log: [00;32mDEBUG oslo_service.service [^[[00;36m-^[[00;32m] ^[[01;35m^[[00;32mservice_auth.admin_password = password Issue is that the cfg.StrOpt for admin_password did not set 'secret=True", which would give: service_auth.admin_password = **** To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1549547/+subscriptions From gerrit2 at review.openstack.org Tue Mar 29 18:38:05 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 29 Mar 2016 18:38:05 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/115483 Log: commit 99590c18ffae9c6dc4bdb498fdf5d0b0f8a7b8da Author: Solly Ross Date: Tue Aug 19 18:48:00 2014 -0400 Introduce VNC Security Proxy Framework This commit introduces the security proxying framework for VNC. Which class is being used to do the security proxying can be set on a per-traffic-type basis by pointing the appropriate configuration option to an appropriate subclass. Currently, only VNC is supported, via the configuration option 'novncproxy_security_driver'. The workflow for adding a new VNC security proxy driver is to subclass the traffic-type-specific security proxy base classes (e.g. RFBSecurityProxyHelper), and implement the `choose_security_type` and `security_handshake` methods. DocImpact SecurityImpact Implements bp: websocket-proxy-to-host-security Change-Id: Id586b2558fd4c7ed0eda3d3555d51fcd019eb414 From gerrit2 at review.openstack.org Tue Mar 29 18:38:16 2016 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 29 Mar 2016 18:38:16 +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 fb23cab3ece9d1da26b1484d8bf4b8bea566b3ae 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 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 tmcpeak at us.ibm.com Tue Mar 29 20:19:29 2016 From: tmcpeak at us.ibm.com (Travis McPeak) Date: Tue, 29 Mar 2016 20:19:29 -0000 Subject: [Openstack-security] [Bug 1554288] Re: [FG-VD-16-015] Openstack Glance Authenticated User DoS Vulnerability Notification References: <20160308012033.21213.8906.malonedeb@soybean.canonical.com> Message-ID: <20160329201929.3675.57327.malone@wampee.canonical.com> Sorry I'm playing catch up a bit here but UUID collision definitely should be infeasible. Also image creation for non-admin users should be subject to quotas, correct? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1554288 Title: [FG-VD-16-015] Openstack Glance Authenticated User DoS Vulnerability Notification Status in Glance: New Status in OpenStack Security Advisory: Won't Fix Bug description: Vulnerability Notification March 7, 2016 Tracking Case #: FG-VD-16-015 Dear Openstack, The following information pertains to information discovered by Fortinet's FortiGuard Labs. It has been determined that a vulnerability exists in Openstack Glance module. To streamline the disclosure process, we have created a preliminary advisory which you can find below. This upcoming advisory is purely intended as a reference, and does not contain sensitive information such as proof of concept code. As a mature corporation involved in security research, we strive to responsibly disclose vulnerability information. We will not post an advisory until we determine it is appropriate to do so in co- ordination with the vendor unless a resolution cannot be reached. We will not disclose full proof of concept, only details relevant to the advisory. We look forward to working closely with you to resolve this issue, and kindly ask for your co-operation during this time. Please let us know if you have any further questions, and we will promptly respond to address any issues. If this message is not encrypted, it is because we could not find your key to do so. If you have one available for use, please notify us and we will ensure that this is used in future correspondence. We ask you use our public PGP key to encrypt and communicate any sensitive information with us. You may find the key on our FortiGuard center at: http://www.fortiguard.com/pgp_key.html. Type of Vulnerability & Repercussions:   DoS Affected Software:   Ubuntu 14.04.3 with latest repository installed   # apt-get install software-properties-common   # add-apt-repository cloud-archive:liberty Upcoming Advisory Reference:   http://www.fortiguard.com/advisory/UpcomingAdvisories.html Credits:   This vulnerability was discovered by Fortinet's FortiGuard Labs. Proof of Concept/How to Reproduce:   1. Run script "sh curl_get_token_demo_work.txt" to get a valid non-admin or admin user token. Need to replace "tenantName", "username", "password" with your Openstack credential.   2. Open script glance_DoS.py, and replace the line 30 "x-auth-token" value with the above token value, also replace the IP in url "http://10.0.0.11:9191/images" with your Openstack control node IP address.   3. Run script glance_DoS.py which will keep running forever. You can check the images added by the script using console command "glance image-list" or clicking Dashboard images column. You will notice you cannnot delete the images added by the script. It prompts failure. Refer to the screenshots glance_cli_delete_fail.png and dashboard_delete_garbage_image_fail.png.   4. Because either non-admin or admin user cannot delete the garbage images, with the above PoC running forever, more and more garbage images are added. So finally DoS can be caused because resource is exhausted or glance database query is very very slow.  Notes:      1) Run the PoC glance_DoS.py in Windows 7.  Additional Information: To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1554288/+subscriptions From doug at doughellmann.com Wed Mar 30 10:37:21 2016 From: doug at doughellmann.com (Doug Hellmann) Date: Wed, 30 Mar 2016 10:37:21 -0000 Subject: [Openstack-security] [Bug 1556231] Fix included in openstack/openstack-ansible 12.0.9 References: <20160311182127.26542.80930.malonedeb@chaenomeles.canonical.com> Message-ID: <20160330103721.3955.52467.malone@wampee.canonical.com> This issue was fixed in the openstack/openstack-ansible 12.0.9 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1556231 Title: Rootwrap configuration has incorrect ownership Status in openstack-ansible: Fix Committed Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Released Status in openstack-ansible trunk series: Fix Committed Bug description: The /etc//rootwrap.conf file and /etc//rootwrap.d directory and its contents created by the Nova, Neutron, Cinder and Ceilomer playbooks/roles are incorrectly owned by a user other than root. This is a security vulnerability inasmuch as it may allow users with lower privileges to modify the rootwrap configuration and escalate privileges. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1556231/+subscriptions