From 1611171 at bugs.launchpad.net Tue Nov 1 16:26:30 2016 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 01 Nov 2016 16:26:30 -0000 Subject: [Openstack-security] [Bug 1611171] Re: re-runs self via sudo References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <20161101162630.21179.47063.malone@gac.canonical.com> Reviewed: https://review.openstack.org/371930 Committed: https://git.openstack.org/cgit/openstack/ec2-api/commit/?id=f8dbd1cc45a1ceeedebf80607ef72eaaaba174a9 Submitter: Jenkins Branch: master commit f8dbd1cc45a1ceeedebf80607ef72eaaaba174a9 Author: Iswarya_Vakati Date: Sat Sep 17 18:28:28 2016 +0530 Don't attempt to escalate ec2-api-manage privileges Remove code which allowed ec2-api-manage to attempt to escalate privileges so that configuration files can be read by users who normally wouldn't have access, but do have sudo access. Change-Id: I1ab7052fc117f064054e3127517da77598b6d27b Closes-Bug:#1611171 ** Changed in: ec2-api 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/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From 1611171 at bugs.launchpad.net Mon Nov 7 04:59:47 2016 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 07 Nov 2016 04:59:47 -0000 Subject: [Openstack-security] [Bug 1611171] Fix included in openstack/nova 14.0.2 References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <20161107045947.29634.52183.malone@wampee.canonical.com> This issue was fixed in the openstack/nova 14.0.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/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From 1419577 at bugs.launchpad.net Mon Nov 7 20:05:30 2016 From: 1419577 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 07 Nov 2016 20:05:30 -0000 Subject: [Openstack-security] [Bug 1419577] Change abandoned on nova (master) References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <20161107200530.29321.70473.malone@wampee.canonical.com> Change abandoned by Lee Yarwood (lyarwood at redhat.com) on branch: master Review: https://review.openstack.org/391598 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1419577 Title: when live-migrate failed, lun-id couldn't be rollback in havana Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: Hi, guys When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback. and failed VM can have others volume. my test environment is following : Openstack Version : Havana ( 2013.2.3) Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 1 cinder volume (vol01) 4) attach 1 volume to vm01 (/dev/vdb) 5) live-migrate vm01 from host#1 to host#2 6) live-migrate success      - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.        and the status of devices is "failed faulty"      - please check the lun-id of vol01 7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4) 8) live-migrate fail      - please check the mapper in host#1      - please check the lun-id of vol01, then you can find the lun hav "two" igroups      - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback This Bug is critical security issue because the failed VM can have others volume. and every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. I suggest below methods to solve issue : 1) when live-migrate is complete, nova should delete mapper devices at origin host 2) when live-migrate is failed, nova should rollback lun-id in connection_info column 3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...) 4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping please check this bug. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions From 1532317 at bugs.launchpad.net Thu Nov 10 00:51:05 2016 From: 1532317 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 00:51:05 -0000 Subject: [Openstack-security] [Bug 1532317] Fix included in openstack/murano 2015.1.1 References: <20160108202404.8643.13925.malonedeb@wampee.canonical.com> Message-ID: <20161110005105.4382.42007.malone@gac.canonical.com> This issue was fixed in the openstack/murano 2015.1.1 release. -- 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 1472331 at bugs.launchpad.net Thu Nov 10 00:51:40 2016 From: 1472331 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 00:51:40 -0000 Subject: [Openstack-security] [Bug 1472331] Fix included in openstack/murano 2015.1.1 References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Message-ID: <20161110005140.4547.36819.malone@gac.canonical.com> This issue was fixed in the openstack/murano 2015.1.1 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472331 Title: Trust id is not hidden in logs Status in Murano: Fix Released Status in Murano kilo series: Fix Committed Bug description: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1472331/+subscriptions From 1586079 at bugs.launchpad.net Thu Nov 10 01:07:20 2016 From: 1586079 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 01:07:20 -0000 Subject: [Openstack-security] [Bug 1586079] Fix included in openstack/murano-dashboard 1.0.3 References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com> Message-ID: <20161110010721.4454.83106.malone@gac.canonical.com> This issue was fixed in the openstack/murano-dashboard 1.0.3 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1586079 Title: YaqlYamlLoader inherits from YamlLoader Status in Murano: Fix Released Status in Murano kilo series: Won't Fix Status in Murano liberty series: Fix Released Status in Murano mitaka series: Fix Released Status in Murano newton series: Fix Released Bug description: YaqlYamlLoader inherits from YamlLoader, meaning that it is possible to use extended unsafe tags in yaml files http://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes Both dashboard, engine/api seem to be vulnerable. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1586079/+subscriptions From 1586079 at bugs.launchpad.net Thu Nov 10 01:07:29 2016 From: 1586079 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 01:07:29 -0000 Subject: [Openstack-security] [Bug 1586079] Fix included in openstack/murano 1.0.3 References: <20160526151540.19337.24947.malonedeb@soybean.canonical.com> Message-ID: <20161110010729.4327.73511.malone@wampee.canonical.com> This issue was fixed in the openstack/murano 1.0.3 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1586079 Title: YaqlYamlLoader inherits from YamlLoader Status in Murano: Fix Released Status in Murano kilo series: Won't Fix Status in Murano liberty series: Fix Released Status in Murano mitaka series: Fix Released Status in Murano newton series: Fix Released Bug description: YaqlYamlLoader inherits from YamlLoader, meaning that it is possible to use extended unsafe tags in yaml files http://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes Both dashboard, engine/api seem to be vulnerable. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1586079/+subscriptions From 1586078 at bugs.launchpad.net Thu Nov 10 01:15:05 2016 From: 1586078 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 01:15:05 -0000 Subject: [Openstack-security] [Bug 1586078] Fix included in openstack/python-muranoclient 0.7.3 References: <20160526151327.17490.6569.malonedeb@soybean.canonical.com> Message-ID: <20161110011505.3891.46749.malone@wampee.canonical.com> This issue was fixed in the openstack/python-muranoclient 0.7.3 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1586078 Title: YaqlYamlLoader inherits from YamlLoader Status in python-muranoclient: Fix Released Status in python-muranoclient kilo series: Won't Fix Status in python-muranoclient liberty series: Fix Committed Status in python-muranoclient mitaka series: Fix Committed Status in python-muranoclient newton series: Fix Released Bug description: YaqlYamlLoader inherits from YamlLoader, meaning that it is possible to use extended unsafe tags in yaml files http://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes To manage notifications about this bug go to: https://bugs.launchpad.net/python-muranoclient/+bug/1586078/+subscriptions From 1556231 at bugs.launchpad.net Thu Nov 10 01:11:27 2016 From: 1556231 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 01:11:27 -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: <20161110011127.31809.17800.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 Released Status in openstack-ansible kilo series: Fix Released Status in openstack-ansible liberty series: Fix Released Status in openstack-ansible trunk series: Fix Released 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 1552291 at bugs.launchpad.net Thu Nov 10 01:07:45 2016 From: 1552291 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 01:07:45 -0000 Subject: [Openstack-security] [Bug 1552291] Fix included in openstack/murano 1.0.3 References: <20160302155143.1515.80235.malonedeb@soybean.canonical.com> Message-ID: <20161110010745.31780.41821.malone@soybean.canonical.com> This issue was fixed in the openstack/murano 1.0.3 release. -- 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 Released 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 1534299 at bugs.launchpad.net Thu Nov 10 01:14:39 2016 From: 1534299 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 01:14:39 -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: <20161110011440.21635.80527.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 1532317 at bugs.launchpad.net Thu Nov 10 01:07:55 2016 From: 1532317 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 01:07:55 -0000 Subject: [Openstack-security] [Bug 1532317] Fix included in openstack/murano 1.0.3 References: <20160108202404.8643.13925.malonedeb@wampee.canonical.com> Message-ID: <20161110010755.4250.17936.malone@gac.canonical.com> This issue was fixed in the openstack/murano 1.0.3 release. -- 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 1422046 at bugs.launchpad.net Thu Nov 10 01:13:09 2016 From: 1422046 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 01:13:09 -0000 Subject: [Openstack-security] [Bug 1422046] Fix included in openstack/python-cinderclient 1.4.0 References: <20150215013602.20879.11525.malonedeb@wampee.canonical.com> Message-ID: <20161110011309.32193.39577.malone@soybean.canonical.com> This issue was fixed in the openstack/python-cinderclient 1.4.0 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1422046 Title: cinder backup-list is always listing all tenants's bug for admin Status in OpenStack Dashboard (Horizon): New Status in ospurge: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in python-cinderclient: Fix Released Status in python-cinderclient package in Ubuntu: Fix Released Bug description: cinder backup-list doesn't support '--all-tenants' argument for admin wright now. This lead to admin always getting all tenants's backups. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1422046/+subscriptions From 1611171 at bugs.launchpad.net Thu Nov 10 02:34:13 2016 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 10 Nov 2016 02:34:13 -0000 Subject: [Openstack-security] [Bug 1611171] Fix included in openstack/nova 14.0.2 References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <20161110023413.4579.50578.malone@gac.canonical.com> This issue was fixed in the openstack/nova 14.0.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/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From fungi at yuggoth.org Fri Nov 11 21:02:21 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 11 Nov 2016 21:02:21 -0000 Subject: [Openstack-security] [Bug 1639032] Re: Hardcoded password sent plaintext References: <20161103200833.21606.82991.malonedeb@gac.canonical.com> Message-ID: <20161111210221.22690.64463.malone@chaenomeles.canonical.com> Thanks Sean. I am sufficiently convinced that there's no risk in switching this to public, at the very least. I'm setting the OSSA task to invalid as well, though that is easily reversible if for some reason we find out there is some action we need to take (however unlikely). ** Information type changed from Private Security to Public ** Changed in: ossa 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/1639032 Title: Hardcoded password sent plaintext Status in Cinder: Invalid Status in OpenStack Security Advisory: Invalid 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. In cinder/volume/drivers/nexenta/utils.py:103 there is a hardcoded password. This password is then used in cinder/volume/drivers/nexenta/iscsi.py and cinder/volume/drivers/nexenta/nfs.py. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1639032/+subscriptions From 1514396 at bugs.launchpad.net Sun Nov 13 03:21:40 2016 From: 1514396 at bugs.launchpad.net (Steve Martinelli) Date: Sun, 13 Nov 2016 03:21:40 -0000 Subject: [Openstack-security] [Bug 1514396] Re: cinder backup-list is always listing all tenants's bug for admin in V1 api References: <20151109111138.23414.38152.malonedeb@gac.canonical.com> Message-ID: <20161113032140.3720.36210.malone@wampee.canonical.com> As far as i can tell, this was fixed by bug 1422046, and new versions of cinderclient should fix this in ospurge ** Changed in: ospurge Status: Confirmed => Invalid -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1514396 Title: cinder backup-list is always listing all tenants's bug for admin in V1 api Status in ospurge: Invalid Status in OpenStack Security Advisory: Won't Fix Status in python-cinderclient: Fix Released Bug description: https://bugs.launchpad.net/python-cinderclient/+bug/1422046 has been fixed for V2 only This is a security issue cause it leads to deleting all production backups when logged as admin To manage notifications about this bug go to: https://bugs.launchpad.net/ospurge/+bug/1514396/+subscriptions From major at mhtx.net Mon Nov 14 20:51:14 2016 From: major at mhtx.net (Major Hayden) Date: Mon, 14 Nov 2016 20:51:14 -0000 Subject: [Openstack-security] [Bug 1641729] [NEW] Enable repo GPG checks breaks yum in CentOS Message-ID: <20161114205114.5475.37635.malonedeb@chaenomeles.canonical.com> Public bug reported: Setting repo_gpgcheck=1 for RHEL-07-020152 causes some CentOS systems to become unable to retrieve yum repository information. In addition, it has caused gate jobs for the security role to balloon out to 12 minutes (normally 2-4 minutes). This affects the RHEL7 STIG work only. ** Affects: openstack-ansible Importance: Undecided Assignee: Major Hayden (rackerhacker) Status: In Progress ** Tags: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1641729 Title: Enable repo GPG checks breaks yum in CentOS Status in openstack-ansible: In Progress Bug description: Setting repo_gpgcheck=1 for RHEL-07-020152 causes some CentOS systems to become unable to retrieve yum repository information. In addition, it has caused gate jobs for the security role to balloon out to 12 minutes (normally 2-4 minutes). This affects the RHEL7 STIG work only. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1641729/+subscriptions From 1641729 at bugs.launchpad.net Mon Nov 14 20:52:25 2016 From: 1641729 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 14 Nov 2016 20:52:25 -0000 Subject: [Openstack-security] [Bug 1641729] Re: Enable repo GPG checks breaks yum in CentOS References: <20161114205114.5475.37635.malonedeb@chaenomeles.canonical.com> Message-ID: <20161114205225.3362.43138.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/397370 ** Changed in: openstack-ansible 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/1641729 Title: Enable repo GPG checks breaks yum in CentOS Status in openstack-ansible: In Progress Bug description: Setting repo_gpgcheck=1 for RHEL-07-020152 causes some CentOS systems to become unable to retrieve yum repository information. In addition, it has caused gate jobs for the security role to balloon out to 12 minutes (normally 2-4 minutes). This affects the RHEL7 STIG work only. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1641729/+subscriptions From 1578466 at bugs.launchpad.net Tue Nov 15 14:01:29 2016 From: 1578466 at bugs.launchpad.net (Steve Martinelli) Date: Tue, 15 Nov 2016 14:01:29 -0000 Subject: [Openstack-security] [Bug 1578466] Re: keystone token cache should offer encryption like the middleware cache does References: <20160505031406.17572.11746.malonedeb@soybean.canonical.com> Message-ID: <20161115140130.3880.61292.launchpad@soybean.canonical.com> ** 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/1578466 Title: keystone token cache should offer encryption like the middleware cache does Status in OpenStack Identity (keystone): Triaged Bug description: Keystone middleware's caching of tokens offers HMAC validation and encryption of the tokens in the cache. This is important because memcache has literally zero authentication or protection from any user on the system. So this feature should be ported in from keystone middleware into keystone. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1578466/+subscriptions From 1578466 at bugs.launchpad.net Tue Nov 15 16:04:35 2016 From: 1578466 at bugs.launchpad.net (Steve Martinelli) Date: Tue, 15 Nov 2016 16:04:35 -0000 Subject: [Openstack-security] [Bug 1578466] Re: keystone token cache should offer encryption like the middleware cache does References: <20160505031406.17572.11746.malonedeb@soybean.canonical.com> Message-ID: <20161115160436.19605.62498.launchpad@gac.canonical.com> ** Tags added: caching -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1578466 Title: keystone token cache should offer encryption like the middleware cache does Status in OpenStack Identity (keystone): Triaged Bug description: Keystone middleware's caching of tokens offers HMAC validation and encryption of the tokens in the cache. This is important because memcache has literally zero authentication or protection from any user on the system. So this feature should be ported in from keystone middleware into keystone. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1578466/+subscriptions From 1613901 at bugs.launchpad.net Tue Nov 15 16:06:08 2016 From: 1613901 at bugs.launchpad.net (Steve Martinelli) Date: Tue, 15 Nov 2016 16:06:08 -0000 Subject: [Openstack-security] [Bug 1613901] Re: String "..%c0%af" causes 500 errors in multiple locations References: <20160816233137.14656.30722.malonedeb@soybean.canonical.com> Message-ID: <20161115160612.3399.57215.launchpad@soybean.canonical.com> ** Changed in: keystone Status: Confirmed => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1613901 Title: String "..%c0%af" causes 500 errors in multiple locations Status in Cinder: Incomplete Status in Glance: New Status in OpenStack Identity (keystone): Incomplete Status in neutron: Incomplete Status in OpenStack Security Advisory: Won't Fix Bug description: While doing some testing on Keystone using Syntribos (https://github.com/openstack/syntribos), our team (myself, Michael Dong, Rahul U Nair, Vinay Potluri, Aastha Dixit, and Khanak Nangia) noticed that we got 500 status codes when the string "..%c0%af" was inserted in various places in the URL for different types of requests. Here are some examples: ========= DELETE /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] Content-Length: 0 HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:04:27 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-238fd5a9-be45-41f2-893a-97b513b27af3 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= PATCH /v3/policies/..%c0%af HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 Content-type: application/json X-Auth-Token: [REDACTED] Content-Length: 70 {"type": "--serialization-mime-type--", "blob": "--serialized-blob--"} HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:05:36 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-57a41600-02b4-4d2a-b3e9-40f7724d65f2 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= GET /v3/domains/0426ac1e48f642ef9544c2251e07e261/groups/..%c0%af/roles HTTP/1.1 Host: [REDACTED]:5000 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.0 X-Auth-Token: [REDACTED] HTTP/1.1 500 Internal Server Error Date: Tue, 16 Aug 2016 22:07:09 GMT Server: Apache/2.4.7 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-request-id: req-02313f77-63c6-4aa8-a87e-e3d2a13ad6b7 Content-Length: 143 Connection: close Content-Type: application/json {"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}} ========= I've marked this as a security issue as a precaution in case it turns out that there is a more serious vulnerability underlying these errors. We have no reason to suspect that there is a greater vulnerability at this time, but given the many endpoints this seems to affect, I figured caution was worthwhile since this may be a framework-wide issue. Feel free to make this public if it is determined not to be security-impacting. Here is a (possibly incomplete) list of affected endpoints. Inserting the string "..%c0%af" in any or all of the spots labeled "HERE" should yield a 500 error. As you can see, virtually all v3 endpoints exhibit this behavior. ========= [GET|PATCH|DELETE] /v3/endpoints/[HERE] [GET|PATCH] /v3/domains/[HERE] GET /v3/domains/[HERE]/groups/[HERE]/roles [HEAD|PUT|DELETE] /v3/domains/[HERE]/groups/[HERE]/roles/[HERE] GET /v3/domains/[HERE]/users/[HERE]/roles [HEAD|DELETE] /v3/domains/[HERE]/users/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/groups/[HERE] [HEAD|PUT|DELETE] /v3/groups[HERE]/users/[HERE] [POST|DELETE] /v3/keys/[HERE] [GET|PATCH|DELETE] /v3/policies/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/endpoints/[HERE] [GET|HEAD] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/policy [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/[HERE] [GET|PUT|DELETE] /v3/policies/[HERE]/OS-ENDPOINT-POLICY/services/regions/[HERE] [GET|PATCH|DELETE] /v3/projects/[HERE] [DELETE|PATCH] /v3/projects/[HERE]/cascade GET /v3/projects/[HERE]/groups/[HERE]/roles GET /v3/projects/[HERE]/users/[HERE]/roles [HEAD|PUT|DELETE] /v3/projects/[HERE]/groups/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/regions/[HERE] [PATCH|DELETE] /v3/roles/[HERE] [GET|PATCH|DELETE] /v3/services/[HERE] [GET|PATCH|DELETE] /v3/users/[HERE] GET /v3/users/[HERE]/groups POST /v3/users/[HERE]/password GET /v3/users/[HERE]/projects GET /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE]/roles/[HERE] [GET|PATCH|DELETE] /v3/OS-OAUTH1/consumers/[HERE] [GET|DELETE] /v3/OS-OAUTH1/users/[HERE]/access_tokens/[HERE] To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1613901/+subscriptions From anto0192 at orange.fr Wed Nov 16 10:16:44 2016 From: anto0192 at orange.fr (Antonin M) Date: Wed, 16 Nov 2016 11:16:44 +0100 (CET) Subject: [Openstack-security] Security Guideline pdf + SCAP implementation Message-ID: <1974572544.4329.1479291404621.JavaMail.www@wwinf1k31> Hi all,   It might be a simple question, but I haven't find a way to do so. I would like to know if it is possible to download the Security Guide (http://docs.openstack.org/security-guide/) in pdf? My other question is about SCAP files (https://scap.nist.gov/index.html). Is there any SCAP files available (OVAL/XCCDF…) in order to check the security compliance described in the Security Guide? If not, is it planned to generate those kind of files?   Best Regards, Antonin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhinds at redhat.com Wed Nov 16 11:50:44 2016 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 16 Nov 2016 11:50:44 +0000 Subject: [Openstack-security] Security Guideline pdf + SCAP implementation In-Reply-To: <1974572544.4329.1479291404621.JavaMail.www@wwinf1k31> References: <1974572544.4329.1479291404621.JavaMail.www@wwinf1k31> Message-ID: On Wed, Nov 16, 2016 at 10:16 AM, Antonin M wrote: > Hi all, > > > > It might be a simple question, but I haven't find a way to do so. I would > like to know if it is possible to download the Security Guide ( > http://docs.openstack.org/security-guide/) in pdf? > I thought there used to be one, but it seems not. You could use the rst2pdf sphinx plugin, and I will also ask on the OSSP IRC meeting tomorrow. > My other question is about SCAP files (https://scap.nist.gov/index.html). > Is there any SCAP files available (OVAL/XCCDF…) in order to check the > security compliance described in the Security Guide? If not, is it planned > to generate those kind of files? > There are some that were put up as prototypes that use the same recommendations as the security guide / security notes, but they are outdated (OSP7 is Kilo) https://github.com/OpenSCAP/scap-security-guide/tree/master/OpenStack/RHEL-OSP/7 I am planning to update these shortly to work with /master and then tag a version for each release in the scap profiles. I can email you when something is up that can be taking out for a test drive. Luke > > > Best Regards, > > Antonin > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anto0192 at orange.fr Wed Nov 16 16:42:42 2016 From: anto0192 at orange.fr (Antonin M) Date: Wed, 16 Nov 2016 17:42:42 +0100 (CET) Subject: [Openstack-security] Security Guideline pdf + SCAP implementation In-Reply-To: References: <1974572544.4329.1479291404621.JavaMail.www@wwinf1k31> Message-ID: <1189948638.11549.1479314562045.JavaMail.www@wwinf1f15> Thanks for your answers Luke. I exported the doc using Sphinx and rst2pdf. Got some trouble with Adobe Reader that detects the file as a corrupted one. No problem with other pdf readers. Yes, I would really appreciate if you could email me when something is ready for testing. Regards, Antonin   > Message du 16/11/16 12:50 > De : "Luke Hinds" > A : "Antonin M" > Copie à : openstack-security at lists.openstack.org > Objet : Re: [Openstack-security] Security Guideline pdf + SCAP implementation > > > > On Wed, Nov 16, 2016 at 10:16 AM, Antonin M wrote: > > > Hi all,   It might be a simple question, but I haven't find a way to do so. I would like to know if it is possible to download the Security Guide (http://docs.openstack.org/security-guide/) in pdf? > I thought there used to be one, but it seems not. You could use the rst2pdf sphinx plugin, and I will also ask on the OSSP IRC meeting tomorrow.   My other question is about SCAP files (https://scap.nist.gov/index.html). Is there any SCAP files available (OVAL/XCCDF…) in order to check the security compliance described in the Security Guide? If not, is it planned to generate those kind of files? > There are some that were put up as prototypes that use the same recommendations as the security guide / security notes, but they are outdated (OSP7 is Kilo) > https://github.com/OpenSCAP/scap-security-guide/tree/master/OpenStack/RHEL-OSP/7 > > I am planning to update these shortly to work with /master and then tag a version for each release in the scap profiles. > I can email you when something is up that can be taking out for a test drive. > Luke     Best Regards, Antonin > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1611171 at bugs.launchpad.net Wed Nov 16 16:51:24 2016 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 16 Nov 2016 16:51:24 -0000 Subject: [Openstack-security] [Bug 1611171] Fix included in openstack/cinder 10.0.0.0b1 References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <20161116165124.5084.91104.malone@wampee.canonical.com> This issue was fixed in the openstack/cinder 10.0.0.0b1 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/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From 1641729 at bugs.launchpad.net Thu Nov 17 03:02:31 2016 From: 1641729 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 17 Nov 2016 03:02:31 -0000 Subject: [Openstack-security] [Bug 1641729] Re: Enable repo GPG checks breaks yum in CentOS References: <20161114205114.5475.37635.malonedeb@chaenomeles.canonical.com> Message-ID: <20161117030231.6123.29873.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/397370 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=8868011d4cd039e926e7a6f843d65f1c3b0ecf38 Submitter: Jenkins Branch: master commit 8868011d4cd039e926e7a6f843d65f1c3b0ecf38 Author: Major Hayden Date: Mon Nov 14 15:20:04 2016 -0600 Disable repo GPG checks by default Enable repo GPG checks causes some CentOS systems to become unable to retrieve yum metadata. It also causes the security gate jobs to balloon out to 12 minutes (normally 3-4 mins). Closes-Bug: 1641729 Change-Id: I229b471bbd9fbe39776b9022671b03da0a659163 ** Changed in: openstack-ansible 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/1641729 Title: Enable repo GPG checks breaks yum in CentOS Status in openstack-ansible: Fix Released Bug description: Setting repo_gpgcheck=1 for RHEL-07-020152 causes some CentOS systems to become unable to retrieve yum repository information. In addition, it has caused gate jobs for the security role to balloon out to 12 minutes (normally 2-4 minutes). This affects the RHEL7 STIG work only. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1641729/+subscriptions From 1611171 at bugs.launchpad.net Thu Nov 17 13:12:47 2016 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 17 Nov 2016 13:12:47 -0000 Subject: [Openstack-security] [Bug 1611171] Fix included in openstack/nova 15.0.0.0b1 References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <20161117131247.8310.39767.malone@soybean.canonical.com> This issue was fixed in the openstack/nova 15.0.0.0b1 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/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From 1641729 at bugs.launchpad.net Fri Nov 18 16:30:52 2016 From: 1641729 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 18 Nov 2016 16:30:52 -0000 Subject: [Openstack-security] [Bug 1641729] Fix included in openstack/openstack-ansible-security 15.0.0.0b1 References: <20161114205114.5475.37635.malonedeb@chaenomeles.canonical.com> Message-ID: <20161118163052.5356.9700.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/openstack-ansible-security 15.0.0.0b1 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/1641729 Title: Enable repo GPG checks breaks yum in CentOS Status in openstack-ansible: Fix Released Bug description: Setting repo_gpgcheck=1 for RHEL-07-020152 causes some CentOS systems to become unable to retrieve yum repository information. In addition, it has caused gate jobs for the security role to balloon out to 12 minutes (normally 2-4 minutes). This affects the RHEL7 STIG work only. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1641729/+subscriptions From 1268751 at bugs.launchpad.net Fri Nov 18 18:32:20 2016 From: 1268751 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 18 Nov 2016 18:32:20 -0000 Subject: [Openstack-security] [Bug 1268751] Related fix proposed to keystone (master) References: <20140113215431.25014.35474.malonedeb@chaenomeles.canonical.com> Message-ID: <20161118183221.8684.92922.malone@soybean.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/399728 -- 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): Won't Fix 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 yamamoto at midokura.com Tue Nov 22 10:18:19 2016 From: yamamoto at midokura.com (YAMAMOTO Takashi) Date: Tue, 22 Nov 2016 10:18:19 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20161122101821.8477.44350.malone@soybean.canonical.com> this is an ancient bug and the symptom has not been seen these days. let's assume it was fixed. please open a new bug if you see the issue again. ** Changed in: networking-midonet Importance: Undecided => Low ** Changed in: networking-midonet Status: Incomplete => Fix Released ** Changed in: networking-midonet Milestone: None => 3.0.0 ** Changed in: networking-midonet Assignee: (unassigned) => YAMAMOTO Takashi (yamamoto) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in networking-midonet: Fix Released Status in neutron havana series: New Status in OpenStack Security Advisory: Won't Fix Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-midonet/+bug/1244025/+subscriptions From charles.neill at rackspace.com Wed Nov 23 16:27:53 2016 From: charles.neill at rackspace.com (Charles Neill) Date: Wed, 23 Nov 2016 16:27:53 -0000 Subject: [Openstack-security] [Bug 1625402] Re: Authenticated "Billion laughs" memory exhaustion / DoS vulnerability in ovf_process.py References: <20160920002310.32086.46442.malonedeb@wampee.canonical.com> Message-ID: <20161123162753.8206.28364.malone@gac.canonical.com> Any new thoughts on this? Should I reach out to MITRE about getting a CVE assigned? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1625402 Title: Authenticated "Billion laughs" memory exhaustion / DoS vulnerability in ovf_process.py Status in Glance: Opinion Status in OpenStack Security Advisory: Opinion Bug description: Creating a task to import an OVA file with a malicious OVF file inside it will result in significant memory usage by the glance-api process. This is caused by the use of the xml.etree module in ovf_process.py [1] [2] to process OVF images extracted from OVA files with ET.iterparse(). No validation is currently performed on the XML prior to parsing. As outlined in the Python documentation, xml.etree is vulnerable to the "billion laughs" vulnerability when parsing untrusted input [3] Note: if using a devstack instance, you will need to edit the "work_dir" variable in /etc/glance/glance-api.conf to point to a real folder. ----------------------------------------- Example request ----------------------------------------- POST /v2/tasks HTTP/1.1 Host: localhost:1338 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.1 Content-Type: application/json X-Auth-Token: [ADMIN TOKEN] Content-Length: 287 {     "type": "import",     "input": {         "import_from": "http://127.0.0.1:9090/laugh.ova",         "import_from_format": "raw",         "image_properties": {             "disk_format": "raw",             "container_format": "ova",      "name": "laugh"         }     } } ----------------------------------------- Creating the malicious OVA/OVF ----------------------------------------- "laugh.ova" can be created like so: 1. Copy this into a file called "laugh.ovf":                       ]> &lol10; 2. Create the OVA file (tarball) with the "tar" utility:     $ tar -cf laugh.ova.tar laugh.ovf && mv laugh.ova.tar laugh.ova 3. (Optional) If you want to serve this from your devstack instance (as in the request above), run this in the folder where you created the OVA file:     $ python -m SimpleHTTPServer 9090 ----------------------------------------- Performance impact ----------------------------------------- Profiling my VM from a fresh boot: $ vboxmanage metrics query [VM NAME] Guest/RAM/Usage/Free,Guest/Pagefile/Usage/Total,Guest/CPU/Load/User:avg Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 13.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 2456680 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB After submitting this task twice (repeating calls to the above command): Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1989684 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 88.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1694080 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 83.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1426876 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 79.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1181248 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 85.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 817244 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 548636 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 74.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 118932 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB After submitting enough of these requests at once, glance-api runs out of memory and can't restart itself. Here's what the log looks like after the "killer request" [4] ----------------------------------------- Mitigation ----------------------------------------- Any instances of xml.etree should be replaced with their equivalent in a secure XML parsing library like defusedxml [5] 1: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L21-L24 2: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L184 3: https://docs.python.org/2/library/xml.html#xml-vulnerabilities 4: https://gist.github.com/cneill/5265d887e0125c0e20254282a6d8ae64 5: https://pypi.python.org/pypi/defusedxml ----------------------------------------- Other ----------------------------------------- Thanks to Rahul Nair from the OpenStack Security Project for bringing the ovf_process file to my attention in the first place. We are testing Glance for security defects as part of OSIC, using our API security testing tool called Syntribos (https://github.com/openstack/syntribos), and Bandit (which was used to discover this issue). To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1625402/+subscriptions From fungi at yuggoth.org Wed Nov 23 17:12:01 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 23 Nov 2016 17:12:01 -0000 Subject: [Openstack-security] [Bug 1625402] Re: Authenticated "Billion laughs" memory exhaustion / DoS vulnerability in ovf_process.py References: <20160920002310.32086.46442.malonedeb@wampee.canonical.com> Message-ID: <20161123171202.8768.63353.malone@gac.canonical.com> Anyone's welcome to request a CVE assignment for a bug report. The OpenStack VMT isn't going to request one themselves because they don't plan to issue an advisory about this one, and it doesn't look like there are plans for the Glance team to "fix" it anyway. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1625402 Title: Authenticated "Billion laughs" memory exhaustion / DoS vulnerability in ovf_process.py Status in Glance: Opinion Status in OpenStack Security Advisory: Opinion Bug description: Creating a task to import an OVA file with a malicious OVF file inside it will result in significant memory usage by the glance-api process. This is caused by the use of the xml.etree module in ovf_process.py [1] [2] to process OVF images extracted from OVA files with ET.iterparse(). No validation is currently performed on the XML prior to parsing. As outlined in the Python documentation, xml.etree is vulnerable to the "billion laughs" vulnerability when parsing untrusted input [3] Note: if using a devstack instance, you will need to edit the "work_dir" variable in /etc/glance/glance-api.conf to point to a real folder. ----------------------------------------- Example request ----------------------------------------- POST /v2/tasks HTTP/1.1 Host: localhost:1338 Connection: close Accept-Encoding: gzip, deflate Accept: application/json User-Agent: python-requests/2.11.1 Content-Type: application/json X-Auth-Token: [ADMIN TOKEN] Content-Length: 287 {     "type": "import",     "input": {         "import_from": "http://127.0.0.1:9090/laugh.ova",         "import_from_format": "raw",         "image_properties": {             "disk_format": "raw",             "container_format": "ova",      "name": "laugh"         }     } } ----------------------------------------- Creating the malicious OVA/OVF ----------------------------------------- "laugh.ova" can be created like so: 1. Copy this into a file called "laugh.ovf":                       ]> &lol10; 2. Create the OVA file (tarball) with the "tar" utility:     $ tar -cf laugh.ova.tar laugh.ovf && mv laugh.ova.tar laugh.ova 3. (Optional) If you want to serve this from your devstack instance (as in the request above), run this in the folder where you created the OVA file:     $ python -m SimpleHTTPServer 9090 ----------------------------------------- Performance impact ----------------------------------------- Profiling my VM from a fresh boot: $ vboxmanage metrics query [VM NAME] Guest/RAM/Usage/Free,Guest/Pagefile/Usage/Total,Guest/CPU/Load/User:avg Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 13.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 2456680 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB After submitting this task twice (repeating calls to the above command): Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1989684 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 88.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1694080 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 83.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1426876 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 79.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 1181248 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 85.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 817244 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 84.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 548636 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB Object Metric Values ---------- -------------------- -------------------------------------------- devstack_devstack_1473967678756_60616 Guest/CPU/Load/User:avg 74.00% devstack_devstack_1473967678756_60616 Guest/RAM/Usage/Free 118932 kB devstack_devstack_1473967678756_60616 Guest/Pagefile/Usage/Total 0 kB After submitting enough of these requests at once, glance-api runs out of memory and can't restart itself. Here's what the log looks like after the "killer request" [4] ----------------------------------------- Mitigation ----------------------------------------- Any instances of xml.etree should be replaced with their equivalent in a secure XML parsing library like defusedxml [5] 1: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L21-L24 2: https://github.com/openstack/glance/blob/master/glance/async/flows/ovf_process.py#L184 3: https://docs.python.org/2/library/xml.html#xml-vulnerabilities 4: https://gist.github.com/cneill/5265d887e0125c0e20254282a6d8ae64 5: https://pypi.python.org/pypi/defusedxml ----------------------------------------- Other ----------------------------------------- Thanks to Rahul Nair from the OpenStack Security Project for bringing the ovf_process file to my attention in the first place. We are testing Glance for security defects as part of OSIC, using our API security testing tool called Syntribos (https://github.com/openstack/syntribos), and Bandit (which was used to discover this issue). To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1625402/+subscriptions From 1597557 at bugs.launchpad.net Thu Nov 24 05:59:08 2016 From: 1597557 at bugs.launchpad.net (anusha) Date: Thu, 24 Nov 2016 05:59:08 -0000 Subject: [Openstack-security] [Bug 1597557] Re: getting CSRF token missing or incorrect. /api/nova/servers/ when CSRF_COOKIE_HTTPONLY=True References: <20160630003449.23279.98663.malonedeb@gac.canonical.com> Message-ID: <20161124055910.5067.11123.launchpad@chaenomeles.canonical.com> ** Changed in: horizon Assignee: (unassigned) => anusha (anusha) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1597557 Title: getting CSRF token missing or incorrect. /api/nova/servers/ when CSRF_COOKIE_HTTPONLY=True Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Using stable/mitkaka if I set CSRF_COOKIE_HTTPONLY=True in local_settings.py, when i try to launch an instance i get Forbidden (CSRF token missing or incorrect.): /api/nova/servers/ If i set it to false (or don't set it) then it works fine. This is what does not work # If Horizon is being served through SSL, then uncomment the following two # settings to better secure the cookies from security exploits CSRF_COOKIE_SECURE = True SESSION_COOKIE_SECURE = True # prevent certain client-side attacks, such as cross-site scripting CSRF_COOKIE_HTTPONLY = True SESSION_COOKIE_HTTPONLY = True this is what does work # If Horizon is being served through SSL, then uncomment the following two # settings to better secure the cookies from security exploits CSRF_COOKIE_SECURE = True SESSION_COOKIE_SECURE = True # prevent certain client-side attacks, such as cross-site scripting CSRF_COOKIE_HTTPONLY = False SESSION_COOKIE_HTTPONLY = True To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1597557/+subscriptions From fungi at yuggoth.org Mon Nov 28 16:55:54 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 28 Nov 2016 16:55:54 -0000 Subject: [Openstack-security] [Bug 1575913] Re: Generate and download keypair GET endpoint allows CSRF attacks References: <20160427202224.17621.97555.malonedeb@soybean.canonical.com> Message-ID: <20161128165555.28092.51142.launchpad@soybean.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. - Requests to create (and download) nova keypairs are made as GETs. As such the CSRF token is not sent nor validated on these requests. This breaks the principle Django's CSRF middleware relies upon which is that requests with side effects should not cause side effects. I'm told there was a reason for doing this related to being able to send the data back to the browser, and that this may not be trivial to fix. Filing this as a security bug since a malicious site could fool a user into creating keypairs. The attacker would not gain access to the contents, so the impact is not as serious as it might seem at first glance. See https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 ** 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/1575913 Title: Generate and download keypair GET endpoint allows CSRF attacks Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Bug description: Requests to create (and download) nova keypairs are made as GETs. As such the CSRF token is not sent nor validated on these requests. This breaks the principle Django's CSRF middleware relies upon which is that requests with side effects should not cause side effects. I'm told there was a reason for doing this related to being able to send the data back to the browser, and that this may not be trivial to fix. Filing this as a security bug since a malicious site could fool a user into creating keypairs. The attacker would not gain access to the contents, so the impact is not as serious as it might seem at first glance. See https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575913/+subscriptions From 1575913 at bugs.launchpad.net Tue Nov 29 12:41:29 2016 From: 1575913 at bugs.launchpad.net (Robert Clark) Date: Tue, 29 Nov 2016 12:41:29 -0000 Subject: [Openstack-security] [Bug 1575913] Re: Generate and download keypair GET endpoint allows CSRF attacks References: <20160427202224.17621.97555.malonedeb@soybean.canonical.com> <20161128165555.28092.51142.launchpad@soybean.canonical.com> Message-ID: Im put of the office so attempting to reply by email on phone. A concern is that in the attack described, new keypairs could be created that would later used in a social engineering attack. Naming keys certain ways might encourage their use in future or as part of a more complex attack scenario. On 28 Nov 2016 17:15, "Jeremy Stanley" wrote: > ** 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. > - > Requests to create (and download) nova keypairs are made as GETs. As > such the CSRF token is not sent nor validated on these requests. This > breaks the principle Django's CSRF middleware relies upon which is that > requests with side effects should not cause side effects. I'm told there > was a reason for doing this related to being able to send the data back > to the browser, and that this may not be trivial to fix. > > Filing this as a security bug since a malicious site could fool a user > into creating keypairs. The attacker would not gain access to the > contents, so the impact is not as serious as it might seem at first > glance. > > See > https://github.com/openstack/horizon/blob/master/openstack_ > dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 > > ** 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 OSSG > CoreSec, which is subscribed to the bug report. > https://bugs.launchpad.net/bugs/1575913 > > Title: > Generate and download keypair GET endpoint allows CSRF attacks > > Status in OpenStack Dashboard (Horizon): > New > Status in OpenStack Security Advisory: > Won't Fix > > Bug description: > Requests to create (and download) nova keypairs are made as GETs. As > such the CSRF token is not sent nor validated on these requests. This > breaks the principle Django's CSRF middleware relies upon which is > that requests with side effects should not cause side effects. I'm > told there was a reason for doing this related to being able to send > the data back to the browser, and that this may not be trivial to fix. > > Filing this as a security bug since a malicious site could fool a user > into creating keypairs. The attacker would not gain access to the > contents, so the impact is not as serious as it might seem at first > glance. > > See > https://github.com/openstack/horizon/blob/master/openstack_ > dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/horizon/+bug/1575913/+subscriptions > -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1575913 Title: Generate and download keypair GET endpoint allows CSRF attacks Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Bug description: Requests to create (and download) nova keypairs are made as GETs. As such the CSRF token is not sent nor validated on these requests. This breaks the principle Django's CSRF middleware relies upon which is that requests with side effects should not cause side effects. I'm told there was a reason for doing this related to being able to send the data back to the browser, and that this may not be trivial to fix. Filing this as a security bug since a malicious site could fool a user into creating keypairs. The attacker would not gain access to the contents, so the impact is not as serious as it might seem at first glance. See https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575913/+subscriptions From fungi at yuggoth.org Tue Nov 29 15:57:35 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 29 Nov 2016 15:57:35 -0000 Subject: [Openstack-security] [Bug 1575913] Re: Generate and download keypair GET endpoint allows CSRF attacks References: <20160427202224.17621.97555.malonedeb@soybean.canonical.com> Message-ID: <20161129155735.28185.69543.malone@soybean.canonical.com> Agreed, this is certainly worth fixing, and maybe even worth backporting. I'm just questioning whether its severity is sufficient to warrant wider communication given that exploiting it would rely on social engineering or some other vulnerability allowing you to obtain a user's keys or compel them to take some action through the UI/API (in which case there are probably far easier ways to achieve the desired outcome from your victim anyway). The line between a hardening opportunity (D) and an impractical vulnerability (C1) is often pretty fuzzy. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1575913 Title: Generate and download keypair GET endpoint allows CSRF attacks Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Bug description: Requests to create (and download) nova keypairs are made as GETs. As such the CSRF token is not sent nor validated on these requests. This breaks the principle Django's CSRF middleware relies upon which is that requests with side effects should not cause side effects. I'm told there was a reason for doing this related to being able to send the data back to the browser, and that this may not be trivial to fix. Filing this as a security bug since a malicious site could fool a user into creating keypairs. The attacker would not gain access to the contents, so the impact is not as serious as it might seem at first glance. See https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575913/+subscriptions From 1268751 at bugs.launchpad.net Tue Nov 29 17:15:43 2016 From: 1268751 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 29 Nov 2016 17:15:43 -0000 Subject: [Openstack-security] [Bug 1268751] Related fix merged to keystone (master) References: <20140113215431.25014.35474.malonedeb@chaenomeles.canonical.com> Message-ID: <20161129171543.29508.73788.malone@gac.canonical.com> Reviewed: https://review.openstack.org/399728 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=df721d05bfa4c69f8540d6051912d2430ed06213 Submitter: Jenkins Branch: master commit df721d05bfa4c69f8540d6051912d2430ed06213 Author: “Richard Date: Fri Nov 18 18:25:07 2016 +0000 Don't invalidate all user tokens of roleless group As discussed in [1], deleting a group invalidates all user tokens which can flood the revocation event table if the deleted group contained thousands of users in the group. This happens regardless of whether the group had any role assignment or not. This patch makes it so that only groups that had role assignments to a project or domain can then invalidate user tokens, otherwise there is no need to revoke each user token because the group was not assigned any form of authorization to begin with. [1]: https://bugs.launchpad.net/keystone/+bug/1268751 Related-Bug: #1268751 Change-Id: I22ad364cb4737df3ed086f78310f75f3099ab4c1 -- 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): Won't Fix 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 tmcpeak at us.ibm.com Tue Nov 29 19:22:45 2016 From: tmcpeak at us.ibm.com (Travis McPeak) Date: Tue, 29 Nov 2016 19:22:45 -0000 Subject: [Openstack-security] [Bug 1575913] Re: Generate and download keypair GET endpoint allows CSRF attacks References: <20160427202224.17621.97555.malonedeb@soybean.canonical.com> <20161128165555.28092.51142.launchpad@soybean.canonical.com> Message-ID: But still, the attacker wouldn't be able to access the key. So the attacker could possible trick the victim to add a key they didn't mean to, but the attacker doesn't have the corresponding key if I understand correctly. > On Nov 29, 2016, at 6:54 AM, Robert Clark <1575913 at bugs.launchpad.net> wrote: > > Im put of the office so attempting to reply by email on phone. > > A concern is that in the attack described, new keypairs could be created > that would later used in a social engineering attack. Naming keys certain > ways might encourage their use in future or as part of a more complex > attack scenario. > >> On 28 Nov 2016 17:15, "Jeremy Stanley" wrote: >> >> ** 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. >> - >> Requests to create (and download) nova keypairs are made as GETs. As >> such the CSRF token is not sent nor validated on these requests. This >> breaks the principle Django's CSRF middleware relies upon which is that >> requests with side effects should not cause side effects. I'm told there >> was a reason for doing this related to being able to send the data back >> to the browser, and that this may not be trivial to fix. >> >> Filing this as a security bug since a malicious site could fool a user >> into creating keypairs. The attacker would not gain access to the >> contents, so the impact is not as serious as it might seem at first >> glance. >> >> See >> https://github.com/openstack/horizon/blob/master/openstack_ >> dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 >> >> ** 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 OSSG >> CoreSec, which is subscribed to the bug report. >> https://bugs.launchpad.net/bugs/1575913 >> >> Title: >> Generate and download keypair GET endpoint allows CSRF attacks >> >> Status in OpenStack Dashboard (Horizon): >> New >> Status in OpenStack Security Advisory: >> Won't Fix >> >> Bug description: >> Requests to create (and download) nova keypairs are made as GETs. As >> such the CSRF token is not sent nor validated on these requests. This >> breaks the principle Django's CSRF middleware relies upon which is >> that requests with side effects should not cause side effects. I'm >> told there was a reason for doing this related to being able to send >> the data back to the browser, and that this may not be trivial to fix. >> >> Filing this as a security bug since a malicious site could fool a user >> into creating keypairs. The attacker would not gain access to the >> contents, so the impact is not as serious as it might seem at first >> glance. >> >> See >> https://github.com/openstack/horizon/blob/master/openstack_ >> dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 >> >> To manage notifications about this bug go to: >> https://bugs.launchpad.net/horizon/+bug/1575913/+subscriptions >> > > -- > You received this bug notification because you are a member of OSSG > CoreSec, which is subscribed to the bug report. > https://bugs.launchpad.net/bugs/1575913 > > Title: > Generate and download keypair GET endpoint allows CSRF attacks > > Status in OpenStack Dashboard (Horizon): > New > Status in OpenStack Security Advisory: > Won't Fix > > Bug description: > Requests to create (and download) nova keypairs are made as GETs. As > such the CSRF token is not sent nor validated on these requests. This > breaks the principle Django's CSRF middleware relies upon which is > that requests with side effects should not cause side effects. I'm > told there was a reason for doing this related to being able to send > the data back to the browser, and that this may not be trivial to fix. > > Filing this as a security bug since a malicious site could fool a user > into creating keypairs. The attacker would not gain access to the > contents, so the impact is not as serious as it might seem at first > glance. > > See > https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/horizon/+bug/1575913/+subscriptions > -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1575913 Title: Generate and download keypair GET endpoint allows CSRF attacks Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Bug description: Requests to create (and download) nova keypairs are made as GETs. As such the CSRF token is not sent nor validated on these requests. This breaks the principle Django's CSRF middleware relies upon which is that requests with side effects should not cause side effects. I'm told there was a reason for doing this related to being able to send the data back to the browser, and that this may not be trivial to fix. Filing this as a security bug since a malicious site could fool a user into creating keypairs. The attacker would not gain access to the contents, so the impact is not as serious as it might seem at first glance. See https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/access_and_security/keypairs/views.py#L112 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575913/+subscriptions From info at bjoern-stuebe.de Wed Nov 30 09:02:40 2016 From: info at bjoern-stuebe.de (=?UTF-8?B?QmrDtnJuIFN0w7xiZQ==?=) Date: Wed, 30 Nov 2016 10:02:40 +0100 Subject: [Openstack-security] Security Audit Message-ID: <039fa61e-6b5b-1052-33c7-4ad24d0df6b7@bjoern-stuebe.de> Hey Community, I'm implementing an OpenStack environment for study purposes. My goal is to make an security audit on the environment for the ISO/IEC 27001 certificate. Do you have hints as I could started? Do you have tipps which I should pay attention to? Best regards, Björn From aheczko at mirantis.com Wed Nov 30 09:46:43 2016 From: aheczko at mirantis.com (Adam Heczko) Date: Wed, 30 Nov 2016 10:46:43 +0100 Subject: [Openstack-security] Security Audit In-Reply-To: References: <039fa61e-6b5b-1052-33c7-4ad24d0df6b7@bjoern-stuebe.de> Message-ID: Hey Bjorn, pls start with reading OpenStack Security Guide. Cloud Security Alliance Cloud Control Matrix may also be useful for you. Apologies for misspelling your name, I'm sending from mobile. Adam On 30 Nov 2016 10:05, "Björn Stübe" wrote: Hey Community, I'm implementing an OpenStack environment for study purposes. My goal is to make an security audit on the environment for the ISO/IEC 27001 certificate. Do you have hints as I could started? Do you have tipps which I should pay attention to? Best regards, Björn _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhinds at redhat.com Wed Nov 30 12:00:31 2016 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 30 Nov 2016 12:00:31 +0000 Subject: [Openstack-security] Security Audit In-Reply-To: <039fa61e-6b5b-1052-33c7-4ad24d0df6b7@bjoern-stuebe.de> References: <039fa61e-6b5b-1052-33c7-4ad24d0df6b7@bjoern-stuebe.de> Message-ID: On Wed, Nov 30, 2016 at 9:02 AM, Björn Stübe wrote: > Hey Community, > > I'm implementing an OpenStack environment for study purposes. My goal is > to make an security audit on the environment for the ISO/IEC 27001 > certificate. Do you have hints as I could started? Do you have tipps > which I should pay attention to? > > Best regards, > Björn > I would recommend coming onto the security project IRC meeting tomorrow, as there is an ongoing program in place for Threat Analysis and would be very useful to align efforts with you. We meet on IRC every Thursday @ 17:00 UTC on freenode, channel #openstack-meeting-alt This is where we are maintaining threat analysis: https://review.openstack.org/#/q/project:openstack/security-analysis You can see a current review underway here: https://review.openstack.org/#/c/356025/ -------------- next part -------------- An HTML attachment was scrubbed... URL: