From 1501808 at bugs.launchpad.net Tue Aug 1 09:52:45 2017 From: 1501808 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 01 Aug 2017 09:52:45 -0000 Subject: [Openstack-security] [Bug 1501808] Change abandoned on nova (master) References: <20151001152652.22834.78736.malonedeb@gac.canonical.com> Message-ID: <150158116525.13879.2986531056889363421.malone@soybean.canonical.com> Change abandoned by Sean Dague (sean at dague.net) on branch: master Review: https://review.openstack.org/386756 Reason: This review is > 4 weeks without comment, and is not mergable in it's current state. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1501808 Title: Enabling soft-deletes opens a DOS on compute hosts Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: If the user sets reclaim_instance_interval to anything other than 0, then when a user requests an instance delete, it will instead be soft deleted. Soft delete explicitly releases the user's quota, but does not release the instance's resources until period task _reclaim_queued_deletes runs with a period of reclaim_instance_interval seconds. A malicious authenticated user can repeatedly create and delete instances without limit, which will consume resources on the host without consuming their quota. If done quickly enough, this will exhaust host resources. I'm not entirely sure what to suggest in remediation, as this seems to be a deliberate design. The most obvious fix would be to not release quota until the instance is reaped, but that would be a significant change in behaviour. This is very similar to https://bugs.launchpad.net/bugs/cve/2015-3280 , except that we do it deliberately. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1501808/+subscriptions From 1419577 at bugs.launchpad.net Tue Aug 1 10:03:00 2017 From: 1419577 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 01 Aug 2017 10:03:00 -0000 Subject: [Openstack-security] [Bug 1419577] Change abandoned on nova (master) References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <150158178087.3652.2580348896219902435.malone@gac.canonical.com> Change abandoned by Sean Dague (sean at dague.net) on branch: master Review: https://review.openstack.org/338929 Reason: This review is > 4 weeks without comment, and is not mergable in it's current state. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results. -- You received this bug notification because you are a member of OpenStack Security, 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 1708122 at bugs.launchpad.net Thu Aug 3 04:01:03 2017 From: 1708122 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 03 Aug 2017 04:01:03 -0000 Subject: [Openstack-security] [Bug 1708122] Re: Don't return back the sensitive information to user References: <150166534782.4172.13585998432019727052.malonedeb@gac.canonical.com> Message-ID: <150173286348.26072.17708916902618849712.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/490320 ** Changed in: heat 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/1708122 Title: Don't return back the sensitive information to user Status in OpenStack Heat: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: We return back the sensitive information to user when some exception happen, for example, when DBError happened, we will return the whole sql statement to user, it's not safe, also we return the traceback to user, it's not necessary. Maybe we can do the same thing like nova and cinder to add an attribute 'safe' for some exceptions to decide whether to return the information like the error message details to user. To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1708122/+subscriptions From 1708547 at bugs.launchpad.net Thu Aug 3 23:08:30 2017 From: 1708547 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 03 Aug 2017 23:08:30 -0000 Subject: [Openstack-security] [Bug 1708547] Re: Infortrend driver logs password in commands References: <150179925020.26336.11801506653229617346.malonedeb@chaenomeles.canonical.com> Message-ID: <150180171032.4022.6303002079688790601.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/490674 ** Changed in: cinder Status: New => In Progress ** Changed in: cinder Assignee: (unassigned) => Walt Boring (walter-boring) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1708547 Title: Infortrend driver logs password in commands Status in Cinder: In Progress Bug description: The Infortrend driver's cli_factory constructs a command to execute, which can include a password. When the command fails, the cli_factory logs the entire command line to the log file, leaving the password in clear text. password line https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/infortrend/raidcmd_cli/cli_factory.py#L173-L175 command logged https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/infortrend/raidcmd_cli/cli_factory.py#L221-L226 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1708547/+subscriptions From fungi at yuggoth.org Fri Aug 4 15:33:11 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 04 Aug 2017 15:33:11 -0000 Subject: [Openstack-security] [Bug 1668410] Re: Infinite loop trying to delete deleted HA router References: <20170227213540.6394.32961.malonedeb@wampee.canonical.com> Message-ID: <150186079204.21721.11896883988968338146.malone@wampee.canonical.com> Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. Given this was purported to gave been fixed in master by https://review.openstack.org/365653 prior to the Newton release and it in turn claims to be fixing bug 1607381 (which itself makes mention of an infinite loop bug 1606844 which is also questioned as a possible dupe for bug 1605546, bug 1533441, bug 1533457 and bug 1605546, some of which are still open), it's not entirely clear to me the degree to which this has been solved so some summary from neutron-coresec reviewers would be particularly appreciated. That aside, "denial of service" conditions arising from unconstrained resource consumption by authenticated users is a grey area we struggle with classifying. At some point, operators must have a means of identifying abuse by their users, locking them out and cleaning up the mess. In a "typical" production deployment servicing potentially risky users, how quickly can an abuser "fill up" your logs doing this? Will your monitoring system alert operations to the increase in activity and disk utilization in reasonable time for them to take mitigating action? Are deployments likely to include rate-limiting proxies which further throttle problem API calls such as these? In most cases, we triage such reports as security hardening opportunities (class D in our taxonomy: https://security.openstack.org /vmt-process.html#incident-report-taxonomy ) and since this report is already public there's no harm in doing that for now while entertaining further discussion on whether it should be reclassed and any potential advisory issued. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public 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/1668410 Title: Infinite loop trying to delete deleted HA router Status in neutron: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: Latest Mitaka code, L3 HA After running rally create_and_delete_routers (concurrency 100 and times 100, or more) neutron l3 agent logs on nodes filled (every .003 second timestamp) with such traces: http://paste.openstack.org/show/599851/ which causes cluster fall when log partition will filled up. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1668410/+subscriptions From 1668410 at bugs.launchpad.net Fri Aug 4 15:55:13 2017 From: 1668410 at bugs.launchpad.net (Denis Gubanov) Date: Fri, 04 Aug 2017 15:55:13 -0000 Subject: [Openstack-security] [Bug 1668410] Re: Infinite loop trying to delete deleted HA router References: <20170227213540.6394.32961.malonedeb@wampee.canonical.com> Message-ID: <150186211385.21611.1495862567261764469.launchpad@wampee.canonical.com> ** Also affects: neutron (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668410 Title: Infinite loop trying to delete deleted HA router Status in neutron: In Progress Status in OpenStack Security Advisory: Won't Fix Status in neutron package in Ubuntu: New Bug description: Latest Mitaka code, L3 HA After running rally create_and_delete_routers (concurrency 100 and times 100, or more) neutron l3 agent logs on nodes filled (every .003 second timestamp) with such traces: http://paste.openstack.org/show/599851/ which causes cluster fall when log partition will filled up. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1668410/+subscriptions From fungi at yuggoth.org Mon Aug 7 15:21:18 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 07 Aug 2017 15:21:18 -0000 Subject: [Openstack-security] [Bug 1632537] Re: l3 agent print the ERROR log in l3 log file continuously , finally fill file space, leading to crash the l3-agent service References: <20161012023819.5296.65303.malonedeb@chaenomeles.canonical.com> Message-ID: <150211927817.10750.234044058615558989.malone@wampee.canonical.com> "Denial of service" conditions arising from unconstrained resource consumption by authenticated users is a grey area we struggle with classifying (and we don't even have confirmation yet that it _can_ be triggered intentionally by mere users of the environment). At some point, operators must have a means of identifying abuse by their users, locking them out and cleaning up the mess. In a "typical" production deployment servicing potentially risky users, how quickly can an abuser "fill up" your logs doing this? Will your monitoring system alert operations to the increase in activity and disk utilization in reasonable time for them to take mitigating action? Are deployments likely to include rate-limiting proxies which further throttle problem API calls such as these? In most cases, we triage such reports as security hardening opportunities (class D in our taxonomy: https://security.openstack.org /vmt-process.html#incident-report-taxonomy ) and since this report is already public there's no harm in doing that for now while entertaining further discussion on whether it should be reclassed and any potential advisory issued. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public 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/1632537 Title: l3 agent print the ERROR log in l3 log file continuously ,finally fill file space,leading to crash the l3-agent service Status in neutron: New Status in OpenStack Security Advisory: Won't Fix Bug description: 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent [req-5d499217-05b6-4a56-a3b7-5681adb53d6c - d2b95803757641b6bc55f6309c12c6e9 - - -] Failed to process compatible router 'da82aeb4-07a4-45ca-ae7a-570aec69df29' 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent Traceback (most recent call last): 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 501, in _process_router_update 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent self._process_router_if_compatible(router) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 438, in _process_router_if_compatible 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent self._process_added_router(router) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 446, in _process_added_router 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent ri.process(self) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/dvr_local_router.py", line 488, in process 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent super(DvrLocalRouter, self).process(agent) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/dvr_router_base.py", line 30, in process 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent super(DvrRouterBase, self).process(agent) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/ha_router.py", line 386, in process 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent super(HaRouter, self).process(agent) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 385, in call 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent self.logger(e) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent self.force_reraise() 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent six.reraise(self.type_, self.value, self.tb) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 382, in call 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent return func(*args, **kwargs) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py", line 964, in process 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent self.process_address_scope() 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/l3/dvr_edge_router.py", line 239, in process_address_scope 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent self.snat_iptables_manager, ports_scopemark) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib64/python2.7/contextlib.py", line 24, in __exit__ 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent self.gen.next() 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/site-packages/neutron/agent/linux/iptables_manager.py", line 461, in defer_apply 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent raise n_exc.IpTablesApplyException(msg) 2016-10-12 10:04:38.587 25667 ERROR neutron.agent.l3.agent IpTablesApplyException: Failure applying iptables rules this ERROR information will fill l3-agent log file continuously until solving the problem ,it will fill the file space. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1632537/+subscriptions From 1708547 at bugs.launchpad.net Tue Aug 8 21:07:30 2017 From: 1708547 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 08 Aug 2017 21:07:30 -0000 Subject: [Openstack-security] [Bug 1708547] Re: Infortrend driver logs password in commands References: <150179925020.26336.11801506653229617346.malonedeb@chaenomeles.canonical.com> Message-ID: <150222645077.8620.9138239233991143260.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/490674 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=af0b0082de8556e6923634986567b42c94fc31b3 Submitter: Jenkins Branch: master commit af0b0082de8556e6923634986567b42c94fc31b3 Author: Walter A. Boring IV Date: Thu Aug 3 23:05:34 2017 +0000 Infortrend mask password logging This patch fixes a problem when a cli command is executed and fails, the driver logs the entire command including the password in clear text. This patch makes sure that the password is masked out. Change-Id: I4984b994bde4c5aa3a8914f06f5cfc8205f0f4d8 Closes-Bug: 1708547 ** Changed in: cinder 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/1708547 Title: Infortrend driver logs password in commands Status in Cinder: Fix Released Bug description: The Infortrend driver's cli_factory constructs a command to execute, which can include a password. When the command fails, the cli_factory logs the entire command line to the log file, leaving the password in clear text. password line https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/infortrend/raidcmd_cli/cli_factory.py#L173-L175 command logged https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/infortrend/raidcmd_cli/cli_factory.py#L221-L226 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1708547/+subscriptions From morgan.fainberg at gmail.com Wed Aug 9 22:08:57 2017 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 09 Aug 2017 22:08:57 -0000 Subject: [Openstack-security] [Bug 1621626] Re: Unauthenticated requests return information References: <20160908210003.13656.43704.malonedeb@wampee.canonical.com> Message-ID: <150231653850.11238.453907366742888660.malone@wampee.canonical.com> Mitaka is EOL ** Changed in: keystone/mitaka Status: New => Won't Fix ** Changed in: keystone/mitaka Status: Won't Fix => Fix Released ** Changed in: keystone/mitaka Status: Fix Released => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1621626 Title: Unauthenticated requests return information Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: I can get information back on an unauthenticated request. $ curl http://192.168.122.126:35357/v3/projects/8d34a533f85b423e8589061cde451edd/users/68ec7d9b6e464649b11d1340d5e05666/roles/ca314e7f7faf4f948bf6e7cf2077806e {"error": {"message": "Could not find role: ca314e7f7faf4f948bf6e7cf2077806e", "code": 404, "title": "Not Found"}} This should have returned 401 Unauthenticated, like this: $ curl http://192.168.122.126:35357/v3/projects {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}} To recreate, just start up devstack on stable/mitaka and do the above request. I tried this on master and it's fixed. Probably by https://review.openstack.org/#/c/339356/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1621626/+subscriptions From morgan.fainberg at gmail.com Thu Aug 10 19:28:10 2017 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Thu, 10 Aug 2017 19:28:10 -0000 Subject: [Openstack-security] [Bug 1534288] Re: keystoneclient should not be using pickle References: <20160114195928.28540.47395.malonedeb@gac.canonical.com> Message-ID: <150239329098.17031.9256930050963968309.malone@gac.canonical.com> Marked as wont fix based on comment #10 and #9 ** Changed in: python-keystoneclient Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534288 Title: keystoneclient should not be using pickle Status in OpenStack Security Advisory: Won't Fix Status in python-keystoneclient: Won't Fix Bug description: keystoneclient uses pickle to pull the keystoneclient_auth value out of the keyring. pickle is not safe to use since it can run commands as the user. I guess someone could use this to run some code as the nova user by putting something into the keystoneclient_auth value in the nova user's keyring and then getting nova to use keystoneclient.httpclient. There's probably a safer way to do serialize the auth info using JSON or some other format. Opening this as private security since there's a potential attack here although I don't have any proof. This was found using bandit 0.17.0. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1534288/+subscriptions From 1708547 at bugs.launchpad.net Fri Aug 11 02:51:50 2017 From: 1708547 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 11 Aug 2017 02:51:50 -0000 Subject: [Openstack-security] [Bug 1708547] Fix included in openstack/cinder 11.0.0.0rc1 References: <150179925020.26336.11801506653229617346.malonedeb@chaenomeles.canonical.com> Message-ID: <150241991054.11024.1517236306437827530.malone@wampee.canonical.com> This issue was fixed in the openstack/cinder 11.0.0.0rc1 release candidate. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1708547 Title: Infortrend driver logs password in commands Status in Cinder: Fix Released Bug description: The Infortrend driver's cli_factory constructs a command to execute, which can include a password. When the command fails, the cli_factory logs the entire command line to the log file, leaving the password in clear text. password line https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/infortrend/raidcmd_cli/cli_factory.py#L173-L175 command logged https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/infortrend/raidcmd_cli/cli_factory.py#L221-L226 To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1708547/+subscriptions From 1708122 at bugs.launchpad.net Sat Aug 12 03:17:40 2017 From: 1708122 at bugs.launchpad.net (Rabi Mishra) Date: Sat, 12 Aug 2017 03:17:40 -0000 Subject: [Openstack-security] [Bug 1708122] Re: Don't return back the sensitive information to user References: <150166534782.4172.13585998432019727052.malonedeb@gac.canonical.com> Message-ID: <150250786169.19716.17548387114906389592.launchpad@chaenomeles.canonical.com> ** Changed in: heat Milestone: pike-rc1 => pike-rc2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1708122 Title: Don't return back the sensitive information to user Status in OpenStack Heat: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: We return back the sensitive information to user when some exception happen, for example, when DBError happened, we will return the whole sql statement to user, it's not safe, also we return the traceback to user, it's not necessary. Maybe we can do the same thing like nova and cinder to add an attribute 'safe' for some exceptions to decide whether to return the information like the error message details to user. To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1708122/+subscriptions From 1188189 at bugs.launchpad.net Sun Aug 13 08:22:40 2017 From: 1188189 at bugs.launchpad.net (Chris Suttles) Date: Sun, 13 Aug 2017 08:22:40 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <150261256016.8395.3352517829186257620.malone@soybean.canonical.com> I'm sorry to bail on this after grabbing it @d-gollub. I spent some time on this, but got stuck on updating tests. I reached out in a couple related tickets but got no replies. I'd hand this back but I don't have permission to do so. ** Changed in: cinder Assignee: Chris Suttles (killface007) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: Triaged Status in OpenStack Identity (keystone): Fix Released Status in neutron: Fix Released Status in oslo.vmware: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Status in python-keystoneclient: Fix Released Status in OpenStack Object Storage (swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From tdecacqu at redhat.com Tue Aug 15 03:01:05 2017 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Tue, 15 Aug 2017 03:01:05 -0000 Subject: [Openstack-security] [Bug 1708122] Re: Don't return back the sensitive information to user References: <150166534782.4172.13585998432019727052.malonedeb@gac.canonical.com> Message-ID: <150276606583.8514.7822800730720949836.malone@soybean.canonical.com> Switching the OSSA task to Won't Fix since this looks like a class D (harderning) at most. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1708122 Title: Don't return back the sensitive information to user Status in OpenStack Heat: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: We return back the sensitive information to user when some exception happen, for example, when DBError happened, we will return the whole sql statement to user, it's not safe, also we return the traceback to user, it's not necessary. Maybe we can do the same thing like nova and cinder to add an attribute 'safe' for some exceptions to decide whether to return the information like the error message details to user. To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1708122/+subscriptions From tdecacqu at redhat.com Tue Aug 15 04:03:05 2017 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Tue, 15 Aug 2017 04:03:05 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <150276978568.19430.882956258838100609.malone@chaenomeles.canonical.com> Adding OSSN task based on comment #3 ** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From lhinds at redhat.com Tue Aug 15 06:57:36 2017 From: lhinds at redhat.com (Luke Hinds) Date: Tue, 15 Aug 2017 06:57:36 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <150278025702.19543.7600188616995519674.malone@chaenomeles.canonical.com> Couple of Q's... For the OSSN what would the 'recommended actions' be to update to Pike? Is it a seamless crossover going from sha512_crypt to bcrypt, scrypt, or pbkdf2_sha512, or would passwords need to be regenerated (thinking in this instance of an operator upgrading from a previous release to Pike) ? ** Changed in: ossn Assignee: (unassigned) => Luke Hinds (lhinds) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From 1674954 at bugs.launchpad.net Tue Aug 15 09:33:02 2017 From: 1674954 at bugs.launchpad.net (Amrith Kumar) Date: Tue, 15 Aug 2017 09:33:02 -0000 Subject: [Openstack-security] [Bug 1674954] Re: trove log-enable causes unnecessary file permission change References: <20170322104835.30899.5431.malonedeb@wampee.canonical.com> Message-ID: <150278958497.8211.12696535808987208367.launchpad@soybean.canonical.com> ** Changed in: trove Status: New => Opinion ** Changed in: trove Status: Opinion => Invalid ** Changed in: trove Importance: Low => Undecided -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1674954 Title: trove log-enable causes unnecessary file permission change Status in OpenStack Security Advisory: Won't Fix Status in OpenStack DBaaS (Trove): Invalid Bug description: When log-enable called, Guestagent try to change log directory permission to readable. Unfortunately, it changes permission in recursively like below. This is security issue that allow any of OS users to read the database data files. I believe that we should fix this line. https://github.com/openstack/trove/blob/master/trove/guestagent/guest_log.py#L115 [samitani at samitani-mi02-member-2 ~]$ sudo grep 'Running cmd' /var/log/trove/guestagent.log 2017-03-22 19:21:47.070 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf /tmp/tmpoJ2r5O execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.078 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmpoJ2r5O execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.117 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/.+-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.136 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-001-cluster.cnf /tmp/tmp0AhUIT execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.142 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp0AhUIT execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.153 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.177 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.183 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.190 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.196 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.202 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.209 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.216 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-general.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.222 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.228 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/log/mysqld.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.235 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:21:47.241 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +664 /var/lib/mysql/data/pxc-slow_query.log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.743 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/lib/mysql/data execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.760 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/lib/mysql/data execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.769 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/log/trove execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.777 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +055 /var/log execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.846 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/50-system-([0-9]+)-disable_general_log\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.853 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf /tmp/tmpNUmZt6 execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.860 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmpNUmZt6 execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.883 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/.+-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.890 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-001-cluster.cnf /tmp/tmp7MujEH execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.897 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp7MujEH execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.905 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/50-system-([0-9]+)-enable_general_log\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.912 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/50-system-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.920 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /tmp/tmpTVRVmR /etc/my.cnf.d/50-system-002-enable_general_log.cnf execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.926 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chown -R mysql:mysql /etc/my.cnf.d/50-system-002-enable_general_log.cnf execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.932 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /etc/my.cnf.d/50-system-002-enable_general_log.cnf execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.939 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf /tmp/tmpCzeJfw execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.945 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmpCzeJfw execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.988 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): find /etc/my.cnf.d/ -noleaf -type f -regextype posix-extended -regex .*/.+-([0-9]+)-.+\.cnf$$ execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:08.995 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-001-cluster.cnf /tmp/tmp7O4zdM execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:09.002 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp7O4zdM execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:09.010 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): cp -f -R /etc/my.cnf.d/50-system-002-enable_general_log.cnf /tmp/tmp_Kw0Ju execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:09.016 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): chmod -R +444 /tmp/tmp_Kw0Ju execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 2017-03-22 19:22:47.599 24586 DEBUG oslo_concurrency.processutils [-] Running cmd (subprocess): /usr/bin/mysqladmin ping execute /opt/trove/lib/python2.7/site-packages/oslo_concurrency/processutils.py:326 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1674954/+subscriptions From 1657139 at bugs.launchpad.net Tue Aug 15 09:45:09 2017 From: 1657139 at bugs.launchpad.net (Amrith Kumar) Date: Tue, 15 Aug 2017 09:45:09 -0000 Subject: [Openstack-security] [Bug 1657139] Re: XML Injection References: <20170117144110.27439.8124.malonedeb@chaenomeles.canonical.com> Message-ID: <150279031077.8395.3584726370296192188.launchpad@soybean.canonical.com> ** Changed in: trove Importance: Undecided => Wishlist -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1657139 Title: XML Injection Status in OpenStack Security Advisory: Won't Fix Status in OpenStack DBaaS (Trove): New Bug description: The xml.dom.minidom module is not secure against maliciously constructed data. If you need to parse untrusted or unauthenticated data see XML vulnerabilities. Trove code base is using xml.dom.minidom. Writing unvalidated data into an XML document can allow an attacker to change the structure and contents of the XML. https://github.com/openstack/trove/blob/129fac7d5374e18a428afa1b5c0259743677222e/trove/common/base_wsgi.py#L509 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1657139/+subscriptions From morgan.fainberg at gmail.com Tue Aug 15 14:48:07 2017 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Tue, 15 Aug 2017 14:48:07 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> <150278025702.19543.7600188616995519674.malone@chaenomeles.canonical.com> Message-ID: All new/updated/changes passwords (after upgrade) would be bcrypt hashed, old passwords remain sha512_crypt. An operator may want to force password changes. On Aug 15, 2017 00:11, "Luke Hinds" wrote: > Couple of Q's... > > For the OSSN what would the 'recommended actions' be to update to Pike? > > Is it a seamless crossover going from sha512_crypt to bcrypt, scrypt, or > pbkdf2_sha512, or would passwords need to be regenerated (thinking in > this instance of an operator upgrading from a previous release to Pike) > ? > > ** Changed in: ossn > Assignee: (unassigned) => Luke Hinds (lhinds) > > -- > You received this bug notification because you are subscribed to the bug > report. > Matching subscriptions: Private security bugs > https://bugs.launchpad.net/bugs/1668503 > > Title: > sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing > > Status in OpenStack Identity (keystone): > Fix Released > Status in OpenStack Identity (keystone) mitaka series: > Won't Fix > Status in OpenStack Identity (keystone) newton series: > Won't Fix > Status in OpenStack Identity (keystone) ocata series: > Won't Fix > Status in OpenStack Identity (keystone) pike series: > Fix Released > Status in OpenStack Security Advisory: > Won't Fix > Status in OpenStack Security Notes: > New > > Bug description: > Keystone uses sha512_crypt for password hashing. This is insufficient > and provides limited protection (even with 10,000 rounds) against > brute-forcing of the password hashes (especially with FPGAs and/or GPU > processing). > > The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 > instead of sha512_crypt. > > This bug is marked as public security as bug #1543048 has already > highlighted this issue. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions > -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From morgan.fainberg at gmail.com Tue Aug 15 14:48:41 2017 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Tue, 15 Aug 2017 14:48:41 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> <150278025702.19543.7600188616995519674.malone@chaenomeles.canonical.com> Message-ID: ** or to whichever hash is configured if not default. On Aug 15, 2017 07:48, "Morgan Fainberg" wrote: > All new/updated/changes passwords (after upgrade) would be bcrypt hashed, > old passwords remain sha512_crypt. An operator may want to force password > changes. > > On Aug 15, 2017 00:11, "Luke Hinds" wrote: > >> Couple of Q's... >> >> For the OSSN what would the 'recommended actions' be to update to Pike? >> >> Is it a seamless crossover going from sha512_crypt to bcrypt, scrypt, or >> pbkdf2_sha512, or would passwords need to be regenerated (thinking in >> this instance of an operator upgrading from a previous release to Pike) >> ? >> >> ** Changed in: ossn >> Assignee: (unassigned) => Luke Hinds (lhinds) >> >> -- >> You received this bug notification because you are subscribed to the bug >> report. >> Matching subscriptions: Private security bugs >> https://bugs.launchpad.net/bugs/1668503 >> >> Title: >> sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing >> >> Status in OpenStack Identity (keystone): >> Fix Released >> Status in OpenStack Identity (keystone) mitaka series: >> Won't Fix >> Status in OpenStack Identity (keystone) newton series: >> Won't Fix >> Status in OpenStack Identity (keystone) ocata series: >> Won't Fix >> Status in OpenStack Identity (keystone) pike series: >> Fix Released >> Status in OpenStack Security Advisory: >> Won't Fix >> Status in OpenStack Security Notes: >> New >> >> Bug description: >> Keystone uses sha512_crypt for password hashing. This is insufficient >> and provides limited protection (even with 10,000 rounds) against >> brute-forcing of the password hashes (especially with FPGAs and/or GPU >> processing). >> >> The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 >> instead of sha512_crypt. >> >> This bug is marked as public security as bug #1543048 has already >> highlighted this issue. >> >> To manage notifications about this bug go to: >> https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions >> > -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From gerrit2 at review.openstack.org Tue Aug 15 17:21:20 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 15 Aug 2017 17:21:20 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change I121b2e7641c77a4872a1e801eb039050e6a996ea Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/488541 Log: commit a0f4638eaee90d9d1d901adfffb611ffecd28dc1 Author: Peter Hamilton Date: Fri Jul 28 13:18:30 2017 -0400 Add support for certificate validation This spec describes changes that would allow Nova to perform certificate validation when verifying Glance image signatures. While image signing ensures that image data is obtained unmodified from Glance, it does not prevent an attacker from uploading and signing a malicious image. The addition of Nova API changes allows Nova users to control the certificates which are allowed to sign images. This spec describes work related to image verification. For more information, see: https://review.openstack.org/#/c/343654 APIImpact DocImpact SecurityImpact Previously-approved: Pike Change-Id: I121b2e7641c77a4872a1e801eb039050e6a996ea From fungi at yuggoth.org Wed Aug 16 15:44:44 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 16 Aug 2017 15:44:44 -0000 Subject: [Openstack-security] [Bug 1684320] Re: Domain admin has access to service Admin API with policy.v3cloudsample.json References: <20170419233825.2559.57296.malonedeb@wampee.canonical.com> Message-ID: <150289828456.8620.15052037712174388098.malone@soybean.canonical.com> Okay, so somewhere between the aforementioned B2 ("A vulnerability without a complete fix yet...") and B1 ("A vulnerability that can only be fixed in master, security note for stable branches, e.g., default config value is insecure"). I'll go ahead and mark our advisory task "won't fix" and let the OSSN editors decide how and when they might want to write this up as a note. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public 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/1684320 Title: Domain admin has access to service Admin API with policy.v3cloudsample.json Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Won't Fix Bug description: Keystone has a sample policy file to create a concept of domains per customer, with a domain admin that manages users and tenants inside that domain. https://github.com/openstack/keystone/commits/master/etc/policy.v3cloudsample.json In this policy, the domain admin role (a user who manages that domain) would get the "admin" role assigned to them. However, with the "admin" role assigned to them, they can make requests to the admin_api (in this case, the Nova example). https://github.com/openstack/nova/blob/master/nova/policies/base.py#L18-L28 I have done a fair bit of checking but I believe that a domain admin can get full access to the admin_api (or be able to create a user with an "admin" role and get access to the entire cloud). I believe this affects all other projects and users of this policy would not be aware at the level of access given to a domain admin. Perhaps the file can be revised to use a role like "domain_admin" and Keystone would have a setting of "reserved role names" which cannot be used (e.g. block the role "admin" from being created in a domain). Please forgive me in advance if this is not a security issue and a lack of understanding (I hope it is), but I have done a fair amount of research on this so far and it seems like getting access to that `admin` role is an issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1684320/+subscriptions From 1702123 at bugs.launchpad.net Thu Aug 17 10:21:30 2017 From: 1702123 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 17 Aug 2017 10:21:30 -0000 Subject: [Openstack-security] [Bug 1702123] Re: SELinux error: keepalived reading haproxy pid file References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com> Message-ID: <150296529010.11133.9067490714699282846.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/494468 ** Changed in: openstack-ansible Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1702123 Title: SELinux error: keepalived reading haproxy pid file Status in openstack-ansible: In Progress Bug description: When keepalived tries to read the haproxy PID file, SELinux denies the access. This should be added into the haproxy role. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions From 1702123 at bugs.launchpad.net Thu Aug 17 15:11:17 2017 From: 1702123 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 17 Aug 2017 15:11:17 -0000 Subject: [Openstack-security] [Bug 1702123] Re: SELinux error: keepalived reading haproxy pid file References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com> Message-ID: <150298267782.19393.6710820374225896775.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/494468 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=2bf2d65c4dcd17219187fd12014ae87e346199b7 Submitter: Jenkins Branch: master commit 2bf2d65c4dcd17219187fd12014ae87e346199b7 Author: Jean-Philippe Evrard Date: Thu Aug 17 10:08:01 2017 +0000 Allow Keepalived to read haproxy pid file Keepalived, luckily for us, currently ship an example file of a SELinux rule to read haproxy pid. We could simply use this available file to compile the selinux rules. Change-Id: I8e6d811bca7553d82591a6c96f4316377d0d1829 Fixes-Bug: #1702123 ** 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/1702123 Title: SELinux error: keepalived reading haproxy pid file Status in openstack-ansible: Fix Released Bug description: When keepalived tries to read the haproxy PID file, SELinux denies the access. This should be added into the haproxy role. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions From 1702123 at bugs.launchpad.net Thu Aug 17 15:37:31 2017 From: 1702123 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 17 Aug 2017 15:37:31 -0000 Subject: [Openstack-security] [Bug 1702123] Fix proposed to openstack-ansible (master) References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com> Message-ID: <150298425195.19430.15864362595596954008.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/494610 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1702123 Title: SELinux error: keepalived reading haproxy pid file Status in openstack-ansible: Fix Released Bug description: When keepalived tries to read the haproxy PID file, SELinux denies the access. This should be added into the haproxy role. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions From 1702123 at bugs.launchpad.net Thu Aug 17 15:40:29 2017 From: 1702123 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 17 Aug 2017 15:40:29 -0000 Subject: [Openstack-security] [Bug 1702123] Fix proposed to openstack-ansible (stable/ocata) References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com> Message-ID: <150298442942.10854.16955382468795197343.malone@wampee.canonical.com> Fix proposed to branch: stable/ocata Review: https://review.openstack.org/494612 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1702123 Title: SELinux error: keepalived reading haproxy pid file Status in openstack-ansible: Fix Released Bug description: When keepalived tries to read the haproxy PID file, SELinux denies the access. This should be added into the haproxy role. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions From lhinds at redhat.com Thu Aug 17 16:58:17 2017 From: lhinds at redhat.com (Luke Hinds) Date: Thu, 17 Aug 2017 16:58:17 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <150298909756.18978.4418302194250880057.malone@chaenomeles.canonical.com> ack, thanks Morgan..I will start on the OSSN. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From 1702123 at bugs.launchpad.net Fri Aug 18 13:48:18 2017 From: 1702123 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 18 Aug 2017 13:48:18 -0000 Subject: [Openstack-security] [Bug 1702123] Fix proposed to openstack-ansible (stable/pike) References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com> Message-ID: <150306409865.11349.2088107592374169673.malone@wampee.canonical.com> Fix proposed to branch: stable/pike Review: https://review.openstack.org/495303 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1702123 Title: SELinux error: keepalived reading haproxy pid file Status in openstack-ansible: Fix Released Bug description: When keepalived tries to read the haproxy PID file, SELinux denies the access. This should be added into the haproxy role. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions From 1702123 at bugs.launchpad.net Mon Aug 21 13:06:06 2017 From: 1702123 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 21 Aug 2017 13:06:06 -0000 Subject: [Openstack-security] [Bug 1702123] Change abandoned on openstack-ansible (master) References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com> Message-ID: <150332076653.19611.11173582560300209961.malone@chaenomeles.canonical.com> Change abandoned by Major Hayden (major at mhtx.net) on branch: master Review: https://review.openstack.org/494610 Reason: Well nevermind! Someone bumped OSA master to use ansible-keepalived's master branch. ;) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1702123 Title: SELinux error: keepalived reading haproxy pid file Status in openstack-ansible: Fix Released Bug description: When keepalived tries to read the haproxy PID file, SELinux denies the access. This should be added into the haproxy role. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions From gerrit2 at review.openstack.org Mon Aug 21 15:57:13 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 21 Aug 2017 15:57:13 +0000 Subject: [Openstack-security] [openstack/cursive] SecurityImpact review request change I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357202 Log: commit 16a2510c5f66bf32f75fbedfebc50a0f03e77c33 Author: Peter Hamilton Date: Thu Aug 18 08:50:38 2016 -0400 Add certificate validation This change adds support for certificate validation, including certificate inspection utilities. Validating a certificate requires the certificate UUID of the certificate to validate, a set of UUIDs corresponding to the set of trusted certificates needed to validate the certificate, and a user context for authentication to the key manager. A new certificate verification context is included that is used to store the set of trusted certificates once they are loaded from the key manager. This context is used to validate the signing certificate, verifying that the certificate belongs to a valid certificate chain rooted in the set of trusted certificates. All new certificate utility code is added in a new module named certificate_utils. For more information on this work, see the spec: https://review.openstack.org/#/c/357151/ SecurityImpact DocImpact Change-Id: I8d7f43fb4c0573ac3681147eac213b369bbbcb3b From lbragstad at gmail.com Tue Aug 22 17:18:09 2017 From: lbragstad at gmail.com (Lance Bragstad) Date: Tue, 22 Aug 2017 17:18:09 -0000 Subject: [Openstack-security] [Bug 1543048] Re: support alternative password hashing in keystone References: <20160208102502.15773.89678.malonedeb@gac.canonical.com> Message-ID: <150342229105.10892.9410091183534758443.launchpad@wampee.canonical.com> ** Changed in: keystone Milestone: None => pike-3 ** Changed in: keystone Milestone: pike-3 => pike-2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1543048 Title: support alternative password hashing in keystone Status in OpenStack Identity (keystone): Fix Released Bug description: Once upon a time there was bug #862730 recommending that alternative password hashing be supported which was closed as invalid since hashing became base-line feature of Keystone's passwords. It would be generally beneficial to support at the very least the passlib implementation of bcrypt as an alternative to strictly sha512 based password hashing. Ideally this should also take into account the relatively new player scrypt. NIST has standardized (afaict) on the SHA-2 based hashing, which should remain the default. Architecture that will support some different password hashing made available at least through passlib will make keystone better in the long term, allowing for operators to determine more than just the SHA-2 based cost. The proposal is as follows: * Allow selected support of different password hashing algorithms from with passlib architecturally * Expand to support bcrypt * Deprecate the "crypt_strength" option in favor of identifying the cost when selecting the password hashing algorithm such as: sha512::10000 or bcrypt::12 * Keep the default the same as today * Identify the password hash based upon the algorithm used, no identifier = sha512 (this might not be required) * Add "py-bcrypt" or similar "preferred" backend(s) to extras in setup.cfg To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1543048/+subscriptions From tdecacqu at redhat.com Wed Aug 23 00:36:59 2017 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Wed, 23 Aug 2017 00:36:59 -0000 Subject: [Openstack-security] [Bug 1534322] Re: On new port, traffic flow is allowed before security groups are programmed References: <20160114214439.14625.28884.malonedeb@wampee.canonical.com> Message-ID: <150344862062.8283.12811002469702025620.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. - - -- - Description: During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed. File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py Funtion: process_network_ports Step-by-step: During the creation of a neutron port, the following calls are made: - treat_devices_added_or_updated - sg_agent.setup_port_filters - _bind_devices Before early November, process_network_ports called sg_agent.setup_port_filters before it called _bind_devices. This meant that security groups were programmed before traffic flow is enabled by _bind_devices, which sets the port-lvm mapping in br-int. Bug #1512636 reversed this order of operation, so that _bind_devices is called before sg_agent.setup_port_filters. This opens up a brief security hole, allowing traffic to flow for a short time before security groups are applied. Proposed solution: Revert bug# 1512636 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1534322 Title: On new port, traffic flow is allowed before security groups are programmed Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Description: During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed. File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py Funtion: process_network_ports Step-by-step: During the creation of a neutron port, the following calls are made: - treat_devices_added_or_updated - sg_agent.setup_port_filters - _bind_devices Before early November, process_network_ports called sg_agent.setup_port_filters before it called _bind_devices. This meant that security groups were programmed before traffic flow is enabled by _bind_devices, which sets the port-lvm mapping in br-int. Bug #1512636 reversed this order of operation, so that _bind_devices is called before sg_agent.setup_port_filters. This opens up a brief security hole, allowing traffic to flow for a short time before security groups are applied. Proposed solution: Revert bug# 1512636 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1534322/+subscriptions From 1702123 at bugs.launchpad.net Wed Aug 23 20:46:50 2017 From: 1702123 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 23 Aug 2017 20:46:50 -0000 Subject: [Openstack-security] [Bug 1702123] Re: SELinux error: keepalived reading haproxy pid file References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com> Message-ID: <150352121098.19046.9270721576226739027.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/495303 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=6c8e2b441d677855769975a771cf08784827b6c2 Submitter: Jenkins Branch: stable/pike commit 6c8e2b441d677855769975a771cf08784827b6c2 Author: Major Hayden Date: Thu Aug 17 10:37:15 2017 -0500 Bump ansible-keepalived to 3.0.3 This applies the changes that were made in the variable change from I8e6d811bca7553d82591a6c96f4316377d0d1829. Closes-Bug: 1702123 Change-Id: I8e87a5285afc52ef6ec9169e1a145b8308f78fcf ** Tags added: in-stable-pike -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1702123 Title: SELinux error: keepalived reading haproxy pid file Status in openstack-ansible: Fix Released Bug description: When keepalived tries to read the haproxy PID file, SELinux denies the access. This should be added into the haproxy role. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions From 1702123 at bugs.launchpad.net Wed Aug 23 21:04:24 2017 From: 1702123 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 23 Aug 2017 21:04:24 -0000 Subject: [Openstack-security] [Bug 1702123] Re: SELinux error: keepalived reading haproxy pid file References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com> Message-ID: <150352226463.8112.13781131209412713580.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/494612 Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=25becb3c09e092001b0789b48d86ea53d20f73bb Submitter: Jenkins Branch: stable/ocata commit 25becb3c09e092001b0789b48d86ea53d20f73bb Author: Major Hayden Date: Thu Aug 17 10:38:46 2017 -0500 Allow Keepalived to read haproxy pid file This is a combined backport of the master patch to add a SELinux rule that allows keepalived to read haproxy's PID file. It also includes a bump of ansible-keepalived to 3.0.2. Closes-Bug: 1702123 Change-Id: I3e206d0f2de663c9612d15444a827baf166af8d9 ** Tags added: in-stable-ocata -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1702123 Title: SELinux error: keepalived reading haproxy pid file Status in openstack-ansible: Fix Released Bug description: When keepalived tries to read the haproxy PID file, SELinux denies the access. This should be added into the haproxy role. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions From gerrit2 at review.openstack.org Thu Aug 24 14:56:54 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 24 Aug 2017 14:56:54 +0000 Subject: [Openstack-security] [openstack/cursive] SecurityImpact review request change I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357202 Log: commit f0fce1d24d8a3c24157a6e031abf202479855bc3 Author: Peter Hamilton Date: Thu Aug 18 08:50:38 2016 -0400 Add certificate validation This change adds support for certificate validation, including certificate inspection utilities. Validating a certificate requires the certificate UUID of the certificate to validate, a set of UUIDs corresponding to the set of trusted certificates needed to validate the certificate, and a user context for authentication to the key manager. A new certificate verification context is included that is used to store the set of trusted certificates once they are loaded from the key manager. This context is used to validate the signing certificate, verifying that the certificate belongs to a valid certificate chain rooted in the set of trusted certificates. All new certificate utility code is added in a new module named certificate_utils. For more information on this work, see the spec: https://review.openstack.org/#/c/357151/ SecurityImpact DocImpact Change-Id: I8d7f43fb4c0573ac3681147eac213b369bbbcb3b From 1702123 at bugs.launchpad.net Mon Aug 28 00:58:20 2017 From: 1702123 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 28 Aug 2017 00:58:20 -0000 Subject: [Openstack-security] [Bug 1702123] Fix included in openstack/openstack-ansible 15.1.8 References: <149909478116.6327.1678093967892023529.malonedeb@gac.canonical.com> Message-ID: <150388190056.8658.3700943660983440974.malone@soybean.canonical.com> This issue was fixed in the openstack/openstack-ansible 15.1.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/1702123 Title: SELinux error: keepalived reading haproxy pid file Status in openstack-ansible: Fix Released Bug description: When keepalived tries to read the haproxy PID file, SELinux denies the access. This should be added into the haproxy role. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1702123/+subscriptions From gerrit2 at review.openstack.org Tue Aug 29 13:39:53 2017 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 29 Aug 2017 13:39:53 +0000 Subject: [Openstack-security] [openstack/cursive] SecurityImpact review request change I8d7f43fb4c0573ac3681147eac213b369bbbcb3b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/357202 Log: commit 16a6fd0b6852e5ca6b361294a5ae821a4bbd32a4 Author: Peter Hamilton Date: Thu Aug 18 08:50:38 2016 -0400 Add certificate validation This change adds support for certificate validation, including certificate inspection utilities. Validating a certificate requires the certificate UUID of the certificate to validate, a set of UUIDs corresponding to the set of trusted certificates needed to validate the certificate, and a user context for authentication to the key manager. A new certificate verification context is included that is used to store the set of trusted certificates once they are loaded from the key manager. This context is used to validate the signing certificate, verifying that the certificate belongs to a valid certificate chain rooted in the set of trusted certificates. All new certificate utility code is added in a new module named certificate_utils. For more information on this work, see the spec: https://review.openstack.org/#/c/357151/ SecurityImpact DocImpact Change-Id: I8d7f43fb4c0573ac3681147eac213b369bbbcb3b From 1668410 at bugs.launchpad.net Wed Aug 30 04:20:10 2017 From: 1668410 at bugs.launchpad.net (Ubuntu Foundations Team Bug Bot) Date: Wed, 30 Aug 2017 04:20:10 -0000 Subject: [Openstack-security] [Bug 1668410] Re: [SRU] Infinite loop trying to delete deleted HA router References: <20170227213540.6394.32961.malonedeb@wampee.canonical.com> Message-ID: <150406681082.10786.5289230044639470892.malone@wampee.canonical.com> The attachment "mitaka.debdiff" seems to be a debdiff. The ubuntu- sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] ** Tags added: patch -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668410 Title: [SRU] Infinite loop trying to delete deleted HA router Status in neutron: In Progress Status in OpenStack Security Advisory: Won't Fix Status in neutron package in Ubuntu: Triaged Bug description: [Impact] When deleting a router the logfile is filled up. See full log - http://paste.ubuntu.com/25429257/ I can see the error 'Error while deleting router c0dab368-5ac8-4996-88c9-f5d345a774a6' occured 3343386 times from _safe_router_removed() [1]: $ grep -r 'Error while deleting router c0dab368-5ac8-4996-88c9-f5d345a774a6' |wc -l 3343386 This _safe_router_removed() is invoked by L488 [2], if _safe_router_removed() goes wrong it will return False, then self._resync_router(update) [3] will make the code _safe_router_removed be run again and again. So we saw so many errors 'Error while deleting router XXXXX'. [1] https://github.com/openstack/neutron/blob/mitaka-eol/neutron/agent/l3/agent.py#L361 [2] https://github.com/openstack/neutron/blob/mitaka-eol/neutron/agent/l3/agent.py#L488 [3] https://github.com/openstack/neutron/blob/mitaka-eol/neutron/agent/l3/agent.py#L457 [Test Case] That's because race condition between neutron server and L3 agent, after neutron server deletes HA interfaces the L3 agent may sync a HA router without HA interface info (just need to trigger L708[1] after deleting HA interfaces and before deleting HA router). If we delete HA router at this time, this problem will happen. So test case we design is as below: 1, First update fixed package, and restart neutron-server by 'sudo service neutron-server restart' 2, Create ha_router neutron router-create harouter --ha=True 3, Delete ports associated with ha_router before deleting ha_router neutron router-port-list harouter |grep 'HA port' |awk '{print $2}' |xargs -l neutron port-delete neutron router-port-list harouter 4, Update ha_router to trigger l3-agent to update ha_router info without ha_port into self.router_info neutron router-update harouter --description=test 5, Delete ha_router this time neutron router-delete harouter [1] https://github.com/openstack/neutron/blob/mitaka- eol/neutron/db/l3_hamode_db.py#L708 [Regression Potential] The fixed patch [1] for neutron-server will no longer return ha_router which is missing ha_ports, so L488 will no longer have chance to call _safe_router_removed() for a ha_router, so the problem has been fundamentally fixed by this patch and no regression potential. Besides, this fixed patch has been in mitaka-eol branch now, and neutron-server mitaka package is based on neutron-8.4.0, so we need to backport it to xenial and mitaka. $ git tag --contains 8c77ee6b20dd38cc0246e854711cb91cffe3a069 mitaka-eol [1] https://review.openstack.org/#/c/440799/2/neutron/db/l3_hamode_db.py [2] https://github.com/openstack/neutron/blob/mitaka-eol/neutron/agent/l3/agent.py#L488 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1668410/+subscriptions From lhinds at redhat.com Wed Aug 30 14:25:20 2017 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 30 Aug 2017 14:25:20 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <150410312182.11619.6775031834665802124.launchpad@wampee.canonical.com> ** Changed in: ossn Status: New => In Progress ** Changed in: ossn Importance: Undecided => High -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From lhinds at redhat.com Wed Aug 30 14:51:14 2017 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 30 Aug 2017 14:51:14 -0000 Subject: [Openstack-security] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing References: <20170228052347.7890.80677.malonedeb@chaenomeles.canonical.com> Message-ID: <150410467661.11063.5870757985107200730.launchpad@wampee.canonical.com> ** Changed in: ossn Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Committed Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions From fungi at yuggoth.org Thu Aug 31 19:04:14 2017 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 31 Aug 2017 19:04:14 -0000 Subject: [Openstack-security] [Bug 1713783] Re: After failed evacuation the recovered source compute tries to delete the instance References: <150402703560.19393.11649471063519714290.malonedeb@chaenomeles.canonical.com> Message-ID: <150420625473.19506.5363162046672342364.malone@chaenomeles.canonical.com> Agreeing with Tristan et al, and adding the "security" bug tag to indicate it's a hardening opportunity (C1). ** Tags added: security ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1713783 Title: After failed evacuation the recovered source compute tries to delete the instance Status in OpenStack Compute (nova): Triaged Status in OpenStack Compute (nova) newton series: Triaged Status in OpenStack Compute (nova) ocata series: Triaged Status in OpenStack Compute (nova) pike series: Triaged Status in OpenStack Security Advisory: Won't Fix Bug description: Description =========== In case of a failed evacuation attempt the status of the migration is 'accepted' instead of 'failed' so when source compute is recovered the compute manager tries to delete the instance from the source host. However a secondary fault prevents deleting the allocation in placement so the actual deletion of the instance fails as well. Steps to reproduce ================== The following functional test reproduces the bug: https://review.openstack.org/#/c/498482/ What it does: initiate evacuation when no valid host is available and evacuation fails, but nova manager still tries to delete the instance. Logs:     2017-08-29 19:11:15,751 ERROR [oslo_messaging.rpc.server] Exception during message handling     NoValidHost: No valid host was found. There are not enough hosts available.     2017-08-29 19:11:16,103 INFO [nova.tests.functional.test_servers] Running periodic for compute1 (host1)     2017-08-29 19:11:16,115 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/aggregates" status: 200 len: 18 microversion: 1.1     2017-08-29 19:11:16,120 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/inventories" status: 200 len: 401 microversion: 1.0     2017-08-29 19:11:16,131 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/allocations" status: 200 len: 152 microversion: 1.0     2017-08-29 19:11:16,138 INFO [nova.compute.resource_tracker] Final resource view: name=host1 phys_ram=8192MB used_ram=1024MB phys_disk=1028GB used_disk=1GB total_vcpus=10 used_vcpus=1 pci_stats=[]     2017-08-29 19:11:16,146 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/aggregates" status: 200 len: 18 microversion: 1.1     2017-08-29 19:11:16,151 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/4e8e23ff-0c52-4cf7-8356-d9fa88536316/inventories" status: 200 len: 401 microversion: 1.0     2017-08-29 19:11:16,152 INFO [nova.tests.functional.test_servers] Running periodic for compute2 (host2)     2017-08-29 19:11:16,163 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/aggregates" status: 200 len: 18 microversion: 1.1     2017-08-29 19:11:16,168 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/inventories" status: 200 len: 401 microversion: 1.0     2017-08-29 19:11:16,176 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/allocations" status: 200 len: 54 microversion: 1.0     2017-08-29 19:11:16,184 INFO [nova.compute.resource_tracker] Final resource view: name=host2 phys_ram=8192MB used_ram=512MB phys_disk=1028GB used_disk=0GB total_vcpus=10 used_vcpus=0 pci_stats=[]     2017-08-29 19:11:16,192 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/aggregates" status: 200 len: 18 microversion: 1.1     2017-08-29 19:11:16,197 INFO [nova.api.openstack.placement.requestlog] 127.0.0.1 "GET /placement/resource_providers/531b1ce8-def1-455d-95b3-4140665d956f/inventories" status: 200 len: 401 microversion: 1.0     2017-08-29 19:11:16,198 INFO [nova.tests.functional.test_servers] Finished with periodics     2017-08-29 19:11:16,255 INFO [nova.api.openstack.requestlog] 127.0.0.1 "GET /v2.1/6f70656e737461636b20342065766572/servers/5058200c-478e-4449-88c1-906fdd572662" status: 200 len: 1875 microversion: 2.53 time: 0.056198     2017-08-29 19:11:16,262 INFO [nova.api.openstack.requestlog] 127.0.0.1 "GET /v2.1/6f70656e737461636b20342065766572/os-migrations" status: 200 len: 373 microversion: 2.53 time: 0.004618     2017-08-29 19:11:16,280 INFO [nova.api.openstack.requestlog] 127.0.0.1 "PUT /v2.1/6f70656e737461636b20342065766572/os-services/c269bc74-4720-4de4-a6e5-889080b892a0" status: 200 len: 245 microversion: 2.53 time: 0.016442     2017-08-29 19:11:16,281 INFO [nova.service] Starting compute node (version 16.0.0)     2017-08-29 19:11:16,296 INFO [nova.compute.manager] Deleting instance as it has been evacuated from this host To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1713783/+subscriptions