From 1252519 at bugs.launchpad.net Mon Sep 1 17:13:58 2014 From: 1252519 at bugs.launchpad.net (Hendrik Frenzel) Date: Mon, 01 Sep 2014 17:13:58 -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: <20140901171400.27701.66755.launchpad@wampee.canonical.com> ** Changed in: nova Status: Triaged => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, 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): Confirmed 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 tim.kelsey at hp.com Tue Sep 2 14:34:23 2014 From: tim.kelsey at hp.com (Tim Kelsey) Date: Tue, 02 Sep 2014 14:34:23 -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: <20140902143427.3968.50768.launchpad@soybean.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Tim Kelsey (tim-kelsey) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: New 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 gerrit2 at review.openstack.org Tue Sep 2 14:54:03 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 02 Sep 2014 14:54:03 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit 2875f5892555e893fd549a1eb545177d06a9635f Author: Daniel Genin Date: Thu Aug 21 11:00:59 2014 -0400 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint lvm-ephemeral-storage-encryption Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From gerrit2 at review.openstack.org Tue Sep 2 18:41:26 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 02 Sep 2014 18:41:26 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I64859ad01120782fb17308aac3abb125597c3ea2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/115484 Log: commit b2a9646dd544692704ec0ecc1953bdf1d4026528 Author: Solly Ross Date: Tue Aug 19 19:21:52 2014 -0400 Add VeNCrypt (TLS/x509) Security Proxy Driver This adds support for using x509/TLS security between the compute node and websocket proxy when using websockify to proxy VNC traffic. In order to use this with x509, an operator would have to set up client keys and certificates, as well as CA certificates, and configure libvirt to pass the appropriate options to QEmu (this is configured globally for libvirt, not by Nova). This is process is documented on the libvirt website. Then, the operator would enable this driver and set the following options in /etc/nova/nova.conf: [console_proxy_tls] client_key = /path/to/client/keyfile client_cert = /path/to/client/cert.pem ca_certs = /pat/to/ca/cert.pem SecurityImpact DocImpact Implements bp: websocket-proxy-to-host-security Change-Id: I64859ad01120782fb17308aac3abb125597c3ea2 From 1316271 at bugs.launchpad.net Tue Sep 2 22:04:50 2014 From: 1316271 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 02 Sep 2014 22:04:50 -0000 Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts can SSH to compute node References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20140902220450.8919.40983.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/118476 ** Changed in: nova Status: New => In Progress ** Changed in: nova Assignee: (unassigned) => David Hill (david-hill-ubisoft) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From gerrit2 at review.openstack.org Wed Sep 3 14:57:28 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 03 Sep 2014 14:57:28 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I64859ad01120782fb17308aac3abb125597c3ea2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/115484 Log: commit a4fc5a7522fad879cde41cb0b11d9fd134fea3d0 Author: Solly Ross Date: Tue Aug 19 19:21:52 2014 -0400 Add VeNCrypt (TLS/x509) Security Proxy Driver This adds support for using x509/TLS security between the compute node and websocket proxy when using websockify to proxy VNC traffic. In order to use this with x509, an operator would have to set up client keys and certificates, as well as CA certificates, and configure libvirt to pass the appropriate options to QEmu (this is configured globally for libvirt, not by Nova). This is process is documented on the libvirt website. Then, the operator would enable this driver and set the following options in /etc/nova/nova.conf: [console_proxy_tls] client_key = /path/to/client/keyfile client_cert = /path/to/client/cert.pem ca_certs = /pat/to/ca/cert.pem SecurityImpact DocImpact Implements bp: websocket-proxy-to-host-security Change-Id: I64859ad01120782fb17308aac3abb125597c3ea2 From thierry.carrez+lp at gmail.com Wed Sep 3 15:44:27 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 03 Sep 2014 15:44:27 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140903154431.25418.3674.launchpad@soybean.canonical.com> ** Changed in: neutron Milestone: juno-3 => juno-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: In Progress Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From 1329737 at bugs.launchpad.net Wed Sep 3 18:59:27 2014 From: 1329737 at bugs.launchpad.net (Dolph Mathews) Date: Wed, 03 Sep 2014 18:59:27 -0000 Subject: [Openstack-security] [Bug 1329737] Re: Valid tokens may remain after token's user was deleted References: <20140613111922.26567.45578.malonedeb@chaenomeles.canonical.com> Message-ID: <20140903185928.5362.56261.malone@wampee.canonical.com> This has been addressed on the Keystone side with the above BP. ** Changed in: keystone Status: Triaged => Invalid ** Changed in: keystone Milestone: juno-3 => None -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329737 Title: Valid tokens may remain after token's user was deleted Status in OpenStack Identity (Keystone): Invalid Status in OpenStack Security Advisories: Won't Fix Bug description: When user is deleted, deleted user's tokens are expired after committing transaction for deleting user. If database dies while tokens are being expired, remaining tokens will lose the chance to expire until 24 hours later. (Because user is already deleted.) In this case, remaining tokens are able to used to authenticate despite the fact that token's user was deleted. I think this case is dangerous from the security point of view. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1329737/+subscriptions From 1274034 at bugs.launchpad.net Thu Sep 4 10:52:03 2014 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 04 Sep 2014 10:52:03 -0000 Subject: [Openstack-security] [Bug 1274034] Fix proposed to neutron (master) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140904105203.18315.48369.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/119031 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: New 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 Sep 4 13:24:36 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 04 Sep 2014 13:24:36 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140904132440.17776.8032.launchpad@chaenomeles.canonical.com> ** Changed in: cinder Status: Fix Committed => Fix Released ** Changed in: cinder Milestone: None => juno-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): New Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From nkinder at redhat.com Thu Sep 4 16:17:56 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 04 Sep 2014 16:17:56 -0000 Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup strategies References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com> Message-ID: <20140904161758.32318.91897.launchpad@gac.canonical.com> ** Changed in: ossn Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1343657 Title: Shell Injection in backup strategies Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Status in Openstack Database (Trove): New Bug description: Trove uses subprocess.Popen with shell=True in trove/trove/guestagent/strategies/backup/base.py line 61: def run(self): self.process = subprocess.Popen(self.command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) self.pid = self.process.pid This could be used, maliciously or not, to inject arbitrary commands into a command line string. An example of this could be triggered is in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It is creating a MySQL string with single quote. If the password, either maliciously or just happens to contain another single quote, it will escape from the command and arbitrary data will be executed instead. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently- used-arguments To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1343657/+subscriptions From nkinder at redhat.com Thu Sep 4 16:17:13 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 04 Sep 2014 16:17:13 -0000 Subject: [Openstack-security] [Bug 1337349] Re: Nova qemu hypervisor host smbios serial number is leaked to guest References: <20140703142824.27562.82896.malonedeb@gac.canonical.com> Message-ID: <20140904161716.5401.22352.launchpad@wampee.canonical.com> ** Changed in: ossn Importance: Undecided => Medium ** Changed in: ossn Status: New => In Progress ** Changed in: ossn Assignee: (unassigned) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1337349 Title: Nova qemu hypervisor host smbios serial number is leaked to guest Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: Erwan Velu from eNovance reported a vulnerability in OpenStack Nova. The hypervisor is passing host system uuid (-smbios version) to guests, and this happen to be a critical info leak. The defect have been pinpointed to: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3054 From a simple virtual machine, this may allow numerous info leak like: Allow compute hardware enumeration from guests Deduce service tag and get all hardware configuration Ability to know if two instances are on the same compute Dell hardware is particulary impacted as : - the uuid encodes the service tag - the service tag can be used on support site to determine: - detailled hardware configuration - date & country where the hw was shipped - date & type of support contract - amount of servers bought during this shipment If there is no use case for this, we should scrambled that piece of information. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1337349/+subscriptions From thierry.carrez+lp at gmail.com Fri Sep 5 09:54:05 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 05 Sep 2014 09:54:05 -0000 Subject: [Openstack-security] [Bug 1337349] Re: Nova qemu hypervisor host smbios serial number is leaked to guest References: <20140703142824.27562.82896.malonedeb@gac.canonical.com> Message-ID: <20140905095409.5005.28101.launchpad@wampee.canonical.com> ** Changed in: nova Status: Fix Committed => Fix Released ** Changed in: nova Milestone: None => juno-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1337349 Title: Nova qemu hypervisor host smbios serial number is leaked to guest Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: Erwan Velu from eNovance reported a vulnerability in OpenStack Nova. The hypervisor is passing host system uuid (-smbios version) to guests, and this happen to be a critical info leak. The defect have been pinpointed to: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3054 From a simple virtual machine, this may allow numerous info leak like: Allow compute hardware enumeration from guests Deduce service tag and get all hardware configuration Ability to know if two instances are on the same compute Dell hardware is particulary impacted as : - the uuid encodes the service tag - the service tag can be used on support site to determine: - detailled hardware configuration - date & country where the hw was shipped - date & type of support contract - amount of servers bought during this shipment If there is no use case for this, we should scrambled that piece of information. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1337349/+subscriptions From tim.kelsey at hp.com Fri Sep 5 10:22:45 2014 From: tim.kelsey at hp.com (Tim Kelsey) Date: Fri, 05 Sep 2014 10:22:45 -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: <20140905102249.25315.32653.launchpad@soybean.canonical.com> ** Changed in: ossn Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: In Progress 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 1274034 at bugs.launchpad.net Fri Sep 5 11:58:17 2014 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 05 Sep 2014 11:58:17 -0000 Subject: [Openstack-security] [Bug 1274034] Fix proposed to neutron (master) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140905115817.17973.31760.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/119352 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: In Progress 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 1274034 at bugs.launchpad.net Fri Sep 5 12:04:36 2014 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 05 Sep 2014 12:04:36 -0000 Subject: [Openstack-security] [Bug 1274034] Change abandoned on neutron (master) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140905120436.5098.13958.malone@wampee.canonical.com> Change abandoned by Juergen Brendel (jbrendel at cisco.com) on branch: master Review: https://review.openstack.org/119031 Reason: After feedback decided to replace this patch with two separate patches instead: 1. Implement ebtables manager: https://review.openstack.org/#/c/119343/ 2. Implement ARP fix: https://review.openstack.org/#/c/119352/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: In Progress 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 1252519 at bugs.launchpad.net Fri Sep 5 14:10:39 2014 From: 1252519 at bugs.launchpad.net (Dylan) Date: Fri, 05 Sep 2014 14:10:39 -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: <20140905141039.4798.89309.malone@wampee.canonical.com> I think this is related to a bug I have found at Bugzilla. The work around solved my issue. excerpt from bug to workaround this issue. * stop your guests * stop libvirt-bin * edit /etc/libvirt/qemu.conf - this contains a commented out entry 'dynamic_ownership=1', which is the default. Change this to 0, and remove the comment. * Do a chown to libvirt-qemu:kvm for all your stopped images. * Start the service libvirt-bin again * Bring up the guests * Repeat on the other half of your cluster * Test a live migration - for me, they work again. https://bugzilla.redhat.com/show_bug.cgi?id=1057645 ** Bug watch added: Red Hat Bugzilla #1057645 https://bugzilla.redhat.com/show_bug.cgi?id=1057645 -- You received this bug notification because you are a member of OpenStack Security Group, 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): Confirmed 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 fungi at yuggoth.org Fri Sep 5 15:28:53 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 05 Sep 2014 15:28:53 -0000 Subject: [Openstack-security] [Bug 1365712] Re: Command Execution Possible Through Config File Tampering References: <20140904211316.25282.32054.malonedeb@soybean.canonical.com> Message-ID: <20140905152853.18382.76415.malone@chaenomeles.canonical.com> Got it. We use "security" bugs (whether private or public) to track vulnerabilities, and use normal public bugs with the "security" tag for hardening tasks. ** Tags added: security ** Information type changed from Public Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1365712 Title: Command Execution Possible Through Config File Tampering Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The OpenStack Security Group has been reviewing OpenStack code to find potential security vulnerabilities. One class of these vulnerabilities is to allow someone with write access to nova.conf to cause code to be executed as the OpenStack user. Some details are here: https://review.openstack.org/#/c/118910/ More tracking information is here: https://bugs.launchpad.net/nova/+bug/1192971 This bug is specifically to address the possible vulnerability at nova/nova/virt/baremetal/ipmi.py:292 If a user has write access to nova.conf, he can set [baremetal] terminal = /bin/foo and cause /bin/foo to be executed. If a user has write access to nova.conf, he case set [baremetal] terminal_cert_dir = "; cat /etc/passwd" and cause the password file to be written to stdout. Some input validation would help correct this. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1365712/+subscriptions From gerrit2 at review.openstack.org Fri Sep 5 17:44:46 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 05 Sep 2014 17:44:46 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit b1027aba0d1ee34590d0f0f6e3055dd15cdedd48 Author: Daniel Genin Date: Tue Sep 2 17:04:53 2014 -0400 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint lvm-ephemeral-storage-encryption Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From gerrit2 at review.openstack.org Fri Sep 5 18:53:18 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 05 Sep 2014 18:53:18 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit 389285591ea55341fc64965bcf20ffd5e3aaee2c Author: Daniel Genin Date: Tue Sep 2 18:16:04 2014 -0400 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint lvm-ephemeral-storage-encryption Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From travis.mcpeak at hp.com Fri Sep 5 20:28:21 2014 From: travis.mcpeak at hp.com (Travis McPeak) Date: Fri, 05 Sep 2014 20:28:21 -0000 Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup strategies References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com> Message-ID: <20140905202825.17616.34374.launchpad@chaenomeles.canonical.com> ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1343657 Title: Shell Injection in backup strategies Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Openstack Database (Trove): New Bug description: Trove uses subprocess.Popen with shell=True in trove/trove/guestagent/strategies/backup/base.py line 61: def run(self): self.process = subprocess.Popen(self.command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) self.pid = self.process.pid This could be used, maliciously or not, to inject arbitrary commands into a command line string. An example of this could be triggered is in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It is creating a MySQL string with single quote. If the password, either maliciously or just happens to contain another single quote, it will escape from the command and arbitrary data will be executed instead. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently- used-arguments To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1343657/+subscriptions From gerrit2 at review.openstack.org Fri Sep 5 21:03:24 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 05 Sep 2014 21:03:24 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit faaac020c2bcc36ceadb9eeba51de0a45de27eec Author: Daniel Genin Date: Tue Sep 2 18:16:04 2014 -0400 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint lvm-ephemeral-storage-encryption Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From davanum at gmail.com Sat Sep 6 02:00:49 2014 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Sat, 06 Sep 2014 02:00:49 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140906020049.4935.3701.malone@wampee.canonical.com> Here's a oslo.vmware review that adds back a memory based cache - https://review.openstack.org/#/c/116297/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): New Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From 1252519 at bugs.launchpad.net Sat Sep 6 19:09:29 2014 From: 1252519 at bugs.launchpad.net (Hendrik Frenzel) Date: Sat, 06 Sep 2014 19:09:29 -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: <20140906190930.17776.89782.malone@chaenomeles.canonical.com> Great, this works for me. Thank you, Dylan. -- You received this bug notification because you are a member of OpenStack Security Group, 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): Confirmed 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 1316271 at bugs.launchpad.net Sun Sep 7 01:29:32 2014 From: 1316271 at bugs.launchpad.net (David Hill) Date: Sun, 07 Sep 2014 01:29:32 -0000 Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts can SSH to compute node References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20140907012932.4873.64382.malone@wampee.canonical.com> I created a blueprint in order to further development of logging features for the network layer. https://blueprints.launchpad.net/nova/+spec/nova-compute-instance- traffic-logging -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From 1316271 at bugs.launchpad.net Sun Sep 7 03:04:17 2014 From: 1316271 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 07 Sep 2014 03:04:17 -0000 Subject: [Openstack-security] [Bug 1316271] Related fix proposed to nova (master) References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20140907030417.4798.51177.malone@wampee.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/119589 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From gerrit2 at review.openstack.org Mon Sep 8 00:55:14 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 08 Sep 2014 00:55:14 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit 5fa74bc0b2ab6fe5149a9b684b4beadb67877622 Author: Daniel Genin Date: Tue Sep 2 18:16:04 2014 -0400 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint lvm-ephemeral-storage-encryption Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From maurice at leeflang.net Mon Sep 8 10:26:59 2014 From: maurice at leeflang.net (Maurice Leeflang) Date: Mon, 08 Sep 2014 10:26:59 -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: <20140908102659.5362.79815.malone@wampee.canonical.com> Works for me too! Thanks a lot Dylan! -- You received this bug notification because you are a member of OpenStack Security Group, 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): Confirmed 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 maruti.kamat at hp.com Tue Sep 2 15:15:17 2014 From: maruti.kamat at hp.com (Maruti Kamat) Date: Tue, 02 Sep 2014 15:15:17 -0000 Subject: [Openstack-security] [Bug 1278843] Re: Neutron doesn't report using a stale CA certificate References: <20140211121101.2015.95668.malonedeb@chaenomeles.canonical.com> Message-ID: <20140902151519.7567.77838.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Assignee: (unassigned) => Maruti Kamat (marutik) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1278843 Title: Neutron doesn't report using a stale CA certificate Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Neutron (virtual network service): Confirmed Bug description: It seems that when the CA certificate cashed locally by Neutron in /var/lib/neutron/keystone-signing/ is stale (does not match the current CA cert used by keystone), it is not possible to start a new instance. This is understandable. However, the stacktrace error you get while trying to start as instance in such a situation is a hugely misleading: "ERROR: Error: unsupported operand type(s) for +: 'NoneType' and 'str'" It's rather tricky to debug the issue. To reproduce just redo the pki-setup for keystone on a deployed and otherwise healthy openstack cluster. This will create a new CA cert for keystone, however neutron-server will be completely oblivious to this fact and will still insist on using it's local copy of the cacert. I'm running Havana on rhel6.4 ---------- /var/log/nova/compute.log on the compute node when trying to start a vm OpenStack (nova:4668) ERROR: Instance failed network setup after 1 attempt(s) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager Traceback (most recent call last): 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1238, in _allocate_network_async 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager dhcp_options=dhcp_options) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/api.py", line 49, in wrapper 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager res = f(self, context, *args, **kwargs) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 358, in allocate_for_instance 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager LOG.exception(msg, port_id) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 323, in allocate_for_instance 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager port_req_body) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 392, in _populate_neutron_extension_values 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager self._refresh_neutron_extensions_cache() 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 376, in _refresh_neutron_extensions_cache 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager extensions_list = neutron.list_extensions()['extensions'] 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 108, in with_params 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager ret = self.function(instance, *args, **kwargs) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 286, in list_extensions 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager return self.get(self.extensions_path, params=_params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1183, in get 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager headers=headers, params=params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1168, in retry_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager headers=headers, params=params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1103, in do_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager resp, replybody = self.httpclient.do_request(action, method, body=body) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 188, in do_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager self.authenticate() 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 224, in authenticate 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager token_url = self.auth_url + "/tokens" 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager ---------------- /var/log/neutron/server.log on the controller when trying to start a vm OpenStack (neutron:29274) DEBUG: Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User- Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role OpenStack (neutron:29274) INFO: Starting new HTTP connection (1): openstack OpenStack (neutron:29274) DEBUG: received {u'_context_roles': [u'admin'], u'_context_read_deleted': u'no', u'_context_tenant_id': None, u'args': {u'agent_state': {u'agent_state': {u'topic': u'N/A', u'binary' : u'neutron-openvswitch-agent', u'host': u'node001', u'agent_type': u'Open vSwitch agent', u'configurations': {u'tunnel_types': [], u'tunneling_ip': u'', u'bridge_mappings': {u'ph-eth0': u'br0'}, u'l2_popula tion': False, u'devices': 0}}}, u'time': u'2014-02-11T12:06:32.434133'}, u'namespace': None, u'_unique_id': u'ae5c6b608f6547f7b630dace2c5411bd', u'_context_is_admin': True, u'version': u'1.0', u'_context_pro ject_id': None, u'_context_timestamp': u'2014-02-11 12:00:14.386557', u'_context_user_id': None, u'method': u'report_state'} OpenStack (neutron:29274) DEBUG: unpacked context: {'user_id': None, 'roles': [u'admin'], 'tenant_id': None, 'is_admin': True, 'timestamp': u'2014-02-11 12:00:14.386557', 'project_id': None, 'read_deleted': u'no'} OpenStack (neutron:29274) DEBUG: "GET /v2.0/tokens/revoked HTTP/1.1" 200 1234 OpenStack (neutron:29274) WARNING: Verify error: Command 'openssl' returned non-zero exit status 4 OpenStack (neutron:29274) DEBUG: Token validation failure. Traceback (most recent call last):   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 808, in _validate_user_token     verified = self.verify_signed_token(user_token)   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1165, in verify_signed_token     if self.is_signed_token_revoked(signed_text):   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1127, in is_signed_token_revoked     revocation_list = self.token_revocation_list   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1217, in token_revocation_list     self.token_revocation_list = self.fetch_revocation_list()   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1247, in fetch_revocation_list     return self.cms_verify(data['signed'])   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1160, in cms_verify     raise err CalledProcessError: Command 'openssl' returned non-zero exit status 4 OpenStack (neutron:29274) DEBUG: Marking token c5e1c4ed4d0ab0db8bbaffbb33e139ba as unauthorized in memcache OpenStack (neutron:29274) WARNING: Authorization failed for token c5e1c4ed4d0ab0db8bbaffbb33e139ba OpenStack (neutron:29274) INFO: Invalid user token - rejecting request To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1278843/+subscriptions From 1362343 at bugs.launchpad.net Tue Sep 2 18:45:59 2014 From: 1362343 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 02 Sep 2014 18:45:59 -0000 Subject: [Openstack-security] [Bug 1362343] Re: weak digest algorithm for PKI References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com> Message-ID: <20140902184600.7697.28745.launchpad@chaenomeles.canonical.com> ** Tags added: pki ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1362343 Title: weak digest algorithm for PKI Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: The digest algorithm for PKI tokens is the openssl default of sha1. This is a weak algorithm and some security standards require a stronger algorithm such as sha256. Keystone should make the token digest hash algorithm configurable so that deployments can use a stronger algorithm. Also, the default could be stronger. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1362343/+subscriptions From 1341954 at bugs.launchpad.net Wed Sep 3 07:26:29 2014 From: 1341954 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 03 Sep 2014 07:26:29 -0000 Subject: [Openstack-security] [Bug 1341954] Fix proposed to cinder (stable/icehouse) References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140903072629.24844.63960.malone@soybean.canonical.com> Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/118560 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Committed Status in Gantt: New Status in OpenStack Compute (Nova): New Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From 1341954 at bugs.launchpad.net Wed Sep 3 08:14:22 2014 From: 1341954 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 03 Sep 2014 08:14:22 -0000 Subject: [Openstack-security] [Bug 1341954] Fix proposed to cinder (stable/havana) References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140903081422.5461.86258.malone@wampee.canonical.com> Fix proposed to branch: stable/havana Review: https://review.openstack.org/118565 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Committed Status in Gantt: New Status in OpenStack Compute (Nova): New Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From sean at dague.net Wed Sep 3 20:14:05 2014 From: sean at dague.net (Sean Dague) Date: Wed, 03 Sep 2014 20:14:05 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> Message-ID: <20140903201405.32706.54589.malone@gac.canonical.com> I feel like this is pretty strongly out of scope. Applications that need to talk to databases that require passwords need access to those passwords in plain text. While we could do obfuscation, it doesn't really address the issue, it just makes you think you addressed it. Honestly better to leave things clear so people rightly understand that a compromise of that file means all bets are off. ** Changed in: nova Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in OpenStack Compute (Nova): Won't Fix Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions From 1350766 at bugs.launchpad.net Thu Sep 4 19:56:13 2014 From: 1350766 at bugs.launchpad.net (melanie witt) Date: Thu, 04 Sep 2014 19:56:13 -0000 Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute intermittently corrupts base images on download from glance References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com> Message-ID: <20140904195616.18167.43675.launchpad@chaenomeles.canonical.com> ** Changed in: nova Importance: Undecided => High ** Changed in: nova Status: New => Triaged -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1350766 Title: Race condition: compute intermittently corrupts base images on download from glance Status in OpenStack Compute (Nova): Triaged Status in OpenStack Security Advisories: Incomplete Bug description: Under certain conditions, which I happen to meet often on my Icehouse single node setup, uploaded images or snapshots fail to boot. See also https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a -snapshot-from-a-running-instance/ Reason: When first instantiating a QCOW2 image, it's (1) downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part (2) converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img The step (1) is performed in nova/image/glance.py, GlanceImageService.download using buffered IO, which does not guarantee the resulting data to be written to disk on file close. Consequently, the source image file may not be written completely when qemu-img sub-process starts reading in step (2). Whether the result is good or bad depends on speed of download, file size, and how quickly qemu-image can digest its input. Proposed fix: enforce fsync on output File object before returning from download. Patch attached. Security considerations: * Due to the race between resources shared between users and tenants (compute node network and filesystem IO) a failure can be triggered across tenants, implying the risk of DoS. * To make things worse -- with the default setting of not cleaning the image cache -- any corrupted image will remain in cache until replaced with fresh upload using a new image ID. Affected snapshots remain unusable forever, until ex- and re-imported manually under better conditions. * Base image corruptions here are not detected and cannot be caught. Theoretically (a bit esoteric, quite unlikely, but not impossible), an attacker might modulate resource usage to precisely create an incompletely written image, that boots and runs, but has access control information stripped. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1350766/+subscriptions From 1362343 at bugs.launchpad.net Thu Sep 4 20:46:36 2014 From: 1362343 at bugs.launchpad.net (Dolph Mathews) Date: Thu, 04 Sep 2014 20:46:36 -0000 Subject: [Openstack-security] [Bug 1362343] Re: weak digest algorithm for PKI References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com> Message-ID: <20140904204638.18413.47090.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Importance: Undecided => Wishlist ** Changed in: python-keystoneclient Importance: Undecided => Wishlist -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1362343 Title: weak digest algorithm for PKI Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: The digest algorithm for PKI tokens is the openssl default of sha1. This is a weak algorithm and some security standards require a stronger algorithm such as sha256. Keystone should make the token digest hash algorithm configurable so that deployments can use a stronger algorithm. Also, the default could be stronger. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1362343/+subscriptions From davanum at gmail.com Mon Sep 8 11:29:46 2014 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Mon, 08 Sep 2014 11:29:46 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20140908112949.5494.79113.launchpad@wampee.canonical.com> ** Changed in: nova Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security Group, 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 facundo.n.maldonado at intel.com Mon Sep 8 12:31:22 2014 From: facundo.n.maldonado at intel.com (Facundo Maldonado) Date: Mon, 08 Sep 2014 12:31:22 -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: <20140908123124.32257.2931.launchpad@gac.canonical.com> ** Changed in: nova Assignee: Facundo Maldonado (facundo-n-maldonado) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, 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): Confirmed 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 1341954 at bugs.launchpad.net Mon Sep 8 13:02:58 2014 From: 1341954 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 08 Sep 2014 13:02:58 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140908130258.17709.9939.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/118560 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=03573a02a3235db2bf65d48aceb92a6e81850dd9 Submitter: Jenkins Branch: stable/icehouse commit 03573a02a3235db2bf65d48aceb92a6e81850dd9 Author: Vipin Balachandran Date: Fri Aug 22 10:19:29 2014 +0530 VMware: Disable suds caching The default cache implementation in suds store pickled objects in a predictable path in /tmp which could lead to attacks. This patch turns off suds caching to address this security issue. Change-Id: I7daaa25a0677004e03896298e9c3026d5c33c6ac Closes-Bug: #1341954 (cherry picked from commit 6a41fe9c5c98a14a355fa81b41aae2c4b0ce0a7b) ** Tags added: in-stable-icehouse -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): New Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From davanum at gmail.com Mon Sep 8 13:27:29 2014 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Mon, 08 Sep 2014 13:27:29 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140908132729.18382.77829.malone@chaenomeles.canonical.com> This has been fixed in oslo.vmware which Nova now depends on, we just need a fresh release of oslo.vmware to fix this in Nova ** Changed in: nova Importance: Undecided => Medium ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): Confirmed Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From davanum at gmail.com Mon Sep 8 13:35:08 2014 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Mon, 08 Sep 2014 13:35:08 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140908133510.18008.81581.launchpad@chaenomeles.canonical.com> ** Changed in: nova Assignee: (unassigned) => Davanum Srinivas (DIMS) (dims-v) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): Confirmed Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From 1252519 at bugs.launchpad.net Mon Sep 8 18:12:24 2014 From: 1252519 at bugs.launchpad.net (Hendrik Frenzel) Date: Mon, 08 Sep 2014 18:12:24 -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: <20140908181224.17842.59823.malone@chaenomeles.canonical.com> I would suggest to set user="nova" and group="nova" in qemu.conf too. Without them, a permission denied error occured on instance creation: 2014-09-08 20:08:33.267 4740 TRACE nova.compute.manager [instance: 6fbc9080-772d-4c18-a630-2196763742bf] qemu-kvm: -drive file=/var/lib/nova/instances/6fbc9080-772d- 4c18-a630-2196763742bf/disk,if=none,id=drive-virtio- disk0,format=qcow2,cache=none: could not open disk image /var/lib/nova/instances/6fbc9080-772d-4c18-a630-2196763742bf/disk: Permission denied -- You received this bug notification because you are a member of OpenStack Security Group, 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): Confirmed 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 maruti.kamat at hp.com Mon Sep 8 18:18:09 2014 From: maruti.kamat at hp.com (Maruti Kamat) Date: Mon, 08 Sep 2014 18:18:09 -0000 Subject: [Openstack-security] [Bug 1278843] Re: Neutron doesn't report using a stale CA certificate References: <20140211121101.2015.95668.malonedeb@chaenomeles.canonical.com> Message-ID: <20140908181810.376.73391.malone@gac.canonical.com> https://github.com/openstack/python- neutronclient/blob/2.3.4/neutronclient/client.py, inside authenticate() method, L231 was: token_url = self.auth_url + "/tokens" If self.auth_url is None, then the above line used to report an error as you saw. However, recently, this is fixed in https://github.com/openstack/python- neutronclient/blob/2.3.5/neutronclient/client.py where authenticate() method at L228 executes self._authenticate_keystone() inside which a check is performed at L201 whether self.auth_url is None or not. if self.auth_url is None: raise exceptions.NoAuthURLProvided() This fix was introduced as : https://github.com/openstack/python- neutronclient/commit/42f48fb1e71a6ff27b4727fbf5cabd2bcad8535a -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1278843 Title: Neutron doesn't report using a stale CA certificate Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Neutron (virtual network service): Confirmed Bug description: It seems that when the CA certificate cashed locally by Neutron in /var/lib/neutron/keystone-signing/ is stale (does not match the current CA cert used by keystone), it is not possible to start a new instance. This is understandable. However, the stacktrace error you get while trying to start as instance in such a situation is a hugely misleading: "ERROR: Error: unsupported operand type(s) for +: 'NoneType' and 'str'" It's rather tricky to debug the issue. To reproduce just redo the pki-setup for keystone on a deployed and otherwise healthy openstack cluster. This will create a new CA cert for keystone, however neutron-server will be completely oblivious to this fact and will still insist on using it's local copy of the cacert. I'm running Havana on rhel6.4 ---------- /var/log/nova/compute.log on the compute node when trying to start a vm OpenStack (nova:4668) ERROR: Instance failed network setup after 1 attempt(s) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager Traceback (most recent call last): 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1238, in _allocate_network_async 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager dhcp_options=dhcp_options) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/api.py", line 49, in wrapper 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager res = f(self, context, *args, **kwargs) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 358, in allocate_for_instance 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager LOG.exception(msg, port_id) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 323, in allocate_for_instance 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager port_req_body) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 392, in _populate_neutron_extension_values 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager self._refresh_neutron_extensions_cache() 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 376, in _refresh_neutron_extensions_cache 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager extensions_list = neutron.list_extensions()['extensions'] 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 108, in with_params 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager ret = self.function(instance, *args, **kwargs) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 286, in list_extensions 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager return self.get(self.extensions_path, params=_params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1183, in get 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager headers=headers, params=params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1168, in retry_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager headers=headers, params=params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1103, in do_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager resp, replybody = self.httpclient.do_request(action, method, body=body) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 188, in do_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager self.authenticate() 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 224, in authenticate 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager token_url = self.auth_url + "/tokens" 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager ---------------- /var/log/neutron/server.log on the controller when trying to start a vm OpenStack (neutron:29274) DEBUG: Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User- Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role OpenStack (neutron:29274) INFO: Starting new HTTP connection (1): openstack OpenStack (neutron:29274) DEBUG: received {u'_context_roles': [u'admin'], u'_context_read_deleted': u'no', u'_context_tenant_id': None, u'args': {u'agent_state': {u'agent_state': {u'topic': u'N/A', u'binary' : u'neutron-openvswitch-agent', u'host': u'node001', u'agent_type': u'Open vSwitch agent', u'configurations': {u'tunnel_types': [], u'tunneling_ip': u'', u'bridge_mappings': {u'ph-eth0': u'br0'}, u'l2_popula tion': False, u'devices': 0}}}, u'time': u'2014-02-11T12:06:32.434133'}, u'namespace': None, u'_unique_id': u'ae5c6b608f6547f7b630dace2c5411bd', u'_context_is_admin': True, u'version': u'1.0', u'_context_pro ject_id': None, u'_context_timestamp': u'2014-02-11 12:00:14.386557', u'_context_user_id': None, u'method': u'report_state'} OpenStack (neutron:29274) DEBUG: unpacked context: {'user_id': None, 'roles': [u'admin'], 'tenant_id': None, 'is_admin': True, 'timestamp': u'2014-02-11 12:00:14.386557', 'project_id': None, 'read_deleted': u'no'} OpenStack (neutron:29274) DEBUG: "GET /v2.0/tokens/revoked HTTP/1.1" 200 1234 OpenStack (neutron:29274) WARNING: Verify error: Command 'openssl' returned non-zero exit status 4 OpenStack (neutron:29274) DEBUG: Token validation failure. Traceback (most recent call last):   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 808, in _validate_user_token     verified = self.verify_signed_token(user_token)   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1165, in verify_signed_token     if self.is_signed_token_revoked(signed_text):   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1127, in is_signed_token_revoked     revocation_list = self.token_revocation_list   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1217, in token_revocation_list     self.token_revocation_list = self.fetch_revocation_list()   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1247, in fetch_revocation_list     return self.cms_verify(data['signed'])   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1160, in cms_verify     raise err CalledProcessError: Command 'openssl' returned non-zero exit status 4 OpenStack (neutron:29274) DEBUG: Marking token c5e1c4ed4d0ab0db8bbaffbb33e139ba as unauthorized in memcache OpenStack (neutron:29274) WARNING: Authorization failed for token c5e1c4ed4d0ab0db8bbaffbb33e139ba OpenStack (neutron:29274) INFO: Invalid user token - rejecting request To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1278843/+subscriptions From 1350766 at bugs.launchpad.net Mon Sep 8 18:36:39 2014 From: 1350766 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 08 Sep 2014 18:36:39 -0000 Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute intermittently corrupts base images on download from glance References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com> Message-ID: <20140908183640.5527.18049.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/119866 ** Changed in: nova Status: Triaged => In Progress ** Changed in: nova Assignee: (unassigned) => Davanum Srinivas (DIMS) (dims-v) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1350766 Title: Race condition: compute intermittently corrupts base images on download from glance Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Incomplete Bug description: Under certain conditions, which I happen to meet often on my Icehouse single node setup, uploaded images or snapshots fail to boot. See also https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a -snapshot-from-a-running-instance/ Reason: When first instantiating a QCOW2 image, it's (1) downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part (2) converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img The step (1) is performed in nova/image/glance.py, GlanceImageService.download using buffered IO, which does not guarantee the resulting data to be written to disk on file close. Consequently, the source image file may not be written completely when qemu-img sub-process starts reading in step (2). Whether the result is good or bad depends on speed of download, file size, and how quickly qemu-image can digest its input. Proposed fix: enforce fsync on output File object before returning from download. Patch attached. Security considerations: * Due to the race between resources shared between users and tenants (compute node network and filesystem IO) a failure can be triggered across tenants, implying the risk of DoS. * To make things worse -- with the default setting of not cleaning the image cache -- any corrupted image will remain in cache until replaced with fresh upload using a new image ID. Affected snapshots remain unusable forever, until ex- and re-imported manually under better conditions. * Base image corruptions here are not detected and cannot be caught. Theoretically (a bit esoteric, quite unlikely, but not impossible), an attacker might modulate resource usage to precisely create an incompletely written image, that boots and runs, but has access control information stripped. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1350766/+subscriptions From travis.mcpeak at hp.com Mon Sep 8 22:52:46 2014 From: travis.mcpeak at hp.com (Travis McPeak) Date: Mon, 08 Sep 2014 22:52:46 -0000 Subject: [Openstack-security] [Bug 1367022] [NEW] Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Public bug reported: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. ** Affects: ceilometer Importance: Undecided Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From fungi at yuggoth.org Mon Sep 8 23:50:35 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 08 Sep 2014 23:50:35 -0000 Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute intermittently corrupts base images on download from glance References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com> Message-ID: <20140908235035.18348.54102.malone@chaenomeles.canonical.com> I've marked the OSSA task as "won't fix" to indicate this issue isn't one for which the project vulnerability management team would publish a coordinated security advisory, as the conditions by which it is triggered do not seem to be under direct control of a malicious actor but rather one of volume and statistical happenstance. This does definitely still sound like an annoying bug, however, and one which the Nova developers will hopefully address in a timely manner. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1350766 Title: Race condition: compute intermittently corrupts base images on download from glance Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Under certain conditions, which I happen to meet often on my Icehouse single node setup, uploaded images or snapshots fail to boot. See also https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a -snapshot-from-a-running-instance/ Reason: When first instantiating a QCOW2 image, it's (1) downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part (2) converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img The step (1) is performed in nova/image/glance.py, GlanceImageService.download using buffered IO, which does not guarantee the resulting data to be written to disk on file close. Consequently, the source image file may not be written completely when qemu-img sub-process starts reading in step (2). Whether the result is good or bad depends on speed of download, file size, and how quickly qemu-image can digest its input. Proposed fix: enforce fsync on output File object before returning from download. Patch attached. Security considerations: * Due to the race between resources shared between users and tenants (compute node network and filesystem IO) a failure can be triggered across tenants, implying the risk of DoS. * To make things worse -- with the default setting of not cleaning the image cache -- any corrupted image will remain in cache until replaced with fresh upload using a new image ID. Affected snapshots remain unusable forever, until ex- and re-imported manually under better conditions. * Base image corruptions here are not detected and cannot be caught. Theoretically (a bit esoteric, quite unlikely, but not impossible), an attacker might modulate resource usage to precisely create an incompletely written image, that boots and runs, but has access control information stripped. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1350766/+subscriptions From maurice at leeflang.net Tue Sep 9 09:06:02 2014 From: maurice at leeflang.net (Maurice Leeflang) Date: Tue, 09 Sep 2014 09:06:02 -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: <20140909090602.17709.35255.malone@chaenomeles.canonical.com> Agreed, and I managed to avoid bringing all running instances down by chowning the disk and monitor files to group nova and then chmod g+w on those files. Then, assuming all nova nodes are using the working qemu configuration, it is possible to live migrate the instances, and after that migration, the files can also be chowned to user nova. That way there is no need for downtime -- You received this bug notification because you are a member of OpenStack Security Group, 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): Confirmed 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 doug at doughellmann.com Tue Sep 9 13:10:45 2014 From: doug at doughellmann.com (Doug Hellmann) Date: Tue, 09 Sep 2014 13:10:45 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140909131048.32745.94858.launchpad@gac.canonical.com> ** Changed in: oslo.vmware Milestone: None => juno-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): Confirmed Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From 1350766 at bugs.launchpad.net Tue Sep 9 13:18:42 2014 From: 1350766 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 09 Sep 2014 13:18:42 -0000 Subject: [Openstack-security] [Bug 1350766] Change abandoned on nova (master) References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com> Message-ID: <20140909131842.32158.25747.malone@gac.canonical.com> Change abandoned by Davanum Srinivas (dims) (davanum at gmail.com) on branch: master Review: https://review.openstack.org/119866 Reason: Looks like there are major issues with this approach. need to find another way -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1350766 Title: Race condition: compute intermittently corrupts base images on download from glance Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Under certain conditions, which I happen to meet often on my Icehouse single node setup, uploaded images or snapshots fail to boot. See also https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a -snapshot-from-a-running-instance/ Reason: When first instantiating a QCOW2 image, it's (1) downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part (2) converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img The step (1) is performed in nova/image/glance.py, GlanceImageService.download using buffered IO, which does not guarantee the resulting data to be written to disk on file close. Consequently, the source image file may not be written completely when qemu-img sub-process starts reading in step (2). Whether the result is good or bad depends on speed of download, file size, and how quickly qemu-image can digest its input. Proposed fix: enforce fsync on output File object before returning from download. Patch attached. Security considerations: * Due to the race between resources shared between users and tenants (compute node network and filesystem IO) a failure can be triggered across tenants, implying the risk of DoS. * To make things worse -- with the default setting of not cleaning the image cache -- any corrupted image will remain in cache until replaced with fresh upload using a new image ID. Affected snapshots remain unusable forever, until ex- and re-imported manually under better conditions. * Base image corruptions here are not detected and cannot be caught. Theoretically (a bit esoteric, quite unlikely, but not impossible), an attacker might modulate resource usage to precisely create an incompletely written image, that boots and runs, but has access control information stripped. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1350766/+subscriptions From fungi at yuggoth.org Tue Sep 9 15:32:00 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 09 Sep 2014 15:32:00 -0000 Subject: [Openstack-security] [Bug 1367000] Re: Malicious name could lead to local information disclosure vulnerability References: <20140908220415.25176.20373.malonedeb@soybean.canonical.com> Message-ID: <20140909153200.32545.21449.launchpad@gac.canonical.com> ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags removed: security ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367000 Title: Malicious name could lead to local information disclosure vulnerability Status in Cinder: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: In the cinder scality driver, the following code sets file permissions to 0o666 (read, write for all users): https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L118 This code is called in a couple of locations, one of which is here: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L172 That line of code gets the filename from this function: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L185 Which joins two paths, one of which is this: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L181 Which joins two paths, one of which is volume['name'] which is un- sanitized input. If a malicious user sets a volume name to something like "/etc/passwd", the /etc/passwd permissions will be set to '0o666' with the privileges of the user that is running Cinder. This could be used to expose files and sensitive data on the machine that is running Cinder. If combined with another vulnerability this could lead to some really bad things. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1367000/+subscriptions From travis.mcpeak at hp.com Tue Sep 9 15:35:08 2014 From: travis.mcpeak at hp.com (Travis McPeak) Date: Tue, 09 Sep 2014 15:35:08 -0000 Subject: [Openstack-security] [Bug 1367000] Re: Malicious name could lead to local information disclosure vulnerability References: <20140908220415.25176.20373.malonedeb@soybean.canonical.com> Message-ID: <20140909153508.17647.3478.malone@chaenomeles.canonical.com> My apologies, I thought 'name' and 'display-name' were the same. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367000 Title: Malicious name could lead to local information disclosure vulnerability Status in Cinder: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: In the cinder scality driver, the following code sets file permissions to 0o666 (read, write for all users): https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L118 This code is called in a couple of locations, one of which is here: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L172 That line of code gets the filename from this function: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L185 Which joins two paths, one of which is this: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L181 Which joins two paths, one of which is volume['name'] which is un- sanitized input. If a malicious user sets a volume name to something like "/etc/passwd", the /etc/passwd permissions will be set to '0o666' with the privileges of the user that is running Cinder. This could be used to expose files and sensitive data on the machine that is running Cinder. If combined with another vulnerability this could lead to some really bad things. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1367000/+subscriptions From duncan.thomas at gmail.com Tue Sep 9 15:59:17 2014 From: duncan.thomas at gmail.com (Duncan Thomas) Date: Tue, 09 Sep 2014 15:59:17 -0000 Subject: [Openstack-security] [Bug 1367000] Re: Malicious name could lead to local information disclosure vulnerability References: <20140908220415.25176.20373.malonedeb@soybean.canonical.com> Message-ID: <20140909155919.17908.5476.launchpad@chaenomeles.canonical.com> ** Changed in: cinder Importance: Undecided => Low ** Tags added: drivers-scality -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367000 Title: Malicious name could lead to local information disclosure vulnerability Status in Cinder: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: In the cinder scality driver, the following code sets file permissions to 0o666 (read, write for all users): https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L118 This code is called in a couple of locations, one of which is here: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L172 That line of code gets the filename from this function: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L185 Which joins two paths, one of which is this: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L181 Which joins two paths, one of which is volume['name'] which is un- sanitized input. If a malicious user sets a volume name to something like "/etc/passwd", the /etc/passwd permissions will be set to '0o666' with the privileges of the user that is running Cinder. This could be used to expose files and sensitive data on the machine that is running Cinder. If combined with another vulnerability this could lead to some really bad things. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1367000/+subscriptions From duncan.thomas at gmail.com Tue Sep 9 17:07:55 2014 From: duncan.thomas at gmail.com (Duncan Thomas) Date: Tue, 09 Sep 2014 17:07:55 -0000 Subject: [Openstack-security] [Bug 1367000] Re: Malicious name could lead to local information disclosure vulnerability References: <20140908220415.25176.20373.malonedeb@soybean.canonical.com> <20140909165522.310.67714.malone@gac.canonical.com> Message-ID: I have vague memories of somebody needing '.' too due to a weird backend, but that should be harmless as long as we require %s On 9 September 2014 17:55, Eric Harney <1367000 at bugs.launchpad.net> wrote: > I assume the volume/snapshot/backup_name_template options are rarely > changed by deployers. > > For Duncan's suggestion, I'd propose we allow a limited set of > characters for those options: alphanumeric, "-", and require the "%s" to > be present, which should eliminate the concerns here. > > -- > You received this bug notification because you are a member of Cinder > Bug Team, which is subscribed to Cinder. > https://bugs.launchpad.net/bugs/1367000 > > Title: > Malicious name could lead to local information disclosure > vulnerability > > Status in Cinder: > Confirmed > Status in OpenStack Security Advisories: > Won't Fix > > Bug description: > In the cinder scality driver, the following code sets file permissions to 0o666 (read, write for all users): > https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L118 > > This code is called in a couple of locations, one of which is here: > https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L172 > > That line of code gets the filename from this function: > https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L185 > > Which joins two paths, one of which is this: > https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L181 > > Which joins two paths, one of which is volume['name'] which is un- > sanitized input. If a malicious user sets a volume name to something > like "/etc/passwd", the /etc/passwd permissions will be set to '0o666' > with the privileges of the user that is running Cinder. This could be > used to expose files and sensitive data on the machine that is running > Cinder. If combined with another vulnerability this could lead to > some really bad things. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cinder/+bug/1367000/+subscriptions -- Duncan Thomas -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367000 Title: Malicious name could lead to local information disclosure vulnerability Status in Cinder: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: In the cinder scality driver, the following code sets file permissions to 0o666 (read, write for all users): https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L118 This code is called in a couple of locations, one of which is here: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L172 That line of code gets the filename from this function: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L185 Which joins two paths, one of which is this: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L181 Which joins two paths, one of which is volume['name'] which is un- sanitized input. If a malicious user sets a volume name to something like "/etc/passwd", the /etc/passwd permissions will be set to '0o666' with the privileges of the user that is running Cinder. This could be used to expose files and sensitive data on the machine that is running Cinder. If combined with another vulnerability this could lead to some really bad things. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1367000/+subscriptions From 1118194 at bugs.launchpad.net Tue Sep 9 18:04:55 2014 From: 1118194 at bugs.launchpad.net (Andreas Jaeger) Date: Tue, 09 Sep 2014 18:04:55 -0000 Subject: [Openstack-security] [Bug 1118194] Re: Security Documentation for Horizon References: <20130207100009.11250.38496.malonedeb@chaenomeles.canonical.com> Message-ID: <20140909180459.32267.47041.launchpad@gac.canonical.com> ** Changed in: openstack-manuals Status: Confirmed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is a bug assignee. https://bugs.launchpad.net/bugs/1118194 Title: Security Documentation for Horizon Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Manuals: Fix Released Bug description: Horizon's documentation doesn't contain much in terms of guidelines for securing a deployment. The following should be documented somewhere: When implementing Horizon for public usage, with the website served through HTTPS, the following recommendations apply. In the Apache global configuration ensure that the following directive is configured to prevent the server from sharing its name, version and any other information that could be used for an attack: ServerSignature Off In the Apache global configuration ensure that the following directive is configured to prevent cross-site tracing [1]: TraceEnable Off In the Apache virtual host configuration: 1) Ensure that the "Indexes" option is not included in the Options directive. 2) Protect the server from BEAST attacks [2] by implementing the following options:   SSLHonorCipherOrder on   SSLProtocol -ALL +SSLv3 +TLSv1   SSLCipherSuite RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!ADH:!AESGCM:!AES In local_settings.py, implement the following settings in order to help protect the cookies from cross-site scripting [3]: CSRF_COOKIE_SECURE = True SESSION_COOKIE_SECURE = True SESSION_COOKIE_HTTPONLY = True Note that the CSRF_COOKIE_SECURE option is only available from Django 1.4 and will therefore not work for most packaged Essex deployments. Also, since a recent patch [4], you can disable browser autocompletion [5] for the authentication form by changing the 'password_autocomplete' attribute to 'off' in horizon/conf/default.py. [1] http://www.kb.cert.org/vuls/id/867593 [2] http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack [3] https://www.owasp.org/index.php/HttpOnly [4] https://review.openstack.org/21349 [5] https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1118194/+subscriptions From 1341954 at bugs.launchpad.net Wed Sep 10 10:48:07 2014 From: 1341954 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 10 Sep 2014 10:48:07 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140910104807.32675.70308.malone@gac.canonical.com> Reviewed: https://review.openstack.org/118565 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=3c3530db2445eca9be583715ff689bd746e6d387 Submitter: Jenkins Branch: stable/havana commit 3c3530db2445eca9be583715ff689bd746e6d387 Author: Vipin Balachandran Date: Fri Aug 22 10:19:29 2014 +0530 VMware: Disable suds caching The default cache implementation in suds store pickled objects in a predictable path in /tmp which could lead to attacks. This patch turns off suds caching to address this security issue. Conflicts: cinder/volume/drivers/vmware/pbm.py Change-Id: I7daaa25a0677004e03896298e9c3026d5c33c6ac Closes-Bug: #1341954 (cherry picked from commit 6a41fe9c5c98a14a355fa81b41aae2c4b0ce0a7b) ** Tags added: in-stable-havana -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): Confirmed Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From sean at dague.net Wed Sep 10 11:43:19 2014 From: sean at dague.net (Sean Dague) Date: Wed, 10 Sep 2014 11:43:19 -0000 Subject: [Openstack-security] [Bug 1365712] Re: Command Execution Possible Through Config File Tampering References: <20140904211316.25282.32054.malonedeb@soybean.canonical.com> Message-ID: <20140910114319.5205.69295.malone@wampee.canonical.com> Right, if you have write access to etc on the box... then all bets are off. ** Changed in: nova Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1365712 Title: Command Execution Possible Through Config File Tampering Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The OpenStack Security Group has been reviewing OpenStack code to find potential security vulnerabilities. One class of these vulnerabilities is to allow someone with write access to nova.conf to cause code to be executed as the OpenStack user. Some details are here: https://review.openstack.org/#/c/118910/ More tracking information is here: https://bugs.launchpad.net/nova/+bug/1192971 This bug is specifically to address the possible vulnerability at nova/nova/virt/baremetal/ipmi.py:292 If a user has write access to nova.conf, he can set [baremetal] terminal = /bin/foo and cause /bin/foo to be executed. If a user has write access to nova.conf, he case set [baremetal] terminal_cert_dir = "; cat /etc/passwd" and cause the password file to be written to stdout. Some input validation would help correct this. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1365712/+subscriptions From sean at dague.net Wed Sep 10 12:08:37 2014 From: sean at dague.net (Sean Dague) Date: Wed, 10 Sep 2014 12:08:37 -0000 Subject: [Openstack-security] [Bug 1360260] Re: 'allow_same_net_traffic=true' has no effect References: <20140822131915.17201.76910.malonedeb@chaenomeles.canonical.com> Message-ID: <20140910120838.32380.24358.launchpad@gac.canonical.com> ** Also affects: openstack-manuals Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1360260 Title: 'allow_same_net_traffic=true' has no effect Status in OpenStack Compute (Nova): New Status in OpenStack Manuals: New Bug description: environment: Ubuntu trusty, icehouse from repos. Setup per 'Openstack Installation Guide for Ubuntu 12.04/14.04 LTS' **brief** two instances X and Y are members of security group A. Despite the following explicit setting in nova.conf: allow_same_net_traffic=True ...the instances are only allowed to communicate according to the rules defined in security group A. **detail** I first noticed this attempting to run iperf between two instances on the same security network; they were unable to connect via the default TCP port 5001. They were able to ping...looking at rules for the security group they are are associated with, ping was allowed, so I then suspected the security group rules were being applied to all communication, despite them being on the same security group. To test, I added rules to group A that allowed all communication, and associated the rules with itself (i.e. security group A) and voila, they could talk! I then thought I had remembered incorrectly that by default all traffic is allowed between instances on the same security group, so I double-checked the documentation, but according to the documentation I had remembered correctly: allow_same_net_traffic = True (BoolOpt) Whether to allow network traffic from same network ...I searched through my nova.conf files, but there was no 'allow_same_net_traffic' entry, so the default ought to be True, right? Just to be sure, I explicitly added: allow_same_net_traffic = True to nova.conf and restarted nova services, but the security group rules are still being applied to communication between instances that are associated with the same security group. I thought the 'default' security group might be a special case, so I tested on another security group, but still get the same behaviour. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1360260/+subscriptions From travis.mcpeak at hp.com Wed Sep 10 14:28:33 2014 From: travis.mcpeak at hp.com (Travis McPeak) Date: Wed, 10 Sep 2014 14:28:33 -0000 Subject: [Openstack-security] [Bug 1367000] Re: Malicious name could lead to local information disclosure vulnerability References: <20140908220415.25176.20373.malonedeb@soybean.canonical.com> Message-ID: <20140910142833.32220.14731.malone@gac.canonical.com> What about for the file permissions issue? We should at least lock it down so that the files it creates are only readable/writeable for the specific cinder user, otherwise anybody on the box can tamper with/read sensitive data from these files. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367000 Title: Malicious name could lead to local information disclosure vulnerability Status in Cinder: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: In the cinder scality driver, the following code sets file permissions to 0o666 (read, write for all users): https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L118 This code is called in a couple of locations, one of which is here: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L172 That line of code gets the filename from this function: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L185 Which joins two paths, one of which is this: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L181 Which joins two paths, one of which is volume['name'] which is un- sanitized input. If a malicious user sets a volume name to something like "/etc/passwd", the /etc/passwd permissions will be set to '0o666' with the privileges of the user that is running Cinder. This could be used to expose files and sensitive data on the machine that is running Cinder. If combined with another vulnerability this could lead to some really bad things. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1367000/+subscriptions From gerrit2 at review.openstack.org Thu Sep 11 18:52:39 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 11 Sep 2014 18:52:39 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/120881 Log: commit ac6cf599e8b3ad41faf3fef5e05548b7e8bcc7e8 Author: Tristan Cacqueray Date: Thu Sep 11 16:31:24 2014 +0000 Fix password leak from ProcessExecution errors This backport the necessary changes to fix both issues: * Make execute method clean password in exeception * Make sure mask_password works properly The backport is not trivial as these fix relies on many other changes, only the necesasry code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 6a60f842 - Mask passwords in exceptions and error messages (ssh) 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From sean at dague.net Thu Sep 11 19:15:01 2014 From: sean at dague.net (Sean Dague) Date: Thu, 11 Sep 2014 19:15:01 -0000 Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com> Message-ID: <20140911191501.25176.10744.malone@soybean.canonical.com> The only place this exists inside nova is db tests and tools that are meant to be run locally, and the baremetal driver, which we are about to delete. So this is a won't fix. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348416 Title: Popen with shell=True Status in OpenStack Image Registry and Delivery Service (Glance): Confirmed Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Bug description: Glance uses subprocess.Popen with shell=True in glance/tests/unit/test_migrations.py line 175 in function _reset_datases: def execute_cmd(cmd=None): proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True) If execute_cmd contains, either accidentally or maliciously, a double quote then arbitrary data will be executed. Popen should be called with an argument list instead of directly through the shell. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently-used- arguments Since these are unit tests and the likelihood of malicious input is low the severity should also be low. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1348416/+subscriptions From sean at dague.net Thu Sep 11 21:33:41 2014 From: sean at dague.net (Sean Dague) Date: Thu, 11 Sep 2014 21:33:41 -0000 Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com> Message-ID: <20140911213342.4904.14529.launchpad@wampee.canonical.com> ** No longer affects: nova -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348416 Title: Popen with shell=True Status in OpenStack Image Registry and Delivery Service (Glance): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: Glance uses subprocess.Popen with shell=True in glance/tests/unit/test_migrations.py line 175 in function _reset_datases: def execute_cmd(cmd=None): proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True) If execute_cmd contains, either accidentally or maliciously, a double quote then arbitrary data will be executed. Popen should be called with an argument list instead of directly through the shell. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently-used- arguments Since these are unit tests and the likelihood of malicious input is low the severity should also be low. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1348416/+subscriptions From gerrit2 at review.openstack.org Thu Sep 11 23:22:30 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 11 Sep 2014 23:22:30 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/120881 Log: commit 3344affe60e261121005fff8c43e078263cc76ac Author: Tristan Cacqueray Date: Thu Sep 11 16:31:24 2014 +0000 Fix password leak from ProcessExecution errors This backport the necessary changes to fix both issues: * Make execute method clean password in exeception * Make sure mask_password works properly The backport is not trivial as these fix relies on many other changes, only the necesasry code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From sean at dague.net Fri Sep 12 01:19:52 2014 From: sean at dague.net (Sean Dague) Date: Fri, 12 Sep 2014 01:19:52 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140912011955.32512.1926.launchpad@gac.canonical.com> ** Changed in: nova Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Notes: In Progress Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From gerrit2 at review.openstack.org Fri Sep 12 01:32:19 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 12 Sep 2014 01:32:19 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/120881 Log: commit b50add90d8ec9402d73453f73c40ce283ac5c180 Author: Tristan Cacqueray Date: Thu Sep 11 16:31:24 2014 +0000 Fix password leak from ProcessExecution errors This backport the necessary changes to fix both issues: * Make execute method clean password in exeception * Make sure mask_password works properly The backport is not trivial as these fix relies on many other changes, only the necesasry code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From nkinder at redhat.com Fri Sep 12 04:25:46 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 12 Sep 2014 04:25:46 -0000 Subject: [Openstack-security] [Bug 1365712] Re: Command Execution Possible Through Config File Tampering References: <20140904211316.25282.32054.malonedeb@soybean.canonical.com> Message-ID: <20140912042547.32442.56861.malone@gac.canonical.com> This is already covered by published note OSSN-0026: https://wiki.openstack.org/wiki/OSSN/OSSN-0026 ** Changed in: ossn Status: New => Fix Released ** Changed in: ossn Assignee: (unassigned) => Travis McPeak (travis-mcpeak) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1365712 Title: Command Execution Possible Through Config File Tampering Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: The OpenStack Security Group has been reviewing OpenStack code to find potential security vulnerabilities. One class of these vulnerabilities is to allow someone with write access to nova.conf to cause code to be executed as the OpenStack user. Some details are here: https://review.openstack.org/#/c/118910/ More tracking information is here: https://bugs.launchpad.net/nova/+bug/1192971 This bug is specifically to address the possible vulnerability at nova/nova/virt/baremetal/ipmi.py:292 If a user has write access to nova.conf, he can set [baremetal] terminal = /bin/foo and cause /bin/foo to be executed. If a user has write access to nova.conf, he case set [baremetal] terminal_cert_dir = "; cat /etc/passwd" and cause the password file to be written to stdout. Some input validation would help correct this. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1365712/+subscriptions From nkinder at redhat.com Fri Sep 12 04:27:50 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 12 Sep 2014 04:27:50 -0000 Subject: [Openstack-security] [Bug 1316822] Re: soft reboot of instance does not ensure iptables rules are present References: <20140506221318.20885.39818.malonedeb@gac.canonical.com> Message-ID: <20140912042751.24784.5159.malone@soybean.canonical.com> This was published as OSSN-0022: https://wiki.openstack.org/wiki/OSSN/OSSN-0022 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316822 Title: soft reboot of instance does not ensure iptables rules are present Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: The iptables rules needed to implement instance security group rules get inserted by the "_create_domain_and_network" function in nova/virt/libvirt/driver.py This function is called by the following functions: _hard_reboot, resume and spawn (also in a couple of migration related functions). Doing "nova reboot " only does a soft reboot (_soft_reboot) and assumes that the rules are already present and therefore does not check or try to add them. If the instances is stopped (nova stop ) and nova-compute is restarted (for example for a maintenance or problem), the iptables rules are removed as observed via output displayed in iptables -S. If the instance is started via nova reboot the rule is NOT reapplied until a service nova-compute restart is issued. I have reports that this may affect "nova start " as well. Depending on if the Cloud is public facing, this opens up a potentially huge security vulnerability as an instance can be powered on without being protected by any security group rules (not even the sg-fallback rule). This is unbeknownst to the instance owner or Cloud operators unless they specifically monitor for this situation. The code should not do a soft reboot/start and error out or fallback to a resume (start)or hard reboot if it detects that the domain is not running. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316822/+subscriptions From thierry.carrez+lp at gmail.com Fri Sep 12 08:39:06 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 12 Sep 2014 08:39:06 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140912083907.18348.76785.launchpad@chaenomeles.canonical.com> ** 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 Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Incomplete Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From gerrit2 at review.openstack.org Fri Sep 12 12:56:00 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 12 Sep 2014 12:56:00 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121095 Log: commit bcc1456f56f1e0f099ada7bc4d391ae9e4c9c36a Author: Tristan Cacqueray Date: Fri Sep 12 12:51:11 2014 +0000 Sync latest processutils from oslo-incubator This backport the necessary changes to fix both issues: * Make execute method clean password in exeception * Make sure mask_password works properly Backport review: https://review.openstack.org/120881/ Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Fri Sep 12 13:00:17 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 12 Sep 2014 13:00:17 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121096 Log: commit ffbfd75285096672882116858bac68a8dc871930 Author: Tristan Cacqueray Date: Fri Sep 12 12:58:24 2014 +0000 Sync latest processutils from oslo-incubator This backport the necessary changes to fix both issues: * Make execute method clean password in exeception * Make sure mask_password works properly Backport review: https://review.openstack.org/120881/ Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From sean at dague.net Fri Sep 12 14:55:01 2014 From: sean at dague.net (Sean Dague) Date: Fri, 12 Sep 2014 14:55:01 -0000 Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should not be world-readable References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com> Message-ID: <20140912145502.17647.65684.malone@chaenomeles.canonical.com> Honestly, if you have shell users on your compute... things are all kinds of bad. ** Changed in: nova Status: New => Opinion ** Changed in: nova Importance: Medium => Low -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (Nova): Opinion Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions From michael_steffens at posteo.de Fri Sep 12 15:00:41 2014 From: michael_steffens at posteo.de (Michael Steffens) Date: Fri, 12 Sep 2014 15:00:41 -0000 Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute intermittently corrupts base images on download from glance References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com> Message-ID: <20140912150041.32545.16547.malone@gac.canonical.com> Filed a bug report for qemu-img: https://bugs.launchpad.net/qemu/+bug/1368815 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1350766 Title: Race condition: compute intermittently corrupts base images on download from glance Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Under certain conditions, which I happen to meet often on my Icehouse single node setup, uploaded images or snapshots fail to boot. See also https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a -snapshot-from-a-running-instance/ Reason: When first instantiating a QCOW2 image, it's (1) downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part (2) converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img The step (1) is performed in nova/image/glance.py, GlanceImageService.download using buffered IO, which does not guarantee the resulting data to be written to disk on file close. Consequently, the source image file may not be written completely when qemu-img sub-process starts reading in step (2). Whether the result is good or bad depends on speed of download, file size, and how quickly qemu-image can digest its input. Proposed fix: enforce fsync on output File object before returning from download. Patch attached. Security considerations: * Due to the race between resources shared between users and tenants (compute node network and filesystem IO) a failure can be triggered across tenants, implying the risk of DoS. * To make things worse -- with the default setting of not cleaning the image cache -- any corrupted image will remain in cache until replaced with fresh upload using a new image ID. Affected snapshots remain unusable forever, until ex- and re-imported manually under better conditions. * Base image corruptions here are not detected and cannot be caught. Theoretically (a bit esoteric, quite unlikely, but not impossible), an attacker might modulate resource usage to precisely create an incompletely written image, that boots and runs, but has access control information stripped. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1350766/+subscriptions From sean at dague.net Fri Sep 12 15:11:08 2014 From: sean at dague.net (Sean Dague) Date: Fri, 12 Sep 2014 15:11:08 -0000 Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute intermittently corrupts base images on download from glance References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com> Message-ID: <20140912151109.18167.16668.launchpad@chaenomeles.canonical.com> *** This bug is a duplicate of bug 1368815 *** https://bugs.launchpad.net/bugs/1368815 ** This bug has been marked a duplicate of bug 1368815 qemu-img convert intermittently corrupts output images -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1350766 Title: Race condition: compute intermittently corrupts base images on download from glance Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Under certain conditions, which I happen to meet often on my Icehouse single node setup, uploaded images or snapshots fail to boot. See also https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a -snapshot-from-a-running-instance/ Reason: When first instantiating a QCOW2 image, it's (1) downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part (2) converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img The step (1) is performed in nova/image/glance.py, GlanceImageService.download using buffered IO, which does not guarantee the resulting data to be written to disk on file close. Consequently, the source image file may not be written completely when qemu-img sub-process starts reading in step (2). Whether the result is good or bad depends on speed of download, file size, and how quickly qemu-image can digest its input. Proposed fix: enforce fsync on output File object before returning from download. Patch attached. Security considerations: * Due to the race between resources shared between users and tenants (compute node network and filesystem IO) a failure can be triggered across tenants, implying the risk of DoS. * To make things worse -- with the default setting of not cleaning the image cache -- any corrupted image will remain in cache until replaced with fresh upload using a new image ID. Affected snapshots remain unusable forever, until ex- and re-imported manually under better conditions. * Base image corruptions here are not detected and cannot be caught. Theoretically (a bit esoteric, quite unlikely, but not impossible), an attacker might modulate resource usage to precisely create an incompletely written image, that boots and runs, but has access control information stripped. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1350766/+subscriptions From gerrit2 at review.openstack.org Fri Sep 12 17:25:59 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 12 Sep 2014 17:25:59 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/120881 Log: commit 170e8078991fea7e6118eae84fda6de2041a2b1e Author: Tristan Cacqueray Date: Thu Sep 11 16:31:24 2014 +0000 Fix password leak from ProcessExecution errors This backport required changes to fix both issues: * Make execute method clean password in exeception * Make sure mask_password works properly This backport is not trivial as these fixes relies on many other changes, only the necessary code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Fri Sep 12 17:26:28 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 12 Sep 2014 17:26:28 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/120881 Log: commit a8cecfb569a3a8d36eaa8ad7824db37b60c0ed5a Author: Tristan Cacqueray Date: Thu Sep 11 16:31:24 2014 +0000 Fix password leak from ProcessExecution errors This backport required changes to fix both issues: * Make execute method clean password in exeception * Make sure mask_password works properly This backport is not trivial as these fixes relies on many other changes, only the necessary code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Fri Sep 12 17:28:59 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 12 Sep 2014 17:28:59 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/120881 Log: commit 4cf1a2a158f7c3c21799bf2e6ba0e7b5fbc25d62 Author: Tristan Cacqueray Date: Thu Sep 11 16:31:24 2014 +0000 Fix password leak from ProcessExecution errors This backport required changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly This backport is not trivial as these fixes relies on many other changes, only the necessary code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Fri Sep 12 17:30:14 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 12 Sep 2014 17:30:14 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121095 Log: commit a3e02f8a958b32605205e478096ac924247396b2 Author: Tristan Cacqueray Date: Fri Sep 12 12:51:11 2014 +0000 Sync latest processutils from oslo-incubator This backport the necessary changes to fix both issues: * Make execute method clean password in execption * Make sure mask_password works properly Backport review: https://review.openstack.org/120881/ Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Fri Sep 12 17:30:24 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 12 Sep 2014 17:30:24 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121096 Log: commit 725395de2925820050719dce0492f6fca1ebdd54 Author: Tristan Cacqueray Date: Fri Sep 12 12:58:24 2014 +0000 Sync latest processutils from oslo-incubator This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport review: https://review.openstack.org/120881/ Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Fri Sep 12 17:30:31 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 12 Sep 2014 17:30:31 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121095 Log: commit 1460ddc1f8e42947a3612d6a809b279a9c6ec4e4 Author: Tristan Cacqueray Date: Fri Sep 12 12:51:11 2014 +0000 Sync latest processutils from oslo-incubator This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport review: https://review.openstack.org/120881/ Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From sean at dague.net Fri Sep 12 22:25:19 2014 From: sean at dague.net (Sean Dague) Date: Fri, 12 Sep 2014 22:25:19 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140912222519.18210.56964.malone@chaenomeles.canonical.com> This is definitely still in nova in a few places. I kind of thing this should be an RC bug to actually clean up the rest of this. ** Changed in: nova Importance: Undecided => High ** Changed in: nova Assignee: Xurong Yang (idopra) => (unassigned) ** Changed in: nova Importance: High => Critical ** Changed in: nova Milestone: None => juno-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From nathanael.i.burton.work at gmail.com Sat Sep 13 00:13:35 2014 From: nathanael.i.burton.work at gmail.com (Nathanael Burton) Date: Sat, 13 Sep 2014 00:13:35 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140913001335.25076.92610.malone@soybean.canonical.com> Sean, I agree. Here's one that's almost through gerrit after *only* seven months of review for a tiny change. https://bugs.launchpad.net/nova/+bug/1279381 https://review.openstack.org/#/c/72974/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From gerrit2 at review.openstack.org Sat Sep 13 15:53:19 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 15:53:19 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121095 Log: commit 20a0f25b4839a27b5ea45ff3cc17b1841b0565fb Author: Tristan Cacqueray Date: Sat Sep 13 15:51:44 2014 +0000 Sync latest processutils from oslo-incubator This backport the necessary changes to fix both issues: * Make execute method clean password in exeception * Make sure mask_password works properly Backport review: https://review.openstack.org/120881/ Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sat Sep 13 15:59:43 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 15:59:43 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121095 Log: commit b5992fc00d99bc428f6cef77ce39c08421710c68 Author: Tristan Cacqueray Date: Sat Sep 13 15:51:44 2014 +0000 Sync latest processutils from oslo-incubator This backport the necessary changes to fix both issues: * Make execute method clean password in exeception * Make sure mask_password works properly Backport review: https://review.openstack.org/120881/ Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sat Sep 13 17:28:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 17:28:02 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121096 Log: commit b1222c84ef2d046aef1844506e2b0b87a89e3b75 Author: Tristan Cacqueray Date: Fri Sep 12 12:58:24 2014 +0000 Sync latest processutils from oslo-incubator This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport review: https://review.openstack.org/120881/ Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sat Sep 13 17:31:37 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 17:31:37 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121365 Log: commit d54b4dc1597dd3baee3c934face55d98028a79a3 Author: Tristan Cacqueray Date: Thu Sep 11 16:31:24 2014 +0000 Fix password leak from ProcessExecution errors This backport required changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly This backport is not trivial as these fixes relies on many other changes, only the necessary code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Conflicts: openstack/common/processutils.py tests/unit/test_strutils.py Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 (cherry picked from commit 4cf1a2a158f7c3c21799bf2e6ba0e7b5fbc25d62) From gerrit2 at review.openstack.org Sat Sep 13 17:42:29 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 17:42:29 +0000 Subject: [Openstack-security] [openstack/oslo-incubator] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121365 Log: commit 485ea7470fa5dd962e26cbb907a964377516db7f Author: Tristan Cacqueray Date: Thu Sep 11 16:31:24 2014 +0000 Fix password leak from ProcessExecution errors This backport required changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly This backport is not trivial as these fixes relies on many other changes, only the necessary code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Conflicts: openstack/common/processutils.py tests/unit/test_strutils.py Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 (cherry picked from commit 4cf1a2a158f7c3c21799bf2e6ba0e7b5fbc25d62) From gerrit2 at review.openstack.org Sat Sep 13 18:18:41 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 18:18:41 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121095 Log: commit 08d0912272906f6585eec17af3117f5acb30dbbf Author: Tristan Cacqueray Date: Sat Sep 13 15:51:44 2014 +0000 Sync latest processutils from oslo-incubator This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport in oslo: 4cf1a2a158f7c3c21799bf2e6ba0e7b5fbc25d62 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sat Sep 13 19:09:48 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 19:09:48 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121095 Log: commit 7accbe8726ebc908e70fb4b25b48bd259e437188 Author: Tristan Cacqueray Date: Sat Sep 13 15:51:44 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport in oslo-incubator: 4cf1a2a158f7c3c21799bf2e6ba0e7b5fbc25d62 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sat Sep 13 19:12:36 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 19:12:36 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121095 Log: commit 6772d5ffb2ca3fbfb0accebaed0cea18b80a03e0 Author: Tristan Cacqueray Date: Sat Sep 13 15:51:44 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport in oslo-incubator: 4cf1a2a158f7c3c21799bf2e6ba0e7b5fbc25d62 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sat Sep 13 19:23:53 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 19:23:53 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121096 Log: commit 34611b3e369f4b78c6575281858d60907ceca92d Author: Tristan Cacqueray Date: Fri Sep 12 12:58:24 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport in oslo-incubator: 4cf1a2a158f7c3c21799bf2e6ba0e7b5fbc25d62 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sat Sep 13 19:36:25 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 19:36:25 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121382 Log: commit 2d508e3417ea83fd768c14c4eac41af14eb1f811 Author: Tristan Cacqueray Date: Sat Sep 13 18:12:05 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport in oslo-incubator: https://review.openstack.org/121365 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sat Sep 13 19:37:52 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 13 Sep 2014 19:37:52 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121383 Log: commit 839bd70a47b43aa72a43321a5b308b29ef986330 Author: Tristan Cacqueray Date: Sat Sep 13 18:54:33 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport in oslo-incubator: https://review.openstack.org/121365 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sun Sep 14 18:56:43 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 14 Sep 2014 18:56:43 +0000 Subject: [Openstack-security] [openstack/trove] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121416 Log: commit faa23cb312f6e3ee1a92270d53c09b2fd4744c18 Author: Tristan Cacqueray Date: Sun Sep 14 18:17:40 2014 +0000 Sync latest process and str utils from oslo This sync required changes to fix these issues: * Make execute method clean password in exception * Make sure mask_password works properly This is not trivial as these fixes relies on many other changes, only the necessary code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sun Sep 14 19:12:16 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 14 Sep 2014 19:12:16 +0000 Subject: [Openstack-security] [openstack/trove] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121416 Log: commit a36c2a7732cc33623b95989d6c27812014a9a727 Author: Tristan Cacqueray Date: Sun Sep 14 18:17:40 2014 +0000 Sync latest process and str utils from oslo This sync required changes to fix these issues: * Make execute method clean password in exception * Make sure mask_password works properly This is not trivial as these fixes relies on many other changes, only the necessary code have been imported/adapted. ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Sun Sep 14 19:22:19 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 14 Sep 2014 19:22:19 +0000 Subject: [Openstack-security] [openstack/trove] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121417 Log: commit e9beec22cc0209512bbe372e6b38ad27f5f0c1ee Author: Tristan Cacqueray Date: Sun Sep 14 19:18:06 2014 +0000 Sync latest process and str utils from oslo This sync required changes to fix these issues: * Make execute method clean password in exception * Make sure mask_password works properly ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 6a60f842 - Mask passwords in exceptions and error messages (SSH) 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From sean at dague.net Sun Sep 14 22:48:36 2014 From: sean at dague.net (Sean Dague) Date: Sun, 14 Sep 2014 22:48:36 -0000 Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts can SSH to compute node References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20140914224838.32318.12924.launchpad@gac.canonical.com> ** Changed in: nova Milestone: None => kilo-1 ** Changed in: nova Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From thierry.carrez+lp at gmail.com Mon Sep 15 14:52:45 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 15 Sep 2014 14:52:45 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140915145245.4904.74249.malone@wampee.canonical.com> The question is... is this a user-controlled string ? If not, we can fix it without issuing a CVE. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Incomplete Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From travis.mcpeak at hp.com Mon Sep 15 15:06:11 2014 From: travis.mcpeak at hp.com (Travis McPeak) Date: Mon, 15 Sep 2014 15:06:11 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140915150611.18348.89991.malone@chaenomeles.canonical.com> This is a utility library, so whether it is user-controlled input or not really depends on how it is being used. I was unable to find any actual usages of this during my review. Maybe somebody more familiar can help shed some light on this. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Incomplete Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From sean at dague.net Mon Sep 15 15:09:35 2014 From: sean at dague.net (Sean Dague) Date: Mon, 15 Sep 2014 15:09:35 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140915150935.18087.52230.malone@chaenomeles.canonical.com> This should be addressed by the oslo.vmware bump in requirements ** Changed in: nova Milestone: None => juno-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): Confirmed Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From sean at dague.net Mon Sep 15 15:06:37 2014 From: sean at dague.net (Sean Dague) Date: Mon, 15 Sep 2014 15:06:37 -0000 Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session token in URL and insecurely sets the session cookie References: <20130703161152.14968.85936.malonedeb@gac.canonical.com> Message-ID: <20140915150637.5461.15834.malone@wampee.canonical.com> Moving to opinion state. From nova IRC: sdague: No i don't think we cut a patch for more recent cloud - since there was general agreeement that this wasn't exploitable ** Changed in: nova Status: Confirmed => Opinion ** Changed in: nova Importance: High => Low -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1197459 Title: noVNC contains the session token in URL and insecurely sets the session cookie Status in OpenStack Compute (Nova): Opinion Status in OpenStack Security Advisories: Won't Fix Bug description: The VNC Console connection in Nova works by having the user connect to the API which returns a URL such as: https://example.com:443/?token=abc Where the token has a TTL which is then used to create a session from a WebSocket. However, URL's should not contain sensitive information such as session tokens with a TTL since URL's can be leaked through proxy logs or other types of attacks such as Cross-Site Scripting. Additionally, due to the session cookie being set with JavaScript it cannot securely be set to HttpOnly nor is it set with the Secure flag making it further susceptible to Cross- Site Scripting attacks or leakage through a non-SSL connection. To limit the exposure of the token being leaked through the URL the returned token from the API should be of a one-time use and only used as an authentication token in order to obtain a session. The session cookie should be set by a Web Service instead of the client in order to securely set the cookie with the HttpOnly flag to be set in addition to setting the Secure flag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions From sean at dague.net Mon Sep 15 15:27:22 2014 From: sean at dague.net (Sean Dague) Date: Mon, 15 Sep 2014 15:27:22 -0000 Subject: [Openstack-security] [Bug 1192971] Re: Command execution cases need to be strengthened References: <20130620133506.19620.30523.malonedeb@gac.canonical.com> Message-ID: <20140915152723.4798.11632.malone@wampee.canonical.com> It looks like all the nova cases are actually handled here ** No longer affects: nova -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1192971 Title: Command execution cases need to be strengthened Status in Cinder: In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Grant Murphy from Red Hat Product Security Team reports the following potential vulnerability: For the most part OpenStack seems to do command execution safely using subprocess.Popen. There are two instances where things become a little dubious. The first is when shell=True is used with subprocess. This doesn't prevent arguments being supplied that allow for multiple commands to be executed. e.g. '; cat /etc/passwd'. The second case is where commands are made to an external ssh host. See attached file for a lit of potential injections: we should double- check them (even if I expect most of them to turn false positive) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1192971/+subscriptions From sean at dague.net Mon Sep 15 15:40:14 2014 From: sean at dague.net (Sean Dague) Date: Mon, 15 Sep 2014 15:40:14 -0000 Subject: [Openstack-security] [Bug 985184] Re: Security groups fail to be set correctly if incorrect case is used for protocol specification References: <20120418200406.7143.26540.malonedeb@chaenomeles.canonical.com> Message-ID: <20140915154014.32220.39816.launchpad@gac.canonical.com> ** No longer affects: nova/diablo -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/985184 Title: Security groups fail to be set correctly if incorrect case is used for protocol specification Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) essex series: Fix Released Status in “nova” package in Ubuntu: Fix Released Status in “nova” source package in Precise: Fix Released Bug description: The high level issue is that if a security group rule is specified with the protocol in uppercase (e.g. TCP instead of tcp) on a system using the IpTablesFirewallDriver then the security group rules may fail to be properly applied, leading to security groups that are more open than specified. The detail of the issue is as follows (Described from the OSAPI perspective, but the problem also exists on EC2) When a security group rule is specified with the protocol in upper case it is validated (contrig/security_groups.py: _rule_args_to_dict() regardless of case but stored in the database in the supplied case: if ip_protocol.upper() not in ['TCP', 'UDP', 'ICMP']: raise exception.InvalidIpProtocol(protocol=ip_protocol) … values['protocol'] = ip_protocol When the security group refresh is triggered (virt/firewall.py – instance_rules() the protocol check is case sensitive: if protocol in ['udp', 'tcp']: args += self._build_tcp_udp_rule(rule, version) elif protocol == 'icmp': args += self._build_icmp_rule(rule, version) if rule.cidr: LOG.info('Using cidr %r', rule.cidr) args += ['-s', rule.cidr] fw_rules += [' '.join(args)] Because the protocol doesn’t match ‘udp’ or ‘tcp’ the protocol part of the rule is skipped, leading to an incomplete and invalid iptables command line. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/985184/+subscriptions From 1341954 at bugs.launchpad.net Mon Sep 15 16:17:27 2014 From: 1341954 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 15 Sep 2014 16:17:27 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140915161727.17807.9189.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/121614 ** Changed in: nova Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From davanum at gmail.com Mon Sep 15 16:49:03 2014 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Mon, 15 Sep 2014 16:49:03 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140915164903.4829.63035.launchpad@wampee.canonical.com> ** Also affects: oslo.vmware Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in Oslo VMware library for OpenStack projects: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1334926 at bugs.launchpad.net Mon Sep 15 22:21:14 2014 From: 1334926 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 15 Sep 2014 22:21:14 -0000 Subject: [Openstack-security] [Bug 1334926] Related fix proposed to neutron (master) References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140915222114.4873.40464.malone@wampee.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/121689 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: In Progress Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From nkinder at redhat.com Mon Sep 15 23:51:51 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 15 Sep 2014 23:51:51 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140915235153.32512.42571.malone@gac.canonical.com> This was published as OSSN-0020: https://wiki.openstack.org/wiki/OSSN/OSSN-0020 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From 1320098 at bugs.launchpad.net Tue Sep 16 02:58:22 2014 From: 1320098 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 16 Sep 2014 02:58:22 -0000 Subject: [Openstack-security] [Bug 1320098] Change abandoned on python-neutronclient (master) References: <20140516064420.2758.66631.malonedeb@wampee.canonical.com> Message-ID: <20140916025822.32745.89033.malone@gac.canonical.com> Change abandoned by Xu Han Peng (xuhanp at linux.vnet.ibm.com) on branch: master Review: https://review.openstack.org/93866 Reason: Abandon this patch because X-Auth-Token has been replaced by "TOKEN_REDACTED" by this keystone client patch: https://github.com/openstack/python-keystoneclient/commit/605577192d7158ecf40bd9a94b7cf3acc2ce1c95 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320098 Title: neutronclient debug logging includes keystone auth token Status in Python client library for Neutron: In Progress Bug description: neutronclient is logging the auth token in the nova logs. Since the logs are world-readable, this means anyone user on this system can see the auth token, which they can then use to get OpenStack administrator access. To manage notifications about this bug go to: https://bugs.launchpad.net/python-neutronclient/+bug/1320098/+subscriptions From 1174499 at bugs.launchpad.net Tue Sep 16 07:52:11 2014 From: 1174499 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 16 Sep 2014 07:52:11 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20140916075211.17873.24393.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/116509 Committed: https://git.openstack.org/cgit/openstack/django_openstack_auth/commit/?id=ed1e31eca6cd34677feb6674973c4f8989b2b4e4 Submitter: Jenkins Branch: master commit ed1e31eca6cd34677feb6674973c4f8989b2b4e4 Author: Brant Knudson Date: Sat Aug 23 11:35:25 2014 -0500 Configurable token hashing algorithm The user's authentication token was hashed using the MD5 algorithm. The MD5 algorithm shouldn't be used because of the potential for hash collisions. Some security standards mandate a SHA2 algorithm or better must be used. With this change the algorithm to use for hashing tokens can be configured by setting the OPENSTACK_TOKEN_HASH_ALGORITHM configuration option to a hash algorithm supported by Python's hashlib library[1]. For example, a deployer could set the option to 'sha256' to meet a SHA2 security standard. The algorithm chosen must match the hash algorithm that the identity server is configured to use (Keystone and the auth_token middleware can be configured to use any hash algorithm supported by hashlib). This is for security hardening. [1] https://docs.python.org/2/library/hashlib.html DocImpact SecurityImpact Change-Id: I9e3eba7e0a12ae40a08d0ed851ea916ec6591bcc Closes-Bug: #1174499 ** Changed in: django-openstack-auth Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in Django OpenStack Auth: Fix Committed Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack API documentation site: Confirmed Status in Python client library for Keystone: Fix Released Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1174499/+subscriptions From 1367000 at bugs.launchpad.net Tue Sep 9 16:55:22 2014 From: 1367000 at bugs.launchpad.net (Eric Harney) Date: Tue, 09 Sep 2014 16:55:22 -0000 Subject: [Openstack-security] [Bug 1367000] Re: Malicious name could lead to local information disclosure vulnerability References: <20140908220415.25176.20373.malonedeb@soybean.canonical.com> Message-ID: <20140909165522.310.67714.malone@gac.canonical.com> I assume the volume/snapshot/backup_name_template options are rarely changed by deployers. For Duncan's suggestion, I'd propose we allow a limited set of characters for those options: alphanumeric, "-", and require the "%s" to be present, which should eliminate the concerns here. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367000 Title: Malicious name could lead to local information disclosure vulnerability Status in Cinder: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: In the cinder scality driver, the following code sets file permissions to 0o666 (read, write for all users): https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L118 This code is called in a couple of locations, one of which is here: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L172 That line of code gets the filename from this function: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L185 Which joins two paths, one of which is this: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L181 Which joins two paths, one of which is volume['name'] which is un- sanitized input. If a malicious user sets a volume name to something like "/etc/passwd", the /etc/passwd permissions will be set to '0o666' with the privileges of the user that is running Cinder. This could be used to expose files and sensitive data on the machine that is running Cinder. If combined with another vulnerability this could lead to some really bad things. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1367000/+subscriptions From 1367000 at bugs.launchpad.net Wed Sep 10 14:14:53 2014 From: 1367000 at bugs.launchpad.net (Eric Harney) Date: Wed, 10 Sep 2014 14:14:53 -0000 Subject: [Openstack-security] [Bug 1367000] Re: Malicious name could lead to local information disclosure vulnerability References: <20140908220415.25176.20373.malonedeb@soybean.canonical.com> Message-ID: <20140910141453.32614.55327.malone@gac.canonical.com> So there is no expectation for changes specific to the Scality driver here, right? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367000 Title: Malicious name could lead to local information disclosure vulnerability Status in Cinder: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: In the cinder scality driver, the following code sets file permissions to 0o666 (read, write for all users): https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L118 This code is called in a couple of locations, one of which is here: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L172 That line of code gets the filename from this function: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L185 Which joins two paths, one of which is this: https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/scality.py#L181 Which joins two paths, one of which is volume['name'] which is un- sanitized input. If a malicious user sets a volume name to something like "/etc/passwd", the /etc/passwd permissions will be set to '0o666' with the privileges of the user that is running Cinder. This could be used to expose files and sensitive data on the machine that is running Cinder. If combined with another vulnerability this could lead to some really bad things. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1367000/+subscriptions From 1348416 at bugs.launchpad.net Thu Sep 11 17:55:50 2014 From: 1348416 at bugs.launchpad.net (Mark Washenberger) Date: Thu, 11 Sep 2014 17:55:50 -0000 Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com> Message-ID: <20140911175550.17842.96824.malone@chaenomeles.canonical.com> There is also a nasty shell=True in glance.tests.utils.execute, which is probably even worse! Our test_migrations code was copied from nova I believe, and a brief glance at nova master indicates a similar use of shell=True in test_migrations.py. So I'm adding Nova as well. ** Changed in: glance Status: New => Confirmed ** Changed in: glance Importance: Undecided => Low ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1348416 Title: Popen with shell=True Status in OpenStack Image Registry and Delivery Service (Glance): Confirmed Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Bug description: Glance uses subprocess.Popen with shell=True in glance/tests/unit/test_migrations.py line 175 in function _reset_datases: def execute_cmd(cmd=None): proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, shell=True) If execute_cmd contains, either accidentally or maliciously, a double quote then arbitrary data will be executed. Popen should be called with an argument list instead of directly through the shell. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently-used- arguments Since these are unit tests and the likelihood of malicious input is low the severity should also be low. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1348416/+subscriptions From 1329301 at bugs.launchpad.net Fri Sep 12 00:32:25 2014 From: 1329301 at bugs.launchpad.net (Travis Tripp) Date: Fri, 12 Sep 2014 00:32:25 -0000 Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are redacted References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com> Message-ID: <20140912003226.5063.38889.malone@wampee.canonical.com> I just went through the thread and as best as I can tell there wasn’t a conclusion in the ML. However, if we are going to do anything, IMO the thread leans toward {SHA1}, with Morgan Fainberg dissenting. However, he references a patch that was ultimately abandoned. Sent new message out to ML. ** Changed in: python-glanceclient Status: New => Incomplete ** Tags added: security ** Tags added: ops -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329301 Title: Update how tokens are redacted Status in Python client library for Glance: Incomplete Bug description: We should move from this approach: https://review.openstack.org/#/c/83350/ to whatever cross-project approach is agreed upon: See this thread: http://lists.openstack.org/pipermail/openstack- dev/2014-June/037345.html To manage notifications about this bug go to: https://bugs.launchpad.net/python-glanceclient/+bug/1329301/+subscriptions From 1329301 at bugs.launchpad.net Fri Sep 12 09:50:51 2014 From: 1329301 at bugs.launchpad.net (Stuart McLaren) Date: Fri, 12 Sep 2014 09:50:51 -0000 Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are redacted References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com> Message-ID: <20140912095051.5494.19540.malone@wampee.canonical.com> Here's what nova went with: https://review.openstack.org/#/c/99511/ swift seem to be following suit: https://review.openstack.org/#/c/99632/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329301 Title: Update how tokens are redacted Status in Python client library for Glance: Incomplete Bug description: We should move from this approach: https://review.openstack.org/#/c/83350/ to whatever cross-project approach is agreed upon: See this thread: http://lists.openstack.org/pipermail/openstack- dev/2014-June/037345.html To manage notifications about this bug go to: https://bugs.launchpad.net/python-glanceclient/+bug/1329301/+subscriptions From Glenn.Ferguson at wellsfargo.com Fri Sep 12 20:21:32 2014 From: Glenn.Ferguson at wellsfargo.com (Glenn Ferguson) Date: Fri, 12 Sep 2014 20:21:32 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> Message-ID: <20140912202132.32318.85059.malone@gac.canonical.com> This issue should not be dismissed as out of scope or declared as Won't fix. If OpenStack wants enterprise adoption, this are the issues that will need to be addressed. As a side note, It doesn't help to have comments such as "acquire the passwords to the database, giving them ALOT of access to that system" in the thread then later dismiss the issue. It is not uncommon for IT auditors to assess risk to a given deployment and to come across this exchange. For someone not familiar with the inner workings of OpenStack - this becomes a major red flag in the audit report. Personally I would like to see this issue addressed in some fashion other than plain text. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in OpenStack Compute (Nova): Won't Fix Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions From 1329301 at bugs.launchpad.net Mon Sep 15 22:23:47 2014 From: 1329301 at bugs.launchpad.net (Travis Tripp) Date: Mon, 15 Sep 2014 22:23:47 -0000 Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are redacted References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com> Message-ID: <20140915222348.376.61091.malone@gac.canonical.com> >From new Mailing list thread: http://lists.openstack.org/pipermail /openstack-dev/2014-September/045802.html So, will propose fix similar to swift which copied from Nova. -----Original Message----- From: Morgan Fainberg [mailto:morgan.fainberg at gmail.com] Sent: Friday, September 12, 2014 3:39 PM To: Brant Knudson; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency -----Original Message----- From: Brant Knudson Reply: OpenStack Development Mailing List (not for usage questions) > Date: September 12, 2014 at 14:32:20 To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency > On Fri, Sep 12, 2014 at 12:02 PM, Tripp, Travis S > wrote: > > > > > From Jamie Lennox: > > >> We handle this in the keystoneclient Session object by just > > >> printing > > REDACTED or something similar. > > >> The problem with using a SHA1 is that for backwards compatability > > >> we > > often use the SHA1 of a PKI token > > >> as if it were a UUID token and so this is still sensitive data. > > >> There > > is working in keystone by morganfainberg > > >> (which i think was merged) to add a new audit_it which will be > > >> able to > > identify a token across calls without > > >> exposing any sensitive information. We will support this in > > >> session > > when available. > > > > From Sean Dague > > > So the problem is that means we are currently leaking secrets and > > > making > > the logs unreadable. > > > > > It seems like we should move forward with the {SHA1} ... and if > > > that is > > still sensitive, address that later. > > > Not addressing it basically keeps the exposure and destroys > > > usability of > > the code because there is so much garbage printed out. > > > > I understand Sean's point about debugging. Right now the > > glanceclient is just printing ***. So it isn't printing a lot of > > excess and isn't leaking anything sensitive. The other usability > > concern with the *** that Sean previously mentioned was having a > > short usable string might be useful for debugging. > > > > Morgan and Jamie, You think switching to SHA1 in actually adds a > > potential security vulnerability to glanceclient that doesn't exist > > now. If that is true, I think it would override the additional > > debugging concern of using > > SHA1 for now. Can you please confirm? > > > > If only for consistency sake, I could switch to "TOKEN_REDACTED" > > like the code sample Morgan sent. [1] > > > > [1] > > https://github.com/openstack/python-keystoneclient/blob/01cabf6bbbee > > 8b5340295f3be5e1fa7111387e7d/keystoneclient/session.py#L126-L131 > > > > As the person who proposed the change to print TOKEN_REDACTED, I'd be > happy to see it printed as {SHA1} instead. I only had it print > TOKEN_REDACTED because I was concerned that we were still logging > tokens and wanted to get something merged that didn't do that rather > than waiting for the perfect solution to come along. > > Since we have configurable token hashing algorithm support in keystone > and auth_token middleware, it's possible that someone could lose their > sanity and decide to use sha1 as the hash algorithm (it defaults to > MD5, which some security standards say is inadequate), and now your > logs have usable token IDs instead of an unusable hash, ***, > TOKEN_REDACTED, or whatever. We could accept this as a risk, and we > could mitigate the risk some by changing keystone to reject sha1 as a hashing algorithm. > > - Brant Ideally, I want to see the use of the audit_ids (in each token as of Juno) as the end goal. If we can get there as fast as changing to the {SHA1}, I’d advocate for that. Brant nicely outlined why we didn’t go with SHA1 earlier on in the cycle. I think we are close to solving this in a better way than using sha1, but if we need a stop-gap we can go towards that for the short term (and disallow sha1 as a hash for Keystone). —Morgan -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329301 Title: Update how tokens are redacted Status in Python client library for Glance: Incomplete Bug description: We should move from this approach: https://review.openstack.org/#/c/83350/ to whatever cross-project approach is agreed upon: See this thread: http://lists.openstack.org/pipermail/openstack- dev/2014-June/037345.html To manage notifications about this bug go to: https://bugs.launchpad.net/python-glanceclient/+bug/1329301/+subscriptions From 1329301 at bugs.launchpad.net Mon Sep 15 23:11:42 2014 From: 1329301 at bugs.launchpad.net (Travis Tripp) Date: Mon, 15 Sep 2014 23:11:42 -0000 Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are redacted References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com> Message-ID: <20140915231143.17616.41854.launchpad@chaenomeles.canonical.com> ** Changed in: python-glanceclient Status: Incomplete => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329301 Title: Update how tokens are redacted Status in Python client library for Glance: In Progress Bug description: We should move from this approach: https://review.openstack.org/#/c/83350/ to whatever cross-project approach is agreed upon: See this thread: http://lists.openstack.org/pipermail/openstack- dev/2014-June/037345.html To manage notifications about this bug go to: https://bugs.launchpad.net/python-glanceclient/+bug/1329301/+subscriptions From 1158328 at bugs.launchpad.net Tue Sep 16 11:28:19 2014 From: 1158328 at bugs.launchpad.net (Daniel Berrange) Date: Tue, 16 Sep 2014 11:28:19 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> Message-ID: <20140916112821.5063.70600.malone@wampee.canonical.com> With postgresql at least you can configure it with authenticate with GSSAPI+Kerberos at which point there is no need to use passwords at all. I'm not sure if MySQL has the same level of GSSAPI integration, but this is the kind of approach we need to take. Use of any kind of password auth is the root cause flaw, regardless of whether Nova has the passwd in a plain text file. So we need to identify recommendations on how to configure Nova + databases, etc with out use of passwords at all. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in OpenStack Compute (Nova): Won't Fix Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions From 1129748 at bugs.launchpad.net Tue Sep 16 12:31:08 2014 From: 1129748 at bugs.launchpad.net (Robert Clark) Date: Tue, 16 Sep 2014 12:31:08 -0000 Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should not be world-readable References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com> Message-ID: <20140916123108.18413.5693.malone@chaenomeles.canonical.com> @sean - yes that's true but there are all sorts of file disclosure vulnerabilities, leaks and remote reads that don't require shell. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (Nova): Opinion Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions From fungi at yuggoth.org Tue Sep 16 13:54:03 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 16 Sep 2014 13:54:03 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> Message-ID: <20140916135403.32578.92139.malone@gac.canonical.com> Agreed. Obfuscation or symmetric encryption of passwords does not actually solve anything either, and is ultimately no better than plain text under most circumstances. The actual solution to the issues raised here is to not use passwords at all. Hopefully "enterprise" auditors will encourage systems which don't use passwords rather than bandages over something we've agreed for decades is bad practice. As for MySQL, 5.5.7 and later support pluggable authentication backends: http://dev.mysql.com/doc/refman/5.5/en/pluggable-authentication.html Perhaps this is something worth documenting in an upcoming revision of the security guide? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in OpenStack Compute (Nova): Won't Fix Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions From 1329301 at bugs.launchpad.net Tue Sep 16 14:33:59 2014 From: 1329301 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 16 Sep 2014 14:33:59 -0000 Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are redacted References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com> Message-ID: <20140916143359.5296.3427.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/121692 Committed: https://git.openstack.org/cgit/openstack/python-glanceclient/commit/?id=f980fc549247fa2deb87dfacebc6d8d13ccd45d1 Submitter: Jenkins Branch: master commit f980fc549247fa2deb87dfacebc6d8d13ccd45d1 Author: Travis Tripp Date: Mon Sep 15 16:17:18 2014 -0600 Update how tokens are redacted Using SHA-1 to match how Nova and Swift redact their tokens. Was discussed in the below thread: http://lists.openstack.org/pipermail/openstack-dev/2014-September/045802.html Here's what nova went with: https://review.openstack.org/#/c/99511/ swift seem to be following suit: https://review.openstack.org/#/c/99632/ Change-Id: I3045d6d9d2a13770f4022dbbd474b34eb1032f6e Closes-bug: 1329301 ** Changed in: python-glanceclient Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329301 Title: Update how tokens are redacted Status in Python client library for Glance: Fix Committed Bug description: We should move from this approach: https://review.openstack.org/#/c/83350/ to whatever cross-project approach is agreed upon: See this thread: http://lists.openstack.org/pipermail/openstack- dev/2014-June/037345.html To manage notifications about this bug go to: https://bugs.launchpad.net/python-glanceclient/+bug/1329301/+subscriptions From 1329301 at bugs.launchpad.net Tue Sep 16 15:16:44 2014 From: 1329301 at bugs.launchpad.net (Travis Tripp) Date: Tue, 16 Sep 2014 15:16:44 -0000 Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are redacted References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com> Message-ID: <20140916151646.5205.18231.launchpad@wampee.canonical.com> ** Changed in: python-glanceclient Assignee: (unassigned) => Travis Tripp (travis-tripp) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329301 Title: Update how tokens are redacted Status in Python client library for Glance: Fix Committed Bug description: We should move from this approach: https://review.openstack.org/#/c/83350/ to whatever cross-project approach is agreed upon: See this thread: http://lists.openstack.org/pipermail/openstack- dev/2014-June/037345.html To manage notifications about this bug go to: https://bugs.launchpad.net/python-glanceclient/+bug/1329301/+subscriptions From pengxuhan at gmail.com Wed Sep 17 05:24:02 2014 From: pengxuhan at gmail.com (Xu Han Peng) Date: Wed, 17 Sep 2014 05:24:02 -0000 Subject: [Openstack-security] [Bug 1320098] Re: neutronclient debug logging includes keystone auth token References: <20140516064420.2758.66631.malonedeb@wampee.canonical.com> Message-ID: <20140917052402.508.79325.malone@gac.canonical.com> Mark as fixed since X-Auth-Token has been replaced by "TOKEN_REDACTED" by this keystone client patch: https://github.com/openstack/python-keystoneclient/commit/605577192d7158ecf40bd9a94b7cf3acc2ce1c95 ** Changed in: python-neutronclient Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320098 Title: neutronclient debug logging includes keystone auth token Status in Python client library for Neutron: Fix Released Bug description: neutronclient is logging the auth token in the nova logs. Since the logs are world-readable, this means anyone user on this system can see the auth token, which they can then use to get OpenStack administrator access. To manage notifications about this bug go to: https://bugs.launchpad.net/python-neutronclient/+bug/1320098/+subscriptions From morgan.fainberg at gmail.com Wed Sep 17 05:34:08 2014 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 17 Sep 2014 05:34:08 -0000 Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting a token revokes all tokens with same expiration References: <20140314003341.30362.66976.malonedeb@gac.canonical.com> Message-ID: <20140917053409.18413.77132.malone@chaenomeles.canonical.com> This is no longer valid for Horizon ** Changed in: horizon Status: Confirmed => Invalid ** Changed in: keystone Milestone: next => None -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1292283 Title: revocation events: deleting a token revokes all tokens with same expiration Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Identity (Keystone): Fix Committed Bug description: As part of the design process for revocation events it was determined that a mechanism to revoke all dependent tokens was needed. This covers the case of revoking a token and ensuring all tokens that were created from that token are also revoked. To accomplish this, the revocation of a specific token is done by expiration_time. The expiration_time attribute is never changed on subsequent tokens. This means it is easy to ensure revocation of an entire chain of tokens. This poses an issue if any specific token (or all tokens that are a child of a specific token) should be revoked, but the parent tokens should not be revoked. Use case: Get Unscoped token Get Scoped Token from Unscoped token Get New Scoped Token Revoke first unscoped token Now all tokens (including the Unscoped token) are revoked because they share an expiration_time. Likely there needs to be a solution that allows for revoking based upon expiration_time and issued_at and one that revokes on expiration_time alone. Revoking by expiration_time alone is API incompatible with previous API mechanisms (both V2 and V3). This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099 was identified. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1292283/+subscriptions From morgan.fainberg at gmail.com Wed Sep 17 05:36:31 2014 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 17 Sep 2014 05:36:31 -0000 Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting a token revokes all tokens with same expiration References: <20140314003341.30362.66976.malonedeb@gac.canonical.com> Message-ID: <20140917053631.32477.23338.malone@gac.canonical.com> This was included in Juno-3, targeting at juno-RC so it can be included in release documents. ** Changed in: keystone Milestone: None => juno-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1292283 Title: revocation events: deleting a token revokes all tokens with same expiration Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Identity (Keystone): Fix Committed Bug description: As part of the design process for revocation events it was determined that a mechanism to revoke all dependent tokens was needed. This covers the case of revoking a token and ensuring all tokens that were created from that token are also revoked. To accomplish this, the revocation of a specific token is done by expiration_time. The expiration_time attribute is never changed on subsequent tokens. This means it is easy to ensure revocation of an entire chain of tokens. This poses an issue if any specific token (or all tokens that are a child of a specific token) should be revoked, but the parent tokens should not be revoked. Use case: Get Unscoped token Get Scoped Token from Unscoped token Get New Scoped Token Revoke first unscoped token Now all tokens (including the Unscoped token) are revoked because they share an expiration_time. Likely there needs to be a solution that allows for revoking based upon expiration_time and issued_at and one that revokes on expiration_time alone. Revoking by expiration_time alone is API incompatible with previous API mechanisms (both V2 and V3). This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099 was identified. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1292283/+subscriptions From duncan.thomas at gmail.com Wed Sep 17 16:27:46 2014 From: duncan.thomas at gmail.com (Duncan Thomas) Date: Wed, 17 Sep 2014 16:27:46 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> Message-ID: <20140917162746.18130.56869.malone@chaenomeles.canonical.com> This affects cinder (and many other projects) - we'd welcome a good solution, though I've no idea what that might be ** Also affects: cinder Importance: Undecided Status: New ** Changed in: cinder Importance: Undecided => Wishlist ** Changed in: cinder Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in Cinder: Confirmed Status in OpenStack Compute (Nova): Won't Fix Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1158328/+subscriptions From 1158328 at bugs.launchpad.net Wed Sep 17 18:43:05 2014 From: 1158328 at bugs.launchpad.net (John Griffith) Date: Wed, 17 Sep 2014 18:43:05 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> Message-ID: <20140917184305.5527.50695.malone@wampee.canonical.com> My two cents: Agree with encrypting the password doesn't solve much.... using pluggable options to db auth is the right answer here IMO. I don't believe this is a bug either, but a feature request. I am certainly not discounting the importance of this feature, I'm receiving this question more and more from customers in the field deploying OpenStack in their internal cloud environments. Maybe we can look at something in Kilo as a feature/enhancement. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in Cinder: Confirmed Status in OpenStack Compute (Nova): Won't Fix Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1158328/+subscriptions From travis.mcpeak at hp.com Wed Sep 17 21:37:31 2014 From: travis.mcpeak at hp.com (Travis McPeak) Date: Wed, 17 Sep 2014 21:37:31 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140917213731.5362.80644.malone@wampee.canonical.com> There are other ways for a string to enter the system, it could be inferred from something that is user controlled, or it could come from config files, for example. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Incomplete Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From dstanek at dstanek.com Thu Sep 18 16:12:21 2014 From: dstanek at dstanek.com (David Stanek) Date: Thu, 18 Sep 2014 16:12:21 -0000 Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears not to hash PKIZ tokens References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com> Message-ID: <20140918161223.32745.91319.launchpad@gac.canonical.com> ** Changed in: python-keystoneclient Milestone: None => 0.11.0 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1355125 Title: keystonemiddleware appears not to hash PKIZ tokens Status in OpenStack Identity (Keystone) Middleware: Fix Released Status in Python client library for Keystone: Fix Committed Bug description: It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself) And that should make token revocation for PKIZ tokens broken. [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399 [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741 To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1355125/+subscriptions From gerrit2 at review.openstack.org Thu Sep 18 22:03:57 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 18 Sep 2014 22:03:57 +0000 Subject: [Openstack-security] [openstack/swift] SecurityImpact review request change If1983b0450a85f79f5bcd5ca6acd859d68de73e4 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/122541 Log: commit fc5cee5f05692f7e6dd5ad5a6d0ae682dd4bf3e0 Author: Christian Schwede Date: Mon Sep 15 17:22:54 2014 +0000 Allow filtering by region in swift-recon The option "-r" is already used, thus only "--region" is used to specify filter by region. Change-Id: If769f2f3191c202933b03b48fe0f22b7c94a4dd6 Closes-Bug: 1369583 commit 423ac74e888dcd693129100e0b37a51428bb62e1 Author: Christian Schwede Date: Sun Sep 14 23:41:19 2014 +0200 Fix internal link to keystoneauth in documentation This patch fixes a broken link at the end of the table in http://docs.openstack.org/developer/swift/logs.html#swift-source Change-Id: I989173ac93e0f840997333be0d5cec07eb77b304 commit 64548420c87f3163ed543c9e9a02a4f1abec69e0 Author: Andreas Jaeger Date: Sat Sep 13 09:48:14 2014 +0200 Stop using intersphinx Remove intersphinx from the docs build as it triggers network calls that occasionally fail, and we don't really use intersphinx (links other sphinx documents out on the internet) This also removes the requirement for internet access during docs build. This can cause docs jobs to fail if the project errors out on warnings. Change-Id: I71e941e2a639641a662a163c682eb86d51de42fb Related-Bug: #1368910 commit 5c9835125802c51e2eb2823f5208d53c358a5e84 Author: Christian Schwede Date: Fri Sep 12 14:37:04 2014 +0000 Fix RingBuilder._build_max_replicas_by_tier docstring The current docstring doesn't include zones, and the order of the entries is not up to date with the current code. Let's fix this. Change-Id: Ibabd79427b83d9e8c86b2caeb93dee219c8274c0 commit a03732e142540e5a7d6cb11de5232f0642beb20d Author: Alistair Coles Date: Fri Sep 12 10:20:19 2014 +0100 Add comments to clarify change to www-authenticate test Trivial patch to tidy-up change to the functional test for www-authenticate header and add a comment to explain that multiple header values might be returned. Change-Id: If62cb3fd9e11450a2be0cec71e80ecb74a959d04 Related-bug: 1368048 commit ab96796dc8d1da9037330da0822c8b8d2264d192 Author: Alistair Coles Date: Thu Sep 11 10:23:32 2014 +0100 Fix broken www-authenticate functional test testQuotedWWWAuthenticateHeader functional test started failing due to a change to keystonemiddleware.auth_token, which now adds its own www-authenticate header in addition to the one that swift keystoneauth adds. This patch changes the functional test to check expected swift generated header value is in the concatenation of www-authenticate values. Verified that functional tests still pass using tempauth. Closes-Bug: 1368048 Change-Id: I913af077df800a559d259c1622f286ad10eae9df commit f4d3facdf4b6ec8ee0dcacc7be8999731c68a8ec Author: Matthew Oliver Date: Thu Aug 14 14:39:18 2014 +1000 Treat 404s as 204 on object delete in proxy This change adds an optional overrides map to _make_request method in the base Controller class. def make_requests(self, req, ring, part, method, path, headers, query_string='', overrides=None) Which will be passed on the the best_response method. If set and no quorum it reached, the override map is used to attempt to find quorum. The overrides map is in the form: { : , .. } The ObjectController, in the DELETE method now passes an override map to make_requests method in the base Controller class in the form of: { 404: 204 } Statuses/responses that have been overridden are used in calculation of the quorum but never returned to the user. They are replaced by: (STATUS, '', '', '') And left out of the search for best response. Change-Id: Ibf969eac3a09d67668d5275e808ed626152dd7eb Closes-Bug: 1318375 commit eff9ab74a4b88102e8938c52cb01b311f932949e Author: David Goetz Date: Fri Aug 15 15:54:05 2014 -0700 Delete expired objects in slightly smarter way. When the expirer tries to delete customer objects, if it just walks through the containers in order the deamon will tend to send DELETEs to the same container highly concurrently. This will in turn create a lot of asyncs because of all the concurrent deletes. If the deletes were spread out to multiple containers it would improve performance and decrease the number of asyncs made. Change-Id: I3d08118c197b7f18dd7e880bd5664508934ffd24 commit efdc27caaca96a42c5466131a2c672f92cfac63a Author: Matt Riedemann Date: Mon Sep 8 21:00:49 2014 -0700 Fix directory value for compile_catalog Commit 7a192987c0a5edb9e239ffb4aba3b1dac083b41e sets up swift for translation but the compile_catalog directory option is pointing at the wrong location to scan for po files. Change-Id: Id4dd24ddfde735ef8ef064882bea045361b5db90 Closes-Bug: #1367086 commit d2a94bd43c383add237966c9f885be6b890a8141 Author: Richard (Rick) Hawkins Date: Mon Sep 8 13:51:07 2014 -0500 Fix FormPOST max_file_size exceeded bug. When using FormPOST, if the size of the file being posted exceeds max_file_size, a HTTP 499 was being returned rather than HTTP 400. Change-Id: I48c781735c66eccde3deb6f9c3c184aee964a4a5 commit fa23202b30c5a1ca89802749ccefd1363fac1d72 Author: Timothy Okwii Date: Mon Sep 8 17:43:19 2014 -0700 Fixed Typo - dictonary to dictionary Change-Id: Ia2a07bf1d1a77f6d6af0c8d9f53c2d47c2ba6d75 commit cb55e89bf1892c62a981df6b205d41ebfdee65ef Author: Clay Gerrard Date: Mon Sep 8 12:25:54 2014 -0700 test tempurl header sanitization priority Change-Id: I0bb3004a717da2f65196bc56b0f7baef49e649e8 commit 88d1d53d98c5e24896710dfeb829de01a85b2d2f Author: YummyBian Date: Mon Sep 8 22:43:53 2014 +0800 Too many if clauses in the _clean_incoming_headers and the _clean_outgoing_headers routines of the tempurl module Too many if clauses make code complicated. For more pythonic, you'd better to use the for ... else clause instead of them. Fix Bug #1363125 Change-Id: I837235ecb08dd912e56cdfb363c4b4a6cc053e7d commit b7281cf2c584cde8f516ba206d90024af03236dd Author: John Dickinson Date: Mon Sep 1 11:22:53 2014 -0700 make the bind_port config setting required In a long-term effort to change the recommended ports for Swift, the first step is to require the bind_port in config files. Later, we can change the recommended setting. Anyone currently explicitly setting the ports will not be affected. Anyone not setting the ports will need to specify them to match their rings. DocImpact Change-Id: Icca83a263acdd0afc9016424a3e9f8c15e944789 commit 4dc718e8c3bd2a8bbe1f2d7a98ad03421a70217f Author: Alistair Coles Date: Mon Sep 8 14:06:00 2014 +0100 Extra unit tests for check_delete_headers A few extra tests to verify check_delete_headers in constraints.py. A little duplication of coverage of existing proxy/controllers/test_obj.py:TestObjController.test_POST_delete_at but these tests call the recently refactored function directly, and also add tests for X-Delete-After taking precedence over X-Delete-At. Change-Id: I129cef15a6feac8a60fd4efbb3535d93f0eaab36 commit 12268677589907e8d10aec6d5aa09c2f72c0ab77 Author: Prashanth Pai Date: Mon Sep 8 15:35:48 2014 +0530 Mention storage backends in Associated Projects Change-Id: I6d88cfe668a557c41e6e6958cd73412ca50c6ba8 Signed-off-by: Prashanth Pai commit 9dcf15f8b50188c592acc4c34e333c738173d516 Author: Thiago da Silva Date: Thu Aug 21 10:33:30 2014 -0400 moving object validation checks to top of PUT method This adds a sanity check on x-delete headers as part of check_object_creation method Change-Id: If5069469e433189235b1178ea203b5c8a926f553 Signed-off-by: Thiago da Silva commit 0221f1f8478fda595e0f1d266f5d04c06cb4e76f Author: Samuel Merritt Date: Fri Sep 5 14:08:03 2014 -0700 Pay attention to all punctual nodes The proxy sends requests to all storage nodes, but it only needs a quorum of them to respond before the proxy can, in turn, respond to the client. Thus, it gets quorum, and then briefly waits to see if the remainder of the storage nodes respond before giving up on them. However, the proxy was not paying any attention to the responses from the non-quorum storage nodes. This would lead to some odd behavior, like a container PUT where the backends returned (201, 201, 202) would become a 201 to the client, but the permutation (201, 202, 201) would become 202. Further, on object PUT, if the last node responded with an error code, that error wouldn't count towards error-limiting. The fix is quite simple: after getting quorum, the make_requests() method was calling a method that returns responses from the remainder of the nodes, but it was ignoring that return value and making up responses with dummy values instead. Now, prior to making up dummy responses, the proxy first uses the responses it already has, and only fills in dummy responses for nodes that really didn't respond in time. Change-Id: I0206b6b2272b0e7dcc80fb6c51840d8dae25cee2 commit 315af1737be9a017a06634ae5f5ab89352e89cb5 Author: Samuel Merritt Date: Fri Sep 5 11:39:36 2014 -0700 Error limit the right node on object PUT If any node had an error on object PUT, the proxy would count the error against the last-connected-to node instead of the one with the error. Now it counts the error against the right node. Change-Id: I884eb73cebe0c723473a6d5e390a148fcad0d3ed commit 72385a6981b38c870dc3c46346fe7eff86f1bba3 Author: Lin Yang Date: Fri Sep 5 15:51:07 2014 +0800 Change method _sort_key_for to static This method does not reference to any attribute of this class, so it's better to change it to classstatic. Change-Id: I3ea0ca83cb29ceae9afb20da0c9817a9b044c084 Signed-off-by: Lin Yang commit 2a8b43e5e73c899cc476428c82c1831fdc546b29 Author: saranjan Date: Wed Sep 3 10:40:30 2014 -0700 Spelling mistakes corrected in comments. Change-Id: Ibbd7511c3a2b08519feb4db18eca6e000603ea32 commit 1a561e67794f6813636377026d8de26f0fb7ad53 Author: Dolph Mathews Date: Wed Sep 3 12:03:40 2014 -0500 warn against sorting requirements Change-Id: I64ae9191863564e278a35d42ec9cd743a233028e Closes-Bug: 1365061 commit 84a1e17f2039e6e5ef732c8931fe47f44f770738 Author: Yuan Zhou Date: Thu Apr 17 15:39:50 2014 +0800 Fix delete versioning objects when previous is expired When deleteing versioned objects proxy will try to restore the previous copy. The COPY request will fail if the previous version is expired but not handled by object-expirer. This patch checks COPY respones on the previous copy, if it's HTTP_NOT_FOUND(mostly because it's expired) proxy will try to restore with the version before previous. Closes-Bug #1308446 Change-Id: I17f049ea3ef62723effae8086ec427f6e151cd9c commit b9ae377eab9c7ceba4f5909cd1f4e804bf3a5b8f Author: Alistair Coles Date: Tue Sep 2 15:46:16 2014 +0100 Check for change before container replicator updates db As described in the related bug report, unnecessary updates to the container db during replication can impact object object GET performance in certain circumstances. This patch changes swift/container/replicator.py so that calls to merge_timestamps and update_reconciler_sync are conditional on values having actually changed. Related-Bug: 1332025 Change-Id: If498251656500ed7a3d7ca4b109ea1079b8513c2 commit 8e9b16a9eaef90add74b71e846371ef61396e19a Author: Andrew Hale Date: Mon Sep 1 18:53:30 2014 +0100 Only bind SAIO daemons to localhost The SAIO configs have no default bind_ip setting configured which causes them to listen on all available IP addresses. This can be dangerous on a test machine with public interfaces, especially with the default passwords set. Its reasonable to choose a more restrictive setup, especially in SAIO which uses 127.0.0.1 throughout ring-builder, example commands and the probe tests. Change-Id: I471c49705ce09e07ec7acc07ee42a1e220529b82 commit 33980c792d40803e8d4c68bd92d9fd869fb861fa Author: Samuel Merritt Date: Fri Aug 29 15:48:38 2014 -0700 Fix last_modified_date_to_timestamp on non-UTC systems Before, we were calling datetime.datetime.strftime('%s.%f') to convert a datetime to epoch seconds + microseconds. However, the '%s' format isn't actually part of Python's library. Rather, Python passes that on to the system C library, which is typically glibc. Now, glibc takes the '%s' format and helpfully* applies the current timezone as an offset. This gives bogus results on machines where UTC is not the system timezone. (Yes, some people really do that.) For example: >>> import os >>> from swift.common import utils >>> os.environ['TZ'] = 'PST8PDT,M3.2.0,M11.1.0' >>> float(utils.last_modified_date_to_timestamp('1970-01-01T00:00:00.000000')) 28800.0 >>> That timestamp should obviously be 0. This patch replaces the strftime() call with datetime arithmetic, which is entirely in Python so the system timezone doesn't mess it up. * unhelpfully Change-Id: I56855acd79a5d8f2c98a771fa9fd2729e4f490b1 commit 849b21a4429e945e5499957b1b884eee9600281f Author: David Goetz Date: Thu Aug 28 14:31:29 2014 -0700 Combine acc/cont put_* methods and fix their lock problem. The container backend is supposed to build a pending file and, when it gets to a certain size, flush it all at once into the sqlite db. Before this fix, many concurrent threads would ask what the pending file size is to see if they should flush instead of just appending to the pending file. The problem is that many would ask, find it's too big, and try to get a lock. The first one wins, flushes, but all the other waiting threads still think they have to flush- which is a much slower opertaion than just the append. This change gets the lock first and makes sure that merge_items is only called when the pending file is full. Change-Id: I29cfa13a48c8f7d16dd414b2288d50461adbafd2 commit 3a7f80aa472794951461cf95fac4ec029167c17d Author: Kota Tsuyuzaki Date: Thu Aug 28 19:20:02 2014 -0700 Small Fix for FakeServerConnection Current FakeServerConnection might cause 499 error in some unit tests because sent (put) data will be overridden by new one every time. e.g. When calling conn.queue.put() twice and more in an object PUT sequence, we can use only a last chunk as the body. This fixes it to merge all chunks as a body. Change-Id: I463e9e2b454e3f3eb26950b3af4c8b8167a9a971 commit 5616d98cc32a5c11014d5e31571fac87d795d113 Author: zhang-hare Date: Wed Aug 27 11:42:06 2014 +0800 fix my name in AUTHORS My author name is my gmail account name, change it to my real name. Change-Id: Iafd94f694f7d007c54de086941309b119683f6cb commit 21adf82cf11fa80479676225a8a61c0029387cb5 Author: Clay Gerrard Date: Fri Aug 8 02:14:27 2014 -0700 code shuffle post expired headers refactor Change-Id: I62248d7d3d7e0a3696a30e3d567ac6c2bea3c8eb commit 43ac76373a353fe74a520108a198b0b563c4f3a2 Author: Constantine Peresypkin Date: Wed Apr 30 15:00:49 2014 +0300 account to account copy implementation Adds ability to copy objects between different accounts (on server side) Adds new header to `PUT` request: `X-Copy-From-Account: ` Account name corresponds to the last part of storage URL. Adds new header to `COPY` request: `Destination-Account: ` Account name corresponds to the last part of storage URL. If your storage URL is: http://server:8080/v1/AUTH_test Then the account name is `AUTH_test` These headers should be used alongside `X-Copy-From` and `Destination` headers The legacy headers should specify `/` path as usual. DocImpact Change-Id: I0285fe6a47df9e699ac20ae4a83b0bf23829e1e6 commit a4f634bd898603225d2218eec220b61a8fd9865c Author: anc Date: Fri Mar 28 02:46:08 2014 +0000 Restrict keystone cross-tenant ACLs to IDs The keystoneauth middleware supports cross-tenant access control using the syntax : in container ACLs, where and may currently be either a unique id or a name. As a result of the keystone v3 API introducing domains, names are no longer globally unique and are only unique within a domain. The use of unqualified tenant and user names in this ACL syntax is therefore not 'safe' in a keystone v3 environment. This patch modifies keystoneauth to restrict cross-tenant ACL matching to use only ids for accounts that are not in the default domain. For backwards compatibility, names will still be matched in ACLs when both the requesting user and tenant are known to be in the default domain AND the account's tenant is also in the default domain (the default domain being the domain to which existing tenants are migrated). Accounts existing prior to this patch are assumed to be for tenants in the default domain. New accounts created using a v2 token scoped on the tenant are also assumed to be in the default domain. New accounts created using a v3 token scoped on the tenant will learn their domain membership from the token info. New accounts created using any unscoped token, (i.e. with a reselleradmin role) will have unknown domain membership and therefore be assumed to NOT be in the default domain. Despite this provision for backwards compatibility, names must no longer be used when setting new ACLs in any account, including new accounts in the default domain. This change obviously impacts users accustomed to specifying cross-tenant ACLs in terms of names, and further work will be necessary to restore those use cases. Some ideas are discussed under the bug report. With that caveat, this patch removes the reported vulnerability when using swift/keystoneauth with a keystone v3 API. Note: to observe the new 'restricted' behaviour you will need to setup keystone user(s) and tenant(s) in a non-default domain and set auth_version = v3.0 in the auth_token middleware config section of proxy-server.conf. You may also benefit from the keystone v3 enabled swiftclient patch under review here: https://review.openstack.org/#/c/91788/ DocImpact blueprint keystone-v3-support Closes-Bug: #1299146 Change-Id: Ib32df093f7450f704127da77ff06b595f57615cb commit 6978275cdb04bb08aaf142d401b52a46527dac4c Author: Nathan Kinder Date: Fri Jul 25 20:47:11 2014 -0700 Avoid usage of insecure mktemp() function This patch eliminates the use of the deprecated and insecure tempfile.mktemp() function. It has been replaced with secure alternatives where temporary files are actually required. Change-Id: I0a13d6d44cd1abc4b66fa33f39eea407617a01d5 SecurityImpact Closes-bug: #1348869 commit 7a192987c0a5edb9e239ffb4aba3b1dac083b41e Author: Andreas Jaeger Date: Sun Jun 1 11:51:29 2014 +0200 Setup localization properly To start translation of swift, we need to initially import the translation file - and place it at the proper place so that the usual CI scripts can handle it. The proper place is for all python projects $PROJECT/locale/$PROJECT.pot, so move locale/$PROJECT.pot to the new location and regenerate the file. Update setup.cfg with the new paths. Further imports will be done by the OpenStack Proposal bot. Change-Id: Ide4da91f2af71db529f4a06d6b1e30ba79883506 Partial-Bug: #608725 Closes-Bug: #1082805 From sean at dague.net Thu Sep 18 23:42:56 2014 From: sean at dague.net (Sean Dague) Date: Thu, 18 Sep 2014 23:42:56 -0000 Subject: [Openstack-security] [Bug 1175193] Re: Instance actions history is unbounded References: <20130501143332.32195.9096.malonedeb@gac.canonical.com> Message-ID: <20140918234256.17589.38852.malone@chaenomeles.canonical.com> It's not really clear that anyone is actually seeing this thing, and there seems to be no interest in fixing it. So it's a pretty theoretical bug right now. ** Changed in: nova Importance: Medium => Wishlist ** Changed in: nova Status: Confirmed => Opinion -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175193 Title: Instance actions history is unbounded Status in OpenStack Compute (Nova): Opinion Bug description: Grizzly included a new feature to keep a history of actions performed on an instance. The history kept in the database is unbounded. As a result, a malicious user could perform actions in a loop and cause the database to grow without bounds. Some of the quicker actions that could be used to exploit this are pause, unpause, or change password. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1175193/+subscriptions From tim.kelsey at hp.com Fri Sep 19 10:29:34 2014 From: tim.kelsey at hp.com (Tim Kelsey) Date: Fri, 19 Sep 2014 10:29:34 -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: <20140919102936.32578.44612.launchpad@gac.canonical.com> ** Changed in: ossn Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: Fix Committed 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 sean at dague.net Fri Sep 19 11:02:23 2014 From: sean at dague.net (Sean Dague) Date: Fri, 19 Sep 2014 11:02:23 -0000 Subject: [Openstack-security] [Bug 1174608] Re: [OSSA 2013-010] Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20140919110223.310.3944.launchpad@gac.canonical.com> ** No longer affects: nova/folsom -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: [OSSA 2013-010] Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Released Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) grizzly series: Fix Released Status in OpenStack Security Advisories: Fix Released Status in Python client library for Keystone: Fix Released Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. 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* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From thierry.carrez+lp at gmail.com Fri Sep 19 13:47:58 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 19 Sep 2014 13:47:58 -0000 Subject: [Openstack-security] =?utf-8?b?W0J1ZyAxMzY4MDczXSBSZTog77u/W1Nl?= =?utf-8?q?curity-NIST=5DSimpleDH_in_=EF=BB=BFnova/virt/xenapi/agent=2Epy_?= =?utf-8?q?does_not_fit_the_NIST?= References: <20140911075020.4966.25460.malonedeb@wampee.canonical.com> Message-ID: <20140919134759.18348.28635.launchpad@chaenomeles.canonical.com> ** Tags added: security ** Information type changed from Public Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1368073 Title: [Security-NIST]SimpleDH in nova/virt/xenapi/agent.py does not fit the NIST Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: class SimpleDH(object): """This class wraps all the functionality needed to implement basic Diffie-Hellman-Merkle key exchange in Python. It features intelligent defaults for the prime and base numbers needed for the calculation, while allowing you to supply your own. It requires that the openssl binary be installed on the system on which this is run, as it uses that to handle the encryption and decryption. If openssl is not available, a RuntimeError will be raised. """ def __init__(self): self._prime = 162259276829213363391578010288127 self._base = 5 self._public = None self._shared = None self.generate_private() def generate_private(self): self._private = int(binascii.hexlify(os.urandom(10)), 16) return self._private def get_public(self): self._public = pow(self._base, self._private, self._prime) return self._public def compute_shared(self, other): self._shared = pow(other, self._private, self._prime) return self._shared def _run_ssl(self, text, decrypt=False): cmd = ['openssl', 'aes-128-cbc', '-A', '-a', '-pass', 'pass:%s' % self._shared, '-nosalt'] if decrypt: cmd.append('-d') out, err = utils.execute(*cmd, process_input=text) if err: raise RuntimeError(_('OpenSSL error: %s') % err) return out def encrypt(self, text): return self._run_ssl(text).strip('\n') def decrypt(self, text): return self._run_ssl(text, decrypt=True)  Nova use the SimpleDH to call the xen agent to set the root password of the instance. In NIST, the DH algorithm need |p| = 2048 bit, and |q| = 224 or 256 bits In the SimpleDH, |q| = int(binascii.hexlify(os.urandom(10)), 16) It was only 24*4 = 96bit p = 162259276829213363391578010288127 is far less than 2048 bit So the SimpleDH is not fit the NIST To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1368073/+subscriptions From thierry.carrez+lp at gmail.com Fri Sep 19 13:48:37 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 19 Sep 2014 13:48:37 -0000 Subject: [Openstack-security] [Bug 1368040] Re: random.choice in /cinder/volume/utils.py may has potential security issue References: <20140911060647.5527.88497.malonedeb@wampee.canonical.com> Message-ID: <20140919134840.25387.66336.launchpad@soybean.canonical.com> ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1368040 Title: random.choice in /cinder/volume/utils.py may has potential security issue Status in Cinder: Invalid Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: The choice is used for security here, could we find out other more security methods to generate randomness? # NOTE(jerdfelt): Some password policies require at least one character # from each group of symbols, so start off with one random character # from each symbol group password = [random.choice(s) for s in symbolgroups] --------------> This line has described issue # If length < len(symbolgroups), the leading characters will only # be from the first length groups. Try our best to not be predictable # by shuffling and then truncating. # then fill with random characters from all symbol groups symbols = ''.join(symbolgroups) password.extend([random.choice(symbols) for _i in xrange(length)]) --------------> This line has described issue # finally shuffle to ensure first x characters aren't from a # predictable group To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1368040/+subscriptions From thierry.carrez+lp at gmail.com Fri Sep 19 13:53:13 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 19 Sep 2014 13:53:13 -0000 Subject: [Openstack-security] [Bug 1369487] Re: NIST: increase RSA key length to 2048 bit References: <20140915100120.18130.90286.malonedeb@chaenomeles.canonical.com> Message-ID: <20140919135314.32318.14195.launchpad@gac.canonical.com> ** Information type changed from Public Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369487 Title: NIST: increase RSA key length to 2048 bit Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: According to NIST 800-131A, RSA key lenght for digital signature must >= 2048 bit. In crypto.py, we use 1024 bit as the default key length to generate cert file, and does not specify any larger number to override the default value when utilizing it. def generate_x509_cert(user_id, project_id, bits=1024): Need to increase the default key length to 2048 bit. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369487/+subscriptions From thierry.carrez+lp at gmail.com Fri Sep 19 13:50:57 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 19 Sep 2014 13:50:57 -0000 Subject: [Openstack-security] [Bug 1367238] Re: IBM NAS cinder driver sets 'rw' permissions to all during volume create operation, which is security issue References: <20140909112305.32185.63569.malonedeb@gac.canonical.com> Message-ID: <20140919135058.32349.24510.launchpad@gac.canonical.com> ** Tags added: security ** Information type changed from Public Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367238 Title: IBM NAS cinder driver sets 'rw' permissions to all during volume create operation, which is security issue Status in Cinder: Fix Committed Status in OpenStack Security Advisories: Won't Fix Bug description: IBM NAS cinder driver sets 'rw' permissions to all during volume create operation from a volume snapshot or from an existing volume (volume clone operation). This is not required as 'rw' permissions to the user only should be sufficient. This also helps resolve the security issue setting 'rw' permissions to all. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1367238/+subscriptions From thierry.carrez+lp at gmail.com Fri Sep 19 13:51:51 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 19 Sep 2014 13:51:51 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140919135152.5296.96495.launchpad@wampee.canonical.com> ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Incomplete Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From fungi at yuggoth.org Fri Sep 19 19:22:12 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 19 Sep 2014 19:22:12 -0000 Subject: [Openstack-security] [Bug 1370295] Re: Possible SQL Injection vulnerability in hyperv volumeutils2 References: <20140917005121.25418.63480.malonedeb@soybean.canonical.com> Message-ID: <20140919192212.32257.3536.malone@gac.canonical.com> Switched the bug to public and marked the security advisory task wontfix based on the above discussion. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1370295 Title: Possible SQL Injection vulnerability in hyperv volumeutils2 Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Won't Fix Bug description: This line: https://github.com/openstack/nova/blob/master/nova/virt/hyperv/volumeutilsv2.py#L54 makes a raw SQL query using input from target_address and target_port. If an attacker is able to manipulate either of these parameters, they can exploit a SQL injection vulnerability. If neither of these parameters can be controlled by an attacker, it's probably OK to fix this in public. These should definitely at least be strengthened by using prepared statements, or even better, a secure SQL library such as sqlalchemy. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1370295/+subscriptions From doug at doughellmann.com Fri Sep 19 20:29:23 2014 From: doug at doughellmann.com (Doug Hellmann) Date: Fri, 19 Sep 2014 20:29:23 -0000 Subject: [Openstack-security] [Bug 1328488] Re: oslo apiclient logs sensitive data References: <20140610105701.26336.80011.malonedeb@wampee.canonical.com> Message-ID: <20140919202925.25348.30863.launchpad@soybean.canonical.com> ** Changed in: oslo-incubator Milestone: None => kilo-1 ** Changed in: oslo-incubator Status: Triaged => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1328488 Title: oslo apiclient logs sensitive data Status in The Oslo library incubator: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: When trying to clean up the tempest logs in the gate, we leak passwords and keystone tokens everywhere. For instance, python- novaclient logs the auth token. What's more problematic though is that apiclient does the following: def _http_log_req(self, method, url, kwargs): if not self.debug: return string_parts = [ "curl -i", "-X '%s'" % method, "'%s'" % url, ] for element in kwargs['headers']: header = "-H '%s: %s'" % (element, kwargs['headers'][element]) string_parts.append(header) _logger.debug("REQ: %s" % " ".join(string_parts)) if 'data' in kwargs: _logger.debug("REQ BODY: %s\n" % (kwargs['data'])) The argument that it's at DEBUG level doesn't hold, because from the Atlanta operators summit it was clear that *all* operators are running their servers at DEBUG, because OpenStack is impossible to actually troubleshoot at any other logging level. And if you run neutron at debug level, then all your nova credentials are in your logs. This is coupled with the fact that a large amount of users are streaming all their logs directly into logstash. Which means they've now got a potentially public endpoint that lets them search for credentials. We need to stop doing that in a blanket way across OpenStack. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo-incubator/+bug/1328488/+subscriptions From 1174499 at bugs.launchpad.net Sat Sep 20 11:44:18 2014 From: 1174499 at bugs.launchpad.net (Akihiro Motoki) Date: Sat, 20 Sep 2014 11:44:18 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20140920114421.24944.85373.launchpad@soybean.canonical.com> ** Changed in: django-openstack-auth Milestone: None => 1.1.7 ** Changed in: django-openstack-auth Status: Fix Committed => Fix Released ** Changed in: django-openstack-auth Importance: Undecided => Wishlist -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in Django OpenStack Auth: Fix Released Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack API documentation site: Confirmed Status in Python client library for Keystone: Fix Released Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1174499/+subscriptions From davanum at gmail.com Sun Sep 21 03:14:10 2014 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Sun, 21 Sep 2014 03:14:10 -0000 Subject: [Openstack-security] [Bug 1328488] Re: oslo apiclient logs sensitive data References: <20140610105701.26336.80011.malonedeb@wampee.canonical.com> Message-ID: <20140921031413.5098.21046.launchpad@wampee.canonical.com> ** Changed in: oslo-incubator Assignee: (unassigned) => Davanum Srinivas (DIMS) (dims-v) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1328488 Title: oslo apiclient logs sensitive data Status in The Oslo library incubator: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: When trying to clean up the tempest logs in the gate, we leak passwords and keystone tokens everywhere. For instance, python- novaclient logs the auth token. What's more problematic though is that apiclient does the following: def _http_log_req(self, method, url, kwargs): if not self.debug: return string_parts = [ "curl -i", "-X '%s'" % method, "'%s'" % url, ] for element in kwargs['headers']: header = "-H '%s: %s'" % (element, kwargs['headers'][element]) string_parts.append(header) _logger.debug("REQ: %s" % " ".join(string_parts)) if 'data' in kwargs: _logger.debug("REQ BODY: %s\n" % (kwargs['data'])) The argument that it's at DEBUG level doesn't hold, because from the Atlanta operators summit it was clear that *all* operators are running their servers at DEBUG, because OpenStack is impossible to actually troubleshoot at any other logging level. And if you run neutron at debug level, then all your nova credentials are in your logs. This is coupled with the fact that a large amount of users are streaming all their logs directly into logstash. Which means they've now got a potentially public endpoint that lets them search for credentials. We need to stop doing that in a blanket way across OpenStack. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo-incubator/+bug/1328488/+subscriptions From 1355125 at bugs.launchpad.net Sun Sep 21 18:53:57 2014 From: 1355125 at bugs.launchpad.net (Dolph Mathews) Date: Sun, 21 Sep 2014 18:53:57 -0000 Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears not to hash PKIZ tokens References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com> Message-ID: <20140921185359.341.21992.launchpad@gac.canonical.com> ** Changed in: python-keystoneclient Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1355125 Title: keystonemiddleware appears not to hash PKIZ tokens Status in OpenStack Identity (Keystone) Middleware: Fix Released Status in Python client library for Keystone: Fix Released Bug description: It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself) And that should make token revocation for PKIZ tokens broken. [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399 [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741 To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1355125/+subscriptions From 1004114 at bugs.launchpad.net Sun Sep 21 18:54:20 2014 From: 1004114 at bugs.launchpad.net (Dolph Mathews) Date: Sun, 21 Sep 2014 18:54:20 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140921185424.18382.15023.launchpad@chaenomeles.canonical.com> ** Changed in: python-keystoneclient Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: In Progress Status in Python client library for Keystone: Fix Released Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From gerrit2 at review.openstack.org Mon Sep 22 00:55:34 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 22 Sep 2014 00:55:34 +0000 Subject: [Openstack-security] [openstack/horizon] SecurityImpact review request change I6774b9b7215d191259586e4721e357487bb777cd Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/116510 Log: commit 372d033d89c0f5d305959a6ad5fd3e1159cc91ed Author: Brant Knudson Date: Sun Aug 24 10:04:10 2014 -0500 Document token hash algorithm option With https://review.openstack.org/#/c/116509/ , django-openstack-auth will support a new option for the token hash algorithm. This adds the documentation to Horizon's local settings example file. This is for security hardening. The token hash algorithm defaults to MD5, which is considered too weak due to the potential for hash collisions. Some security standards require a SHA2 hash algorithm to be used. DocImpact SecurityImpact Change-Id: I6774b9b7215d191259586e4721e357487bb777cd Closes-Bug: #1174499 From svnsatya at gmail.com Tue Sep 16 12:36:08 2014 From: svnsatya at gmail.com (satyadev svn) Date: Tue, 16 Sep 2014 12:36:08 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140916123610.32185.72174.launchpad@gac.canonical.com> ** Tags added: vmware -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From 1367022 at bugs.launchpad.net Tue Sep 16 14:45:17 2014 From: 1367022 at bugs.launchpad.net (Eoghan Glynn) Date: Tue, 16 Sep 2014 14:45:17 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140916144517.442.56964.malone@gac.canonical.com> The string concerned is read from a ceilometer config file /etc/ceilometer/pipeline.yaml, that should be protected from an attacker by host-level file permissions. For example, here it's used to provide the logic to scale the delta in cumulative CPU time in nanos for multiple vcpus to a single utilization percentage: https://github.com/openstack/ceilometer/blob/master/etc/ceilometer/pipeline.yaml#L46 The string to be eval'd is not submitted via the ceilometer API, so is not part of the "attack surface" as I would understand it. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Incomplete Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From sross at redhat.com Thu Sep 18 15:37:40 2014 From: sross at redhat.com (Solly Ross) Date: Thu, 18 Sep 2014 15:37:40 -0000 Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will have issues when booting two with different config drive values References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com> Message-ID: <20140918153742.376.74475.launchpad@gac.canonical.com> ** Changed in: nova Importance: Undecided => Critical ** Tags added: security ** Changed in: nova Milestone: None => juno-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369627 Title: libvirt disk.config will have issues when booting two with different config drive values Status in OpenStack Compute (Nova): In Progress Bug description: Currently, in the image creating code for Juno we have if configdrive.required_by(instance): LOG.info(_LI('Using config drive'), instance=instance) image_type = self._get_configdrive_image_type() backend = image('disk.config', image_type) backend.cache(fetch_func=self._create_configdrive, filename='disk.config' + suffix, instance=instance, admin_pass=admin_pass, files=files, network_info=network_info) The important thing to notice here is that we have "filename='disk.confg' + suffix". This means that the filename for the config drive in the cache directory will be simply 'disk.config' followed by any potential suffix (e.g. '.rescue'). This name is not unique to the instance whose config drive we are creating. Therefore, when we go to boot another instance with a different config drive, the cache function will detect the old config drive, and decide it doesn't need to create the new config drive with the appropriate config for the new instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369627/+subscriptions From kragniz at gmail.com Sun Sep 21 18:12:20 2014 From: kragniz at gmail.com (Louis Taylor) Date: Sun, 21 Sep 2014 18:12:20 -0000 Subject: [Openstack-security] [Bug 1329301] Re: Update how tokens are redacted References: <20140612121824.4650.65306.malonedeb@wampee.canonical.com> Message-ID: <20140921181222.24944.52503.launchpad@soybean.canonical.com> ** Changed in: python-glanceclient Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329301 Title: Update how tokens are redacted Status in Python client library for Glance: Fix Released Bug description: We should move from this approach: https://review.openstack.org/#/c/83350/ to whatever cross-project approach is agreed upon: See this thread: http://lists.openstack.org/pipermail/openstack- dev/2014-June/037345.html To manage notifications about this bug go to: https://bugs.launchpad.net/python-glanceclient/+bug/1329301/+subscriptions From 1369627 at bugs.launchpad.net Mon Sep 22 08:16:00 2014 From: 1369627 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 22 Sep 2014 08:16:00 -0000 Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will have issues when booting two with different config drive values References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922081600.5331.1375.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/123073 ** Changed in: nova Assignee: Solly Ross (sross-7) => Michael Still (mikalstill) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369627 Title: libvirt disk.config will have issues when booting two with different config drive values Status in OpenStack Compute (Nova): In Progress Bug description: Currently, in the image creating code for Juno we have if configdrive.required_by(instance): LOG.info(_LI('Using config drive'), instance=instance) image_type = self._get_configdrive_image_type() backend = image('disk.config', image_type) backend.cache(fetch_func=self._create_configdrive, filename='disk.config' + suffix, instance=instance, admin_pass=admin_pass, files=files, network_info=network_info) The important thing to notice here is that we have "filename='disk.confg' + suffix". This means that the filename for the config drive in the cache directory will be simply 'disk.config' followed by any potential suffix (e.g. '.rescue'). This name is not unique to the instance whose config drive we are creating. Therefore, when we go to boot another instance with a different config drive, the cache function will detect the old config drive, and decide it doesn't need to create the new config drive with the appropriate config for the new instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369627/+subscriptions From fungi at yuggoth.org Mon Sep 22 14:53:08 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 22 Sep 2014 14:53:08 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922145308.32545.11892.malone@gac.canonical.com> Sounds like this is not a security vulnerability if the value is only taken from configuration files. As such the VMT would not issue an advisory for it. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Won't Fix Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From fungi at yuggoth.org Mon Sep 22 14:58:37 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 22 Sep 2014 14:58:37 -0000 Subject: [Openstack-security] [Bug 1372375] Re: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922145838.32411.61079.launchpad@gac.canonical.com> ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372375 Title: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: I have doubts about the flow of the volume attaching operation, as defined in /usr/lib/python2.6/site- packages/nova/volume/encryptors/luks.py. If the device is not recognized to be a valid luks device, the script is luks formatting it! So if for some reason the luks header get corrupted, it erases the whole data. To manage corrupted headers there are the cryptsetup luksHeaderBackup and cryptsetup luksHeaderRestore commands that respectively do the backup and the restore of the headers. I think that the process has to be reviewed, and the luksFormat operation has to be performed during the volume creation. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1372375/+subscriptions From travis.mcpeak at hp.com Mon Sep 22 14:56:20 2014 From: travis.mcpeak at hp.com (Travis McPeak) Date: Mon, 22 Sep 2014 14:56:20 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922145620.17647.73705.malone@chaenomeles.canonical.com> An example of an inferred value would be the case where we have something like the following: value_from_api = "40MB" trans_val = value_from_api[-2:] In this case, the trans_val is being inferred or calculated from the last two characters of user controlled input. I'm not saying this is the case, it's just an example. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Won't Fix Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From fungi at yuggoth.org Mon Sep 22 15:06:00 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 22 Sep 2014 15:06:00 -0000 Subject: [Openstack-security] [Bug 1370283] Re: python-glanceclient uses extremely insecure configurations of OpenSSL References: <20140916232429.32614.13519.malonedeb@gac.canonical.com> Message-ID: <20140922150601.25240.94393.launchpad@soybean.canonical.com> ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1370283 Title: python-glanceclient uses extremely insecure configurations of OpenSSL Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Glance: New Bug description: glanceclient does not properly configure OpenSSL, which results in making TLS connections which allow extremely bad security settings. Specifically it allows SSLv2, and many insecure ciphersuites. From Ubuntu 14.04: >>> import pprint; import glanceclient.common.http; pprint.pprint(glanceclient.common.http.HTTPClient('https://', ssl_compression=False).session.get("https://www.howsmyssl.com/a/check").json()) {u'able_to_detect_n_minus_one_splitting': False, u'beast_vuln': False, u'ephemeral_keys_supported': True, u'given_cipher_suites': [u'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_AES_256_GCM_SHA384', u'TLS_RSA_WITH_AES_256_CBC_SHA256', u'TLS_RSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA', u'TLS_DHE_RSA_WITH_SEED_CBC_SHA', u'TLS_DHE_DSS_WITH_SEED_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_AES_128_GCM_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_SEED_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDHE_RSA_WITH_RC4_128_SHA', u'TLS_ECDHE_ECDSA_WITH_RC4_128_SHA', u'TLS_ECDH_RSA_WITH_RC4_128_SHA', u'TLS_ECDH_ECDSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_MD5', u'TLS_DHE_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_DSS_WITH_DES_CBC_SHA', u'TLS_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5', u'TLS_RSA_EXPORT_WITH_RC4_40_MD5', u'TLS_EMPTY_RENEGOTIATION_INFO_SCSV'], u'insecure_cipher_suites': {u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_DSS_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC4_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption']}, u'rating': u'Bad', u'session_ticket_supported': True, u'tls_compression_supported': False, u'tls_version': u'TLS 1.2', u'unknown_cipher_suite_supported': False} I *strongly* recommend just deleting all this code and using requests. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1370283/+subscriptions From thierry.carrez+lp at gmail.com Mon Sep 22 15:10:26 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 22 Sep 2014 15:10:26 -0000 Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs x-subject-token at the debug log level References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922151028.25143.356.launchpad@soybean.canonical.com> ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Private Security to Public Security ** Information type changed from Public Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1371355 Title: Keystone client logs x-subject-token at the debug log level Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Keystone: New Bug description: When you invoke any OpenStack API of any of the OpenStack services listed below, then it logs readable x-subject-token as a debug log message in the respective log file. x-subject-token is introduced in v3, so only setups using v3 keystone apis are affected. All OpenStack services using keystone client for authentication and debug log level are affected Service affected are: glance neutron cinder heat ceilometer nova keystone neutron Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log nova-api.log {{{ 2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153 2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’}) }}} I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information. {{{ openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5" HTTP/1.1 200 OK Content-Type: application/json Content-Length: 15 X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d Date: Thu, 18 Sep 2014 22:58:56 GMT {"servers": []} }}} To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1371355/+subscriptions From gerrit2 at review.openstack.org Mon Sep 22 16:59:27 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 22 Sep 2014 16:59:27 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121382 Log: commit d3f97a1c78caf2ef4620f29b9de9af3270fd8b71 Author: Tristan Cacqueray Date: Sat Sep 13 18:12:05 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport in oslo-incubator: https://review.openstack.org/121365 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Mon Sep 22 16:59:48 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 22 Sep 2014 16:59:48 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121383 Log: commit cdd95d60eab262cc6ff1a3f95d79e5fabb2137e0 Author: Tristan Cacqueray Date: Sat Sep 13 18:54:33 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport in oslo-incubator: https://review.openstack.org/121365 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Mon Sep 22 17:00:16 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 22 Sep 2014 17:00:16 +0000 Subject: [Openstack-security] [openstack/trove] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121417 Log: commit 9672744f090d462cac5eb757ceaacd7122362708 Author: Tristan Cacqueray Date: Sun Sep 14 19:18:06 2014 +0000 Sync latest process and str utils from oslo This sync required changes to fix these issues: * Make execute method clean password in exception * Make sure mask_password works properly ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 6a60f842 - Mask passwords in exceptions and error messages (SSH) 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure ----------------------------------------------- Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From 1341954 at bugs.launchpad.net Mon Sep 22 17:08:10 2014 From: 1341954 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 22 Sep 2014 17:08:10 -0000 Subject: [Openstack-security] [Bug 1341954] Change abandoned on nova (master) References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140922170810.32380.34187.malone@gac.canonical.com> Change abandoned by Davanum Srinivas (dims) (davanum at gmail.com) on branch: master Review: https://review.openstack.org/121614 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From 1290537 at bugs.launchpad.net Mon Sep 22 17:40:07 2014 From: 1290537 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 17:40:07 -0000 Subject: [Openstack-security] [Bug 1290537] Re: [0SSA 2014-011] RBAC policy not enforced when adding a security group rule using EC2 API (CVE-2014-0167) References: <20140310202059.13934.40594.malonedeb@gac.canonical.com> Message-ID: <20140922174009.17908.52433.launchpad@chaenomeles.canonical.com> ** Changed in: nova/havana Milestone: None => 2013.2.4 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290537 Title: [0SSA 2014-011] RBAC policy not enforced when adding a security group rule using EC2 API (CVE-2014-0167) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) havana series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons. The Nova API security group implementation does enforce RBAC on these functions. In addition, the add_to_instance and remove_from _instance functions which are wrapped in RBAC verification use the "compute:security_groups" action which is not even listed in the default /etc/nova/policy.json. The latter is confusing to users. This is the case on Grizlly and at first glance, it doesn't look like this has changed in Havana. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1290537/+subscriptions From bknudson at us.ibm.com Mon Sep 22 19:03:48 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Mon, 22 Sep 2014 19:03:48 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922190348.24753.96960.malone@soybean.canonical.com> The eval() call could be made safer by setting globals and locals to only those symbols that are useful in the context it's used. https://docs.python.org/2/library/functions.html#eval and http://lybniz2.sourceforge.net/safeeval.html -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Won't Fix Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From bknudson at us.ibm.com Mon Sep 22 19:08:41 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Mon, 22 Sep 2014 19:08:41 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922190841.24944.6425.malone@soybean.canonical.com> >>> eval('abc + ghi * 100.0', {'__builtins__': None}, {'abc': 10, 'ghi': 20}) 2010.0 >>> eval('__import__("os")', {'__builtins__': None}, {'abc': 10, 'ghi': 20}) NameError: name '__import__' is not defined -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Won't Fix Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From bknudson at us.ibm.com Mon Sep 22 19:12:59 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Mon, 22 Sep 2014 19:12:59 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922191259.25043.45411.malone@soybean.canonical.com> The place that's mentioned here is return ((eval(scale, {}, ns) if isinstance(scale, six.string_types) ... but since the globals doesn't mask __builtins__ you can do something like '__import__("os")' and then do whatever. I'll propose a change to mask __builtins__ as a security hardening. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Won't Fix Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From gerrit2 at review.openstack.org Mon Sep 22 19:47:32 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 22 Sep 2014 19:47:32 +0000 Subject: [Openstack-security] [openstack/ceilometer] SecurityImpact review request change I91a32a62204dd44fa850f9ec0efd4f45cd3d72c2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/123237 Log: commit 0cd8389616df13f7927d35747ff5d285ae447cde Author: Brant Knudson Date: Mon Sep 22 14:34:50 2014 -0500 Safer use of eval eval() was used with an empty globals parameter. This meant that the expression could call __import__ and then do whatever (remove all your files, for examples). By setting globals to {'__builtins__': None} the expression can't use __import__. This is for security hardening. SecurityImpact Change-Id: I91a32a62204dd44fa850f9ec0efd4f45cd3d72c2 Partial-Bug: #1367022 From 1367022 at bugs.launchpad.net Mon Sep 22 19:47:30 2014 From: 1367022 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 22 Sep 2014 19:47:30 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922194730.310.24782.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/123237 ** Changed in: ceilometer Status: New => In Progress ** Changed in: ceilometer Assignee: (unassigned) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From 1300274 at bugs.launchpad.net Mon Sep 22 21:07:22 2014 From: 1300274 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 21:07:22 -0000 Subject: [Openstack-security] [Bug 1300274] Re: [0SSA 2014-013] V3 Authentication Chaining - uniqueness of auth method names (CVE-2014-2828) References: <20140331151221.30715.87577.malonedeb@gac.canonical.com> Message-ID: <20140922210724.17973.51681.launchpad@chaenomeles.canonical.com> ** Changed in: keystone/havana Milestone: None => 2013.2.4 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1300274 Title: [0SSA 2014-013] V3 Authentication Chaining - uniqueness of auth method names (CVE-2014-2828) Status in OpenStack Identity (Keystone): Fix Released Status in Keystone havana series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: In V3.0 API, we can chain authentication methods. An attacker can place the same authentication method multiple times in the methods filed. This will result in the same authentication method checking over and over (for loop in code). Using this, an attacker can achieve some sorts of Denial of Service. The methods field is not properly sanitized. { "auth":{ "identity":{ "methods":[ "password", "password", "password", "password", "password" ], "password":{ "user":{ "domain":{ "id":"default" }, "name":"demo", "password":"stack" } } } } } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1300274/+subscriptions From 1334926 at bugs.launchpad.net Mon Sep 22 21:12:45 2014 From: 1334926 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 22 Sep 2014 21:12:45 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140922211248.508.75106.launchpad@gac.canonical.com> ** Changed in: neutron Assignee: yong sheng gong (gongysh) => Carl Baldwin (carl-baldwin) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From 1341954 at bugs.launchpad.net Mon Sep 22 21:35:43 2014 From: 1341954 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 21:35:43 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140922213544.18167.27062.launchpad@chaenomeles.canonical.com> ** Also affects: cinder/havana Importance: Undecided Status: New ** Changed in: cinder/havana Status: New => Fix Committed ** Changed in: cinder/havana Milestone: None => 2013.2.4 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Cinder havana series: Fix Committed Status in Gantt: New Status in OpenStack Compute (Nova): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From 1321080 at bugs.launchpad.net Mon Sep 22 21:47:11 2014 From: 1321080 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 21:47:11 -0000 Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token is exposed in meter http.request (CVE-2014-4615) References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140922214715.17647.9547.launchpad@chaenomeles.canonical.com> ** Changed in: ceilometer/havana Milestone: None => 2013.2.4 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: [OSSA 2014-021] auth token is exposed in meter http.request (CVE-2014-4615) Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Committed Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in The Oslo library incubator: Fix Released Status in oslo-incubator havana series: Fix Committed Status in oslo-incubator icehouse series: Fix Committed Status in OpenStack Security Advisories: Fix Released Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1308727 at bugs.launchpad.net Mon Sep 22 21:49:08 2014 From: 1308727 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 21:49:08 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140922214910.18382.4614.launchpad@chaenomeles.canonical.com> ** Changed in: horizon/havana Milestone: None => 2013.2.4 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) havana series: Fix Committed Status in OpenStack Dashboard (Horizon) icehouse series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From 1289033 at bugs.launchpad.net Mon Sep 22 21:49:32 2014 From: 1289033 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 21:49:32 -0000 Subject: [Openstack-security] [Bug 1289033] Re: [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157) References: <20140306223232.13317.99583.malonedeb@gac.canonical.com> Message-ID: <20140922214935.4873.66840.launchpad@wampee.canonical.com> ** Changed in: horizon/havana Milestone: None => 2013.2.4 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1289033 Title: [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157) Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) havana series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: *Description* XSS vulnerability identified in Horizon-Orchestration while uploading a stack template. Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon. *Threat Description* -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs. -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc. -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. *Environment* One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration: shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw *Steps to reproduce* 1- Sign-in to Horizon and click on Orchestration/Stack section. 2- Click on "Launch Stack" 3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template) 4- Update the contents of the DBUsername "Description" field with the following: "DBUsername": { ... "Description" : "", ... }, 5- Click on Next 6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value. 7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability. *How to fix* - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input). - Perform output sanitization when displaying template's "Description" messages. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1289033/+subscriptions From 1290537 at bugs.launchpad.net Mon Sep 22 22:20:17 2014 From: 1290537 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 22:20:17 -0000 Subject: [Openstack-security] [Bug 1290537] Re: [0SSA 2014-011] RBAC policy not enforced when adding a security group rule using EC2 API (CVE-2014-0167) References: <20140310202059.13934.40594.malonedeb@gac.canonical.com> Message-ID: <20140922222021.5331.71882.launchpad@wampee.canonical.com> ** Changed in: nova/havana Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290537 Title: [0SSA 2014-011] RBAC policy not enforced when adding a security group rule using EC2 API (CVE-2014-0167) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) havana series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons. The Nova API security group implementation does enforce RBAC on these functions. In addition, the add_to_instance and remove_from _instance functions which are wrapped in RBAC verification use the "compute:security_groups" action which is not even listed in the default /etc/nova/policy.json. The latter is confusing to users. This is the case on Grizlly and at first glance, it doesn't look like this has changed in Havana. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1290537/+subscriptions From 1300274 at bugs.launchpad.net Mon Sep 22 22:24:24 2014 From: 1300274 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 22:24:24 -0000 Subject: [Openstack-security] [Bug 1300274] Re: [0SSA 2014-013] V3 Authentication Chaining - uniqueness of auth method names (CVE-2014-2828) References: <20140331151221.30715.87577.malonedeb@gac.canonical.com> Message-ID: <20140922222426.32185.33735.launchpad@gac.canonical.com> ** Changed in: keystone/havana Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1300274 Title: [0SSA 2014-013] V3 Authentication Chaining - uniqueness of auth method names (CVE-2014-2828) Status in OpenStack Identity (Keystone): Fix Released Status in Keystone havana series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: In V3.0 API, we can chain authentication methods. An attacker can place the same authentication method multiple times in the methods filed. This will result in the same authentication method checking over and over (for loop in code). Using this, an attacker can achieve some sorts of Denial of Service. The methods field is not properly sanitized. { "auth":{ "identity":{ "methods":[ "password", "password", "password", "password", "password" ], "password":{ "user":{ "domain":{ "id":"default" }, "name":"demo", "password":"stack" } } } } } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1300274/+subscriptions From SlickNik at gmail.com Mon Sep 22 22:47:28 2014 From: SlickNik at gmail.com (Nikhil Manchanda) Date: Mon, 22 Sep 2014 22:47:28 -0000 Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup strategies References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com> Message-ID: <20140922224728.24784.12838.malone@soybean.canonical.com> So the reason this runs with shell = true is because it uses POSIX pipes to do redirection as part of the backup / restore command. Is there a viable alternative which we can use that allows us to work with pipes doing the backup, and still harden the code wrt the security concern identified here? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1343657 Title: Shell Injection in backup strategies Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Openstack Database (Trove): New Bug description: Trove uses subprocess.Popen with shell=True in trove/trove/guestagent/strategies/backup/base.py line 61: def run(self): self.process = subprocess.Popen(self.command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) self.pid = self.process.pid This could be used, maliciously or not, to inject arbitrary commands into a command line string. An example of this could be triggered is in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It is creating a MySQL string with single quote. If the password, either maliciously or just happens to contain another single quote, it will escape from the command and arbitrary data will be executed instead. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently- used-arguments To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1343657/+subscriptions From 1341954 at bugs.launchpad.net Mon Sep 22 22:49:36 2014 From: 1341954 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 22:49:36 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140922224940.17807.33373.launchpad@chaenomeles.canonical.com> ** Changed in: cinder/havana Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Cinder havana series: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): In Progress Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From 1321080 at bugs.launchpad.net Mon Sep 22 22:39:21 2014 From: 1321080 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 22:39:21 -0000 Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token is exposed in meter http.request (CVE-2014-4615) References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140922223925.32185.57332.launchpad@gac.canonical.com> ** Changed in: ceilometer/havana Status: Fix Committed => Fix Released ** Changed in: ceilometer/havana Importance: Undecided => Critical -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: [OSSA 2014-021] auth token is exposed in meter http.request (CVE-2014-4615) Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Released Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in The Oslo library incubator: Fix Released Status in oslo-incubator havana series: Fix Committed Status in oslo-incubator icehouse series: Fix Committed Status in OpenStack Security Advisories: Fix Released Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1308727 at bugs.launchpad.net Mon Sep 22 22:36:01 2014 From: 1308727 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 22:36:01 -0000 Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) References: <20140416193338.27100.82700.malonedeb@gac.canonical.com> Message-ID: <20140922223604.32477.21220.launchpad@gac.canonical.com> ** Changed in: horizon/havana Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1308727 Title: [OSSA 2014-023] XSS in Horizon Heat template - resource name (CVE-2014-3473) Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) havana series: Fix Released Status in OpenStack Dashboard (Horizon) icehouse series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: The attached yaml will result in a Cross Site Script when viewing the resources or events of an Orchestration stack in the following paths: /project/stacks/stack/{stack_id}/?tab=stack_details__resources /project/stacks/stack/{stack_id}/?tab=stack_details__events The A tag's href attribute does not properly URL encode the name of the resource string resulting in escaping out of the attribute and arbitrary HTML written to the page. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1308727/+subscriptions From 1289033 at bugs.launchpad.net Mon Sep 22 22:35:58 2014 From: 1289033 at bugs.launchpad.net (Alan Pevec) Date: Mon, 22 Sep 2014 22:35:58 -0000 Subject: [Openstack-security] [Bug 1289033] Re: [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157) References: <20140306223232.13317.99583.malonedeb@gac.canonical.com> Message-ID: <20140922223600.32578.28945.launchpad@gac.canonical.com> ** Changed in: horizon/havana Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1289033 Title: [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157) Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Dashboard (Horizon) havana series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: *Description* XSS vulnerability identified in Horizon-Orchestration while uploading a stack template. Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon. *Threat Description* -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs. -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc. -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. *Environment* One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration: shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw *Steps to reproduce* 1- Sign-in to Horizon and click on Orchestration/Stack section. 2- Click on "Launch Stack" 3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template) 4- Update the contents of the DBUsername "Description" field with the following: "DBUsername": { ... "Description" : "", ... }, 5- Click on Next 6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value. 7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability. *How to fix* - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input). - Perform output sanitization when displaying template's "Description" messages. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1289033/+subscriptions From travis.mcpeak at hp.com Tue Sep 23 00:53:18 2014 From: travis.mcpeak at hp.com (Travis McPeak) Date: Tue, 23 Sep 2014 00:53:18 -0000 Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup strategies References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com> Message-ID: <20140923005318.25076.95064.malone@soybean.canonical.com> Anything that you are using piped shell commands for can be written as separate statements. It might not read as smoothly, but it will be safer. Another approach is to move a lot of the operating system calls to their Python equivalents. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1343657 Title: Shell Injection in backup strategies Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Openstack Database (Trove): New Bug description: Trove uses subprocess.Popen with shell=True in trove/trove/guestagent/strategies/backup/base.py line 61: def run(self): self.process = subprocess.Popen(self.command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) self.pid = self.process.pid This could be used, maliciously or not, to inject arbitrary commands into a command line string. An example of this could be triggered is in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It is creating a MySQL string with single quote. If the password, either maliciously or just happens to contain another single quote, it will escape from the command and arbitrary data will be executed instead. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently- used-arguments To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1343657/+subscriptions From 1343657 at bugs.launchpad.net Tue Sep 23 01:39:51 2014 From: 1343657 at bugs.launchpad.net (Amrith) Date: Tue, 23 Sep 2014 01:39:51 -0000 Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup strategies References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com> Message-ID: <20140923013951.25076.96772.malone@soybean.canonical.com> For Trove, this is related to 1349939, 1360954, and 1361622 ** Changed in: trove Assignee: (unassigned) => Amrith (amrith) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1343657 Title: Shell Injection in backup strategies Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Openstack Database (Trove): New Bug description: Trove uses subprocess.Popen with shell=True in trove/trove/guestagent/strategies/backup/base.py line 61: def run(self): self.process = subprocess.Popen(self.command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) self.pid = self.process.pid This could be used, maliciously or not, to inject arbitrary commands into a command line string. An example of this could be triggered is in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It is creating a MySQL string with single quote. If the password, either maliciously or just happens to contain another single quote, it will escape from the command and arbitrary data will be executed instead. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently- used-arguments To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1343657/+subscriptions From nkinder at redhat.com Tue Sep 23 02:21:16 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 23 Sep 2014 02:21:16 -0000 Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup strategies References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com> Message-ID: <20140923022116.32318.93248.malone@gac.canonical.com> @slicknik If you are referring to the usage of subprocess.PIPE for stderr/stdout, that will work fine with 'shell=False' as demonstrated by this sample program (create a /tmp/foo.txt with some content first): ------------------------------------------------------------------------------------------- import os import subprocess command = '/usr/bin/cat /tmp/foo.txt' backup_process = subprocess.Popen(['/usr/bin/cat', '/tmp/foo.txt'], shell=False, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) print '%s' % backup_process.stdout.read() ------------------------------------------------------------------------------------------- Are you piping the output of one command to another in the command that is passed into subprocess.Popen() in BackupRunner? If so, you can also do that like this: ------------------------------------------------------------------------------------------- import os import subprocess command = '/usr/bin/cat /tmp/foo.txt' backup_process = subprocess.Popen(['/usr/bin/cat', '/tmp/foo.txt'], shell=False, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) grep_process = subprocess.Popen(['/usr/bin/grep', 'blah'], shell=False, stdin=backup_process.stdout, stdout=subprocess.PIPE) print '%s' % grep_process.stdout.read() ------------------------------------------------------------------------------------------- -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1343657 Title: Shell Injection in backup strategies Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Openstack Database (Trove): New Bug description: Trove uses subprocess.Popen with shell=True in trove/trove/guestagent/strategies/backup/base.py line 61: def run(self): self.process = subprocess.Popen(self.command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, preexec_fn=os.setsid) self.pid = self.process.pid This could be used, maliciously or not, to inject arbitrary commands into a command line string. An example of this could be triggered is in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It is creating a MySQL string with single quote. If the password, either maliciously or just happens to contain another single quote, it will escape from the command and arbitrary data will be executed instead. For more information on subprocess, shell=True and command injection see: https://docs.python.org/2/library/subprocess.html#frequently- used-arguments To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1343657/+subscriptions From gerrit2 at review.openstack.org Tue Sep 23 07:49:09 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 23 Sep 2014 07:49:09 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Ie19d093d0494443ce4cd880ae1f92dffd5c361ef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/117372 Log: commit e0f352dc7931d6d4e565de16814d126992f2182c Author: Brant Knudson Date: Wed Aug 27 17:53:41 2014 -0500 token signing support alternative message digest The functions for creating signed tokens in common.cms always used sha256 for the message digest. This might be inadequate in the future so the digest algorithm shouldn't be hard-coded. A parameter is added to allow choosing a different digest algorithm. SecurityImpact Change-Id: Ie19d093d0494443ce4cd880ae1f92dffd5c361ef Related-Bug: #1362343 From mikal at stillhq.com Tue Sep 23 08:08:33 2014 From: mikal at stillhq.com (Michael Still) Date: Tue, 23 Sep 2014 08:08:33 -0000 Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will have issues when booting two with different config drive values References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com> Message-ID: <20140923080833.32158.89559.malone@gac.canonical.com> In the end it looks like we're resolving this one by reverting these changes: 228d0221763b12f11ecbacde4db38b1151f96e31 0b01e846d40f3b343da9ebe1dae89cca8bc2ac66 ecce888c469c62374a3cc43e3cede11d8aa1e799 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369627 Title: libvirt disk.config will have issues when booting two with different config drive values Status in OpenStack Compute (Nova): In Progress Bug description: Currently, in the image creating code for Juno we have if configdrive.required_by(instance): LOG.info(_LI('Using config drive'), instance=instance) image_type = self._get_configdrive_image_type() backend = image('disk.config', image_type) backend.cache(fetch_func=self._create_configdrive, filename='disk.config' + suffix, instance=instance, admin_pass=admin_pass, files=files, network_info=network_info) The important thing to notice here is that we have "filename='disk.confg' + suffix". This means that the filename for the config drive in the cache directory will be simply 'disk.config' followed by any potential suffix (e.g. '.rescue'). This name is not unique to the instance whose config drive we are creating. Therefore, when we go to boot another instance with a different config drive, the cache function will detect the old config drive, and decide it doesn't need to create the new config drive with the appropriate config for the new instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369627/+subscriptions From john at johngarbutt.com Tue Sep 23 08:11:52 2014 From: john at johngarbutt.com (John Garbutt) Date: Tue, 23 Sep 2014 08:11:52 -0000 Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will have issues when booting two with different config drive values References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com> Message-ID: <20140923081153.24911.60162.launchpad@soybean.canonical.com> ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369627 Title: libvirt disk.config will have issues when booting two with different config drive values Status in OpenStack Compute (Nova): In Progress Bug description: Currently, in the image creating code for Juno we have if configdrive.required_by(instance): LOG.info(_LI('Using config drive'), instance=instance) image_type = self._get_configdrive_image_type() backend = image('disk.config', image_type) backend.cache(fetch_func=self._create_configdrive, filename='disk.config' + suffix, instance=instance, admin_pass=admin_pass, files=files, network_info=network_info) The important thing to notice here is that we have "filename='disk.confg' + suffix". This means that the filename for the config drive in the cache directory will be simply 'disk.config' followed by any potential suffix (e.g. '.rescue'). This name is not unique to the instance whose config drive we are creating. Therefore, when we go to boot another instance with a different config drive, the cache function will detect the old config drive, and decide it doesn't need to create the new config drive with the appropriate config for the new instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369627/+subscriptions From nsaje at redhat.com Mon Sep 22 13:43:29 2014 From: nsaje at redhat.com (Nejc Saje) Date: Mon, 22 Sep 2014 13:43:29 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922134329.32745.22412.malone@gac.canonical.com> It does come from a config file, as Eoghan mentioned, and from config file only. Can you provide more specific examples of what you mean by inferred from something that is user controlled? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): New Status in OpenStack Security Advisories: Incomplete Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From 1370283 at bugs.launchpad.net Mon Sep 22 15:18:25 2014 From: 1370283 at bugs.launchpad.net (Matthew Thode) Date: Mon, 22 Sep 2014 15:18:25 -0000 Subject: [Openstack-security] [Bug 1370283] Re: python-glanceclient uses extremely insecure configurations of OpenSSL References: <20140916232429.32614.13519.malonedeb@gac.canonical.com> Message-ID: <20140922151825.18276.12307.malone@chaenomeles.canonical.com> why was this closed, was the cipher suite strengthened? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1370283 Title: python-glanceclient uses extremely insecure configurations of OpenSSL Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Glance: New Bug description: glanceclient does not properly configure OpenSSL, which results in making TLS connections which allow extremely bad security settings. Specifically it allows SSLv2, and many insecure ciphersuites. From Ubuntu 14.04: >>> import pprint; import glanceclient.common.http; pprint.pprint(glanceclient.common.http.HTTPClient('https://', ssl_compression=False).session.get("https://www.howsmyssl.com/a/check").json()) {u'able_to_detect_n_minus_one_splitting': False, u'beast_vuln': False, u'ephemeral_keys_supported': True, u'given_cipher_suites': [u'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_AES_256_GCM_SHA384', u'TLS_RSA_WITH_AES_256_CBC_SHA256', u'TLS_RSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA', u'TLS_DHE_RSA_WITH_SEED_CBC_SHA', u'TLS_DHE_DSS_WITH_SEED_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_AES_128_GCM_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_SEED_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDHE_RSA_WITH_RC4_128_SHA', u'TLS_ECDHE_ECDSA_WITH_RC4_128_SHA', u'TLS_ECDH_RSA_WITH_RC4_128_SHA', u'TLS_ECDH_ECDSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_MD5', u'TLS_DHE_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_DSS_WITH_DES_CBC_SHA', u'TLS_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5', u'TLS_RSA_EXPORT_WITH_RC4_40_MD5', u'TLS_EMPTY_RENEGOTIATION_INFO_SCSV'], u'insecure_cipher_suites': {u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_DSS_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC4_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption']}, u'rating': u'Bad', u'session_ticket_supported': True, u'tls_compression_supported': False, u'tls_version': u'TLS 1.2', u'unknown_cipher_suite_supported': False} I *strongly* recommend just deleting all this code and using requests. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1370283/+subscriptions From 1370283 at bugs.launchpad.net Mon Sep 22 16:23:31 2014 From: 1370283 at bugs.launchpad.net (Stuart McLaren) Date: Mon, 22 Sep 2014 16:23:31 -0000 Subject: [Openstack-security] [Bug 1370283] Re: python-glanceclient uses extremely insecure configurations of OpenSSL References: <20140916232429.32614.13519.malonedeb@gac.canonical.com> Message-ID: <20140922162331.5205.65847.malone@wampee.canonical.com> @matthew No, the patch is still up for review: https://review.openstack.org/122749 @jeremy can you comment on why this was closed? Thanks. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1370283 Title: python-glanceclient uses extremely insecure configurations of OpenSSL Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Glance: New Bug description: glanceclient does not properly configure OpenSSL, which results in making TLS connections which allow extremely bad security settings. Specifically it allows SSLv2, and many insecure ciphersuites. From Ubuntu 14.04: >>> import pprint; import glanceclient.common.http; pprint.pprint(glanceclient.common.http.HTTPClient('https://', ssl_compression=False).session.get("https://www.howsmyssl.com/a/check").json()) {u'able_to_detect_n_minus_one_splitting': False, u'beast_vuln': False, u'ephemeral_keys_supported': True, u'given_cipher_suites': [u'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_AES_256_GCM_SHA384', u'TLS_RSA_WITH_AES_256_CBC_SHA256', u'TLS_RSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA', u'TLS_DHE_RSA_WITH_SEED_CBC_SHA', u'TLS_DHE_DSS_WITH_SEED_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_AES_128_GCM_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_SEED_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDHE_RSA_WITH_RC4_128_SHA', u'TLS_ECDHE_ECDSA_WITH_RC4_128_SHA', u'TLS_ECDH_RSA_WITH_RC4_128_SHA', u'TLS_ECDH_ECDSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_MD5', u'TLS_DHE_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_DSS_WITH_DES_CBC_SHA', u'TLS_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5', u'TLS_RSA_EXPORT_WITH_RC4_40_MD5', u'TLS_EMPTY_RENEGOTIATION_INFO_SCSV'], u'insecure_cipher_suites': {u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_DSS_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC4_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption']}, u'rating': u'Bad', u'session_ticket_supported': True, u'tls_compression_supported': False, u'tls_version': u'TLS 1.2', u'unknown_cipher_suite_supported': False} I *strongly* recommend just deleting all this code and using requests. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1370283/+subscriptions From 1369487 at bugs.launchpad.net Mon Sep 22 16:44:14 2014 From: 1369487 at bugs.launchpad.net (Joe Gordon) Date: Mon, 22 Sep 2014 16:44:14 -0000 Subject: [Openstack-security] [Bug 1369487] Re: NIST: increase RSA key length to 2048 bit References: <20140915100120.18130.90286.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922164416.32257.23593.launchpad@gac.canonical.com> ** Changed in: nova Milestone: None => juno-rc1 ** Changed in: nova Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369487 Title: NIST: increase RSA key length to 2048 bit Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: According to NIST 800-131A, RSA key lenght for digital signature must >= 2048 bit. In crypto.py, we use 1024 bit as the default key length to generate cert file, and does not specify any larger number to override the default value when utilizing it. def generate_x509_cert(user_id, project_id, bits=1024): Need to increase the default key length to 2048 bit. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369487/+subscriptions From 1371355 at bugs.launchpad.net Mon Sep 22 17:08:53 2014 From: 1371355 at bugs.launchpad.net (Tushar Patil) Date: Mon, 22 Sep 2014 17:08:53 -0000 Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs x-subject-token at the debug log level References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922170856.4708.39898.launchpad@wampee.canonical.com> ** Changed in: python-keystoneclient Assignee: (unassigned) => Tushar Patil (tpatil) ** Changed in: python-keystoneclient Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1371355 Title: Keystone client logs x-subject-token at the debug log level Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Keystone: In Progress Bug description: When you invoke any OpenStack API of any of the OpenStack services listed below, then it logs readable x-subject-token as a debug log message in the respective log file. x-subject-token is introduced in v3, so only setups using v3 keystone apis are affected. All OpenStack services using keystone client for authentication and debug log level are affected Service affected are: glance neutron cinder heat ceilometer nova keystone neutron Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log nova-api.log {{{ 2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153 2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’}) }}} I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information. {{{ openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5" HTTP/1.1 200 OK Content-Type: application/json Content-Length: 15 X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d Date: Thu, 18 Sep 2014 22:58:56 GMT {"servers": []} }}} To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1371355/+subscriptions From patriziotufarolo at gmail.com Mon Sep 22 20:14:24 2014 From: patriziotufarolo at gmail.com (Patrizio Tufarolo) Date: Mon, 22 Sep 2014 20:14:24 -0000 Subject: [Openstack-security] [Bug 1372375] Re: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922201424.25282.89945.malone@soybean.canonical.com> I am so sorry for the mistake. I think it is really important to have it fixed because it could cause whole damages to companies that use LUKS in a production environment. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372375 Title: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: I have doubts about the flow of the volume attaching operation, as defined in /usr/lib/python2.6/site- packages/nova/volume/encryptors/luks.py. If the device is not recognized to be a valid luks device, the script is luks formatting it! So if for some reason the luks header get corrupted, it erases the whole data. To manage corrupted headers there are the cryptsetup luksHeaderBackup and cryptsetup luksHeaderRestore commands that respectively do the backup and the restore of the headers. I think that the process has to be reviewed, and the luksFormat operation has to be performed during the volume creation. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1372375/+subscriptions From 1369487 at bugs.launchpad.net Mon Sep 22 20:51:57 2014 From: 1369487 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 22 Sep 2014 20:51:57 -0000 Subject: [Openstack-security] [Bug 1369487] Re: NIST: increase RSA key length to 2048 bit References: <20140915100120.18130.90286.malonedeb@chaenomeles.canonical.com> Message-ID: <20140922205157.24844.11355.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/121497 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=3957d3bed8f2ee2bbb9e54dd67d4f3ab25fc3a13 Submitter: Jenkins Branch: master commit 3957d3bed8f2ee2bbb9e54dd67d4f3ab25fc3a13 Author: Qin Zhao Date: Mon Sep 15 18:08:51 2014 +0800 NIST: increase RSA key length to 2048 bit According to NIST 800-131A, RSA key lenght for digital signature must >= 2048 bit. Now we use 1024 bit key to generate x509 cert file. Need to increase the key length to 2048 bit. Change-Id: I59f614b5d8a79f9e0a96503867cfca176be5c757 Closes-Bug: 1369487 ** Changed in: nova Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369487 Title: NIST: increase RSA key length to 2048 bit Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Security Advisories: Won't Fix Bug description: According to NIST 800-131A, RSA key lenght for digital signature must >= 2048 bit. In crypto.py, we use 1024 bit as the default key length to generate cert file, and does not specify any larger number to override the default value when utilizing it. def generate_x509_cert(user_id, project_id, bits=1024): Need to increase the default key length to 2048 bit. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369487/+subscriptions From carl.baldwin at hp.com Mon Sep 22 21:22:01 2014 From: carl.baldwin at hp.com (Carl Baldwin) Date: Mon, 22 Sep 2014 21:22:01 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140922212203.18210.57106.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Assignee: Carl Baldwin (carl-baldwin) => yong sheng gong (gongysh) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From ankit11.agrawal at nttdata.com Tue Sep 23 06:46:49 2014 From: ankit11.agrawal at nttdata.com (Ankit Agrawal) Date: Tue, 23 Sep 2014 06:46:49 -0000 Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs x-subject-token at the debug log level References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com> Message-ID: <20140923064651.5162.76774.launchpad@wampee.canonical.com> ** Changed in: python-keystoneclient Assignee: Tushar Patil (tpatil) => Ankit Agrawal (ankitagrawal) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1371355 Title: Keystone client logs x-subject-token at the debug log level Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Keystone: In Progress Bug description: When you invoke any OpenStack API of any of the OpenStack services listed below, then it logs readable x-subject-token as a debug log message in the respective log file. x-subject-token is introduced in v3, so only setups using v3 keystone apis are affected. All OpenStack services using keystone client for authentication and debug log level are affected Service affected are: glance neutron cinder heat ceilometer nova keystone neutron Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log nova-api.log {{{ 2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153 2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’}) }}} I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information. {{{ openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5" HTTP/1.1 200 OK Content-Type: application/json Content-Length: 15 X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d Date: Thu, 18 Sep 2014 22:58:56 GMT {"servers": []} }}} To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1371355/+subscriptions From nsaje at redhat.com Tue Sep 23 07:23:09 2014 From: nsaje at redhat.com (Nejc Saje) Date: Tue, 23 Sep 2014 07:23:09 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140923072309.17873.64745.malone@chaenomeles.canonical.com> Even setting __builtins__ to None is possible to circumvent: http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html . I personally wouldn't mind including your change since it introduces more 'hygenic' use of eval, but as was said before, the input to the eval is protected by filesystem permissions anyway. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From duncan.thomas at gmail.com Tue Sep 23 11:31:45 2014 From: duncan.thomas at gmail.com (Duncan Thomas) Date: Tue, 23 Sep 2014 11:31:45 -0000 Subject: [Openstack-security] [Bug 1372375] Re: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: <20140923113145.32706.28863.malone@gac.canonical.com> Adding cinder on since it is likely the fix will end up in cinder ** Also affects: cinder Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372375 Title: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted Status in Cinder: New Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: I have doubts about the flow of the volume attaching operation, as defined in /usr/lib/python2.6/site- packages/nova/volume/encryptors/luks.py. If the device is not recognized to be a valid luks device, the script is luks formatting it! So if for some reason the luks header get corrupted, it erases the whole data. To manage corrupted headers there are the cryptsetup luksHeaderBackup and cryptsetup luksHeaderRestore commands that respectively do the backup and the restore of the headers. I think that the process has to be reviewed, and the luksFormat operation has to be performed during the volume creation. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1372375/+subscriptions From fungi at yuggoth.org Tue Sep 23 13:23:11 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 23 Sep 2014 13:23:11 -0000 Subject: [Openstack-security] [Bug 1370283] Re: python-glanceclient uses extremely insecure configurations of OpenSSL References: <20140916232429.32614.13519.malonedeb@gac.canonical.com> Message-ID: <20140923132311.5205.94593.malone@wampee.canonical.com> The bug is not closed--it's still in an untriaged "new" state for python-glanceclient. I merely marked the security advsory task "won't fix" to denote that the VMT has judged this a security hardening opportunity rather than an explicit security vulnerability. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1370283 Title: python-glanceclient uses extremely insecure configurations of OpenSSL Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Glance: New Bug description: glanceclient does not properly configure OpenSSL, which results in making TLS connections which allow extremely bad security settings. Specifically it allows SSLv2, and many insecure ciphersuites. From Ubuntu 14.04: >>> import pprint; import glanceclient.common.http; pprint.pprint(glanceclient.common.http.HTTPClient('https://', ssl_compression=False).session.get("https://www.howsmyssl.com/a/check").json()) {u'able_to_detect_n_minus_one_splitting': False, u'beast_vuln': False, u'ephemeral_keys_supported': True, u'given_cipher_suites': [u'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_GCM_SHA384', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_256_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_256_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384', u'TLS_ECDH_RSA_WITH_AES_256_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_AES_256_GCM_SHA384', u'TLS_RSA_WITH_AES_256_CBC_SHA256', u'TLS_RSA_WITH_AES_256_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_256_CBC_SHA', u'TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA', u'TLS_RSA_WITH_3DES_EDE_CBC_SHA', u'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA256', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA256', u'TLS_DHE_RSA_WITH_AES_128_CBC_SHA', u'TLS_DHE_DSS_WITH_AES_128_CBC_SHA', u'TLS_DHE_RSA_WITH_SEED_CBC_SHA', u'TLS_DHE_DSS_WITH_SEED_CBC_SHA', u'TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256', u'TLS_ECDH_RSA_WITH_AES_128_CBC_SHA', u'TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_AES_128_GCM_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA256', u'TLS_RSA_WITH_AES_128_CBC_SHA', u'TLS_RSA_WITH_SEED_CBC_SHA', u'TLS_RSA_WITH_CAMELLIA_128_CBC_SHA', u'TLS_ECDHE_RSA_WITH_RC4_128_SHA', u'TLS_ECDHE_ECDSA_WITH_RC4_128_SHA', u'TLS_ECDH_RSA_WITH_RC4_128_SHA', u'TLS_ECDH_ECDSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_SHA', u'TLS_RSA_WITH_RC4_128_MD5', u'TLS_DHE_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_DSS_WITH_DES_CBC_SHA', u'TLS_RSA_WITH_DES_CBC_SHA', u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA', u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5', u'TLS_RSA_EXPORT_WITH_RC4_40_MD5', u'TLS_EMPTY_RENEGOTIATION_INFO_SCSV'], u'insecure_cipher_suites': {u'TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_DSS_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_DHE_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_DES40_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_EXPORT_WITH_RC4_40_MD5': [u'uses keys smaller than 128 bits in its encryption'], u'TLS_RSA_WITH_DES_CBC_SHA': [u'uses keys smaller than 128 bits in its encryption']}, u'rating': u'Bad', u'session_ticket_supported': True, u'tls_compression_supported': False, u'tls_version': u'TLS 1.2', u'unknown_cipher_suite_supported': False} I *strongly* recommend just deleting all this code and using requests. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1370283/+subscriptions From fungi at yuggoth.org Tue Sep 23 13:26:42 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 23 Sep 2014 13:26:42 -0000 Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will have issues when booting two with different config drive values References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com> Message-ID: <20140923132643.17807.73401.malone@chaenomeles.canonical.com> This only affects juno right? (Those changes are only in the master branch?) Just confirming we don't need an advisory for any released versions. ** 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 Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369627 Title: libvirt disk.config will have issues when booting two with different config drive values Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Incomplete Bug description: Currently, in the image creating code for Juno we have if configdrive.required_by(instance): LOG.info(_LI('Using config drive'), instance=instance) image_type = self._get_configdrive_image_type() backend = image('disk.config', image_type) backend.cache(fetch_func=self._create_configdrive, filename='disk.config' + suffix, instance=instance, admin_pass=admin_pass, files=files, network_info=network_info) The important thing to notice here is that we have "filename='disk.confg' + suffix". This means that the filename for the config drive in the cache directory will be simply 'disk.config' followed by any potential suffix (e.g. '.rescue'). This name is not unique to the instance whose config drive we are creating. Therefore, when we go to boot another instance with a different config drive, the cache function will detect the old config drive, and decide it doesn't need to create the new config drive with the appropriate config for the new instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369627/+subscriptions From 1367022 at bugs.launchpad.net Tue Sep 23 13:44:13 2014 From: 1367022 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 23 Sep 2014 13:44:13 -0000 Subject: [Openstack-security] [Bug 1367022] Change abandoned on ceilometer (master) References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140923134413.5098.47660.malone@wampee.canonical.com> Change abandoned by Brant Knudson (bknudson at us.ibm.com) on branch: master Review: https://review.openstack.org/123237 Reason: This is completely useless. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From sross at redhat.com Tue Sep 23 15:01:46 2014 From: sross at redhat.com (Solly Ross) Date: Tue, 23 Sep 2014 15:01:46 -0000 Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will have issues when booting two with different config drive values References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com> Message-ID: <20140923150146.17709.4956.malone@chaenomeles.canonical.com> Yep, it's only people running off of master. ** Changed in: ossa Status: Incomplete => New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369627 Title: libvirt disk.config will have issues when booting two with different config drive values Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: New Bug description: Currently, in the image creating code for Juno we have if configdrive.required_by(instance): LOG.info(_LI('Using config drive'), instance=instance) image_type = self._get_configdrive_image_type() backend = image('disk.config', image_type) backend.cache(fetch_func=self._create_configdrive, filename='disk.config' + suffix, instance=instance, admin_pass=admin_pass, files=files, network_info=network_info) The important thing to notice here is that we have "filename='disk.confg' + suffix". This means that the filename for the config drive in the cache directory will be simply 'disk.config' followed by any potential suffix (e.g. '.rescue'). This name is not unique to the instance whose config drive we are creating. Therefore, when we go to boot another instance with a different config drive, the cache function will detect the old config drive, and decide it doesn't need to create the new config drive with the appropriate config for the new instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369627/+subscriptions From fungi at yuggoth.org Tue Sep 23 15:30:05 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 23 Sep 2014 15:30:05 -0000 Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will have issues when booting two with different config drive values References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com> Message-ID: <20140923153005.18008.89934.malone@chaenomeles.canonical.com> Thanks Solly. Setting the OSSA task to won't fix in that case, to track that we don't need an advisory. ** Changed in: ossa Status: New => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369627 Title: libvirt disk.config will have issues when booting two with different config drive values Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Currently, in the image creating code for Juno we have if configdrive.required_by(instance): LOG.info(_LI('Using config drive'), instance=instance) image_type = self._get_configdrive_image_type() backend = image('disk.config', image_type) backend.cache(fetch_func=self._create_configdrive, filename='disk.config' + suffix, instance=instance, admin_pass=admin_pass, files=files, network_info=network_info) The important thing to notice here is that we have "filename='disk.confg' + suffix". This means that the filename for the config drive in the cache directory will be simply 'disk.config' followed by any potential suffix (e.g. '.rescue'). This name is not unique to the instance whose config drive we are creating. Therefore, when we go to boot another instance with a different config drive, the cache function will detect the old config drive, and decide it doesn't need to create the new config drive with the appropriate config for the new instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369627/+subscriptions From slukjanov at mirantis.com Tue Sep 23 16:31:42 2014 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Tue, 23 Sep 2014 16:31:42 -0000 Subject: [Openstack-security] [Bug 1321906] Re: [EDP] Swift credentials passed in plain text References: <20140521195819.29499.71748.malonedeb@wampee.canonical.com> Message-ID: <20140923163142.5430.31788.malone@wampee.canonical.com> Fix has been committed as part of new feature - https://blueprints.launchpad.net/sahara/+spec/edp-swift-trust- authentication ** Changed in: sahara Status: Triaged => Fix Committed ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1321906 Title: [EDP] Swift credentials passed in plain text Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara, ex. Savanna): Fix Committed Bug description: For Sahara, we support job binaries and data sources in Swift. Job binaries are accessed from the Sahara process, and data sources are accessed from Hadoop at job execution time. Username/password credentials are required for swift access. These credentials might be/are compromised in the following ways: 1) For both job binaries and data sources, objects are created and stored in the Sahara database that contain the path and the associated credentials in plain text. Anyone gaining access to the database can therefore read the username/password credentials stored there with the swift path. 2) For data sources, the credentials are passed as part of the Hadoop job configuration. Currently all Hadoop jobs are run as Oozie workflows. The swift username and password values are set in the workflow.xml file, and are visible to anyone that can access the Oozie UI console, use the Oozie command line to retrieve the workflow.xml, or even use hadoop fs to look at the files uploaded for the job (which include the workflow.xml) We need a way for Sahara and Hadoop to access swift objects securely, without exposing swift credentials in workflow.xml or storing them in the database in plain text. In the future we will support mechanisms other than Oozie so this is not just an Oozie issue per se. For further background, here is the Hadoop patch that allows Hadoop to access swift paths. It uses a service suffix in the netlocation portion of the URL to match the URL against credential values in the job configuration. Any solution to this issue will require a new patch to Hadoop itself, as well as changes to the Sahara code base. https://issues.apache.org/jira/browse/HADOOP-8545 It's been suggested within the Sahara team that we can potentially accomplish this with trusts. Note, this vulnerability isn't really a secret to anyone observant who is familiar with Sahara EDP, but it is probably better not to trumpet it too loudly. To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1321906/+subscriptions From gary.w.smith at hp.com Tue Sep 23 20:05:40 2014 From: gary.w.smith at hp.com (Gary W. Smith) Date: Tue, 23 Sep 2014 20:05:40 -0000 Subject: [Openstack-security] [Bug 1369870] Re: The cookies for messages, django_timezone, horizon_pagesize, and horizon_language are not marked as "secure" References: <20140916063505.5162.66017.malonedeb@wampee.canonical.com> Message-ID: <20140923200541.32380.87728.launchpad@gac.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369870 Title: The cookies for messages, django_timezone,horizon_pagesize, and horizon_language are not marked as "secure" Status in OpenStack Dashboard (Horizon): Incomplete Bug description: Affected URL: https://Ip_address/settings/ Affected Entity: messages, django_timezone, horizon_pagesize, and horizon_language Risk: It may be possible to steal user and session information (cookies) that was sent during an encrypted session Causes: The web application sends non-secure cookies over SSL Recommend Fix: Add the 'Secure' attribute to all sensitive cookies To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369870/+subscriptions From gary.w.smith at hp.com Tue Sep 23 20:05:23 2014 From: gary.w.smith at hp.com (Gary W. Smith) Date: Tue, 23 Sep 2014 20:05:23 -0000 Subject: [Openstack-security] [Bug 1369865] Re: Permanent Cookie Contains Sensitive Session Information References: <20140916062427.24753.72518.malonedeb@soybean.canonical.com> Message-ID: <20140923200524.25110.86822.launchpad@soybean.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369865 Title: Permanent Cookie Contains Sensitive Session Information Status in OpenStack Dashboard (Horizon): New Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It may be possible to steal session information (cookies) that was kept on disk as permanent cookies. Causes: The web application stores sensitive session information in a permanent cookie (on disk) Recommend Fix: Avoid storing sensitive session information in permanent cookies Test requests and response: GET /admin/ HTTP/1.1 Host: 9.5.29.52 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://9.5.29.52/ Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb Connection: keep-alive HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 07:52:50 GMT Server: Apache Vary: Accept-Language,Cookie,Accept-Encoding X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure 2014/9/12 516 Usage Overview - Cloud Management Dashboard

Cloud Management Dashboard

2014/9/12 517 TOC
Project

Orchestration

... ... ... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369865/+subscriptions From 1334926 at bugs.launchpad.net Tue Sep 23 21:39:23 2014 From: 1334926 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 23 Sep 2014 21:39:23 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140923213925.32477.35199.launchpad@gac.canonical.com> ** Changed in: neutron Assignee: yong sheng gong (gongysh) => Carl Baldwin (carl-baldwin) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From mikal at stillhq.com Wed Sep 24 01:26:22 2014 From: mikal at stillhq.com (Michael Still) Date: Wed, 24 Sep 2014 01:26:22 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140924012622.442.69606.malone@gac.canonical.com> So, for this to remain RC for nova I need a list of patches that need review. If we don't have that basically now, then we're going to need to drop this from rc1. (That doesn't mean its important, just that I don't think we can hold rc1 waiting for it). -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in Oslo VMware library for OpenStack projects: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From robert.clark at hp.com Wed Sep 24 13:42:02 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 24 Sep 2014 13:42:02 +0000 Subject: [Openstack-security] Summit Planning for Security / OSSG Message-ID: If you have ideas for security related sessions at the summit please update the summit etherpad https://wiki.openstack.org/wiki/Summit/Planning -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From gerrit2 at review.openstack.org Wed Sep 24 16:01:22 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 24 Sep 2014 16:01:22 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Ie19d093d0494443ce4cd880ae1f92dffd5c361ef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/117372 Log: commit 554152e2fee926b1f99bb3eb9873adb684da3fc6 Author: Brant Knudson Date: Wed Aug 27 17:53:41 2014 -0500 token signing support alternative message digest The functions for creating signed tokens in common.cms always used sha256 for the message digest. This might be inadequate in the future so the digest algorithm shouldn't be hard-coded. A parameter is added to allow choosing a different digest algorithm. SecurityImpact Change-Id: Ie19d093d0494443ce4cd880ae1f92dffd5c361ef Related-Bug: #1362343 From gerrit2 at review.openstack.org Wed Sep 24 16:01:28 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 24 Sep 2014 16:01:28 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Iff063149e1f12df69bbf9015222d09d798980872 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/117371 Log: commit 84c9ccaed34d83b7e97a4890561b1b218d99b1ba Author: Brant Knudson Date: Wed Aug 27 17:50:19 2014 -0500 Change cms_sign_data to use sha256 message digest cms_sign_data was not passing the md parameter to openssl, so it was using the default digest of sha1. Some security standards require a SHA2 algorithm for the digest. This if for security hardening. SecurityImpact Change-Id: Iff063149e1f12df69bbf9015222d09d798980872 Closes-Bug: #1362343 From nkinder at redhat.com Wed Sep 24 18:39:40 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 24 Sep 2014 18:39:40 -0000 Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs x-subject-token at the debug log level References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com> Message-ID: <20140924183940.24944.63478.malone@soybean.canonical.com> It looks like the request side of this was taken care of in the following review: https://review.openstack.org/#/c/110117 It appears that the response side remains exposed. It needs similar 'TOKEN_REDACTED' logic to be implemented. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1371355 Title: Keystone client logs x-subject-token at the debug log level Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Keystone: In Progress Bug description: When you invoke any OpenStack API of any of the OpenStack services listed below, then it logs readable x-subject-token as a debug log message in the respective log file. x-subject-token is introduced in v3, so only setups using v3 keystone apis are affected. All OpenStack services using keystone client for authentication and debug log level are affected Service affected are: glance neutron cinder heat ceilometer nova keystone neutron Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log nova-api.log {{{ 2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153 2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’}) }}} I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information. {{{ openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5" HTTP/1.1 200 OK Content-Type: application/json Content-Length: 15 X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d Date: Thu, 18 Sep 2014 22:58:56 GMT {"servers": []} }}} To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1371355/+subscriptions From gerrit2 at review.openstack.org Wed Sep 24 19:30:42 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 24 Sep 2014 19:30:42 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121382 Log: commit ec249ee8c68e8d22a9e52cdc8bf062e7b0f7fd79 Author: Tristan Cacqueray Date: Sat Sep 13 18:12:05 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly Backport in oslo-incubator: https://review.openstack.org/121365 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Wed Sep 24 19:36:30 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 24 Sep 2014 19:36:30 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121383 Log: commit 2a4897216c544cd05ab8422aa0caa3a955bad95e Author: Tristan Cacqueray Date: Sat Sep 13 18:54:33 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Backport in oslo-incubator: https://review.openstack.org/121365 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From gerrit2 at review.openstack.org Wed Sep 24 19:36:39 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 24 Sep 2014 19:36:39 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121383 Log: commit a0e414f1126916a1547415b2379ebfb18f45973f Author: Tristan Cacqueray Date: Sat Sep 13 18:54:33 2014 +0000 Sync latest process and str utils from oslo This backport the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Backport in oslo-incubator: https://review.openstack.org/121365 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From bknudson at us.ibm.com Wed Sep 24 19:32:14 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Wed, 24 Sep 2014 19:32:14 -0000 Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs x-subject-token at the debug log level References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com> Message-ID: <20140924193214.4767.50412.malone@wampee.canonical.com> The problem is in keystoneclient, it's logged in _http_log_response: http://git.openstack.org/cgit/openstack/python- keystoneclient/tree/keystoneclient/session.py#n158 There's already code in _http_log_request that redacts the token in the requests: http://git.openstack.org/cgit/openstack/python- keystoneclient/tree/keystoneclient/session.py#n158 So the code in _http_log_request needs to be shared with _http_log_response. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1371355 Title: Keystone client logs x-subject-token at the debug log level Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Keystone: In Progress Bug description: When you invoke any OpenStack API of any of the OpenStack services listed below, then it logs readable x-subject-token as a debug log message in the respective log file. x-subject-token is introduced in v3, so only setups using v3 keystone apis are affected. All OpenStack services using keystone client for authentication and debug log level are affected Service affected are: glance neutron cinder heat ceilometer nova keystone neutron Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log nova-api.log {{{ 2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153 2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’}) }}} I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information. {{{ openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5" HTTP/1.1 200 OK Content-Type: application/json Content-Length: 15 X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d Date: Thu, 18 Sep 2014 22:58:56 GMT {"servers": []} }}} To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1371355/+subscriptions From 1371355 at bugs.launchpad.net Wed Sep 24 21:19:34 2014 From: 1371355 at bugs.launchpad.net (Tushar Patil) Date: Wed, 24 Sep 2014 21:19:34 -0000 Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs x-subject-token at the debug log level References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com> Message-ID: <20140924211934.17842.4165.malone@chaenomeles.canonical.com> Ankit has identified what changes are required as pointed out by Brant and he will push the patch by tomorrow. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1371355 Title: Keystone client logs x-subject-token at the debug log level Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Keystone: In Progress Bug description: When you invoke any OpenStack API of any of the OpenStack services listed below, then it logs readable x-subject-token as a debug log message in the respective log file. x-subject-token is introduced in v3, so only setups using v3 keystone apis are affected. All OpenStack services using keystone client for authentication and debug log level are affected Service affected are: glance neutron cinder heat ceilometer nova keystone neutron Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log nova-api.log {{{ 2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153 2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’}) }}} I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information. {{{ openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5" HTTP/1.1 200 OK Content-Type: application/json Content-Length: 15 X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d Date: Thu, 18 Sep 2014 22:58:56 GMT {"servers": []} }}} To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1371355/+subscriptions From gerrit2 at review.openstack.org Thu Sep 25 07:01:50 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 25 Sep 2014 07:01:50 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Iac16c6358250677544761beea9f5c5d8ba29afac Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/123954 Log: commit ebeca911fa291e258c2c0b1ef55a26ff5ac009d2 Author: ankitagrawal Date: Fri Sep 19 04:46:11 2014 -0700 Redact x-subject-token from response headers When you invoke any OpenStack API of any of the OpenStack services e.g. glance, neutron, cinder, heat, ceilometer, nova, keystone then it logs readable x-subject-token at the debug log level in the respective log files. Simply redacting the x-subject-token in keystone client response header before logging it. SecurityImpact Closes-Bug: #1371355 Change-Id: Iac16c6358250677544761beea9f5c5d8ba29afac From 1371355 at bugs.launchpad.net Thu Sep 25 07:01:47 2014 From: 1371355 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 25 Sep 2014 07:01:47 -0000 Subject: [Openstack-security] [Bug 1371355] Fix proposed to python-keystoneclient (master) References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com> Message-ID: <20140925070148.25282.81719.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/123954 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1371355 Title: Keystone client logs x-subject-token at the debug log level Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Keystone: In Progress Bug description: When you invoke any OpenStack API of any of the OpenStack services listed below, then it logs readable x-subject-token as a debug log message in the respective log file. x-subject-token is introduced in v3, so only setups using v3 keystone apis are affected. All OpenStack services using keystone client for authentication and debug log level are affected Service affected are: glance neutron cinder heat ceilometer nova keystone neutron Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log nova-api.log {{{ 2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153 2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’}) }}} I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information. {{{ openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5" HTTP/1.1 200 OK Content-Type: application/json Content-Length: 15 X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d Date: Thu, 18 Sep 2014 22:58:56 GMT {"servers": []} }}} To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1371355/+subscriptions From 1350766 at bugs.launchpad.net Thu Sep 25 07:18:14 2014 From: 1350766 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 25 Sep 2014 07:18:14 -0000 Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute intermittently corrupts base images on download from glance References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com> Message-ID: <20140925071814.25513.80082.malone@soybean.canonical.com> *** This bug is a duplicate of bug 1368815 *** https://bugs.launchpad.net/bugs/1368815 Fix proposed to branch: master Review: https://review.openstack.org/123957 ** Changed in: nova Assignee: Davanum Srinivas (DIMS) (dims-v) => Tony Breeds (o-tony) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1350766 Title: Race condition: compute intermittently corrupts base images on download from glance Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: Under certain conditions, which I happen to meet often on my Icehouse single node setup, uploaded images or snapshots fail to boot. See also https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a -snapshot-from-a-running-instance/ Reason: When first instantiating a QCOW2 image, it's (1) downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part (2) converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img The step (1) is performed in nova/image/glance.py, GlanceImageService.download using buffered IO, which does not guarantee the resulting data to be written to disk on file close. Consequently, the source image file may not be written completely when qemu-img sub-process starts reading in step (2). Whether the result is good or bad depends on speed of download, file size, and how quickly qemu-image can digest its input. Proposed fix: enforce fsync on output File object before returning from download. Patch attached. Security considerations: * Due to the race between resources shared between users and tenants (compute node network and filesystem IO) a failure can be triggered across tenants, implying the risk of DoS. * To make things worse -- with the default setting of not cleaning the image cache -- any corrupted image will remain in cache until replaced with fresh upload using a new image ID. Affected snapshots remain unusable forever, until ex- and re-imported manually under better conditions. * Base image corruptions here are not detected and cannot be caught. Theoretically (a bit esoteric, quite unlikely, but not impossible), an attacker might modulate resource usage to precisely create an incompletely written image, that boots and runs, but has access control information stripped. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1350766/+subscriptions From gerrit2 at review.openstack.org Thu Sep 25 09:05:37 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 25 Sep 2014 09:05:37 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I3b49b1d667f6ade9ae3f6765d735440a3e838917 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/121383 Log: commit f58d95c964cb9a42f573596d1cc80d2034ddb23e Author: Tristan Cacqueray Date: Sat Sep 13 18:54:33 2014 +0000 Sync process and str utils from oslo This patch backports the necessary changes to fix both issues: * Make execute method clean password in exception * Make sure mask_password works properly ------------------------------------------------ The sync pulls in the following changes (newest to oldest): 63c99a0f - Mask passwords in exceptions and error messages 66142c34 - Make strutils.mask_password more secure d6b55fb2 - Remove `processutils` dependency on `log` cb5a804b - Move `mask_password` to strutils ----------------------------------------------- Backport in oslo-incubator: https://review.openstack.org/121365 Closes-Bug: 1343604 Closes-Bug: 1345233 SecurityImpact Change-Id: I3b49b1d667f6ade9ae3f6765d735440a3e838917 From 1334926 at bugs.launchpad.net Thu Sep 25 09:27:09 2014 From: 1334926 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 25 Sep 2014 09:27:09 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140925092709.18041.4064.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/103475 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=966645538395079b5337b5ed30d597112279283c Submitter: Jenkins Branch: master commit 966645538395079b5337b5ed30d597112279283c Author: Yong Sheng Gong Date: Mon Jun 30 15:01:17 2014 +0800 Deletes floating ip related connection states When a floating ip is dissociated with a port, the current connection with the floating ip is still working. This patch will clear the connection state and cut off the connection immediately. Since conntrack -D will return 1, which is not an error code, so add extra_ok_codes argument to execute methods. Change-Id: Ia9bd7ae243a0859dcb97e2fa939f7d16f9c2456c Closes-Bug: 1334926 ** Changed in: neutron Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): Fix Committed Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From mikal at stillhq.com Thu Sep 25 11:30:18 2014 From: mikal at stillhq.com (Michael Still) Date: Thu, 25 Sep 2014 11:30:18 -0000 Subject: [Openstack-security] [Bug 1369627] Re: libvirt disk.config will have issues when booting two with different config drive values References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com> Message-ID: <20140925113018.32642.49910.malone@gac.canonical.com> These reverts have now merged. ** Changed in: nova Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369627 Title: libvirt disk.config will have issues when booting two with different config drive values Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Security Advisories: Won't Fix Bug description: Currently, in the image creating code for Juno we have if configdrive.required_by(instance): LOG.info(_LI('Using config drive'), instance=instance) image_type = self._get_configdrive_image_type() backend = image('disk.config', image_type) backend.cache(fetch_func=self._create_configdrive, filename='disk.config' + suffix, instance=instance, admin_pass=admin_pass, files=files, network_info=network_info) The important thing to notice here is that we have "filename='disk.confg' + suffix". This means that the filename for the config drive in the cache directory will be simply 'disk.config' followed by any potential suffix (e.g. '.rescue'). This name is not unique to the instance whose config drive we are creating. Therefore, when we go to boot another instance with a different config drive, the cache function will detect the old config drive, and decide it doesn't need to create the new config drive with the appropriate config for the new instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369627/+subscriptions From thierry.carrez+lp at gmail.com Thu Sep 25 11:27:14 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 25 Sep 2014 11:27:14 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140925112717.376.63209.launchpad@gac.canonical.com> ** Changed in: nova Milestone: juno-rc1 => None -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in Oslo VMware library for OpenStack projects: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From davanum at gmail.com Thu Sep 25 14:31:49 2014 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Thu, 25 Sep 2014 14:31:49 -0000 Subject: [Openstack-security] [Bug 1328488] Re: oslo apiclient logs sensitive data References: <20140610105701.26336.80011.malonedeb@wampee.canonical.com> Message-ID: <20140925143149.25043.62373.malone@soybean.canonical.com> Being worked on in https://review.openstack.org/#/c/122977/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1328488 Title: oslo apiclient logs sensitive data Status in The Oslo library incubator: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: When trying to clean up the tempest logs in the gate, we leak passwords and keystone tokens everywhere. For instance, python- novaclient logs the auth token. What's more problematic though is that apiclient does the following: def _http_log_req(self, method, url, kwargs): if not self.debug: return string_parts = [ "curl -i", "-X '%s'" % method, "'%s'" % url, ] for element in kwargs['headers']: header = "-H '%s: %s'" % (element, kwargs['headers'][element]) string_parts.append(header) _logger.debug("REQ: %s" % " ".join(string_parts)) if 'data' in kwargs: _logger.debug("REQ BODY: %s\n" % (kwargs['data'])) The argument that it's at DEBUG level doesn't hold, because from the Atlanta operators summit it was clear that *all* operators are running their servers at DEBUG, because OpenStack is impossible to actually troubleshoot at any other logging level. And if you run neutron at debug level, then all your nova credentials are in your logs. This is coupled with the fact that a large amount of users are streaming all their logs directly into logstash. Which means they've now got a potentially public endpoint that lets them search for credentials. We need to stop doing that in a blanket way across OpenStack. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo-incubator/+bug/1328488/+subscriptions From davanum at gmail.com Thu Sep 25 14:41:30 2014 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Thu, 25 Sep 2014 14:41:30 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140925144133.17942.34879.launchpad@chaenomeles.canonical.com> ** Changed in: nova Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Cinder havana series: Fix Released Status in Gantt: New Status in OpenStack Compute (Nova): Fix Committed Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From sean at dague.net Thu Sep 25 15:27:07 2014 From: sean at dague.net (Sean Dague) Date: Thu, 25 Sep 2014 15:27:07 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140925152707.32512.71319.malone@gac.canonical.com> The generic version of this isn't getting fixed in Nova, so openning the following bugs: https://bugs.launchpad.net/nova/+bug/1373992 https://bugs.launchpad.net/nova/+bug/1373993 https://bugs.launchpad.net/nova/+bug/1374000 https://bugs.launchpad.net/nova/+bug/1374001 For the specific instances where we need to fix this -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in Oslo VMware library for OpenStack projects: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1188189 at bugs.launchpad.net Thu Sep 25 16:28:50 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 25 Sep 2014 16:28:50 -0000 Subject: [Openstack-security] [Bug 1188189] Related fix proposed to nova (master) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140925162850.25451.35537.malone@soybean.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/124104 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo VMware library for OpenStack projects: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From sean at dague.net Thu Sep 25 16:33:10 2014 From: sean at dague.net (Sean Dague) Date: Thu, 25 Sep 2014 16:33:10 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140925163310.5362.19018.malone@wampee.canonical.com> Nova bugs will be tracked in the separate bugs listed above, so removing Nova from this bug. ** No longer affects: nova -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo VMware library for OpenStack projects: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From patriziotufarolo at gmail.com Thu Sep 25 16:57:39 2014 From: patriziotufarolo at gmail.com (Patrizio Tufarolo) Date: Thu, 25 Sep 2014 16:57:39 -0000 Subject: [Openstack-security] [Bug 1372375] Re: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: <20140925165739.5063.99900.malone@wampee.canonical.com> The bug I submitted wants to be related more to the flow of the volume encryption procedure than to the LUKS header backup, that is also important. I have no idea, at the moment, on where to store luks headers' backup, I'm looking around. However a backup of the whole volume could be sufficient, but in my opinion it could become expensive in some cases. I focused on luksHeaderBackup and luksHeaderRestore to highlight on how formatting a volume is not a valid choice when the device is not recognized as valid luks. I agree with the decision to format the device in Nova, but I think that Cinder should ask luksFormat to nova at the moment of volume creation, and not when attaching for the problem above. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372375 Title: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted Status in Cinder: New Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: I have doubts about the flow of the volume attaching operation, as defined in /usr/lib/python2.6/site- packages/nova/volume/encryptors/luks.py. If the device is not recognized to be a valid luks device, the script is luks formatting it! So if for some reason the luks header get corrupted, it erases the whole data. To manage corrupted headers there are the cryptsetup luksHeaderBackup and cryptsetup luksHeaderRestore commands that respectively do the backup and the restore of the headers. I think that the process has to be reviewed, and the luksFormat operation has to be performed during the volume creation. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1372375/+subscriptions From gary.w.smith at hp.com Thu Sep 25 18:30:52 2014 From: gary.w.smith at hp.com (Gary W. Smith) Date: Thu, 25 Sep 2014 18:30:52 -0000 Subject: [Openstack-security] [Bug 1369876] Re: Missing HttpOnly Attribute in Session Cookie References: <20140916064453.32545.92390.malonedeb@gac.canonical.com> Message-ID: <20140925183053.32220.54219.launchpad@gac.canonical.com> ** Tags added: security ** Changed in: horizon Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369876 Title: Missing HttpOnly Attribute in Session Cookie Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It is possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user. Causes: The web application sets session cookies without the HttpOnly attribute Recommend Fix: Add the 'HttpOnly' attribute to all session cookies. The Test Requests and Responses: GET /admin/ HTTP/1.1 Host: 9.5.29.52 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://9.5.29.52/ Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb Connection: keep-alive HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 07:52:50 GMT Server: Apache Vary: Accept-Language,Cookie,Accept-Encoding X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive 2014/9/12 504 Transfer-Encoding: chunked Content-Type: text/html Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure Usage Overview - Cloud Management Dashboard

Cloud Management Dashboard

admin
Project

Orchestration

... ... ... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369876/+subscriptions From nkinder at redhat.com Fri Sep 26 02:27:40 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 26 Sep 2014 02:27:40 -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: <20140926022741.25387.72436.malone@soybean.canonical.com> This was published as OSSN-0027: https://wiki.openstack.org/wiki/OSSN/OSSN-0027 ** Changed in: ossn Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Advisories: 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 nkinder at redhat.com Fri Sep 26 02:26:29 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 26 Sep 2014 02:26:29 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140926022630.32614.26161.malone@gac.canonical.com> This was published as OSSN-0024: https://wiki.openstack.org/wiki/OSSN/OSSN-0024 ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From gerrit2 at review.openstack.org Fri Sep 26 06:14:19 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 26 Sep 2014 06:14:19 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I8e46d41164e9478b820cad569ba82f25de244620 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/124296 Log: commit ecfbc4806deaecb005a6d7f4e848a01dc2c5021d Author: melanie witt Date: Fri Sep 26 05:15:16 2014 +0000 replace httplib.HTTPSConnection in EC2KeystoneAuth httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. This change replaces use of httplib.HTTPSConnection with the requests module. It also adds some config settings related to SSL verification: keystone_ec2_keyfile, keystone_ec2_certfile, keystone_ec2_cafile, keystone_ec2_insecure. By default, SSL verification is on, but can be disabled by setting: keystone_ec2_insecure=true This patch is based on the keystone middleware ec2 token patch: https://review.openstack.org/#/c/76476 SecurityImpact DocImpact Closes-Bug: #1373992 Change-Id: I8e46d41164e9478b820cad569ba82f25de244620 From 1188189 at bugs.launchpad.net Fri Sep 26 07:47:01 2014 From: 1188189 at bugs.launchpad.net (haruka tanizawa) Date: Fri, 26 Sep 2014 07:47:01 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140926074702.25513.3004.malone@soybean.canonical.com> Is there any in progress work for neutron ? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo VMware library for OpenStack projects: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From thierry.carrez+lp at gmail.com Fri Sep 26 09:15:50 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 26 Sep 2014 09:15:50 -0000 Subject: [Openstack-security] [Bug 1367022] Re: Un-sanitized eval may have security impact References: <20140908225246.18130.67662.malonedeb@chaenomeles.canonical.com> Message-ID: <20140926091551.5461.45481.launchpad@wampee.canonical.com> ** Information type changed from Public Security to Public -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1367022 Title: Un-sanitized eval may have security impact Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: On this line: https://github.com/openstack/ceilometer/blob/master/ceilometer/transformer/conversions.py#L62 eval is used for some transformation. The comments near by suggest that it is used for a 'multiplicative factor or else a string to be eval'd'. If an attacker is able to provide an input like "__import__('os').system('rm -rf /etc')" the process will delete the etc directory with the privileges of the user that is running Ceilometer. Eval input should always be sanitized. I was unable to find any places that this is actually used, but this should definitely be hardened. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1367022/+subscriptions From tim.kelsey at hp.com Fri Sep 26 11:04:10 2014 From: tim.kelsey at hp.com (Kelsey, Timothy John) Date: Fri, 26 Sep 2014 11:04:10 +0000 Subject: [Openstack-security] OSSN-0030 'Shellshock' CVE-2014-6271 input request. Message-ID: Hey folks, So I have just pushed OSSN-0030 up to gerrit, it concerns CVE-2014-6271 aka Shellshock. https://review.openstack.org/#/c/124357/ Review comments and input would be extremely welcome. Thanks all, -- Tim Kelsey Cloud Security Engineer HP Helion From 1334926 at bugs.launchpad.net Fri Sep 26 11:38:52 2014 From: 1334926 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 26 Sep 2014 11:38:52 -0000 Subject: [Openstack-security] [Bug 1334926] Fix proposed to neutron (stable/icehouse) References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140926113852.5566.11232.malone@wampee.canonical.com> Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/124375 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): Fix Committed Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From 1334926 at bugs.launchpad.net Fri Sep 26 11:40:59 2014 From: 1334926 at bugs.launchpad.net (Cedric Brandily) Date: Fri, 26 Sep 2014 11:40:59 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140926114100.32318.7459.launchpad@gac.canonical.com> ** Tags added: icehouse-backport-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): Fix Committed Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From gary.w.smith at hp.com Fri Sep 26 20:41:20 2014 From: gary.w.smith at hp.com (Gary W. Smith) Date: Fri, 26 Sep 2014 20:41:20 -0000 Subject: [Openstack-security] [Bug 1369865] Re: Permanent Cookie Contains Sensitive Session Information References: <20140916062427.24753.72518.malonedeb@soybean.canonical.com> Message-ID: <20140926204124.25240.48320.launchpad@soybean.canonical.com> ** Changed in: horizon Status: New => Confirmed ** Changed in: horizon Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369865 Title: Permanent Cookie Contains Sensitive Session Information Status in OpenStack Dashboard (Horizon): Confirmed Bug description: Affected URL: https://Ip_address/admin/ Entity: csrftoken (Cookie) Risk: It may be possible to steal session information (cookies) that was kept on disk as permanent cookies. Causes: The web application stores sensitive session information in a permanent cookie (on disk) Recommend Fix: Avoid storing sensitive session information in permanent cookies Test requests and response: GET /admin/ HTTP/1.1 Host: 9.5.29.52 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: https://9.5.29.52/ Cookie: csrftoken=JPjBiDp6Ex6YDw3sgfZPCTPUwWKZdZTm; sessionid=oad3bpy15qm8ntml9wx604yr79cc6zpb Connection: keep-alive HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 07:52:50 GMT Server: Apache Vary: Accept-Language,Cookie,Accept-Encoding X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html Set-Cookie: csrftoken=silTP6ARbLvXohF6YYFLlWHce0KZkjPy; expires=Fri, 11-Sep-2015 07:52:52 GMT; Max-Age=31449600; Path=/; secure Set-Cookie: sessionid=ygq094phgr6og471j6n0asq7x6q37j6n; httponly; Path=/; secure 2014/9/12 516 Usage Overview - Cloud Management Dashboard

Cloud Management Dashboard

2014/9/12 517 TOC
Project

Orchestration

... ... ... To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369865/+subscriptions From gary.w.smith at hp.com Fri Sep 26 20:53:10 2014 From: gary.w.smith at hp.com (Gary W. Smith) Date: Fri, 26 Sep 2014 20:53:10 -0000 Subject: [Openstack-security] [Bug 1369870] Re: The cookies for messages, django_timezone, horizon_pagesize, and horizon_language are not marked as "secure" References: <20140916063505.5162.66017.malonedeb@wampee.canonical.com> Message-ID: <20140926205310.5205.92679.malone@wampee.canonical.com> These fields don't contain sensitive information, so why do they need to be marked secure? Can you help explain what is the security risk is here? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369870 Title: The cookies for messages, django_timezone,horizon_pagesize, and horizon_language are not marked as "secure" Status in OpenStack Dashboard (Horizon): New Bug description: Affected URL: https://Ip_address/settings/ Affected Entity: messages, django_timezone, horizon_pagesize, and horizon_language Risk: It may be possible to steal user and session information (cookies) that was sent during an encrypted session Causes: The web application sends non-secure cookies over SSL Recommend Fix: Add the 'Secure' attribute to all sensitive cookies To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369870/+subscriptions From morgan.fainberg at gmail.com Fri Sep 26 23:38:48 2014 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Fri, 26 Sep 2014 23:38:48 -0000 Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs x-subject-token at the debug log level References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com> Message-ID: <20140926233849.32512.93633.launchpad@gac.canonical.com> ** Changed in: python-keystoneclient Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1371355 Title: Keystone client logs x-subject-token at the debug log level Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Keystone: In Progress Bug description: When you invoke any OpenStack API of any of the OpenStack services listed below, then it logs readable x-subject-token as a debug log message in the respective log file. x-subject-token is introduced in v3, so only setups using v3 keystone apis are affected. All OpenStack services using keystone client for authentication and debug log level are affected Service affected are: glance neutron cinder heat ceilometer nova keystone neutron Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log nova-api.log {{{ 2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153 2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’}) }}} I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information. {{{ openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5" HTTP/1.1 200 OK Content-Type: application/json Content-Length: 15 X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d Date: Thu, 18 Sep 2014 22:58:56 GMT {"servers": []} }}} To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1371355/+subscriptions From 1362343 at bugs.launchpad.net Mon Sep 29 03:52:54 2014 From: 1362343 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 29 Sep 2014 03:52:54 -0000 Subject: [Openstack-security] [Bug 1362343] Re: weak digest algorithm for PKI References: <20140827212906.28020.52551.malonedeb@wampee.canonical.com> Message-ID: <20140929035254.18243.67083.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/117371 Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=84c9ccaed34d83b7e97a4890561b1b218d99b1ba Submitter: Jenkins Branch: master commit 84c9ccaed34d83b7e97a4890561b1b218d99b1ba Author: Brant Knudson Date: Wed Aug 27 17:50:19 2014 -0500 Change cms_sign_data to use sha256 message digest cms_sign_data was not passing the md parameter to openssl, so it was using the default digest of sha1. Some security standards require a SHA2 algorithm for the digest. This if for security hardening. SecurityImpact Change-Id: Iff063149e1f12df69bbf9015222d09d798980872 Closes-Bug: #1362343 ** Changed in: python-keystoneclient Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1362343 Title: weak digest algorithm for PKI Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: Fix Committed Bug description: The digest algorithm for PKI tokens is the openssl default of sha1. This is a weak algorithm and some security standards require a stronger algorithm such as sha256. Keystone should make the token digest hash algorithm configurable so that deployments can use a stronger algorithm. Also, the default could be stronger. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1362343/+subscriptions From robert.clark at hp.com Mon Sep 29 12:50:37 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 29 Sep 2014 12:50:37 +0000 Subject: [Openstack-security] Congratulations on reaching 30 Security Notes Message-ID: It’s my pleasure to note in this email that with the issuing of a security note regarding Bash vulnerabilities and how they may affect OpenStack (https://wiki.openstack.org/wiki/OSSN/OSSN-0030) we have reached 30 notes published or in progress – that’s thirty different ways to improve the security of OpenStack deployments where fixes can’t or won’t be applied directly to OpenStack. Thank you to all of you who have been involved in writing, reviewing and publishing OpenStack Security Notes and of course special thanks to Nathan Kinder, who took over the project from myself and Bryan and developed it significantly, adding useful processes and fostering adoption by the community as a whole. The list of OSSNs is here https://wiki.openstack.org/wiki/Security_Notes – thank you to all of you who continue to work on this. -Rob From tom at openstack.org Mon Sep 29 13:22:11 2014 From: tom at openstack.org (Tom Fifield) Date: Mon, 29 Sep 2014 22:22:11 +0900 Subject: [Openstack-security] Congratulations on reaching 30 Security Notes In-Reply-To: References: Message-ID: <54295D03.6030708@openstack.org> On 29/09/14 21:50, Clark, Robert Graham wrote: > It’s my pleasure to note in this email that with the issuing of a security note regarding Bash vulnerabilities and how they may affect OpenStack (https://wiki.openstack.org/wiki/OSSN/OSSN-0030) we have reached 30 notes published or in progress – that’s thirty different ways to improve the security of OpenStack deployments where fixes can’t or won’t be applied directly to OpenStack. > > Thank you to all of you who have been involved in writing, reviewing and publishing OpenStack Security Notes and of course special thanks to Nathan Kinder, who took over the project from myself and Bryan and developed it significantly, adding useful processes and fostering adoption by the community as a whole. > > The list of OSSNs is here https://wiki.openstack.org/wiki/Security_Notes – thank you to all of you who continue to work on this. > > -Rob Indeed - keep up the high quality work all! I have seen several cases of ops folk forward them to their internal mailing lists and use them to manage security activities. Regards, Tom From nkinder at redhat.com Mon Sep 29 15:07:35 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 29 Sep 2014 08:07:35 -0700 Subject: [Openstack-security] Congratulations on reaching 30 Security Notes In-Reply-To: <54295D03.6030708@openstack.org> References: <54295D03.6030708@openstack.org> Message-ID: <542975B7.9020508@redhat.com> On 09/29/2014 06:22 AM, Tom Fifield wrote: > On 29/09/14 21:50, Clark, Robert Graham wrote: >> It’s my pleasure to note in this email that with the issuing of a security note regarding Bash vulnerabilities and how they may affect OpenStack (https://wiki.openstack.org/wiki/OSSN/OSSN-0030) we have reached 30 notes published or in progress – that’s thirty different ways to improve the security of OpenStack deployments where fixes can’t or won’t be applied directly to OpenStack. >> >> Thank you to all of you who have been involved in writing, reviewing and publishing OpenStack Security Notes and of course special thanks to Nathan Kinder, who took over the project from myself and Bryan and developed it significantly, adding useful processes and fostering adoption by the community as a whole. >> >> The list of OSSNs is here https://wiki.openstack.org/wiki/Security_Notes – thank you to all of you who continue to work on this. +100! We've had a great group of people getting involved in the creation of these notes, both on the authoring and reviewing side of things. >> >> -Rob > > Indeed - keep up the high quality work all! I have seen several cases of > ops folk forward them to their internal mailing lists and use them to > manage security activities. That's great feedback to hear. If you hear of any other feedback or suggestions from folks on the ops side, please let us know. Thanks, -NGK > > > Regards, > > > Tom > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > From davanum at gmail.com Mon Sep 29 16:40:35 2014 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Mon, 29 Sep 2014 16:40:35 -0000 Subject: [Openstack-security] [Bug 1328488] Re: oslo apiclient logs sensitive data References: <20140610105701.26336.80011.malonedeb@wampee.canonical.com> Message-ID: <20140929164037.32675.69391.launchpad@gac.canonical.com> ** Changed in: oslo-incubator Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1328488 Title: oslo apiclient logs sensitive data Status in The Oslo library incubator: In Progress Status in OpenStack Security Advisories: Won't Fix Bug description: When trying to clean up the tempest logs in the gate, we leak passwords and keystone tokens everywhere. For instance, python- novaclient logs the auth token. What's more problematic though is that apiclient does the following: def _http_log_req(self, method, url, kwargs): if not self.debug: return string_parts = [ "curl -i", "-X '%s'" % method, "'%s'" % url, ] for element in kwargs['headers']: header = "-H '%s: %s'" % (element, kwargs['headers'][element]) string_parts.append(header) _logger.debug("REQ: %s" % " ".join(string_parts)) if 'data' in kwargs: _logger.debug("REQ BODY: %s\n" % (kwargs['data'])) The argument that it's at DEBUG level doesn't hold, because from the Atlanta operators summit it was clear that *all* operators are running their servers at DEBUG, because OpenStack is impossible to actually troubleshoot at any other logging level. And if you run neutron at debug level, then all your nova credentials are in your logs. This is coupled with the fact that a large amount of users are streaming all their logs directly into logstash. Which means they've now got a potentially public endpoint that lets them search for credentials. We need to stop doing that in a blanket way across OpenStack. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo-incubator/+bug/1328488/+subscriptions From 1341954 at bugs.launchpad.net Mon Sep 29 19:17:18 2014 From: 1341954 at bugs.launchpad.net (Adam Gandelman) Date: Mon, 29 Sep 2014 19:17:18 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140929191718.32545.47776.launchpad@gac.canonical.com> ** Also affects: cinder/icehouse Importance: Undecided Status: New ** Changed in: cinder/icehouse Status: New => Fix Committed ** Changed in: cinder/icehouse Milestone: None => 2014.1.3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Cinder havana series: Fix Released Status in Cinder icehouse series: Fix Committed Status in Gantt: New Status in OpenStack Compute (Nova): Fix Committed Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From 1341954 at bugs.launchpad.net Mon Sep 29 19:35:29 2014 From: 1341954 at bugs.launchpad.net (Adam Gandelman) Date: Mon, 29 Sep 2014 19:35:29 -0000 Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache poisoning by local attacker References: <20140715043528.2209.47100.malonedeb@gac.canonical.com> Message-ID: <20140929193532.32706.12439.launchpad@gac.canonical.com> ** Changed in: cinder/icehouse Assignee: (unassigned) => Vipin Balachandran (vbala) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1341954 Title: suds client subject to cache poisoning by local attacker Status in Cinder: Fix Released Status in Cinder havana series: Fix Released Status in Cinder icehouse series: Fix Committed Status in Gantt: New Status in OpenStack Compute (Nova): Fix Committed Status in Oslo VMware library for OpenStack projects: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. cinder/requirements.txt:suds>=0.4 gantt/requirements.txt:suds>=0.4 nova/requirements.txt:suds>=0.4 oslo.vmware/requirements.txt:suds>=0.4 The details are available here - https://bugzilla.redhat.com/show_bug.cgi?id=978696 (CVE-2013-2217) Although this is an unlikely attack vector steps should be taken to prevent this behaviour. Potential ways to fix this are by explicitly setting the cache location to a directory created via tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or using a custom cache implementation that doesn't load / store pickled objects from an insecure location. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1341954/+subscriptions From gary.w.smith at hp.com Mon Sep 29 20:17:43 2014 From: gary.w.smith at hp.com (Gary W. Smith) Date: Mon, 29 Sep 2014 20:17:43 -0000 Subject: [Openstack-security] [Bug 1369870] Re: The cookies for messages, django_timezone, horizon_pagesize, and horizon_language are not marked as "secure" References: <20140916063505.5162.66017.malonedeb@wampee.canonical.com> Message-ID: <20140929201743.17678.88218.malone@chaenomeles.canonical.com> Good catch, Julie. There are probably some messages that could have sensitive info in them. It appears that as of Django 1.7, this can be made sure via the SESSION_COOKIE_SECURE setting ( https://docs.djangoproject.com/en/dev/ref/settings/#session-cookie- secure) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369870 Title: The cookies for messages, django_timezone,horizon_pagesize, and horizon_language are not marked as "secure" Status in OpenStack Dashboard (Horizon): New Bug description: Affected URL: https://Ip_address/settings/ Affected Entity: messages, django_timezone, horizon_pagesize, and horizon_language Risk: It may be possible to steal user and session information (cookies) that was sent during an encrypted session Causes: The web application sends non-secure cookies over SSL Recommend Fix: Add the 'Secure' attribute to all sensitive cookies To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369870/+subscriptions From 1334926 at bugs.launchpad.net Mon Sep 29 22:11:45 2014 From: 1334926 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 29 Sep 2014 22:11:45 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140929221145.18315.75030.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/124375 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=3a30d19e4e2e5bf4f54045561158661b43beecb3 Submitter: Jenkins Branch: stable/icehouse commit 3a30d19e4e2e5bf4f54045561158661b43beecb3 Author: Cedric Brandily Date: Fri Sep 26 12:00:33 2014 +0200 Deletes floating ip related connection states When a floating ip is dissociated with a port, the current connection with the floating ip is still working. This patch will clear the connection state and cut off the connection immediately. Since conntrack -D will return 1, which is not an error code, so add extra_ok_codes argument to execute methods. Change-Id: Ia9bd7ae243a0859dcb97e2fa939f7d16f9c2456c Closes-Bug: #1334926 (cherry picked from commit 966645538395079b5337b5ed30d597112279283c) ** Tags added: in-stable-icehouse -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): Fix Committed Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From thierry.carrez+lp at gmail.com Tue Sep 30 07:03:57 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Tue, 30 Sep 2014 07:03:57 -0000 Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting a token revokes all tokens with same expiration References: <20140314003341.30362.66976.malonedeb@gac.canonical.com> Message-ID: <20140930070400.18382.51401.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1292283 Title: revocation events: deleting a token revokes all tokens with same expiration Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Identity (Keystone): Fix Released Bug description: As part of the design process for revocation events it was determined that a mechanism to revoke all dependent tokens was needed. This covers the case of revoking a token and ensuring all tokens that were created from that token are also revoked. To accomplish this, the revocation of a specific token is done by expiration_time. The expiration_time attribute is never changed on subsequent tokens. This means it is easy to ensure revocation of an entire chain of tokens. This poses an issue if any specific token (or all tokens that are a child of a specific token) should be revoked, but the parent tokens should not be revoked. Use case: Get Unscoped token Get Scoped Token from Unscoped token Get New Scoped Token Revoke first unscoped token Now all tokens (including the Unscoped token) are revoked because they share an expiration_time. Likely there needs to be a solution that allows for revoking based upon expiration_time and issued_at and one that revokes on expiration_time alone. Revoking by expiration_time alone is API incompatible with previous API mechanisms (both V2 and V3). This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099 was identified. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1292283/+subscriptions From 1334926 at bugs.launchpad.net Tue Sep 30 09:00:11 2014 From: 1334926 at bugs.launchpad.net (Cedric Brandily) Date: Tue, 30 Sep 2014 09:00:11 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140930090013.310.20645.launchpad@gac.canonical.com> ** Tags removed: icehouse-backport-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): Fix Committed Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From 1290537 at bugs.launchpad.net Tue Sep 30 09:39:54 2014 From: 1290537 at bugs.launchpad.net (Alan Pevec) Date: Tue, 30 Sep 2014 09:39:54 -0000 Subject: [Openstack-security] [Bug 1290537] Re: [0SSA 2014-011] RBAC policy not enforced when adding a security group rule using EC2 API (CVE-2014-0167) References: <20140310202059.13934.40594.malonedeb@gac.canonical.com> Message-ID: <20140930093956.32614.22584.launchpad@gac.canonical.com> ** Changed in: nova/havana Importance: Undecided => High ** Changed in: nova/havana Assignee: (unassigned) => Andrew Laski (alaski) ** Tags removed: icehouse-rc-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290537 Title: [0SSA 2014-011] RBAC policy not enforced when adding a security group rule using EC2 API (CVE-2014-0167) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) havana series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons. The Nova API security group implementation does enforce RBAC on these functions. In addition, the add_to_instance and remove_from _instance functions which are wrapped in RBAC verification use the "compute:security_groups" action which is not even listed in the default /etc/nova/policy.json. The latter is confusing to users. This is the case on Grizlly and at first glance, it doesn't look like this has changed in Havana. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1290537/+subscriptions From patriziotufarolo at gmail.com Tue Sep 30 10:25:44 2014 From: patriziotufarolo at gmail.com (Patrizio Tufarolo) Date: Tue, 30 Sep 2014 10:25:44 -0000 Subject: [Openstack-security] [Bug 1372375] Re: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: <20140930102544.32185.78483.malone@gac.canonical.com> A simpler approach could consist in a flag stored in the cinder db to indicate if the volume has been formatted before. Then we could handle the volume attachment procedure checking this flag's value first. If the device has been used but Nova would not be able to mount it, we could return an exception inviting the cloud administrator to check for the volume integrity. What do you think about that? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372375 Title: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted Status in Cinder: New Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: I have doubts about the flow of the volume attaching operation, as defined in /usr/lib/python2.6/site- packages/nova/volume/encryptors/luks.py. If the device is not recognized to be a valid luks device, the script is luks formatting it! So if for some reason the luks header get corrupted, it erases the whole data. To manage corrupted headers there are the cryptsetup luksHeaderBackup and cryptsetup luksHeaderRestore commands that respectively do the backup and the restore of the headers. I think that the process has to be reviewed, and the luksFormat operation has to be performed during the volume creation. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1372375/+subscriptions From 1371355 at bugs.launchpad.net Tue Sep 30 13:53:41 2014 From: 1371355 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 30 Sep 2014 13:53:41 -0000 Subject: [Openstack-security] [Bug 1371355] Re: Keystone client logs x-subject-token at the debug log level References: <20140919000453.18243.72646.malonedeb@chaenomeles.canonical.com> Message-ID: <20140930135341.32545.1071.malone@gac.canonical.com> Reviewed: https://review.openstack.org/123954 Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=ebeca911fa291e258c2c0b1ef55a26ff5ac009d2 Submitter: Jenkins Branch: master commit ebeca911fa291e258c2c0b1ef55a26ff5ac009d2 Author: ankitagrawal Date: Fri Sep 19 04:46:11 2014 -0700 Redact x-subject-token from response headers When you invoke any OpenStack API of any of the OpenStack services e.g. glance, neutron, cinder, heat, ceilometer, nova, keystone then it logs readable x-subject-token at the debug log level in the respective log files. Simply redacting the x-subject-token in keystone client response header before logging it. SecurityImpact Closes-Bug: #1371355 Change-Id: Iac16c6358250677544761beea9f5c5d8ba29afac ** Changed in: python-keystoneclient Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1371355 Title: Keystone client logs x-subject-token at the debug log level Status in OpenStack Security Advisories: Won't Fix Status in Python client library for Keystone: Fix Committed Bug description: When you invoke any OpenStack API of any of the OpenStack services listed below, then it logs readable x-subject-token as a debug log message in the respective log file. x-subject-token is introduced in v3, so only setups using v3 keystone apis are affected. All OpenStack services using keystone client for authentication and debug log level are affected Service affected are: glance neutron cinder heat ceilometer nova keystone neutron Example, I tried to list servers from nova using "nova list” command, then it records following log message in the nova-api.log nova-api.log {{{ 2014-09-18 15:48:14.491 20940 DEBUG keystoneclient.session [-] REQ: curl -i -X GET http://10.69.4.172:35357/v3/auth/tokens -H "X-Subject-Token: TOKEN_REDACTED" -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: TOKEN_REDACTED" _http_log_request /opt/stack/python-keystoneclient/keystoneclient/session.py:153 2014-09-18 15:48:14.533 20940 DEBUG keystoneclient.session [-] RESP: [200] CaseInsensitiveDict({'content-length': '7113', 'x-subject-token': '7574276dc55f45878f18e14396dcf7f5', 'vary': 'X-Auth-Token', 'server': 'Apache/2.4.7 (Ubuntu)', 'date': 'Thu, 18 Sep 2014 22:48:14 GMT', 'content-type': 'application/json’}) }}} I can then simply use x-subject-token': ‘7574276dc55f45878f18e14396dcf7f5 as X-auth-token in the curl command and access tenant’s information. {{{ openstack at ubuntu:~$ curl -i 'http://10.69.4.172:8774/v2/d8a8252b035b4c18bee9215292485f78/servers/detail' -X GET -H "Accept: application/json" -H "X-Auth-Project-Id: demo" -H "X-Auth-Token: 7574276dc55f45878f18e14396dcf7f5" HTTP/1.1 200 OK Content-Type: application/json Content-Length: 15 X-Compute-Request-Id: req-20ad9134-0c61-46de-91a1-da89283a057d Date: Thu, 18 Sep 2014 22:58:56 GMT {"servers": []} }}} To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1371355/+subscriptions From gerrit2 at review.openstack.org Tue Sep 30 14:43:49 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 30 Sep 2014 14:43:49 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I0b8e6319a4cc39876b1e396ef705f0fc5def1e44 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/124714 Log: commit 30871e8702737edbbfbcbbb5f21858873b37685c Author: Sylvain Bauza Date: Mon Sep 29 13:33:50 2014 +0200 Fix unsafe SSL connection on TrustedFilter TrustedFilter was using httplib which doesn't check for CAs. Here the change is using Requests and verifies local CAs by default (or another one if provided) This effort is related to CVE 2013-2255. SecurityImpact Closes-Bug: #1373993 Change-Id: I0b8e6319a4cc39876b1e396ef705f0fc5def1e44 From 1334926 at bugs.launchpad.net Tue Sep 30 17:38:15 2014 From: 1334926 at bugs.launchpad.net (Adam Gandelman) Date: Tue, 30 Sep 2014 17:38:15 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140930173815.17873.81762.launchpad@chaenomeles.canonical.com> ** Also affects: neutron/icehouse Importance: Undecided Status: New ** Changed in: neutron/icehouse Milestone: None => 2014.1.3 ** Changed in: neutron/icehouse Assignee: (unassigned) => Cedric Brandily (cbrandily) ** Changed in: neutron/icehouse Status: New => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): Fix Committed Status in neutron icehouse series: Fix Committed Status in OpenStack Security Notes: Fix Released Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From zhangyun at cn.ibm.com Wed Sep 24 02:20:04 2014 From: zhangyun at cn.ibm.com (Zhang Yun) Date: Wed, 24 Sep 2014 02:20:04 -0000 Subject: [Openstack-security] [Bug 1369870] Re: The cookies for messages, django_timezone, horizon_pagesize, and horizon_language are not marked as "secure" References: <20140916063505.5162.66017.malonedeb@wampee.canonical.com> Message-ID: <20140924022005.32267.89339.malone@gac.canonical.com> Hi Doug, I modified the title and removed the sample response according to your comments. Would you please take some time to re-investigate it? Thanks. ** Changed in: horizon Status: Incomplete => New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369870 Title: The cookies for messages, django_timezone,horizon_pagesize, and horizon_language are not marked as "secure" Status in OpenStack Dashboard (Horizon): New Bug description: Affected URL: https://Ip_address/settings/ Affected Entity: messages, django_timezone, horizon_pagesize, and horizon_language Risk: It may be possible to steal user and session information (cookies) that was sent during an encrypted session Causes: The web application sends non-secure cookies over SSL Recommend Fix: Add the 'Secure' attribute to all sensitive cookies To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369870/+subscriptions From 1372375 at bugs.launchpad.net Thu Sep 25 15:00:24 2014 From: 1372375 at bugs.launchpad.net (Joel Coffman) Date: Thu, 25 Sep 2014 15:00:24 -0000 Subject: [Openstack-security] [Bug 1372375] Re: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: <20140925150024.25387.29145.malone@soybean.canonical.com> The question here is really what should happen if the LUKS header become corrupted for some reason. Implicit to that question is the assumption that the header could be corrupted without also impacting the integrity of the data stored in the volume. While it's probably possible, my inclination is that corrupting the header would also likely corrupt other portions of the volume in which case the user would probably want to restore the volume from a backup. (See patch to support backups of encrypted volumes: https://review.openstack.org/#/c/74532/) Regarding the use of luksHeaderBackup and luksHeaderRestore, where do you propose storing the backup header file? Would a backup of the whole volume (see above) be sufficient in your opinion, or is there a specific need to backup only the header? Finally, the decision to format the device in Nova instead of Cinder was intentional: because Cinder never has access to the encryption key (it merely requests the creation of an encryption key), only the compute host must be trusted. That is, the current flow limits trust among the various services in OpenStack. (I do not argue that flow could be different, but there are security trade-offs that should be considered with such a change.) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372375 Title: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted Status in Cinder: New Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: I have doubts about the flow of the volume attaching operation, as defined in /usr/lib/python2.6/site- packages/nova/volume/encryptors/luks.py. If the device is not recognized to be a valid luks device, the script is luks formatting it! So if for some reason the luks header get corrupted, it erases the whole data. To manage corrupted headers there are the cryptsetup luksHeaderBackup and cryptsetup luksHeaderRestore commands that respectively do the backup and the restore of the headers. I think that the process has to be reviewed, and the luksFormat operation has to be performed during the volume creation. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1372375/+subscriptions From zhangyun at cn.ibm.com Mon Sep 29 02:43:31 2014 From: zhangyun at cn.ibm.com (Zhang Yun) Date: Mon, 29 Sep 2014 02:43:31 -0000 Subject: [Openstack-security] [Bug 1369870] Re: The cookies for messages, django_timezone, horizon_pagesize, and horizon_language are not marked as "secure" References: <20140916063505.5162.66017.malonedeb@wampee.canonical.com> Message-ID: <20140929024331.18315.23195.malone@chaenomeles.canonical.com> Ok, if no sensitive information here, please close this bug, thanks. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369870 Title: The cookies for messages, django_timezone,horizon_pagesize, and horizon_language are not marked as "secure" Status in OpenStack Dashboard (Horizon): New Bug description: Affected URL: https://Ip_address/settings/ Affected Entity: messages, django_timezone, horizon_pagesize, and horizon_language Risk: It may be possible to steal user and session information (cookies) that was sent during an encrypted session Causes: The web application sends non-secure cookies over SSL Recommend Fix: Add the 'Secure' attribute to all sensitive cookies To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369870/+subscriptions From 1369870 at bugs.launchpad.net Mon Sep 29 07:54:32 2014 From: 1369870 at bugs.launchpad.net (Julie Pichon) Date: Mon, 29 Sep 2014 07:54:32 -0000 Subject: [Openstack-security] [Bug 1369870] Re: The cookies for messages, django_timezone, horizon_pagesize, and horizon_language are not marked as "secure" References: <20140916063505.5162.66017.malonedeb@wampee.canonical.com> Message-ID: <20140929075432.5331.11129.malone@wampee.canonical.com> It may be worth considering for the "messages" cookie? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369870 Title: The cookies for messages, django_timezone,horizon_pagesize, and horizon_language are not marked as "secure" Status in OpenStack Dashboard (Horizon): New Bug description: Affected URL: https://Ip_address/settings/ Affected Entity: messages, django_timezone, horizon_pagesize, and horizon_language Risk: It may be possible to steal user and session information (cookies) that was sent during an encrypted session Causes: The web application sends non-secure cookies over SSL Recommend Fix: Add the 'Secure' attribute to all sensitive cookies To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369870/+subscriptions From 1372375 at bugs.launchpad.net Mon Sep 29 16:47:21 2014 From: 1372375 at bugs.launchpad.net (Joel Coffman) Date: Mon, 29 Sep 2014 16:47:21 -0000 Subject: [Openstack-security] [Bug 1372375] Re: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: <20140929164721.508.55914.malone@gac.canonical.com> > [...] I think that Cinder should ask luksFormat to nova at the moment of volume creation [...] I agree that approach would be cleaner, but it also forces Cinder to delegate a significant amount of work to Nova -- it's basically comparable to attaching a volume to a VM. I'm also not really sure that (encrypted) volume creation should couple Cinder to Nova. It would certainly be a significant change from the creation of non-encrypted volumes. While it's not optimal, the existing approach is simple -- much simpler than the alternatives in my opinion. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372375 Title: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted Status in Cinder: New Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: I have doubts about the flow of the volume attaching operation, as defined in /usr/lib/python2.6/site- packages/nova/volume/encryptors/luks.py. If the device is not recognized to be a valid luks device, the script is luks formatting it! So if for some reason the luks header get corrupted, it erases the whole data. To manage corrupted headers there are the cryptsetup luksHeaderBackup and cryptsetup luksHeaderRestore commands that respectively do the backup and the restore of the headers. I think that the process has to be reviewed, and the luksFormat operation has to be performed during the volume creation. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1372375/+subscriptions From 1372375 at bugs.launchpad.net Tue Sep 30 17:02:40 2014 From: 1372375 at bugs.launchpad.net (Joel Coffman) Date: Tue, 30 Sep 2014 17:02:40 -0000 Subject: [Openstack-security] [Bug 1372375] Re: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: <20140930170240.32185.56479.malone@gac.canonical.com> That approach seems good in my opinion -- no real downsides apart from the additional metadata. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372375 Title: Attaching LVM encrypted volumes (with LUKS) could cause data loss if LUKS headers get corrupted Status in Cinder: New Status in OpenStack Compute (Nova): Incomplete Status in OpenStack Security Advisories: Won't Fix Bug description: I have doubts about the flow of the volume attaching operation, as defined in /usr/lib/python2.6/site- packages/nova/volume/encryptors/luks.py. If the device is not recognized to be a valid luks device, the script is luks formatting it! So if for some reason the luks header get corrupted, it erases the whole data. To manage corrupted headers there are the cryptsetup luksHeaderBackup and cryptsetup luksHeaderRestore commands that respectively do the backup and the restore of the headers. I think that the process has to be reviewed, and the luksFormat operation has to be performed during the volume creation. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1372375/+subscriptions