From 1419577 at bugs.launchpad.net Mon Jul 2 13:41:10 2018 From: 1419577 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 02 Jul 2018 13:41:10 -0000 Subject: [Openstack-security] [Bug 1419577] Change abandoned on nova (master) References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <153053887102.18448.1834074793045871365.malone@chaenomeles.canonical.com> Change abandoned by Lee Yarwood (lyarwood at redhat.com) on branch: master Review: https://review.openstack.org/338929 Reason: https://review.openstack.org/#/c/551302/ -- You received this bug notification because you are a member of OpenStack Security SIG, 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 1739646 at bugs.launchpad.net Wed Jul 4 14:54:35 2018 From: 1739646 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 04 Jul 2018 14:54:35 -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: <153071607582.7221.843415726506302364.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/563719 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=8392c7f2656ae624877e3df539681c0a8f8b4926 Submitter: Zuul Branch: stable/ocata commit 8392c7f2656ae624877e3df539681c0a8f8b4926 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: api-ref/source/parameters.yaml doc/source/admin/flavors2.rst nova/policies/servers.py nova/tests/functional/wsgi/test_servers.py NOTE(mriedem): The api-ref/source/parameters.yaml conflict is due to If646149efb7eec8c90bf7d07c39ff4c495349941 not being in Pike. The doc/source/admin/flavors2.rst conflict is due to the doc not being in Ocata - it was migrated from the central admin-guide in Ifa0039e270e54ea2fb58ab18ce6724e5e8e061a1. The nova/policies/servers.py conflict is due to two changes in Pike: I17b6ca6e17c777ae7d337bf70ec4774ffe5187a8 and I050c4f5f19aa79a682e076cc3e47eba597f272dd. The DocumentedRuleDefault class was added to oslo.policy starting in 1.21.1 in Pike which is newer than what stable/ocata supports in global-requirements so we can't use it in this backport. The nova/tests/functional/wsgi/test_servers.py conflict is due to Ifcaaf285c8f98a1d0e8bbbc87b2f57fbce057346 and I294c54e5a22dd6e5b226a4b00e7cd116813f0704 not being in Ocata. Change-Id: Id67e1285a0522474844de130c9263e11868f67fb Closes-Bug: #1739646 (cherry picked from commit 763fd62464e9a0753e061171cc1fd826055bbc01) (cherry picked from commit 7bcd581c78bb5916bf4b52e213322e7b56283572) (cherry picked from commit 0bf75621bbd25d4ce8a3588f112cf714891556eb) ** Changed in: nova/ocata 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: Fix Committed 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 From 1611171 at bugs.launchpad.net Mon Jul 30 15:21:25 2018 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 30 Jul 2018 15:21:25 -0000 Subject: [Openstack-security] [Bug 1611171] Fix included in openstack/ec2-api 7.0.0 References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <153296408594.16669.12384114036526246319.malone@wampee.canonical.com> This issue was fixed in the openstack/ec2-api 7.0.0 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/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: Fix Released Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: Fix Released Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From 1739646 at bugs.launchpad.net Mon Jul 30 16:08:22 2018 From: 1739646 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 30 Jul 2018 16:08:22 -0000 Subject: [Openstack-security] [Bug 1739646] Fix included in openstack/nova 18.0.0.0b3 References: <151387701431.11131.16472149525534236557.malonedeb@gac.canonical.com> Message-ID: <153296690226.30696.2531890722027317335.malone@soybean.canonical.com> This issue was fixed in the openstack/nova 18.0.0.0b3 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/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: Fix Committed 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