From 1244025 at bugs.launchpad.net Thu Oct 1 00:53:34 2015 From: 1244025 at bugs.launchpad.net (Armando Migliaccio) Date: Thu, 01 Oct 2015 00:53:34 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20151001005335.29333.22598.launchpad@gac.canonical.com> ** Also affects: networking-midonet Importance: Undecided Status: New ** No longer affects: neutron -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in networking-midonet: New Status in neutron havana series: New Status in OpenStack Security Advisory: Won't Fix Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-midonet/+bug/1244025/+subscriptions From pawel.koniszewski at intel.com Fri Oct 2 07:19:07 2015 From: pawel.koniszewski at intel.com (Pawel Koniszewski) Date: Fri, 02 Oct 2015 07:19:07 -0000 Subject: [Openstack-security] [Bug 1252519] Re: Live migration failed because of file permission changed References: <20131119003108.27374.76789.malonedeb@gac.canonical.com> Message-ID: <20151002071907.30415.22666.malone@chaenomeles.canonical.com> This is a regression introduced in Gluster 3.4.1 as pointed here - http://www.gluster.org/pipermail/gluster-users/2014-January/015885.html There is a workaround for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1057645#c7 Marking as invalid as this is not nova bug. ** Changed in: nova Status: Confirmed => Invalid -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1252519 Title: Live migration failed because of file permission changed Status in OpenStack Compute (nova): Invalid Bug description: Openstack : Havana OS : CentOS 6.4 Shared storage with GlusterFS : /var/lib/nova/instances mounted on glusterfs shared Instance start up fine on node01. When live migration happen, it moved to node02 but failed with the following error 2013-11-18 16:27:37.813 9837 ERROR nova.openstack.common.periodic_task [-] Error during ComputeManager.update_available_resource: Unexpected error while running command. Command: env LC_ALL=C LANG=C qemu-img info /var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk Exit code: 1 Stdout: '' Stderr: "qemu-img: Could not open '/var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk'\n" 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task Traceback (most recent call last): 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task File "/usr/lib/python2.6/site-packages/nova/openstack/common/periodic_task.py", line 180, in run_periodic_tasks 2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task task(self, context) The problem is with the file ownership of "console.log" and "disk". Those file should be owned by user "qemu" and group "qemu" but after the migration, both files are owned by root drwxr-xr-x 2 nova nova 53 Nov 18 13:40 . drwxr-xr-x 6 nova nova 110 Nov 18 13:43 .. -rw-rw---- 1 root root 1546 Nov 18 13:43 console.log -rw-r--r-- 1 root root 12058624 Nov 18 13:42 disk -rw-r--r-- 1 nova nova 1569 Nov 18 13:42 libvirt.xml To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1252519/+subscriptions From 1378172 at bugs.launchpad.net Fri Oct 2 08:22:24 2015 From: 1378172 at bugs.launchpad.net (Serg Melikyan) Date: Fri, 02 Oct 2015 08:22:24 -0000 Subject: [Openstack-security] [Bug 1378172] Re: Insecure tmp file creation in python-muranoclient References: <20141007043025.32411.70053.malonedeb@gac.canonical.com> Message-ID: <20151002082224.22834.10100.launchpad@gac.canonical.com> ** No longer affects: python-muranoclient/kilo ** Changed in: python-muranoclient Milestone: 0.7.1 => 0.8.0 ** Information type changed from Private Security to Public ** Information type changed from Public to Private Security ** Changed in: python-muranoclient Assignee: (unassigned) => Dmytro Dovbii (ddovbii) ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1378172 Title: Insecure tmp file creation in python-muranoclient Status in python-muranoclient: Confirmed Bug description: ./python-muranoclient/muranoclient/v1/shell.py:258: archive_name = args.output or tempfile.mktemp(prefix="murano_") try: if args.template: directory_path = hot_package.prepare_package(args) else: directory_path = mpl_package.prepare_package(args) archive_name = args.output or tempfile.mktemp(prefix="murano_") _make_archive(archive_name, directory_path) print("Application package is available at " + os.path.abspath(archive_name)) this is highly insecure and allows an attacker to modify the contents of the archive, assuming no arg name was passed. This code does not appear to be used, but is still CVE worthy as the code may be used (ref: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1692). Exploitation of this vuln would appear to lead to code execution (e.g. modify the archive package which is then used while deploying systems). To manage notifications about this bug go to: https://bugs.launchpad.net/python-muranoclient/+bug/1378172/+subscriptions From 1355509 at bugs.launchpad.net Fri Oct 2 12:06:17 2015 From: 1355509 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 02 Oct 2015 12:06:17 -0000 Subject: [Openstack-security] [Bug 1355509] Related fix merged to fuel-library (master) References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com> Message-ID: <20151002120617.22623.57290.malone@gac.canonical.com> Reviewed: https://review.openstack.org/229310 Committed: https://git.openstack.org/cgit/stackforge/fuel-library/commit/?id=7c1694dc2f573f8714f1845cf446bdcec5d01420 Submitter: Jenkins Branch: master commit 7c1694dc2f573f8714f1845cf446bdcec5d01420 Author: Matthew Mosesohn Date: Wed Sep 30 12:05:01 2015 +0300 Remove database_connection from compute Compute uses nova-conductor for communciation and not a direct database connection. The current database connection is unused and should be removed. Change-Id: Ied0e04d16779abaebd821f0d65b65ddfbf71316f Related-Bug: #1355509 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1355509 Title: Better conductor deployment Status in Fuel for OpenStack: Confirmed Status in Fuel for OpenStack 6.0.x series: Won't Fix Status in Fuel for OpenStack 7.0.x series: Won't Fix Status in Fuel for OpenStack 8.0.x series: Confirmed Bug description: Here is several issues with how MOS deploys conductor. 1 By default all deployment variants assume deployments with conductor enabled. But this requires to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor. One of the reason for creating conductor service was to provide security level for nova. 2 by default it not possible to disable conductor using MOS tools. Customers who prefer performance over security should have this options. Conductor can introduce significant delay in all actions required database access. This two enchantments are tied together. The following actions are required to disable usage of conductor. On all compute nodes: 1 make use mysql port is accessible from compute nodes and all necessary grange are present. 2 add into nova.conf [DEFAULT] sql_connection = mysql://nova:password at mysqlhost/nova_db [conductor] use_local=true 3 service openstack-nova-compute restart 4 optionally stop conductor process on controllers Monitoring tuning may be required.. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1355509/+subscriptions From fungi at yuggoth.org Fri Oct 2 12:21:00 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 02 Oct 2015 12:21:00 -0000 Subject: [Openstack-security] [Bug 1378172] Re: Insecure tmp file creation in python-muranoclient References: <20141007043025.32411.70053.malonedeb@gac.canonical.com> Message-ID: <20151002122100.30555.32305.malone@chaenomeles.canonical.com> The offending code seems to have been replaced months ago as a side effect of https://review.openstack.org/204048 (so fixed in 0.6.3), and was originally introduced in 8468a03 which first appeared in the 0.5.3 release. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1378172 Title: Insecure tmp file creation in python-muranoclient Status in python-muranoclient: Confirmed Bug description: ./python-muranoclient/muranoclient/v1/shell.py:258: archive_name = args.output or tempfile.mktemp(prefix="murano_") try: if args.template: directory_path = hot_package.prepare_package(args) else: directory_path = mpl_package.prepare_package(args) archive_name = args.output or tempfile.mktemp(prefix="murano_") _make_archive(archive_name, directory_path) print("Application package is available at " + os.path.abspath(archive_name)) this is highly insecure and allows an attacker to modify the contents of the archive, assuming no arg name was passed. This code does not appear to be used, but is still CVE worthy as the code may be used (ref: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1692). Exploitation of this vuln would appear to lead to code execution (e.g. modify the archive package which is then used while deploying systems). To manage notifications about this bug go to: https://bugs.launchpad.net/python-muranoclient/+bug/1378172/+subscriptions From mmosesohn at mirantis.com Fri Oct 2 12:43:47 2015 From: mmosesohn at mirantis.com (Matthew Mosesohn) Date: Fri, 02 Oct 2015 12:43:47 -0000 Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com> Message-ID: <20151002124347.22834.71634.malone@gac.canonical.com> The related issue (DB connection in compute settings) is fixed, but we are not moving nova-conductor off of controllers at this time. ** Changed in: fuel/8.0.x Status: Confirmed => Won't Fix ** Changed in: fuel/6.0.x Importance: Undecided => Wishlist ** Changed in: fuel/7.0.x Importance: Low => Wishlist -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1355509 Title: Better conductor deployment Status in Fuel for OpenStack: Confirmed Status in Fuel for OpenStack 6.0.x series: Won't Fix Status in Fuel for OpenStack 7.0.x series: Won't Fix Status in Fuel for OpenStack 8.0.x series: Won't Fix Bug description: Here is several issues with how MOS deploys conductor. 1 By default all deployment variants assume deployments with conductor enabled. But this requires to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor. One of the reason for creating conductor service was to provide security level for nova. 2 by default it not possible to disable conductor using MOS tools. Customers who prefer performance over security should have this options. Conductor can introduce significant delay in all actions required database access. This two enchantments are tied together. The following actions are required to disable usage of conductor. On all compute nodes: 1 make use mysql port is accessible from compute nodes and all necessary grange are present. 2 add into nova.conf [DEFAULT] sql_connection = mysql://nova:password at mysqlhost/nova_db [conductor] use_local=true 3 service openstack-nova-compute restart 4 optionally stop conductor process on controllers Monitoring tuning may be required.. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1355509/+subscriptions From 1378172 at bugs.launchpad.net Sat Oct 3 12:16:25 2015 From: 1378172 at bugs.launchpad.net (Serg Melikyan) Date: Sat, 03 Oct 2015 12:16:25 -0000 Subject: [Openstack-security] [Bug 1378172] Re: Insecure tmp file creation in python-muranoclient References: <20141007043025.32411.70053.malonedeb@gac.canonical.com> Message-ID: <20151003121626.1398.28794.launchpad@wampee.canonical.com> ** Changed in: python-muranoclient Milestone: 0.8.0 => 0.6.3 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1378172 Title: Insecure tmp file creation in python-muranoclient Status in python-muranoclient: Fix Committed Bug description: ./python-muranoclient/muranoclient/v1/shell.py:258: archive_name = args.output or tempfile.mktemp(prefix="murano_") try: if args.template: directory_path = hot_package.prepare_package(args) else: directory_path = mpl_package.prepare_package(args) archive_name = args.output or tempfile.mktemp(prefix="murano_") _make_archive(archive_name, directory_path) print("Application package is available at " + os.path.abspath(archive_name)) this is highly insecure and allows an attacker to modify the contents of the archive, assuming no arg name was passed. This code does not appear to be used, but is still CVE worthy as the code may be used (ref: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1692). Exploitation of this vuln would appear to lead to code execution (e.g. modify the archive package which is then used while deploying systems). To manage notifications about this bug go to: https://bugs.launchpad.net/python-muranoclient/+bug/1378172/+subscriptions From grant.murphy at hp.com Mon Oct 5 14:12:53 2015 From: grant.murphy at hp.com (Grant Murphy) Date: Mon, 05 Oct 2015 14:12:53 -0000 Subject: [Openstack-security] [Bug 1491307] Re: secgroup rules doesn't work for instance immediately References: <20150902093003.15597.54869.malonedeb@gac.canonical.com> Message-ID: <20151005141253.1947.72611.malone@wampee.canonical.com> +1 with affects line update -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1491307 Title: secgroup rules doesn't work for instance immediately Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Triaged Bug description: I have an OpenStack kilo setup on RHEL7.1 with a controller and a compute node (network-compute + network-network)，the config is following: # /etc/nova.nova.conf on contrller node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova # /etc/nova/nova.conf on compute node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver network_manager = nova.network.manager.FlatDHCPManager network_size = 254 allow_same_net_traffic = False multi_host = True send_arp_for_ha = True share_dhcp_address = True force_dhcp_release = True flat_network_bridge = br100 flat_interface = eth0 public_interface = eth0 steps for test 1: 1) create and start VM instance-1 with secgroup default; 2) VM instance-1 ping br100: OK; 3) br100 ping VM instance-1: operation not permitted (because of no secgroup-rules for ICMP) 4) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 5) br100 ping VM instance-1: i got the same wrong message, not expected. steps for test 2: 1) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0; 2) create and start VM instance-2 with secgroup default; 3) br100 ping instance-2: OK It seems that command "nova secgroup-add-rule ..." doesn't work immediately for the existed or running VM instances? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491307/+subscriptions From gerrit2 at review.openstack.org Mon Oct 5 14:59:17 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 05 Oct 2015 14:59:17 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/207226 Log: commit 2ddec53797a7db0ec9c32e174f6f9ab3c7498103 Author: Brant Knudson Date: Wed Jul 29 16:29:42 2015 -0500 Config option for insecure responses oslo.log's "debug" option was coopted to also indicate that the responses should include more information. A separate config option should be used instead so that deployers don't mistakenly expose themselves to security issues. The debug option still is used for what it does in oslo.log and how it works on all other projects -- if you're not using a log config file it sets the base logger to debug. SecurityImpact Change-Id: Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Closes-Bug: 1479523 From fungi at yuggoth.org Mon Oct 5 17:05:20 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 05 Oct 2015 17:05:20 -0000 Subject: [Openstack-security] [Bug 1491307] Re: secgroup rules doesn't work for instance immediately References: <20150902093003.15597.54869.malonedeb@gac.canonical.com> Message-ID: <20151005170520.1398.78533.malone@wampee.canonical.com> Also a slight phrasing improvement to suggest over the second sentence of Tristan's impact description from comment #14: "Security group changes silently fail to be applied to already running instances, potentially resulting in instances not being protected by the security group." Otherwise looks good to me. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1491307 Title: secgroup rules doesn't work for instance immediately Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Triaged Bug description: I have an OpenStack kilo setup on RHEL7.1 with a controller and a compute node (network-compute + network-network)，the config is following: # /etc/nova.nova.conf on contrller node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova # /etc/nova/nova.conf on compute node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver network_manager = nova.network.manager.FlatDHCPManager network_size = 254 allow_same_net_traffic = False multi_host = True send_arp_for_ha = True share_dhcp_address = True force_dhcp_release = True flat_network_bridge = br100 flat_interface = eth0 public_interface = eth0 steps for test 1: 1) create and start VM instance-1 with secgroup default; 2) VM instance-1 ping br100: OK; 3) br100 ping VM instance-1: operation not permitted (because of no secgroup-rules for ICMP) 4) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 5) br100 ping VM instance-1: i got the same wrong message, not expected. steps for test 2: 1) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0; 2) create and start VM instance-2 with secgroup default; 3) br100 ping instance-2: OK It seems that command "nova secgroup-add-rule ..." doesn't work immediately for the existed or running VM instances? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491307/+subscriptions From tdecacqu at redhat.com Mon Oct 5 18:20:31 2015 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 05 Oct 2015 18:20:31 -0000 Subject: [Openstack-security] [Bug 1491307] Re: secgroup rules doesn't work for instance immediately References: <20150902093003.15597.54869.malonedeb@gac.canonical.com> Message-ID: <20151005182031.23009.90331.malone@gac.canonical.com> Thanks, CVE requested with: Title: Nova network security group changes are not applied to running instances Reporter: Sreekumar S and Suntao Products: Nova Affects: <=2014.2.3, >=2015.1.0, <=2015.1.1 Description: Sreekumar S and Suntao independently reported a vulnerability in Nova network. Security group changes silently fail to be applied to already running instances, potentially resulting in instances not being protected by the security group. All Nova network setups are affected. ** Changed in: ossa Status: Triaged => In Progress ** Changed in: ossa Assignee: (unassigned) => Tristan Cacqueray (tristan-cacqueray) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1491307 Title: secgroup rules doesn't work for instance immediately Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: In Progress Bug description: I have an OpenStack kilo setup on RHEL7.1 with a controller and a compute node (network-compute + network-network)，the config is following: # /etc/nova.nova.conf on contrller node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova # /etc/nova/nova.conf on compute node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver network_manager = nova.network.manager.FlatDHCPManager network_size = 254 allow_same_net_traffic = False multi_host = True send_arp_for_ha = True share_dhcp_address = True force_dhcp_release = True flat_network_bridge = br100 flat_interface = eth0 public_interface = eth0 steps for test 1: 1) create and start VM instance-1 with secgroup default; 2) VM instance-1 ping br100: OK; 3) br100 ping VM instance-1: operation not permitted (because of no secgroup-rules for ICMP) 4) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 5) br100 ping VM instance-1: i got the same wrong message, not expected. steps for test 2: 1) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0; 2) create and start VM instance-2 with secgroup default; 3) br100 ping instance-2: OK It seems that command "nova secgroup-add-rule ..." doesn't work immediately for the existed or running VM instances? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491307/+subscriptions From tdecacqu at redhat.com Tue Oct 6 12:49:13 2015 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Tue, 06 Oct 2015 12:49:13 -0000 Subject: [Openstack-security] [Bug 1491307] Re: secgroup rules doesn't work for instance immediately (CVE-2015-7713) References: <20150902093003.15597.54869.malonedeb@gac.canonical.com> Message-ID: <20151006124914.26771.65685.launchpad@gac.canonical.com> ** Summary changed: - secgroup rules doesn't work for instance immediately + secgroup rules doesn't work for instance immediately (CVE-2015-7713) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1491307 Title: secgroup rules doesn't work for instance immediately (CVE-2015-7713) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: In Progress Bug description: I have an OpenStack kilo setup on RHEL7.1 with a controller and a compute node (network-compute + network-network)，the config is following: # /etc/nova.nova.conf on contrller node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova # /etc/nova/nova.conf on compute node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver network_manager = nova.network.manager.FlatDHCPManager network_size = 254 allow_same_net_traffic = False multi_host = True send_arp_for_ha = True share_dhcp_address = True force_dhcp_release = True flat_network_bridge = br100 flat_interface = eth0 public_interface = eth0 steps for test 1: 1) create and start VM instance-1 with secgroup default; 2) VM instance-1 ping br100: OK; 3) br100 ping VM instance-1: operation not permitted (because of no secgroup-rules for ICMP) 4) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 5) br100 ping VM instance-1: i got the same wrong message, not expected. steps for test 2: 1) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0; 2) create and start VM instance-2 with secgroup default; 3) br100 ping instance-2: OK It seems that command "nova secgroup-add-rule ..." doesn't work immediately for the existed or running VM instances? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491307/+subscriptions From gerrit2 at review.openstack.org Tue Oct 6 15:04:42 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 06 Oct 2015 15:04:42 +0000 Subject: [Openstack-security] [openstack/python-muranoclient] SecurityImpact review request change Iaaf06268bba8f437a0cd46c7393e1024d542888a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/231435 Log: commit d1a894a31b3e039ca7ab1bf0184006169a9305b4 Author: Nikolay Starodubtsev Date: Tue Oct 6 14:37:36 2015 +0300 Hide token id in logs Until this time it was possible to get token id directly from logs. SecurityImpact Closes-Bug: #1503065 Change-Id: Iaaf06268bba8f437a0cd46c7393e1024d542888a From gerrit2 at review.openstack.org Tue Oct 6 15:05:27 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 06 Oct 2015 15:05:27 +0000 Subject: [Openstack-security] [openstack/murano-dashboard] SecurityImpact review request change Ia2c7e19872a4d5b5093acd2e43b76273f02996e9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/231437 Log: commit 426742aa41fdcc08b34fd79df26a1f8fda865628 Author: Nikolay Starodubtsev Date: Tue Oct 6 14:50:14 2015 +0300 Hide token id in logs Until this time it was possible to steal token from the logs. Token was logged during muranoclient creation. SecurityImpact Closes-Bug: #1503059 Change-Id: Ia2c7e19872a4d5b5093acd2e43b76273f02996e9 From mriedem at us.ibm.com Tue Oct 6 17:35:51 2015 From: mriedem at us.ibm.com (Matt Riedemann) Date: Tue, 06 Oct 2015 17:35:51 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20151006173551.30686.84854.malone@soybean.canonical.com> The link to the blueprint in comment 13 is wrong, it's this: https://blueprints.launchpad.net/nova/+spec/validate-project-with- keystone There was a change proposed for juno and kilo but missed deadlines: https://review.openstack.org/#/c/143934/ Since that's an API impacting change it's going to require a spec for mitaka, which would also help to get operator and keystone team feedback. So I'm marking this as wishlist given it requires a spec. ** Changed in: nova Importance: High => Wishlist -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From mriedem at us.ibm.com Tue Oct 6 17:50:58 2015 From: mriedem at us.ibm.com (Matt Riedemann) Date: Tue, 06 Oct 2015 17:50:58 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20151006175058.26700.20643.malone@gac.canonical.com> Rather than validate against keystone, couldn't we just fail if we're trying to update a quotas or project_quotas table entry where project_id doesn't exist? -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From mriedem at us.ibm.com Tue Oct 6 19:09:56 2015 From: mriedem at us.ibm.com (Matt Riedemann) Date: Tue, 06 Oct 2015 19:09:56 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20151006190956.25919.5152.malone@chaenomeles.canonical.com> I validated today with openstackclient 1.7.0 that you can't show quotas for a project that doesn't exist: stack at client:~/devstack$ openstack quota show randomtext Tenant ID: randomtext does not exist. (HTTP 404) (Request-ID: req-cc9354ea-5935-45db-be60-b86aaf0a20ea) And I validated that with the v2.1 API you can't request a quota update on non-standard resources: {"badRequest": {"message": "Invalid input for field/attribute quota_set. Value: {u'foo': 20, u'force': True}. Additional properties are not allowed (u'foo' was unexpected)", "code": 400}} Because the jsonschema prevents that: https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/quota_sets.py#L28 However, you can create a nova.quotas table entry with an invalid projectid: http://paste.openstack.org/show/475511/ So we need to do something about that. I see two options: 1. quota-sets.update should only attempt to update quota on existing resources - if objects.Quotas.update_limit fails with a not found, we return 404 on the response. We don't try to create quotas automatically if they don't exist. However, as part of this we'd need to add a new quotas-sets.create API since update is handling both create and update today. This would require a microversion change since it's not backward compatible. 2. We could change quota-sets.update to try and update first and if we get a 404, then we validate the projectid against the identity service before calling objects.Quotas.create_limit. That would at least narrow the performance impact of validating the projectid against keystone in the request. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From mriedem at us.ibm.com Tue Oct 6 19:11:54 2015 From: mriedem at us.ibm.com (Matt Riedemann) Date: Tue, 06 Oct 2015 19:11:54 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20151006191154.18610.25744.malone@wampee.canonical.com> Also, confirmed that you can pass a random uuid to nova quota-show and it will just return default quotas: http://paste.openstack.org/show/475512/ Which is misleading if that project doesn't exist, but if you try updating it with the current behavior it will create the quotas entry in the db as detailed in comment 24. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From mriedem at us.ibm.com Tue Oct 6 19:29:59 2015 From: mriedem at us.ibm.com (Matt Riedemann) Date: Tue, 06 Oct 2015 19:29:59 -0000 Subject: [Openstack-security] [Bug 1031139] Re: quota-show should return error for invalid tenant id References: <20120730234300.27634.40825.malonedeb@gac.canonical.com> Message-ID: <20151006193000.18978.66768.launchpad@wampee.canonical.com> *** This bug is a duplicate of bug 1118066 *** https://bugs.launchpad.net/bugs/1118066 ** This bug has been marked a duplicate of bug 1118066 Nova should confirm quota requests against Keystone -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1031139 Title: quota-show should return error for invalid tenant id Status in OpenStack Compute (nova): Confirmed Bug description: quota-show does not handle alternatives for tenant_id as expected ENV: Devstack trunk (Folsom) / nova d56b5fc3ad6dbfc56e0729174925fb146cef87fa , Mon Jul 30 21:59:56 2012 +0000 I'd expect the following command to work as $ env | grep TENANT -> OS_TENANT_NAME=demo $ nova --debug --os_username=admin --os_password=password quota-show usage: nova quota-show error: too few arguments I'd also expect the following to work: $ nova --debug --os_username=admin --os_password=password quota-show --os_tenant_name=demo usage: nova quota-show error: too few arguments What is more awesome, if in the event that I do provide the wrong tenant_id, it proceeds to use OS_TENANT_NAME returning those results: $nova --debug --os_username=admin --os_password=password quota-show gggggggggggggggggggggggggggggggggg REQ: curl -i http://10.1.11.219:8774/v2/04adebe40d214581b84118bcce264f0e/os-quota- sets/ggggggggggggggggggggggggggggggggggg -X GET -H "X-Auth-Project-Id: demo" -H "User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 10bd3f948df24039b2b88b98771b2b99" +-----------------------------+-------+ | Property | Value | +-----------------------------+-------+ | cores | 20 | | floating_ips | 10 | | gigabytes | 1000 | | injected_file_content_bytes | 10240 | | injected_files | 5 | | instances | 10 | | metadata_items | 128 | | ram | 51200 | | volumes | 10 | +-----------------------------+-------+ I also couldn't figure out how to get the quota-show to work as a member (non-admin) of a project. Let me know if you want any of these issues broken out in to additional bugs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1031139/+subscriptions From gerrit2 at review.openstack.org Wed Oct 7 08:43:40 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 07 Oct 2015 08:43:40 +0000 Subject: [Openstack-security] [openstack/murano-dashboard] SecurityImpact review request change Ia2c7e19872a4d5b5093acd2e43b76273f02996e9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/231889 Log: commit eba215e1ab7c9581b8426b2ec91e11cbe045d0e3 Author: Nikolay Starodubtsev Date: Tue Oct 6 14:50:14 2015 +0300 Hide token id in logs Until this time it was possible to steal token from the logs. Token was logged during muranoclient creation. SecurityImpact Closes-Bug: #1503059 Change-Id: Ia2c7e19872a4d5b5093acd2e43b76273f02996e9 From gerrit2 at review.openstack.org Wed Oct 7 08:44:09 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 07 Oct 2015 08:44:09 +0000 Subject: [Openstack-security] [openstack/python-muranoclient] SecurityImpact review request change Iaaf06268bba8f437a0cd46c7393e1024d542888a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/231890 Log: commit d87a6656ba19714808ed26d25ffd2f0c8027f9aa Author: Nikolay Starodubtsev Date: Tue Oct 6 14:37:36 2015 +0300 Hide token id in logs Until this time it was possible to get token id directly from logs. SecurityImpact Closes-Bug: #1503065 Change-Id: Iaaf06268bba8f437a0cd46c7393e1024d542888a From tdecacqu at redhat.com Wed Oct 7 18:27:50 2015 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Wed, 07 Oct 2015 18:27:50 -0000 Subject: [Openstack-security] [Bug 1491307] Re: [OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713) References: <20150902093003.15597.54869.malonedeb@gac.canonical.com> Message-ID: <20151007182751.26569.67930.launchpad@chaenomeles.canonical.com> ** Summary changed: - secgroup rules doesn't work for instance immediately (CVE-2015-7713) + [OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1491307 Title: [OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: I have an OpenStack kilo setup on RHEL7.1 with a controller and a compute node (network-compute + network-network)，the config is following: # /etc/nova.nova.conf on contrller node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova # /etc/nova/nova.conf on compute node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver network_manager = nova.network.manager.FlatDHCPManager network_size = 254 allow_same_net_traffic = False multi_host = True send_arp_for_ha = True share_dhcp_address = True force_dhcp_release = True flat_network_bridge = br100 flat_interface = eth0 public_interface = eth0 steps for test 1: 1) create and start VM instance-1 with secgroup default; 2) VM instance-1 ping br100: OK; 3) br100 ping VM instance-1: operation not permitted (because of no secgroup-rules for ICMP) 4) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 5) br100 ping VM instance-1: i got the same wrong message, not expected. steps for test 2: 1) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0; 2) create and start VM instance-2 with secgroup default; 3) br100 ping instance-2: OK It seems that command "nova secgroup-add-rule ..." doesn't work immediately for the existed or running VM instances? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491307/+subscriptions From tdecacqu at redhat.com Wed Oct 7 18:33:18 2015 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Wed, 07 Oct 2015 18:33:18 -0000 Subject: [Openstack-security] [Bug 1491307] Re: [OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713) References: <20150902093003.15597.54869.malonedeb@gac.canonical.com> Message-ID: <20151007183321.26179.10982.launchpad@gac.canonical.com> ** Changed in: ossa 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/1491307 Title: [OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: I have an OpenStack kilo setup on RHEL7.1 with a controller and a compute node (network-compute + network-network)，the config is following: # /etc/nova.nova.conf on contrller node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova # /etc/nova/nova.conf on compute node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver network_manager = nova.network.manager.FlatDHCPManager network_size = 254 allow_same_net_traffic = False multi_host = True send_arp_for_ha = True share_dhcp_address = True force_dhcp_release = True flat_network_bridge = br100 flat_interface = eth0 public_interface = eth0 steps for test 1: 1) create and start VM instance-1 with secgroup default; 2) VM instance-1 ping br100: OK; 3) br100 ping VM instance-1: operation not permitted (because of no secgroup-rules for ICMP) 4) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 5) br100 ping VM instance-1: i got the same wrong message, not expected. steps for test 2: 1) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0; 2) create and start VM instance-2 with secgroup default; 3) br100 ping instance-2: OK It seems that command "nova secgroup-add-rule ..." doesn't work immediately for the existed or running VM instances? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491307/+subscriptions From gerrit2 at review.openstack.org Thu Oct 8 07:00:12 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 08 Oct 2015 07:00:12 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If143638a5ae21068c062048dc6e5e91b31cd524f Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/232371 Log: commit a47bf0994c9a3b56588bada6a57d7e48f4f01ce6 Author: bria4010 Date: Thu Oct 8 02:59:21 2015 -0400 Image Import Refactor This spec is intended to serve as the basis for the discussion on refactoring the Glance image import functionality at the Mitka summit. ApiImpact DocImpact SecurityImpact Change-Id: If143638a5ae21068c062048dc6e5e91b31cd524f Implements: blueprint image-import-refactor From ashtokolov at mirantis.com Tue Oct 6 13:54:00 2015 From: ashtokolov at mirantis.com (Alexey Shtokolov) Date: Tue, 06 Oct 2015 13:54:00 -0000 Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com> Message-ID: <20151006135402.26614.8357.launchpad@gac.canonical.com> ** Changed in: fuel Status: Confirmed => Triaged -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1355509 Title: Better conductor deployment Status in Fuel for OpenStack: Triaged Status in Fuel for OpenStack 6.0.x series: Won't Fix Status in Fuel for OpenStack 7.0.x series: Won't Fix Status in Fuel for OpenStack 8.0.x series: Won't Fix Bug description: Here is several issues with how MOS deploys conductor. 1 By default all deployment variants assume deployments with conductor enabled. But this requires to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor. One of the reason for creating conductor service was to provide security level for nova. 2 by default it not possible to disable conductor using MOS tools. Customers who prefer performance over security should have this options. Conductor can introduce significant delay in all actions required database access. This two enchantments are tied together. The following actions are required to disable usage of conductor. On all compute nodes: 1 make use mysql port is accessible from compute nodes and all necessary grange are present. 2 add into nova.conf [DEFAULT] sql_connection = mysql://nova:password at mysqlhost/nova_db [conductor] use_local=true 3 service openstack-nova-compute restart 4 optionally stop conductor process on controllers Monitoring tuning may be required.. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1355509/+subscriptions From yamamoto at midokura.com Wed Oct 7 04:51:29 2015 From: yamamoto at midokura.com (YAMAMOTO Takashi) Date: Wed, 07 Oct 2015 04:51:29 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20151007045130.18978.8258.malone@wampee.canonical.com> Brandon, this bug doesn't exit for currently supported versions, right? ** Changed in: networking-midonet Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in networking-midonet: Incomplete Status in neutron havana series: New Status in OpenStack Security Advisory: Won't Fix Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/networking-midonet/+bug/1244025/+subscriptions From robert.clark at hpe.com Thu Oct 8 08:57:39 2015 From: robert.clark at hpe.com (Clark, Robert Graham) Date: Thu, 8 Oct 2015 08:57:39 +0000 Subject: [Openstack-security] [Security] Weekly Meeting Agenda Message-ID: Hi All, I've created an etherpad for today's IRC meeting agenda as we've got a lot to talk about. https://etherpad.openstack.org/p/security-20151008-irc It's listed in the agenda but to be explicit too, we're attempting to plan our schedule for the summit rooms: https://etherpad.openstack.org/p/security-mikata-scheduling Cheers -Rob From mmosesohn at mirantis.com Thu Oct 8 10:13:39 2015 From: mmosesohn at mirantis.com (Matthew Mosesohn) Date: Thu, 08 Oct 2015 10:13:39 -0000 Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com> Message-ID: <20151008101341.19153.65388.launchpad@wampee.canonical.com> ** Changed in: fuel Status: Triaged => Won't Fix ** Changed in: fuel/6.0.x Assignee: (unassigned) => Matthew Mosesohn (raytrac3r) ** Changed in: fuel/7.0.x Assignee: Fuel Library Team (fuel-library) => Matthew Mosesohn (raytrac3r) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1355509 Title: Better conductor deployment Status in Fuel for OpenStack: Won't Fix Status in Fuel for OpenStack 6.0.x series: Won't Fix Status in Fuel for OpenStack 7.0.x series: Won't Fix Bug description: Here is several issues with how MOS deploys conductor. 1 By default all deployment variants assume deployments with conductor enabled. But this requires to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor. One of the reason for creating conductor service was to provide security level for nova. 2 by default it not possible to disable conductor using MOS tools. Customers who prefer performance over security should have this options. Conductor can introduce significant delay in all actions required database access. This two enchantments are tied together. The following actions are required to disable usage of conductor. On all compute nodes: 1 make use mysql port is accessible from compute nodes and all necessary grange are present. 2 add into nova.conf [DEFAULT] sql_connection = mysql://nova:password at mysqlhost/nova_db [conductor] use_local=true 3 service openstack-nova-compute restart 4 optionally stop conductor process on controllers Monitoring tuning may be required.. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1355509/+subscriptions From gerrit2 at review.openstack.org Thu Oct 8 13:06:44 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 08 Oct 2015 13:06:44 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If143638a5ae21068c062048dc6e5e91b31cd524f Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/232371 Log: commit 5ae8b054c89823fe4cfad0b3078496349a083914 Author: bria4010 Date: Thu Oct 8 02:59:21 2015 -0400 Image Import Refactor This spec is intended to serve as the basis for the discussion on refactoring the Glance image import functionality at the Mitka summit. ApiImpact DocImpact SecurityImpact Change-Id: If143638a5ae21068c062048dc6e5e91b31cd524f Implements: blueprint image-import-refactor From gerrit2 at review.openstack.org Thu Oct 8 13:35:21 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 08 Oct 2015 13:35:21 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If143638a5ae21068c062048dc6e5e91b31cd524f Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/232371 Log: commit 36b21cb9cc66d77e1518e875e89718a93d3468d0 Author: bria4010 Date: Thu Oct 8 02:59:21 2015 -0400 Image Import Refactor This spec is intended to serve as the basis for the discussion on refactoring the Glance image import functionality at the Mitka summit. ApiImpact DocImpact SecurityImpact Change-Id: If143638a5ae21068c062048dc6e5e91b31cd524f Implements: blueprint image-import-refactor From 1490693 at bugs.launchpad.net Fri Oct 9 15:09:43 2015 From: 1490693 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 09 Oct 2015 15:09:43 -0000 Subject: [Openstack-security] [Bug 1490693] Fix proposed to python-keystoneclient (stable/kilo) References: <20150831192731.19704.45527.malonedeb@soybean.canonical.com> Message-ID: <20151009150943.30719.79618.malone@soybean.canonical.com> Fix proposed to branch: stable/kilo Review: https://review.openstack.org/233111 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1490693 Title: session fails to sanitize response body of passwords Status in python-keystoneclient: Fix Released Bug description: Seeing this in the n-cpu logs when nova calls the os- initialize_connection API via python-cinderclient and cinder returns a response body with credentials in it: http://logs.openstack.org/66/218666/1/check/gate-tempest-dsvm- full/3ac1f2b/logs/screen-n-cpu.txt.gz#_2015-08-30_16_33_09_578 keystoneclient.session is logging the response body without sanitizing it first. 2015-08-30 16:33:09.578 DEBUG keystoneclient.session [req-ff63c358-41b0-4aac-8d8c-e369d82a0d5e tempest-TestMinimumBasicScenario-472140388 tempest-TestMinimumBasicScenario-192291337] REQ: curl -g -i -X POST http://127.0.0.1:8776/v2/8a98625b8c5445afbc72496ce2f7ab7f/volumes/744d2085-8e78-40a5-8659-ef3cffb2480e/action -H "User-Agent: python-cinderclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}fbdcb6c88ebb8ec83181b62e338a1a4b909f7031" -d '{"os-initialize_connection": {"connector": {"initiator": "iqn.1993-08.org.debian:01:f991bccc0", "ip": "172.99.69.228", "platform": "x86_64", "host": "devstack-trusty-rax-iad-4640004", "os_type": "linux2", "multipath": false}}}' _http_log_request /usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:195 2015-08-30 16:33:10.674 DEBUG keystoneclient.session [req-ff63c358-41b0-4aac-8d8c-e369d82a0d5e tempest-TestMinimumBasicScenario-472140388 tempest-TestMinimumBasicScenario-192291337] RESP: [200] content-length: 447 x-compute-request-id: req-747a68eb-f62e-4a43-aa8a-ff332c92783d connection: keep-alive date: Sun, 30 Aug 2015 16:33:10 GMT content-type: application/json x-openstack-request-id: req-747a68eb-f62e-4a43-aa8a-ff332c92783d RESP BODY: {"connection_info": {"driver_volume_type": "iscsi", "data": {"auth_password": "FF5vCvAvks8iQ2Vx", "target_discovered": false, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-744d2085-8e78-40a5-8659-ef3cffb2480e", "target_portal": "172.99.69.228:3260", "volume_id": "744d2085-8e78-40a5-8659-ef3cffb2480e", "target_lun": 1, "access_mode": "rw", "auth_username": "82tvLceDnfHjg6jrTwpq", "auth_method": "CHAP"}}} To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1490693/+subscriptions From mriedem at us.ibm.com Fri Oct 9 15:21:39 2015 From: mriedem at us.ibm.com (Matt Riedemann) Date: Fri, 09 Oct 2015 15:21:39 -0000 Subject: [Openstack-security] [Bug 1321785] Re: RFE: block_device_info dict should have a password key rather than clear password References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com> Message-ID: <20151009152140.26114.23797.launchpad@chaenomeles.canonical.com> ** Also affects: oslo.versionedobjects Importance: Undecided Status: New ** Changed in: oslo.versionedobjects Status: New => Confirmed ** Changed in: oslo.versionedobjects Importance: Undecided => Medium ** Changed in: oslo.versionedobjects Assignee: (unassigned) => Matt Riedemann (mriedem) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1321785 Title: RFE: block_device_info dict should have a password key rather than clear password Status in OpenStack Compute (nova): Confirmed Status in oslo.versionedobjects: Confirmed Bug description: See bug 1319943 and the related patch https://review.openstack.org/#/c/93787/ for details, but right now the block_device_info dict passed around in the nova virt driver can contain a clear text password for the auth_password key. That bug and patch are masking the password when logged in the immediate known locations, but this could continue to crop up so we should change the design such that the block_device_info dict doesn't contain the password but rather a key to a store that nova can retrieve the password for use. Comment from Daniel Berrange in the patch above: "Long term I think we need to figure out a way to remove the passwords from any data dicts we pass around. Ideally the block device info would merely contain something like a UUID to identify a password, which Nova could use to fetch the actual password from a secure password manager service at time of use. Thus we wouldn't have to worry about random objects/dicts containing actual passwords. Obviously this isn't something we can do now, but could you file an RFE to address this from a design POV, because masking passwords at time of logging call is not really a viable long term strategy IMHO." To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1321785/+subscriptions From mriedem at us.ibm.com Fri Oct 9 16:17:12 2015 From: mriedem at us.ibm.com (Matt Riedemann) Date: Fri, 09 Oct 2015 16:17:12 -0000 Subject: [Openstack-security] [Bug 1321785] Re: RFE: block_device_info dict should have a password key rather than clear password References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com> Message-ID: <20151009161712.30936.48102.malone@soybean.canonical.com> oslo.versionedobjects change: https://review.openstack.org/#/c/233151/ ** Changed in: oslo.versionedobjects 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/1321785 Title: RFE: block_device_info dict should have a password key rather than clear password Status in OpenStack Compute (nova): Confirmed Status in oslo.versionedobjects: In Progress Bug description: See bug 1319943 and the related patch https://review.openstack.org/#/c/93787/ for details, but right now the block_device_info dict passed around in the nova virt driver can contain a clear text password for the auth_password key. That bug and patch are masking the password when logged in the immediate known locations, but this could continue to crop up so we should change the design such that the block_device_info dict doesn't contain the password but rather a key to a store that nova can retrieve the password for use. Comment from Daniel Berrange in the patch above: "Long term I think we need to figure out a way to remove the passwords from any data dicts we pass around. Ideally the block device info would merely contain something like a UUID to identify a password, which Nova could use to fetch the actual password from a secure password manager service at time of use. Thus we wouldn't have to worry about random objects/dicts containing actual passwords. Obviously this isn't something we can do now, but could you file an RFE to address this from a design POV, because masking passwords at time of logging call is not really a viable long term strategy IMHO." To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1321785/+subscriptions From dpyzhov+launchpad at mirantis.com Thu Oct 8 10:12:03 2015 From: dpyzhov+launchpad at mirantis.com (Dmitry Pyzhov) Date: Thu, 08 Oct 2015 10:12:03 -0000 Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com> Message-ID: <20151008101205.26217.60531.launchpad@chaenomeles.canonical.com> ** Changed in: fuel Milestone: 7.0 => 8.0 ** No longer affects: fuel/8.0.x -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1355509 Title: Better conductor deployment Status in Fuel for OpenStack: Won't Fix Status in Fuel for OpenStack 6.0.x series: Won't Fix Status in Fuel for OpenStack 7.0.x series: Won't Fix Bug description: Here is several issues with how MOS deploys conductor. 1 By default all deployment variants assume deployments with conductor enabled. But this requires to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor. One of the reason for creating conductor service was to provide security level for nova. 2 by default it not possible to disable conductor using MOS tools. Customers who prefer performance over security should have this options. Conductor can introduce significant delay in all actions required database access. This two enchantments are tied together. The following actions are required to disable usage of conductor. On all compute nodes: 1 make use mysql port is accessible from compute nodes and all necessary grange are present. 2 add into nova.conf [DEFAULT] sql_connection = mysql://nova:password at mysqlhost/nova_db [conductor] use_local=true 3 service openstack-nova-compute restart 4 optionally stop conductor process on controllers Monitoring tuning may be required.. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1355509/+subscriptions From chuck.short at canonical.com Sun Oct 11 14:22:38 2015 From: chuck.short at canonical.com (Chuck Short) Date: Sun, 11 Oct 2015 14:22:38 -0000 Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user attribute in k2k assertions with different domains References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com> Message-ID: <20151011142239.26400.59762.launchpad@chaenomeles.canonical.com> ** Also affects: keystone/kilo Importance: Undecided Status: New ** Changed in: keystone/kilo Status: New => Fix Committed ** Changed in: keystone/kilo Milestone: None => 2015.1.2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in Keystone: Fix Released Status in Keystone kilo series: Fix Committed Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions From chuck.short at canonical.com Sun Oct 11 16:01:40 2015 From: chuck.short at canonical.com (Chuck Short) Date: Sun, 11 Oct 2015 16:01:40 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20151011160144.26650.52599.launchpad@gac.canonical.com> ** Changed in: heat/kilo Milestone: None => 2015.1.2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in heat kilo series: Fix Committed Status in Keystone: Fix Released Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Status in Sahara: Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From chuck.short at canonical.com Sun Oct 11 18:30:14 2015 From: chuck.short at canonical.com (Chuck Short) Date: Sun, 11 Oct 2015 18:30:14 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20151011183014.18829.196.launchpad@wampee.canonical.com> ** Also affects: neutron/kilo Importance: Undecided Status: New ** Changed in: neutron/kilo Status: New => Fix Committed ** Changed in: neutron/kilo Milestone: None => 2015.1.2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in neutron: Fix Released Status in neutron kilo series: Fix Committed Status in OpenStack Security Advisory: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From nstarodubtsev at mirantis.com Mon Oct 12 07:49:52 2015 From: nstarodubtsev at mirantis.com (Nikolay Starodubtsev) Date: Mon, 12 Oct 2015 07:49:52 -0000 Subject: [Openstack-security] [Bug 1504610] Re: Murano API cannot cope with being behind an SSL terminator References: <20151009165323.30614.6589.malonedeb@soybean.canonical.com> Message-ID: <20151012074954.18864.72705.launchpad@wampee.canonical.com> ** Changed in: murano/mitaka Assignee: (unassigned) => Nikolay Starodubtsev (starodubcevna) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1504610 Title: Murano API cannot cope with being behind an SSL terminator Status in murano: New Status in murano liberty series: New Status in murano mitaka series: New Bug description: On environments with SSL/https for all endpoints Murano deployments fail because Murano works under SSL terminator. Steps To Reproduce: 1. Deploy Murano in http mode and configure HA Proxy with SSL termination 2. Deploy Murano application Observed Result: Deployment will fail with the error about unreachable http Murano endpoint. We have the same issue for Heat which is already fixed now: https://bugs.launchpad.net/heat/+bug/1235555 HAProxy serves as the SSL termination for all of the LCP Services, Client HTTPS Request -> HAProxy HTTPS Listener -> Murano HTTP ListenerHAProxy uses the X-Forwarded-Proto to try and tell the application that the original request was HTTPS, unfortunately it does not appear Murano/webob adheres to the use of this header.https://github.com/Pylons/webob/blob/master/webob/request.py#L437 See the change issue related to heat api,https://review.openstack.org/#/c/64142/ To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1504610/+subscriptions From nstarodubtsev at mirantis.com Mon Oct 12 08:55:09 2015 From: nstarodubtsev at mirantis.com (Nikolay Starodubtsev) Date: Mon, 12 Oct 2015 08:55:09 -0000 Subject: [Openstack-security] [Bug 1504610] Re: Murano API cannot cope with being behind an SSL terminator References: <20151009165323.30614.6589.malonedeb@soybean.canonical.com> Message-ID: <20151012085510.30719.53810.launchpad@soybean.canonical.com> ** Changed in: murano/liberty Assignee: (unassigned) => Nikolay Starodubtsev (starodubcevna) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1504610 Title: Murano API cannot cope with being behind an SSL terminator Status in murano: New Status in murano liberty series: New Status in murano mitaka series: New Bug description: On environments with SSL/https for all endpoints Murano deployments fail because Murano works under SSL terminator. Steps To Reproduce: 1. Deploy Murano in http mode and configure HA Proxy with SSL termination 2. Deploy Murano application Observed Result: Deployment will fail with the error about unreachable http Murano endpoint. We have the same issue for Heat which is already fixed now: https://bugs.launchpad.net/heat/+bug/1235555 HAProxy serves as the SSL termination for all of the LCP Services, Client HTTPS Request -> HAProxy HTTPS Listener -> Murano HTTP ListenerHAProxy uses the X-Forwarded-Proto to try and tell the application that the original request was HTTPS, unfortunately it does not appear Murano/webob adheres to the use of this header.https://github.com/Pylons/webob/blob/master/webob/request.py#L437 See the change issue related to heat api,https://review.openstack.org/#/c/64142/ To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1504610/+subscriptions From nstarodubtsev at mirantis.com Mon Oct 12 09:13:34 2015 From: nstarodubtsev at mirantis.com (Nikolay Starodubtsev) Date: Mon, 12 Oct 2015 09:13:34 -0000 Subject: [Openstack-security] [Bug 1504610] Re: Murano API cannot cope with being behind an SSL terminator References: <20151009165323.30614.6589.malonedeb@soybean.canonical.com> Message-ID: <20151012091335.18690.12142.launchpad@wampee.canonical.com> ** Changed in: murano/liberty Milestone: None => liberty-rc2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1504610 Title: Murano API cannot cope with being behind an SSL terminator Status in murano: Confirmed Status in murano liberty series: Confirmed Status in murano mitaka series: Confirmed Bug description: On environments with SSL/https for all endpoints Murano deployments fail because Murano works under SSL terminator. Steps To Reproduce: 1. Deploy Murano in http mode and configure HA Proxy with SSL termination 2. Deploy Murano application Observed Result: Deployment will fail with the error about unreachable http Murano endpoint. We have the same issue for Heat which is already fixed now: https://bugs.launchpad.net/heat/+bug/1235555 HAProxy serves as the SSL termination for all of the LCP Services, Client HTTPS Request -> HAProxy HTTPS Listener -> Murano HTTP ListenerHAProxy uses the X-Forwarded-Proto to try and tell the application that the original request was HTTPS, unfortunately it does not appear Murano/webob adheres to the use of this header.https://github.com/Pylons/webob/blob/master/webob/request.py#L437 See the change issue related to heat api,https://review.openstack.org/#/c/64142/ To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1504610/+subscriptions From rydou at cn.ibm.com Tue Oct 13 03:06:46 2015 From: rydou at cn.ibm.com (Rui Yuan Dou) Date: Tue, 13 Oct 2015 03:06:46 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20151013030646.20876.50874.malone@gac.canonical.com> I just include the web console url in a iframe item of my localhost web server page, and the console still can be shown in that page, and there's no such "Origin" header exists. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1361360 at bugs.launchpad.net Tue Oct 13 12:55:20 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 13 Oct 2015 12:55:20 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20151013125523.20704.77971.launchpad@gac.canonical.com> ** Changed in: sahara 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/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in heat kilo series: Fix Committed Status in Keystone: Fix Released Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Status in Sahara: In Progress Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From chuck.short at canonical.com Tue Oct 13 19:21:44 2015 From: chuck.short at canonical.com (Chuck Short) Date: Tue, 13 Oct 2015 19:21:44 -0000 Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user attribute in k2k assertions with different domains References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com> Message-ID: <20151013192147.11215.29733.launchpad@wampee.canonical.com> ** Changed in: keystone/kilo Status: Fix Committed => 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/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in Keystone: Fix Released Status in Keystone kilo series: Fix Released Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions From chuck.short at canonical.com Tue Oct 13 19:23:10 2015 From: chuck.short at canonical.com (Chuck Short) Date: Tue, 13 Oct 2015 19:23:10 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20151013192314.11138.45104.launchpad@wampee.canonical.com> ** Changed in: neutron/kilo Status: Fix Committed => 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/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in neutron: Fix Released Status in neutron kilo series: Fix Released Status in OpenStack Security Advisory: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 08:15:39 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 08:15:39 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20151015081541.10985.80051.launchpad@wampee.canonical.com> ** Changed in: barbican Milestone: liberty-1 => 1.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in Barbican: Fix Released Status in Barbican kilo series: Fix Released Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 08:51:00 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 08:51:00 -0000 Subject: [Openstack-security] [Bug 1451931] Re: ironic password config not marked as secret References: <20150505164255.28640.31104.malonedeb@soybean.canonical.com> Message-ID: <20151015085101.17367.77432.launchpad@chaenomeles.canonical.com> ** Changed in: nova Milestone: liberty-1 => 12.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1451931 Title: ironic password config not marked as secret Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Committed Bug description: The ironic config option for the password and auth token are not marked as secret so the values will get logged during startup in debug mode. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1451931/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:03:38 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:03:38 -0000 Subject: [Openstack-security] [Bug 1491307] Re: [OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713) References: <20150902093003.15597.54869.malonedeb@gac.canonical.com> Message-ID: <20151015090340.17334.67651.launchpad@chaenomeles.canonical.com> ** Changed in: nova Milestone: liberty-rc1 => 12.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1491307 Title: [OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: I have an OpenStack kilo setup on RHEL7.1 with a controller and a compute node (network-compute + network-network)，the config is following: # /etc/nova.nova.conf on contrller node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova # /etc/nova/nova.conf on compute node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver network_manager = nova.network.manager.FlatDHCPManager network_size = 254 allow_same_net_traffic = False multi_host = True send_arp_for_ha = True share_dhcp_address = True force_dhcp_release = True flat_network_bridge = br100 flat_interface = eth0 public_interface = eth0 steps for test 1: 1) create and start VM instance-1 with secgroup default; 2) VM instance-1 ping br100: OK; 3) br100 ping VM instance-1: operation not permitted (because of no secgroup-rules for ICMP) 4) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 5) br100 ping VM instance-1: i got the same wrong message, not expected. steps for test 2: 1) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0; 2) create and start VM instance-2 with secgroup default; 3) br100 ping instance-2: OK It seems that command "nova secgroup-add-rule ..." doesn't work immediately for the existed or running VM instances? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491307/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:40:58 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:40:58 -0000 Subject: [Openstack-security] [Bug 1376915] Re: Access to sensitive audit data is not properly restricted References: <20141002203501.17647.70947.malonedeb@chaenomeles.canonical.com> Message-ID: <20151015094100.17635.75288.launchpad@soybean.canonical.com> ** Changed in: ceilometer Milestone: liberty-rc1 => 5.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1376915 Title: Access to sensitive audit data is not properly restricted Status in Ceilometer: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Audit data stored in http.request and http.response meters is not being adequately protected. Admins are allowed to access audit data for all projects rather than just their own. Non-admins are allowed to access audit data for all users within their project rather than just themselves. A non-admin user should not be able to see what other users are doing, and being an admin in project A does not make you an admin in project B. The following blueprints acknowledge the lack of this support. To quote one: "as ceilometer collects more and more different types of data... some of the data collected may be 'privileged' data that only admins should have access to regardless of membership to a tenant (ie. audit data should only be visible to admins)". That day has come, and the implementation of these blueprints is still missing. At this point there is a security hole here (data exposure) which needs to be plugged immediately, either with the implementation of one of these blueprints (which should probably be merged together) or by a less flexible but more easily implemented stopgap measure. Given time constraints and the urgency of closing this hole, I propose the latter, though the blueprints will obviously still be necessary for a more robust and complete solution. https://blueprints.launchpad.net/ceilometer/+spec/advanced-policy-rule and https://blueprints.launchpad.net/ceilometer/+spec/admin-only-api- access and https://blueprints.launchpad.net/ceilometer/+spec/ready- ceilometer-rbac-keystone-v3 To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1376915/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:55:28 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:55:28 -0000 Subject: [Openstack-security] [Bug 1440958] Re: loosen validation on matching trusted dashboard References: <20150407024927.26193.80349.malonedeb@gac.canonical.com> Message-ID: <20151015095529.17202.69880.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Milestone: liberty-1 => 8.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1440958 Title: loosen validation on matching trusted dashboard Status in Keystone: Fix Released Bug description: In the current implementation for verifying where the SSO request came from, the host is grabbed from the 'origin' query parameter, and compared to the list of 'trusted_dashboards' in the config file. origin = context['query_string'].get('origin') host = urllib.parse.unquote_plus(origin) if host in CONF.federation.trusted_dashboard: ... https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/controllers.py#L278-L287 This works, but unless the entry is marked perfectly in the config file, it won't match. We should loosen the validation that is performed, and maybe even use the HTTP Referer instead (and no longer require the 'origin' parameter from horizon). We should be able to decompose the Refer to figure out the scheme + hostname + path, and use that hostname to check against the trusted dashboards. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1440958/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:54:51 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:54:51 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate (and overly broad?) events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20151015095453.20843.38920.launchpad@gac.canonical.com> ** Changed in: keystone Milestone: liberty-1 => 8.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in Keystone: Fix Released Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:55:13 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:55:13 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20151015095516.17591.80178.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Milestone: liberty-1 => 8.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in heat kilo series: Fix Released Status in Keystone: Fix Released Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Status in Sahara: In Progress Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:59:19 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:59:19 -0000 Subject: [Openstack-security] [Bug 1484237] Re: token revocations not always respected when using fernet tokens References: <20150812185544.5991.94491.malonedeb@gac.canonical.com> Message-ID: <20151015095920.17874.77980.launchpad@soybean.canonical.com> ** Changed in: keystone Milestone: liberty-rc1 => 8.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1484237 Title: token revocations not always respected when using fernet tokens Status in Keystone: Fix Released Status in Keystone kilo series: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: A simple test that shows that fernet tokens are not always being invalidated. Simple test steps: 1) gets a token 2) deletes a token 3) tries to validate the deleted token When I run this in production on 10 tokens, I get about a 20% success rate on the token being detected as invalid, 80% of the time, keystone tells me the token is valid. I have validated that the token is showing in the revocation event table. I've tried a 5 second delay between the calls which did not change the behavior. My current script (below) will look for 204 and 404 to show failure and will wait forever. I've let it wait over 5 minutes, it seems to me that either keystone knows immediately that the token is invalid or not at all. I do not have memcache enabled on these nodes. The same test has a 100% pass rate with UUID tokens. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1484237/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:56:57 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:56:57 -0000 Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled References: <20150617025422.18505.35016.malonedeb@gac.canonical.com> Message-ID: <20151015095659.17224.44724.launchpad@soybean.canonical.com> ** Changed in: keystone Milestone: liberty-2 => 8.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1465922 Title: Password visible in clear text in keystone.log when user created and keystone debug logging is enabled Status in Keystone: Fix Released Status in Keystone juno series: In Progress Status in Keystone kilo series: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: grep CLEARTEXTPASSWORD keystone.log 2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:create_user(user={u'domain_id': u'default', u'password': u'CLEARTEXTPASSWORD', u'enabled': True, u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name': u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site- packages/keystone/common/controller.py:57 Issue code: https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57     LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {         'action': action,         'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])}) Shadow the values of sensitive fields like 'password' by some meaningless garbled text like "XXXXX" is one way to fix. Well, in addition to this, I think we should never pass the 'password' with its original value along the code and save it in any persistence, instead we should convert it to a strong hash value as early as possible. With the help of a good hash system, we never have to need the original value of the password, right? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1465922/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:56:36 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:56:36 -0000 Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user attribute in k2k assertions with different domains References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com> Message-ID: <20151015095637.10648.67443.launchpad@wampee.canonical.com> ** Changed in: keystone Milestone: liberty-1 => 8.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in Keystone: Fix Released Status in Keystone kilo series: Fix Released Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:56:34 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:56:34 -0000 Subject: [Openstack-security] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20151015095635.20664.85152.launchpad@gac.canonical.com> ** Changed in: keystone Milestone: liberty-1 => 8.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in Keystone: Fix Released Status in Keystone kilo series: Fix Released Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 09:58:35 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 09:58:35 -0000 Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE References: <20130503065127.14958.89453.malonedeb@gac.canonical.com> Message-ID: <20151015095837.21166.74831.launchpad@gac.canonical.com> ** Changed in: keystone Milestone: liberty-3 => 8.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175905 Title: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE Status in Keystone: Fix Released Bug description: Grant Murphy originally reported: * Usage of passlib The keystone server does not appear to sanitize the environment when starting. This means that an unintended value can be set for PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 4096 and potentially cause an unhandled passlib.exc.PasswordSizeError. We should ensure sensible defaults are applied here prior to loading passlib. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175905/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 10:19:17 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 10:19:17 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20151015101921.17171.16545.launchpad@chaenomeles.canonical.com> ** Changed in: heat Milestone: liberty-1 => 5.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in heat kilo series: Fix Released Status in Keystone: Fix Released Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Status in Sahara: In Progress Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 11:19:25 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 11:19:25 -0000 Subject: [Openstack-security] [Bug 1461154] Re: Cross-Frame Scripting (XFS) Clickjacking vulnerability with legacy browsers References: <20150602162757.6123.3584.malonedeb@wampee.canonical.com> Message-ID: <20151015111927.17367.18063.launchpad@chaenomeles.canonical.com> ** Changed in: horizon Milestone: liberty-2 => 8.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1461154 Title: Cross-Frame Scripting (XFS) Clickjacking vulnerability with legacy browsers Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Vulnerability Details A Cross-Frame Scripting (XFS) vulnerability can allow an attacker to load the vulnerable application inside an HTML iframe tag on a malicious page. Impact An attacker could use XFS to devise a Clickjacking attack to conduct phishing, frame sniffing, social engineering or Cross-Site Request Forgery attacks. Recommendations Set the HTTP X-Frame-Options header to one of the following: DENY - deny any frames SAMEORIGIN - frames are only allowed from the same origin ALLOW-FROM - a list of allowable origin's Although many pages within Horizon 1.1 leverage the X-Frame-Options header with the recommended SAMEORIGIN policy, some (still popular) older browsers don’t support this setting. Namely, browsers older than IE 8 and Firefox 3.6.9 don’t recognize the header and are thus vulnerable to an attack known as ClickJacking unless an additional mitigating control is present. To support legacy browsers, a suggested best practice is to add a frame breaking script to the base/global template file. Based off of https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet#Best- for-now_Legacy_Browser_Frame_Breaking_Script """ One way to defend against clickjacking is to include a "frame-breaker" script in each page that should not be framed. The following methodology will prevent a webpage from being framed even in legacy browsers, that do not support the X-Frame-Options-Header. In the document HEAD element, add the following: First apply an ID to the style element itself: And then delete that style by its ID immediately after in the script: This way, everything can be in the document HEAD and you only need one method/taglib in your API. """ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1461154/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 12:25:05 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 12:25:05 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20151015122508.10512.12365.launchpad@wampee.canonical.com> ** Changed in: neutron Milestone: liberty-2 => 7.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in neutron: Fix Released Status in neutron kilo series: Fix Released Status in OpenStack Security Advisory: Invalid Status in OpenStack Security Notes: Fix Released Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From thierry.carrez+lp at gmail.com Thu Oct 15 13:08:04 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 15 Oct 2015 13:08:04 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20151015130808.20955.85226.launchpad@gac.canonical.com> ** Changed in: manila Milestone: liberty-2 => 1.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in heat kilo series: Fix Released Status in Keystone: Fix Released Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Status in Sahara: In Progress Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1491218 at bugs.launchpad.net Thu Oct 15 15:54:18 2015 From: 1491218 at bugs.launchpad.net (Serg Melikyan) Date: Thu, 15 Oct 2015 15:54:18 -0000 Subject: [Openstack-security] [Bug 1491218] Re: [api] no checks of request tenant_id during querying service last status of an environment References: <20150902030415.8521.36980.malonedeb@wampee.canonical.com> Message-ID: <20151015155419.21087.49609.launchpad@gac.canonical.com> ** Changed in: murano Milestone: liberty-3 => 1.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1491218 Title: [api] no checks of request tenant_id during querying service last status of an environment Status in murano: Fix Released Bug description: Currently api code does not check whether a given env belongs to current requests tenant when call api /environments/{environment_id}/lastStatus. Therefore it might be possible for users from different tenants to get last services status. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1491218/+subscriptions From 1472331 at bugs.launchpad.net Thu Oct 15 15:52:39 2015 From: 1472331 at bugs.launchpad.net (Serg Melikyan) Date: Thu, 15 Oct 2015 15:52:39 -0000 Subject: [Openstack-security] [Bug 1472331] Re: Trust id is not hidden in logs References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com> Message-ID: <20151015155241.17131.24564.launchpad@soybean.canonical.com> ** Changed in: murano Milestone: liberty-2 => 1.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1472331 Title: Trust id is not hidden in logs Status in murano: Fix Released Status in murano kilo series: Fix Committed Bug description: When murano creates trustes and operates with data, contains it, the value of trust is not hidden: "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}}, "token": "*** SANITIZED ***", Need to use *** like it's done with token To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1472331/+subscriptions From 1464219 at bugs.launchpad.net Thu Oct 15 15:52:33 2015 From: 1464219 at bugs.launchpad.net (Serg Melikyan) Date: Thu, 15 Oct 2015 15:52:33 -0000 Subject: [Openstack-security] [Bug 1464219] Re: [api] there are no checks of request tenant_id during abandoning of an environment References: <20150611110620.13354.78142.malonedeb@wampee.canonical.com> Message-ID: <20151015155235.11025.77796.launchpad@wampee.canonical.com> ** Changed in: murano Milestone: liberty-2 => 1.0.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1464219 Title: [api] there are no checks of request tenant_id during abandoning of an environment Status in murano: Fix Released Bug description: Looks like the code currently does not check, that a given env belongs to current requests tenant. Therefore it might be possible for users from different tenants to delete/deploy environments. To manage notifications about this bug go to: https://bugs.launchpad.net/murano/+bug/1464219/+subscriptions From fungi at yuggoth.org Thu Oct 15 18:00:32 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 15 Oct 2015 18:00:32 -0000 Subject: [Openstack-security] [Bug 1493448] Re: All operations are perfomed with admin priveleges when 'use_user_token' is False References: <20150908163321.8816.82829.malonedeb@wampee.canonical.com> Message-ID: <20151015180032.20766.20986.malone@gac.canonical.com> I've switched this to a normal public bug with a security tag. ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1493448 Title: All operations are perfomed with admin priveleges when 'use_user_token' is False Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. In glance-api.conf we have a param called 'use_user_token' which is enabled by default. It was introduced to allow for reauthentication when tokens expire and prevents requests from silently failing. https://review.openstack.org/#/c/29967/ Unfortunately disabling this parameter leads to security issues and allows a regular user to perform any operation with admin rights. Steps to reproduce on devstack: 1. Change /etc/glance/glance-api.conf parameters and restart glance-api: # Pass the user's token through for API requests to the registry. # Default: True use_user_token = False # If 'use_user_token' is not in effect then admin credentials # can be specified. Requests to the registry on behalf of # the API will use these credentials. # Admin user name admin_user = glance # Admin password admin_password = nova # Admin tenant name admin_tenant_name = service # Keystone endpoint auth_url = http://127.0.0.1:5000/v2.0 (for v2 api it's required to enable registry service, too: data_api = glance.db.registry.api) 2. Create a private image with admin user: source openrc admin admin glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | | virtual_size | None | +------------------+--------------------------------------+ 3. Check the image list with admin user: glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 4. Enable demo user and get the image list: source openrc demo demo glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 5. Try to get access to admin's private image with demo user: glance --os-image-api-version 1 image-show private +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | +------------------+--------------------------------------+ The same happens when demo user wants to create/update/delete any image. v2 with enabled registry backend is affected too. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1493448/+subscriptions From 1490693 at bugs.launchpad.net Thu Oct 15 22:36:10 2015 From: 1490693 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 15 Oct 2015 22:36:10 -0000 Subject: [Openstack-security] [Bug 1490693] Re: session fails to sanitize response body of passwords References: <20150831192731.19704.45527.malonedeb@soybean.canonical.com> Message-ID: <20151015223610.10686.26336.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/233111 Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=ec70eb02f8a5889828cde786694283240f64c5c4 Submitter: Jenkins Branch: stable/kilo commit ec70eb02f8a5889828cde786694283240f64c5c4 Author: Matt Riedemann Date: Mon Aug 31 12:32:25 2015 -0700 Mask passwords when logging the HTTP response We should sanitize the response body before logging to make sure we aren't leaking through credentials like in the case of the response from the os-initialize_connection volume API. Closes-Bug: #1490693 NOTE(mriedem): The test is slightly different in kilo because the _http_log_response method requires kwargs. Change-Id: Ifd95d3fb624b4636fb72cc11762af62e00a026a0 (cherry picked from commit 3e26ff824801d5084791a52980021784e794e35f) ** Tags added: in-stable-kilo -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1490693 Title: session fails to sanitize response body of passwords Status in python-keystoneclient: Fix Released Bug description: Seeing this in the n-cpu logs when nova calls the os- initialize_connection API via python-cinderclient and cinder returns a response body with credentials in it: http://logs.openstack.org/66/218666/1/check/gate-tempest-dsvm- full/3ac1f2b/logs/screen-n-cpu.txt.gz#_2015-08-30_16_33_09_578 keystoneclient.session is logging the response body without sanitizing it first. 2015-08-30 16:33:09.578 DEBUG keystoneclient.session [req-ff63c358-41b0-4aac-8d8c-e369d82a0d5e tempest-TestMinimumBasicScenario-472140388 tempest-TestMinimumBasicScenario-192291337] REQ: curl -g -i -X POST http://127.0.0.1:8776/v2/8a98625b8c5445afbc72496ce2f7ab7f/volumes/744d2085-8e78-40a5-8659-ef3cffb2480e/action -H "User-Agent: python-cinderclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}fbdcb6c88ebb8ec83181b62e338a1a4b909f7031" -d '{"os-initialize_connection": {"connector": {"initiator": "iqn.1993-08.org.debian:01:f991bccc0", "ip": "172.99.69.228", "platform": "x86_64", "host": "devstack-trusty-rax-iad-4640004", "os_type": "linux2", "multipath": false}}}' _http_log_request /usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:195 2015-08-30 16:33:10.674 DEBUG keystoneclient.session [req-ff63c358-41b0-4aac-8d8c-e369d82a0d5e tempest-TestMinimumBasicScenario-472140388 tempest-TestMinimumBasicScenario-192291337] RESP: [200] content-length: 447 x-compute-request-id: req-747a68eb-f62e-4a43-aa8a-ff332c92783d connection: keep-alive date: Sun, 30 Aug 2015 16:33:10 GMT content-type: application/json x-openstack-request-id: req-747a68eb-f62e-4a43-aa8a-ff332c92783d RESP BODY: {"connection_info": {"driver_volume_type": "iscsi", "data": {"auth_password": "FF5vCvAvks8iQ2Vx", "target_discovered": false, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-744d2085-8e78-40a5-8659-ef3cffb2480e", "target_portal": "172.99.69.228:3260", "volume_id": "744d2085-8e78-40a5-8659-ef3cffb2480e", "target_lun": 1, "access_mode": "rw", "auth_username": "82tvLceDnfHjg6jrTwpq", "auth_method": "CHAP"}}} To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1490693/+subscriptions From 1361360 at bugs.launchpad.net Fri Oct 16 17:20:19 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 16 Oct 2015 17:20:19 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20151016172019.18010.13726.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/231989 Committed: https://git.openstack.org/cgit/openstack/sahara/commit/?id=64583e4b839d96e2cbe7dcba7d0f08852b40bcca Submitter: Jenkins Branch: master commit 64583e4b839d96e2cbe7dcba7d0f08852b40bcca Author: Sergey Reshetnyak Date: Wed Oct 7 16:24:35 2015 +0300 Use api-paste.ini for loading middleware Changes: * use api-paste.ini config for loading middleware * refactoring middlewares to support loading via pastedeploy * use debug middleware from oslo_middleware library instead log_exchange middleware Closes-bug: #1503983 Closes-bug: #1361360 Change-Id: I444c1799ef53dbb19a601e51dd95cd8509fb1c0c ** Changed in: sahara 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/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in Glance: Fix Released Status in Glance icehouse series: Fix Committed Status in heat: Fix Released Status in heat kilo series: Fix Released Status in Keystone: Fix Released Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in Manila: Fix Released Status in neutron: Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Status in Sahara: Fix Committed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From dstanek at dstanek.com Fri Oct 16 17:46:43 2015 From: dstanek at dstanek.com (David Stanek) Date: Fri, 16 Oct 2015 17:46:43 -0000 Subject: [Openstack-security] [Bug 1499555] Re: You can crash keystone or make the DB very slow by assigning many roles References: <20150924232400.8965.55797.malonedeb@gac.canonical.com> Message-ID: <20151016174643.10791.59638.malone@wampee.canonical.com> Does this make all of Keystone slow or just the creating the token for the user with that many roles? This also you can't just do this to an arbitrary cloud unless they relax the default policy of who can create roles. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in Keystone: Triaged Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB    Say user is U, and Project is P    for i =1 to 1000 ( or any large number)         role x = create role i with some large name         assign role x for user U and Project P        create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions From fungi at yuggoth.org Fri Oct 16 18:03:37 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 16 Oct 2015 18:03:37 -0000 Subject: [Openstack-security] [Bug 1499555] Re: You can crash keystone or make the DB very slow by assigning many roles References: <20150924232400.8965.55797.malonedeb@gac.canonical.com> Message-ID: <20151016180337.17563.37615.malone@soybean.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. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in Keystone: Triaged Status in OpenStack Security Advisory: Incomplete Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB    Say user is U, and Project is P    for i =1 to 1000 ( or any large number)         role x = create role i with some large name         assign role x for user U and Project P        create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions From 1499555 at bugs.launchpad.net Fri Oct 16 23:02:42 2015 From: 1499555 at bugs.launchpad.net (Haneef Ali) Date: Fri, 16 Oct 2015 23:02:42 -0000 Subject: [Openstack-security] [Bug 1499555] Re: You can crash keystone or make the DB very slow by assigning many roles References: <20150924232400.8965.55797.malonedeb@gac.canonical.com> Message-ID: <20151016230242.20704.28529.malone@gac.canonical.com> This is not the question about permission issue. Basically keystone is having an unbounded list in the backend which can be exploited by the user. All we need is a simple conf value to guard against such exploitation. e.g max roles that can be added to a user = (50). This itself is too much, but it is better than infinity -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in Keystone: Triaged Status in OpenStack Security Advisory: Incomplete Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB    Say user is U, and Project is P    for i =1 to 1000 ( or any large number)         role x = create role i with some large name         assign role x for user U and Project P        create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions From gerrit2 at review.openstack.org Mon Oct 19 12:26:01 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 19 Oct 2015 12:26:01 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idbe37922c5f944e3d567ce16913ce5d87af41fef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141485 Log: commit 588442e78c867d092048b80745d0bf314b25a611 Author: Joel Coffman Date: Mon Oct 19 08:25:18 2015 -0400 libvirt: Disconnect dm-crypt on instance suspend/stop Strengthens protection provided by ephemeral storage encryption feature by disconnecting the dm-crypt device, which provides access to unencrypted disk, when an encrypted instance is suspended or stopped. Co-Authored-By: Joel Coffman Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From gerrit2 at review.openstack.org Mon Oct 19 12:27:24 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 19 Oct 2015 12:27:24 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idbe37922c5f944e3d567ce16913ce5d87af41fef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141485 Log: commit dcc7471ba941809dbb0f201f5283ab7984f99418 Author: Joel Coffman Date: Mon Oct 19 08:25:18 2015 -0400 libvirt: Disconnect dm-crypt on instance suspend/stop Strengthens protection provided by ephemeral storage encryption feature by disconnecting the dm-crypt device, which provides access to unencrypted disk, when an encrypted instance is suspended or stopped. Co-Authored-By: Joel Coffman Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From gerrit2 at review.openstack.org Tue Oct 20 16:51:13 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 20 Oct 2015 16:51:13 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change If143638a5ae21068c062048dc6e5e91b31cd524f Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/232371 Log: commit 7568576c624dc84f0ff06d453ab98b274ae32765 Author: bria4010 Date: Thu Oct 8 02:59:21 2015 -0400 Image Import Refactor This spec is intended to serve as the basis for the discussion on refactoring the Glance image import functionality at the Mitka summit. ApiImpact DocImpact SecurityImpact Change-Id: If143638a5ae21068c062048dc6e5e91b31cd524f Implements: blueprint image-import-refactor From 1490693 at bugs.launchpad.net Tue Oct 20 18:21:57 2015 From: 1490693 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 20 Oct 2015 18:21:57 -0000 Subject: [Openstack-security] [Bug 1490693] Change abandoned on python-keystoneclient (feature/keystoneauth_integration) References: <20150831192731.19704.45527.malonedeb@soybean.canonical.com> Message-ID: <20151020182158.5478.21192.malone@chaenomeles.canonical.com> Change abandoned by Steve Martinelli (stevemar at ca.ibm.com) on branch: feature/keystoneauth_integration Review: https://review.openstack.org/218269 Reason: need to abandon in order to delete branch -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1490693 Title: session fails to sanitize response body of passwords Status in python-keystoneclient: Fix Released Bug description: Seeing this in the n-cpu logs when nova calls the os- initialize_connection API via python-cinderclient and cinder returns a response body with credentials in it: http://logs.openstack.org/66/218666/1/check/gate-tempest-dsvm- full/3ac1f2b/logs/screen-n-cpu.txt.gz#_2015-08-30_16_33_09_578 keystoneclient.session is logging the response body without sanitizing it first. 2015-08-30 16:33:09.578 DEBUG keystoneclient.session [req-ff63c358-41b0-4aac-8d8c-e369d82a0d5e tempest-TestMinimumBasicScenario-472140388 tempest-TestMinimumBasicScenario-192291337] REQ: curl -g -i -X POST http://127.0.0.1:8776/v2/8a98625b8c5445afbc72496ce2f7ab7f/volumes/744d2085-8e78-40a5-8659-ef3cffb2480e/action -H "User-Agent: python-cinderclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}fbdcb6c88ebb8ec83181b62e338a1a4b909f7031" -d '{"os-initialize_connection": {"connector": {"initiator": "iqn.1993-08.org.debian:01:f991bccc0", "ip": "172.99.69.228", "platform": "x86_64", "host": "devstack-trusty-rax-iad-4640004", "os_type": "linux2", "multipath": false}}}' _http_log_request /usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:195 2015-08-30 16:33:10.674 DEBUG keystoneclient.session [req-ff63c358-41b0-4aac-8d8c-e369d82a0d5e tempest-TestMinimumBasicScenario-472140388 tempest-TestMinimumBasicScenario-192291337] RESP: [200] content-length: 447 x-compute-request-id: req-747a68eb-f62e-4a43-aa8a-ff332c92783d connection: keep-alive date: Sun, 30 Aug 2015 16:33:10 GMT content-type: application/json x-openstack-request-id: req-747a68eb-f62e-4a43-aa8a-ff332c92783d RESP BODY: {"connection_info": {"driver_volume_type": "iscsi", "data": {"auth_password": "FF5vCvAvks8iQ2Vx", "target_discovered": false, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-744d2085-8e78-40a5-8659-ef3cffb2480e", "target_portal": "172.99.69.228:3260", "volume_id": "744d2085-8e78-40a5-8659-ef3cffb2480e", "target_lun": 1, "access_mode": "rw", "auth_username": "82tvLceDnfHjg6jrTwpq", "auth_method": "CHAP"}}} To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1490693/+subscriptions From 1493448 at bugs.launchpad.net Tue Oct 20 18:59:14 2015 From: 1493448 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 20 Oct 2015 18:59:14 -0000 Subject: [Openstack-security] [Bug 1493448] Related fix proposed to glance (master) References: <20150908163321.8816.82829.malonedeb@wampee.canonical.com> Message-ID: <20151020185914.13081.11144.malone@soybean.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/237742 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1493448 Title: All operations are perfomed with admin priveleges when 'use_user_token' is False Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. In glance-api.conf we have a param called 'use_user_token' which is enabled by default. It was introduced to allow for reauthentication when tokens expire and prevents requests from silently failing. https://review.openstack.org/#/c/29967/ Unfortunately disabling this parameter leads to security issues and allows a regular user to perform any operation with admin rights. Steps to reproduce on devstack: 1. Change /etc/glance/glance-api.conf parameters and restart glance-api: # Pass the user's token through for API requests to the registry. # Default: True use_user_token = False # If 'use_user_token' is not in effect then admin credentials # can be specified. Requests to the registry on behalf of # the API will use these credentials. # Admin user name admin_user = glance # Admin password admin_password = nova # Admin tenant name admin_tenant_name = service # Keystone endpoint auth_url = http://127.0.0.1:5000/v2.0 (for v2 api it's required to enable registry service, too: data_api = glance.db.registry.api) 2. Create a private image with admin user: source openrc admin admin glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | | virtual_size | None | +------------------+--------------------------------------+ 3. Check the image list with admin user: glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 4. Enable demo user and get the image list: source openrc demo demo glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 5. Try to get access to admin's private image with demo user: glance --os-image-api-version 1 image-show private +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | +------------------+--------------------------------------+ The same happens when demo user wants to create/update/delete any image. v2 with enabled registry backend is affected too. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1493448/+subscriptions From ian.cordasco at rackspace.com Tue Oct 20 19:20:39 2015 From: ian.cordasco at rackspace.com (Ian Cordasco) Date: Tue, 20 Oct 2015 19:20:39 -0000 Subject: [Openstack-security] [Bug 1493448] Re: All operations are perfomed with admin priveleges when 'use_user_token' is False References: <20150908163321.8816.82829.malonedeb@wampee.canonical.com> Message-ID: <20151020192040.4054.97262.launchpad@wampee.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. - In glance-api.conf we have a param called 'use_user_token' which is enabled by default. It was introduced to allow for reauthentication when tokens expire and prevents requests from silently failing. https://review.openstack.org/#/c/29967/ Unfortunately disabling this parameter leads to security issues and allows a regular user to perform any operation with admin rights. Steps to reproduce on devstack: 1. Change /etc/glance/glance-api.conf parameters and restart glance-api: # Pass the user's token through for API requests to the registry. # Default: True use_user_token = False # If 'use_user_token' is not in effect then admin credentials # can be specified. Requests to the registry on behalf of # the API will use these credentials. # Admin user name admin_user = glance # Admin password admin_password = nova # Admin tenant name admin_tenant_name = service # Keystone endpoint auth_url = http://127.0.0.1:5000/v2.0 (for v2 api it's required to enable registry service, too: data_api = glance.db.registry.api) 2. Create a private image with admin user: source openrc admin admin glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | | virtual_size | None | +------------------+--------------------------------------+ 3. Check the image list with admin user: glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 4. Enable demo user and get the image list: source openrc demo demo glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 5. Try to get access to admin's private image with demo user: glance --os-image-api-version 1 image-show private +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | +------------------+--------------------------------------+ The same happens when demo user wants to create/update/delete any image. v2 with enabled registry backend is affected too. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1493448 Title: All operations are perfomed with admin priveleges when 'use_user_token' is False Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: In glance-api.conf we have a param called 'use_user_token' which is enabled by default. It was introduced to allow for reauthentication when tokens expire and prevents requests from silently failing. https://review.openstack.org/#/c/29967/ Unfortunately disabling this parameter leads to security issues and allows a regular user to perform any operation with admin rights. Steps to reproduce on devstack: 1. Change /etc/glance/glance-api.conf parameters and restart glance-api: # Pass the user's token through for API requests to the registry. # Default: True use_user_token = False # If 'use_user_token' is not in effect then admin credentials # can be specified. Requests to the registry on behalf of # the API will use these credentials. # Admin user name admin_user = glance # Admin password admin_password = nova # Admin tenant name admin_tenant_name = service # Keystone endpoint auth_url = http://127.0.0.1:5000/v2.0 (for v2 api it's required to enable registry service, too: data_api = glance.db.registry.api) 2. Create a private image with admin user: source openrc admin admin glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | | virtual_size | None | +------------------+--------------------------------------+ 3. Check the image list with admin user: glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 4. Enable demo user and get the image list: source openrc demo demo glance --os-image-api-version 1 image-list +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active | | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active | | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active | | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active | +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+ 5. Try to get access to admin's private image with demo user: glance --os-image-api-version 1 image-show private +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | e533283e6aac072533d1d091a7d2e413 | | container_format | bare | | created_at | 2015-09-01T22:17:25.000000 | | deleted | False | | disk_format | qcow2 | | id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | | is_public | False | | min_disk | 0 | | min_ram | 0 | | name | private | | owner | e1cec705e33b4dfaaece11b623f3c680 | | protected | False | | size | 616 | | status | active | | updated_at | 2015-09-01T22:17:27.000000 | +------------------+--------------------------------------+ The same happens when demo user wants to create/update/delete any image. v2 with enabled registry backend is affected too. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1493448/+subscriptions From fungi at yuggoth.org Tue Oct 20 22:52:49 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 20 Oct 2015 22:52:49 -0000 Subject: [Openstack-security] [Bug 1506419] Re: Running Flask server in debug mode may be a security issue References: <20151015104156.20843.43715.malonedeb@gac.canonical.com> Message-ID: <20151020225249.3478.62246.malone@gac.canonical.com> Added a "won't fix" security advisory task for this and marked it as a hardening opportunity (class D in https://security.openstack.org/vmt- process.html#incident-report-taxonomy ) due to being an sensitive information disclosure occurring only in DEBUG level logs. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Won't Fix ** 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/1506419 Title: Running Flask server in debug mode may be a security issue Status in Ironic Inspector: Fix Committed Status in Ironic Inspector liberty series: Fix Committed Status in Ironic Inspector mitaka series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: A lot of people default to running their servers in debug mode. While handy for getting the full logs, in our case it will also allow access to Flask console, which may pose a security risk. We need a separate option for this. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic-inspector/+bug/1506419/+subscriptions From fungi at yuggoth.org Wed Oct 21 01:00:20 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 21 Oct 2015 01:00:20 -0000 Subject: [Openstack-security] [Bug 1506419] Re: Running Flask server in debug mode may be a security issue References: <20151015104156.20843.43715.malonedeb@gac.canonical.com> Message-ID: <20151021010020.12936.91966.malone@soybean.canonical.com> Sorry, as Garth Mollett pointed out to me via E-mail, this is not simply an information disclosure but instead a backdoor. Probably the closest prior report I've seen is bug 1425206. Though also, Ironic is not currently under OpenStack VMT oversight[*], so take this as guidance for how I would have classified it were that not actually the case. [*] http://governance.openstack.org/reference/tags/vulnerability_managed.html -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1506419 Title: Running Flask server in debug mode may be a security issue Status in Ironic Inspector: Fix Committed Status in Ironic Inspector liberty series: Fix Committed Status in Ironic Inspector mitaka series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: A lot of people default to running their servers in debug mode. While handy for getting the full logs, in our case it will also allow access to Flask console, which may pose a security risk. We need a separate option for this. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic-inspector/+bug/1506419/+subscriptions From gmollett at redhat.com Wed Oct 21 01:32:29 2015 From: gmollett at redhat.com (Garth Mollett) Date: Wed, 21 Oct 2015 01:32:29 -0000 Subject: [Openstack-security] [Bug 1506419] Re: Running Flask server in debug mode may be a security issue References: <20151015104156.20843.43715.malonedeb@gac.canonical.com> Message-ID: <20151021013229.13373.6826.malone@soybean.canonical.com> CVE-2015-5306 OpenStack Ironic: Potential remote code execution with debug mode enabled. Has been assigned to this issue. ** CVE added: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2015-5306 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1506419 Title: Running Flask server in debug mode may be a security issue Status in Ironic Inspector: Fix Committed Status in Ironic Inspector liberty series: Fix Committed Status in Ironic Inspector mitaka series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: A lot of people default to running their servers in debug mode. While handy for getting the full logs, in our case it will also allow access to Flask console, which may pose a security risk. We need a separate option for this. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic-inspector/+bug/1506419/+subscriptions From michael.xin at RACKSPACE.COM Wed Oct 21 07:56:43 2015 From: michael.xin at RACKSPACE.COM (Michael Xin) Date: Wed, 21 Oct 2015 07:56:43 +0000 Subject: [Openstack-security] The first version of the Logo for Openstack security project In-Reply-To: References: Message-ID: Hi, guys: Thanks for your help. We are designing a logo and a flyer for Openstack Security Project. Rachel helped us with the task. Attached is her first version of the logo. Please send us your feedback. http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png Thanks and have a great day. Yours, Michael ----------------------------------------------------------------------------- Michael Xin | Manager, Security Engineering - US Product Security |Rackspace Hosting Office #: 501-7341 or 210-312-7341 Mobile #: 210-284-8674 5000 Walzem Road, San Antonio, Tx 78218 ---------------------------------------------------------------------------- Experience fanatical support -------------- next part -------------- An HTML attachment was scrubbed... URL: From lexuns at gmail.com Mon Oct 19 23:42:29 2015 From: lexuns at gmail.com (Tong Liu) Date: Mon, 19 Oct 2015 23:42:29 -0000 Subject: [Openstack-security] [Bug 1507815] [NEW] Security group is dropping DHCP packet Message-ID: <20151019234229.4089.28458.malonedeb@wampee.canonical.com> Public bug reported: The instances launched are not able to get IP addresses because the DHCP packet are dropped by security group. If we open up OS default Block all, instances are able to acquire IP addresses. I saw we only allow DHCP-Client packet in the OS default section. But I believe we should also allow DHCP-Server. ** Affects: vmware-nsx Importance: Undecided Status: New ** Tags: group liberty security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1507815 Title: Security group is dropping DHCP packet Status in vmware-nsx: New Bug description: The instances launched are not able to get IP addresses because the DHCP packet are dropped by security group. If we open up OS default Block all, instances are able to acquire IP addresses. I saw we only allow DHCP-Client packet in the OS default section. But I believe we should also allow DHCP-Server. To manage notifications about this bug go to: https://bugs.launchpad.net/vmware-nsx/+bug/1507815/+subscriptions From michael.xin at RACKSPACE.COM Wed Oct 21 07:09:56 2015 From: michael.xin at RACKSPACE.COM (Michael Xin) Date: Wed, 21 Oct 2015 07:09:56 +0000 Subject: [Openstack-security] The first version of the Logo for Openstack security project Message-ID: Hi, guys: Thanks for your help. We want to design a logo and a flyer for Openstack Security Project. Rachel helped us with the task. Attached is her first version of the logo. Please send us your feedback. http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png Thanks and have a great day. Yours, Michael ----------------------------------------------------------------------------- Michael Xin | Manager, Security Engineering - US Product Security |Rackspace Hosting Office #: 501-7341 or 210-312-7341 Mobile #: 210-284-8674 5000 Walzem Road, San Antonio, Tx 78218 ---------------------------------------------------------------------------- Experience fanatical support -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: os-security-project-logo.png Type: image/png Size: 545514 bytes Desc: os-security-project-logo.png URL: From tim.kelsey at hpe.com Wed Oct 21 08:05:51 2015 From: tim.kelsey at hpe.com (Kelsey, Timothy John) Date: Wed, 21 Oct 2015 08:05:51 +0000 Subject: [Openstack-security] The first version of the Logo for Openstack security project In-Reply-To: References: Message-ID: I really like this! thanks for making it Rachel and thanks for taking this on Michael. I hope you don’t mind but I have made one very small tweak to the original, the shape of the padlock bar was just getting to me :P A very crude mockup can be found here: https://www.dropbox.com/s/z18dcw5xm4qes8w/logo-tweak.png?dl=0 Of course, a real graphics designer like Rachel would need to make the actual change if people think it is worth it. Many thanks! -- Tim Kelsey Cloud Security Engineer HP Helion From: Michael Xin > Date: Wednesday, 21 October 2015 08:56 To: "openstack-security at lists.openstack.org" > Cc: Rachel Grahmann > Subject: [Openstack-security] The first version of the Logo for Openstack security project Hi, guys: Thanks for your help. We are designing a logo and a flyer for Openstack Security Project. Rachel helped us with the task. Attached is her first version of the logo. Please send us your feedback. http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png Thanks and have a great day. Yours, Michael ----------------------------------------------------------------------------- Michael Xin | Manager, Security Engineering - US Product Security |Rackspace Hosting Office #: 501-7341 or 210-312-7341 Mobile #: 210-284-8674 5000 Walzem Road, San Antonio, Tx 78218 ---------------------------------------------------------------------------- Experience fanatical support From robert.clark at hpe.com Wed Oct 21 08:48:33 2015 From: robert.clark at hpe.com (Clark, Robert Graham) Date: Wed, 21 Oct 2015 08:48:33 +0000 Subject: [Openstack-security] The first version of the Logo for Openstack security project In-Reply-To: References: Message-ID: These look good, I'm not sure that we can use any likeness of the OpenStack logo though - I seem to remember this coming up a long time ago. Thierry knows all things OpenStack (or at least who we should go bug) so I've added him to this thread for clarification: Thierry, who would we need to get permission from (if possible) to have a logo like the ones linked in this thread? -Rob > -----Original Message----- > From: Kelsey, Timothy John > Sent: 21 October 2015 09:06 > To: Michael Xin; openstack-security at lists.openstack.org > Cc: Rachel Grahmann > Subject: Re: [Openstack-security] The first version of the Logo for Openstack security project > > I really like this! thanks for making it Rachel and thanks for taking this on Michael. I hope you don't mind but I have made one very small > tweak to the original, the shape of the padlock bar was just getting to me :P > > A very crude mockup can be found here: https://www.dropbox.com/s/z18dcw5xm4qes8w/logo-tweak.png?dl=0 > Of course, a real graphics designer like Rachel would need to make the actual change if people think it is worth it. > > Many thanks! > > -- > Tim Kelsey > Cloud Security Engineer > HP Helion > > From: Michael Xin > > Date: Wednesday, 21 October 2015 08:56 > To: "openstack-security at lists.openstack.org" security at lists.openstack.org> > Cc: Rachel Grahmann > > Subject: [Openstack-security] The first version of the Logo for Openstack security project > > > Hi, guys: > Thanks for your help. We are designing a logo and a flyer for Openstack Security Project. Rachel helped us with the task. Attached is her first > version of the logo. Please send us your feedback. > > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png > Thanks and have a great day. > > Yours, > Michael > > ----------------------------------------------------------------------------- > Michael Xin | Manager, Security Engineering - US > Product Security |Rackspace Hosting > Office #: 501-7341 or 210-312-7341 > Mobile #: 210-284-8674 > 5000 Walzem Road, San Antonio, Tx 78218 > ---------------------------------------------------------------------------- > Experience fanatical support > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From 1506419 at bugs.launchpad.net Wed Oct 21 11:57:20 2015 From: 1506419 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 21 Oct 2015 11:57:20 -0000 Subject: [Openstack-security] [Bug 1506419] Fix proposed to ironic-inspector (stable/1.1) References: <20151015104156.20843.43715.malonedeb@gac.canonical.com> Message-ID: <20151021115720.3617.59694.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/1.1 Review: https://review.openstack.org/238007 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1506419 Title: Running Flask server in debug mode may be a security issue Status in Ironic Inspector: Fix Committed Status in Ironic Inspector kilo series: In Progress Status in Ironic Inspector liberty series: Fix Released Status in Ironic Inspector mitaka series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: A lot of people default to running their servers in debug mode. While handy for getting the full logs, in our case it will also allow access to Flask console, which may pose a security risk. We need a separate option for this. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic-inspector/+bug/1506419/+subscriptions From 1506419 at bugs.launchpad.net Wed Oct 21 12:14:47 2015 From: 1506419 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 21 Oct 2015 12:14:47 -0000 Subject: [Openstack-security] [Bug 1506419] Fix merged to ironic-inspector (stable/1.1) References: <20151015104156.20843.43715.malonedeb@gac.canonical.com> Message-ID: <20151021121448.30338.33039.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/238007 Committed: https://git.openstack.org/cgit/openstack/ironic-inspector/commit/?id=7ca56201897d8288b1acaafeccd9469840f73dcf Submitter: Jenkins Branch: stable/1.1 commit 7ca56201897d8288b1acaafeccd9469840f73dcf Author: Dmitry Tantsur Date: Wed Oct 21 13:56:34 2015 +0200 Never run Flask in debug mode, it poses a security risk Change-Id: I0c0c192bc75f42cfb070059f1764a0837ae956bb Closes-Bug: #1506419 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1506419 Title: Running Flask server in debug mode may be a security issue Status in Ironic Inspector: Fix Committed Status in Ironic Inspector kilo series: Fix Committed Status in Ironic Inspector liberty series: Fix Released Status in Ironic Inspector mitaka series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Bug description: A lot of people default to running their servers in debug mode. While handy for getting the full logs, in our case it will also allow access to Flask console, which may pose a security risk. We need a separate option for this. To manage notifications about this bug go to: https://bugs.launchpad.net/ironic-inspector/+bug/1506419/+subscriptions From matt at nycresistor.com Wed Oct 21 13:10:13 2015 From: matt at nycresistor.com (matt) Date: Wed, 21 Oct 2015 09:10:13 -0400 Subject: [Openstack-security] The first version of the Logo for Openstack security project In-Reply-To: References: Message-ID: made these years ago for a blog that never went anywhere: http://surly.bike/secstack-header2.jpg http://surly.bike/secstack-header1.jpg looks good! -Matt On Wed, Oct 21, 2015 at 4:48 AM, Clark, Robert Graham wrote: > These look good, I'm not sure that we can use any likeness of the > OpenStack logo though - I seem to remember this coming up a long time ago. > > Thierry knows all things OpenStack (or at least who we should go bug) so > I've added him to this thread for clarification: Thierry, who would we need > to get permission from (if possible) to have a logo like the ones linked in > this thread? > > -Rob > > > -----Original Message----- > > From: Kelsey, Timothy John > > Sent: 21 October 2015 09:06 > > To: Michael Xin; openstack-security at lists.openstack.org > > Cc: Rachel Grahmann > > Subject: Re: [Openstack-security] The first version of the Logo for > Openstack security project > > > > I really like this! thanks for making it Rachel and thanks for taking > this on Michael. I hope you don't mind but I have made one very small > > tweak to the original, the shape of the padlock bar was just getting to > me :P > > > > A very crude mockup can be found here: > https://www.dropbox.com/s/z18dcw5xm4qes8w/logo-tweak.png?dl=0 > > Of course, a real graphics designer like Rachel would need to make the > actual change if people think it is worth it. > > > > Many thanks! > > > > -- > > Tim Kelsey > > Cloud Security Engineer > > HP Helion > > > > From: Michael Xin michael.xin at RACKSPACE.COM>> > > Date: Wednesday, 21 October 2015 08:56 > > To: "openstack-security at lists.openstack.org openstack-security at lists.openstack.org>" > security at lists.openstack.org openstack-security at lists.openstack.org>> > > Cc: Rachel Grahmann rachel.grahmann at RACKSPACE.COM>> > > Subject: [Openstack-security] The first version of the Logo for > Openstack security project > > > > > > Hi, guys: > > Thanks for your help. We are designing a logo and a flyer for Openstack > Security Project. Rachel helped us with the task. Attached is her first > > version of the logo. Please send us your feedback. > > > > > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png > > Thanks and have a great day. > > > > Yours, > > Michael > > > > > ----------------------------------------------------------------------------- > > Michael Xin | Manager, Security Engineering - US > > Product Security |Rackspace Hosting > > Office #: 501-7341 or 210-312-7341 > > Mobile #: 210-284-8674 > > 5000 Walzem Road, San Antonio, Tx 78218 > > > ---------------------------------------------------------------------------- > > Experience fanatical support > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.neill at RACKSPACE.COM Wed Oct 21 15:49:18 2015 From: charles.neill at RACKSPACE.COM (Charles Neill) Date: Wed, 21 Oct 2015 15:49:18 +0000 Subject: [Openstack-security] The first version of the Logo for Openstack security project In-Reply-To: Message-ID: My vote is for the lock (though the pirate flag is undeniably awesome). Funnily enough, I tried to make basically the exact same thing (OpenStack logo + lock) but failed miserably, so hats off to you, Rachel! Thanks for helping us out with this. Cheers, Charles Neill - Software Security Engineer ------------------------------------------------ 9001 N. IH 35 #150 Office: 210.312.5560 Austin, TX 78753 Cell: 210.897.1058 ------------------------------------------------ Rackspace Hosting - The #1 Managed Cloud Company From: matt > Date: Wednesday, October 21, 2015 at 8:10 AM To: "Clark, Robert Graham" > Cc: "openstack-security at lists.openstack.org" >, Rachel Grahmann >, "Kelsey, Timothy John" >, "Thierry Carrez (thierry at openstack.org)" > Subject: Re: [Openstack-security] The first version of the Logo for Openstack security project made these years ago for a blog that never went anywhere: http://surly.bike/secstack-header2.jpg http://surly.bike/secstack-header1.jpg looks good! -Matt On Wed, Oct 21, 2015 at 4:48 AM, Clark, Robert Graham > wrote: These look good, I'm not sure that we can use any likeness of the OpenStack logo though - I seem to remember this coming up a long time ago. Thierry knows all things OpenStack (or at least who we should go bug) so I've added him to this thread for clarification: Thierry, who would we need to get permission from (if possible) to have a logo like the ones linked in this thread? -Rob > -----Original Message----- > From: Kelsey, Timothy John > Sent: 21 October 2015 09:06 > To: Michael Xin; openstack-security at lists.openstack.org > Cc: Rachel Grahmann > Subject: Re: [Openstack-security] The first version of the Logo for Openstack security project > > I really like this! thanks for making it Rachel and thanks for taking this on Michael. I hope you don't mind but I have made one very small > tweak to the original, the shape of the padlock bar was just getting to me :P > > A very crude mockup can be found here: https://www.dropbox.com/s/z18dcw5xm4qes8w/logo-tweak.png?dl=0 > Of course, a real graphics designer like Rachel would need to make the actual change if people think it is worth it. > > Many thanks! > > -- > Tim Kelsey > Cloud Security Engineer > HP Helion > > From: Michael Xin >> > Date: Wednesday, 21 October 2015 08:56 > To: "openstack-security at lists.openstack.org>" security at lists.openstack.org>> > Cc: Rachel Grahmann >> > Subject: [Openstack-security] The first version of the Logo for Openstack security project > > > Hi, guys: > Thanks for your help. We are designing a logo and a flyer for Openstack Security Project. Rachel helped us with the task. Attached is her first > version of the logo. Please send us your feedback. > > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png > Thanks and have a great day. > > Yours, > Michael > > ----------------------------------------------------------------------------- > Michael Xin | Manager, Security Engineering - US > Product Security |Rackspace Hosting > Office #: 501-7341 or 210-312-7341 > Mobile #: 210-284-8674 > 5000 Walzem Road, San Antonio, Tx 78218 > ---------------------------------------------------------------------------- > Experience fanatical support > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.xin at RACKSPACE.COM Wed Oct 21 16:21:31 2015 From: michael.xin at RACKSPACE.COM (Michael Xin) Date: Wed, 21 Oct 2015 16:21:31 +0000 Subject: [Openstack-security] Fw: help us design flyer and logo for OpenStack Security Project In-Reply-To: <5b4ec42f66f24d09949a13899b0f5247@RACKSPACE.COM> References: <0a5d2dcc0b5945f686b63721d76a9bb3@RACKSPACE.COM> <4dee3d9f42284988ab10d751b2dc4a21@RACKSPACE.COM> <34118647267d4515bd3aa92d9a28a5fb@RACKSPACE.COM> , , <5b4ec42f66f24d09949a13899b0f5247@RACKSPACE.COM> Message-ID: hi, all: Is it ok for us to use official OpenStack logo during our design? I think it is ok. But want to double check. Thanks. yours, Michael ________________________________ From: Rachel Grahmann Sent: Wednesday, October 21, 2015 11:08 AM To: Michael Xin Subject: Re: help us design flyer and logo for OpenStack Security Project Hey Michael, Thanks so much for forwarding these! I would like to find out if using the OpenStack logo is allowed before making final edits -- just in case it's not! Then we can go back to the drawing board or use a variation of the pirate banner (very cool!). As far as the feedback goes -- great stuff! I'll gladly change the padlock bar like Tim suggested. Keep me posted! Rachel -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Oct 21 17:14:33 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 21 Oct 2015 17:14:33 +0000 Subject: [Openstack-security] Fw: help us design flyer and logo for OpenStack Security Project In-Reply-To: References: <4dee3d9f42284988ab10d751b2dc4a21@RACKSPACE.COM> <34118647267d4515bd3aa92d9a28a5fb@RACKSPACE.COM> <5b4ec42f66f24d09949a13899b0f5247@RACKSPACE.COM> Message-ID: <20151021171433.GI4731@yuggoth.org> On 2015-10-21 16:21:31 +0000 (+0000), Michael Xin wrote: > Is it ok for us to use official OpenStack logo during our design? > I think it is ok. But want to double check. I know displaying modified OpenStack logos is generally discouraged because it can lead to trademark dilution, though I don't know to what extent it's possible to get specific modifications cleared for certain uses. I've asked some OpenStack Foundation staff (with a much better grasp of the details than I have) to weigh in on this, but it may take time since they're all fairly busy preparing for some conference in Tokyo next week. ;) -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: Digital signature URL: From michael.xin at RACKSPACE.COM Wed Oct 21 21:11:22 2015 From: michael.xin at RACKSPACE.COM (Michael Xin) Date: Wed, 21 Oct 2015 21:11:22 +0000 Subject: [Openstack-security] [openstack-dev] [security] The first version of the Logo for Openstack Security Project In-Reply-To: References: <5627BCE3.3020309@redhat.com> Message-ID: Rob and Michael: Thanks for the update. We will probably not use any Openstack Logo. Here is the first draft of the flyer: http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf Please send us your feedback. Yours, Michael On 10/21/15, 11:32 AM, "Clark, Robert Graham" wrote: >I had looped some people into a previous version of the thread but they've not replied yet. > >I think we ran into this problem before and got a firm "maybe, depending on what it is" from the powers-that-be. > >Perhaps we should look at a rough-draft alternative logo while we await a verdict? > >> -----Original Message----- >> From: michael mccune [mailto:msm at redhat.com] >> Sent: 21 October 2015 17:27 >> To: openstack-dev at lists.openstack.org >> Subject: Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project >> >> On 10/21/2015 03:54 AM, Michael Xin wrote: >> > Hi, guys: >> > Thanks for your help. We are designing a logo and a flyer for Openstack >> > Security Project. Rachel helped us with the task. Attached is her first >> > version of the logo. Please let us know your feedback. >> > >> > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png >> > Thanks and have a great day. >> >> hi Michael, thanks to Rachel for putting this together. i like the >> general concept of the openstack logo as a lock. i think the "lock >> parts" could have a little more depth on them. >> >> you had asked in irc about usage of the openstack logo, i'm not sure. >> but this page, https://www.openstack.org/brand/openstack-logo/ , seems >> to indicate that the usage is pretty limited. in specific, this section >> "You agree that you will not (i) alter or modify the OpenStack Logo as >> provided by the OpenStack Foundation; " seems to indicate that we may >> not be able to use the logo like this. we should probably ask someone >> from the foundation. >> >> all in all though, a nice effort. many thanks =) >> >> mike >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From heidijoy at openstack.org Wed Oct 21 21:25:34 2015 From: heidijoy at openstack.org (Heidi Joy Tretheway) Date: Wed, 21 Oct 2015 14:25:34 -0700 Subject: [Openstack-security] The first version of the Logo for Openstack security project Message-ID: Hi security team, I wanted to follow up on the questions about whether the OpenStack logo can be used for the security team’s logo. The short answer is no - per my conversations with other foundation leaders and our policy, we can’t allow derivatives of the logo. Distinctiveness is one of the requirements to have a trademark and one of the battles we've had to fight in certain jurisdictions, which is why we have to hold the line pretty tight on derivative logos. That means changing the logo or icon's color or its elements (removing the drop-shadow, making it chunkier, adapting it to look like a lock) are all no-gos. We do grant exceptions for special-purpose one-time uses (such as a T-shirt design), but project logos don’t fit that category. You’ll see Keystone also has a lock-style logo, and Manila’s logo uses the OpenStack mark without modifying it. I’d recommend creating something akin to Cinder’s logo, which uses the typical OpenStack font and color, but with a different icon. I’m very happy to volunteer to help guide a designer on this to ensure your team gets what you’re happy with that also falls within the brand guidelines, and you’ve got some good ideas in the first design already. How can I help? Looking forward to meeting many of you all in Tokyo. Heidi Joy Tretheway Senior Marketing Manager OpenStack Foundation 503 816 9769 heidi.tretheway - skype heidijoy at openstack.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot_2015-10-21_08.14.06_720.png Type: image/png Size: 148593 bytes Desc: not available URL: From robert.clark at hpe.com Wed Oct 21 21:27:40 2015 From: robert.clark at hpe.com (Clark, Robert Graham) Date: Wed, 21 Oct 2015 21:27:40 +0000 Subject: [Openstack-security] [openstack-dev] [security] The first version of the Logo for Openstack Security Project In-Reply-To: References: <5627BCE3.3020309@redhat.com> Message-ID: Wow, that looks amazing. It's pretty late my time so I'll take a closer look at the text tomorrow but the overall look and style is superb! Thank you for all the effort that's gone into this! > -----Original Message----- > From: Michael Xin [mailto:michael.xin at RACKSPACE.COM] > Sent: 21 October 2015 22:11 > To: OpenStack Development Mailing List (not for usage questions) > Cc: openstack-security at lists.openstack.org > Subject: Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project > > Rob and Michael: > Thanks for the update. We will probably not use any Openstack Logo. > > Here is the first draft of the flyer: > > http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf > > > Please send us your feedback. > > > Yours, > Michael > > > > > > On 10/21/15, 11:32 AM, "Clark, Robert Graham" wrote: > > >I had looped some people into a previous version of the thread but they've not replied yet. > > > >I think we ran into this problem before and got a firm "maybe, depending on what it is" from the powers-that-be. > > > >Perhaps we should look at a rough-draft alternative logo while we await a verdict? > > > >> -----Original Message----- > >> From: michael mccune [mailto:msm at redhat.com] > >> Sent: 21 October 2015 17:27 > >> To: openstack-dev at lists.openstack.org > >> Subject: Re: [openstack-dev] [security] The first version of the Logo for Openstack Security Project > >> > >> On 10/21/2015 03:54 AM, Michael Xin wrote: > >> > Hi, guys: > >> > Thanks for your help. We are designing a logo and a flyer for Openstack > >> > Security Project. Rachel helped us with the task. Attached is her first > >> > version of the logo. Please let us know your feedback. > >> > > >> > http://5d100f09242e1d85fe65-9262bad2bd2ce9d805c21cb30838f376.r18.cf1.rackcdn.com/os-security-project-logo.png > >> > Thanks and have a great day. > >> > >> hi Michael, thanks to Rachel for putting this together. i like the > >> general concept of the openstack logo as a lock. i think the "lock > >> parts" could have a little more depth on them. > >> > >> you had asked in irc about usage of the openstack logo, i'm not sure. > >> but this page, https://www.openstack.org/brand/openstack-logo/ , seems > >> to indicate that the usage is pretty limited. in specific, this section > >> "You agree that you will not (i) alter or modify the OpenStack Logo as > >> provided by the OpenStack Foundation; " seems to indicate that we may > >> not be able to use the logo like this. we should probably ask someone > >> from the foundation. > >> > >> all in all though, a nice effort. many thanks =) > >> > >> mike > >> > >> > >> __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > >__________________________________________________________________________ > >OpenStack Development Mailing List (not for usage questions) > >Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From dpyzhov+launchpad at mirantis.com Thu Oct 22 03:14:04 2015 From: dpyzhov+launchpad at mirantis.com (Dmitry Pyzhov) Date: Thu, 22 Oct 2015 03:14:04 -0000 Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com> Message-ID: <20151022031404.26477.61737.launchpad@gac.canonical.com> ** Tags added: area-library -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1355509 Title: Better conductor deployment Status in Fuel for OpenStack: Won't Fix Status in Fuel for OpenStack 6.0.x series: Won't Fix Status in Fuel for OpenStack 7.0.x series: Won't Fix Bug description: Here is several issues with how MOS deploys conductor. 1 By default all deployment variants assume deployments with conductor enabled. But this requires to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor. One of the reason for creating conductor service was to provide security level for nova. 2 by default it not possible to disable conductor using MOS tools. Customers who prefer performance over security should have this options. Conductor can introduce significant delay in all actions required database access. This two enchantments are tied together. The following actions are required to disable usage of conductor. On all compute nodes: 1 make use mysql port is accessible from compute nodes and all necessary grange are present. 2 add into nova.conf [DEFAULT] sql_connection = mysql://nova:password at mysqlhost/nova_db [conductor] use_local=true 3 service openstack-nova-compute restart 4 optionally stop conductor process on controllers Monitoring tuning may be required.. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1355509/+subscriptions From gerrit2 at review.openstack.org Thu Oct 22 13:36:04 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 22 Oct 2015 13:36:04 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/188874 Log: commit 65431df068612a4edce213fdc8633f4406c5703f Author: Dane Fichter Date: Wed Sep 9 14:18:56 2015 -0400 Nova Support of Glance Image Signing This spec is related to work in the Glance project which handles signed images. SecurityImpact DocImpact It depends on this glance spec: Depends-On: I305b2ae86415c8d256c641abb2795af663bee56a Change-Id: Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Implements: blueprint nova-support-image-signing From gerrit2 at review.openstack.org Thu Oct 22 13:50:36 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 22 Oct 2015 13:50:36 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/188874 Log: commit c7cb81a354ea1befb84722a511d8ee0a89438588 Author: Dane Fichter Date: Wed Sep 9 14:18:56 2015 -0400 Nova Support of Glance Image Signing This spec is related to work in the Glance project which handles signed images. SecurityImpact DocImpact It depends on this glance spec: Depends-On: I305b2ae86415c8d256c641abb2795af663bee56a Change-Id: Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Implements: blueprint nova-support-image-signing From michael.xin at RACKSPACE.COM Thu Oct 22 20:42:07 2015 From: michael.xin at RACKSPACE.COM (Michael Xin) Date: Thu, 22 Oct 2015 20:42:07 +0000 Subject: [Openstack-security] [openstack-dev] [security] The first version of the Logo for Openstack Security Project In-Reply-To: References: <5627BCE3.3020309@redhat.com> <56291A64.3090009@redhat.com> Message-ID: Hi, guys: Here are the latest version of the flyer and logo. Please let me know if you have any question. http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer_v3.pdf http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-badge-logo-01.png http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-badge-logo-01-distressed.png As for the flyer, I will print 200 copies and bring them to Tokyo. Yours, Michael On 10/22/15, 1:03 PM, "Michael Xin" wrote: >Mike: >Got it. Thanks. We will update it. > > >Yours, >Michael > > > > >On 10/22/15, 12:18 PM, "michael mccune" wrote: > >>On 10/21/2015 05:11 PM, Michael Xin wrote: >>> Rob and Michael: >>> Thanks for the update. We will probably not use any Openstack Logo. >>> >>> Here is the first draft of the flyer: >>> >>> http://5a6aa6580e900b8e8020-e5e45c5cb10329ebc9fb69948bb1b1a5.r65.cf1.rackcdn.com/ossp-flag-flyer.pdf >>> >>> >>> Please send us your feedback. >> >>i think my only suggestion on the text would be to slightly alter the >>second sentence of the "What's the OSSP?" section. >> >>currently it is: >> >>"The Security Project undertakes both technical and governance >>activities within OpenStack, aiming to provide guidance, information and >>code that enhances the overall security of the OpenStack ecosystem" >> >>i would change the beginning to: >> >>"The Security Project undertakes both technical and governance >>activities for the OpenStack community, aiming to provide guidance, >>information and code that enhances the overall security of the OpenStack >>ecosystem" >> >>but i think this is a pretty minor nit. >> >>regards, >>mike >> >>__________________________________________________________________________ >>OpenStack Development Mailing List (not for usage questions) >>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From 1434545 at bugs.launchpad.net Fri Oct 23 11:26:57 2015 From: 1434545 at bugs.launchpad.net (Amrith) Date: Fri, 23 Oct 2015 11:26:57 -0000 Subject: [Openstack-security] [Bug 1434545] Re: Several command injection vulnerabilities in guestagent/pkg References: <20150320131103.23017.37206.malonedeb@chaenomeles.canonical.com> Message-ID: <20151023112659.1126.96253.launchpad@soybean.canonical.com> ** Changed in: trove Assignee: (unassigned) => Amrith (amrith) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1434545 Title: Several command injection vulnerabilities in guestagent/pkg Status in OpenStack Security Advisory: Won't Fix Status in Trove: Triaged Bug description: At several places in the file guestagent/pkg.py, there are shell injection vulnerabilities: https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L209 In this line, the cmd_list is being built parameterized, but then it is just combined into one big string and called directly on a shell through the command getstatusoutput, which does a popen. If package name is set maliciously, the command will execute arbitrary code with the privilege of the trove process. The same is true on this line, https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L258 , where a package named something like "abc; rm -rf /etc" will cause all files in /etc which Trove has permissions for, to be deleted. Again, on this line: https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L371 , a malicious package name will cause arbitrary code injection with the privileges of the Trove process. I'm not nearly familiar enough with the Trove code and uses to know all the ways that package names for this code can be set, but these commands should be parameterized. Finally, os.popen is a deprecated function. The subprocess module should be used instead. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1434545/+subscriptions From gerrit2 at review.openstack.org Fri Oct 23 18:12:59 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 23 Oct 2015 18:12:59 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/188874 Log: commit c056bce01f39c02ab327e565d875503d0f433c40 Author: Dane Fichter Date: Wed Sep 9 14:18:56 2015 -0400 Nova Support of Glance Image Signing This spec is related to work in the Glance project which handles signed images. SecurityImpact DocImpact It depends on this glance spec: Depends-On: I305b2ae86415c8d256c641abb2795af663bee56a Change-Id: Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Implements: blueprint nova-support-image-signing From gerrit2 at review.openstack.org Fri Oct 23 19:35:23 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 23 Oct 2015 19:35:23 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/188874 Log: commit a6933de63d0b3eefc46b2d0372259ee7b00721ef Author: Dane Fichter Date: Wed Sep 9 14:18:56 2015 -0400 Nova Support of Glance Image Signing This spec is related to work in the Glance project which handles signed images. SecurityImpact DocImpact It depends on this glance spec: Depends-On: I305b2ae86415c8d256c641abb2795af663bee56a Change-Id: Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Implements: blueprint nova-support-image-signing From stanislaw.pitucha at hpe.com Sun Oct 25 09:03:12 2015 From: stanislaw.pitucha at hpe.com (Pitucha, Stanislaw Izaak) Date: Sun, 25 Oct 2015 09:03:12 +0000 Subject: [Openstack-security] Good work security group! Message-ID: Hi all, Just wanted to let all of you involved in OpenStack security know that the group got a shout out at Ruxcon security conference for security engineering done right. It was mentioned in context of being easy to reach, having good process of dealing with reports and security engineering in general. Another slide mentioned Bandit and cross project guidelines (https://pbs.twimg.com/media/CSHpRzJU8AAu8fj.jpg:large). The talk was not related to OpenStack in any way – it was about security in general. Well done to everyone involved! Best Regards, Stanisław Pitucha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3508 bytes Desc: not available URL: From tom at openstack.org Sun Oct 25 10:00:56 2015 From: tom at openstack.org (Tom Fifield) Date: Sun, 25 Oct 2015 19:00:56 +0900 Subject: [Openstack-security] Good work security group! In-Reply-To: References: Message-ID: <562CA858.9090609@openstack.org> That is very cool indeed. Congratulations to the security team! On 25/10/15 18:03, Pitucha, Stanislaw Izaak wrote: > Hi all, > > Just wanted to let all of you involved in OpenStack security know that > the group got a shout out at Ruxcon security conference for security > engineering done right. It was mentioned in context of being easy to > reach, having good process of dealing with reports and security > engineering in general. Another slide mentioned Bandit and cross project > guidelines (https://pbs.twimg.com/media/CSHpRzJU8AAu8fj.jpg:large). > > The talk was not related to OpenStack in any way – it was about security > in general. Well done to everyone involved! > > Best Regards, > > Stanisław Pitucha > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > From msm at redhat.com Sun Oct 25 21:19:14 2015 From: msm at redhat.com (michael mccune) Date: Sun, 25 Oct 2015 17:19:14 -0400 Subject: [Openstack-security] Good work security group! In-Reply-To: References: Message-ID: <562D4752.2030802@redhat.com> On 10/25/2015 05:03 AM, Pitucha, Stanislaw Izaak wrote: > Hi all, > > Just wanted to let all of you involved in OpenStack security know that > the group got a shout out at Ruxcon security conference for security > engineering done right. It was mentioned in context of being easy to > reach, having good process of dealing with reports and security > engineering in general. Another slide mentioned Bandit and cross project > guidelines (https://pbs.twimg.com/media/CSHpRzJU8AAu8fj.jpg:large). > > The talk was not related to OpenStack in any way – it was about security > in general. Well done to everyone involved! very cool, thanks for passing that along Stanislaw regards, mike From gerrit2 at review.openstack.org Tue Oct 27 13:01:41 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 27 Oct 2015 13:01:41 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/188874 Log: commit 7326fb153e322b863c04ed1e200ad492fb3aa0a0 Author: Dane Fichter Date: Wed Sep 9 14:18:56 2015 -0400 Nova Support of Glance Image Signing This spec is related to work in the Glance project which handles signed images. SecurityImpact DocImpact It depends on this glance spec: Depends-On: I305b2ae86415c8d256c641abb2795af663bee56a Change-Id: Ia8e7fcc21d7c15e480facbe30af88cdce2d73159 Implements: blueprint nova-support-image-signing From 1499555 at bugs.launchpad.net Wed Oct 28 14:23:28 2015 From: 1499555 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 28 Oct 2015 14:23:28 -0000 Subject: [Openstack-security] [Bug 1499555] Re: You can crash keystone or make the DB very slow by assigning many roles References: <20150924232400.8965.55797.malonedeb@gac.canonical.com> Message-ID: <20151028142328.10979.63046.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/239948 ** Changed in: keystone Status: Triaged => 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/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Incomplete Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB    Say user is U, and Project is P    for i =1 to 1000 ( or any large number)         role x = create role i with some large name         assign role x for user U and Project P        create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions From grant.murphy at hp.com Thu Oct 29 21:49:08 2015 From: grant.murphy at hp.com (Grant Murphy) Date: Thu, 29 Oct 2015 21:49:08 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20151029214908.13806.97313.malone@wampee.canonical.com> I've opened https://bugs.launchpad.net/ossa/+bug/1511541 to track this as an incomplete fix. @al592b, @rydoc if you can attach your test case to that bug it might help expedite the process. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From gerrit2 at review.openstack.org Fri Oct 30 00:19:25 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 30 Oct 2015 00:19:25 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/207226 Log: commit afad604685b139d66199b90942a18df92c70e7a0 Author: Brant Knudson Date: Wed Jul 29 16:29:42 2015 -0500 Config option for insecure responses oslo.log's "debug" option was coopted to also indicate that the responses should include more information. A separate config option should be used instead so that deployers don't mistakenly expose themselves to security issues. The debug option still is used for what it does in oslo.log and how it works on all other projects -- if you're not using a log config file it sets the base logger to debug. SecurityImpact Change-Id: Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Closes-Bug: 1479523 From gerrit2 at review.openstack.org Fri Oct 30 07:42:27 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 30 Oct 2015 07:42:27 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/207226 Log: commit 88f7a05ed241dba6cc3269178d80c1a96477d52d Author: Brant Knudson Date: Wed Jul 29 16:29:42 2015 -0500 Config option for insecure responses oslo.log's "debug" option was co-opted to also indicate that the responses should include more information. A separate config option should be used instead so that deployers don't mistakenly expose themselves to security issues. The debug option still is used for what it does in oslo.log and how it works on all other projects -- if you're not using a log config file it sets the base logger to debug. SecurityImpact Change-Id: Icf8dd2f0b88abc89092d487bbcefb525960c4ec6 Closes-Bug: 1479523 From 1471158 at bugs.launchpad.net Fri Oct 30 18:36:37 2015 From: 1471158 at bugs.launchpad.net (Federico Ceratto) Date: Fri, 30 Oct 2015 18:36:37 -0000 Subject: [Openstack-security] [Bug 1471158] Re: Incorrect regular expressions used for schema validation References: <20150703091933.9600.68969.malonedeb@gac.canonical.com> Message-ID: <20151030183638.23556.3248.launchpad@gac.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1471158 Title: Incorrect regular expressions used for schema validation Status in Designate: Fix Released Status in Designate juno series: Fix Committed Status in Designate kilo series: Fix Committed Bug description: The regular expressions listed in designate/schema/format.py allow trailing "\n" characters because "$" matches "\n" at the end of the string. Submitting a record creation request with "name" ending with "\n" currently results in an internal server, with the following traceback in the log file: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply executor_callback)) File "/usr/lib/python2.7/site-packages/designate/rpc.py", line 178, in _dispatch return super(RPCDispatcher, self)._dispatch(*args, **kwds) File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 186, in _dispatch executor_callback) File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 130, in _do_dispatch result = func(ctxt, **new_args) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 220, in wrapper result = f(self, *args, **kwargs) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 194, in wrapper result = f(self, *args, **kwargs) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 1119, in create_recordset context, domain, recordset, increment_serial=increment_serial) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 84, in wrapper **copy.deepcopy(kwargs)) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 123, in wrapper self.storage.rollback() File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 119, in __exit__ six.reraise(self.type_, self.value, self.tb) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 118, in wrapper result = f(self, *args, **kwargs) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 1138, in _create_recordset_in_storage self._is_valid_recordset_name(context, domain, recordset.name) File "/usr/lib/python2.7/site-packages/designate/central/service.py", line 341, in _is_valid_recordset_name raise ValueError('Please supply a FQDN') ValueError: Please supply a FQDN If such additional checks are everywhere, the incorrect regular expressions should be harmless, and the security flag can be removed. Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1235655 To manage notifications about this bug go to: https://bugs.launchpad.net/designate/+bug/1471158/+subscriptions From travis.mcpeak at hpe.com Wed Oct 28 15:01:18 2015 From: travis.mcpeak at hpe.com (McPeak, Travis) Date: Wed, 28 Oct 2015 15:01:18 +0000 Subject: [Openstack-security] Good work security group! Message-ID: This is really awesome! Thanks for sharing this Stan. It's nice to get feedback like this as we continue to grow our security community! Thanks, -Travis On 10/25/15, 1:00 PM, "openstack-security-request at lists.openstack.org" wrote: >Hi all, > >Just wanted to let all of you involved in OpenStack security know that >the group got a shout out at Ruxcon security conference for security >engineering done right. It was mentioned in context of being easy to >reach, having good process of dealing with reports and security >engineering in general. Another slide mentioned Bandit and cross >project guidelines >(https://pbs.twimg.com/media/CSHpRzJU8AAu8fj.jpg:large). > > >The talk was not related to OpenStack in any way ? it was about >security in general. Well done to everyone involved! > > >Best Regards, > >Stanis?aw Pitucha -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5465 bytes Desc: not available URL: From alopgeek at gmail.com Thu Oct 29 20:24:00 2015 From: alopgeek at gmail.com (Abel Lopez) Date: Thu, 29 Oct 2015 20:24:00 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20151029202400.6266.8463.malone@soybean.canonical.com> This is still present after this patch. In our testing, we're able to get consoles for the same instance on different hosts. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions