From pawel.koniszewski at intel.com Wed Apr 1 11:59:11 2015 From: pawel.koniszewski at intel.com (Pawel Koniszewski) Date: Wed, 01 Apr 2015 11:59:11 -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: <20150401115911.7787.14691.malone@chaenomeles.canonical.com> Eli, do you have idea how to fix this issue? I believe that it should be fixed in libvirt (don't chown if gluster detected): https://bugzilla.redhat.com/show_bug.cgi?id=1057645 https://bugzilla.redhat.com/show_bug.cgi?id=1004673 https://bugzilla.redhat.com/show_bug.cgi?id=714997 ** Bug watch added: Red Hat Bugzilla #1004673 https://bugzilla.redhat.com/show_bug.cgi?id=1004673 ** Bug watch added: Red Hat Bugzilla #714997 https://bugzilla.redhat.com/show_bug.cgi?id=714997 -- 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 1409142 at bugs.launchpad.net Wed Apr 1 13:45:41 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 01 Apr 2015 13:45:41 -0000 Subject: [Openstack-security] [Bug 1409142] Related fix proposed to nova (master) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150401134541.23574.45683.malone@wampee.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/169752 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1409142 at bugs.launchpad.net Wed Apr 1 13:45:48 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 01 Apr 2015 13:45:48 -0000 Subject: [Openstack-security] [Bug 1409142] Fix proposed to nova (master) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150401134549.7711.47520.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/169753 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From sean at dague.net Wed Apr 1 14:19:24 2015 From: sean at dague.net (Sean Dague) Date: Wed, 01 Apr 2015 14:19:24 -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: <20150401141927.26046.89680.launchpad@gac.canonical.com> ** Changed in: nova Status: Incomplete => 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/1368040 Title: random.choice in /cinder/volume/utils.py may has potential security issue Status in Cinder: Invalid Status in OpenStack Compute (Nova): Opinion 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 sean at dague.net Wed Apr 1 15:14:38 2015 From: sean at dague.net (Sean Dague) Date: Wed, 01 Apr 2015 15:14:38 -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: <20150401151438.23033.31428.malone@wampee.canonical.com> This seems like this really should be handled in cinder scope, marking nova invalid for now. Please flag back to new if we feel it should be in the fix. ** Changed in: nova Status: Incomplete => Invalid -- 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): Invalid 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 Wed Apr 1 16:40:25 2015 From: 1372375 at bugs.launchpad.net (John Griffith) Date: Wed, 01 Apr 2015 16:40:25 -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: <20150401164026.25980.5229.malone@gac.canonical.com> @Patrizio/Joel Couple questions, like how would we like to see the info passed to Cinder to indicate that the Volume has been formatted to set the proposed flag? This is part of the reason why this was all handled on the Nova side to begin with, that's where the encryption *stuff* happens for the most part, and given we don't currently have any mechanism for Nova sending updates back to Cinder there's a good deal of plumbing needed here I think. Also, is anybody interested enough to work 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/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): Invalid 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 patriziotufarolo at gmail.com Wed Apr 1 16:58:54 2015 From: patriziotufarolo at gmail.com (Patrizio Tufarolo) Date: Wed, 01 Apr 2015 16:58:54 -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: <20150401165854.7181.83952.malone@chaenomeles.canonical.com> I don't know if someone could be interested. As of now, I think we can leave the encryption layer in nova but I would at least change the workflow of the volume encryption operation. It is crazy to luks format a volume because I am not able to mount it, and it is crazy to suppose that if I am not able to mount a volume, then it's the first time I am mounting 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/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): Invalid 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 1427228 at bugs.launchpad.net Thu Apr 2 11:39:31 2015 From: 1427228 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 02 Apr 2015 11:39:31 -0000 Subject: [Openstack-security] [Bug 1427228] Fix merged to neutron (master) References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150402113931.23327.86217.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/161494 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fbc22784149cd6b3ca6d8161e360d3d7c10d94ac Submitter: Jenkins Branch: master commit fbc22784149cd6b3ca6d8161e360d3d7c10d94ac Author: Cedric Brandily Date: Tue Mar 3 22:26:52 2015 +0000 Allow metadata proxy to log with nobody user/group Currently metadata proxy cannot run with nobody user/group as metadata proxy (as other services) uses WatchedFileHandler handler to log to file which does not support permissions drop (the process must be able to r/w after permissions drop to "watch" the file). This change allows to enable/disable log watch in metadata proxies with the new option metadata_proxy_log_watch. It should be disabled when metadata_proxy_user/group is not allowed to read/write metadata proxy log files. Option default value is deduced from metadata_proxy_user: * True if metadata_proxy_user is agent effective user id/name, * False otherwise. When log watch is disabled and logrotate is enabled on metadata proxy logging files, 'copytruncate' logrotate option must be used otherwise metadata proxy logs will be lost after the first log rotation. DocImpact Change-Id: I40a7bd82a2c60d9198312fdb52e3010c60db3511 Partial-Bug: #1427228 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): In Progress Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 2 13:27:02 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 02 Apr 2015 13:27:02 -0000 Subject: [Openstack-security] [Bug 1435530] Re: keystonemiddleware without TRL checking and default cache config can allow access after token revocation References: <20150323201925.7521.48815.malonedeb@chaenomeles.canonical.com> Message-ID: <20150402132702.25776.95720.malone@gac.canonical.com> OK, it's public now. ** Information type changed from Private 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/1435530 Title: keystonemiddleware without TRL checking and default cache config can allow access after token revocation Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: *** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call *** Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user). Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used. This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions From gerrit2 at review.openstack.org Thu Apr 2 15:58:57 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 02 Apr 2015 15:58:57 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ie8d653eed2fea244be6fa535ed6fd003ea15c2bb Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/164813 Log: commit 15a2abca42c5d2c27370054dfa0a81fc080695a2 Author: David Hu Date: Mon Mar 16 10:44:09 2015 -0700 Nova admin role Current “admin” role in Nova and other services are pretty static. A user with “admin” role has the super admin privilege not only in Nova, but other services as well. In most organizations, compute administrators and administrators from other services are from distinct group of administrator. If an organization does not allow Nova administrators to make changes to say Cinder or Neutron, then Nova administrators should only have a “Nova specific admin role”, and not the super ”admin” role. Enhance Nova policy to include Nova admin role, so that administrators with Nova admin role can perform Nova administrative tasks without having to take on the super "admin" role. SecurityImpact Change-Id: Ie8d653eed2fea244be6fa535ed6fd003ea15c2bb From morgan.fainberg at gmail.com Thu Apr 2 17:55:50 2015 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Thu, 02 Apr 2015 17:55:50 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate (and overly broad?) events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20150402175551.7457.69370.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Milestone: kilo-rc1 => liberty-1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in OpenStack Identity (Keystone): Triaged Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From gerrit2 at review.openstack.org Thu Apr 2 21:10:24 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 02 Apr 2015 21:10:24 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I577d4435d551181298b23e713ed84f76d9f1ba3e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/166934 Log: commit 2e859e17f97d78a4146e6bf4e7711bb1806c5ab1 Author: Brant Knudson Date: Mon Mar 23 12:26:50 2015 -0500 Fix for notifications for v2 role grant/delete Notifications were not being sent when role grants were added or deleted using the v2 API. SecurityImpact Change-Id: I577d4435d551181298b23e713ed84f76d9f1ba3e Closes-Bug: #1435396 From edmondsw at us.ibm.com Fri Apr 3 22:21:57 2015 From: edmondsw at us.ibm.com (Matthew Edmonds) Date: Fri, 03 Apr 2015 22:21:57 -0000 Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed, lun-id couldn't be rollback in havana References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <20150403222157.26333.62488.malone@gac.canonical.com> per http://seclists.org/oss-sec/2015/q1/990: For purposes of CVE, we typically don't think of vulnerabilities in the way expressed in https://bugs.launchpad.net/nova/+bug/1419577/comments/4 "without a way to make the migration process fail, this is a bug with security consequence, but not a vulnerability." In other words, for a CVE, the attacker can be a person who wishes to have an unauthorized volume attachment after the bug is triggered. The attacker does not need to be a person who has determined a reproducible way to trigger the bug. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1419577 Title: when live-migrate failed, lun-id couldn't be rollback in havana Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: Hi, guys When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback. and failed VM can have others volume. my test environment is following : Openstack Version : Havana ( 2013.2.3) Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 1 cinder volume (vol01) 4) attach 1 volume to vm01 (/dev/vdb) 5) live-migrate vm01 from host#1 to host#2 6) live-migrate success      - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.        and the status of devices is "failed faulty"      - please check the lun-id of vol01 7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4) 8) live-migrate fail      - please check the mapper in host#1      - please check the lun-id of vol01, then you can find the lun hav "two" igroups      - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback This Bug is critical security issue because the failed VM can have others volume. and every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. I suggest below methods to solve issue : 1) when live-migrate is complete, nova should delete mapper devices at origin host 2) when live-migrate is failed, nova should rollback lun-id in connection_info column 3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...) 4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping please check this bug. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions From fungi at yuggoth.org Fri Apr 3 22:36:46 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 03 Apr 2015 22:36:46 -0000 Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed, lun-id couldn't be rollback in havana References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com> Message-ID: <20150403223647.7810.81806.malone@soybean.canonical.com> And as I indicated in follow-up replies on that thread, the OpenStack VMT doesn't decide whether or not a bug is worthy of getting a CVE assigned (only whether or not we're going to embargo it and/or eventually issue a security advisory about it). ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2015-2687 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1419577 Title: when live-migrate failed, lun-id couldn't be rollback in havana Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: Hi, guys When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback. and failed VM can have others volume. my test environment is following : Openstack Version : Havana ( 2013.2.3) Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2 test step is : 1) create 2 Compute node (host#1 and host#2) 2) create 1 VM on host#1 (vm01) 3) create 1 cinder volume (vol01) 4) attach 1 volume to vm01 (/dev/vdb) 5) live-migrate vm01 from host#1 to host#2 6) live-migrate success      - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.        and the status of devices is "failed faulty"      - please check the lun-id of vol01 7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4) 8) live-migrate fail      - please check the mapper in host#1      - please check the lun-id of vol01, then you can find the lun hav "two" igroups      - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback This Bug is critical security issue because the failed VM can have others volume. and every backend storage of cinder-volume can have same problem because this is the bug of live-migration's rollback process. I suggest below methods to solve issue : 1) when live-migrate is complete, nova should delete mapper devices at origin host 2) when live-migrate is failed, nova should rollback lun-id in connection_info column 3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...) 4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping please check this bug. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1419577/+subscriptions From morgan.fainberg at gmail.com Sat Apr 4 00:27:26 2015 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Sat, 04 Apr 2015 00:27:26 -0000 Subject: [Openstack-security] [Bug 1379077] Re: Tenants can be created with invalid ids References: <20141009004653.32578.45865.malonedeb@gac.canonical.com> Message-ID: <20150404002727.7521.41311.launchpad@chaenomeles.canonical.com> ** Changed in: keystone/icehouse Importance: Undecided => Medium ** Changed in: keystone/juno 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/1379077 Title: Tenants can be created with invalid ids Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: In Progress Status in Keystone juno series: Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: When creating a new tenant, there is an optional argument 'id' that may be passed: https://github.com/openstack/keystone/blob/9025b64a8f2bf5cf01a18453d6728e081bd2c3b9/keystone/assignment/controllers.py#L114 If not passed, this just creates a uuid and proceeds. If a value is passed, it will use that value. So a user with priv's to create a tenant can pass something like "../../../../../" as the id. If this is done, then the project can't be deleted without manually removing the value from the database. This can lead to a DoS that could fill the db and take down the cloud, in the worst of circumstances. I believe the proper fix here would be to just remove this feature altogether. But this is because I'm not clear about why we would ever want to allow someone to set the id manually. If there's a valid use case here, then we should at least do some input validation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1379077/+subscriptions From 1372375 at bugs.launchpad.net Mon Apr 6 14:45:50 2015 From: 1372375 at bugs.launchpad.net (Joel Coffman) Date: Mon, 06 Apr 2015 14:45:50 -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: <20150406144550.25645.75961.malone@gac.canonical.com> > [...] how would we like to see the info passed to Cinder to indicate that the Volume has been formatted to set the proposed flag? Perhaps something could be added to the VolumeEncryptionMetadata API extension to support toggling the flag when the volume is formatted. Not sure how much would be gained from this approval since it potentially would create a way to (maliciously) trigger reformatting the volume -- maybe it would be write-once so it can only be set (i.e., formatted = True). > It is crazy to luks format a volume because I am not able to mount it, and it is crazy to suppose that if I am not able to mount a volume, then it's the first time I am mounting it. You could use the cryptsetup encryptor instead of LUKS, as raw cryptsetup does not format the volume at all. > Also, is anybody interested enough to work on this? I'm willing to look into this issue since I'm responsible for the original feature, but it's pretty much at the bottom of my priority list. I also stand by my original comment on this bug report. We're talking about a situation where 1) the LUKS header is corrupted, 2) the (encrypted) volume "data" is not corrupted, and 3) the user doesn't have backups or snapshots of the volume. Perhaps someone from the Cinder core team will correct me, but I'd guess that Cinder's backends try to avoid data corruption, but it remains the user's responsibility to have snapshots or backups of the volume in case corruption occurs. If so, we're talking about a very specific situation where changing the existing behavior would be beneficial. -- 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): Invalid 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 1427228 at bugs.launchpad.net Mon Apr 6 21:12:41 2015 From: 1427228 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 06 Apr 2015 21:12:41 -0000 Subject: [Openstack-security] [Bug 1427228] Re: Allow to run neutron-ns-metadata-proxy as nobody References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150406211241.26299.53303.malone@gac.canonical.com> Reviewed: https://review.openstack.org/165115 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=80bea7a38670620934faafd5f583fe6164b9f9b3 Submitter: Jenkins Branch: master commit 80bea7a38670620934faafd5f583fe6164b9f9b3 Author: Cedric Brandily Date: Tue Mar 17 15:20:07 2015 +0000 Allow metadata proxy running with nobody user/group Currently metadata proxy cannot run with nobody user/group as metadata proxy requires to connect to metadata_proxy_socket when queried. This change allows to run metadata proxy with nobody user/group by allowing to choose the metadata_proxy_socket mode with the new option metadata_proxy_socket_mode (4 choices) in order to adapt socket permissions to metadata proxy user/group. This change refactors also where options are defined to enable metadata_proxy_user/group options in the metadata agent. In practice: * if metadata_proxy_user is agent effective user or root, then: * metadata proxy is allowed to use rootwrap (unsecure) * set metadata_proxy_socket_mode = user (0o644) * else if metadata_proxy_group is agent effective group, then: * metadata proxy is not allowed to use rootwrap (secure) * set metadata_proxy_socket_mode = group (0o664) * set metadata_proxy_log_watch = false * else: * metadata proxy has lowest permissions (securest) but metadata proxy socket can be opened by everyone * set metadata_proxy_socket_mode = all (0o666) * set metadata_proxy_log_watch = false An alternative is to set metadata_proxy_socket_mode = deduce, in such case metadata agent uses previous rules to choose the correct mode. DocImpact Closes-Bug: #1427228 Change-Id: I235a0cc4f0cbd55ae4ec1570daf2ebbb6a72441d ** 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/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): Fix Committed Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From morgan.fainberg at gmail.com Mon Apr 6 22:32:19 2015 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Mon, 06 Apr 2015 22:32:19 -0000 Subject: [Openstack-security] [Bug 1381365] Re: SSL Version and cipher selection not possible References: <20141015072233.17942.25827.malonedeb@chaenomeles.canonical.com> Message-ID: <20150406223223.7030.88390.launchpad@chaenomeles.canonical.com> ** Changed in: keystone 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/1381365 Title: SSL Version and cipher selection not possible Status in Cinder: New Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Identity (Keystone): Won't Fix Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Advisories: Won't Fix Bug description: We configure keystone to use SSL always. Due to the poodle issue, I was trying to configure keystone to disable SSLv3 completely. http://googleonlinesecurity.blogspot.fi/2014/10/this-poodle-bites-exploiting-ssl-30.html https://www.openssl.org/~bodo/ssl-poodle.pdf It seems that keystone has no support for configring SSL versions, nor ciphers. If I'm not mistaken the relevant code is in the start function in common/environment/eventlet_server.py It calls eventlet.wrap_ssl but with no SSL version nor cipher options. Since the interface is identical, I assume it uses ssl.wrap_socket. The default here seems to be PROTOCOL_SSLv23 (SSL2 disabled), which would make this vulnerable to the poodle issue. SSL conifgs should probably be possible to be set in the config file (with sane defaults), so that current and newly detected weak ciphers can be disabled without code changes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1381365/+subscriptions From 1274034 at bugs.launchpad.net Mon Apr 6 23:21:17 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 06 Apr 2015 23:21:17 -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: <20150406232117.7457.57418.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/171003 ** Changed in: neutron Assignee: Juergen Brendel (jbrendel) => Kevin Benton (kevinbenton) -- 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 slukjanov at mirantis.com Tue Apr 7 06:57:37 2015 From: slukjanov at mirantis.com (Sergey Lukjanov) Date: Tue, 07 Apr 2015 06:57:37 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150407065742.7647.17533.launchpad@soybean.canonical.com> ** Changed in: sahara Milestone: kilo-rc1 => liberty-1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): In Progress Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From bdobrelia at mirantis.com Tue Apr 7 07:35:55 2015 From: bdobrelia at mirantis.com (Bogdan Dobrelya) Date: Tue, 07 Apr 2015 07:35:55 -0000 Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com> Message-ID: <20150407073557.7387.1981.launchpad@soybean.canonical.com> ** Changed in: fuel Milestone: 6.1 => 7.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/1355509 Title: Better conductor deployment Status in Fuel: OpenStack installer that works: Triaged Status in Fuel for OpenStack 6.0.x series: Won't Fix Bug description: Here is several issues with how MOS deploys conductor. 1 By default all deployment variants assume deployments with conductor enabled. But this requires to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor. One of the reason for creating conductor service was to provide security level for nova. 2 by default it not possible to disable conductor using MOS tools. Customers who prefer performance over security should have this options. Conductor can introduce significant delay in all actions required database access. This two enchantments are tied together. The following actions are required to disable usage of conductor. On all compute nodes: 1 make use mysql port is accessible from compute nodes and all necessary grange are present. 2 add into nova.conf [DEFAULT] sql_connection = mysql://nova:password at mysqlhost/nova_db [conductor] use_local=true 3 service openstack-nova-compute restart 4 optionally stop conductor process on controllers Monitoring tuning may be required.. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1355509/+subscriptions From 1274034 at bugs.launchpad.net Tue Apr 7 13:59:09 2015 From: 1274034 at bugs.launchpad.net (Kyle Mestery) Date: Tue, 07 Apr 2015 13:59:09 -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: <20150407135909.26127.73797.malone@gac.canonical.com> Kevin has a fix we should seriously look at for Kilo. ** Changed in: neutron Milestone: liberty-1 => kilo-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/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 morgan.fainberg at gmail.com Tue Apr 7 15:00:32 2015 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Tue, 07 Apr 2015 15:00:32 -0000 Subject: [Openstack-security] [Bug 1435530] Re: keystonemiddleware without TRL checking and default cache config can allow access after token revocation References: <20150323201925.7521.48815.malonedeb@chaenomeles.canonical.com> Message-ID: <20150407150032.26046.46161.malone@gac.canonical.com> This is a case where an OSSN and eliminating awful defaults will make behavior less bad. The fact that a similar issue in the past did not have an OSSN was the main reason this was raised as it was. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1435530 Title: keystonemiddleware without TRL checking and default cache config can allow access after token revocation Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: *** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call *** Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user). Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used. This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions From morgan.fainberg at gmail.com Tue Apr 7 15:06:19 2015 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Tue, 07 Apr 2015 15:06:19 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150407150620.25645.66333.malone@gac.canonical.com> Eventlet is deprecated for keystone and not the primary deployment method. For many reasons it is recommended that keystone not be deployed under event let ** Changed in: keystone Status: In Progress => 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/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Won't Fix Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From 1430951 at bugs.launchpad.net Tue Apr 7 17:24:31 2015 From: 1430951 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 07 Apr 2015 17:24:31 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate (and overly broad?) events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20150407172431.23688.91111.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/171305 ** Changed in: keystone Status: Triaged => In Progress ** Changed in: keystone Assignee: Adam Young (ayoung) => Alexander Makarov (amakarov) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in OpenStack Identity (Keystone): In Progress Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From 1260525 at bugs.launchpad.net Wed Apr 1 00:21:23 2015 From: 1260525 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 01 Apr 2015 00:21:23 -0000 Subject: [Openstack-security] [Bug 1260525] Re: Incomplete XSS fix for ossa/1247675 References: <20131212225614.8529.85762.malonedeb@gac.canonical.com> Message-ID: <20150401002123.25704.80357.malone@gac.canonical.com> Reviewed: https://review.openstack.org/169462 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=2ad1e1935a325cc5345fb4b08ca7ecdf3a8dadf7 Submitter: Jenkins Branch: master commit 2ad1e1935a325cc5345fb4b08ca7ecdf3a8dadf7 Author: Paul McMillan Date: Tue Mar 31 20:07:26 2015 +0100 Fix unlikely XSS in attachment rendering This isn't likely to get hit in production, but it's generally a good cleanup. Change-Id: I9f92098046038bf1ab2afdd17c845ef44f89af3b Closes-Bug: 1260525 ** Changed in: horizon 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/1260525 Title: Incomplete XSS fix for ossa/1247675 Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Security Advisories: Invalid Bug description: The patch for https://bugs.launchpad.net/ossa/+bug/1247675 did not completely fix the reported issue. It failed to completely remove the use of html.strip_tags, which is not intended to be a security function, and does not properly sanitize output. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/tables.py#L254 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1260525/+subscriptions From 1260525 at bugs.launchpad.net Wed Apr 1 00:24:10 2015 From: 1260525 at bugs.launchpad.net (Lin Hua Cheng) Date: Wed, 01 Apr 2015 00:24:10 -0000 Subject: [Openstack-security] [Bug 1260525] Re: Incomplete XSS fix for ossa/1247675 References: <20131212225614.8529.85762.malonedeb@gac.canonical.com> Message-ID: <20150401002412.22908.39997.launchpad@wampee.canonical.com> ** Changed in: horizon Milestone: None => kilo-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/1260525 Title: Incomplete XSS fix for ossa/1247675 Status in OpenStack Dashboard (Horizon): Fix Committed Status in OpenStack Security Advisories: Invalid Bug description: The patch for https://bugs.launchpad.net/ossa/+bug/1247675 did not completely fix the reported issue. It failed to completely remove the use of html.strip_tags, which is not intended to be a security function, and does not properly sanitize output. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/tables.py#L254 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1260525/+subscriptions From liyong.qiao at intel.com Wed Apr 1 08:31:13 2015 From: liyong.qiao at intel.com (Eli Qiao) Date: Wed, 01 Apr 2015 08:31:13 -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: <20150401083115.26333.75593.launchpad@gac.canonical.com> ** Changed in: nova Assignee: (unassigned) => Eli Qiao (taget-9) -- 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 liyong.qiao at intel.com Thu Apr 2 05:50:44 2015 From: liyong.qiao at intel.com (Eli Qiao) Date: Thu, 02 Apr 2015 05:50:44 -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: <20150402055044.26077.4910.malone@gac.canonical.com> thanks Pawel, that seems need to be fixed in libvirt. ** Changed in: nova Assignee: Eli Qiao (taget-9) => (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 1381365 at bugs.launchpad.net Mon Apr 6 22:44:53 2015 From: 1381365 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 06 Apr 2015 22:44:53 -0000 Subject: [Openstack-security] [Bug 1381365] Related fix proposed to keystone (master) References: <20141015072233.17942.25827.malonedeb@chaenomeles.canonical.com> Message-ID: <20150406224454.7744.43297.malone@soybean.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/171001 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1381365 Title: SSL Version and cipher selection not possible Status in Cinder: New Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Identity (Keystone): Won't Fix Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Advisories: Won't Fix Bug description: We configure keystone to use SSL always. Due to the poodle issue, I was trying to configure keystone to disable SSLv3 completely. http://googleonlinesecurity.blogspot.fi/2014/10/this-poodle-bites-exploiting-ssl-30.html https://www.openssl.org/~bodo/ssl-poodle.pdf It seems that keystone has no support for configring SSL versions, nor ciphers. If I'm not mistaken the relevant code is in the start function in common/environment/eventlet_server.py It calls eventlet.wrap_ssl but with no SSL version nor cipher options. Since the interface is identical, I assume it uses ssl.wrap_socket. The default here seems to be PROTOCOL_SSLv23 (SSL2 disabled), which would make this vulnerable to the poodle issue. SSL conifgs should probably be possible to be set in the config file (with sane defaults), so that current and newly detected weak ciphers can be disabled without code changes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1381365/+subscriptions From 1435530 at bugs.launchpad.net Tue Apr 7 12:38:41 2015 From: 1435530 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 07 Apr 2015 12:38:41 -0000 Subject: [Openstack-security] [Bug 1435530] Re: keystonemiddleware without TRL checking and default cache config can allow access after token revocation References: <20150323201925.7521.48815.malonedeb@chaenomeles.canonical.com> Message-ID: <20150407123841.7552.95140.malone@chaenomeles.canonical.com> This is by design, but we have a chance to improve the behavior with token revocation events. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1435530 Title: keystonemiddleware without TRL checking and default cache config can allow access after token revocation Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: *** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call *** Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user). Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used. This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions From 1381365 at bugs.launchpad.net Tue Apr 7 14:05:18 2015 From: 1381365 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 07 Apr 2015 14:05:18 -0000 Subject: [Openstack-security] [Bug 1381365] Related fix merged to keystone (master) References: <20141015072233.17942.25827.malonedeb@chaenomeles.canonical.com> Message-ID: <20150407140518.25735.87884.malone@gac.canonical.com> Reviewed: https://review.openstack.org/171001 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=1d4a6db158e3118181ae9d96a03832c49ff8998f Submitter: Jenkins Branch: master commit 1d4a6db158e3118181ae9d96a03832c49ff8998f Author: Morgan Fainberg Date: Mon Apr 6 15:41:29 2015 -0700 Skip SSL tests because some platforms do not enable SSLv3 For "damned good security reasons" (POODLE) some platforms have patched out SSLv3 from OpenSSL. Because Evenetlet cannot be configured for specific versions (or ciphers) and httplib is extremely limited, the tests for SSL have been explicitly skipped. These tests should be potentially re-enabled in the functional suite for SSL terminated endpoints. This comes back to "do not terminate SSL in the eventlet wsgi" that was determined in bug 1381365. Change-Id: Ic4b446ceee9034de5b6530c2d79d798a903fcbbf Related-Bug: #1381365 Closes-Bug: #1435174 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1381365 Title: SSL Version and cipher selection not possible Status in Cinder: New Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Identity (Keystone): Won't Fix Status in OpenStack Compute (Nova): Won't Fix Status in OpenStack Security Advisories: Won't Fix Bug description: We configure keystone to use SSL always. Due to the poodle issue, I was trying to configure keystone to disable SSLv3 completely. http://googleonlinesecurity.blogspot.fi/2014/10/this-poodle-bites-exploiting-ssl-30.html https://www.openssl.org/~bodo/ssl-poodle.pdf It seems that keystone has no support for configring SSL versions, nor ciphers. If I'm not mistaken the relevant code is in the start function in common/environment/eventlet_server.py It calls eventlet.wrap_ssl but with no SSL version nor cipher options. Since the interface is identical, I assume it uses ssl.wrap_socket. The default here seems to be PROTOCOL_SSLv23 (SSL2 disabled), which would make this vulnerable to the poodle issue. SSL conifgs should probably be possible to be set in the config file (with sane defaults), so that current and newly detected weak ciphers can be disabled without code changes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1381365/+subscriptions From 1435530 at bugs.launchpad.net Wed Apr 8 13:48:51 2015 From: 1435530 at bugs.launchpad.net (Robert Clark) Date: Wed, 08 Apr 2015 13:48:51 -0000 Subject: [Openstack-security] [Bug 1435530] Re: keystonemiddleware without TRL checking and default cache config can allow access after token revocation References: <20150323201925.7521.48815.malonedeb@chaenomeles.canonical.com> Message-ID: <20150408134851.7088.78403.malone@chaenomeles.canonical.com> I agree that an OSSN would be appropriate. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1435530 Title: keystonemiddleware without TRL checking and default cache config can allow access after token revocation Status in OpenStack Identity (Keystone) Middleware: New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: *** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call *** Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user). Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used. This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted. To manage notifications about this bug go to: https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions From gerrit2 at review.openstack.org Wed Apr 8 22:17:00 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 08 Apr 2015 22:17:00 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I7c079b779245a0af6bc793564fa8a560e4226afe Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/171003 Log: commit 77f61e9c779ac97663cdbcb1641f87c80161e77d Author: Kevin Benton Date: Sun Mar 29 03:37:25 2015 -0700 Add simple ARP spoofing protection Adds an option to setup OVS rules that will prevent ports attached to the agent from sending any ARP responses that contain an IP address not belonging to the port (in fixed IPs or allowed_address_pairs). It is disabled by default and requires an OVS version that can match on ARP fields. If it is too old, traffic will still flow but it won't have ARP spoofing protection. There is a sanity check to verify that ARP header matching is supported. This prevention is specific to OVS so it will not help with other plugins that use the reference iptables filtering. A non-OVS-specific general approach will require something like the ebtables integration in Ibc6d3d520c1383cf7e00f4bdeb7853a41ac4b14b. Details: A new table is added for ARP spoofing prevention. All ARP traffic on the local switching table is sent to this spoofing table. The spoofing table will allow all ARP requests because we aren't interested in them. It will then install an ARP response allow rule for each IP address the port is assigned. All other ARP responses are dropped. DocImpact SecurityImpact Partial-Bug: #1274034 Change-Id: I7c079b779245a0af6bc793564fa8a560e4226afe From gerrit2 at review.openstack.org Wed Apr 8 23:06:44 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 08 Apr 2015 23:06:44 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I7c079b779245a0af6bc793564fa8a560e4226afe Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/171003 Log: commit aa7356b729f9672855980429677c969b6bab61a1 Author: Kevin Benton Date: Sun Mar 29 03:37:25 2015 -0700 Add simple ARP spoofing protection Adds an option to setup OVS rules that will prevent ports attached to the agent from sending any ARP responses that contain an IP address not belonging to the port (in fixed IPs or allowed_address_pairs). It is disabled by default and requires an OVS version that can match on ARP fields. If it is too old, traffic will still flow but it won't have ARP spoofing protection. There is a sanity check to verify that ARP header matching is supported. This prevention is specific to OVS so it will not help with other plugins that use the reference iptables filtering. A non-OVS-specific general approach will require something like the ebtables integration in Ibc6d3d520c1383cf7e00f4bdeb7853a41ac4b14b. Details: A new table is added for ARP spoofing prevention. All ARP traffic on the local switching table is sent to this spoofing table. The spoofing table will allow all ARP requests because we aren't interested in them. It will then install an ARP response allow rule for each IP address the port is assigned. All other ARP responses are dropped. DocImpact SecurityImpact Partial-Bug: #1274034 Change-Id: I7c079b779245a0af6bc793564fa8a560e4226afe From 1274034 at bugs.launchpad.net Thu Apr 9 01:21:58 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 09 Apr 2015 01:21:58 -0000 Subject: [Openstack-security] [Bug 1274034] Fix merged to neutron (master) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150409012158.7725.8844.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/171003 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=aa7356b729f9672855980429677c969b6bab61a1 Submitter: Jenkins Branch: master commit aa7356b729f9672855980429677c969b6bab61a1 Author: Kevin Benton Date: Sun Mar 29 03:37:25 2015 -0700 Add simple ARP spoofing protection Adds an option to setup OVS rules that will prevent ports attached to the agent from sending any ARP responses that contain an IP address not belonging to the port (in fixed IPs or allowed_address_pairs). It is disabled by default and requires an OVS version that can match on ARP fields. If it is too old, traffic will still flow but it won't have ARP spoofing protection. There is a sanity check to verify that ARP header matching is supported. This prevention is specific to OVS so it will not help with other plugins that use the reference iptables filtering. A non-OVS-specific general approach will require something like the ebtables integration in Ibc6d3d520c1383cf7e00f4bdeb7853a41ac4b14b. Details: A new table is added for ARP spoofing prevention. All ARP traffic on the local switching table is sent to this spoofing table. The spoofing table will allow all ARP requests because we aren't interested in them. It will then install an ARP response allow rule for each IP address the port is assigned. All other ARP responses are dropped. DocImpact SecurityImpact Partial-Bug: #1274034 Change-Id: I7c079b779245a0af6bc793564fa8a560e4226afe -- 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 1274034 at bugs.launchpad.net Thu Apr 9 01:29:34 2015 From: 1274034 at bugs.launchpad.net (Kyle Mestery) Date: Thu, 09 Apr 2015 01: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: <20150409012934.23574.99096.malone@wampee.canonical.com> Kevin's fix for ML2+OVS merged in Kilo, moving this out to Liberty to examine the ebtables fix. ** Changed in: neutron Milestone: kilo-rc1 => liberty-1 -- 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 1409142 at bugs.launchpad.net Thu Apr 9 10:30:49 2015 From: 1409142 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 09 Apr 2015 10:30:49 -0000 Subject: [Openstack-security] [Bug 1409142] Related fix merged to nova (master) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150409103049.25905.38415.malone@gac.canonical.com> Reviewed: https://review.openstack.org/169752 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=2ffcf18d00eff6fb0777769469c4aa5ac7bbb6c9 Submitter: Jenkins Branch: master commit 2ffcf18d00eff6fb0777769469c4aa5ac7bbb6c9 Author: Nikola Dipanov Date: Wed Apr 1 14:35:13 2015 +0100 consoleauth: Store access_url on token authorization Related-bug: 1409142 As part of the fix for the related bug - we've added protocol checking to mitigate MITM attacks, however we base protocol checking on a config option that is normally only intended for compute hosts. This is quite user hostile, as it is now important that all nodes running compute and proxy services have this option in sync. We can do better than that - we can persist the URL the client is expected to use, and once we get it back on token validation, we can make sure that the request is using the intended protocol, mitigating the MITM injected script attacks. This patch makes sure that the access_url is persisted with the token - the follow-up patch makes consoles use that info. Change-Id: I02a377f54de46536ca35413b615d3298967afc33 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 9 18:43:32 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 09 Apr 2015 18:43:32 -0000 Subject: [Openstack-security] [Bug 1427228] Re: Allow to run neutron-ns-metadata-proxy as nobody References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150409184335.7181.40099.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): Fix Released Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From 1409142 at bugs.launchpad.net Thu Apr 9 18:52:36 2015 From: 1409142 at bugs.launchpad.net (Adam Gandelman) Date: Thu, 09 Apr 2015 18:52:36 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150409185239.7346.72164.launchpad@chaenomeles.canonical.com> ** Changed in: nova/juno Milestone: None => 2014.2.3 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From 1394988 at bugs.launchpad.net Fri Apr 10 06:28:31 2015 From: 1394988 at bugs.launchpad.net (Adam Gandelman) Date: Fri, 10 Apr 2015 06:28:31 -0000 Subject: [Openstack-security] [Bug 1394988] Re: Hadoop with auto security group not working References: <20141121132920.28673.42565.malonedeb@wampee.canonical.com> Message-ID: <20150410062833.26299.60648.launchpad@gac.canonical.com> ** Changed in: sahara/juno Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1394988 Title: Hadoop with auto security group not working Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: Fix Released Bug description: ENV: OpenStack with Neutron Steps to reproduce: 1. Create cluster with auto security groups and two or more nodemanagers. 2. Launch pig job with 1Gb input data Result: After ~1 hour job in KILLED state. Reproduced with the following plugins: Vanilla 2 HDP 2 CDH To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1394988/+subscriptions From 1391520 at bugs.launchpad.net Fri Apr 10 06:28:34 2015 From: 1391520 at bugs.launchpad.net (Adam Gandelman) Date: Fri, 10 Apr 2015 06:28:34 -0000 Subject: [Openstack-security] [Bug 1391520] Re: Create CDH cluster with auto security group failed References: <20141111134553.19455.35550.malonedeb@gac.canonical.com> Message-ID: <20150410062836.7513.21992.launchpad@soybean.canonical.com> ** Changed in: sahara/juno Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1391520 Title: Create CDH cluster with auto security group failed Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: Fix Released Bug description: Steps to reproduce: Create cluster with auto security groups. Result: Cluster in 'Configuring' state To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1391520/+subscriptions From 1409142 at bugs.launchpad.net Fri Apr 10 06:44:27 2015 From: 1409142 at bugs.launchpad.net (Adam Gandelman) Date: Fri, 10 Apr 2015 06:44:27 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150410064429.7725.93102.launchpad@chaenomeles.canonical.com> ** Changed in: nova/juno Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments. OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From thierry.carrez+lp at gmail.com Fri Apr 10 15:43:18 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 10 Apr 2015 15:43:18 -0000 Subject: [Openstack-security] [Bug 1414532] Re: asserts used in cache.py References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150410154322.14016.55989.launchpad@soybean.canonical.com> ** Changed in: glance Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From 1274034 at bugs.launchpad.net Sun Apr 12 20:59:28 2015 From: 1274034 at bugs.launchpad.net (Kevin Benton) Date: Sun, 12 Apr 2015 20:59:28 -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: <20150412205928.26249.38254.malone@gac.canonical.com> As Kyle mentioned, this is fixed for OVS, but not for Linux bridge or other vswitches. ** Changed in: neutron Assignee: Kevin Benton (kevinbenton) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in 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 jbrendel at cisco.com Sun Apr 12 21:28:04 2015 From: jbrendel at cisco.com (Juergen Brendel) Date: Sun, 12 Apr 2015 21:28:04 -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: <20150412212807.14221.39137.launchpad@wampee.canonical.com> ** Changed in: ossa Assignee: (unassigned) => Juergen Brendel (jbrendel) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in 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 gerrit2 at review.openstack.org Mon Apr 13 13:58:45 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 13 Apr 2015 13:58:45 +0000 Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review request change Ie948ccc999f79300d7449944406f063d62a95533 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/172924 Log: commit ad94c5fee5f403dfe1efd66686bfa6623a3b0ee0 Author: Dan Genin Date: Mon Apr 13 09:51:05 2015 -0400 Stop encrypted disk on instance suspend/power off Disconnecting dm-crypt device from an encrypted LVM volume while the instance is suspended or powered off will secure user data from unauthorized access. This will extend data at-rest protection provided by the LVM ephemeral storage encryption feature. SecurityImpact Change-Id: Ie948ccc999f79300d7449944406f063d62a95533 Implements: blueprint stop-dmcrypt-on-suspend Previouly-approved: kilo (I6070754d998abc73c8a2e03025700da71dcdafbe) From dklyle0 at gmail.com Tue Apr 14 15:49:28 2015 From: dklyle0 at gmail.com (David Lyle) Date: Tue, 14 Apr 2015 15:49:28 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <20150414154928.26346.30543.launchpad@gac.canonical.com> ** Tags removed: kilo-rc-potential -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Bug description: --- This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added as to the bug as attachments. --- The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From thierry.carrez+lp at gmail.com Tue Apr 14 16:43:40 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Tue, 14 Apr 2015 16:43:40 -0000 Subject: [Openstack-security] [Bug 1260525] Re: Incomplete XSS fix for ossa/1247675 References: <20131212225614.8529.85762.malonedeb@gac.canonical.com> Message-ID: <20150414164342.30176.80359.launchpad@gac.canonical.com> ** Changed in: horizon Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260525 Title: Incomplete XSS fix for ossa/1247675 Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisories: Invalid Bug description: The patch for https://bugs.launchpad.net/ossa/+bug/1247675 did not completely fix the reported issue. It failed to completely remove the use of html.strip_tags, which is not intended to be a security function, and does not properly sanitize output. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/tables.py#L254 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1260525/+subscriptions From fungi at yuggoth.org Tue Apr 14 21:23:57 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 14 Apr 2015 21:23:57 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150414212358.30278.75610.launchpad@gac.canonical.com> ** Description changed: - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added as to the bug as - attachments. - OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From fungi at yuggoth.org Tue Apr 14 21:26:28 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 14 Apr 2015 21:26:28 -0000 Subject: [Openstack-security] [Bug 1417762] Re: XSS in network create error reporting References: <20150203205415.432.2591.malonedeb@wampee.canonical.com> Message-ID: <20150414212629.29661.93298.launchpad@gac.canonical.com> ** Description changed: - --- - - This issue is being treated as a potential security risk under embargo. - Please do not make any public mention of embargoed (private) security - vulnerabilities before their coordinated publication by the OpenStack - Vulnerability Management Team in the form of an official OpenStack - Security Advisory. This includes discussion of the bug or associated - fixes in public forums such as mailing lists, code review systems and - bug trackers. Please also avoid private disclosure to other individuals - not already approved for access to this information, and provide this - same reminder to those who are made aware of the issue prior to - publication. All discussion should remain confined to this private bug - report, and any proposed fixes should be added as to the bug as - attachments. - - --- - The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1417762 Title: XSS in network create error reporting Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisories: Won't Fix Bug description: The error reporting in Horizon for creating a new network is susceptible to a Cross-Site Scripting vulnerability. Example request/response: Request POST /project/networks/create HTTP/1.1 ... csrfmiddlewaretoken=6MGUvp62x8c6GU7TfRXQLZERmJuN7nXT&net_profile_id=&net_name=foobar&admin_state=True&with_subnet=on&subnet_name=&cidr=&ip_version=4&gateway_ip=&enable_dhcp=on&ipv6_modes=none%2Fnone&allocation_pools=&dns_nameservers=&host_routes= Response HTTP/1.1 200 OK Date: Tue, 03 Feb 2015 20:42:28 GMT Server: Apache/2.4.10 (Debian) Vary: Accept-Language,Cookie X-Frame-Options: SAMEORIGIN Content-Language: en Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/json Content-Length: 209 {"has_errors": true, "errors": {"createnetworkinfoaction": {"net_profile_id": ["Select a valid choice. is not one of the available choices."]}}, "workflow_slug": "create_network"} In the above example if the net_profile_id does not exist, the json response contains the user input and Horizon echo's it out. Although it would be difficult to exploit this vulnerability because an attacker would need to manipulate the hidden HTML net_profile_id parameter or the POST body, Horizon should still HTML encode the output. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417762/+subscriptions From 1430951 at bugs.launchpad.net Wed Apr 15 00:48:48 2015 From: 1430951 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 15 Apr 2015 00:48:48 -0000 Subject: [Openstack-security] [Bug 1430951] Re: Revocation causes duplicate (and overly broad?) events in revocation table References: <20150311182038.25203.5527.malonedeb@chaenomeles.canonical.com> Message-ID: <20150415004849.21456.92014.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/171305 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=888488cc2e205971636a83ad39059ed2cf8a9c65 Submitter: Jenkins Branch: master commit 888488cc2e205971636a83ad39059ed2cf8a9c65 Author: Alexander Makarov Date: Tue Apr 7 20:25:03 2015 +0300 Redundant events on group grant revocation Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) Both 2 & 3 are the result of handling notification fired by _emit_invalidate_token_persistence. Change-Id: I7199bcb9f9425004985e9db0833ce1f8a0ff5ac6 Closes-Bug: 1430951 ** Changed in: keystone Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1430951 Title: Revocation causes duplicate (and overly broad?) events in revocation table Status in OpenStack Identity (Keystone): Fix Committed Bug description: Revoke a project scoped token You see 3 entries in revocation_event table 1) (id, user_id, project_id, role_id, issued_before) 2) (id, user_id,, issued_before) 3) (id, user_id,, issued_before) 2 & 3 are redundant. Definitely 3) is redundant as it is same as 2) BTW, this from master branch as of 3/11/2015 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1430951/+subscriptions From msm at redhat.com Fri Apr 17 18:40:18 2015 From: msm at redhat.com (Michael McCune) Date: Fri, 17 Apr 2015 18:40:18 -0000 Subject: [Openstack-security] [Bug 1414532] Re: asserts used in cache.py References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150417184020.31803.40833.launchpad@gac.canonical.com> ** Changed in: ossn Assignee: Robert Clark (robert-clark) => Michael McCune (mimccune) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From 1414532 at bugs.launchpad.net Fri Apr 17 20:09:32 2015 From: 1414532 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 17 Apr 2015 20:09:32 -0000 Subject: [Openstack-security] [Bug 1414532] Fix proposed to glance (stable/juno) References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150417200933.16199.19107.malone@soybean.canonical.com> Fix proposed to branch: stable/juno Review: https://review.openstack.org/175043 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From 1414532 at bugs.launchpad.net Fri Apr 17 20:09:42 2015 From: 1414532 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 17 Apr 2015 20:09:42 -0000 Subject: [Openstack-security] [Bug 1414532] Fix proposed to glance (stable/icehouse) References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150417200942.13384.88250.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/175044 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From john at johngarbutt.com Mon Apr 20 11:21:25 2015 From: john at johngarbutt.com (John Garbutt) Date: Mon, 20 Apr 2015 11:21:25 -0000 Subject: [Openstack-security] [Bug 1445335] Re: create/delete flavor permissions should be controlled by policy.json References: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Message-ID: <20150420112126.32560.64235.launchpad@gac.canonical.com> ** Changed in: nova Importance: High => Critical -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445335 Title: create/delete flavor permissions should be controlled by policy.json Status in OpenStack Compute (Nova): Confirmed Bug description: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1445335/+subscriptions From thierry.carrez+lp at gmail.com Mon Apr 20 14:10:07 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 20 Apr 2015 14:10:07 -0000 Subject: [Openstack-security] [Bug 1434034] Re: Disabling users & groups may not invalidate previously-issued tokens References: <20150319111325.13509.80712.malonedeb@wampee.canonical.com> Message-ID: <20150420141007.32147.75502.malone@gac.canonical.com> Adding OSSN for discussion ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1434034 Title: Disabling users & groups may not invalidate previously-issued tokens Status in OpenStack Identity (Keystone): In Progress Status in Keystone juno series: In Progress Status in OpenStack Security Advisories: Confirmed Status in OpenStack Security Notes: New Bug description: Even if the user is disabled, can use the last token is validated. 0. user foo is enable 1. get token (a) 2. user foo is disabled 3. foo can still use any APIs by token(a) that's all. This issue is not cache process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1434034/+subscriptions From john at johngarbutt.com Mon Apr 20 14:57:25 2015 From: john at johngarbutt.com (John Garbutt) Date: Mon, 20 Apr 2015 14:57:25 -0000 Subject: [Openstack-security] [Bug 1445335] Re: create/delete flavor permissions should be controlled by policy.json References: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Message-ID: <20150420145725.31904.44769.launchpad@gac.canonical.com> ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445335 Title: create/delete flavor permissions should be controlled by policy.json Status in OpenStack Compute (Nova): Confirmed Bug description: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1445335/+subscriptions From fungi at yuggoth.org Mon Apr 20 15:33:23 2015 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 20 Apr 2015 15:33:23 -0000 Subject: [Openstack-security] [Bug 1445335] Re: create/delete flavor permissions should be controlled by policy.json References: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Message-ID: <20150420153323.16769.6802.malone@soybean.canonical.com> You've switched the status of this bug to indicate an exploitable security vulnerability. Can you please clarify the conditions under which this bug can be exploited by a malicious actor, and the extent of the impact it implies? ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445335 Title: create/delete flavor permissions should be controlled by policy.json Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Incomplete Bug description: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1445335/+subscriptions From dstanek at dstanek.com Mon Apr 20 20:44:46 2015 From: dstanek at dstanek.com (David Stanek) Date: Mon, 20 Apr 2015 20:44:46 -0000 Subject: [Openstack-security] [Bug 1440958] Re: loosen validation on matching trusted dashboard References: <20150407024927.26193.80349.malonedeb@gac.canonical.com> Message-ID: <20150420204447.13822.13987.launchpad@chaenomeles.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1440958 Title: loosen validation on matching trusted dashboard Status in OpenStack Identity (Keystone): Fix Committed Bug description: In the current implementation for verifying where the SSO request came from, the host is grabbed from the 'origin' query parameter, and compared to the list of 'trusted_dashboards' in the config file. origin = context['query_string'].get('origin') host = urllib.parse.unquote_plus(origin) if host in CONF.federation.trusted_dashboard: ... https://github.com/openstack/keystone/blob/master/keystone/contrib/federation/controllers.py#L278-L287 This works, but unless the entry is marked perfectly in the config file, it won't match. We should loosen the validation that is performed, and maybe even use the HTTP Referer instead (and no longer require the 'origin' parameter from horizon). We should be able to decompose the Refer to figure out the scheme + hostname + path, and use that hostname to check against the trusted dashboards. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1440958/+subscriptions From charles.neill at rackspace.com Tue Apr 21 20:52:19 2015 From: charles.neill at rackspace.com (Charles Neill) Date: Tue, 21 Apr 2015 20:52:19 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150421205220.16292.16651.launchpad@soybean.canonical.com> ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): New Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From douglas.mendizabal at rackspace.com Tue Apr 21 21:00:56 2015 From: douglas.mendizabal at rackspace.com (=?utf-8?q?Douglas_Mendiz=C3=A1bal?=) Date: Tue, 21 Apr 2015 21:00:56 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150421210058.13483.20777.launchpad@wampee.canonical.com> ** Changed in: barbican Status: New => Confirmed ** Changed in: barbican Importance: Undecided => Critical ** Changed in: barbican Assignee: (unassigned) => Charles Neill (charles-neill) ** Changed in: barbican Milestone: None => liberty-1 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): Confirmed Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From gerrit2 at review.openstack.org Tue Apr 21 21:32:48 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 21 Apr 2015 21:32:48 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141130 Log: commit 2414834ffeb8ba7ce2401236d01c88702fec5a14 Author: Édouard Thuleau Date: Tue Feb 10 13:43:34 2015 +1300 ARP spoofing patch: Low level ebtables integration ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into a set of smaller patches for easier review. This patch here is th first of the series and includes the low-level ebtables integration, unit and functional tests. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From kent.wang at intel.com Tue Apr 21 23:44:39 2015 From: kent.wang at intel.com (Kent Wang) Date: Tue, 21 Apr 2015 23:44:39 -0000 Subject: [Openstack-security] [Bug 1369870] Re: The "message" cookie is not marked as "secure" References: <20140916063505.5162.66017.malonedeb@wampee.canonical.com> Message-ID: <20150421234441.16385.42086.launchpad@soybean.canonical.com> ** Changed in: horizon Assignee: (unassigned) => Kent Wang (k.wang) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1369870 Title: The "message" cookie is not marked as "secure" Status in OpenStack Dashboard (Horizon): Confirmed Bug description: The message cookie is not marked as 'secure', as identified by the following security report. If might contain sensitive information, and would benefit from being marked as secure. --- 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 Apr 23 13:27:39 2015 From: 1372375 at bugs.launchpad.net (Dane Fichter) Date: Thu, 23 Apr 2015 13:27:39 -0000 Subject: [Openstack-security] [Bug 1372375] OpenStack Docs References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: Hey Joel, besides just docs.openstack.org, is there any other source of OpenStack documentation? Dane -- You received this bug notification because you are a member of OpenStack Security, 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): Invalid 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 Thu Apr 23 13:47:37 2015 From: 1372375 at bugs.launchpad.net (Dane Fichter) Date: Thu, 23 Apr 2015 13:47: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: <20150423134737.24886.45909.malone@gac.canonical.com> Sorry for the comment. Hilariously stupid Microsoft Outlook error on my part. -- You received this bug notification because you are a member of OpenStack Security, 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): Invalid 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 robert.clark at hp.com Thu Apr 23 14:16:28 2015 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 23 Apr 2015 14:16:28 +0000 Subject: [Openstack-security] [Bug 1372375] OpenStack Docs In-Reply-To: References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: > -----Original Message----- > From: Dane Fichter [mailto:1372375 at bugs.launchpad.net] > Sent: 23 April 2015 14:28 > To: openstack-security at lists.openstack.org > Subject: [Openstack-security] [Bug 1372375] OpenStack Docs > > Hey Joel, > > besides just docs.openstack.org, is there any other source of OpenStack > documentation? > > Dane Hi Dane, This is a good place to start: https://wiki.openstack.org/wiki/Security From 1372375 at bugs.launchpad.net Thu Apr 23 14:16:28 2015 From: 1372375 at bugs.launchpad.net (Robert Clark) Date: Thu, 23 Apr 2015 14:16:28 -0000 Subject: [Openstack-security] [Bug 1372375] OpenStack Docs References: <20140922095132.18315.85937.malonedeb@chaenomeles.canonical.com> Message-ID: > -----Original Message----- > From: Dane Fichter [mailto:1372375 at bugs.launchpad.net] > Sent: 23 April 2015 14:28 > To: openstack-security at lists.openstack.org > Subject: [Openstack-security] [Bug 1372375] OpenStack Docs > > Hey Joel, > > besides just docs.openstack.org, is there any other source of OpenStack > documentation? > > Dane Hi Dane, This is a good place to start: https://wiki.openstack.org/wiki/Security -- You received this bug notification because you are a member of OpenStack Security, 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): Invalid 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 thierry.carrez+lp at gmail.com Thu Apr 23 15:29:15 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 23 Apr 2015 15:29:15 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150423152915.24822.11632.launchpad@gac.canonical.com> ** Also affects: barbican/kilo Importance: Undecided Status: New ** Changed in: barbican/kilo Milestone: None => kilo-rc2 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): In Progress Status in Barbican kilo series: New Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From morgan.fainberg at gmail.com Thu Apr 23 16:38:34 2015 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Thu, 23 Apr 2015 16:38:34 -0000 Subject: [Openstack-security] [Bug 1434034] Re: Disabling users & groups may not invalidate previously-issued tokens References: <20150319111325.13509.80712.malonedeb@wampee.canonical.com> Message-ID: <20150423163834.16769.7404.malone@soybean.canonical.com> For the record, I'm fine with this being either OSSN or OSSA. This should be clearly communicated. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1434034 Title: Disabling users & groups may not invalidate previously-issued tokens Status in OpenStack Identity (Keystone): In Progress Status in Keystone juno series: In Progress Status in OpenStack Security Advisories: Confirmed Status in OpenStack Security Notes: New Bug description: Even if the user is disabled, can use the last token is validated. 0. user foo is enable 1. get token (a) 2. user foo is disabled 3. foo can still use any APIs by token(a) that's all. This issue is not cache process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1434034/+subscriptions From nkinder at redhat.com Thu Apr 23 16:53:17 2015 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 23 Apr 2015 16:53:17 -0000 Subject: [Openstack-security] [Bug 1434034] Re: Disabling users & groups may not invalidate previously-issued tokens References: <20150319111325.13509.80712.malonedeb@wampee.canonical.com> Message-ID: <20150423165317.24759.25662.malone@gac.canonical.com> I think this should be an OSSN (not an OSSA). I do agree that this is more of a "tribal knowledge" item at this point, but we need to get the word out abotu how it bahaves more broadly. I honestly don't think that this is a solvable problem. The token validity period needs to be a choice of acceptable risk (just as it is for things like a Kerberos deployment). -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1434034 Title: Disabling users & groups may not invalidate previously-issued tokens Status in OpenStack Identity (Keystone): In Progress Status in Keystone juno series: In Progress Status in OpenStack Security Advisories: Confirmed Status in OpenStack Security Notes: New Bug description: Even if the user is disabled, can use the last token is validated. 0. user foo is enable 1. get token (a) 2. user foo is disabled 3. foo can still use any APIs by token(a) that's all. This issue is not cache process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1434034/+subscriptions From 1414532 at bugs.launchpad.net Thu Apr 23 21:28:40 2015 From: 1414532 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 23 Apr 2015 21:28:40 -0000 Subject: [Openstack-security] [Bug 1414532] Change abandoned on glance (stable/icehouse) References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150423212840.13855.75145.malone@chaenomeles.canonical.com> Change abandoned by Ian Cordasco (ian.cordasco at rackspace.com) on branch: stable/icehouse Review: https://review.openstack.org/175044 Reason: It's clear to me that Erno is correct. I'm abandoning this for now. If it becomes apparent that it should be in Icehouse, I or another stable maintainer core can restore it. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From douglas.mendizabal at rackspace.com Thu Apr 23 22:20:38 2015 From: douglas.mendizabal at rackspace.com (=?utf-8?q?Douglas_Mendiz=C3=A1bal?=) Date: Thu, 23 Apr 2015 22:20:38 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150423222040.13890.42993.launchpad@wampee.canonical.com> ** Changed in: barbican/kilo Importance: Undecided => Critical ** Changed in: barbican/kilo Assignee: (unassigned) => Douglas Mendizábal (dougmendizabal) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): In Progress Status in Barbican kilo series: New Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From 1274034 at bugs.launchpad.net Fri Apr 24 04:58:37 2015 From: 1274034 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 24 Apr 2015 04:58:37 -0000 Subject: [Openstack-security] [Bug 1274034] Related fix merged to neutron (master) References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20150424045837.25041.32091.malone@gac.canonical.com> Reviewed: https://review.openstack.org/141130 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2414834ffeb8ba7ce2401236d01c88702fec5a14 Submitter: Jenkins Branch: master commit 2414834ffeb8ba7ce2401236d01c88702fec5a14 Author: Édouard Thuleau Date: Tue Feb 10 13:43:34 2015 +1300 ARP spoofing patch: Low level ebtables integration ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into a set of smaller patches for easier review. This patch here is th first of the series and includes the low-level ebtables integration, unit and functional tests. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in 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 douglas.mendizabal at rackspace.com Fri Apr 24 17:40:48 2015 From: douglas.mendizabal at rackspace.com (=?utf-8?q?Douglas_Mendiz=C3=A1bal?=) Date: Fri, 24 Apr 2015 17:40:48 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150424174049.13384.51966.launchpad@chaenomeles.canonical.com> ** Changed in: barbican/kilo Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): In Progress Status in Barbican kilo series: Confirmed Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From 1361360 at bugs.launchpad.net Fri Apr 24 21:37:10 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 24 Apr 2015 21:37:10 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150424213710.25202.57672.malone@gac.canonical.com> Reviewed: https://review.openstack.org/130824 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=3b08644eb9cf4c5aca51a36250ae93105c17f6c4 Submitter: Jenkins Branch: master commit 3b08644eb9cf4c5aca51a36250ae93105c17f6c4 Author: abhishekkekane Date: Tue Oct 21 04:10:57 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=900). SecurityImpact Closes-Bug: #1361360 Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 ** Changed in: keystone Status: Won't Fix => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Mon Apr 27 07:13:49 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 27 Apr 2015 07:13:49 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/177670 Log: commit 67cda0ccae04471340bcada099d945d90979e64d Author: abhishekkekane Date: Tue Oct 21 04:10:57 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=900). SecurityImpact Closes-Bug: #1361360 Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 (cherry picked from commit 3b08644eb9cf4c5aca51a36250ae93105c17f6c4) From 1361360 at bugs.launchpad.net Mon Apr 27 07:13:44 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 27 Apr 2015 07:13:44 -0000 Subject: [Openstack-security] [Bug 1361360] Fix proposed to keystone (stable/kilo) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150427071344.17060.83963.malone@gac.canonical.com> Fix proposed to branch: stable/kilo Review: https://review.openstack.org/177670 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From gerrit2 at review.openstack.org Mon Apr 27 09:19:39 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 27 Apr 2015 09:19:39 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/177686 Log: commit 6b953145eb180a1e16340f95c0d32d7ef8e19bd1 Author: abhishekkekane Date: Tue Oct 21 04:10:57 2014 -0700 Eventlet green threads not released back to pool Presently, the wsgi server allows persist connections hence even after the response is sent to the client, it doesn't close the client socket connection. Because of this problem, the green thread is not released back to the pool. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Add a parameter to take advantage of the new(ish) eventlet socket timeout behaviour. Allows closing idle client connections after a period of time, eg: $ time nc localhost 8776 real 1m0.063s Setting 'client_socket_timeout = 0' means do not timeout. DocImpact: Added wsgi_keep_alive option (default=True). Added client_socket_timeout option (default=900). SecurityImpact Conflicts: keystone/common/config.py keystone/common/environment/eventlet_server.py Closes-Bug: #1361360 Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7 (cherry picked from commit 3b08644eb9cf4c5aca51a36250ae93105c17f6c4) From 1361360 at bugs.launchpad.net Mon Apr 27 09:19:35 2015 From: 1361360 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 27 Apr 2015 09:19:35 -0000 Subject: [Openstack-security] [Bug 1361360] Fix proposed to keystone (stable/juno) References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150427091936.13962.88819.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/juno Review: https://review.openstack.org/177686 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From thierry.carrez+lp at gmail.com Mon Apr 27 18:27:39 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 27 Apr 2015 18:27:39 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150427182741.24323.89046.launchpad@wampee.canonical.com> ** Changed in: barbican/kilo Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): Fix Committed Status in Barbican kilo series: Fix Released Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From gerrit2 at review.openstack.org Mon Apr 27 19:48:40 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 27 Apr 2015 19:48:40 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change I305b2ae86415c8d256c641abb2795af663bee56a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/177948 Log: commit c4780d443ccd67e518de7eac688b2858c2281dae Author: Brianna Poulos Date: Mon Apr 27 15:35:51 2015 -0400 Encrypted and Authenticated Image Support This spec describes a means to support signing and signature validation of bootable images, along with encrypted images. DocImpact SecurityImpact Implements: blueprint encrypted-and-authenticated-image-support Change-Id: I305b2ae86415c8d256c641abb2795af663bee56a From gerrit2 at review.openstack.org Mon Apr 27 20:18:04 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 27 Apr 2015 20:18:04 +0000 Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review request change I305b2ae86415c8d256c641abb2795af663bee56a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/177948 Log: commit 9aca39aef7cfa73639776166375ddf035e55f14a Author: Brianna Poulos Date: Mon Apr 27 15:35:51 2015 -0400 Encrypted and Authenticated Image Support This spec describes a means to support signing and signature validation of bootable images, along with encrypted images. DocImpact SecurityImpact Implements: blueprint encrypted-and-authenticated-image-support Change-Id: I305b2ae86415c8d256c641abb2795af663bee56a From gerrit2 at review.openstack.org Tue Apr 28 03:08:37 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Apr 2015 03:08:37 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3c66e92cbe8883dcad843ad243388def3a96dbe5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157097 Log: commit 30790be34967cdc2412a4409f518bb8c9e1d059c Author: Juergen Brendel Date: Thu Feb 26 13:51:04 2015 +1300 ARP spoofing patch: Data structures for rules. ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into smaller patch sets for easier review. This patch set here includes the some classes for the maintenance of ebtable chains and rules. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I3c66e92cbe8883dcad843ad243388def3a96dbe5 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From gerrit2 at review.openstack.org Tue Apr 28 04:32:46 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Apr 2015 04:32:46 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3c66e92cbe8883dcad843ad243388def3a96dbe5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157097 Log: commit 3d0770d1eae500093ba86931eadcd5493600db5e Author: Juergen Brendel Date: Thu Feb 26 13:51:04 2015 +1300 ARP spoofing patch: Data structures for rules. ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into smaller patch sets for easier review. This patch set here includes the some classes for the maintenance of ebtable chains and rules. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I3c66e92cbe8883dcad843ad243388def3a96dbe5 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From gerrit2 at review.openstack.org Tue Apr 28 04:49:00 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Apr 2015 04:49:00 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3c66e92cbe8883dcad843ad243388def3a96dbe5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157097 Log: commit 0d665cf5020a04e7da784adf4a22fd3db86d0db0 Author: Juergen Brendel Date: Thu Feb 26 13:51:04 2015 +1300 ARP spoofing patch: Data structures for rules. ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into smaller patch sets for easier review. This patch set here includes the some classes for the maintenance of ebtable chains and rules. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I3c66e92cbe8883dcad843ad243388def3a96dbe5 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From gerrit2 at review.openstack.org Tue Apr 28 04:55:52 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Apr 2015 04:55:52 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change Ic115eeb59cbacdafb85296d435322ea8b8cc99d6 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157634 Log: commit b94b26f41119b007a0931f839972335138d76259 Author: Juergen Brendel Date: Fri Mar 20 14:40:35 2015 +1300 ARP spoofing patch: Ebtables manager ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into smaller patch sets for easier review. This patch set here includes the ebtables manager class. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: Ic115eeb59cbacdafb85296d435322ea8b8cc99d6 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From gerrit2 at review.openstack.org Tue Apr 28 16:10:43 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Apr 2015 16:10:43 +0000 Subject: [Openstack-security] [stackforge/networking-ovs-dpdk] SecurityImpact review request change I82426b8d5951d2c96e72e42818bfae90b8301076 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/178268 Log: commit 122e7d436d2baf4286f78c0165fcd6601b6e615e Author: Sean Mooney Date: Tue Apr 28 15:48:02 2015 +0000 reopening master for liberty - updated test-requirments.txt to master - backported neuton agent changes from master. Squashed commit of the following: commit 268f1c5a84ba8fe9ddb453f7c3b13ae6a8f50127 Merge: 79e9ffc a46f609 Author: Jenkins Date: Wed Apr 22 20:37:51 2015 +0000 Merge "ovs_neutron_agent: Remove a redundant assignment of ovs_status" commit 79e9ffc9a423faab05ffdf060d77abaaa44ce19b Merge: f24d1c8 75c1d6f Author: Jenkins Date: Wed Apr 15 00:36:38 2015 +0000 Merge "Enable ARP spoofing prevention by default" commit f24d1c844c4095db9422357453b35251f6125c6a Merge: 7212258 eabd40a Author: Jenkins Date: Mon Apr 13 20:09:06 2015 +0000 Merge "Move values for network_type to plugins.common.constants.py" commit eabd40a8cd20b7189a31c301e5f19703604095d3 Author: Romil Gupta Date: Mon Mar 23 08:05:41 2015 -0700 Move values for network_type to plugins.common.constants.py It is quite confusing to have values for network type in common.constants.py instead of having in plugins.common.constants.py. Currently, the plugins/common/constants.py consists network_type constants like VLAN, VXLAN, GRE etc. but values for network type like ranges are defined in common.constants.py which is not good, it is better to have both things at the same place. This patch set addresses the same. Moved out few methods which are predominantly used in plugins from common.utils.py to plugins.common.utils.py. Removed constants which were used in neutron-fwaas from plugins.common.constants.py: https://review.openstack.org/#/c/168709/ Closes-Bug: #1441043 Change-Id: Iecfb15c541ed5d3cce95ba48f072af7fa60ac6f1 commit 7212258a0fdb4e6c41b816dc433e65f49bd37f1d Merge: 3564b55 088fe8b Author: Jenkins Date: Thu Apr 9 01:21:53 2015 +0000 Merge "Add simple ARP spoofing protection" commit a46f609127d64a158a62588b83eb82c1d0f1a5aa Author: YAMAMOTO Takashi Date: Thu Apr 2 13:57:52 2015 +0900 ovs_neutron_agent: Remove a redundant assignment of ovs_status Change-Id: I8ed572aa48ccc226137f65514c58ca5c3ba77870 commit 75c1d6fa89e0d06c6821ebd998cd66a606fa77d6 Author: Kevin Benton Date: Sun Apr 12 14:14:38 2015 -0700 Enable ARP spoofing prevention by default Turn on the ARP spoofing prevention added in I7c079b779245a0af6bc793564fa8a560e4226afe by default. It was disabled by default since it was going into Kilo at the last minute and we didn't want to risk shipping with a default that might have broken an edge case that we didn't consider. This patch enables it by default since there shouldn't be any need to have it disabled. Change-Id: Id17939914ebf8292dce76ccb7d0f6486c91f49e5 commit 088fe8bf381875525ce1c41f482ce74fa989d786 Author: Kevin Benton Date: Sun Mar 29 03:37:25 2015 -0700 Add simple ARP spoofing protection Adds an option to setup OVS rules that will prevent ports attached to the agent from sending any ARP responses that contain an IP address not belonging to the port (in fixed IPs or allowed_address_pairs). It is disabled by default and requires an OVS version that can match on ARP fields. If it is too old, traffic will still flow but it won't have ARP spoofing protection. There is a sanity check to verify that ARP header matching is supported. This prevention is specific to OVS so it will not help with other plugins that use the reference iptables filtering. A non-OVS-specific general approach will require something like the ebtables integration in Ibc6d3d520c1383cf7e00f4bdeb7853a41ac4b14b. Details: A new table is added for ARP spoofing prevention. All ARP traffic on the local switching table is sent to this spoofing table. The spoofing table will allow all ARP requests because we aren't interested in them. It will then install an ARP response allow rule for each IP address the port is assigned. All other ARP responses are dropped. DocImpact SecurityImpact Partial-Bug: #1274034 Change-Id: I7c079b779245a0af6bc793564fa8a560e4226afe Change-Id: I82426b8d5951d2c96e72e42818bfae90b8301076 From gerrit2 at review.openstack.org Tue Apr 28 16:25:13 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Apr 2015 16:25:13 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idbe37922c5f944e3d567ce16913ce5d87af41fef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141485 Log: commit 983b67d6a44a4cc91355857be727cda7d327c00b Author: Daniel Genin Date: Thu Feb 5 09:28:16 2015 -0500 libvirt: Disconnect dm-crypt on instance suspend/stop Strengthens protection provided by ephemeral storage encryption feature by disconnecting the dm-crypt device, which provides access to unencrypted disk, when an encrypted instance is suspended or stopped. Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From gerrit2 at review.openstack.org Tue Apr 28 16:56:09 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Apr 2015 16:56:09 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idbe37922c5f944e3d567ce16913ce5d87af41fef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141485 Log: commit ac549c02485f973b7b5409b6a12fdaa37629ff74 Author: Daniel Genin Date: Thu Feb 5 09:28:16 2015 -0500 libvirt: Disconnect dm-crypt on instance suspend/stop Strengthens protection provided by ephemeral storage encryption feature by disconnecting the dm-crypt device, which provides access to unencrypted disk, when an encrypted instance is suspended or stopped. Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From gerrit2 at review.openstack.org Tue Apr 28 17:52:51 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Apr 2015 17:52:51 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change Idbe37922c5f944e3d567ce16913ce5d87af41fef Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/141485 Log: commit 330b024a98b72c59b2f1cdf7580036f6ddd9853a Author: Daniel Genin Date: Thu Feb 5 09:28:16 2015 -0500 libvirt: Disconnect dm-crypt on instance suspend/stop Strengthens protection provided by ephemeral storage encryption feature by disconnecting the dm-crypt device, which provides access to unencrypted disk, when an encrypted instance is suspended or stopped. Implements: blueprint stop-dmcrypt-on-suspend SecurityImpact Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef From gerrit2 at review.openstack.org Tue Apr 28 23:28:14 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 28 Apr 2015 23:28:14 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3c66e92cbe8883dcad843ad243388def3a96dbe5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157097 Log: commit 4c4f1fc8cb955bc85098139290dcf678a0dfe2c9 Author: Juergen Brendel Date: Thu Feb 26 13:51:04 2015 +1300 ARP spoofing patch: Data structures for rules. ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into smaller patch sets for easier review. This patch set here includes the some classes for the maintenance of ebtable chains and rules. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I3c66e92cbe8883dcad843ad243388def3a96dbe5 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From 1424089 at bugs.launchpad.net Wed Apr 29 13:25:49 2015 From: 1424089 at bugs.launchpad.net (Dolph Mathews) Date: Wed, 29 Apr 2015 13:25:49 -0000 Subject: [Openstack-security] [Bug 1424089] Re: Use SystemRandom rather than random References: <20150220225213.28004.475.malonedeb@soybean.canonical.com> Message-ID: <20150429132550.22760.84120.launchpad@soybean.canonical.com> ** Changed in: keystone Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1424089 Title: Use SystemRandom rather than random Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Advisories: Won't Fix Bug description: SystemRandom should be preferred over direct use of random. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1424089/+subscriptions From gerrit2 at review.openstack.org Thu Apr 30 04:40:05 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 Apr 2015 04:40:05 +0000 Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact review request change Iccdfca4f309c50b7507f0a0992bec561045784f0 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/178926 Log: commit e522a5a6e2de26c27c61fb1e86ce15388f3eaca0 Author: jfwood Date: Wed Apr 29 23:32:50 2015 -0500 Add Crypto/HSM MKEK Rotation Support Currently Barbican has no means to migrate secrets encrypted with a crypto/HSM-style plugin to a new master key encryption key (MKEK) and its associated wrapped project KEKs. This blueprint proposes adding a new Barbican service process that supports completing the rotation of secrets to a new master key encryption key (MKEK) and a new wrapped project KEK. This process would be started after deployers, out of band: (1) generate new MKEK and HMAC signing keys with a binding to new labels, and then (2) replicate these keys to other HSMs that may be in the high availability (HA) group, and then (3) update Barbican's config file to reference these new labels, and finally (4) restart the Barbican nodes. The proposed process would then migrate secrets from encryption via the old keys to encryption via the new ones. Change-Id: Iccdfca4f309c50b7507f0a0992bec561045784f0 Implements: blueprint add-crypto-mkek-rotation-support SecurityImpact: Rotates and migrates secrets to new KEKs. DocImpact: Add information on running KEK migration process. From gerrit2 at review.openstack.org Thu Apr 30 04:51:08 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 Apr 2015 04:51:08 +0000 Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact review request change Iccdfca4f309c50b7507f0a0992bec561045784f0 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/178926 Log: commit 4f1572ed667b67e1ce3bae66e2bc8968ae2e97c2 Author: jfwood Date: Wed Apr 29 23:32:50 2015 -0500 Add Crypto/HSM MKEK Rotation Support Currently Barbican has no means to migrate secrets encrypted with a crypto/HSM-style plugin to a new master key encryption key (MKEK) and its associated wrapped project KEKs. This blueprint proposes adding a new Barbican service process that supports completing the rotation of secrets to a new master key encryption key (MKEK) and a new wrapped project KEK. This process would be started after deployers, out of band: (1) generate new MKEK and HMAC signing keys with a binding to new labels, and then (2) replicate these keys to other HSMs that may be in the high availability (HA) group, and then (3) update Barbican's config file to reference these new labels, and finally (4) restart the Barbican nodes. The proposed process would then migrate secrets from encryption via the old keys to encryption via the new ones. Change-Id: Iccdfca4f309c50b7507f0a0992bec561045784f0 Implements: blueprint add-crypto-mkek-rotation-support SecurityImpact: Rotates and migrates secrets to new KEKs. DocImpact: Add information on running KEK migration process. From 1118066 at bugs.launchpad.net Thu Apr 30 07:32:26 2015 From: 1118066 at bugs.launchpad.net (Mh Raies) Date: Thu, 30 Apr 2015 07:32:26 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20150430073226.22613.37997.malone@soybean.canonical.com> I will be working on this. And submit a review very soon. ** Changed in: nova Assignee: (unassigned) => Mh Raies (raiesmh08) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From 1031139 at bugs.launchpad.net Thu Apr 30 07:41:37 2015 From: 1031139 at bugs.launchpad.net (Mh Raies) Date: Thu, 30 Apr 2015 07:41:37 -0000 Subject: [Openstack-security] [Bug 1031139] Re: quota-show should return error for invalid tenant id References: <20120730234300.27634.40825.malonedeb@gac.canonical.com> Message-ID: <20150430074138.22259.48236.malone@soybean.canonical.com> It is a problem/limitation of nova not of python-novaclient. What nova do for this API - nova takes the API request and if no project id is given, curent tenant quotas will be displayed. Again if we are taking "--tenant " option then it will be ignored as per current implementation. As per current implementation of nova - It will treat filtering on basis of current tenant and different users in current tenant. So changing it to nova. And also it is a Duplicate of https://bugs.launchpad.net/nova/+bug/1118066 ** Project changed: python-novaclient => nova ** Changed in: nova Assignee: Amandeep (rattenpal-amandeep) => Mh Raies (raiesmh08) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1031139 Title: quota-show should return error for invalid tenant id Status in OpenStack Compute (Nova): Confirmed Bug description: quota-show does not handle alternatives for tenant_id as expected ENV: Devstack trunk (Folsom) / nova d56b5fc3ad6dbfc56e0729174925fb146cef87fa , Mon Jul 30 21:59:56 2012 +0000 I'd expect the following command to work as $ env | grep TENANT -> OS_TENANT_NAME=demo $ nova --debug --os_username=admin --os_password=password quota-show usage: nova quota-show error: too few arguments I'd also expect the following to work: $ nova --debug --os_username=admin --os_password=password quota-show --os_tenant_name=demo usage: nova quota-show error: too few arguments What is more awesome, if in the event that I do provide the wrong tenant_id, it proceeds to use OS_TENANT_NAME returning those results: $nova --debug --os_username=admin --os_password=password quota-show gggggggggggggggggggggggggggggggggg REQ: curl -i http://10.1.11.219:8774/v2/04adebe40d214581b84118bcce264f0e/os-quota- sets/ggggggggggggggggggggggggggggggggggg -X GET -H "X-Auth-Project-Id: demo" -H "User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 10bd3f948df24039b2b88b98771b2b99" +-----------------------------+-------+ | Property | Value | +-----------------------------+-------+ | cores | 20 | | floating_ips | 10 | | gigabytes | 1000 | | injected_file_content_bytes | 10240 | | injected_files | 5 | | instances | 10 | | metadata_items | 128 | | ram | 51200 | | volumes | 10 | +-----------------------------+-------+ I also couldn't figure out how to get the quota-show to work as a member (non-admin) of a project. Let me know if you want any of these issues broken out in to additional bugs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1031139/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 07:59:25 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 07:59:25 -0000 Subject: [Openstack-security] [Bug 1328488] Re: oslo apiclient logs sensitive data References: <20140610105701.26336.80011.malonedeb@wampee.canonical.com> Message-ID: <20150430075927.14688.17707.launchpad@chaenomeles.canonical.com> ** Changed in: oslo-incubator Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1328488 Title: oslo apiclient logs sensitive data Status in The Oslo library incubator: Fix Released 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 thierry.carrez+lp at gmail.com Thu Apr 30 08:05:33 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:05:33 -0000 Subject: [Openstack-security] [Bug 1428829] Re: Fernet tokens don't return audit_ids References: <20150305202358.5908.70068.malonedeb@wampee.canonical.com> Message-ID: <20150430080534.22862.95894.launchpad@soybean.canonical.com> ** Changed in: keystone Milestone: kilo-3 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1428829 Title: Fernet tokens don't return audit_ids Status in OpenStack Identity (Keystone): Fix Released Bug description: The Fernet token formatters accidentally pop the audit_ids from the token_data [1]. The audit_ids shouldn't be removed from the token_data because we need them in the response. [1] https://github.com/openstack/keystone/blob/d36e499a837074d65365ffa440470516c64e2ab6/keystone/token/providers/fernet/token_formatters.py#L126 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1428829/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:05:21 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:05:21 -0000 Subject: [Openstack-security] [Bug 1424089] Re: Use SystemRandom rather than random References: <20150220225213.28004.475.malonedeb@soybean.canonical.com> Message-ID: <20150430080522.16475.45667.launchpad@gac.canonical.com> ** Changed in: keystone Milestone: kilo-3 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1424089 Title: Use SystemRandom rather than random Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Advisories: Won't Fix Bug description: SystemRandom should be preferred over direct use of random. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1424089/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:15:18 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:15:18 -0000 Subject: [Openstack-security] [Bug 1375857] Re: It's not possibile to pass the cacert to the swift store References: <20140930152151.17678.6371.malonedeb@chaenomeles.canonical.com> Message-ID: <20150430081519.14144.1725.launchpad@chaenomeles.canonical.com> ** Changed in: glance Milestone: kilo-2 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1375857 Title: It's not possibile to pass the cacert to the swift store Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Glance backend store-drivers library (glance_store): Fix Committed Bug description: The swift store device defined in the glance store doesn't allow to pass the ca cert file. When the driver creates a connection via the swift client it is not possible to pass that value. That means that if we have swift running on TLS in some cases we have to set the insecure option equals to True as the client can't correctly complete the handshake as it fails on the verification of the cert. The fix I'd like to propose is to add a new parameter to define the ca cert file and pass this value when we create the connection via the swift client. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1375857/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:15:34 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:15:34 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150430081539.25006.41533.launchpad@wampee.canonical.com> ** Changed in: glance Milestone: kilo-3 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:16:26 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:16:26 -0000 Subject: [Openstack-security] [Bug 1414532] Re: asserts used in cache.py References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150430081628.22657.29933.launchpad@soybean.canonical.com> ** Changed in: glance Milestone: kilo-rc1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:15:47 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:15:47 -0000 Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com> Message-ID: <20150430081548.16641.83954.launchpad@gac.canonical.com> ** Changed in: glance Milestone: kilo-3 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, 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): Fix Released 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 thierry.carrez+lp at gmail.com Thu Apr 30 08:22:09 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:22:09 -0000 Subject: [Openstack-security] [Bug 1380642] Re: Horizon should not log token References: <20141013141256.17942.18062.malonedeb@chaenomeles.canonical.com> Message-ID: <20150430082211.22259.67943.launchpad@soybean.canonical.com> ** Changed in: horizon Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1380642 Title: Horizon should not log token Status in OpenStack Dashboard (Horizon): Fix Released Bug description: It is Horizon version of bug 1327019. Various modules in openstack_dashboard/api logs token. In other modules, token value is not logged now and is output as *REDACTED* or some similar string. In Horizon case, these log lines are simply removed to fix the issue as it seems this logging is unnecessary in most cases. I don't think this needs to be private based on the discussion in bug 1327019. def novaclient(request): insecure = getattr(settings, 'OPENSTACK_SSL_NO_VERIFY', False) cacert = getattr(settings, 'OPENSTACK_SSL_CACERT', None) LOG.debug('novaclient connection created using token "%s" and url "%s"' % (request.user.token.id, base.url_for(request, 'compute'))) c = nova_client.Client(request.user.username, request.user.token.id, project_id=request.user.tenant_id, auth_url=base.url_for(request, 'compute'), insecure=insecure, cacert=cacert, http_log_debug=settings.DEBUG) c.client.auth_token = request.user.token.id c.client.management_url = base.url_for(request, 'compute') return c To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1380642/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:28:31 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:28:31 -0000 Subject: [Openstack-security] [Bug 1400872] Re: Show password feature should be configurable References: <20141209205525.24719.53334.malonedeb@wampee.canonical.com> Message-ID: <20150430082833.22464.40103.launchpad@soybean.canonical.com> ** Changed in: horizon Milestone: kilo-2 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1400872 Title: Show password feature should be configurable Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisories: Won't Fix Bug description: Horizon allows the password field to be displayed in plain text. This introduces a potential security risk. Imagine a user leaving their desktop unlock, if the user saved their password on the browser, a malicious user could go into the Login page and display the Openstack password. The show password feature should be made configurable for operators who wants a more secure deployment of Horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1400872/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:32:21 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:32:21 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150430083222.14051.60259.launchpad@chaenomeles.canonical.com> ** Changed in: horizon Milestone: kilo-3 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1420863 Title: Default setting should be secure Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack + Chef: Fix Released Bug description: Horizon has some instructions for setting it up in a secure way[1]. These settings should be the default. [1] http://docs.openstack.org/developer/horizon/topics/deployment.html #secure-site-recommendations To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1420863/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:37:33 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:37:33 -0000 Subject: [Openstack-security] [Bug 1260525] Re: Incomplete XSS fix for ossa/1247675 References: <20131212225614.8529.85762.malonedeb@gac.canonical.com> Message-ID: <20150430083734.16608.62565.launchpad@gac.canonical.com> ** Changed in: horizon Milestone: kilo-rc1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260525 Title: Incomplete XSS fix for ossa/1247675 Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisories: Invalid Bug description: The patch for https://bugs.launchpad.net/ossa/+bug/1247675 did not completely fix the reported issue. It failed to completely remove the use of html.strip_tags, which is not intended to be a security function, and does not properly sanitize output. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/tables.py#L254 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1260525/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:41:22 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:41:22 -0000 Subject: [Openstack-security] [Bug 1394988] Re: Hadoop with auto security group not working References: <20141121132920.28673.42565.malonedeb@wampee.canonical.com> Message-ID: <20150430084123.22725.83422.launchpad@soybean.canonical.com> ** Changed in: sahara Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1394988 Title: Hadoop with auto security group not working Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: Fix Released Bug description: ENV: OpenStack with Neutron Steps to reproduce: 1. Create cluster with auto security groups and two or more nodemanagers. 2. Launch pig job with 1Gb input data Result: After ~1 hour job in KILLED state. Reproduced with the following plugins: Vanilla 2 HDP 2 CDH To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1394988/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:41:56 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:41:56 -0000 Subject: [Openstack-security] [Bug 1393397] Re: Create Spark cluster with auto security group failed References: <20141117121325.31950.16947.malonedeb@soybean.canonical.com> Message-ID: <20150430084156.16856.1953.launchpad@gac.canonical.com> ** Changed in: sahara Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1393397 Title: Create Spark cluster with auto security group failed Status in OpenStack Data Processing (Sahara): Fix Released Bug description: Steps to reproduce: Create cluster with auto security groups. Result: Cluster in 'Error' state To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1393397/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:41:50 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:41:50 -0000 Subject: [Openstack-security] [Bug 1391520] Re: Create CDH cluster with auto security group failed References: <20141111134553.19455.35550.malonedeb@gac.canonical.com> Message-ID: <20150430084151.17724.90576.launchpad@gac.canonical.com> ** Changed in: sahara Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1391520 Title: Create CDH cluster with auto security group failed Status in OpenStack Data Processing (Sahara): Fix Released Status in Sahara juno series: Fix Released Bug description: Steps to reproduce: Create cluster with auto security groups. Result: Cluster in 'Configuring' state To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1391520/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 08:41:48 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 08:41:48 -0000 Subject: [Openstack-security] [Bug 1391518] Re: [HDP] Create HDP cluster with auto security group failed References: <20141111134355.14164.2244.malonedeb@wampee.canonical.com> Message-ID: <20150430084149.22567.34164.launchpad@soybean.canonical.com> ** Changed in: sahara Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1391518 Title: [HDP] Create HDP cluster with auto security group failed Status in OpenStack Data Processing (Sahara): Fix Released Bug description: Steps to reproduce: Create cluster with auto security groups. Result: Cluster in 'Configuring' state To manage notifications about this bug go to: https://bugs.launchpad.net/sahara/+bug/1391518/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 09:10:51 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 09:10:51 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150430091054.17060.70916.launchpad@gac.canonical.com> ** Changed in: nova Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 09:21:37 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 09:21:37 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150430092140.22977.89040.launchpad@soybean.canonical.com> ** Changed in: nova Milestone: kilo-3 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 09:31:25 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 09:31:25 -0000 Subject: [Openstack-security] [Bug 1382562] Re: security groups remote_group fails with CIDR in address pairs References: <20141017134212.4935.31773.malonedeb@wampee.canonical.com> Message-ID: <20150430093127.14248.22082.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1382562 Title: security groups remote_group fails with CIDR in address pairs Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron juno series: Fix Released Status in OpenStack Security Advisories: Won't Fix Bug description: Add a CIDR to allowed address pairs of a host. RPC calls from the agents will run into this issue now when retrieving the security group members' IPs. I haven't confirmed because I came across this working on other code, but I think this may stop all members of the security groups referencing that group from getting their rules over the RPC channel. File "neutron/api/rpc/handlers/securitygroups_rpc.py", line 75, in security_group_info_for_devices return self.plugin.security_group_info_for_ports(context, ports) File "neutron/db/securitygroups_rpc_base.py", line 202, in security_group_info_for_ports return self._get_security_group_member_ips(context, sg_info) File "neutron/db/securitygroups_rpc_base.py", line 209, in _get_security_group_member_ips ethertype = 'IPv%d' % netaddr.IPAddress(ip).version File "/home/administrator/code/neutron/.tox/py27/local/lib/python2.7/site-packages/netaddr/ip/__init__.py", line 281, in __init__ % self.__class__.__name__) ValueError: IPAddress() does not support netmasks or subnet prefixes! See documentation for details. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1382562/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 09:49:59 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 09:49:59 -0000 Subject: [Openstack-security] [Bug 1427228] Re: Allow to run neutron-ns-metadata-proxy as nobody References: <20150302135536.21027.11405.malonedeb@soybean.canonical.com> Message-ID: <20150430095000.14426.57460.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Milestone: kilo-rc1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1427228 Title: Allow to run neutron-ns-metadata-proxy as nobody Status in OpenStack Neutron (virtual network service): Fix Released Bug description: Currently neutron-ns-metadata-proxy runs with neutron user/group permissions on l3-agent but we should allow to run it with less permissions as neutron user is allowed to run neutron-rootwrap. We should restrict as much as possible neutron-ns-metadata-proxy permissions as it's reachable from VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1427228/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 09:56:18 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 09:56:18 -0000 Subject: [Openstack-security] [Bug 1384626] Re: SSL certification verification failed when Heat calls Glanceclient with ca cert References: <20141023090711.3131.60470.malonedeb@wampee.canonical.com> Message-ID: <20150430095620.14525.5498.launchpad@chaenomeles.canonical.com> ** Changed in: heat Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1384626 Title: SSL certification verification failed when Heat calls Glanceclient with ca cert Status in Orchestration API (Heat): Fix Released Status in heat juno series: Fix Released Bug description: Glance server is configured Https. Configured Heat with heat.conf [clients_glance] ca_file= insecure= When trying to create stack, heat will raise exception during heat to load image data. [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed The root cause is that: ca_file as below is a wrong argument to initialize the glance client, it should be cacert which is supported arguments by glanceclient. class GlanceClientPlugin(client_plugin.ClientPlugin): exceptions_module = exc def _create(self): con = self.context endpoint_type = self._get_client_option('glance', 'endpoint_type') endpoint = self.url_for(service_type='image', endpoint_type=endpoint_type) args = { 'auth_url': con.auth_url, 'service_type': 'image', 'project_id': con.tenant, 'token': self.auth_token, 'endpoint_type': endpoint_type, 'ca_file': self._get_client_option('glance', 'ca_file'), 'cert_file': self._get_client_option('glance', 'cert_file'), 'key_file': self._get_client_option('glance', 'key_file'), 'insecure': self._get_client_option('glance', 'insecure') To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1384626/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 09:50:19 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 09:50:19 -0000 Subject: [Openstack-security] [Bug 1372635] Re: MITM vulnerability with EMC VMAX driver References: <20140922201512.25143.9622.malonedeb@soybean.canonical.com> Message-ID: <20150430095021.22567.28480.launchpad@soybean.canonical.com> ** Changed in: cinder Milestone: kilo-3 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1372635 Title: MITM vulnerability with EMC VMAX driver Status in Cinder: Fix Released Status in Cinder icehouse series: New Status in Cinder juno series: New Status in OpenStack Security Advisories: Won't Fix Bug description: The EMC VMAX driver in Juno appears to blindly trust whatever certificate it gets back from the device without any validation (it does not specify the ca_certs parameter, etc. on WBEMConnection.__init__). This would leave it open to a MITM attack. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1372635/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 09:41:40 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 09:41:40 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150430094144.14688.52594.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Milestone: kilo-2 => 2015.1.0 ** Changed in: cinder Milestone: kilo-1 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 09:44:44 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 09:44:44 -0000 Subject: [Openstack-security] [Bug 1187107] Re: quantum-ns-metadata-proxy runs as root References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20150430094446.24911.92060.launchpad@wampee.canonical.com> ** Changed in: neutron Milestone: kilo-3 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1187107 Title: quantum-ns-metadata-proxy runs as root Status in OpenStack Neutron (virtual network service): Fix Released Bug description: # ps -ef | grep quantum-ns-metadata-proxy root 10239 1 0 19:01 ? 00:00:00 python /usr/bin/quantum-ns-metadata-proxy --pid_file=/var/lib/quantum/external/pids/7a44de32-3ac0-4f3e-92cc-1a37d8211db8.pid --router_id=7a44de32-3ac0-4f3e-92cc-1a37d8211db8 --state_path=/var/lib/quantum --debug --log-file=quantum-ns-metadata-proxy7a44de32-3ac0-4f3e-92cc-1a37d8211db8.log --log-dir=/var/log/quantum Root is needed to open the namespace, but the quantum-ns-metadata-proxy does not need root - it listens on 9697 by default not 80. I tried changing /etc/quantum/rootwrap.d/l3.filters for it to run as quantum instead: metadata_proxy: CommandFilter, /usr/bin/quantum-ns-metadata-proxy, quantum but it still runs as root. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1187107/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 10:05:30 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 10:05:30 -0000 Subject: [Openstack-security] [Bug 1406191] Re: node-show discloses credentials as plain text in driver_info References: <20141229065345.16652.7904.malonedeb@soybean.canonical.com> Message-ID: <20150430100531.16821.89163.launchpad@gac.canonical.com> ** Changed in: ironic Milestone: kilo-2 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1406191 Title: node-show discloses credentials as plain text in driver_info Status in OpenStack Bare Metal Provisioning Service (Ironic): Fix Released Bug description: [root at rhel7-vm ~]# ironic node-show b0860248-bf1d-4803-bdc3-5bb42852841c +------------------------+--------------------------------------------------------------------------+ | Property | Value | +------------------------+--------------------------------------------------------------------------+ | instance_uuid | bdaf5cc9-de8f-407e-890a-d4b6c1e3e602 | | target_power_state | None | | properties | {u'memory_mb': u'1024', u'cpu_arch': u'x86_64', u'local_gb': u'10', | | | u'cpus': u'1'} | | maintenance | False | | driver_info | {u'pxe_deploy_ramdisk': u'503e88d9-637c-4369-b8e0-2b2531c0eeb2', | | | u'ipmi_terminal_port': u'1234', u'ipmi_username': u'username', | | | u'ipmi_address': u'9.9.9.9', u'ipmi_password': u'password', | | | u'pxe_deploy_kernel': u'1e676e34-1294-4a17-afba-cd5c358cd314'} | | extra | {} | | last_error | None | | created_at | 2014-12-19T07:13:50+00:00 | | target_provision_state | deploy complete | | driver | pxe_ipmitool | | updated_at | 2014-12-29T04:52:29+00:00 | | instance_info | {u'ramdisk': u'b30a4441-b975-432d-8878-573de2aba297', u'kernel': u | | | '490b7edd-dfe9-4842-80ed-033c788b37d1', u'root_gb': u'10', | | | u'image_source': u'8d860e96-61f9-4070-8b09-4c8037c104c7', u'deploy_key': | | | u'2AX7KT8DXGU395SOA06J676YAC7AVA60', u'swap_mb': u'0'} | | chassis_uuid | | | provision_state | wait call-back | | reservation | None | | power_state | power on | | console_enabled | False | | uuid | b0860248-bf1d-4803-bdc3-5bb42852841c | +------------------------+--------------------------------------------------------------------------+ [root at rhel7-vm ~]# Log file will not show the password - 'ipmi_password': '' So can we hide the password in ironic client side? To manage notifications about this bug go to: https://bugs.launchpad.net/ironic/+bug/1406191/+subscriptions From 1118066 at bugs.launchpad.net Thu Apr 30 10:17:51 2015 From: 1118066 at bugs.launchpad.net (Mh Raies) Date: Thu, 30 Apr 2015 10:17:51 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20150430101751.23012.92170.malone@soybean.canonical.com> nova python client help tells that - root at devstack:/opt/stack/nova# nova help quota-show usage: nova quota-show [--tenant ] [--user ] List the quotas for a tenant/user. Optional arguments: --tenant ID of tenant to list the quotas for. --user ID of user to list the quotas for. root at devstack:/opt/stack/nova# Thus there is three possibilities - 1. Get quota filtered by user_id ==> get_user_quota 2. Get quota filtered by tenant_id ===> get_project_quota 3. Get quota filtered by user_id and tenant_id both ==> get_by_project_and_user Current quota api implementation treats only "get_user_quota" or current project. Need to enhance/modify to entertain remainings. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 12:42:05 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 12:42:05 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150430124206.14355.78147.launchpad@chaenomeles.canonical.com> ** Changed in: barbican/kilo Milestone: kilo-rc2 => 2015.1.0 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): Fix Committed Status in Barbican kilo series: Fix Released Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From vanderwl at us.ibm.com Thu Apr 30 13:15:18 2015 From: vanderwl at us.ibm.com (Mark Vanderwiel) Date: Thu, 30 Apr 2015 13:15:18 -0000 Subject: [Openstack-security] [Bug 1420863] Re: Default setting should be secure References: <20150211162312.25090.29300.malonedeb@chaenomeles.canonical.com> Message-ID: <20150430131520.14426.52905.launchpad@chaenomeles.canonical.com> ** Changed in: openstack-chef Milestone: None => kilo-rc1 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1420863 Title: Default setting should be secure Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack + Chef: Fix Released Bug description: Horizon has some instructions for setting it up in a secure way[1]. These settings should be the default. [1] http://docs.openstack.org/developer/horizon/topics/deployment.html #secure-site-recommendations To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1420863/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 13:15:44 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 13:15:44 -0000 Subject: [Openstack-security] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20150430131544.24585.81636.launchpad@wampee.canonical.com> ** Tags removed: kilo-rc-potential -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): In Progress Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From thierry.carrez+lp at gmail.com Thu Apr 30 13:15:55 2015 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 30 Apr 2015 13:15:55 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150430131556.22792.63852.launchpad@soybean.canonical.com> ** Tags removed: kilo-rc-potential -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From bknudson at us.ibm.com Thu Apr 30 13:28:42 2015 From: bknudson at us.ibm.com (Brant Knudson) Date: Thu, 30 Apr 2015 13:28:42 -0000 Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not released back to the pool leading to choking of new requests References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com> Message-ID: <20150430132844.14498.85288.launchpad@chaenomeles.canonical.com> ** Tags added: kilo-backport-potential -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1361360 Title: Eventlet green threads not released back to the pool leading to choking of new requests Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Released Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: In Progress Status in Orchestration API (Heat): In Progress Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Confirmed Status in Keystone juno series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in neutron juno series: Fix Committed Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: In Progress Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Data Processing (Sahara): Confirmed Bug description: Currently reproduced on Juno milestone 2. but this issue should be reproducible in all releases since its inception. It is possible to choke OpenStack API controller services using wsgi+eventlet library by simply not closing the client socket connection. Whenever a request is received by any OpenStack API service for example nova api service, eventlet library creates a green thread from the pool and starts processing the request. Even after the response is sent to the caller, the green thread is not returned back to the pool until the client socket connection is closed. This way, any malicious user can send many API requests to the API controller node and determine the wsgi pool size configured for the given service and then send those many requests to the service and after receiving the response, wait there infinitely doing nothing leading to disrupting services for other tenants. Even when service providers have enabled rate limiting feature, it is possible to choke the API services with a group (many tenants) attack. Following program illustrates choking of nova-api services (but this problem is omnipresent in all other OpenStack API Services using wsgi+eventlet) Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py. After you run the below program, you should try to invoke API ============================================================================================ import time import requests from multiprocessing import Process def request(number): #Port is important here path = 'http://127.0.0.1:8774/servers' try: response = requests.get(path) print "RESPONSE %s-%d" % (response.status_code, number) #during this sleep time, check if the client socket connection is released or not on the API controller node. time.sleep(1000) print “Thread %d complete" % number except requests.exceptions.RequestException as ex: print “Exception occurred %d-%s" % (number, str(ex)) if __name__ == '__main__': processes = [] for number in range(40): p = Process(target=request, args=(number,)) p.start() processes.append(p) for p in processes: p.join() ================================================================================================ Presently, the wsgi server allows persist connections if you configure keepalive to True which is default. In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server. Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter. For example. Keep-Alive: timeout=10, max=5 Note: After we have disabled keepalive in all the OpenStack API service using wsgi library, then it might impact all existing applications built with the assumptions that OpenStack API services uses persistent connections. They might need to modify their applications if reconnection logic is not in place and also they might experience the performance has slowed down as it will need to reestablish the http connection for every request. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1361360/+subscriptions From bknudson at us.ibm.com Thu Apr 30 15:43:21 2015 From: bknudson at us.ibm.com (Brant Knudson) Date: Thu, 30 Apr 2015 15:43:21 -0000 Subject: [Openstack-security] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20150430154322.22259.44171.launchpad@soybean.canonical.com> ** Tags added: kilo-backport-potential -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): In Progress Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From bknudson at us.ibm.com Thu Apr 30 15:47:38 2015 From: bknudson at us.ibm.com (Brant Knudson) Date: Thu, 30 Apr 2015 15:47:38 -0000 Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user attribute in k2k assertions with different domains References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com> Message-ID: <20150430154739.16570.36691.launchpad@gac.canonical.com> ** Tags added: kilo-backport-potential -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): In Progress Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions From nkinder at redhat.com Thu Apr 30 17:22:30 2015 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 30 Apr 2015 17:22:30 -0000 Subject: [Openstack-security] [Bug 1414532] Re: asserts used in cache.py References: <20150126041237.12665.35620.malonedeb@soybean.canonical.com> Message-ID: <20150430172230.14525.64139.malone@chaenomeles.canonical.com> This has been published as OSSN-0048: https://wiki.openstack.org/wiki/OSSN/OSSN-0048 ** Changed in: ossn Status: New => Fix Released -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1414532 Title: asserts used in cache.py Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: The asserts in the snippet below check at #2 to see if the HTTP method match the HTTP methods actually specified in the patterns at #1. /opt/stack/glance/glance/api/middleware/cache.py PATTERNS = { <--- #1 ('v1', 'GET'): re.compile(r'^/v1/images/([^\/]+)$'), ('v1', 'DELETE'): re.compile(r'^/v1/images/([^\/]+)$'), ('v2', 'GET'): re.compile(r'^/v2/images/([^\/]+)/file$'), ('v2', 'DELETE'): re.compile(r'^/v2/images/([^\/]+)$') } ... @staticmethod def _match_request(request): """Determine the version of the url and extract the image id :returns tuple of version and image id if the url is a cacheable, otherwise None """ for ((version, method), pattern) in PATTERNS.items(): match = pattern.match(request.path_info) try: assert request.method == method <--- #2 image_id = match.group(1) # Ensure the image id we got looks like an image id to filter # out a URI like /images/detail. See LP Bug #879136 assert image_id != 'detail' except (AttributeError, AssertionError): continue else: return (version, method, image_id) As stated in the Python documentation assert statements will not be evaluated when the Python code is compiled with optimization flags. This means that these checks will not be properly executed and one can in that case call a specific method with a completely different HTTP verb. This can result in security issues. For example think of having some filtering in place in front of the glance API to maybe allow only certain API queries to come from certain IP addresses. For example: 'the HTTP verb DELETE may only be executed from this IP range'. An attacker can now specify a completely different HTTP verb such as GET and make sure he still matches regular expressions at #1 and then bypass the firewall. It's a bit of a hypothetical scenario but in general one should never ever do error checking with assert statemetns. This should only be done for things which can never realistically fail and that is simply not an assumption one can hold when it comes to untrusted input from the network. For more information see https://docs.python.org/2/reference/simple_stmts.html#the-assert-statement and https://docs.python.org/2/using/cmdline.html#envvar-PYTHONOPTIMIZE This seems to be related to https://bugs.launchpad.net/cinder/+bug/1199354 but it's not fixed and maybe it should even be a security issue hence why I reported it again and tagged as a security vulnerability. I am not familiar enough with the code base to make that call. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1414532/+subscriptions From gerrit2 at review.openstack.org Thu Apr 30 18:13:58 2015 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 30 Apr 2015 18:13:58 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I3c66e92cbe8883dcad843ad243388def3a96dbe5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/157097 Log: commit d3983b63d2d4cf920c241490d1de898186c4936d Author: Juergen Brendel Date: Thu Feb 26 13:51:04 2015 +1300 ARP spoofing patch: Data structures for rules. ARP cache poisoning is not actually prevented by the firewall driver 'iptables_firewall'. We are adding the use of the ebtables command - with a corresponding ebtables-driver - in order to create Ethernet frame filtering rules, which prevent the sending of ARP cache poisoning frames. The complete patch is broken into smaller patch sets for easier review. This patch set here includes the some classes for the maintenance of ebtable chains and rules. Note: This commit is based greatly on an original, now abandoned patch, presented for review here: https://review.openstack.org/#/c/70067/ Full spec can be found here: https://review.openstack.org/#/c/129090/ SecurityImpact Change-Id: I3c66e92cbe8883dcad843ad243388def3a96dbe5 Implements: blueprint arp-spoof-patch-ebtables Related-Bug: 1274034 Co-Authored-By: jbrendel From rodrigodsousa at gmail.com Wed Apr 15 14:11:02 2015 From: rodrigodsousa at gmail.com (Rodrigo Duarte) Date: Wed, 15 Apr 2015 14:11:02 -0000 Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user attribute in k2k assertions with different domains References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com> Message-ID: <20150415140413.30454.38381.malone@gac.canonical.com> Ok, thanks for clarifying the difference! Will add the security tag. ** Information type changed from Public Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): In Progress Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions From rodrigodsousa at gmail.com Wed Apr 15 14:11:03 2015 From: rodrigodsousa at gmail.com (Rodrigo Duarte) Date: Wed, 15 Apr 2015 14:11:03 -0000 Subject: [Openstack-security] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20150415140511.21857.25663.launchpad@soybean.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): In Progress Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From rodrigodsousa at gmail.com Thu Apr 16 16:55:42 2015 From: rodrigodsousa at gmail.com (Rodrigo Duarte) Date: Thu, 16 Apr 2015 16:55:42 -0000 Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user attribute in k2k assertions with different domains References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com> Message-ID: <20150416164917.11339.23008.malone@wampee.canonical.com> created a spec for this new attributes: https://review.openstack.org/#/c/174462/ -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): In Progress Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions From rodrigodsousa at gmail.com Thu Apr 16 16:55:43 2015 From: rodrigodsousa at gmail.com (Rodrigo Duarte) Date: Thu, 16 Apr 2015 16:55:43 -0000 Subject: [Openstack-security] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20150416164856.21957.84249.malone@soybean.canonical.com> created a spec for this new attributes: https://review.openstack.org/#/c/174462/ -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): In Progress Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From dikonoor at in.ibm.com Fri Apr 17 06:20:45 2015 From: dikonoor at in.ibm.com (Divya K Konoor) Date: Fri, 17 Apr 2015 06:20:45 -0000 Subject: [Openstack-security] [Bug 1445335] [NEW] create/delete flavor permissions should be controlled by policy.json References: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Message-ID: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Public bug reported: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor ** Affects: nova Importance: High Assignee: Divya K Konoor (dikonoor) Status: Confirmed ** Tags: kilo-rc-potential nova security ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445335 Title: create/delete flavor permissions should be controlled by policy.json Status in OpenStack Compute (Nova): Confirmed Bug description: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1445335/+subscriptions From soulxu at gmail.com Fri Apr 17 06:25:40 2015 From: soulxu at gmail.com (Alex Xu) Date: Fri, 17 Apr 2015 06:25:40 -0000 Subject: [Openstack-security] [Bug 1445335] Re: create/delete flavor permissions should be controlled by policy.json References: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Message-ID: <20150417061658.13822.18327.malone@chaenomeles.canonical.com> This is the regression, the original patch assume the user request's context is pass down to the db call. But actually it is not, the code always pass fake admin context. So should fix it to keep the v2 API behavor as before. And it should be backport to Kilo ** Changed in: nova Importance: Undecided => High ** Tags added: kilo-rc-potential -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445335 Title: create/delete flavor permissions should be controlled by policy.json Status in OpenStack Compute (Nova): Confirmed Bug description: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1445335/+subscriptions From dikonoor at in.ibm.com Fri Apr 17 06:25:43 2015 From: dikonoor at in.ibm.com (Divya K Konoor) Date: Fri, 17 Apr 2015 06:25:43 -0000 Subject: [Openstack-security] [Bug 1445335] Re: create/delete flavor permissions should be controlled by policy.json References: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Message-ID: <20150417061929.14106.38918.launchpad@wampee.canonical.com> ** Changed in: nova Assignee: (unassigned) => Divya K Konoor (dikonoor) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445335 Title: create/delete flavor permissions should be controlled by policy.json Status in OpenStack Compute (Nova): Confirmed Bug description: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1445335/+subscriptions From ndipanov at redhat.com Mon Apr 20 13:25:50 2015 From: ndipanov at redhat.com (=?utf-8?q?Nikola_=C4=90ipanov?=) Date: Mon, 20 Apr 2015 13:25:50 -0000 Subject: [Openstack-security] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) References: <20150109220130.23970.7685.malonedeb@gac.canonical.com> Message-ID: <20150420131554.16199.75530.malone@soybean.canonical.com> It is also worth noting here for future reference that the above 2 patches: https://review.openstack.org/169752 https://review.openstack.org/169753 are relevant to Kilo only (they will not be backported to previous releases). In Kilo it will no longer be needed to keep the novncproxy_base_url options in sync between compute and novncproxy services. This is because the URL a token was authorized for will be kept alongside other authorization info. However there is a caveat to the way upgrades need to be done for Juno to Kilo (it copied here from the original commit message): UpgradeImpact: Websocket proxies need to be upgraded in a lockstep with the API nodes up to this commit (or when upgrading to Kilo), as older API nodes will not be sending the access_url when authorizing console access, and newer proxy services (this commit and onward) would fail to authorize such requests. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1409142 Title: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259) Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) icehouse series: Fix Released Status in OpenStack Compute (nova) juno series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: OpenStack Vulnerability Team: Brian Manifold (bmanifol at cisco.com) from Cisco has discovered a vulnerability in the Nova VNC server implementation. We have a patch for this vulnerability and consider this a very high risk. Please email Dave McCowan (dmccowan at cisco.com) for more details on the attached patch. Issue Details: Horizon uses a VNC client which uses websockets to pass information. The Nova VNC server does not validate the origin of the websocket request, which allows an attacker to make a websocket request from another domain. If the victim opens both an attacker's site and the VNC console simultaneously, or if the victim has recently been using the VNC console and then visits the attacker's site, the attacker can make a websocket request to the Horizon domain and proxy the connection to another destination. This gives the attacker full read-write access to the VNC console of any instance recently accessed by the victim. Recommendation:  Verify the origin field in request header on all websocket requests. Threat:       CWE-345  * Insufficient Verification of Data Authenticity -- The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.       CWE-346  * Origin Validation Error -- The software does not properly verify that the source of data or communication is valid.       CWE-441  * Unintended Proxy or Intermediary ('Confused Deputy') -- The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Steps to reproduce:  1. Login to horizon  2. Pick an instance, go to console/vnc tab, wait for console to be loaded  3. In another browser tab or window, load a VNC console script from local disk or remote site  4. Point the newly loaded VNC console to the VNC server and a connection is made Result:  The original connection has been been hijacked by the second connection Root cause:  Cross-Site WebSocket Hijacking is concept that has been written about in various security blogs. One of the recommended countermeasures is to check the Origin header of the WebSocket handshake request. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions From dikonoor at in.ibm.com Tue Apr 21 05:25:41 2015 From: dikonoor at in.ibm.com (Divya K Konoor) Date: Tue, 21 Apr 2015 05:25:41 -0000 Subject: [Openstack-security] [Bug 1445335] Re: create/delete flavor permissions should be controlled by policy.json References: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Message-ID: <20150421051957.32033.67692.malone@gac.canonical.com> Jeremy , this bug does not cause security vulnerability. I am a bit new to using launchpad (I am not sure if the security tag addition was the cause ) . This defect merely overrides the flexibility to apply/control permissions associated with flavor rest api and mandates that only a user with admin permissions can make these calls. -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445335 Title: create/delete flavor permissions should be controlled by policy.json Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Incomplete Bug description: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1445335/+subscriptions From 1445335 at bugs.launchpad.net Tue Apr 21 06:35:42 2015 From: 1445335 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 21 Apr 2015 06:35:42 -0000 Subject: [Openstack-security] [Bug 1445335] Re: create/delete flavor permissions should be controlled by policy.json References: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Message-ID: <20150421062857.31936.91352.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/175739 ** Changed in: nova Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445335 Title: create/delete flavor permissions should be controlled by policy.json Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Incomplete Bug description: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1445335/+subscriptions From soulxu at gmail.com Tue Apr 21 06:45:49 2015 From: soulxu at gmail.com (Alex Xu) Date: Tue, 21 Apr 2015 06:45:49 -0000 Subject: [Openstack-security] [Bug 1445335] Re: create/delete flavor permissions should be controlled by policy.json References: <20150417061052.16946.96314.malonedeb@soybean.canonical.com> Message-ID: <20150421063602.13514.47235.malone@wampee.canonical.com> Yes, this isn't cause security vulnerability. We just add hard- permission checks in the v2 API, that make the flavor api is unconfiguable by policy.json. We just need remove the hard-code permission checks. ** Changed in: ossa Status: Incomplete => Invalid ** Tags removed: security -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1445335 Title: create/delete flavor permissions should be controlled by policy.json Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Advisories: Invalid Bug description: The create/delete flavor rest api always expects the user to be of admin privileges and ignores the rule defined in the nova/policy.json. This behavior is observed after these changes >> https://review.openstack.org/#/c/150352/. The expected behavior is that the permissions are controlled as per the rule defined in the policy file and should not mandate that only an admin should be able to create/delete a flavor To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1445335/+subscriptions From 1446406 at bugs.launchpad.net Tue Apr 21 20:56:13 2015 From: 1446406 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 21 Apr 2015 20:56:13 -0000 Subject: [Openstack-security] [Bug 1446406] Related fix proposed to barbican (master) References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150421205613.32383.86183.malone@gac.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/176071 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): Confirmed Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From 1446406 at bugs.launchpad.net Wed Apr 22 15:44:22 2015 From: 1446406 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 22 Apr 2015 15:44:22 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150422154424.13756.89584.launchpad@chaenomeles.canonical.com> ** Changed in: barbican Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): In Progress Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From 1434034 at bugs.launchpad.net Thu Apr 23 16:48:57 2015 From: 1434034 at bugs.launchpad.net (Robert Clark) Date: Thu, 23 Apr 2015 16:48:57 -0000 Subject: [Openstack-security] [Bug 1434034] Re: Disabling users & groups may not invalidate previously-issued tokens References: <20150319111325.13509.80712.malonedeb@wampee.canonical.com> Message-ID: <20150423164857.27833.37852.malone@gac.canonical.com> Is this caching similar to OSSN-0032? https://wiki.openstack.org/wiki/OSSN/OSSN-0032 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1434034 Title: Disabling users & groups may not invalidate previously-issued tokens Status in OpenStack Identity (Keystone): In Progress Status in Keystone juno series: In Progress Status in OpenStack Security Advisories: Confirmed Status in OpenStack Security Notes: New Bug description: Even if the user is disabled, can use the last token is validated. 0. user foo is enable 1. get token (a) 2. user foo is disabled 3. foo can still use any APIs by token(a) that's all. This issue is not cache process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1434034/+subscriptions From 1446406 at bugs.launchpad.net Fri Apr 24 18:24:05 2015 From: 1446406 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 24 Apr 2015 18:24:05 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150424182406.13756.92889.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/176071 Committed: https://git.openstack.org/cgit/openstack/barbican/commit/?id=dce0c6922062a700a2de1fee9319421cc7d8288e Submitter: Jenkins Branch: master commit dce0c6922062a700a2de1fee9319421cc7d8288e Author: Charles Neill Date: Tue Apr 21 15:49:20 2015 -0500 Removing signing_dir directive from config The signing_dir directive defined in barbican-api-paste.ini explicitly stores Keystone's signing certificates in a known /tmp directory. This could be exploited by populating the directory with bogus certificates, potentially allowing a malicious user to generate valid tokens. Added comment explaining signing_dir, and a reasonable (commented) default. Change-Id: I15fda6863e888e3881694ab47a836eee2fb578ee Closes-Bug: #1446406 ** Changed in: barbican Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): Fix Committed Status in Barbican kilo series: In Progress Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From 1446406 at bugs.launchpad.net Fri Apr 24 18:30:27 2015 From: 1446406 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 24 Apr 2015 18:30:27 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150424183027.13861.37088.malone@wampee.canonical.com> Fix proposed to branch: stable/kilo Review: https://review.openstack.org/177378 ** Changed in: barbican/kilo Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): Fix Committed Status in Barbican kilo series: In Progress Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From 1446406 at bugs.launchpad.net Mon Apr 27 08:58:55 2015 From: 1446406 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 27 Apr 2015 08:58:55 -0000 Subject: [Openstack-security] [Bug 1446406] Re: Insecure signing_dir configuration in barbican-api-paste.ini References: <20150420223742.32593.66588.malonedeb@gac.canonical.com> Message-ID: <20150427085855.22227.62316.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/177378 Committed: https://git.openstack.org/cgit/openstack/barbican/commit/?id=46184bb4b3a81e503a9e4aff4ba9ea0a66061a16 Submitter: Jenkins Branch: stable/kilo commit 46184bb4b3a81e503a9e4aff4ba9ea0a66061a16 Author: Charles Neill Date: Tue Apr 21 15:49:20 2015 -0500 Removing signing_dir directive from config The signing_dir directive defined in barbican-api-paste.ini explicitly stores Keystone's signing certificates in a known /tmp directory. This could be exploited by populating the directory with bogus certificates, potentially allowing a malicious user to generate valid tokens. Added comment explaining signing_dir, and a reasonable (commented) default. Change-Id: I15fda6863e888e3881694ab47a836eee2fb578ee Closes-Bug: #1446406 ** Changed in: barbican/kilo Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1446406 Title: Insecure signing_dir configuration in barbican-api-paste.ini Status in OpenStack Key Management (Barbican): Fix Committed Status in Barbican kilo series: Fix Committed Bug description: It appears that Barbican sets signing_dir to "/tmp/barbican/cache" in etc/barbican/barbican-api-paste.ini (Reference: https://github.com/openstack/barbican/blob/master/etc/barbican /barbican-api-paste.ini#L42) A Nova bug from 2013 (https://bugs.launchpad.net/nova/+bug/1174608) mentions that they had the same basic issue, and it's a security issue because: "This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused*" This Nova bug was issued CVE-2013-2030: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2013-2030 This was originally reported to Barbican devs by the user "zigo" in the #openstack-barbican channel on Freenode: 2015-03-23 16:59:15 zigo_ I just saw in barbican-api-paste.ini a "signing_dir" directive. This is a security issue which you guys need to fix. 2015-03-23 16:59:28 zigo_ The signing_dir directive should never be set to /tmp like this. 2015-03-23 16:59:33 zigo_ Best is to simply remove the directive. 2015-03-23 16:59:57 zigo_ I can find the announce for the nova security patch that happened a few years ago if you don't just trust my words… :) zigo's suggested fix was to remove the directive. It appears Cinder has taken this approach for their project (https://bugs.launchpad.net/cinder/+bug/1185098) To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1446406/+subscriptions From 1442787 at bugs.launchpad.net Thu Apr 30 09:10:00 2015 From: 1442787 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 30 Apr 2015 09:10:00 -0000 Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user attribute in k2k assertions with different domains References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com> Message-ID: <20150430091001.24385.32634.launchpad@wampee.canonical.com> ** Changed in: keystone Assignee: Rodrigo Duarte (rodrigodsousa) => Marek Denis (marek-denis) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): In Progress Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions From 1442343 at bugs.launchpad.net Thu Apr 30 17:39:57 2015 From: 1442343 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 30 Apr 2015 17:39:57 -0000 Subject: [Openstack-security] [Bug 1442343] Re: Mapping openstack_project attribute in k2k assertions with different domains References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20150430173957.22358.20222.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/172536 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=fa844bc88edb417f9513d19c749886a61d7b26ce Submitter: Jenkins Branch: master commit fa844bc88edb417f9513d19c749886a61d7b26ce Author: Rodrigo Duarte Sousa Date: Fri Apr 10 14:59:34 2015 -0300 Add openstack_project_domain to assertion Currently, a keystone IdP does not provide the domain of the project when generating SAML assertions. Since it is possible to have two projects with the same name but in different domains, this patch adds an additional attribute called "openstack_project_domain" in the assertion to identify the domain of the project. Closes-Bug: 1442343 bp assertion-extra-attributes Change-Id: I62ed73d87f268c73294738845421deb87088326b ** Changed in: keystone Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): Fix Committed Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From 1442787 at bugs.launchpad.net Thu Apr 30 18:11:11 2015 From: 1442787 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 30 Apr 2015 18:11:11 -0000 Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user attribute in k2k assertions with different domains References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com> Message-ID: <20150430181112.16570.95036.launchpad@gac.canonical.com> ** Changed in: keystone Assignee: Marek Denis (marek-denis) => Rodrigo Duarte (rodrigodsousa) -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442787 Title: Mapping openstack_user attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): In Progress Bug description: We can have two users with the same username in different domains. So if we have a "User A" in "Domain X" and a "User A" in "Domain Y", there is no way to differ what "User A" is being used in a SAML assertion generated by this IdP (we have only the openstack_user attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442787/+subscriptions From 1442343 at bugs.launchpad.net Thu Apr 30 18:17:33 2015 From: 1442343 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 30 Apr 2015 18:17:33 -0000 Subject: [Openstack-security] [Bug 1442343] Fix proposed to keystone (stable/kilo) References: <20150409195425.7552.82346.malonedeb@chaenomeles.canonical.com> Message-ID: <20150430181733.14144.7332.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/kilo Review: https://review.openstack.org/179195 -- You received this bug notification because you are a member of OpenStack Security, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1442343 Title: Mapping openstack_project attribute in k2k assertions with different domains Status in OpenStack Identity (Keystone): Fix Committed Bug description: We can have two projects with the same name in different domains. So if we have a "Project A" in "Domain X" and a "Project A" in "Domain Y", there is no way to differ what "Project A" is being used in a SAML assertion generated by this IdP (we have only the openstack_project attribute in the SAML assertion). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1442343/+subscriptions From carol.l.barrett at intel.com Thu Apr 30 22:19:24 2015 From: carol.l.barrett at intel.com (Barrett, Carol L) Date: Thu, 30 Apr 2015 22:19:24 +0000 Subject: [Openstack-security] [OpenStack][Product Work Group] [Enterprise][API][Telco][Dev] [Security][Operators][Marketing][User Committee] Cross-Project Vancouver Work Session Message-ID: <2D352D0CD819F64F9715B1B89695400D5C75DA32@ORSMSX113.amr.corp.intel.com> The Product Work Group has formed to listen and aggregate feedback on the desired capabilities for the OpenStack platform from Customers, Users and the Developer Community (including PTLs). Using this feedback we intent to help PTLs and Contributors resolve issues that are either of strategic importance or have broad implications across OpenStack services that will help customers/users be successful with adoption by removing barriers to adoption/operation. To achieve this goal, we are striving to create a multi-release OpenStack roadmap based upon the aggregated information through an open, transparent, cross-community collaboration. In a working session at the Vancouver Summit, we'd like to refine and finalize our approach to creating this roadmap. This session will be on Monday, May 18th 3:40 - 4:40 in Room 212. We'd like to understand what work groups, user groups or community members are interested in joining us for this session. Please go to this etherpad (https://etherpad.openstack.org/p/ProductWG_xProjectSession) to tell us who you are and what you're area of interest is and help shape the agenda for the session. You can find more information about the Product work group here: https://wiki.openstack.org/wiki/ProductTeam We look forward to meeting with you in Vancouver. -------------- next part -------------- An HTML attachment was scrubbed... URL: