From major at mhtx.net Fri Dec 2 13:51:49 2016 From: major at mhtx.net (Major Hayden) Date: Fri, 02 Dec 2016 13:51:49 -0000 Subject: [Openstack-security] [Bug 1568070] Re: Security: Identify which changes require a reboot References: <20160408175640.32100.77020.malonedeb@soybean.canonical.com> Message-ID: <20161202135150.5212.27576.malone@chaenomeles.canonical.com> https://review.openstack.org/404982 should help a little with this. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1568070 Title: Security: Identify which changes require a reboot Status in openstack-ansible: Incomplete Bug description: Some changes made by openstack-ansible-security require a reboot. It would be nice to alert the deployer to those changes at the end of the playbook run so they know if they had a change made that requires a reboot. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-ansible/+bug/1568070/+subscriptions From 832507 at bugs.launchpad.net Mon Dec 5 06:54:08 2016 From: 832507 at bugs.launchpad.net (nazeema) Date: Mon, 05 Dec 2016 06:54:08 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20161205065413.28497.94318.launchpad@soybean.canonical.com> ** Changed in: nova Assignee: Markus Zoeller (markus_z) (mzoeller) => nazeema (nazeema) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From 832507 at bugs.launchpad.net Mon Dec 5 07:00:36 2016 From: 832507 at bugs.launchpad.net (Nazeema Begum) Date: Mon, 05 Dec 2016 07:00:36 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20161205070039.23079.43997.launchpad@wampee.canonical.com> ** Changed in: nova Assignee: nazeema (nazeema) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From 1597557 at bugs.launchpad.net Tue Dec 6 08:44:47 2016 From: 1597557 at bugs.launchpad.net (anusha) Date: Tue, 06 Dec 2016 08:44:47 -0000 Subject: [Openstack-security] [Bug 1597557] Re: getting CSRF token missing or incorrect. /api/nova/servers/ when CSRF_COOKIE_HTTPONLY=True References: <20160630003449.23279.98663.malonedeb@gac.canonical.com> Message-ID: <20161206084449.5485.64062.launchpad@chaenomeles.canonical.com> ** Changed in: horizon Assignee: anusha (anusha) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1597557 Title: getting CSRF token missing or incorrect. /api/nova/servers/ when CSRF_COOKIE_HTTPONLY=True Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Using stable/mitkaka if I set CSRF_COOKIE_HTTPONLY=True in local_settings.py, when i try to launch an instance i get Forbidden (CSRF token missing or incorrect.): /api/nova/servers/ If i set it to false (or don't set it) then it works fine. This is what does not work # If Horizon is being served through SSL, then uncomment the following two # settings to better secure the cookies from security exploits CSRF_COOKIE_SECURE = True SESSION_COOKIE_SECURE = True # prevent certain client-side attacks, such as cross-site scripting CSRF_COOKIE_HTTPONLY = True SESSION_COOKIE_HTTPONLY = True this is what does work # If Horizon is being served through SSL, then uncomment the following two # settings to better secure the cookies from security exploits CSRF_COOKIE_SECURE = True SESSION_COOKIE_SECURE = True # prevent certain client-side attacks, such as cross-site scripting CSRF_COOKIE_HTTPONLY = False SESSION_COOKIE_HTTPONLY = True To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1597557/+subscriptions From 832507 at bugs.launchpad.net Tue Dec 6 10:41:43 2016 From: 832507 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 06 Dec 2016 10:41:43 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20161206104144.28061.95563.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/407450 ** Changed in: nova Assignee: (unassigned) => Markus Zoeller (markus_z) (mzoeller) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From 832507 at bugs.launchpad.net Tue Dec 6 15:11:45 2016 From: 832507 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 06 Dec 2016 15:11:45 -0000 Subject: [Openstack-security] [Bug 832507] Change abandoned on nova (master) References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20161206151145.28688.53556.malone@gac.canonical.com> Change abandoned by Markus Zoeller (markus_z) (mzoeller at linux.vnet.ibm.com) on branch: master Review: https://review.openstack.org/323765 Reason: Got superseded by https://review.openstack.org/#/c/407450/ -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From 1501808 at bugs.launchpad.net Tue Dec 6 16:39:58 2016 From: 1501808 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 06 Dec 2016 16:39:58 -0000 Subject: [Openstack-security] [Bug 1501808] Re: Enabling soft-deletes opens a DOS on compute hosts References: <20151001152652.22834.78736.malonedeb@gac.canonical.com> Message-ID: <20161206164001.28320.46689.launchpad@soybean.canonical.com> ** Changed in: nova Assignee: Andia (wangyuwei) => Chris Martin (cm876n) -- 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 832507 at bugs.launchpad.net Tue Dec 6 21:38:15 2016 From: 832507 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 06 Dec 2016 21:38:15 -0000 Subject: [Openstack-security] [Bug 832507] Re: console.log grows indefinitely References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20161206213815.25188.33890.malone@gac.canonical.com> Reviewed: https://review.openstack.org/407450 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=1f659251c7509cab045024044a6b8d642ad85aef Submitter: Jenkins Branch: master commit 1f659251c7509cab045024044a6b8d642ad85aef Author: Markus Zoeller Date: Tue Dec 6 11:40:25 2016 +0100 libvirt: virtlogd: use virtlogd for char devices This change makes actual usage of the "logd" sub-element for char devices. The two REST APIs ``os-getConsoleOutput`` and ``os-getSerialConsole`` can now be satisfied at the same time. This is valid for any combination of: * char device element: "console", "serial" * char device type: "tcp", "pty" There is also no need to create multiple different device types anymore. If we have a tcp device, we don't need the pty device anymore. The logging will be done in the tcp device. Implements blueprint libvirt-virtlogd Closes-Bug: 832507 Change-Id: Ia412f55bd988f6e11cd78c4c5a50a86389e648b0 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From 1611171 at bugs.launchpad.net Wed Dec 7 10:45:45 2016 From: 1611171 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 07 Dec 2016 10:45:45 -0000 Subject: [Openstack-security] [Bug 1611171] Fix included in openstack/nova 14.0.2 References: <20160809015520.22289.87995.malonedeb@soybean.canonical.com> Message-ID: <20161207104545.17089.82752.malone@soybean.canonical.com> This issue was fixed in the openstack/nova 14.0.2 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: Fix Released Status in gce-api: Fix Released Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in Rally: Fix Released Bug description: Hello, I'm looking through Designate source code to determine if is appropriate to include in Ubuntu Main. This isn't a full security audit. This looks like trouble: ./designate/cmd/manage.py def main(): CONF.register_cli_opt(category_opt) try: utils.read_config('designate', sys.argv) logging.setup(CONF, 'designate') except cfg.ConfigFilesNotFoundError: cfgfile = CONF.config_file[-1] if CONF.config_file else None if cfgfile and not os.access(cfgfile, os.R_OK): st = os.stat(cfgfile) print(_("Could not read %s. Re-running with sudo") % cfgfile) try: os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] + sys.argv) except Exception: print(_('sudo failed, continuing as if nothing happened')) print(_('Please re-run designate-manage as root.')) sys.exit(2) This is an interesting decision -- if the configuration file is _not_ readable by the user in question, give the executing user complete privileges of the user that owns the unreadable file. I'm not a fan of hiding privilege escalation / modifications in programs -- if a user had recently used sudo and thus had the authentication token already stored for their terminal, this 'hidden' use of sudo may be unexpected and unwelcome, especially since it appears that argv from the first call leaks through to the sudo call. Is this intentional OpenStack style? Or unexpected for you guys too? (Feel free to make this public at your convenience.) Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions From mriedem at us.ibm.com Fri Dec 9 16:12:07 2016 From: mriedem at us.ibm.com (Matt Riedemann) Date: Fri, 09 Dec 2016 16:12:07 -0000 Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed, lun-id couldn't be rollback in havana References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <20161209161210.16600.94721.launchpad@soybean.canonical.com> ** Changed in: nova Status: In Progress => Confirmed ** Changed in: nova Assignee: Lee Yarwood (lyarwood) => (unassigned) -- 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): Confirmed 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 sean at dague.net Fri Dec 9 16:14:49 2016 From: sean at dague.net (Sean Dague) Date: Fri, 09 Dec 2016 16:14:49 -0000 Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed, lun-id couldn't be rollback in havana References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <20161209161451.25567.29510.launchpad@gac.canonical.com> ** Changed in: nova Importance: High => Medium -- 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): Confirmed 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 1501808 at bugs.launchpad.net Sun Dec 11 13:50:56 2016 From: 1501808 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 11 Dec 2016 13:50:56 -0000 Subject: [Openstack-security] [Bug 1501808] Re: Enabling soft-deletes opens a DOS on compute hosts References: <20151001152652.22834.78736.malonedeb@gac.canonical.com> Message-ID: <20161211135059.23338.36190.launchpad@chaenomeles.canonical.com> ** Changed in: nova Assignee: Chris Martin (cm876n) => Andia (wangyuwei) -- 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 1501808 at bugs.launchpad.net Mon Dec 12 19:50:06 2016 From: 1501808 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 12 Dec 2016 19:50:06 -0000 Subject: [Openstack-security] [Bug 1501808] Re: Enabling soft-deletes opens a DOS on compute hosts References: <20151001152652.22834.78736.malonedeb@gac.canonical.com> Message-ID: <20161212195009.28951.60457.launchpad@wampee.canonical.com> ** Changed in: nova Assignee: Andia (wangyuwei) => Chris Martin (cm876n) -- 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 832507 at bugs.launchpad.net Thu Dec 15 17:34:36 2016 From: 832507 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 15 Dec 2016 17:34:36 -0000 Subject: [Openstack-security] [Bug 832507] Fix included in openstack/nova 15.0.0.0b2 References: <20110824042742.10840.74572.malonedeb@wampee.canonical.com> Message-ID: <20161215173436.20376.51520.malone@soybean.canonical.com> This issue was fixed in the openstack/nova 15.0.0.0b2 development milestone. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/832507 Title: console.log grows indefinitely Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Won't Fix Status in libvirt package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in qemu-kvm package in Ubuntu: Triaged Bug description: KVM takes everything from stdout and prints it to console.log. This does not appear to have a size limit, so if a user (mistakenly or otherwise) sends a lot of data to stdout, the console.log file can fill the entire disk of the compute node quite quickly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/832507/+subscriptions From fungi at yuggoth.org Mon Dec 19 15:10:04 2016 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 19 Dec 2016 15:10:04 -0000 Subject: [Openstack-security] [Bug 1563954] Re: use_forwarded_for exposes metadata References: <20160330160317.3139.18707.malonedeb@chaenomeles.canonical.com> Message-ID: <20161219151004.18173.15099.malone@chaenomeles.canonical.com> [that was me correcting the bug type/tags a moment ago, I just forgot I was still logged into a test account instead of this one] -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1563954 Title: use_forwarded_for exposes metadata Status in OpenStack Compute (nova): Confirmed Status in OpenStack Security Advisory: Opinion Status in OpenStack Security Notes: Fix Released Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. -- The nova metadata service uses the remote address to determine which metadata to retrieve. In order to work behind a proxy there is an option use_forwarded_for which will use the X-Forwarded-For header to determine the remote IP. If this option is set then anyone who can access the metadata port can request metadata for any instance if they know the IP. The user data is also exposed. $ echo 123456 > /tmp/data $ openstack server create --image CentOS7 --flavor fedora --user-data /tmp/data test $ curl -H 'X-Forwarded-For: 10.0.0.7' http://localhost:8775/latest/user-data/ 123456 At a minimum this side-effect isn't documented anywhere I could find. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1563954/+subscriptions