From morgan.fainberg at gmail.com Sun Jun 3 23:35:20 2018 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Sun, 03 Jun 2018 23:35:20 -0000 Subject: [Openstack-security] [Bug 1578466] Re: keystone token cache should offer encryption like the middleware cache does References: <20160505031406.17572.11746.malonedeb@soybean.canonical.com> Message-ID: <152806892100.3710.11409491708951958508.malone@chaenomeles.canonical.com> This is something we should build into oslo.cache. I have moved the bug to wont fix in keystone and added oslo.cache. ** Also affects: oslo.cache Importance: Undecided Status: New ** Changed in: keystone Status: Triaged => Won't Fix ** Summary changed: - keystone token cache should offer encryption like the middleware cache does + cache should offer encryption in a similar manner to keystonemiddleware cache does -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1578466 Title: cache should offer encryption in a similar manner to keystonemiddleware cache does Status in OpenStack Identity (keystone): Won't Fix Status in oslo.cache: New Bug description: Keystone middleware's caching of tokens offers HMAC validation and encryption of the tokens in the cache. This is important because memcache has literally zero authentication or protection from any user on the system. So this feature should be ported in from keystone middleware into keystone. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1578466/+subscriptions From morgan.fainberg at gmail.com Sun Jun 3 23:36:44 2018 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Sun, 03 Jun 2018 23:36:44 -0000 Subject: [Openstack-security] [Bug 1578466] Re: cache should offer encryption in a similar manner to keystonemiddleware cache does References: <20160505031406.17572.11746.malonedeb@soybean.canonical.com> Message-ID: <152806900461.32111.15185049881556235939.malone@soybean.canonical.com> This can be done as a backend or as a proxy fairly easily. Move this from keystone bug tracker as it is generally a good feature request. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1578466 Title: cache should offer encryption in a similar manner to keystonemiddleware cache does Status in OpenStack Identity (keystone): Won't Fix Status in oslo.cache: New Bug description: Keystone middleware's caching of tokens offers HMAC validation and encryption of the tokens in the cache. This is important because memcache has literally zero authentication or protection from any user on the system. So this feature should be ported in from keystone middleware into keystone. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1578466/+subscriptions From 1750843 at bugs.launchpad.net Mon Jun 4 18:56:54 2018 From: 1750843 at bugs.launchpad.net (Matthew Thode) Date: Mon, 04 Jun 2018 18:56:54 -0000 Subject: [Openstack-security] [Bug 1750843] Re: pysaml2 version in global requirements must be updated to 4.5.0 References: <151922537889.2431.9740442844817515971.malonedeb@gac.canonical.com> Message-ID: <152813861720.4133.3509645398890923237.launchpad@chaenomeles.canonical.com> ** Changed in: openstack-requirements Status: New => Fix Released ** Changed in: openstack-requirements Assignee: (unassigned) => Matthew Thode (prometheanfire) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1750843 Title: pysaml2 version in global requirements must be updated to 4.5.0 Status in OpenStack Identity (keystone): Fix Committed Status in OpenStack Global Requirements: Fix Released Bug description: As per security vulnerability CVE-2016-10149, XML External Entity (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote attackers to read arbitrary files via a crafted SAML XML request or response and it has a CVSS v3 Base Score of 7.5. The above vulnerability has been fixed in version 4.5.0 as per https://github.com/rohe/pysaml2/issues/366. The latest version of pysaml2 (https://pypi.python.org/pypi/pysaml2/4.5.0) has this fix. However, the global requirements has the version set to < 4.0.3 https://github.com/openstack/requirements/blob/master/global-requirements.txt#L230 pysaml2>=4.0.2,<4.0.3 https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L347 pysaml2===4.0.2 The version of pysaml2 supported for OpenStack should be updated such that OpenStack deployments are not vulnerable to the above mentioned CVE. pysaml2 is used by OpenStack Keystone for identity Federation. This bug in itself is not a security vulnerability but not fixing this bug causes OpenStack deployments to be vulnerable. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1750843/+subscriptions From 1749326 at bugs.launchpad.net Thu Jun 7 20:55:30 2018 From: 1749326 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 07 Jun 2018 20:55:30 -0000 Subject: [Openstack-security] [Bug 1749326] Fix included in openstack/kolla-ansible 7.0.0.0b2 References: <151856918155.29609.17973703058565700322.malonedeb@chaenomeles.canonical.com> Message-ID: <152840493047.3753.11639024042345628492.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/kolla-ansible 7.0.0.0b2 development milestone. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1749326 Title: Exploitable services exposed on community test nodes Status in kolla-ansible: Fix Released Bug description: One of the donor service providers for the upstream OpenStack Infrastructure CI pool has notified us that their security team's periodic vulnerability scans have been identifying systems at random within our environment as running open memcached servers. Job correlation from these reports indicates each was running one of the following: kolla-ansible-oraclelinux-binary kolla-ansible-oraclelinux-source kolla-ansible-oraclelinux-source-ceph Please adjust the configuration of your job framework to prevent these services from being exposed to the Internet (through iptables ingress filters, service ACLs, configuring them to not listen on globally- routable interfaces, whatever works). Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1749326/+subscriptions From 1703369 at bugs.launchpad.net Thu Jun 7 22:08:36 2018 From: 1703369 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 07 Jun 2018 22:08:36 -0000 Subject: [Openstack-security] [Bug 1703369] Fix included in openstack/horizon 14.0.0.0b2 References: <149969257444.24611.1539875531360774756.malonedeb@soybean.canonical.com> Message-ID: <152840931660.24753.10975865678568168722.malone@gac.canonical.com> This issue was fixed in the openstack/horizon 14.0.0.0b2 development milestone. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1703369 Title: get_identity_providers policy should be singular Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) newton series: Fix Committed Status in OpenStack Identity (keystone) ocata series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider and the code is setup to check for identity:get_identity_provider (singular). See https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112 found in master (pike) The ocata default policy.json also has this problem. Unless someone manually overrode policy to specify identity:get_identity_provider (singular), the result would be that the default rule was actually used for that check instead of identity:get_identity_providers. We could go back and fix the default policy.json for past releases, but the default actually has the same value as identity:get_identity_providers, and if nobody has complained it's probably safer to just leave it. It is, after all, just defaults there and anyone can override by specifying the correct value. But we must fix in pike to go along with the shift of policy into code. Policy defaults in code definitely need to match up with what the code actually checks. There should no longer be any reliance on the default rule. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1703369/+subscriptions From 1761054 at bugs.launchpad.net Mon Jun 11 15:19:09 2018 From: 1761054 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 11 Jun 2018 15:19:09 -0000 Subject: [Openstack-security] [Bug 1761054] Fix included in openstack/nova 15.1.3 References: <152281951978.29145.13868060795008433631.malonedeb@chaenomeles.canonical.com> Message-ID: <152873034931.2025.3778221952443654569.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/nova 15.1.3 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1761054 Title: nova log expose password when swapvolume Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: http://logs.openstack.org/50/557150/6/check/tempest- full/1f9c9f2/controller/logs/screen-n-cpu.txt.gz#_Mar_30_08_37_13_371323 u'auth_password': u'8KigD3KKykJkJixs', u'auth_username': u'6m4wAHCZVqFfTQaF4eZu', To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1761054/+subscriptions From 1662563 at bugs.launchpad.net Wed Jun 13 05:58:10 2018 From: 1662563 at bugs.launchpad.net (Jan Zerebecki) Date: Wed, 13 Jun 2018 05:58:10 -0000 Subject: [Openstack-security] [Bug 1662563] Re: Tegile disabling certificate verification References: <20170207155109.5558.85832.malonedeb@soybean.canonical.com> Message-ID: <152886949147.7059.9429452665349254277.malone@wampee.canonical.com> https://review.openstack.org/#/c/501333/ removed this driver. ** Changed in: cinder Status: New => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1662563 Title: Tegile disabling certificate verification Status in Cinder: Fix Committed Bug description: Tegile is making reqeust calls with verify=False which disables SSL certificate checks in the following files: cinder/volume/drivers/tegile.py As suggested in this patch set (https://review.openstack.org/#/c/426385/), this bug is being opened in order to either fix the checks or add comments in the driver explaining why this is safe. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1662563/+subscriptions From 1750074 at bugs.launchpad.net Mon Jun 18 15:16:47 2018 From: 1750074 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 18 Jun 2018 15:16:47 -0000 Subject: [Openstack-security] [Bug 1750074] Fix included in openstack/cinder 11.1.1 References: <151882033265.13602.7690410348638039764.malonedeb@gac.canonical.com> Message-ID: <152933500779.2335.16901591827970031923.malone@chaenomeles.canonical.com> This issue was fixed in the openstack/cinder 11.1.1 release. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1750074 Title: Cinder logs rabbitmq password on connection log Status in Cinder: Fix Released Status in Manila: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Cinder may log rabbitmq password on connection when DEBUG is on. Example on cinder-scheduler.log file after enabling DEBUG: (Password has been replaced with XXX) 2018-02-05 19:21:52.721 35 DEBUG cinder.service [req-a2dbe0dd- 14c9-4123-a69a-3623e5f0a4d7 - - - - -] transport_url : rabbit://guest:XXX at 10.10.10.1:5672,guest:XXX at 10.10.10.2:5672,guest:XXX at 10.10.10.3:5672 wait /usr/lib/python2.7/site-packages/cinder/service.py:611 In a production environment, this is pretty bad. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1750074/+subscriptions From 1777460 at bugs.launchpad.net Mon Jun 18 21:19:52 2018 From: 1777460 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 18 Jun 2018 21:19:52 -0000 Subject: [Openstack-security] [Bug 1777460] Fix proposed to nova (stable/queens) References: <152933134329.1989.7672538528184873175.malonedeb@chaenomeles.canonical.com> Message-ID: <152935679298.26226.5006296894348154567.malone@soybean.canonical.com> Fix proposed to branch: stable/queens Review: https://review.openstack.org/576270 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1777460 Title: Whitelist two more SSBD-related CPU flags for AMD ('amd-ssbd', 'amd- no-ssb') Status in OpenStack Compute (nova): New Bug description: In addition to the existing 'virt-ssbd', future AMD CPUs will have another (architectural) way to deal with SSBD (Speculative Store Bypass Disable), via the CPU flag: 'amd-ssbd'. Furthermore, future AMD CPUs also will expose a mechanism to tell the guest that the "Speculative Store Bypass Disable" (SSBD) is not needed and that the CPU is all good. This is via the CPU flag: 'amd-no-ssb' In summary, two new flags are[1][2]: amd-ssbd amdb-no-ssb It is recommended to add the above two flags to the whitelist of Nova's `cpu_model_extra_flags` config attribute -- for stable branches (Queens, Pike and Ocata). For Rocky and above release, no such white-listing is required, since we allow free-form CPU flags[3].     * * * Additional notes (from the QEMU mailing list thread[4]) related to performance and live migration:   - tl;dr: On an AMD Compute node, a guest should be presented with     'amd-ssbd', if available, in preference to 'virt-ssbd'.     Details: Tom Lendacky from AMD writes[4] -- "The idea behind     'virt-ssbd' was to provide an architectural method for a guest to do     SSBD when 'amd-ssbd' isn't present. The 'amd-ssbd' feature will use     SPEC_CTRL which is intended to not be intercepted and will be fast.     The use of 'virt-ssbd' will always be intercepted and therefore will     not be as fast. So a guest should be presented with 'amd-ssbd', if     available, in preference to 'virt-ssbd'."   - It safe to use 'amd-ssbd' (it is an architectural method for a guest     to do SSBD) in a guest which can be live migrated between different     generations/families of AMD CPU. [1] libvirt patch:     https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html [2] QEMU patch:     https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html [3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --     libvirt: Lift the restriction of choices for `cpu_model_extra_flags` [4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1777460/+subscriptions From 1739646 at bugs.launchpad.net Tue Jun 19 12:01:23 2018 From: 1739646 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 19 Jun 2018 12:01:23 -0000 Subject: [Openstack-security] [Bug 1739646] Re: Instance type with disk set to 0 can cause DoS References: <151387701431.11131.16472149525534236557.malonedeb@gac.canonical.com> Message-ID: <152940968399.26875.14753821631255384085.malone@gac.canonical.com> Reviewed: https://review.openstack.org/561284 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=763fd62464e9a0753e061171cc1fd826055bbc01 Submitter: Zuul Branch: master commit 763fd62464e9a0753e061171cc1fd826055bbc01 Author: Matt Riedemann Date: Fri Apr 13 13:44:33 2018 -0400 Add policy rule to block image-backed servers with 0 root disk flavor This adds a new policy rule which defaults to behave in a backward compatible way, but will allow operators to enforce that servers created with a zero disk flavor must also be volume-backed servers. Allowing users to upload their own images and create image-backed servers on local disk with zero root disk size flavors can be potentially hazardous if the size of the image is unexpectedly large, since it can consume the local disk (or shared storage pool). It should be noted that disabling the new policy rule will result in a non-backward compatible API behavior change and no microversion is being introduced for this because enforcement via a new microversion would not close the security gap on any previous microversions. Related compute API reference and user documentation is updated to mention the policy rule along with a release note since this is tied to a security bug, which will be backported to stable branches. Change-Id: Id67e1285a0522474844de130c9263e11868f67fb Closes-Bug: #1739646 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1739646 Title: Instance type with disk set to 0 can cause DoS Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: In Progress Status in OpenStack Compute (nova) pike series: In Progress Status in OpenStack Compute (nova) queens series: In Progress Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: In OpenStack at the moment, there is the ability to create instance types with disk size 0. The API documentation states the following: "The size of the root disk that will be created in GiB. If 0 the root disk will be set to exactly the size of the image used to deploy the instance. However, in this case filter scheduler cannot select the compute host based on the virtual image size. Therefore, 0 should only be used for volume booted instances or for testing purposes." In a cloud environment where a deployer wants to offer boot-from- volume instances, those instance types will be there. However, this means that a user can upload an image of 4TB and boot small instances where each one will have 4TB of storage, potentially exhausting the disks local storage (or Ceph cluster if using Ceph for ephemeral storage). I'm not sure if this is a security issue or it should be published as an advisory, but I believe there should be an option to disable the feature of booting an instance with the exact size of the image used so deployers have the ability/choice to provide boot-from-volume instance types. I can confirm this in our environment that if a customer creates an instance with 200GB of ephemeral disk space, they can take an image of it, then create an instance with that image on an instance type that has no ephemeral disk space and get 200GB of disk. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1739646/+subscriptions From 1777460 at bugs.launchpad.net Fri Jun 22 20:14:26 2018 From: 1777460 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 22 Jun 2018 20:14:26 -0000 Subject: [Openstack-security] [Bug 1777460] Re: Whitelist two more SSBD-related CPU flags for AMD ('amd-ssbd', 'amd-no-ssb') References: <152933134329.1989.7672538528184873175.malonedeb@chaenomeles.canonical.com> Message-ID: <152969846643.2182.2818654985230635604.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/576270 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=f8aca778f704983bc7ebb0a75d42914fee2dac06 Submitter: Zuul Branch: stable/queens commit f8aca778f704983bc7ebb0a75d42914fee2dac06 Author: Dan Smith Date: Mon Jun 18 14:13:29 2018 -0700 [Stable Only] Add amd-ssbd and amd-no-ssb CPU flags Update the whitelist for the latest new CPU flags for mitigation of recent security issues. Change-Id: I8686a4755777c8c720c40d4111cc469676d2a5fd Closes-Bug: #1777460 ** Changed in: nova/queens Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1777460 Title: Whitelist two more SSBD-related CPU flags for AMD ('amd-ssbd', 'amd- no-ssb') Status in OpenStack Compute (nova): Won't Fix Status in OpenStack Compute (nova) ocata series: Confirmed Status in OpenStack Compute (nova) pike series: Confirmed Status in OpenStack Compute (nova) queens series: Fix Committed Bug description: In addition to the existing 'virt-ssbd', future AMD CPUs will have another (architectural) way to deal with SSBD (Speculative Store Bypass Disable), via the CPU flag: 'amd-ssbd'. Furthermore, future AMD CPUs also will expose a mechanism to tell the guest that the "Speculative Store Bypass Disable" (SSBD) is not needed and that the CPU is all good. This is via the CPU flag: 'amd-no-ssb' In summary, two new flags are[1][2]:     amd-ssbd     amd-no-ssb It is recommended to add the above two flags to the whitelist of Nova's `cpu_model_extra_flags` config attribute -- for stable branches (Queens, Pike and Ocata). For Rocky and above release, no such white-listing is required, since we allow free-form CPU flags[3].     * * * Additional notes (from the QEMU mailing list thread[4]) related to performance and live migration:   - tl;dr: On an AMD Compute node, a guest should be presented with     'amd-ssbd', if available, in preference to 'virt-ssbd'.     Details: Tom Lendacky from AMD writes[4] -- "The idea behind     'virt-ssbd' was to provide an architectural method for a guest to do     SSBD when 'amd-ssbd' isn't present. The 'amd-ssbd' feature will use     SPEC_CTRL which is intended to not be intercepted and will be fast.     The use of 'virt-ssbd' will always be intercepted and therefore will     not be as fast. So a guest should be presented with 'amd-ssbd', if     available, in preference to 'virt-ssbd'."   - It is safe to use 'amd-ssbd' (it is an architectural method for guest to do SSBD) in a guest which can be live migrated between different generations/families of AMD CPU. [1] libvirt patch:     https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html [2] QEMU patch:     https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html [3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --     libvirt: Lift the restriction of choices for `cpu_model_extra_flags` [4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1777460/+subscriptions From 1777460 at bugs.launchpad.net Fri Jun 22 20:25:00 2018 From: 1777460 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 22 Jun 2018 20:25:00 -0000 Subject: [Openstack-security] [Bug 1777460] Re: Whitelist two more SSBD-related CPU flags for AMD ('amd-ssbd', 'amd-no-ssb') References: <152933134329.1989.7672538528184873175.malonedeb@chaenomeles.canonical.com> Message-ID: <152969910032.1911.3463498821421508188.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/pike Review: https://review.openstack.org/577548 ** Changed in: nova/pike Status: Confirmed => In Progress ** Changed in: nova/pike Assignee: (unassigned) => Dan Smith (danms) -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1777460 Title: Whitelist two more SSBD-related CPU flags for AMD ('amd-ssbd', 'amd- no-ssb') Status in OpenStack Compute (nova): Won't Fix Status in OpenStack Compute (nova) ocata series: Confirmed Status in OpenStack Compute (nova) pike series: In Progress Status in OpenStack Compute (nova) queens series: Fix Committed Bug description: In addition to the existing 'virt-ssbd', future AMD CPUs will have another (architectural) way to deal with SSBD (Speculative Store Bypass Disable), via the CPU flag: 'amd-ssbd'. Furthermore, future AMD CPUs also will expose a mechanism to tell the guest that the "Speculative Store Bypass Disable" (SSBD) is not needed and that the CPU is all good. This is via the CPU flag: 'amd-no-ssb' In summary, two new flags are[1][2]:     amd-ssbd     amd-no-ssb It is recommended to add the above two flags to the whitelist of Nova's `cpu_model_extra_flags` config attribute -- for stable branches (Queens, Pike and Ocata). For Rocky and above release, no such white-listing is required, since we allow free-form CPU flags[3].     * * * Additional notes (from the QEMU mailing list thread[4]) related to performance and live migration:   - tl;dr: On an AMD Compute node, a guest should be presented with     'amd-ssbd', if available, in preference to 'virt-ssbd'.     Details: Tom Lendacky from AMD writes[4] -- "The idea behind     'virt-ssbd' was to provide an architectural method for a guest to do     SSBD when 'amd-ssbd' isn't present. The 'amd-ssbd' feature will use     SPEC_CTRL which is intended to not be intercepted and will be fast.     The use of 'virt-ssbd' will always be intercepted and therefore will     not be as fast. So a guest should be presented with 'amd-ssbd', if     available, in preference to 'virt-ssbd'."   - It is safe to use 'amd-ssbd' (it is an architectural method for guest to do SSBD) in a guest which can be live migrated between different generations/families of AMD CPU. [1] libvirt patch:     https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html [2] QEMU patch:     https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html [3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --     libvirt: Lift the restriction of choices for `cpu_model_extra_flags` [4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1777460/+subscriptions From 1739646 at bugs.launchpad.net Mon Jun 25 03:00:11 2018 From: 1739646 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 25 Jun 2018 03:00:11 -0000 Subject: [Openstack-security] [Bug 1739646] Re: Instance type with disk set to 0 can cause DoS References: <151387701431.11131.16472149525534236557.malonedeb@gac.canonical.com> Message-ID: <152989561131.7138.1309218252005046739.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/563692 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=7bcd581c78bb5916bf4b52e213322e7b56283572 Submitter: Zuul Branch: stable/queens commit 7bcd581c78bb5916bf4b52e213322e7b56283572 Author: Matt Riedemann Date: Fri Apr 13 13:44:33 2018 -0400 Add policy rule to block image-backed servers with 0 root disk flavor This adds a new policy rule which defaults to behave in a backward compatible way, but will allow operators to enforce that servers created with a zero disk flavor must also be volume-backed servers. Allowing users to upload their own images and create image-backed servers on local disk with zero root disk size flavors can be potentially hazardous if the size of the image is unexpectedly large, since it can consume the local disk (or shared storage pool). It should be noted that disabling the new policy rule will result in a non-backward compatible API behavior change and no microversion is being introduced for this because enforcement via a new microversion would not close the security gap on any previous microversions. Related compute API reference and user documentation is updated to mention the policy rule along with a release note since this is tied to a security bug, which will be backported to stable branches. Conflicts: nova/policies/servers.py nova/tests/unit/test_policy.py NOTE(mriedem): The conflict is due to not having change Iedd3fea0e86648fae364f075915555dcb2c4f199 in Queens for trusted certs. Change-Id: Id67e1285a0522474844de130c9263e11868f67fb Closes-Bug: #1739646 (cherry picked from commit 763fd62464e9a0753e061171cc1fd826055bbc01) ** Changed in: nova/queens Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1739646 Title: Instance type with disk set to 0 can cause DoS Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: In Progress Status in OpenStack Compute (nova) pike series: In Progress Status in OpenStack Compute (nova) queens series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: In OpenStack at the moment, there is the ability to create instance types with disk size 0. The API documentation states the following: "The size of the root disk that will be created in GiB. If 0 the root disk will be set to exactly the size of the image used to deploy the instance. However, in this case filter scheduler cannot select the compute host based on the virtual image size. Therefore, 0 should only be used for volume booted instances or for testing purposes." In a cloud environment where a deployer wants to offer boot-from- volume instances, those instance types will be there. However, this means that a user can upload an image of 4TB and boot small instances where each one will have 4TB of storage, potentially exhausting the disks local storage (or Ceph cluster if using Ceph for ephemeral storage). I'm not sure if this is a security issue or it should be published as an advisory, but I believe there should be an option to disable the feature of booting an instance with the exact size of the image used so deployers have the ability/choice to provide boot-from-volume instance types. I can confirm this in our environment that if a customer creates an instance with 200GB of ephemeral disk space, they can take an image of it, then create an instance with that image on an instance type that has no ephemeral disk space and get 200GB of disk. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1739646/+subscriptions From 1777460 at bugs.launchpad.net Mon Jun 25 04:53:27 2018 From: 1777460 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 25 Jun 2018 04:53:27 -0000 Subject: [Openstack-security] [Bug 1777460] Re: Whitelist two more SSBD-related CPU flags for AMD ('amd-ssbd', 'amd-no-ssb') References: <152933134329.1989.7672538528184873175.malonedeb@chaenomeles.canonical.com> Message-ID: <152990240717.25530.9747721229776296074.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/577548 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=682ee60803c0e6a468e701282a18cee1c118c9df Submitter: Zuul Branch: stable/pike commit 682ee60803c0e6a468e701282a18cee1c118c9df Author: Dan Smith Date: Mon Jun 18 14:13:29 2018 -0700 [Stable Only] Add amd-ssbd and amd-no-ssb CPU flags Update the whitelist for the latest new CPU flags for mitigation of recent security issues. Change-Id: I8686a4755777c8c720c40d4111cc469676d2a5fd Closes-Bug: #1777460 (cherry picked from commit f8aca778f704983bc7ebb0a75d42914fee2dac06) ** Changed in: nova/pike Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1777460 Title: Whitelist two more SSBD-related CPU flags for AMD ('amd-ssbd', 'amd- no-ssb') Status in OpenStack Compute (nova): Won't Fix Status in OpenStack Compute (nova) ocata series: Confirmed Status in OpenStack Compute (nova) pike series: Fix Committed Status in OpenStack Compute (nova) queens series: Fix Committed Bug description: In addition to the existing 'virt-ssbd', future AMD CPUs will have another (architectural) way to deal with SSBD (Speculative Store Bypass Disable), via the CPU flag: 'amd-ssbd'. Furthermore, future AMD CPUs also will expose a mechanism to tell the guest that the "Speculative Store Bypass Disable" (SSBD) is not needed and that the CPU is all good. This is via the CPU flag: 'amd-no-ssb' In summary, two new flags are[1][2]:     amd-ssbd     amd-no-ssb It is recommended to add the above two flags to the whitelist of Nova's `cpu_model_extra_flags` config attribute -- for stable branches (Queens, Pike and Ocata). For Rocky and above release, no such white-listing is required, since we allow free-form CPU flags[3].     * * * Additional notes (from the QEMU mailing list thread[4]) related to performance and live migration:   - tl;dr: On an AMD Compute node, a guest should be presented with     'amd-ssbd', if available, in preference to 'virt-ssbd'.     Details: Tom Lendacky from AMD writes[4] -- "The idea behind     'virt-ssbd' was to provide an architectural method for a guest to do     SSBD when 'amd-ssbd' isn't present. The 'amd-ssbd' feature will use     SPEC_CTRL which is intended to not be intercepted and will be fast.     The use of 'virt-ssbd' will always be intercepted and therefore will     not be as fast. So a guest should be presented with 'amd-ssbd', if     available, in preference to 'virt-ssbd'."   - It is safe to use 'amd-ssbd' (it is an architectural method for guest to do SSBD) in a guest which can be live migrated between different generations/families of AMD CPU. [1] libvirt patch:     https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html [2] QEMU patch:     https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html [3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --     libvirt: Lift the restriction of choices for `cpu_model_extra_flags` [4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1777460/+subscriptions From fungi at yuggoth.org Wed Jun 27 15:36:29 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 27 Jun 2018 15:36:29 -0000 Subject: [Openstack-security] [Bug 1742102] Re: Simple user can disable compute References: <151549265633.31963.16056376262321946117.malonedeb@wampee.canonical.com> Message-ID: <153011378937.6558.4087465576437423093.malone@soybean.canonical.com> On discussing with Dan Smith, the related denial of service condition described in this report has been a known risk since the introduction of the feature and generally falls below the threshold for broad publication in an advisory. The related fixes merged back as far as stable/pike will mitigate it (or can be tuned to greater extremes to do so if necessary) and are accompanied by a security release note. Since this report is already public, I'm going to mark this as a security hardening opportunity (class D in our VMT report taxonomy[*]) with no OSSA task needed. If there is a strong objection that an advisory is needed, then we can revisit publishing one. [*] https://security.openstack.org/vmt-process.html#incident-report- taxonomy ** Information type changed from Public Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1742102 Title: Simple user can disable compute Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) pike series: New Status in OpenStack Compute (nova) queens series: New Status in OpenStack Security Advisory: Won't Fix Bug description: Hi, When I tested a fresh deploy of Pike, I created a private network with a little subnet like /28. If you try to create a lot of new instances, nova failed because which doesn't have free IP for the creation of new instances. The fail trace is https://thepasteb.in/p/zmh8qDG2ZYJIZ So after that, the trigger consecutive_build_service_disable_threshold up to 10 very fast and computes are disable. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1742102/+subscriptions From 1739646 at bugs.launchpad.net Fri Jun 29 08:52:28 2018 From: 1739646 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 29 Jun 2018 08:52:28 -0000 Subject: [Openstack-security] [Bug 1739646] Re: Instance type with disk set to 0 can cause DoS References: <151387701431.11131.16472149525534236557.malonedeb@gac.canonical.com> Message-ID: <153026234824.30275.6103095346048015931.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/563700 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=0bf75621bbd25d4ce8a3588f112cf714891556eb Submitter: Zuul Branch: stable/pike commit 0bf75621bbd25d4ce8a3588f112cf714891556eb Author: Matt Riedemann Date: Fri Apr 13 13:44:33 2018 -0400 Add policy rule to block image-backed servers with 0 root disk flavor This adds a new policy rule which defaults to behave in a backward compatible way, but will allow operators to enforce that servers created with a zero disk flavor must also be volume-backed servers. Allowing users to upload their own images and create image-backed servers on local disk with zero root disk size flavors can be potentially hazardous if the size of the image is unexpectedly large, since it can consume the local disk (or shared storage pool). It should be noted that disabling the new policy rule will result in a non-backward compatible API behavior change and no microversion is being introduced for this because enforcement via a new microversion would not close the security gap on any previous microversions. Related compute API reference and user documentation is updated to mention the policy rule along with a release note since this is tied to a security bug, which will be backported to stable branches. Conflicts: doc/source/user/flavors.rst nova/tests/functional/wsgi/test_servers.py NOTE(mriedem): The doc/source/user/flavors.rst conflict is due to not having Ia57c93ef1e72ccf134ba6fc7fcb85ab228d68a47 in Pike. Rather than backport that, or drop the note about volume-backed instances for this backport, I have elected to just copy the wording for that particular section on "Root Disk GB". The nova/tests/functional/wsgi/test_servers.py conflict is due to not having I294c54e5a22dd6e5b226a4b00e7cd116813f0704 in Pike. Change-Id: Id67e1285a0522474844de130c9263e11868f67fb Closes-Bug: #1739646 (cherry picked from commit 763fd62464e9a0753e061171cc1fd826055bbc01) (cherry picked from commit 7bcd581c78bb5916bf4b52e213322e7b56283572) ** Changed in: nova/pike Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1739646 Title: Instance type with disk set to 0 can cause DoS Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: In Progress Status in OpenStack Compute (nova) pike series: Fix Committed Status in OpenStack Compute (nova) queens series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: In OpenStack at the moment, there is the ability to create instance types with disk size 0. The API documentation states the following: "The size of the root disk that will be created in GiB. If 0 the root disk will be set to exactly the size of the image used to deploy the instance. However, in this case filter scheduler cannot select the compute host based on the virtual image size. Therefore, 0 should only be used for volume booted instances or for testing purposes." In a cloud environment where a deployer wants to offer boot-from- volume instances, those instance types will be there. However, this means that a user can upload an image of 4TB and boot small instances where each one will have 4TB of storage, potentially exhausting the disks local storage (or Ceph cluster if using Ceph for ephemeral storage). I'm not sure if this is a security issue or it should be published as an advisory, but I believe there should be an option to disable the feature of booting an instance with the exact size of the image used so deployers have the ability/choice to provide boot-from-volume instance types. I can confirm this in our environment that if a customer creates an instance with 200GB of ephemeral disk space, they can take an image of it, then create an instance with that image on an instance type that has no ephemeral disk space and get 200GB of disk. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1739646/+subscriptions