From kesten.broughton at gmail.com Sun Jun 1 18:01:43 2014 From: kesten.broughton at gmail.com (kesten broughton) Date: Sun, 1 Jun 2014 13:01:43 -0500 Subject: [Openstack-security] Preferred os for rapid security patches of openstack Message-ID: Is there any difference in the rate at which security patches get applied between os's. In particular, i'm trying to compare centos 6.5 vs ubuntu 14.04. What is the process through which security-only patches get passed on to production deployments of openstack. Is there a difference in the amount of coverage testing for security services between os's? kesten On Sun, Jun 1, 2014 at 7:00 AM, < openstack-security-request at lists.openstack.org> wrote: > Send Openstack-security mailing list submissions to > openstack-security at lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > or, via email, send a message with subject or body 'help' to > openstack-security-request at lists.openstack.org > > You can reach the person managing the list at > openstack-security-owner at lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Openstack-security digest..." > > > Today's Topics: > > 1. [Bug 1260679] Re: Multiple drivers set insecure file > permissions (Nathan Kinder) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 31 May 2014 15:39:21 -0000 > From: Nathan Kinder > To: openstack-security at lists.openstack.org > Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set > insecure file permissions > Message-ID: > <20140531153922.20634.22748.malone at chaenomeles.canonical.com> > Content-Type: text/plain; charset="utf-8" > > Published as OSSN-0014 on the wiki and the openstack and openstack-dev > mailing lists: > > https://wiki.openstack.org/wiki/OSSN/OSSN-0014 > > ** Changed in: ossn > Status: In Progress => Fix Released > > -- > You received this bug notification because you are a member of OpenStack > Security Group, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1260679 > > Title: > Multiple drivers set insecure file permissions > > Status in Cinder: > In Progress > Status in OpenStack Security Notes: > Fix Released > > Bug description: > GPFS from various places calls "chmod 666" as root: > > ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', > path, run_as_root=True) > ./cinder/volume/drivers/gpfs.py: self._execute('chmod', > '666', vol_path, run_as_root=True) > > the Huawei driver sets 777 permissions as root on some files: > > ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', > '777', filepath, run_as_root=True) > ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', > '777', filepath, run_as_root=True) > > the Scality driver sets 666 permissions on all volumes: > > cinder/volume/drivers/scality.py: > > ????def _create_file(self, path, size): > ????????with open(path, "ab") as f: > ????????????f.truncate(size) > ????????os.chmod(path, 0o666) > > Similarly, the NFS and NEXENTA driver have an implementation of > > def _set_rw_permissions_for_all() > > that is being called on all newly created volumes. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cinder/+bug/1260679/+subscriptions > > > > ------------------------------ > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > End of Openstack-security Digest, Vol 16, Issue 1 > ************************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kseifried at redhat.com Sun Jun 1 18:36:56 2014 From: kseifried at redhat.com (Kurt Seifried) Date: Sun, 01 Jun 2014 12:36:56 -0600 Subject: [Openstack-security] Preferred os for rapid security patches of openstack In-Reply-To: References: Message-ID: <538B72C8.4080602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/01/2014 12:01 PM, kesten broughton wrote: > Is there any difference in the rate at which security patches get > applied between os's. In particular, i'm trying to compare centos > 6.5 vs ubuntu 14.04. > > What is the process through which security-only patches get passed > on to production deployments of openstack. > > Is there a difference in the amount of coverage testing for > security services between os's? > > kesten > > Are you talking about security patches to OpenStack itself? I assume you're not talking about the underlying operating system. Any ways if this is OpenStack specific then my next question would be: how did you install OpenStack on CentOS/Ubuntu? For CentOS your choices would be - From upstream source - From EPEL - From RDO - From something else? All of which of course have different patching schedules/rates. My advice would be to pick say the last two dozen CVEs and then research when they were fixed in each distribution and compare and you'll have your answer. - -- Kurt Seifried - Red Hat - Product Security - Cloud stuff and such PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTi3LIAAoJEBYNRVNeJnmT+hEQANOCLOKvZPxAOKUuFLByJ1kR sexTlmdayf7oIrTalJcncoG3nh8AbSahRE82X8ijVXMGTqB3kdN1MSBg/V2r7M2b +D4ErmQ41KkvmKgduIpsn356ExP+Rpas3CcvIJjU2KaD423o+kzDhjqtEqab1Bqb smRMEgsQ2PCENCiRMnqPkwAdi8odUAb0LeTyAAqJvn6a2uCZznnVDCI53+Camx1/ DMNpfiZXaLdmlOeyTJl8qYnunfTvXvRPqH5u1n6pCGy/lz6Pmsr0Sarx474HIfDg orz/S22HFptf/moYPx009nav1E1ItfzdvkwZ5ZdczzhKQMHfLaoYjQkhwl8FuAXg JAwYR2n1pajF5LgkUm6w0XbfkmpDXRVUo+dgIkn5MiYaY2NfD28p8bZ/WPOupDku knz6trH2VvmMlwvnPe/aDH6sHO2G1OQxD1uWNu+TWcp2ktGnCnoba9DN8Awl7dc6 aHY3EpTfTDKJhiKdGIcBwO5soR9DwyokLYtFsYMkRoOXEoh+TtfPCEgIx/hti7X6 T1aX76fyRxCzk/UmXUmqmZYeQLI0xHmVMQx5DFEjrPJLu3Ae0/Iy9UhzBgyzDt9Y b6B3WOdY7ZYCG3FeBl9MQ+/qBJWddzqtE8nHJRQ5971hABNEz+MH5HYnN0Envvs7 cNUqZIPTqqNjLtU0B0lK =wn/M -----END PGP SIGNATURE----- From kesten.broughton at gmail.com Sun Jun 1 21:45:01 2014 From: kesten.broughton at gmail.com (kesten broughton) Date: Sun, 1 Jun 2014 16:45:01 -0500 Subject: [Openstack-security] Preferred os for rapid security patches of openstack In-Reply-To: <538B72C8.4080602@redhat.com> References: <538B72C8.4080602@redhat.com> Message-ID: Yes, my interest is in patches for openstack modules. We use the EPEL repos. "pick say the last two dozen CVEs and then research when they were fixed in each distribution and compare and you'll have your answer." Was that advice tounge-in-cheek? ;) I picked one, and spent an hour looking for decent sources. I'm looking for either archive or CSV format that includes both the patch release date and the CVE. I picked CVE-2014-0162 I was hoping someone had already done the work for me like this analysis of rhel variants: Lag for centos behind rhel patch releases http://bitrate.epipe.com/rhel-vs-centos-scientific-oracle-linux-6_187 Comparing centos to ubuntu is problematic since the centos announce list does not include the CVE or bug description. Ubuntu has archives here http://people.canonical.com/~ubuntu-security/cve/ But the bug i picked wasn't there. I had to google around to find it here. http://www.ubuntuupdates.org/package/core/saucy/main/updates/glance debian has bundled files, with CVE's but no dates, only release numbers https://security-tracker.debian.org/tracker/ I was only able to find nice stats with everything i needed for Redhat. http://www.redhat.com/security/data/metrics/ If i'm missing any links to make this info more accessible please let me know. Otherwise, 2 dozen comparisons might take a day or two. kesten On Sun, Jun 1, 2014 at 1:36 PM, Kurt Seifried wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/01/2014 12:01 PM, kesten broughton wrote: > > Is there any difference in the rate at which security patches get > > applied between os's. In particular, i'm trying to compare centos > > 6.5 vs ubuntu 14.04. > > > > What is the process through which security-only patches get passed > > on to production deployments of openstack. > > > > Is there a difference in the amount of coverage testing for > > security services between os's? > > > > kesten > > > > > > Are you talking about security patches to OpenStack itself? I assume > you're not talking about the underlying operating system. Any ways if > this is OpenStack specific then my next question would be: > > how did you install OpenStack on CentOS/Ubuntu? For CentOS your > choices would be > > - From upstream source > - From EPEL > - From RDO > - From something else? > > All of which of course have different patching schedules/rates. My > advice would be to pick say the last two dozen CVEs and then research > when they were fixed in each distribution and compare and you'll have > your answer. > > - -- > Kurt Seifried - Red Hat - Product Security - Cloud stuff and such > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJTi3LIAAoJEBYNRVNeJnmT+hEQANOCLOKvZPxAOKUuFLByJ1kR > sexTlmdayf7oIrTalJcncoG3nh8AbSahRE82X8ijVXMGTqB3kdN1MSBg/V2r7M2b > +D4ErmQ41KkvmKgduIpsn356ExP+Rpas3CcvIJjU2KaD423o+kzDhjqtEqab1Bqb > smRMEgsQ2PCENCiRMnqPkwAdi8odUAb0LeTyAAqJvn6a2uCZznnVDCI53+Camx1/ > DMNpfiZXaLdmlOeyTJl8qYnunfTvXvRPqH5u1n6pCGy/lz6Pmsr0Sarx474HIfDg > orz/S22HFptf/moYPx009nav1E1ItfzdvkwZ5ZdczzhKQMHfLaoYjQkhwl8FuAXg > JAwYR2n1pajF5LgkUm6w0XbfkmpDXRVUo+dgIkn5MiYaY2NfD28p8bZ/WPOupDku > knz6trH2VvmMlwvnPe/aDH6sHO2G1OQxD1uWNu+TWcp2ktGnCnoba9DN8Awl7dc6 > aHY3EpTfTDKJhiKdGIcBwO5soR9DwyokLYtFsYMkRoOXEoh+TtfPCEgIx/hti7X6 > T1aX76fyRxCzk/UmXUmqmZYeQLI0xHmVMQx5DFEjrPJLu3Ae0/Iy9UhzBgyzDt9Y > b6B3WOdY7ZYCG3FeBl9MQ+/qBJWddzqtE8nHJRQ5971hABNEz+MH5HYnN0Envvs7 > cNUqZIPTqqNjLtU0B0lK > =wn/M > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kseifried at redhat.com Mon Jun 2 01:17:36 2014 From: kseifried at redhat.com (Kurt Seifried) Date: Sun, 01 Jun 2014 19:17:36 -0600 Subject: [Openstack-security] Preferred os for rapid security patches of openstack In-Reply-To: References: <538B72C8.4080602@redhat.com> Message-ID: <538BD0B0.8080803@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/01/2014 03:45 PM, kesten broughton wrote: > Yes, my interest is in patches for openstack modules. We use the > EPEL repos. > > "pick say the last two dozen CVEs and then research when they were > fixed in each distribution and compare and you'll have your > answer." > > Was that advice tounge-in-cheek? ;) > > I picked one, and spent an hour looking for decent sources. I'm > looking for either archive or CSV format that includes both the > patch release date and the CVE. > > I picked CVE-2014-0162 > > I was hoping someone had already done the work for me like this > analysis of rhel variants: Lag for centos behind rhel patch > releases > http://bitrate.epipe.com/rhel-vs-centos-scientific-oracle-linux-6_187 > > Comparing centos to ubuntu is problematic since the centos > announce list does not include the CVE or bug description. > > Ubuntu has archives here > http://people.canonical.com/~ubuntu-security/cve/ But the bug i > picked wasn't there. > > I had to google around to find it here. > http://www.ubuntuupdates.org/package/core/saucy/main/updates/glance > > > > debian has bundled files, with CVE's but no dates, only release > numbers https://security-tracker.debian.org/tracker/ > > I was only able to find nice stats with everything i needed for > Redhat. http://www.redhat.com/security/data/metrics/ Heh, yup! > If i'm missing any links to make this info more accessible please > let me know. Otherwise, 2 dozen comparisons might take a day or > two. > > kesten So in a previous life when I contracted for iSIGHT/iDefense I know firms like that can produce this data, but they charge quite a bit, the reason being that as you discovered most sources are very messy/hard to parse. Another way to approach it might be to pick a few packages that get updates regularly (e.g. keystone) and go through the package histories noting when the solve various CVEs, that way you only have to look at a handful of files. - -- Kurt Seifried - Red Hat - Product Security - Cloud stuff and such PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTi9CwAAoJEBYNRVNeJnmTGRcP/R5TChgwhkEGZi7P38iZiFA7 ukeUo9Behf0BSOkd9nIhdZsrcluzyZkMSgnpFdkdaBY3u2fcHswg6hG1iONUlNKQ fBtQRwzbD+ZqjHxjoUfL629MzNB57no8okh8RbpexvNCsRFdMICJXCDN2RG68xch 4xg6uITn19AhiIUCuHDESeqCu9xYYJ77anTTXkHpB5kbiwcPU/iZ6P5TB3GqqR1u XqvaYn+niMW0CINPaNXytOvINUiyNNqieKZzu/Nbi1NwmoVHYkdfAVJJs2XDgAaT sWTTlQHXTUJJ0/8SHYkrdnzk6HcvL+Ef38qQ559AdSE51/Aoel8bjDtRHkh/Y6mn a6tidERDlnYsyeZmbGZlzOgV1NQPxGre3dtqe4fu0L+sMrfQw/oqZdk1rMY/lRxJ 8UFemgMgriteX6b/1AooHNYzf780f19o6YBkQJaXXcUgIhgtCij82Gbf24vJlqZA SXpIhzWyUxzM4TNZgKKNvoEXGJnRnqYRwjfttHYogXlXygqKD5jjzhYap4HytCUV tTJGe08WOe76V3jPoS+2bRUJQ2q0XhJmyUVWfQMYER+eE4mhQWiDx1xK3rXylBhF 0Ebsy/2TKVCT4xGr2kDHza4p0BEknvlOiXAz6ZtnKgJxxy4IjHtAaWU4pmL0qnnI 3mn88JhbdhUWWIf7EnJ2 =CJ40 -----END PGP SIGNATURE----- From thierry at openstack.org Mon Jun 2 08:15:15 2014 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 02 Jun 2014 11:15:15 +0300 Subject: [Openstack-security] Fixing errors in issued OSSNs In-Reply-To: References: Message-ID: <538C3293.8060800@openstack.org> Bryan D. Payne wrote: > I vote for cutting OSSN-0013-1 and then, to the extent possible, > ensuring that this new one replaces the old one in all of our > publication locations. +1 -- Thierry Carrez (ttx) From 1320098 at bugs.launchpad.net Mon Jun 2 12:50:56 2014 From: 1320098 at bugs.launchpad.net (Robert Clark) Date: Mon, 02 Jun 2014 12:50:56 -0000 Subject: [Openstack-security] [Bug 1320098] Re: neutronclient debug logging includes keystone auth token References: <20140516064420.2758.66631.malonedeb@wampee.canonical.com> Message-ID: <20140602125056.26499.28243.malone@wampee.canonical.com> Limited security impact because it's client side but certainly an issue that needs to be fixed. -Rob -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320098 Title: neutronclient debug logging includes keystone auth token Status in Python client library for Neutron: In Progress Bug description: neutronclient is logging the auth token in the nova logs. Since the logs are world-readable, this means anyone user on this system can see the auth token, which they can then use to get OpenStack administrator access. To manage notifications about this bug go to: https://bugs.launchpad.net/python-neutronclient/+bug/1320098/+subscriptions From doug.chivers at hp.com Mon Jun 2 13:48:06 2014 From: doug.chivers at hp.com (Chivers, Douglas) Date: Mon, 2 Jun 2014 13:48:06 +0000 Subject: [Openstack-security] Please review OSSN-0016 Message-ID: Hi, I’ve drafted an OSSN and would appreciate any feedback: https://review.openstack.org/#/c/96865/ Thanks Doug _______________________ Doug Chivers HP Helion Security Architect doug.chivers at hp.com From robert.clark at hp.com Mon Jun 2 16:10:37 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 2 Jun 2014 16:10:37 +0000 Subject: [Openstack-security] OpenStack Security Group Mid-Cycle Meetup - Dates and Location Message-ID: Hi All, Just a reminder that if you would like to attend the mid-cycle meet up you need to put your name down against a date here: https://etherpad.openstack.org/p/ossg-juno-meetup HP have offered to host the meet up in Seattle, covering venue, food, ping and power. -Rob From bpokorny at linux.vnet.ibm.com Mon Jun 2 18:16:29 2014 From: bpokorny at linux.vnet.ibm.com (Brad Pokorny) Date: Mon, 02 Jun 2014 18:16:29 -0000 Subject: [Openstack-security] [Bug 1320028] Re: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com> Message-ID: <20140602181629.27567.35316.malone@gac.canonical.com> Review submitted for a specific case that wasn't handled previously: https://review.openstack.org/#/c/97305 ** Changed in: oslo Status: Fix Committed => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320028 Title: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: If debug logging is enabled, the _run_iscsiadm function in volume.py logs the iscsi node.session.auth.password in plain text. 2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req- d21bb680-feb9-4242-9d18-057af79d26e8 0 3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n', 'node.session.auth.password', '-v', u'password'): stdout= stderr= _run_iscsiadm /usr/lib/python2.7/site- packages/nova/virt/libvirt/volume.py:248 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1320028/+subscriptions From gerrit2 at review.openstack.org Tue Jun 3 03:02:41 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Jun 2014 03:02:41 +0000 Subject: [Openstack-security] [stackforge/kite] SecurityImpact review request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80902 Log: commit 2065daeb68a0152206c61e209dacdff5268ed899 Author: Jamie Lennox Date: Tue Dec 3 12:33:28 2013 +1000 Add cryptographic key storage Adds a layer called Storage on top of the DB. The DB is a simple store retrieve interface and things going through Storage are correctly encrypted and stored to the database. Add some routes to allow setting a key through the storage interface. SecurityImpact Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From aaronorosen at gmail.com Tue Jun 3 10:15:05 2014 From: aaronorosen at gmail.com (Aaron Rosen) Date: Tue, 03 Jun 2014 10:15:05 -0000 Subject: [Openstack-security] [Bug 1322173] Re: nova boot with explicitly defined security groups doesn't apply proper groups References: <20140522131508.10129.29697.malonedeb@gac.canonical.com> Message-ID: <20140603101505.20172.57156.malone@chaenomeles.canonical.com> If you did nova boot --nic port-id= --nic net-id= --security_groups web ; then the web security group would be on the second interface. As said above if you pass in a port nova does not update that port by design ** Changed in: nova Status: New => 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/1322173 Title: nova boot with explicitly defined security groups doesn't apply proper groups Status in OpenStack Compute (Nova): Invalid Bug description: Steps to reproduce: $ nova boot --flavor 2 --image $image_id --nic port-id=$port_id --security-groups onlyssh --poll ihor-test-01 | grep security_groups | security_groups | onlyssh | $ nova show ihor-test-01 | grep security_groups | security_groups | default | I tried using both name and id of a security group, none of approaches work. Expected behavior: The security group list is persisted and applied. Actual behavior: The security group list is neither persisted nor applied. Environment: * CentOS 6.5 * OpenStack havana * /etc/neutron/l3_agent.ini: [DEFAULT] interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver ovs_use_veth = True use_namespaces = True handle_internal_only_routers = False external_network_bridge = * /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini [ovs] tenant_network_type = vlan network_vlan_ranges = physnet1:1000:2000 tunnel_id_ranges = integration_bridge = br-int bridge_mappings = physnet1:br-vlan [agent] [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1322173/+subscriptions From 1322173 at bugs.launchpad.net Tue Jun 3 10:45:50 2014 From: 1322173 at bugs.launchpad.net (Ihor Kaharlichenko) Date: Tue, 03 Jun 2014 10:45:50 -0000 Subject: [Openstack-security] [Bug 1322173] Re: nova boot with explicitly defined security groups doesn't apply proper groups References: <20140522131508.10129.29697.malonedeb@gac.canonical.com> Message-ID: <20140603104550.3953.53205.malone@soybean.canonical.com> Aaron, maybe that is indeed by design, yet it is not intuitive. Moreover it first reports that the security group _is_ applied (since nova boot just shows the same output as nova show for the newly created host), but later when you check that host again you see that the security group you provided as a command-line parameter was simply ignored! And you haven't even got any warnings shown that it was ignored. That's not user friendly at all. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1322173 Title: nova boot with explicitly defined security groups doesn't apply proper groups Status in OpenStack Compute (Nova): Invalid Bug description: Steps to reproduce: $ nova boot --flavor 2 --image $image_id --nic port-id=$port_id --security-groups onlyssh --poll ihor-test-01 | grep security_groups | security_groups | onlyssh | $ nova show ihor-test-01 | grep security_groups | security_groups | default | I tried using both name and id of a security group, none of approaches work. Expected behavior: The security group list is persisted and applied. Actual behavior: The security group list is neither persisted nor applied. Environment: * CentOS 6.5 * OpenStack havana * /etc/neutron/l3_agent.ini: [DEFAULT] interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver ovs_use_veth = True use_namespaces = True handle_internal_only_routers = False external_network_bridge = * /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini [ovs] tenant_network_type = vlan network_vlan_ranges = physnet1:1000:2000 tunnel_id_ranges = integration_bridge = br-int bridge_mappings = physnet1:br-vlan [agent] [securitygroup] firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1322173/+subscriptions From 1322766 at bugs.launchpad.net Tue Jun 3 12:26:31 2014 From: 1322766 at bugs.launchpad.net (Doug Chivers) Date: Tue, 03 Jun 2014 12:26:31 -0000 Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open References: <20140523222522.10305.61680.malonedeb@gac.canonical.com> Message-ID: <20140603122635.26302.77852.launchpad@wampee.canonical.com> ** Changed in: ossn Status: In Progress => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1322766 Title: Cinder wipe/shred fails open Status in Cinder: New Status in OpenStack Security Notes: Fix Released Bug description: Previously, lvm_type=default signified a volume should be zero'd or wiped when deleting the volume. Zeroization could be avoided with lvm_type=thin. At https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20, the following was added: volume_clear = none, zero, shred volume_clear_size = size_in_MiB Looking at the code from the commit, the default behavior of wiping was changed, and the change resulted in a "fail open". That is, no wipe occurs on configuration errors or typos: + LOG.info(_("Performing secure delete on volume: %s") % volume['id']) + + if FLAGS.volume_clear == 'zero': + if size_in_m == 0: + return self._copy_volume('/dev/zero', vol_path, size_in_g) + else: + clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m] + elif FLAGS.volume_clear == 'shred': + clear_cmd = ['shred', '-n3'] + if size_in_m: + clear_cmd.append('-s%dMiB' % size_in_m) + else: + LOG.error(_("Error unrecognized volume_clear option: %s"), + FLAGS.volume_clear) + return Perhaps previous behavior should be restored: * default = one pass of 0's * a valid config changes the behavior * an invalid config still uses default behavior I think it s important to ensure cinder serves zero'ized block among tenants in the common case to ensure no data leaks of sensitive or highly sensitive data. Its going to be an important safeguard, especially in industries like US Financial and US Federal. Operators that don't handle sensitive or highly sensitive data can 'volume_clear = none'. And the unexpected case of a configuration error or typo ensures the system fails safe. In fact, specifying 'volume_clear = 1' or 'volume_clear = true' or 'volume_clear = yes' should trigger the unexpected fail open. From the low hanging fruit department.... Feel free to release it at any time. The "security vulnerability" was checked to ensure the security folks had an opportunity to provide feedback. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1322766/+subscriptions From nkinder at redhat.com Tue Jun 3 13:34:11 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 03 Jun 2014 13:34:11 -0000 Subject: [Openstack-security] [Bug 1322766] Re: Cinder wipe/shred fails open References: <20140523222522.10305.61680.malonedeb@gac.canonical.com> Message-ID: <20140603133411.27915.69273.malone@gac.canonical.com> OSSN-0016 has been published to the wiki and the openstack and openstack-dev mailing lists for this issue. https://wiki.openstack.org/wiki/OSSN/OSSN-0016 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1322766 Title: Cinder wipe/shred fails open Status in Cinder: New Status in OpenStack Security Notes: Fix Released Bug description: Previously, lvm_type=default signified a volume should be zero'd or wiped when deleting the volume. Zeroization could be avoided with lvm_type=thin. At https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20, the following was added: volume_clear = none, zero, shred volume_clear_size = size_in_MiB Looking at the code from the commit, the default behavior of wiping was changed, and the change resulted in a "fail open". That is, no wipe occurs on configuration errors or typos: + LOG.info(_("Performing secure delete on volume: %s") % volume['id']) + + if FLAGS.volume_clear == 'zero': + if size_in_m == 0: + return self._copy_volume('/dev/zero', vol_path, size_in_g) + else: + clear_cmd = ['shred', '-n0', '-z', '-s%dMiB' % size_in_m] + elif FLAGS.volume_clear == 'shred': + clear_cmd = ['shred', '-n3'] + if size_in_m: + clear_cmd.append('-s%dMiB' % size_in_m) + else: + LOG.error(_("Error unrecognized volume_clear option: %s"), + FLAGS.volume_clear) + return Perhaps previous behavior should be restored: * default = one pass of 0's * a valid config changes the behavior * an invalid config still uses default behavior I think it s important to ensure cinder serves zero'ized block among tenants in the common case to ensure no data leaks of sensitive or highly sensitive data. Its going to be an important safeguard, especially in industries like US Financial and US Federal. Operators that don't handle sensitive or highly sensitive data can 'volume_clear = none'. And the unexpected case of a configuration error or typo ensures the system fails safe. In fact, specifying 'volume_clear = 1' or 'volume_clear = true' or 'volume_clear = yes' should trigger the unexpected fail open. From the low hanging fruit department.... Feel free to release it at any time. The "security vulnerability" was checked to ensure the security folks had an opportunity to provide feedback. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1322766/+subscriptions From blk at acm.org Tue Jun 3 15:50:29 2014 From: blk at acm.org (Brant Knudson) Date: Tue, 3 Jun 2014 10:50:29 -0500 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: References: Message-ID: That time works for me. - Brant On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham wrote: > Sorry, long week. > > Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. > > > From: Bryan Payne > > Date: Friday, 30 May 2014 17:32 > To: Robert Clark > > Cc: "openstack-security at lists.openstack.org openstack-security at lists.openstack.org>" < > openstack-security at lists.openstack.org openstack-security at lists.openstack.org>> > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > I'm guessing you really mean: > Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? > > Personally... This isn't ideal for me, as I have a daily meeting from 1730 > - 1800. Having said that, I can make this work, if needed. > > -bryan > > > On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham > wrote: > Hi All, > > I think we’re all agreed that we could do with some extra time to have > OSSG discussions, I’m glad to say that we now have more to say than we used > to! - I’d like to extend the meeting out to an hour with the obvious caveat > that we’ll end when possible. > > I’d like to propose that we bring the meeting forward by an hour and > extend it to an hour, making the meeting 1700-1800UTC this should mean that > our west coast friends don’t have to get up too early while allowing our > EMEA folks to finish work too late. > > Looking at the availability on https://wiki.openstack.org/wiki/Meetings< > https://wiki.openstack.org/wiki/Meetings#OpenStack_Project_.26_Release_Status_meeting> > this should work just fine but we’ll have to move to holding the meeting > #openstack-meeting-alt > > So the proposal I’m making is: > Thursdays 1800 UTC in #openstack-meeting-alt > > I’m more than happy to hear other proposals if there’s a better/more > suitable time for everyone. > > -Rob > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org Openstack-security at lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Tue Jun 3 16:17:03 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 03 Jun 2014 09:17:03 -0700 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: References: Message-ID: <538DF4FF.5070106@redhat.com> On 06/03/2014 08:50 AM, Brant Knudson wrote: > > That time works for me. - Brant Same here. -NGK > > > On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham > > wrote: > > Sorry, long week. > > Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. > > > From: Bryan Payne >> > Date: Friday, 30 May 2014 17:32 > To: Robert Clark >> > Cc: "openstack-security at lists.openstack.org > >" > >> > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > I'm guessing you really mean: > Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? > > Personally... This isn't ideal for me, as I have a daily meeting > from 1730 - 1800. Having said that, I can make this work, if needed. > > -bryan > > > On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham > >> wrote: > Hi All, > > I think we’re all agreed that we could do with some extra time to > have OSSG discussions, I’m glad to say that we now have more to say > than we used to! - I’d like to extend the meeting out to an hour > with the obvious caveat that we’ll end when possible. > > I’d like to propose that we bring the meeting forward by an hour and > extend it to an hour, making the meeting 1700-1800UTC this should > mean that our west coast friends don’t have to get up too early > while allowing our EMEA folks to finish work too late. > > Looking at the availability on > https://wiki.openstack.org/wiki/Meetings > this should work just fine but we’ll have to move to holding the > meeting #openstack-meeting-alt > > So the proposal I’m making is: > Thursdays 1800 UTC in #openstack-meeting-alt > > I’m more than happy to hear other proposals if there’s a better/more > suitable time for everyone. > > -Rob > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > From bdpayne at acm.org Tue Jun 3 17:09:48 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 3 Jun 2014 10:09:48 -0700 Subject: [Openstack-security] OpenStack Security Group Mid-Cycle Meetup - Dates and Location In-Reply-To: References: Message-ID: > Just a reminder that if you would like to attend the mid-cycle meet up you > need to put your name down against a date here: > > https://etherpad.openstack.org/p/ossg-juno-meetup Yes, please vote soon as we'll need to finalize the dates before too long! > HP have offered to host the meet up in Seattle, covering venue, food, ping > and power. > Thanks, this sounds like a great option. -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Travis_McPeak at symantec.com Tue Jun 3 17:13:21 2014 From: Travis_McPeak at symantec.com (Travis McPeak) Date: Tue, 3 Jun 2014 10:13:21 -0700 Subject: [Openstack-security] OpenStack Security Group Mid-Cycle Meetup - Dates and Location Message-ID: Sounds great! Thanks Rob (HP) :) Thanks, -Travis On 6/3/14, 5:00 AM, "openstack-security-request at lists.openstack.org" wrote: >Message: 3 >Date: Mon, 2 Jun 2014 16:10:37 +0000 >From: "Clark, Robert Graham" >To: "openstack-security at lists.openstack.org" > >Subject: [Openstack-security] OpenStack Security Group Mid-Cycle > Meetup - Dates and Location >Message-ID: >Content-Type: text/plain; charset="us-ascii" > >Hi All, > >Just a reminder that if you would like to attend the mid-cycle meet up >you need to put your name down against a date here: > >https://etherpad.openstack.org/p/ossg-juno-meetup > >HP have offered to host the meet up in Seattle, covering venue, food, >ping and power. > >-Rob From sriram at sriramhere.com Tue Jun 3 17:40:51 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Tue, 3 Jun 2014 10:40:51 -0700 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: <538DF4FF.5070106@redhat.com> References: <538DF4FF.5070106@redhat.com> Message-ID: 1700-1800 UTC which is 10.00 - 11.00 PDT in #openstack-meeting-alt works for me. Are we starting this thursday, June 5th? On Tue, Jun 3, 2014 at 9:17 AM, Nathan Kinder wrote: > > > On 06/03/2014 08:50 AM, Brant Knudson wrote: > > > > That time works for me. - Brant > > Same here. > > -NGK > > > > > > > On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham > > > wrote: > > > > Sorry, long week. > > > > Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. > > > > > > From: Bryan Payne > > >> > > Date: Friday, 30 May 2014 17:32 > > To: Robert Clark > > >> > > Cc: "openstack-security at lists.openstack.org > > openstack-security at lists.openstack.org > > >" > > > openstack-security at lists.openstack.org > > >> > > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > > > I'm guessing you really mean: > > Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? > > > > Personally... This isn't ideal for me, as I have a daily meeting > > from 1730 - 1800. Having said that, I can make this work, if needed. > > > > -bryan > > > > > > On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham > > > > >> wrote: > > Hi All, > > > > I think we’re all agreed that we could do with some extra time to > > have OSSG discussions, I’m glad to say that we now have more to say > > than we used to! - I’d like to extend the meeting out to an hour > > with the obvious caveat that we’ll end when possible. > > > > I’d like to propose that we bring the meeting forward by an hour and > > extend it to an hour, making the meeting 1700-1800UTC this should > > mean that our west coast friends don’t have to get up too early > > while allowing our EMEA folks to finish work too late. > > > > Looking at the availability on > > https://wiki.openstack.org/wiki/Meetings< > https://wiki.openstack.org/wiki/Meetings#OpenStack_Project_.26_Release_Status_meeting > > > > this should work just fine but we’ll have to move to holding the > > meeting #openstack-meeting-alt > > > > So the proposal I’m making is: > > Thursdays 1800 UTC in #openstack-meeting-alt > > > > I’m more than happy to hear other proposals if there’s a better/more > > suitable time for everyone. > > > > -Rob > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > Openstack-security at lists.openstack.org > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Tue Jun 3 17:43:45 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 3 Jun 2014 17:43:45 +0000 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: <538DF4FF.5070106@redhat.com> References: <538DF4FF.5070106@redhat.com> Message-ID: Great. Lets keep the normal session for this week so we can tell the people who attend about the change in time for next week. > -----Original Message----- > From: Nathan Kinder [mailto:nkinder at redhat.com] > Sent: 03 June 2014 17:17 > To: openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > > > On 06/03/2014 08:50 AM, Brant Knudson wrote: > > > > That time works for me. - Brant > > Same here. > > -NGK > > > > > > > On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham > > > wrote: > > > > Sorry, long week. > > > > Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. > > > > > > From: Bryan Payne > > >> > > Date: Friday, 30 May 2014 17:32 > > To: Robert Clark > > >> > > Cc: "openstack-security at lists.openstack.org > > security at lists.openstack.org > > >" > > > security at lists.openstack.org > > >> > > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > > > I'm guessing you really mean: > > Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? > > > > Personally... This isn't ideal for me, as I have a daily meeting > > from 1730 - 1800. Having said that, I can make this work, if > > needed. > > > > -bryan > > > > > > On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham > > > > >> wrote: > > Hi All, > > > > I think we're all agreed that we could do with some extra time to > > have OSSG discussions, I'm glad to say that we now have more to > > say > > than we used to! - I'd like to extend the meeting out to an hour > > with the obvious caveat that we'll end when possible. > > > > I'd like to propose that we bring the meeting forward by an hour > > and > > extend it to an hour, making the meeting 1700-1800UTC this should > > mean that our west coast friends don't have to get up too early > > while allowing our EMEA folks to finish work too late. > > > > Looking at the availability on > > > https://wiki.openstack.org/wiki/Meetings Meetings#OpenStack_Project_.26_Release_Status_meeting> > > this should work just fine but we'll have to move to holding the > > meeting #openstack-meeting-alt > > > > So the proposal I'm making is: > > Thursdays 1800 UTC in #openstack-meeting-alt > > > > I'm more than happy to hear other proposals if there's a > > better/more > > suitable time for everyone. > > > > -Rob > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > security at lists.openstack.org > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From sriram at sriramhere.com Tue Jun 3 18:08:36 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Tue, 3 Jun 2014 11:08:36 -0700 Subject: [Openstack-security] OpenStack Security Group Mid-Cycle Meetup - Dates and Location In-Reply-To: References: Message-ID: Thanks Rob/ HP. OSSG - welcome to Seattle! On Tue, Jun 3, 2014 at 10:13 AM, Travis McPeak wrote: > Sounds great! Thanks Rob (HP) :) > > Thanks, > -Travis > > > > > On 6/3/14, 5:00 AM, "openstack-security-request at lists.openstack.org" > wrote: > > >Message: 3 > >Date: Mon, 2 Jun 2014 16:10:37 +0000 > >From: "Clark, Robert Graham" > >To: "openstack-security at lists.openstack.org" > > > >Subject: [Openstack-security] OpenStack Security Group Mid-Cycle > > Meetup - Dates and Location > >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > > > >Hi All, > > > >Just a reminder that if you would like to attend the mid-cycle meet up > >you need to put your name down against a date here: > > > >https://etherpad.openstack.org/p/ossg-juno-meetup > > > >HP have offered to host the meet up in Seattle, covering venue, food, > >ping and power. > > > >-Rob > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gexiaoyu at huawei.com Wed Jun 4 08:30:29 2014 From: gexiaoyu at huawei.com (Gexiaoyu) Date: Wed, 4 Jun 2014 08:30:29 +0000 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: References: <538DF4FF.5070106@redhat.com> Message-ID: <27C49E3A44E36C42B89B9012C5CF527C21D0AF13@SZXEMA511-MBX.china.huawei.com> Hi Rob I'm interested in the meeting, Is there a appropriate time that APAC guys can attend. Thanks, Xiaoyu -----Original Message----- From: Clark, Robert Graham [mailto:robert.clark at hp.com] Sent: Wednesday, June 04, 2014 1:44 AM To: Nathan Kinder; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [OSSG] Meeting Time Great. Lets keep the normal session for this week so we can tell the people who attend about the change in time for next week. > -----Original Message----- > From: Nathan Kinder [mailto:nkinder at redhat.com] > Sent: 03 June 2014 17:17 > To: openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > > > On 06/03/2014 08:50 AM, Brant Knudson wrote: > > > > That time works for me. - Brant > > Same here. > > -NGK > > > > > > > On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham > > > wrote: > > > > Sorry, long week. > > > > Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. > > > > > > From: Bryan Payne > > >> > > Date: Friday, 30 May 2014 17:32 > > To: Robert Clark > > >> > > Cc: "openstack-security at lists.openstack.org > > security at lists.openstack.org > > >" > > > security at lists.openstack.org > > >> > > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > > > I'm guessing you really mean: > > Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? > > > > Personally... This isn't ideal for me, as I have a daily meeting > > from 1730 - 1800. Having said that, I can make this work, if > > needed. > > > > -bryan > > > > > > On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham > > > > >> wrote: > > Hi All, > > > > I think we're all agreed that we could do with some extra time to > > have OSSG discussions, I'm glad to say that we now have more to > > say > > than we used to! - I'd like to extend the meeting out to an hour > > with the obvious caveat that we'll end when possible. > > > > I'd like to propose that we bring the meeting forward by an hour > > and > > extend it to an hour, making the meeting 1700-1800UTC this should > > mean that our west coast friends don't have to get up too early > > while allowing our EMEA folks to finish work too late. > > > > Looking at the availability on > > > https://wiki.openstack.org/wiki/Meetings Meetings#OpenStack_Project_.26_Release_Status_meeting> > > this should work just fine but we'll have to move to holding the > > meeting #openstack-meeting-alt > > > > So the proposal I'm making is: > > Thursdays 1800 UTC in #openstack-meeting-alt > > > > I'm more than happy to hear other proposals if there's a > > better/more > > suitable time for everyone. > > > > -Rob > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > security at lists.openstack.org > > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From robert.clark at hp.com Wed Jun 4 08:35:50 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 4 Jun 2014 08:35:50 +0000 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: <27C49E3A44E36C42B89B9012C5CF527C21D0AF13@SZXEMA511-MBX.china.huawei.com> References: <538DF4FF.5070106@redhat.com> <27C49E3A44E36C42B89B9012C5CF527C21D0AF13@SZXEMA511-MBX.china.huawei.com> Message-ID: Hi Xiaoyu, As you¹ll know, it¹s virtually impossible to find a meeting time that is appropriate for everyone, especially when we have members spread all over the world. I don¹t believe that the time we have chosen will work for our friends in APAC, however, the mailing list is being used more-and-more and we publish all the minutes from our meetings here: https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity If our APAC numbers increase significantly we could look into options for another meeting or look again at the timings but we¹re never going to be able to find a time that suits everyone. Hope this helps -Rob On 04/06/2014 09:30, "Gexiaoyu" wrote: >Hi Rob > >I'm interested in the meeting, Is there a appropriate time that APAC guys >can attend. > >Thanks, >Xiaoyu > >-----Original Message----- >From: Clark, Robert Graham [mailto:robert.clark at hp.com] >Sent: Wednesday, June 04, 2014 1:44 AM >To: Nathan Kinder; openstack-security at lists.openstack.org >Subject: Re: [Openstack-security] [OSSG] Meeting Time > >Great. > >Lets keep the normal session for this week so we can tell the people who >attend about the change in time for next week. > > > >> -----Original Message----- >> From: Nathan Kinder [mailto:nkinder at redhat.com] >> Sent: 03 June 2014 17:17 >> To: openstack-security at lists.openstack.org >> Subject: Re: [Openstack-security] [OSSG] Meeting Time >> >> >> >> On 06/03/2014 08:50 AM, Brant Knudson wrote: >> > >> > That time works for me. - Brant >> >> Same here. >> >> -NGK >> >> > >> > >> > On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham >> > > wrote: >> > >> > Sorry, long week. >> > >> > Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. >> > >> > >> > From: Bryan Payne > > > > >> >> > Date: Friday, 30 May 2014 17:32 >> > To: Robert Clark > > > > >> >> > Cc: "openstack-security at lists.openstack.org >> > >> security at lists.openstack.org >> > >" >> > > > >> security at lists.openstack.org >> > >> >> > Subject: Re: [Openstack-security] [OSSG] Meeting Time >> > >> > I'm guessing you really mean: >> > Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? >> > >> > Personally... This isn't ideal for me, as I have a daily meeting >> > from 1730 - 1800. Having said that, I can make this work, if >> > needed. >> > >> > -bryan >> > >> > >> > On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham >> > > > > > >> wrote: >> > Hi All, >> > >> > I think we're all agreed that we could do with some extra time >to >> > have OSSG discussions, I'm glad to say that we now have more to >> > say >> > than we used to! - I'd like to extend the meeting out to an hour >> > with the obvious caveat that we'll end when possible. >> > >> > I'd like to propose that we bring the meeting forward by an hour > >> > and >> > extend it to an hour, making the meeting 1700-1800UTC this >should >> > mean that our west coast friends don't have to get up too early >> > while allowing our EMEA folks to finish work too late. >> > >> > Looking at the availability on >> > >> >https://wiki.openstack.org/wiki/Meetings/ >> Meetings#OpenStack_Project_.26_Release_Status_meeting> >> > this should work just fine but we'll have to move to holding the >> > meeting #openstack-meeting-alt >> > >> > So the proposal I'm making is: >> > Thursdays 1800 UTC in #openstack-meeting-alt >> > >> > I'm more than happy to hear other proposals if there's a >> > better/more >> > suitable time for everyone. >> > >> > -Rob >> > >> > _______________________________________________ >> > Openstack-security mailing list >> > Openstack-security at lists.openstack.org >> > >> security at lists.openstack.org >> > > >> > >> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > >> > >> > _______________________________________________ >> > Openstack-security mailing list >> > Openstack-security at lists.openstack.org >> > >> > >> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > >> > >> > >> > >> > _______________________________________________ >> > Openstack-security mailing list >> > Openstack-security at lists.openstack.org >> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From gexiaoyu at huawei.com Wed Jun 4 09:11:53 2014 From: gexiaoyu at huawei.com (Gexiaoyu) Date: Wed, 4 Jun 2014 09:11:53 +0000 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: References: <538DF4FF.5070106@redhat.com> <27C49E3A44E36C42B89B9012C5CF527C21D0AF13@SZXEMA511-MBX.china.huawei.com> Message-ID: <27C49E3A44E36C42B89B9012C5CF527C21D0AFBF@SZXEMA511-MBX.china.huawei.com> That's ok. The minutes is useful too. I will dial in at the time you recommend when necessary. Thanks, Xiaoyu -----Original Message----- From: Clark, Robert Graham [mailto:robert.clark at hp.com] Sent: Wednesday, June 04, 2014 4:36 PM To: Gexiaoyu Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [OSSG] Meeting Time Hi Xiaoyu, As you¹ll know, it¹s virtually impossible to find a meeting time that is appropriate for everyone, especially when we have members spread all over the world. I don¹t believe that the time we have chosen will work for our friends in APAC, however, the mailing list is being used more-and-more and we publish all the minutes from our meetings here: https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity If our APAC numbers increase significantly we could look into options for another meeting or look again at the timings but we¹re never going to be able to find a time that suits everyone. Hope this helps -Rob On 04/06/2014 09:30, "Gexiaoyu" wrote: >Hi Rob > >I'm interested in the meeting, Is there a appropriate time that APAC >guys can attend. > >Thanks, >Xiaoyu > >-----Original Message----- >From: Clark, Robert Graham [mailto:robert.clark at hp.com] >Sent: Wednesday, June 04, 2014 1:44 AM >To: Nathan Kinder; openstack-security at lists.openstack.org >Subject: Re: [Openstack-security] [OSSG] Meeting Time > >Great. > >Lets keep the normal session for this week so we can tell the people >who attend about the change in time for next week. > > > >> -----Original Message----- >> From: Nathan Kinder [mailto:nkinder at redhat.com] >> Sent: 03 June 2014 17:17 >> To: openstack-security at lists.openstack.org >> Subject: Re: [Openstack-security] [OSSG] Meeting Time >> >> >> >> On 06/03/2014 08:50 AM, Brant Knudson wrote: >> > >> > That time works for me. - Brant >> >> Same here. >> >> -NGK >> >> > >> > >> > On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham >> > > wrote: >> > >> > Sorry, long week. >> > >> > Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. >> > >> > >> > From: Bryan Payne > > > > >> >> > Date: Friday, 30 May 2014 17:32 >> > To: Robert Clark > > > > >> >> > Cc: "openstack-security at lists.openstack.org >> > >> security at lists.openstack.org >> > >" >> > > > >> security at lists.openstack.org >> > >> >> > Subject: Re: [Openstack-security] [OSSG] Meeting Time >> > >> > I'm guessing you really mean: >> > Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? >> > >> > Personally... This isn't ideal for me, as I have a daily meeting >> > from 1730 - 1800. Having said that, I can make this work, if >> > needed. >> > >> > -bryan >> > >> > >> > On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham >> > > > > > >> wrote: >> > Hi All, >> > >> > I think we're all agreed that we could do with some extra time >to >> > have OSSG discussions, I'm glad to say that we now have more to >> > say >> > than we used to! - I'd like to extend the meeting out to an hour >> > with the obvious caveat that we'll end when possible. >> > >> > I'd like to propose that we bring the meeting forward by an >> > hour > >> > and >> > extend it to an hour, making the meeting 1700-1800UTC this >should >> > mean that our west coast friends don't have to get up too early >> > while allowing our EMEA folks to finish work too late. >> > >> > Looking at the availability on >> > >> >https://wiki.openstack.org/wiki/Meetingsi >/ >> Meetings#OpenStack_Project_.26_Release_Status_meeting> >> > this should work just fine but we'll have to move to holding the >> > meeting #openstack-meeting-alt >> > >> > So the proposal I'm making is: >> > Thursdays 1800 UTC in #openstack-meeting-alt >> > >> > I'm more than happy to hear other proposals if there's a >> > better/more >> > suitable time for everyone. >> > >> > -Rob >> > >> > _______________________________________________ >> > Openstack-security mailing list >> > Openstack-security at lists.openstack.org >> > >> security at lists.openstack.org >> > > >> > >> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > >> > >> > _______________________________________________ >> > Openstack-security mailing list >> > Openstack-security at lists.openstack.org >> > >> > >> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > >> > >> > >> > >> > _______________________________________________ >> > Openstack-security mailing list >> > Openstack-security at lists.openstack.org >> > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-securit >> y From 1290486 at bugs.launchpad.net Wed Jun 4 09:13:40 2014 From: 1290486 at bugs.launchpad.net (Alan Pevec) Date: Wed, 04 Jun 2014 09:13:40 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140604091341.27369.79889.launchpad@gac.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Fix Committed Status in tripleo - openstack on openstack: Fix Committed Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From mail at cgoncalves.pt Wed Jun 4 12:58:29 2014 From: mail at cgoncalves.pt (Carlos Goncalves) Date: Wed, 04 Jun 2014 12:58:29 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140604125829.27213.78724.malone@gac.canonical.com> Kyle, as per your comment #8 is it valid to assume that if minimize_polling is set to False, we are not hit by this bug? If so, that would be a workaround for icehouse while review #96919 is not merged and distribution packages are not updated. My guess is that such backport won't make in time for 2014.1.1 which is due to tomorrow, unfortunately. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Fix Committed Status in tripleo - openstack on openstack: Fix Committed Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From 1299012 at bugs.launchpad.net Wed Jun 4 15:11:21 2014 From: 1299012 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 04 Jun 2014 15:11:21 -0000 Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method chaining References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com> Message-ID: <20140604151123.4213.22555.launchpad@soybean.canonical.com> ** Changed in: keystone Assignee: Guang Yee (guang-yee) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1299012 Title: V3 api authentication method chaining Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Security Advisories: Invalid Bug description: When using authentication method chaining for token creation (POST) in Keystone V3 api , it is possible to use authentication credentials for two different users . For example, if i have an existing token for a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier for demo tenant) and i have a user say 'test131' in admin tenant Now i can make an authentication call using auth method chaining { "auth":{ "identity":{ "methods":[ "password", "token" ], "token":{ "id":"6bb934a0120f097a32b5d3cc71f83beb" }, "password":{ "user":{ "domain":{ "id":"default" }, "name":"test131", "password":"test131" } } } } } The call will succeed even though two different users authentication credentials are used. The generated token will get properties of test131 user although the expirary date is set by demo user token. If we change the methods sequence, the generated token will get all properties from demo users token. This is an undesired security behaviour - token should not be allowed to generate using credentials from two different users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299012/+subscriptions From bknudson at us.ibm.com Wed Jun 4 15:26:08 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Wed, 04 Jun 2014 15:26:08 -0000 Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method chaining References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com> Message-ID: <20140604152610.27307.7712.launchpad@gac.canonical.com> ** Changed in: keystone Assignee: Brant Knudson (blk-u) => Guang Yee (guang-yee) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1299012 Title: V3 api authentication method chaining Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Security Advisories: Invalid Bug description: When using authentication method chaining for token creation (POST) in Keystone V3 api , it is possible to use authentication credentials for two different users . For example, if i have an existing token for a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier for demo tenant) and i have a user say 'test131' in admin tenant Now i can make an authentication call using auth method chaining { "auth":{ "identity":{ "methods":[ "password", "token" ], "token":{ "id":"6bb934a0120f097a32b5d3cc71f83beb" }, "password":{ "user":{ "domain":{ "id":"default" }, "name":"test131", "password":"test131" } } } } } The call will succeed even though two different users authentication credentials are used. The generated token will get properties of test131 user although the expirary date is set by demo user token. If we change the methods sequence, the generated token will get all properties from demo users token. This is an undesired security behaviour - token should not be allowed to generate using credentials from two different users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299012/+subscriptions From 1299012 at bugs.launchpad.net Wed Jun 4 15:42:14 2014 From: 1299012 at bugs.launchpad.net (Robert Clark) Date: Wed, 04 Jun 2014 15:42:14 -0000 Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method chaining References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com> Message-ID: <20140604154214.27702.28740.malone@gac.canonical.com> Is there any possibility to leverage this to offset accountability for certain actions etc? I don't fully understand the impact because I've never looked at chaining before. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1299012 Title: V3 api authentication method chaining Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Security Advisories: Invalid Bug description: When using authentication method chaining for token creation (POST) in Keystone V3 api , it is possible to use authentication credentials for two different users . For example, if i have an existing token for a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier for demo tenant) and i have a user say 'test131' in admin tenant Now i can make an authentication call using auth method chaining { "auth":{ "identity":{ "methods":[ "password", "token" ], "token":{ "id":"6bb934a0120f097a32b5d3cc71f83beb" }, "password":{ "user":{ "domain":{ "id":"default" }, "name":"test131", "password":"test131" } } } } } The call will succeed even though two different users authentication credentials are used. The generated token will get properties of test131 user although the expirary date is set by demo user token. If we change the methods sequence, the generated token will get all properties from demo users token. This is an undesired security behaviour - token should not be allowed to generate using credentials from two different users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299012/+subscriptions From 1290486 at bugs.launchpad.net Wed Jun 4 16:13:55 2014 From: 1290486 at bugs.launchpad.net (Alan Pevec) Date: Wed, 04 Jun 2014 16:13:55 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140604161355.28011.85781.launchpad@gac.canonical.com> ** Also affects: neutron/icehouse Importance: Undecided Status: New ** Changed in: neutron/icehouse Importance: Undecided => High ** Changed in: neutron/icehouse Status: New => In Progress ** Changed in: neutron/icehouse Assignee: (unassigned) => Kyle Mestery (mestery) ** Changed in: neutron/icehouse Milestone: None => 2014.1.1 ** Tags removed: icehouse-backport-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Fix Committed Status in neutron icehouse series: In Progress Status in tripleo - openstack on openstack: Fix Committed Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From 1299012 at bugs.launchpad.net Wed Jun 4 16:42:37 2014 From: 1299012 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 04 Jun 2014 16:42:37 -0000 Subject: [Openstack-security] [Bug 1299012] Related fix proposed to keystone (master) References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com> Message-ID: <20140604164237.5670.77077.malone@soybean.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/97852 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1299012 Title: V3 api authentication method chaining Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Security Advisories: Invalid Bug description: When using authentication method chaining for token creation (POST) in Keystone V3 api , it is possible to use authentication credentials for two different users . For example, if i have an existing token for a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier for demo tenant) and i have a user say 'test131' in admin tenant Now i can make an authentication call using auth method chaining { "auth":{ "identity":{ "methods":[ "password", "token" ], "token":{ "id":"6bb934a0120f097a32b5d3cc71f83beb" }, "password":{ "user":{ "domain":{ "id":"default" }, "name":"test131", "password":"test131" } } } } } The call will succeed even though two different users authentication credentials are used. The generated token will get properties of test131 user although the expirary date is set by demo user token. If we change the methods sequence, the generated token will get all properties from demo users token. This is an undesired security behaviour - token should not be allowed to generate using credentials from two different users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299012/+subscriptions From 1299012 at bugs.launchpad.net Wed Jun 4 17:02:08 2014 From: 1299012 at bugs.launchpad.net (Guang Yee) Date: Wed, 04 Jun 2014 17:02:08 -0000 Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method chaining References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com> Message-ID: <20140604170208.4616.11954.malone@soybean.canonical.com> @Robert Clark, not sure if I understand your question. Comment #3 suggested if one does not properly setup their authorization policy, this could be problematic. For example, "some_api": "auth_method: token and auth_method: password and user_id:%(user_id)s", where token and password methods are obtained using the combined credentials. But this is not something we support in OpenStack right now. We don't populate the auth method in auth_context which used for policy check. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1299012 Title: V3 api authentication method chaining Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Security Advisories: Invalid Bug description: When using authentication method chaining for token creation (POST) in Keystone V3 api , it is possible to use authentication credentials for two different users . For example, if i have an existing token for a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier for demo tenant) and i have a user say 'test131' in admin tenant Now i can make an authentication call using auth method chaining { "auth":{ "identity":{ "methods":[ "password", "token" ], "token":{ "id":"6bb934a0120f097a32b5d3cc71f83beb" }, "password":{ "user":{ "domain":{ "id":"default" }, "name":"test131", "password":"test131" } } } } } The call will succeed even though two different users authentication credentials are used. The generated token will get properties of test131 user although the expirary date is set by demo user token. If we change the methods sequence, the generated token will get all properties from demo users token. This is an undesired security behaviour - token should not be allowed to generate using credentials from two different users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299012/+subscriptions From robert.clark at hp.com Wed Jun 4 17:55:20 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 4 Jun 2014 17:55:20 +0000 Subject: [Openstack-security] Whole block of padding? Message-ID: Can someone sanity check this please? https://bugs.launchpad.net/oslo/+bug/1326474 -Rob From dmccowan at cisco.com Wed Jun 4 20:54:46 2014 From: dmccowan at cisco.com (Dave McCowan) Date: Wed, 04 Jun 2014 20:54:46 -0000 Subject: [Openstack-security] [Bug 1326474] Re: crypto/utils.py may use too much padding References: <20140604175430.27948.44935.malonedeb@gac.canonical.com> Message-ID: <20140604205446.20605.95508.malone@chaenomeles.canonical.com> Agreed. The code is working as intended. If the message is 256 bytes long, add one byte for length and you have to send at least 257 bytes. You then need 255 bytes of pad to bring the result up to the 512 byte boundary. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1326474 Title: crypto/utils.py may use too much padding Status in Oslo - a Library of Common OpenStack Code: New Bug description: I've been reviewing some of the crypto code available in OpenStack and noticed something interesting in the padding of common/crypto/utils.py. If the message length is the same as the cipher block size an entire extra block of padding is sent along with the message, I'm not sure if this is desired behaviour (if it is, this bug is invalid) but it certainly doesn't seem quite right. If the message length is ever the same as the boundary size ( % 256) then an entirely extra block of padding will be applied: ---code--- r = len(msg) % self.cipher.block_size padlen = self.cipher.block_size - r - 1 msg += b'\x00' * padlen msg += bchr(padlen) ---/code--- So if our msg length is 256,512,,, then 'r' will be 0 padlen will be 256-0-1 or 255 msg gets 255 * b'\x00' added and then the number 255 tagged on the end. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions From bdpayne at acm.org Wed Jun 4 21:20:43 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 04 Jun 2014 21:20:43 -0000 Subject: [Openstack-security] [Bug 1326474] Re: crypto/utils.py may use too much padding References: <20140604175430.27948.44935.malonedeb@gac.canonical.com> Message-ID: <20140604212043.27501.53327.malone@gac.canonical.com> Yes, I agree with the other notes here that this sounds like the correct behavior. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1326474 Title: crypto/utils.py may use too much padding Status in Oslo - a Library of Common OpenStack Code: New Bug description: I've been reviewing some of the crypto code available in OpenStack and noticed something interesting in the padding of common/crypto/utils.py. If the message length is the same as the cipher block size an entire extra block of padding is sent along with the message, I'm not sure if this is desired behaviour (if it is, this bug is invalid) but it certainly doesn't seem quite right. If the message length is ever the same as the boundary size ( % 256) then an entirely extra block of padding will be applied: ---code--- r = len(msg) % self.cipher.block_size padlen = self.cipher.block_size - r - 1 msg += b'\x00' * padlen msg += bchr(padlen) ---/code--- So if our msg length is 256,512,,, then 'r' will be 0 padlen will be 256-0-1 or 255 msg gets 255 * b'\x00' added and then the number 255 tagged on the end. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions From 1326474 at bugs.launchpad.net Wed Jun 4 17:54:30 2014 From: 1326474 at bugs.launchpad.net (Robert Clark) Date: Wed, 04 Jun 2014 17:54:30 -0000 Subject: [Openstack-security] [Bug 1326474] [NEW] crypto/utils.py may use too much padding References: <20140604175430.27948.44935.malonedeb@gac.canonical.com> Message-ID: <20140604175430.27948.44935.malonedeb@gac.canonical.com> Public bug reported: I've been reviewing some of the crypto code available in OpenStack and noticed something interesting in the padding of common/crypto/utils.py. If the message length is the same as the cipher block size an entire extra block of padding is sent along with the message, I'm not sure if this is desired behaviour (if it is, this bug is invalid) but it certainly doesn't seem quite right. If the message length is ever the same as the boundary size ( % 256) then an entirely extra block of padding will be applied: ---code--- r = len(msg) % self.cipher.block_size padlen = self.cipher.block_size - r - 1 msg += b'\x00' * padlen msg += bchr(padlen) ---/code--- So if our msg length is 256,512,,, then 'r' will be 0 padlen will be 256-0-1 or 255 msg gets 255 * b'\x00' added and then the number 255 tagged on the end. ** Affects: oslo Importance: Undecided Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1326474 Title: crypto/utils.py may use too much padding Status in Oslo - a Library of Common OpenStack Code: New Bug description: I've been reviewing some of the crypto code available in OpenStack and noticed something interesting in the padding of common/crypto/utils.py. If the message length is the same as the cipher block size an entire extra block of padding is sent along with the message, I'm not sure if this is desired behaviour (if it is, this bug is invalid) but it certainly doesn't seem quite right. If the message length is ever the same as the boundary size ( % 256) then an entirely extra block of padding will be applied: ---code--- r = len(msg) % self.cipher.block_size padlen = self.cipher.block_size - r - 1 msg += b'\x00' * padlen msg += bchr(padlen) ---/code--- So if our msg length is 256,512,,, then 'r' will be 0 padlen will be 256-0-1 or 255 msg gets 255 * b'\x00' added and then the number 255 tagged on the end. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions From 1326474 at bugs.launchpad.net Wed Jun 4 19:09:22 2014 From: 1326474 at bugs.launchpad.net (Abu Shohel Ahmed) Date: Wed, 04 Jun 2014 19:09:22 -0000 Subject: [Openstack-security] [Bug 1326474] Re: crypto/utils.py may use too much padding References: <20140604175430.27948.44935.malonedeb@gac.canonical.com> Message-ID: <20140604190922.3953.817.malone@soybean.canonical.com> Padding is required for messages in which msg length is not always guaranteed to be exact multiple of block_size. For cases, when len(msg) % block_size == 0 , still have to add the pad with message during encryption because we have to add the padlen byte. The decryption logic cannot work without knowing a common format of padding (distinguish padded or not). This is the desired behaviour. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1326474 Title: crypto/utils.py may use too much padding Status in Oslo - a Library of Common OpenStack Code: New Bug description: I've been reviewing some of the crypto code available in OpenStack and noticed something interesting in the padding of common/crypto/utils.py. If the message length is the same as the cipher block size an entire extra block of padding is sent along with the message, I'm not sure if this is desired behaviour (if it is, this bug is invalid) but it certainly doesn't seem quite right. If the message length is ever the same as the boundary size ( % 256) then an entirely extra block of padding will be applied: ---code--- r = len(msg) % self.cipher.block_size padlen = self.cipher.block_size - r - 1 msg += b'\x00' * padlen msg += bchr(padlen) ---/code--- So if our msg length is 256,512,,, then 'r' will be 0 padlen will be 256-0-1 or 255 msg gets 255 * b'\x00' added and then the number 255 tagged on the end. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions From 1326474 at bugs.launchpad.net Wed Jun 4 22:11:02 2014 From: 1326474 at bugs.launchpad.net (Robert Clark) Date: Wed, 04 Jun 2014 22:11:02 -0000 Subject: [Openstack-security] [Bug 1326474] Re: crypto/utils.py may use too much padding References: <20140604175430.27948.44935.malonedeb@gac.canonical.com> Message-ID: <20140604221102.27213.54678.malone@gac.canonical.com> Thanks for the clarification guys, this makes sense to me, fwiw I did ask about this in the oslo room first and the suggestion was that I log a bug to get it double checked. Cheers -Rob ** Changed in: oslo Status: New => 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/1326474 Title: crypto/utils.py may use too much padding Status in Oslo - a Library of Common OpenStack Code: Invalid Bug description: I've been reviewing some of the crypto code available in OpenStack and noticed something interesting in the padding of common/crypto/utils.py. If the message length is the same as the cipher block size an entire extra block of padding is sent along with the message, I'm not sure if this is desired behaviour (if it is, this bug is invalid) but it certainly doesn't seem quite right. If the message length is ever the same as the boundary size ( % 256) then an entirely extra block of padding will be applied: ---code--- r = len(msg) % self.cipher.block_size padlen = self.cipher.block_size - r - 1 msg += b'\x00' * padlen msg += bchr(padlen) ---/code--- So if our msg length is 256,512,,, then 'r' will be 0 padlen will be 256-0-1 or 255 msg gets 255 * b'\x00' added and then the number 255 tagged on the end. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions From morgan.fainberg at gmail.com Wed Jun 4 23:05:42 2014 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 04 Jun 2014 23:05:42 -0000 Subject: [Openstack-security] [Bug 890411] Re: Tenant role conflicts/overlaps can be a security issue References: <20111114203901.27657.70484.malonedeb@soybean.canonical.com> Message-ID: <20140604230542.25944.44900.malone@wampee.canonical.com> This stems from a design decision, and isn't really a bug. This is more of a lack of a feature. This should be written up as a specification: https://git.openstack.org/cgit/openstack/keystone-specs and treated like a new feature. Marking this bug as "wont fix" ** Changed in: keystone Status: Confirmed => 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/890411 Title: Tenant role conflicts/overlaps can be a security issue Status in OpenStack Identity (Keystone): Invalid Bug description: During the validate token call all the tenant roles (associated with the tenant scoped token) are returned to the middle-ware component and then passed along in the X_ROLES header to the OS service for consumption. In the case were more than one OS service are bound to the same tenant (e.g. Swift and Nova, or Nova 1 and Nova 2), a user with particular role for one service, lets just say the 'Admin' role will now also have the 'Admin' role in the second service. This is because roles are currently only scoped to the tenant level. The middle-ware just takes all returned tenant roles and stuffs them into the X_ROLES header regardless of the actual service the middle-ware is protecting. A quick fix to this problem would be to change the validate token interfaces (GET/HEAD /tokens/{tokenId}) to require a {serviceId} filter... so something like GET /tokens/{tokenId}?serviceId={serviceId}. The Keystone service would then only return roles in the response that are tied to that specific serviceId. If the serviceId was not provided, or was invalid, or no roles where found for that serviceId, then a 401 would be returned. Future Keystone work could consider allowing to filter down to the {endpointId}, but for such a change it would require a data model change to allow serviceIds to be defined on endpoint references.... Not to mention more API changes. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/890411/+subscriptions From morgan.fainberg at gmail.com Wed Jun 4 23:06:09 2014 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 04 Jun 2014 23:06:09 -0000 Subject: [Openstack-security] [Bug 890411] Re: Tenant role conflicts/overlaps can be a security issue References: <20111114203901.27657.70484.malonedeb@soybean.canonical.com> Message-ID: <20140604230609.27600.74533.malone@gac.canonical.com> Correction, marked as 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/890411 Title: Tenant role conflicts/overlaps can be a security issue Status in OpenStack Identity (Keystone): Invalid Bug description: During the validate token call all the tenant roles (associated with the tenant scoped token) are returned to the middle-ware component and then passed along in the X_ROLES header to the OS service for consumption. In the case were more than one OS service are bound to the same tenant (e.g. Swift and Nova, or Nova 1 and Nova 2), a user with particular role for one service, lets just say the 'Admin' role will now also have the 'Admin' role in the second service. This is because roles are currently only scoped to the tenant level. The middle-ware just takes all returned tenant roles and stuffs them into the X_ROLES header regardless of the actual service the middle-ware is protecting. A quick fix to this problem would be to change the validate token interfaces (GET/HEAD /tokens/{tokenId}) to require a {serviceId} filter... so something like GET /tokens/{tokenId}?serviceId={serviceId}. The Keystone service would then only return roles in the response that are tied to that specific serviceId. If the serviceId was not provided, or was invalid, or no roles where found for that serviceId, then a 401 would be returned. Future Keystone work could consider allowing to filter down to the {endpointId}, but for such a change it would require a data model change to allow serviceIds to be defined on endpoint references.... Not to mention more API changes. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/890411/+subscriptions From morgan.fainberg at gmail.com Wed Jun 4 23:23:55 2014 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Wed, 04 Jun 2014 23:23:55 -0000 Subject: [Openstack-security] [Bug 1174608] Re: [OSSA 2013-010] Insecure directory creation for signing References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com> Message-ID: <20140604232358.27834.43216.launchpad@gac.canonical.com> ** Changed in: keystone/folsom Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174608 Title: [OSSA 2013-010] Insecure directory creation for signing Status in OpenStack Identity (Keystone): Invalid Status in Keystone folsom series: Fix Released Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) folsom series: Fix Committed Status in OpenStack Compute (nova) grizzly series: Fix Released Status in OpenStack Security Advisories: Fix Released Status in Python client library for Keystone: Fix Released Bug description: Originally found by Grant Murphy (gmurphy at redhat.com): The signing directory is used to store the signing certificates and the default location for this directory is: signing_dir = /tmp/keystone-signing-nova In the file: keystone/middleware/auth_token.py During the initialization of the AuthMiddleware the following operations are made for the signing directory: IF the directory exists but cannot be written to a configuration error is raised. ELSE IF the directory doesn't exist, create it. NEXT chmod permisions(stat.S_IRWXU) to the signing_directory AFAICT The signing certificates used in validation will only be fetched from the keystone if the cms_verify action raises an exception because the certificate file is missing from the signing directory. This means that if an attacker populated the /tmp/keystone-signing-nova with the appropriate files for signautre verification they could potentially issue forged tokens which would be validated by the middleware. As: - The directory location deterministic. (default for glance, nova) - *If the directory already exists it is reused* To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions From rpodolyaka at mirantis.com Thu Jun 5 12:32:03 2014 From: rpodolyaka at mirantis.com (Roman Podoliaka) Date: Thu, 05 Jun 2014 12:32:03 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140605123203.27948.84736.malone@gac.canonical.com> Still seeing this with neutron as of commit 53b701a3f91530c9462a9cb0690aaf68efd45f6d (ubuntu saucy, linux 3.11, openvswitch-server 1.10.2) Steps to reproduce: 1. Run devtest.sh 2. Start pinging a user VM using the floating ip. 3. ssh to the controller node. 4. Do: sudo service openvswitch-switch restart The user VM becomes unreachable until neutron-openvswitch-agent is restarted on the controller node. ** Changed in: tripleo Status: Fix Committed => Triaged -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Fix Committed Status in neutron icehouse series: In Progress Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From rpodolyaka at mirantis.com Thu Jun 5 12:51:26 2014 From: rpodolyaka at mirantis.com (Roman Podoliaka) Date: Thu, 05 Jun 2014 12:51:26 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140605125128.27977.96181.launchpad@gac.canonical.com> ** Changed in: neutron Status: Fix Committed => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Confirmed Status in neutron icehouse series: In Progress Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From rpodolyaka at mirantis.com Thu Jun 5 15:39:09 2014 From: rpodolyaka at mirantis.com (Roman Podoliaka) Date: Thu, 05 Jun 2014 15:39:09 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140605153909.4143.56712.malone@soybean.canonical.com> Looks like ovs periodically crashes: http://paste.openstack.org/show/82970/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Confirmed Status in neutron icehouse series: In Progress Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From 1326474 at bugs.launchpad.net Thu Jun 5 17:06:27 2014 From: 1326474 at bugs.launchpad.net (Robert Clark) Date: Thu, 05 Jun 2014 17:06:27 -0000 Subject: [Openstack-security] [Bug 1326474] Re: crypto/utils.py may use too much padding References: <20140604175430.27948.44935.malonedeb@gac.canonical.com> <20140604221102.27213.54678.malone@gac.canonical.com> Message-ID: In the case of 128 bit AES would this not send twice as much padding as needed or is the schema such that padding is always to the nearest 256 ? > -----Original Message----- > From: bounces at canonical.com [mailto:bounces at canonical.com] On > Behalf Of Robert Clark > Sent: 04 June 2014 23:11 > To: Clark, Robert Graham > Subject: [Bug 1326474] Re: crypto/utils.py may use too much padding > > Thanks for the clarification guys, this makes sense to me, fwiw I did > ask > about this in the oslo room first and the suggestion was that I log a > bug to > get it double checked. > > Cheers > -Rob > > ** Changed in: oslo > Status: New => Invalid > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1326474 > > Title: > crypto/utils.py may use too much padding > > Status in Oslo - a Library of Common OpenStack Code: > Invalid > > Bug description: > I've been reviewing some of the crypto code available in OpenStack and > noticed something interesting in the padding of > common/crypto/utils.py. > > > If the message length is the same as the cipher block size an entire > extra > block of padding is sent along with the message, I'm not sure if this is > desired behaviour (if it is, this bug is invalid) but it certainly > doesn't seem > quite right. > > If the message length is ever the same as the boundary size ( % 256) > then an entirely extra block of padding will be applied: > > ---code--- > r = len(msg) % self.cipher.block_size > padlen = self.cipher.block_size - r - 1 > msg += b'\x00' * padlen > msg += bchr(padlen) > ---/code--- > > So if our msg length is 256,512,,, then 'r' will be 0 > padlen will be 256-0-1 or 255 > msg gets 255 * b'\x00' added and then the number 255 tagged on the > end. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1326474 Title: crypto/utils.py may use too much padding Status in Oslo - a Library of Common OpenStack Code: Invalid Bug description: I've been reviewing some of the crypto code available in OpenStack and noticed something interesting in the padding of common/crypto/utils.py. If the message length is the same as the cipher block size an entire extra block of padding is sent along with the message, I'm not sure if this is desired behaviour (if it is, this bug is invalid) but it certainly doesn't seem quite right. If the message length is ever the same as the boundary size ( % 256) then an entirely extra block of padding will be applied: ---code--- r = len(msg) % self.cipher.block_size padlen = self.cipher.block_size - r - 1 msg += b'\x00' * padlen msg += bchr(padlen) ---/code--- So if our msg length is 256,512,,, then 'r' will be 0 padlen will be 256-0-1 or 255 msg gets 255 * b'\x00' added and then the number 255 tagged on the end. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions From jhfeng1 at gmail.com Thu Jun 5 17:26:35 2014 From: jhfeng1 at gmail.com (Jeff Feng) Date: Thu, 05 Jun 2014 12:26:35 -0500 Subject: [Openstack-security] [Bug 1326474] Re: crypto/utils.py may use too much padding In-Reply-To: References: <20140604175430.27948.44935.malonedeb@gac.canonical.com> <20140604221102.27213.54678.malone@gac.canonical.com> Message-ID: <5390A84B.3040202@gmail.com> AES block size is 16 bytes. I don't understand why the padding size would > 16. cipher.block_size should equal to 16. - Jeff On 6/5/2014 12:06 PM, Robert Clark wrote: > In the case of 128 bit AES would this not send twice as much padding as > needed or is the schema such that padding is always to the nearest 256 ? > >> -----Original Message----- >> From: bounces at canonical.com [mailto:bounces at canonical.com] On >> Behalf Of Robert Clark >> Sent: 04 June 2014 23:11 >> To: Clark, Robert Graham >> Subject: [Bug 1326474] Re: crypto/utils.py may use too much padding >> >> Thanks for the clarification guys, this makes sense to me, fwiw I did >> ask >> about this in the oslo room first and the suggestion was that I log a >> bug to >> get it double checked. >> >> Cheers >> -Rob >> >> ** Changed in: oslo >> Status: New => Invalid >> >> -- >> You received this bug notification because you are subscribed to the bug >> report. >> https://bugs.launchpad.net/bugs/1326474 >> >> Title: >> crypto/utils.py may use too much padding >> >> Status in Oslo - a Library of Common OpenStack Code: >> Invalid >> >> Bug description: >> I've been reviewing some of the crypto code available in OpenStack and >> noticed something interesting in the padding of >> common/crypto/utils.py. >> >> >> If the message length is the same as the cipher block size an entire >> extra >> block of padding is sent along with the message, I'm not sure if this is >> desired behaviour (if it is, this bug is invalid) but it certainly >> doesn't seem >> quite right. >> >> If the message length is ever the same as the boundary size ( % 256) >> then an entirely extra block of padding will be applied: >> >> ---code--- >> r = len(msg) % self.cipher.block_size >> padlen = self.cipher.block_size - r - 1 >> msg += b'\x00' * padlen >> msg += bchr(padlen) >> ---/code--- >> >> So if our msg length is 256,512,,, then 'r' will be 0 >> padlen will be 256-0-1 or 255 >> msg gets 255 * b'\x00' added and then the number 255 tagged on the >> end. >> >> To manage notifications about this bug go to: >> https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions From noloader at gmail.com Thu Jun 5 17:52:11 2014 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 5 Jun 2014 13:52:11 -0400 Subject: [Openstack-security] [Bug 1326474] Re: crypto/utils.py may use too much padding In-Reply-To: <5390A84B.3040202@gmail.com> References: <20140604175430.27948.44935.malonedeb@gac.canonical.com> <20140604221102.27213.54678.malone@gac.canonical.com> <5390A84B.3040202@gmail.com> Message-ID: On Thu, Jun 5, 2014 at 1:26 PM, Jeff Feng wrote: > AES block size is 16 bytes. I don't understand why the padding size would > > 16. > cipher.block_size should equal to 16. > They might be trying to hide the length of the plain text. But its not readily obvious since there does not appear to be design documentation or comments in the source code. While its unusual, I'm not sure its incorrect in the context of cryptography. See, for example, "On Hiding a Plaintext Length by Preencryption", http://cihangir.forgottenlance.com/papers/lengthhiding-corrected.pdf. Jeff > On 6/5/2014 12:06 PM, Robert Clark wrote: >> >> In the case of 128 bit AES would this not send twice as much padding as >> needed or is the schema such that padding is always to the nearest 256 ? >> >>> -----Original Message----- >>> From: bounces at canonical.com [mailto:bounces at canonical.com] On >>> Behalf Of Robert Clark >>> Sent: 04 June 2014 23:11 >>> To: Clark, Robert Graham >>> Subject: [Bug 1326474] Re: crypto/utils.py may use too much padding >>> >>> Thanks for the clarification guys, this makes sense to me, fwiw I did >>> ask >>> about this in the oslo room first and the suggestion was that I log a >>> bug to >>> get it double checked. >>> >>> Cheers >>> -Rob >>> >>> ** Changed in: oslo >>> Status: New => Invalid >>> >>> -- >>> You received this bug notification because you are subscribed to the bug >>> report. >>> https://bugs.launchpad.net/bugs/1326474 >>> >>> Title: >>> crypto/utils.py may use too much padding >>> >>> Status in Oslo - a Library of Common OpenStack Code: >>> Invalid >>> >>> Bug description: >>> I've been reviewing some of the crypto code available in OpenStack and >>> noticed something interesting in the padding of >>> common/crypto/utils.py. >>> >>> >>> If the message length is the same as the cipher block size an entire >>> extra >>> block of padding is sent along with the message, I'm not sure if this is >>> desired behaviour (if it is, this bug is invalid) but it certainly >>> doesn't seem >>> quite right. >>> >>> If the message length is ever the same as the boundary size ( % 256) >>> then an entirely extra block of padding will be applied: >>> >>> ---code--- >>> r = len(msg) % self.cipher.block_size >>> padlen = self.cipher.block_size - r - 1 >>> msg += b'\x00' * padlen >>> msg += bchr(padlen) >>> ---/code--- >>> >>> So if our msg length is 256,512,,, then 'r' will be 0 >>> padlen will be 256-0-1 or 255 >>> msg gets 255 * b'\x00' added and then the number 255 tagged on the >>> end. >>> >>> To manage notifications about this bug go to: >>> https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions From sriram at sriramhere.com Thu Jun 5 18:51:18 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 5 Jun 2014 11:51:18 -0700 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda Message-ID: Rob/ OSSG: Per our discussions today at the weekly meetup, I would like to start discussions on the meetup agendas. I am listing out with the projects that I am aware of, please add/ edit appropriately. I might be completely wrong, i filled in to get things rolling. *Etherpad* https://etherpad.openstack.org/p/ossg-juno-meetup *List of Projects* Topic Importance Size Interested On Going (OSSNs, OSSAs) High Medium Baseline Security Review of Projects (not sure if I imagined this, or it was talked about anywhere) Medium Medium OSSG Book Cleanup High Large Threat Modeling High Medium Security Anti-Patterns Medium Small Library Audit Medium Medium Fuzz Testing Medium Small Please chime in (need help in formatting in to a table at etherpad please) -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1319643 at bugs.launchpad.net Thu Jun 5 19:30:55 2014 From: 1319643 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Jun 2014 19:30:55 -0000 Subject: [Openstack-security] [Bug 1319643] Re: Using random.random() should not be used to generate randomness used for security reasons References: <20140515052815.2825.61709.malonedeb@wampee.canonical.com> Message-ID: <20140605193055.4116.52827.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/96738 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=6791fa41e06beab23bc7832a3bfa9ab28adf1e34 Submitter: Jenkins Branch: master commit 6791fa41e06beab23bc7832a3bfa9ab28adf1e34 Author: Ollie Leahy Date: Fri May 30 11:57:02 2014 +0000 Use os.urandom in volume transfer This patch replaces a call to random.random() with a call to os.urandom(), which generates a higher quality random number. Closes-Bug: #1319643 Change-Id: Ifaa2216d4905f5286884629beac52b25249d621f ** Changed in: cinder 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/1319643 Title: Using random.random() should not be used to generate randomness used for security reasons Status in Cinder: Fix Committed Status in OpenStack Security Advisories: Won't Fix Bug description: In cinder code : /cinder/transfer/api.py . Below line of code used random.random() to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. Could we use a crytographic randomness generator to provide sufficient entropy to instead of it? rndstr = "" random.seed(datetime.datetime.now().microsecond) while len(rndstr) < length: rndstr += hashlib.sha224(str(random.random())).hexdigest() ---------------> This line has described issues. return rndstr[0:length] To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1319643/+subscriptions From Travis_McPeak at symantec.com Thu Jun 5 19:58:54 2014 From: Travis_McPeak at symantec.com (Travis McPeak) Date: Thu, 5 Jun 2014 12:58:54 -0700 Subject: [Openstack-security] Python Crypto libs Trustability Message-ID: Hi all, I¹ve been thinking about some of the crypto libraries that are being used in OpenStack projects, specifically how much confidence should we have in them. It has occurred to me that we don¹t really know if they have been audited, or even if anybody has taken a hard look at them. We know that security of a system is only as good as the weakest link, but what about these backbones of security that we are relying on? Have they been vetted? I have started an etherpad: https://etherpad.openstack.org/p/CryptoLibraryInventory to track this very issue. Please contribute if you know anything about any of the libraries listed. If there are libraries that I haven¹t listed, please add them. I think with the collective knowledge of the community, we can begin to build some clarity around which libraries are more ³trustworthy² than others, and how much we can trust them. Thanks, -Travis On 6/5/14, 5:00 AM, "openstack-security-request at lists.openstack.org" wrote: >Send Openstack-security mailing list submissions to > openstack-security at lists.openstack.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > >or, via email, send a message with subject or body 'help' to > openstack-security-request at lists.openstack.org > >You can reach the person managing the list at > openstack-security-owner at lists.openstack.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Openstack-security digest..." > > >Today's Topics: > > 1. [Bug 1174608] Re: [OSSA 2013-010] Insecure directory creation > for signing (Morgan Fainberg) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 04 Jun 2014 23:23:55 -0000 >From: Morgan Fainberg >To: openstack-security at lists.openstack.org >Subject: [Openstack-security] [Bug 1174608] Re: [OSSA 2013-010] > Insecure directory creation for signing >Message-ID: <20140604232358.27834.43216.launchpad at gac.canonical.com> >Content-Type: text/plain; charset="utf-8" > >** Changed in: keystone/folsom > Status: Fix Committed => Fix Released > >-- >You received this bug notification because you are a member of OpenStack >Security Group, which is subscribed to OpenStack. >https://bugs.launchpad.net/bugs/1174608 > >Title: > [OSSA 2013-010] Insecure directory creation for signing > >Status in OpenStack Identity (Keystone): > Invalid >Status in Keystone folsom series: > Fix Released >Status in OpenStack Compute (Nova): > Fix Released >Status in OpenStack Compute (nova) folsom series: > Fix Committed >Status in OpenStack Compute (nova) grizzly series: > Fix Released >Status in OpenStack Security Advisories: > Fix Released >Status in Python client library for Keystone: > Fix Released > >Bug description: > Originally found by Grant Murphy (gmurphy at redhat.com): > > The signing directory is used to store the signing certificates > and the default location for this directory is: > > signing_dir = /tmp/keystone-signing-nova > > In the file: > > keystone/middleware/auth_token.py > > During the initialization of the AuthMiddleware the following > operations are made for the signing directory: > > IF the directory exists but cannot be written to a configuration >error is raised. > ELSE IF the directory doesn't exist, create it. > NEXT chmod permisions(stat.S_IRWXU) to the signing_directory > > AFAICT The signing certificates used in validation will only be > fetched from the keystone if the cms_verify action raises an exception > because the certificate file is missing from the signing directory. > > This means that if an attacker populated the /tmp/keystone-signing-nova > with the appropriate files for signautre verification they could >potentially > issue forged tokens which would be validated by the middleware. As: > - The directory location deterministic. (default for glance, nova) > - *If the directory already exists it is reused* > >To manage notifications about this bug go to: >https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions > > > >------------------------------ > >_______________________________________________ >Openstack-security mailing list >Openstack-security at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > >End of Openstack-security Digest, Vol 16, Issue 10 >************************************************** From tristan.cacqueray at enovance.com Thu Jun 5 20:00:26 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Thu, 05 Jun 2014 20:00:26 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140605200026.4116.5895.malone@soybean.canonical.com> @Gordon, so I have a couple question for the impact description draft. >From the bug description, it appears that the leaked "request.HTTP_X_AUTH_TOKEN: 4724" is not the same than the one provided in the curl command "-H 'X-Auth-Token: 258ab" So is the leak the token of the user requesting the notifier, or is it the admin_token defined in [filter:authtoken] configuration ? The conditions for this leak to happen is when the notifier middleware is set after authtoken, which is not by default right ? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From jarret.raim at RACKSPACE.COM Thu Jun 5 20:58:08 2014 From: jarret.raim at RACKSPACE.COM (Jarret Raim) Date: Thu, 5 Jun 2014 20:58:08 +0000 Subject: [Openstack-security] Python Crypto libs Trustability In-Reply-To: Message-ID: Travis, Several of us have been working along these lines. We presented on the topic at PyCon this year. You can see the slides here: http://www.slideshare.net/jarito030506/state-of-crypto-in-python?qid=c557d2 b4-d080-4696-a467-6050cd189a3d&v=qf1&b=&from_search=1 And a video of the presentation here: http://pyvideo.org/video/2583/the-state-of-crypto-in-python We do have a goal of having cryptography be audited it at some point in the future. However, since cryptography just exposes functionality of C backends, most / all of the crypto heavy lifting happens in C land. That is where the most value for auditing will come in. I've included Paul and Alex, both of whom work heavily on the cryptography package. -- Jarret Raim @jarretraim On 6/5/14, 2:58 PM, "Travis McPeak" wrote: >Hi all, > >I¹ve been thinking about some of the crypto libraries that are being used >in OpenStack projects, specifically how much confidence should we have in >them. It has occurred to me that we don¹t really know if they have been >audited, or even if anybody has taken a hard look at them. We know that >security of a system is only as good as the weakest link, but what about >these backbones of security that we are relying on? Have they been >vetted? > >I have started an etherpad: >https://etherpad.openstack.org/p/CryptoLibraryInventory to track this very >issue. Please contribute if you know anything about any of the libraries >listed. If there are libraries that I haven¹t listed, please add them. > >I think with the collective knowledge of the community, we can begin to >build some clarity around which libraries are more ³trustworthy² than >others, and how much we can trust them. > >Thanks, > -Travis > > > > >On 6/5/14, 5:00 AM, "openstack-security-request at lists.openstack.org" > wrote: > >>Send Openstack-security mailing list submissions to >> openstack-security at lists.openstack.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >>or, via email, send a message with subject or body 'help' to >> openstack-security-request at lists.openstack.org >> >>You can reach the person managing the list at >> openstack-security-owner at lists.openstack.org >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of Openstack-security digest..." >> >> >>Today's Topics: >> >> 1. [Bug 1174608] Re: [OSSA 2013-010] Insecure directory creation >> for signing (Morgan Fainberg) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Wed, 04 Jun 2014 23:23:55 -0000 >>From: Morgan Fainberg >>To: openstack-security at lists.openstack.org >>Subject: [Openstack-security] [Bug 1174608] Re: [OSSA 2013-010] >> Insecure directory creation for signing >>Message-ID: <20140604232358.27834.43216.launchpad at gac.canonical.com> >>Content-Type: text/plain; charset="utf-8" >> >>** Changed in: keystone/folsom >> Status: Fix Committed => Fix Released >> >>-- >>You received this bug notification because you are a member of OpenStack >>Security Group, which is subscribed to OpenStack. >>https://bugs.launchpad.net/bugs/1174608 >> >>Title: >> [OSSA 2013-010] Insecure directory creation for signing >> >>Status in OpenStack Identity (Keystone): >> Invalid >>Status in Keystone folsom series: >> Fix Released >>Status in OpenStack Compute (Nova): >> Fix Released >>Status in OpenStack Compute (nova) folsom series: >> Fix Committed >>Status in OpenStack Compute (nova) grizzly series: >> Fix Released >>Status in OpenStack Security Advisories: >> Fix Released >>Status in Python client library for Keystone: >> Fix Released >> >>Bug description: >> Originally found by Grant Murphy (gmurphy at redhat.com): >> >> The signing directory is used to store the signing certificates >> and the default location for this directory is: >> >> signing_dir = /tmp/keystone-signing-nova >> >> In the file: >> >> keystone/middleware/auth_token.py >> >> During the initialization of the AuthMiddleware the following >> operations are made for the signing directory: >> >> IF the directory exists but cannot be written to a configuration >>error is raised. >> ELSE IF the directory doesn't exist, create it. >> NEXT chmod permisions(stat.S_IRWXU) to the signing_directory >> >> AFAICT The signing certificates used in validation will only be >> fetched from the keystone if the cms_verify action raises an exception >> because the certificate file is missing from the signing directory. >> >> This means that if an attacker populated the /tmp/keystone-signing-nova >> with the appropriate files for signautre verification they could >>potentially >> issue forged tokens which would be validated by the middleware. As: >> - The directory location deterministic. (default for glance, nova) >> - *If the directory already exists it is reused* >> >>To manage notifications about this bug go to: >>https://bugs.launchpad.net/keystone/+bug/1174608/+subscriptions >> >> >> >>------------------------------ >> >>_______________________________________________ >>Openstack-security mailing list >>Openstack-security at lists.openstack.org >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> >>End of Openstack-security Digest, Vol 16, Issue 10 >>************************************************** > > >_______________________________________________ >Openstack-security mailing list >Openstack-security at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5611 bytes Desc: not available URL: From noloader at gmail.com Thu Jun 5 22:32:07 2014 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 5 Jun 2014 18:32:07 -0400 Subject: [Openstack-security] Python Crypto libs Trustability In-Reply-To: References: Message-ID: On Thu, Jun 5, 2014 at 3:58 PM, Travis McPeak wrote: > Hi all, > > I¹ve been thinking about some of the crypto libraries that are being used > in OpenStack projects, specifically how much confidence should we have in > them. Yes, this is a governance issue. If the third-party library does not meet standards, then it should not be used in OpenStack. Cloud providers also have a governance issue: OpenStack must meet the provider's standards, else the provider cannot use OpenStack. However, there's a transitive property in their that's not readily apparent. Namely, how the risk flows from third-party libraries through OpenStack to the providers. Third-party libraries used to cause me a lot of problems when I was doing risk and security architecture work in the financial sector. > It has occurred to me that we don¹t really know if they have been > audited, or even if anybody has taken a hard look at them. We know that > security of a system is only as good as the weakest link, but what about > these backbones of security that we are relying on? Have they been > vetted? I've looked at pycrypto in the past, and I have a number of open questions. For example, Rob Clark and I were talking about the PRNG in pycrypto before CVE-2013-1445 and CVE-2012-2417 were published. And I seem to recall (but I could be wrong) that an *insecure* fallback is performed by pycrypto's Crypto.Random *if* /dev/urandom is not available. > I have started an etherpad: > https://etherpad.openstack.org/p/CryptoLibraryInventory to track this very > issue. Please contribute if you know anything about any of the libraries > listed. If there are libraries that I haven¹t listed, please add them. That's a good idea. > I think with the collective knowledge of the community, we can begin to > build some clarity around which libraries are more ³trustworthy² than > others, and how much we can trust them. One of the first problems seems to be the lack of a single OpenStack crypto wrapper. That is, there should be an OpenStack.Crypto that provides all the primitives. All source code should call through OpenStack.Crypto. Instead, code sometimes calls into other libraries and sometimes rolls its own stuff. What OpenStack.Crypto wraps or implements is a different issue. But its a good first step to ensure calls are being funneled into audited code. Jeff From gord at live.ca Thu Jun 5 22:47:51 2014 From: gord at live.ca (gordon chung) Date: Thu, 05 Jun 2014 22:47:51 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140605224751.20458.71075.malone@chaenomeles.canonical.com> so the leaked HTTP_X_AUTH_TOKEN value is the one in provided in curl command (i assume the description is using curl command and request object that aren't related)... it is not the admin_token defined in [filter:authtoken] configuration you are correct that the leak happens only if notifier middleware is used after auth_token middleware (which it usually is)... by default the notifier middleware is not enabled in any service. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From gerrit2 at review.openstack.org Thu Jun 5 23:15:01 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 05 Jun 2014 23:15:01 +0000 Subject: [Openstack-security] [stackforge/kite] SecurityImpact review request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80902 Log: commit 33c5b9f2e3174776900938f351d0981b8d467b84 Author: Jamie Lennox Date: Tue Dec 3 12:33:28 2013 +1000 Add cryptographic key storage Adds a layer called Storage on top of the DB. The DB is a simple store retrieve interface and things going through Storage are correctly encrypted and stored to the database. Add some routes to allow setting a key through the storage interface. SecurityImpact Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From noloader at gmail.com Fri Jun 6 01:32:47 2014 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 06 Jun 2014 01:32:47 -0000 Subject: [Openstack-security] [Bug 1319643] Re: Using random.random() should not be used to generate randomness used for security reasons References: <20140515052815.2825.61709.malonedeb@wampee.canonical.com> Message-ID: <20140606013247.20559.508.malone@chaenomeles.canonical.com> Sorry about the late comment here. I think the real problem is this line: random.seed(datetime.datetime.now().microsecond) I think its a problem because there's no entropy in datetime. From Python's source code on seed() (available at http://svn.python.org/projects/python/branches/py3k/Lib/random.py): def seed(self, a=None, version=2): if a is None: try: a = int.from_bytes(_urandom(32), 'big') except NotImplementedError: import time a = int(time.time() * 256) # use fractional seconds if version == 2: if isinstance(a, (str, bytes, bytearray)): if isinstance(a, str): a = a.encode("utf-8") a += _sha512(a).digest() a = int.from_bytes(a, 'big') super().seed(a) self.gauss_next = None As can be seen above, the call to seed() replaces the current seed state with a hash of date/time. And its only hashed, and not mixed with bits from, for example, /dev/urandom. So an attacker can perform an exhaustive search of the keyspace based on the time he observes the transfer. The current construction lacks the PRP notion of security. That is, an adversary can distinguish output from random. *If* the call to random.seed was performed using bits from /dev/urandom, then this would not be a problem. Even keying the hash with bits from /dev/urandom would suffice. Wagner and Goldberg had a lot of fun with this sort of entropy collection in 1996. For completeness, Netscape did a little more than just date/time - they included the PID also. See "Randomness and the Netscape Browser", http://www.cs.berkeley.edu/~daw/papers/ddj- netscape.html. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319643 Title: Using random.random() should not be used to generate randomness used for security reasons Status in Cinder: Fix Committed Status in OpenStack Security Advisories: Won't Fix Bug description: In cinder code : /cinder/transfer/api.py . Below line of code used random.random() to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. Could we use a crytographic randomness generator to provide sufficient entropy to instead of it? rndstr = "" random.seed(datetime.datetime.now().microsecond) while len(rndstr) < length: rndstr += hashlib.sha224(str(random.random())).hexdigest() ---------------> This line has described issues. return rndstr[0:length] To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1319643/+subscriptions From 1320098 at bugs.launchpad.net Fri Jun 6 02:39:55 2014 From: 1320098 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 06 Jun 2014 02:39:55 -0000 Subject: [Openstack-security] [Bug 1320098] Re: neutronclient debug logging includes keystone auth token References: <20140516064420.2758.66631.malonedeb@wampee.canonical.com> Message-ID: <20140606023956.26427.34619.launchpad@wampee.canonical.com> ** Changed in: python-neutronclient Assignee: Feng Ju (jufeng) => Xu Han Peng (xuhanp) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320098 Title: neutronclient debug logging includes keystone auth token Status in Python client library for Neutron: In Progress Bug description: neutronclient is logging the auth token in the nova logs. Since the logs are world-readable, this means anyone user on this system can see the auth token, which they can then use to get OpenStack administrator access. To manage notifications about this bug go to: https://bugs.launchpad.net/python-neutronclient/+bug/1320098/+subscriptions From gexiaoyu at huawei.com Fri Jun 6 02:47:55 2014 From: gexiaoyu at huawei.com (Gexiaoyu) Date: Fri, 6 Jun 2014 02:47:55 +0000 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda In-Reply-To: References: Message-ID: <27C49E3A44E36C42B89B9012C5CF527C21D0C64D@SZXEMA511-MBX.china.huawei.com> What’s the detail of the project “OSSG Book Cleanup”, do we intend to add new content/feature to security guide or just revise it? Thanks, Xiaoyu From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: Friday, June 06, 2014 2:51 AM To: openstack-security at lists.openstack.org Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda Rob/ OSSG: Per our discussions today at the weekly meetup, I would like to start discussions on the meetup agendas. I am listing out with the projects that I am aware of, please add/ edit appropriately. I might be completely wrong, i filled in to get things rolling. Etherpad https://etherpad.openstack.org/p/ossg-juno-meetup List of Projects Topic Importance Size Interested On Going (OSSNs, OSSAs) High Medium Baseline Security Review of Projects (not sure if I imagined this, or it was talked about anywhere) Medium Medium OSSG Book Cleanup High Large Threat Modeling High Medium Security Anti-Patterns Medium Small Library Audit Medium Medium Fuzz Testing Medium Small Please chime in (need help in formatting in to a table at etherpad please) -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriram at sriramhere.com Fri Jun 6 03:40:59 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 5 Jun 2014 20:40:59 -0700 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda In-Reply-To: <27C49E3A44E36C42B89B9012C5CF527C21D0C64D@SZXEMA511-MBX.china.huawei.com> References: <27C49E3A44E36C42B89B9012C5CF527C21D0C64D@SZXEMA511-MBX.china.huawei.com> Message-ID: <53913885.238b440a.0440.0403@mx.google.com> Probably both, but afaik, only revisions. -----Original Message----- From: "Gexiaoyu" Sent: ‎6/‎5/‎2014 7:48 PM To: "Sriram Subramanian" ; "openstack-security at lists.openstack.org" Subject: RE: [Openstack-security] OSSG Mid Cycle Meetup Agenda What’s the detail of the project “OSSG Book Cleanup”, do we intend to add new content/feature to security guide or just revise it? Thanks, Xiaoyu From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: Friday, June 06, 2014 2:51 AM To: openstack-security at lists.openstack.org Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda Rob/ OSSG: Per our discussions today at the weekly meetup, I would like to start discussions on the meetup agendas. I am listing out with the projects that I am aware of, please add/ edit appropriately. I might be completely wrong, i filled in to get things rolling. Etherpad https://etherpad.openstack.org/p/ossg-juno-meetup List of Projects TopicImportanceSizeInterested On Going (OSSNs, OSSAs)HighMedium Baseline Security Review of Projects (not sure if I imagined this, or it was talked about anywhere)MediumMedium OSSG Book CleanupHighLarge Threat ModelingHighMedium Security Anti-PatternsMediumSmall Library AuditMediumMedium Fuzz TestingMediumSmall Please chime in (need help in formatting in to a table at etherpad please) -- Thanks, -Sriram 425-610-8465 [The entire original message is not included.] -------------- next part -------------- An HTML attachment was scrubbed... URL: From morgan.fainberg at gmail.com Fri Jun 6 04:16:51 2014 From: morgan.fainberg at gmail.com (Morgan Fainberg) Date: Fri, 06 Jun 2014 04:16:51 -0000 Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE References: <20130503065127.14958.89453.malonedeb@gac.canonical.com> Message-ID: <20140606041651.4176.75948.malone@soybean.canonical.com> Instead of returning HTTP 500 (ISE), the simplest fix is to just return HTTP 400. Lets be fair, if a deployer configures a longer maxium password than passlib can handle, it's either a 500 or a 400. In this case we can determine what the correct size would be and we should raise up a 400 Bad Request. This is an edge case, but handling it elegantly is better than letting it just fail in an ugly way. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175905 Title: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE Status in OpenStack Identity (Keystone): In Progress Bug description: Grant Murphy originally reported: * Usage of passlib The keystone server does not appear to sanitize the environment when starting. This means that an unintended value can be set for PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 4096 and potentially cause an unhandled passlib.exc.PasswordSizeError. We should ensure sensible defaults are applied here prior to loading passlib. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175905/+subscriptions From 1175905 at bugs.launchpad.net Fri Jun 6 04:17:30 2014 From: 1175905 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 06 Jun 2014 04:17:30 -0000 Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE References: <20130503065127.14958.89453.malonedeb@gac.canonical.com> Message-ID: <20140606041730.27948.51947.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/98296 ** Changed in: keystone Status: Confirmed => In Progress ** Changed in: keystone Assignee: (unassigned) => Morgan Fainberg (mdrnstm) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175905 Title: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE Status in OpenStack Identity (Keystone): In Progress Bug description: Grant Murphy originally reported: * Usage of passlib The keystone server does not appear to sanitize the environment when starting. This means that an unintended value can be set for PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 4096 and potentially cause an unhandled passlib.exc.PasswordSizeError. We should ensure sensible defaults are applied here prior to loading passlib. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175905/+subscriptions From 1326474 at bugs.launchpad.net Fri Jun 6 06:49:50 2014 From: 1326474 at bugs.launchpad.net (Robert Clark) Date: Fri, 06 Jun 2014 06:49:50 -0000 Subject: [Openstack-security] [Bug 1326474] Re: crypto/utils.py may use too much padding References: <20140604175430.27948.44935.malonedeb@gac.canonical.com> Message-ID: <20140606064950.4552.5960.malone@soybean.canonical.com> ^ Nope I was wrong, I was working from memory and thought that MAX_CB_SIZE was used for the modulus, in fact it's the block_size of the cipher which in this case defaults to 128. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1326474 Title: crypto/utils.py may use too much padding Status in Oslo - a Library of Common OpenStack Code: Invalid Bug description: I've been reviewing some of the crypto code available in OpenStack and noticed something interesting in the padding of common/crypto/utils.py. If the message length is the same as the cipher block size an entire extra block of padding is sent along with the message, I'm not sure if this is desired behaviour (if it is, this bug is invalid) but it certainly doesn't seem quite right. If the message length is ever the same as the boundary size ( % 256) then an entirely extra block of padding will be applied: ---code--- r = len(msg) % self.cipher.block_size padlen = self.cipher.block_size - r - 1 msg += b'\x00' * padlen msg += bchr(padlen) ---/code--- So if our msg length is 256,512,,, then 'r' will be 0 padlen will be 256-0-1 or 255 msg gets 255 * b'\x00' added and then the number 255 tagged on the end. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1326474/+subscriptions From 1129748 at bugs.launchpad.net Fri Jun 6 07:11:36 2014 From: 1129748 at bugs.launchpad.net (Joe Gordon) Date: Fri, 06 Jun 2014 07:11:36 -0000 Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should not be world-readable References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com> Message-ID: <20140606071136.20203.19977.malone@chaenomeles.canonical.com> This cannot be in progress with no one assigned, moving back to new ** Changed in: nova Status: In Progress => New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (Nova): New Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions From robert.clark at hp.com Fri Jun 6 07:21:10 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 6 Jun 2014 07:21:10 +0000 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda In-Reply-To: <53913885.238b440a.0440.0403@mx.google.com> References: <27C49E3A44E36C42B89B9012C5CF527C21D0C64D@SZXEMA511-MBX.china.huawei.com> <53913885.238b440a.0440.0403@mx.google.com> Message-ID: Great stuff Sriram. I’ve updated the etherpad with a few thoughts on how things should be structured. In general I think we’ve got some great topics here, I feel that we can shape them nicely over the next day or two, each individual effort needs a leader to own it, organise and prepare for the meet up etc. If there is no leader then either I will take it on or we’ll assume that there isn’t enough passion to take that particular project forward at this cycle. I’ve added a topic to the list - “Gate Test Hackathon” - A sprint to write gate tests that flag those most basic things we see that might hope to catch, please comment and add any thing you can think of to: https://etherpad.openstack.org/p/ossg-juno-meetup ALL: Make sure you add your name to all those topics of interest. Cheers -Rob From: Sriram Subramanian > Date: Friday, 6 June 2014 04:40 To: Gexiaoyu >, "openstack-security at lists.openstack.org" > Subject: Re: [Openstack-security] OSSG Mid Cycle Meetup Agenda Probably both, but afaik, only revisions. ________________________________________ From: Gexiaoyu Sent: 6/5/2014 7:48 PM To: Sriram Subramanian ; openstack-security at lists.openstack.org Subject: RE: [Openstack-security] OSSG Mid Cycle Meetup Agenda What’s the detail of the project “OSSG Book Cleanup”, do we intend to add new content/feature to security guide or just revise it? Thanks, Xiaoyu From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: Friday, June 06, 2014 2:51 AM To: openstack-security at lists.openstack.org Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda Rob/ OSSG: Per our discussions today at the weekly meetup, I would like to start discussions on the meetup agendas. I am listing out with the projects that I am aware of, please add/ edit appropriately. I might be completely wrong, i filled in to get things rolling. Etherpad https://etherpad.openstack.org/p/ossg-juno-meetup List of Projects Topic Importance Size Interested On Going (OSSNs, OSSAs) High Medium Baseline Security Review of Projects (not sure if I imagined this, or it was talked about anywhere) Medium Medium OSSG Book Cleanup High Large Threat Modeling High Medium Security Anti-Patterns Medium Small Library Audit Medium Medium Fuzz Testing Medium Small Please chime in (need help in formatting in to a table at etherpad please) -- Thanks, -Sriram 425-610-8465 [The entire original message is not included.] From gexiaoyu at huawei.com Fri Jun 6 07:33:58 2014 From: gexiaoyu at huawei.com (Gexiaoyu) Date: Fri, 6 Jun 2014 07:33:58 +0000 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda In-Reply-To: <53913885.238b440a.0440.0403@mx.google.com> References: <27C49E3A44E36C42B89B9012C5CF527C21D0C64D@SZXEMA511-MBX.china.huawei.com> <53913885.238b440a.0440.0403@mx.google.com> Message-ID: <27C49E3A44E36C42B89B9012C5CF527C21D0C817@SZXEMA511-MBX.china.huawei.com> Thanks, Sriram. I notice that Scott will add some content to the compliance section of the book. I consider to contribute some content to enhance the network section as same as him. But I may can’t attend the Meetup, who can kindly tell me what should I do to promote this work? BR, Xiaoyu From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: Friday, June 06, 2014 11:41 AM To: Gexiaoyu; openstack-security at lists.openstack.org Subject: RE: [Openstack-security] OSSG Mid Cycle Meetup Agenda Probably both, but afaik, only revisions. ________________________________ From: Gexiaoyu Sent: ‎6/‎5/‎2014 7:48 PM To: Sriram Subramanian; openstack-security at lists.openstack.org Subject: RE: [Openstack-security] OSSG Mid Cycle Meetup Agenda What’s the detail of the project “OSSG Book Cleanup”, do we intend to add new content/feature to security guide or just revise it? Thanks, Xiaoyu From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: Friday, June 06, 2014 2:51 AM To: openstack-security at lists.openstack.org Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda Rob/ OSSG: Per our discussions today at the weekly meetup, I would like to start discussions on the meetup agendas. I am listing out with the projects that I am aware of, please add/ edit appropriately. I might be completely wrong, i filled in to get things rolling. Etherpad https://etherpad.openstack.org/p/ossg-juno-meetup List of Projects Topic Importance Size Interested On Going (OSSNs, OSSAs) High Medium Baseline Security Review of Projects (not sure if I imagined this, or it was talked about anywhere) Medium Medium OSSG Book Cleanup High Large Threat Modeling High Medium Security Anti-Patterns Medium Small Library Audit Medium Medium Fuzz Testing Medium Small Please chime in (need help in formatting in to a table at etherpad please) -- Thanks, -Sriram 425-610-8465 [The entire original message is not included.] -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1319643 at bugs.launchpad.net Fri Jun 6 07:34:16 2014 From: 1319643 at bugs.launchpad.net (Robert Clark) Date: Fri, 06 Jun 2014 07:34:16 -0000 Subject: [Openstack-security] [Bug 1319643] Re: Using random.random() should not be used to generate randomness used for security reasons References: <20140515052815.2825.61709.malonedeb@wampee.canonical.com> Message-ID: <20140606073416.20458.89196.malone@chaenomeles.canonical.com> Makes sense, I think most people understand the impact of using datetime to seed random. However, looking at the change that was made in response to this issue: https://review.openstack.org/#/c/96738/2/cinder/transfer/api.py this is no longer the case and the code is much improved. -Rob -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319643 Title: Using random.random() should not be used to generate randomness used for security reasons Status in Cinder: Fix Committed Status in OpenStack Security Advisories: Won't Fix Bug description: In cinder code : /cinder/transfer/api.py . Below line of code used random.random() to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. Could we use a crytographic randomness generator to provide sufficient entropy to instead of it? rndstr = "" random.seed(datetime.datetime.now().microsecond) while len(rndstr) < length: rndstr += hashlib.sha224(str(random.random())).hexdigest() ---------------> This line has described issues. return rndstr[0:length] To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1319643/+subscriptions From liuzhikun at gmail.com Fri Jun 6 09:05:21 2014 From: liuzhikun at gmail.com (Zhi Kun Liu) Date: Fri, 06 Jun 2014 09:05:21 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140606090522.27240.14188.launchpad@gac.canonical.com> ** Tags added: havana-backport-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1321080 at bugs.launchpad.net Fri Jun 6 13:25:06 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 06 Jun 2014 13:25:06 -0000 Subject: [Openstack-security] [Bug 1321080] Change abandoned on ceilometer (master) References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140606132506.4015.54069.malone@soybean.canonical.com> Change abandoned by gordon chung (chungg at ca.ibm.com) on branch: master Review: https://review.openstack.org/96943 Reason: this code doesn't work against master due to switch to oslo.messaging. abandoning for this bug fix: https://bugs.launchpad.net/ceilometer/+bug/1327084 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From Darren.Moffat at Oracle.COM Fri Jun 6 13:34:32 2014 From: Darren.Moffat at Oracle.COM (Darren J Moffat) Date: Fri, 06 Jun 2014 14:34:32 +0100 Subject: [Openstack-security] Python Crypto libs Trustability In-Reply-To: References: Message-ID: <5391C368.8040101@Oracle.COM> On 06/05/14 23:32, Jeffrey Walton wrote: > On Thu, Jun 5, 2014 at 3:58 PM, Travis McPeak > wrote: >> Hi all, >> >> I¹ve been thinking about some of the crypto libraries that are being used >> in OpenStack projects, specifically how much confidence should we have in >> them. > Yes, this is a governance issue. If the third-party library does not > meet standards, then it should not be used in OpenStack. > > Cloud providers also have a governance issue: OpenStack must meet the > provider's standards, else the provider cannot use OpenStack. Some of those Cloud providers will need to be able to make statements about FIPS 140 validation of all crypto used in the infrastructure. While the hosted customer applications will usually not be directly using the crypto from OpenStack they may be depending on it (eg if OpenStack is providing IPsec VPN services between the VMs). > One of the first problems seems to be the lack of a single OpenStack > crypto wrapper. That is, there should be an OpenStack.Crypto that > provides all the primitives. All source code should call through > OpenStack.Crypto. Instead, code sometimes calls into other libraries > and sometimes rolls its own stuff. > > What OpenStack.Crypto wraps or implements is a different issue. But > its a good first step to ensure calls are being funneled into audited > code. Providing that OpenStack.Crypto does no crypto algorithm implementation and does not directly do key management or key generation then it should be possible to depend on a FIPS 140 validation of the underlying provider (all the way back to something like OpenSSL's libcrypto if possible). The other advantage of using something like OpenSSL as the actual cryptographic algorithm implementation is that it provides CPU optimised versions of the common ciphers eg using AES-NI or the SPARC T4 instructions for AES, SHA256 etc. It may also be useful if OpenStack.Crypto code be a thin layer on top of PKCS#11 - though I'd hope that most of the cases where OpenStack needs key management can be dealt with via projects like Barbican providing it as a service. -- Darren J Moffat From sriram at sriramhere.com Fri Jun 6 13:38:20 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Fri, 6 Jun 2014 06:38:20 -0700 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda In-Reply-To: <27C49E3A44E36C42B89B9012C5CF527C21D0C817@SZXEMA511-MBX.china.huawei.com> References: <27C49E3A44E36C42B89B9012C5CF527C21D0C64D@SZXEMA511-MBX.china.huawei.com> <53913885.238b440a.0440.0403@mx.google.com> <27C49E3A44E36C42B89B9012C5CF527C21D0C817@SZXEMA511-MBX.china.huawei.com> Message-ID: Gexiaoyu, You could still do it from where you are, all you need is to be able to submit changes to the repo; or please ping Bryan. Thanks, -Sriram On Fri, Jun 6, 2014 at 12:33 AM, Gexiaoyu wrote: > Thanks, Sriram. > > > > I notice that Scott will add some content to the compliance section of the > book. > > > > I consider to contribute some content to enhance the network section as > same as him. > > But I may can’t attend the Meetup, who can kindly tell me what should I do > to promote this work? > > > > BR, > > Xiaoyu > > *From:* Sriram Subramanian [mailto:sriram at sriramhere.com] > *Sent:* Friday, June 06, 2014 11:41 AM > *To:* Gexiaoyu; openstack-security at lists.openstack.org > > *Subject:* RE: [Openstack-security] OSSG Mid Cycle Meetup Agenda > > > > Probably both, but afaik, only revisions. > ------------------------------ > > *From: *Gexiaoyu > *Sent: *‎6/‎5/‎2014 7:48 PM > *To: *Sriram Subramanian ; > openstack-security at lists.openstack.org > *Subject: *RE: [Openstack-security] OSSG Mid Cycle Meetup Agenda > > What’s the detail of the project “OSSG Book Cleanup”, do we intend to add > new content/feature to security guide or just revise it? > > > > Thanks, > > Xiaoyu > > > > *From:* Sriram Subramanian [mailto:sriram at sriramhere.com > ] > *Sent:* Friday, June 06, 2014 2:51 AM > *To:* openstack-security at lists.openstack.org > *Subject:* [Openstack-security] OSSG Mid Cycle Meetup Agenda > > > > Rob/ OSSG: > > > > Per our discussions today at the weekly meetup, I would like to start > discussions on the meetup agendas. I am listing out with the projects that > I am aware of, please add/ edit appropriately. I might be completely wrong, > i filled in to get things rolling. > > > > *Etherpad* > > > > https://etherpad.openstack.org/p/ossg-juno-meetup > > > > *List of Projects* > > > > *Topic* > > *Importance* > > *Size* > > *Interested* > > On Going (OSSNs, OSSAs) > > High > > Medium > > Baseline Security Review of Projects (not sure if I imagined this, or it > was talked about anywhere) > > Medium > > Medium > > OSSG Book Cleanup > > High > > Large > > Threat Modeling > > High > > Medium > > Security Anti-Patterns > > Medium > > Small > > Library Audit > > Medium > > Medium > > Fuzz Testing > > Medium > > Small > > > > Please chime in (need help in formatting in to a table at etherpad please) > > > > -- > > Thanks, > > -Sriram > > 425-610-8465 > > > > [The entire original message is not included.] > -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.cacqueray at enovance.com Fri Jun 6 13:49:10 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Fri, 06 Jun 2014 13:49:10 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140606134910.27402.20169.malone@gac.canonical.com> @Zhi Kun Liu, Havana is impacted as well ? @All, While oslo-incubator is not supported, should we include it in this OSSA ? Is it realistic to use this middleware out of Oslo in another service or only Neutron and Ceilometer are actually impacted ? In the meantime, here is the impact description draft #1: Title: User token leak to message queue in the notifier middleware Reporter: Zhi Kun Liu (IBM) Products: Neutron, Ceilometer, Oslo Versions: 2014.1.1 Description: Zhi Kun Liu from IBM reported a vulnerability in the notifier middleware available in Neutron and Ceilometer or through the Oslo library. An attacker with read access to the message queue may obtain authentication tokens used in REST requests (X_AUTH_TOKEN) that goes through the notifier middleware. All services using the notifier middleware configured after the auth_token middleware pipeline are impacted. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From paul.montgomery at RACKSPACE.COM Fri Jun 6 15:00:05 2014 From: paul.montgomery at RACKSPACE.COM (Paul Montgomery) Date: Fri, 6 Jun 2014 15:00:05 +0000 Subject: [Openstack-security] Secure Logging Recommendations Message-ID: I created a first pass document describing some potential solutions to OpenStack sensitive data logging leaks (such as credentials or auth tokens): https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines I would appreciate reviews and discussions in order to gain approval of the OSSG and the security-minded community before making recommendations to other projects (especially in the "Possible Implementation Options" section). Thanks! ---paulmo -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.hellmann at dreamhost.com Fri Jun 6 15:48:59 2014 From: doug.hellmann at dreamhost.com (Doug Hellmann) Date: Fri, 06 Jun 2014 15:48:59 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140606154859.27402.1114.malone@gac.canonical.com> There are 2 copies of the notifier middleware in different places in Oslo. The copy in the incubator is used by projects that have not yet updated to oslo.messaging, such as neutron. There is also a copy in the PyCADF library, used by projects that have updated to oslo.messaging, such as ceilometer. Based on the history here, it looks like both copies have been fixed, so I think changing the impact description to say "the PyCADF library" instead of "the Oslo Library" will make it clear which library needs to be updated. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From bdpayne at acm.org Fri Jun 6 16:01:43 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Fri, 6 Jun 2014 09:01:43 -0700 Subject: [Openstack-security] OSSG Mid Cycle Meetup Agenda In-Reply-To: <27C49E3A44E36C42B89B9012C5CF527C21D0C817@SZXEMA511-MBX.china.huawei.com> References: <27C49E3A44E36C42B89B9012C5CF527C21D0C64D@SZXEMA511-MBX.china.huawei.com> <53913885.238b440a.0440.0403@mx.google.com> <27C49E3A44E36C42B89B9012C5CF527C21D0C817@SZXEMA511-MBX.china.huawei.com> Message-ID: I'm happy to receive updates and improvements to the book. It is developed using a similar process as any other code change in OpenStack. I'm happy to discuss in more detail if you have any questions. Cheers, -bryan On Fri, Jun 6, 2014 at 12:33 AM, Gexiaoyu wrote: > Thanks, Sriram. > > > > I notice that Scott will add some content to the compliance section of the > book. > > > > I consider to contribute some content to enhance the network section as > same as him. > > But I may can’t attend the Meetup, who can kindly tell me what should I do > to promote this work? > > > > BR, > > Xiaoyu > > *From:* Sriram Subramanian [mailto:sriram at sriramhere.com] > *Sent:* Friday, June 06, 2014 11:41 AM > *To:* Gexiaoyu; openstack-security at lists.openstack.org > > *Subject:* RE: [Openstack-security] OSSG Mid Cycle Meetup Agenda > > > > Probably both, but afaik, only revisions. > ------------------------------ > > *From: *Gexiaoyu > *Sent: *‎6/‎5/‎2014 7:48 PM > *To: *Sriram Subramanian ; > openstack-security at lists.openstack.org > *Subject: *RE: [Openstack-security] OSSG Mid Cycle Meetup Agenda > > What’s the detail of the project “OSSG Book Cleanup”, do we intend to add > new content/feature to security guide or just revise it? > > > > Thanks, > > Xiaoyu > > > > *From:* Sriram Subramanian [mailto:sriram at sriramhere.com > ] > *Sent:* Friday, June 06, 2014 2:51 AM > *To:* openstack-security at lists.openstack.org > *Subject:* [Openstack-security] OSSG Mid Cycle Meetup Agenda > > > > Rob/ OSSG: > > > > Per our discussions today at the weekly meetup, I would like to start > discussions on the meetup agendas. I am listing out with the projects that > I am aware of, please add/ edit appropriately. I might be completely wrong, > i filled in to get things rolling. > > > > *Etherpad* > > > > https://etherpad.openstack.org/p/ossg-juno-meetup > > > > *List of Projects* > > > > *Topic* > > *Importance* > > *Size* > > *Interested* > > On Going (OSSNs, OSSAs) > > High > > Medium > > Baseline Security Review of Projects (not sure if I imagined this, or it > was talked about anywhere) > > Medium > > Medium > > OSSG Book Cleanup > > High > > Large > > Threat Modeling > > High > > Medium > > Security Anti-Patterns > > Medium > > Small > > Library Audit > > Medium > > Medium > > Fuzz Testing > > Medium > > Small > > > > Please chime in (need help in formatting in to a table at etherpad please) > > > > -- > > Thanks, > > -Sriram > > 425-610-8465 > > > > [The entire original message is not included.] > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tristan.cacqueray at enovance.com Fri Jun 6 16:04:43 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Fri, 06 Jun 2014 16:04:43 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140606160443.26039.83348.malone@wampee.canonical.com> @Doug, Thanks for clarifying! Though from https://wiki.openstack.org/wiki/Security_supported_projects, oslo-incubator, oslo.messaging and PyCADF are not security supported projects (at least not in OSSA territory). However if the notifier middleware is known to be used in services other than Neutron and Ceilometer, I'm wondering how to cover that. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From noloader at gmail.com Fri Jun 6 18:44:33 2014 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 6 Jun 2014 14:44:33 -0400 Subject: [Openstack-security] Python Crypto libs Trustability In-Reply-To: <5391C368.8040101@Oracle.COM> References: <5391C368.8040101@Oracle.COM> Message-ID: On Fri, Jun 6, 2014 at 9:34 AM, Darren J Moffat wrote: > ... >> One of the first problems seems to be the lack of a single OpenStack >> crypto wrapper. That is, there should be an OpenStack.Crypto that >> provides all the primitives. All source code should call through >> OpenStack.Crypto. Instead, code sometimes calls into other libraries >> and sometimes rolls its own stuff. >> >> What OpenStack.Crypto wraps or implements is a different issue. But >> its a good first step to ensure calls are being funneled into audited >> code. > > Providing that OpenStack.Crypto does no crypto algorithm implementation and > does not directly do key management or key generation then it should be > possible to depend on a FIPS 140 validation of the underlying provider (all > the way back to something like OpenSSL's libcrypto if possible). Yes, agreed. Here, I was more interested in funneling all calls into a single set of controlled interfaces to make it easy to use correctly (and hard to use incorrectly) and easy to audit. Having, for example, OpenStack.Crypto.Random call into OpenSSL's DRBG is fine with me (not that I'm anyone special). Others crypto providers should be OK, too. For example, I've never looked at BouncyCastle, but I imagine in PRNG is satisfactory or acceptable. The audit would then be fairly easy: cd openstack grep -R -i Random.random * There should be no hits (or maybe one if OpenStack.Crypto is using it). > The other advantage of using something like OpenSSL as the actual > cryptographic algorithm implementation is that it provides CPU optimised > versions of the common ciphers eg using AES-NI or the SPARC T4 instructions > for AES, SHA256 etc. Some might call that a detriment ;) (But all-in-all, I agree). I know there's some concern over RDRAND due to the lack of audit-ability. I think there's some concern over AES-NI and timing attacks. I believe most in US Federal, US Financial and other Enterprises will be satisfied, though. I guess it depends on the threat model. Document the risk and move on or use something other than a multi-tenant environment... > It may also be useful if OpenStack.Crypto code be a thin layer on top of > PKCS#11 - though I'd hope that most of the cases where OpenStack needs key > management can be dealt with via projects like Barbican providing it as a > service. Yes, good idea. Jeff From doug.hellmann at dreamhost.com Fri Jun 6 19:24:23 2014 From: doug.hellmann at dreamhost.com (Doug Hellmann) Date: Fri, 06 Jun 2014 19:24:23 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140606192423.27735.19844.malone@gac.canonical.com> The incubator isn't on the OSSA list because the code in the incubator is copied into other projects that are on the list, and it's assumed that changes go into the incubator before being released into the project(s) using the modules. oslo.messaging and PyCADF are new releases from the oslo program, and are being added to the list (probably during Juno, but that's not set for certain). I'm not certain what uses the notifier middleware. Technically, it's middleware, so it don't have to be included in a project for a deployer to use it. @Gordon, do you have any insight into other projects using the middleware? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1290486 at bugs.launchpad.net Fri Jun 6 19:49:39 2014 From: 1290486 at bugs.launchpad.net (Kyle Mestery) Date: Fri, 06 Jun 2014 19:49:39 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140606194939.3953.14474.malone@soybean.canonical.com> Roman, I think this is a different bug, because you're using a floating IP, which means the L3 agent needs to recreate it's flows as well. Can you file a separate one to track that issue? I'll assign that one to myself and address this in the L3 agent as well. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Confirmed Status in neutron icehouse series: In Progress Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From gord at live.ca Fri Jun 6 20:04:17 2014 From: gord at live.ca (gordon chung) Date: Fri, 06 Jun 2014 20:04:17 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140606200417.27977.25469.malone@gac.canonical.com> the original blueprint for notifier middleware is: https://blueprints.launchpad.net/ceilometer/+spec/count-api-requests. i'm unaware of anyone using the notifier middleware on its alone. to my knowledge, the main consumer of notifier middlware is pyCADF (and its audit middlware). regarding the audit middleware: the audit middleware (from oslo-incubator) was synced into Neutron in icehouse as a side effect of another patch (so it may not even be used). the audit middleware was also synced into Ceilometer in havana i believe (to my knowledge it's not used either as pycadf is not a requirement in Ceilometer) the audit middleware (from pycadf) was purposely set as a requirement in Nova in icehouse and is used (it is optionally enabled by deployer). this audit middleware (from pycadf) did not exist before icehouse. i'm not aware of any other projects pulling in pyCADF (and it's audit middleware). hope this brain dump helps :) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1290486 at bugs.launchpad.net Fri Jun 6 20:15:38 2014 From: 1290486 at bugs.launchpad.net (Kyle Mestery) Date: Fri, 06 Jun 2014 20:15:38 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140606201538.18322.95500.malone@soybean.canonical.com> Roman, I actually just tried to reproduce this with a single-node setup. What I did was this: 1. Run devstack to setup an all-in one with ML2 and VLANs. 2. Create a VM. Assign a floating IP. 3. Ping the floating IP from the host. 4. Restart OVS. 5. The ping keeps working. So, I'm wondering what's different here. I'll setup a multi-node devstack and verify now, but I think my prior comments about the L3 agent from #37 were incorrect. Are you sure you're running up to commit 53b701a3f91530c9462a9cb0690aaf68efd45f6d on all of your nodes? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Confirmed Status in neutron icehouse series: In Progress Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From noloader at gmail.com Fri Jun 6 21:39:39 2014 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 6 Jun 2014 17:39:39 -0400 Subject: [Openstack-security] review.openstack.org and linking related classes? Message-ID: Hi All, When reviewing commits, is it possible to turn on or enable cross reference hot linking? For example: https://review.openstack.org/#/c/96738/2/cinder/transfer/api.py. In this checkin, I'm interested in seeing the base class declared on line 49: class API(base.Base): .... Without the links, I kind of stumble around when trying to examine context. Is it possible to turn on or enable cross reference hot linking? Thanks in advance (and please forgive my ignorance). From 1290486 at bugs.launchpad.net Sat Jun 7 05:07:01 2014 From: 1290486 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 07 Jun 2014 05:07:01 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140607050701.20352.13087.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/96919 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d00446be1739c93921e3b88763e05fc194ea9b2b Submitter: Jenkins Branch: stable/icehouse commit d00446be1739c93921e3b88763e05fc194ea9b2b Author: Kyle Mestery Date: Fri May 16 04:21:32 2014 +0000 Reprogram flows when ovs-vswitchd restarts When OVS is restarted, by default it will not reprogram flows which were programmed. For the case of the OVS agent, this means a restart will cause all traffic to be switched using the NORMAL action. This is undesirable for a number of reasons, including obvious security reasons. This change provides a way for the agent to check if a restart of ovs-vswitchd has happened in the main agent loop. If a restart of ovs-vswitchd is detected, the agent will run through the setup of the bridges on the host and reprogram flows for all the ports connected. DocImpact This changes adds a new table (table 23) to the integration bridge, with a single 'drop' flow. This is used to monitor OVS restarts and to reprogram flows from the agent. Conflicts: neutron/plugins/openvswitch/common/constants.py Change-Id: If9e07465c43115838de23e12a4e0087c9218cea2 Closes-Bug: #1290486 (cherry picked from commit 8e9f00a19dab98e5cfc7ca32beb9f17ebb5bc1bb) ** Changed in: neutron/icehouse 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/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Confirmed Status in neutron icehouse series: Fix Committed Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From 1321080 at bugs.launchpad.net Sat Jun 7 14:20:54 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 07 Jun 2014 14:20:54 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140607142054.20736.90700.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/94891 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bb4f44654f6765c4e1fbcf92375c273494151099 Submitter: Jenkins Branch: master commit bb4f44654f6765c4e1fbcf92375c273494151099 Author: Gordon Chung Date: Thu May 22 10:51:25 2014 -0400 remove token from notifier middleware notifier middleware is capturing token and sending it to MQ. this is not advisable so we should filter it out. Closes-Bug: #1321080 Change-Id: Ia1bfa1bd24989681db1d2f385defc12e69a01f8d ** 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 the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1290486 at bugs.launchpad.net Sat Jun 7 21:48:02 2014 From: 1290486 at bugs.launchpad.net (Alan Pevec) Date: Sat, 07 Jun 2014 21:48:02 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140607214806.26427.5832.launchpad@wampee.canonical.com> ** Changed in: neutron/icehouse Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Confirmed Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From liuzhikun at gmail.com Mon Jun 9 02:13:44 2014 From: liuzhikun at gmail.com (Zhi Kun Liu) Date: Mon, 09 Jun 2014 02:13:44 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140609021344.28011.81092.malone@gac.canonical.com> @Tristan Cacqueray, I checked nova and neutorn codes in Havana, they don't have audit and notifier middleware. So this does not impact Havana. It's only an internal problem of us. Thanks for your reminding! ** Tags removed: havana-backport-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Confirmed Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1004114 at bugs.launchpad.net Mon Jun 9 07:48:09 2014 From: 1004114 at bugs.launchpad.net (Julie Pichon) Date: Mon, 09 Jun 2014 07:48:09 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140609074810.27702.5372.malone@gac.canonical.com> It seems to me the patch is still necessary, setting a service to "debug" mode to temporarily debug an issue on a production system shouldn't give visibility into user passwords. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From 1004114 at bugs.launchpad.net Mon Jun 9 08:03:18 2014 From: 1004114 at bugs.launchpad.net (Doug Chivers) Date: Mon, 09 Jun 2014 08:03:18 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140609080318.18322.96177.malone@soybean.canonical.com> +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/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From thierry.carrez+lp at gmail.com Mon Jun 9 14:33:50 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 09 Jun 2014 14:33:50 -0000 Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts can SSH to compute node References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20140609143350.4310.43453.launchpad@soybean.canonical.com> ** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public Security to Public -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From thierry.carrez+lp at gmail.com Mon Jun 9 14:51:41 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 09 Jun 2014 14:51:41 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140609145143.20559.61432.launchpad@chaenomeles.canonical.com> ** Changed in: ossa Status: Confirmed => Triaged -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From gerrit2 at review.openstack.org Mon Jun 9 22:32:09 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 09 Jun 2014 22:32:09 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit e14e5cc366a4ef3cfe77f367d4870f9e18742a77 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1175904 at bugs.launchpad.net Tue Jun 10 02:46:17 2014 From: 1175904 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 Jun 2014 02:46:17 -0000 Subject: [Openstack-security] [Bug 1175904] Related fix proposed to keystone (master) References: <20130503065124.14566.73303.malonedeb@gac.canonical.com> Message-ID: <20140610024617.4143.66814.malone@soybean.canonical.com> Related fix proposed to branch: master Review: https://review.openstack.org/98942 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175904 Title: passlib trunc_password MAX_PASSWORD_LENGTH password truncation Status in OpenStack Identity (Keystone): In Progress Bug description: Grant Murphy originally reported: * Insecure / bad practice The trunc_password function attempts to correct and truncate passwords that are over the MAX_PASSWORD_LENGTH value (default 4096). As the MAX_PASSWORD_LENGTH field is globally mutable it could be modified to restrict all passwords to length = 1. This scenario might be unlikely but generally speaking we should not try to 'fix' invalid input and continue on processing as if nothing happened. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175904/+subscriptions From robert.clark at hp.com Tue Jun 10 11:21:40 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 10 Jun 2014 11:21:40 +0000 Subject: [Openstack-security] review.openstack.org and linking related classes? In-Reply-To: References: Message-ID: I¹d be interested in this too, at the moment I find myself pulling down repo¹s to review them in context. It¹s made even more complicated by some projects using ³import helpers² that obfuscate module origins even further -- Robert Clark Lead Security Architect HP Helion On 06/06/2014 22:39, "Jeffrey Walton" wrote: >Hi All, > >When reviewing commits, is it possible to turn on or enable cross >reference hot linking? > >For example: >https://review.openstack.org/#/c/96738/2/cinder/transfer/api.py. >In this checkin, I'm interested in seeing the base class declared on >line 49: > > class API(base.Base): > .... > >Without the links, I kind of stumble around when trying to examine >context. > >Is it possible to turn on or enable cross reference hot linking? > >Thanks in advance (and please forgive my ignorance). > >_______________________________________________ >Openstack-security mailing list >Openstack-security at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From robert.clark at hp.com Tue Jun 10 11:21:43 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 10 Jun 2014 11:21:43 +0000 Subject: [Openstack-security] Python Crypto libs Trustability In-Reply-To: References: <5391C368.8040101@Oracle.COM> Message-ID: I have to admit, I like the idea of pulling crypto operations into one place for easy identification of deviation from policy. -Rob On 06/06/2014 19:44, "Jeffrey Walton" wrote: >On Fri, Jun 6, 2014 at 9:34 AM, Darren J Moffat > wrote: >> ... >>> One of the first problems seems to be the lack of a single OpenStack >>> crypto wrapper. That is, there should be an OpenStack.Crypto that >>> provides all the primitives. All source code should call through >>> OpenStack.Crypto. Instead, code sometimes calls into other libraries >>> and sometimes rolls its own stuff. >>> >>> What OpenStack.Crypto wraps or implements is a different issue. But >>> its a good first step to ensure calls are being funneled into audited >>> code. >> >> Providing that OpenStack.Crypto does no crypto algorithm implementation >>and >> does not directly do key management or key generation then it should be >> possible to depend on a FIPS 140 validation of the underlying provider >>(all >> the way back to something like OpenSSL's libcrypto if possible). >Yes, agreed. Here, I was more interested in funneling all calls into a >single set of controlled interfaces to make it easy to use correctly >(and hard to use incorrectly) and easy to audit. > >Having, for example, OpenStack.Crypto.Random call into OpenSSL's DRBG >is fine with me (not that I'm anyone special). Others crypto providers >should be OK, too. For example, I've never looked at BouncyCastle, but >I imagine in PRNG is satisfactory or acceptable. > >The audit would then be fairly easy: > > cd openstack > grep -R -i Random.random * > >There should be no hits (or maybe one if OpenStack.Crypto is using it). > >> The other advantage of using something like OpenSSL as the actual >> cryptographic algorithm implementation is that it provides CPU optimised >> versions of the common ciphers eg using AES-NI or the SPARC T4 >>instructions >> for AES, SHA256 etc. >Some might call that a detriment ;) (But all-in-all, I agree). > >I know there's some concern over RDRAND due to the lack of >audit-ability. I think there's some concern over AES-NI and timing >attacks. I believe most in US Federal, US Financial and other >Enterprises will be satisfied, though. I guess it depends on the >threat model. Document the risk and move on or use something other >than a multi-tenant environment... > >> It may also be useful if OpenStack.Crypto code be a thin layer on top of >> PKCS#11 - though I'd hope that most of the cases where OpenStack needs >>key >> management can be dealt with via projects like Barbican providing it as >>a >> service. >Yes, good idea. > >Jeff > >_______________________________________________ >Openstack-security mailing list >Openstack-security at lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From doug.chivers at hp.com Tue Jun 10 11:54:37 2014 From: doug.chivers at hp.com (Chivers, Douglas) Date: Tue, 10 Jun 2014 11:54:37 +0000 Subject: [Openstack-security] OpenStack Security Vulnerability Impact Metrics Message-ID: To kick off the discussion of vulnerability metrics for OpenStack, I have taken a look at the two commonest vulnerability scoring frameworks, OWASP and CVSSv2, and looked over the relevant chapter in the security guide (http://docs.openstack.org/security-guide/content/ch012_configuration-manag ement.html). OWASP (https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) uses a fairly simple set of characteristics to define the risk of avulnerability. The Likelihood of the risk is calculated based on factors such as the ease of discovery and exploitation of the vulnerability, and the skill, motive and opportunity of the threat actor. The Technical Impact of the risk is calculated separately from the Business Impact of the risk, where the Technical Impact is based on loss of confidentiality, availability, integrity and accountability(?!) and business impact is based on financial and reputational damage and compliance violations. OWASP gives impacts for each of these categories, with an associated score. These are averaged to come up with likelihood, technical and business risk - the relevance of the technical or business risk is decided by the reviewer based on the scenario. CVSS (http://www.first.org/cvss/cvss-guide#i1.1) calculates a metric based on three sets of metrics: Base Metrics, which are the fundamental characteristics of the vulnerability, Temporal Metrics, which are characteristics that change over time, and Environmental Metrics, which are dependant on a user¹s specific environment. The characteristics, such as ŒAccess Complexity¹, ŒAuthentication Required¹, have sets of specific answers, as for OWASP. Each answer has a specific score associated with it, which are combined to calculate the CVSS score. The Security Guide has a brief section under Triage, for vulnerability assessment, which bases a Critical/High/Medium/Low score on a combination of vulnerability type and attacker location. The metric uses a limited set of vulnerabilities: Information Disclosure, Denial of Service and Privilege Elevation. Neither OWASP nor CVSS are cloud-aware, and the method described in the security guide is very basic, so clearly none of the three is an off the shelf solution. Due to the complexity of the maths involved in calculating the CVSS score I would consider extending OWASP so it is applicable to common cloud deployments. Before we try and define a framework for vulnerability assessment, I suggest we make sure the requirements are clearly defined, here are a few: - Define ŒThreat¹, ŒRisk¹, ŒVulnerability, etc - threat and risk are often used interchangeably, and do not appear to be defined in the security guide. - The Vulnerability framework should include position in cloud in the calculation, e.g. Œunder cloud infrastructure¹, Œon cloud infrastructure¹, Œpublic instance¹ - The Vulnerability framework should include factor for type of deployment, e.g. Œprivate¹, Œpublic¹, Œtrusted¹, Œuntrusted¹, or maybe Œpaas¹ Œiaas¹. Any thoughts? I suggest we flesh out the requirements before diving into designing a methodology, but I¹m open to suggestions. Doug _____________________ Doug Chivers HP Security Architect doug.chivers at hp.com From tristan.cacqueray at enovance.com Tue Jun 10 14:27:35 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Tue, 10 Jun 2014 10:27:35 -0400 Subject: [Openstack-security] OpenStack Security Vulnerability Impact Metrics In-Reply-To: References: Message-ID: <539715D7.9070708@enovance.com> Hi Doug, On 06/10/2014 07:54 AM, Chivers, Douglas wrote: > > Neither OWASP nor CVSS are cloud-aware, and the method described in the > security guide is very basic, so clearly none of the three is an off the > shelf solution. Due to the complexity of the maths involved in calculating > the CVSS score I would consider extending OWASP so it is applicable to > common cloud deployments. > Many thanks for this very nice summary, and it is what we (the VMT) also found out: we don't want to spend that much time on complexity calculation that might even not apply correctly for OpenStack. > > Before we try and define a framework for vulnerability assessment, I > suggest we make sure the requirements are clearly defined, here are a few: > > - Define ŒThreat¹, ŒRisk¹, ŒVulnerability, etc - threat and risk are often > used interchangeably, and do not appear to be defined in the security > guide. > Doesn't the impact description already cover those ? Maybe we could formalize those. Several project break down the description in different parts, e.g. FreeBSD: 1 Background, 2 Problem description 3 Impact 4 Workaround Xen is doing this kind of breakdown: 1 Issue description 2 Impact 3 Vulnerable systems 4 Mitigation > - The Vulnerability framework should include position in cloud in the > calculation, e.g. Œunder cloud infrastructure¹, Œon cloud infrastructure¹, > Œpublic instance¹ > > - The Vulnerability framework should include factor for type of > deployment, e.g. Œprivate¹, Œpublic¹, Œtrusted¹, Œuntrusted¹, or maybe > Œpaas¹ Œiaas¹. > That is indeed something to think about as Openstack usage can be so different, but then it can also be a great source of confusion. Some bugs are indeed much more critical for public instance than under cloud users, but most advisory are impacting all usage. > > Any thoughts? I suggest we flesh out the requirements before diving into > designing a methodology, but I¹m open to suggestions. > It would be great if we could take into account the ease of exploitation. Thinking about OSSA 2014-012 (Remote code execution in Glance Sheepdog backend) it could have use a "Fix this asap" red light compared to other bugs that are more specifics, hard to exploit, like the ones that requires social engineering. Best regards, Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: From matt at nycresistor.com Tue Jun 10 14:36:51 2014 From: matt at nycresistor.com (matt) Date: Tue, 10 Jun 2014 10:36:51 -0400 Subject: [Openstack-security] OpenStack Security Vulnerability Impact Metrics In-Reply-To: <539715D7.9070708@enovance.com> References: <539715D7.9070708@enovance.com> Message-ID: I started making an attempt to role our vulnerability reporting into a more useful format two summits ago with this: https://github.com/openfly/openstack/blob/master/vulnerabilities/apr_2013/vulndb.json Any attempt to quantify risk for OpenStack starts with the collection of data, and the presentation of that data in a usable format. Today, we really don't have vulnerability information for OpenStack in a usable format. We also need to discuss the mechanism by which we will endeavour to collect information on actual exploitation of openstack adopters. I think that discussion is what we'd need to focus on before we can come up with a risk model. Get us using the same tools on the same data, and we'll have a much better time discussing which risk assessment model is right for OpenStack. As stated earlier, OWASP's risk metrics are based on the threat profile of web applications. This is well and good for horizon, but it wouldn't address the most damning vulnerabilities we've seen in keystone or the primacy of a hypervisor escape vulnerability in any threat matrix. I'd be down to collaborate on putting our vulnerability metrics together into a more usable format. Whatever we believe that to be. -Matt Joyce On Tue, Jun 10, 2014 at 10:27 AM, Tristan Cacqueray < tristan.cacqueray at enovance.com> wrote: > Hi Doug, > > On 06/10/2014 07:54 AM, Chivers, Douglas wrote: > > > > Neither OWASP nor CVSS are cloud-aware, and the method described in the > > security guide is very basic, so clearly none of the three is an off the > > shelf solution. Due to the complexity of the maths involved in > calculating > > the CVSS score I would consider extending OWASP so it is applicable to > > common cloud deployments. > > > > Many thanks for this very nice summary, and it is what we (the VMT) also > found out: we don't want to spend that much time on complexity > calculation that might even not apply correctly for OpenStack. > > > > > > Before we try and define a framework for vulnerability assessment, I > > suggest we make sure the requirements are clearly defined, here are a > few: > > > > - Define ŒThreat¹, ŒRisk¹, ŒVulnerability, etc - threat and risk are > often > > used interchangeably, and do not appear to be defined in the security > > guide. > > > > Doesn't the impact description already cover those ? Maybe we could > formalize those. Several project break down the description in different > parts, e.g. FreeBSD: > 1 Background, > 2 Problem description > 3 Impact > 4 Workaround > > Xen is doing this kind of breakdown: > 1 Issue description > 2 Impact > 3 Vulnerable systems > 4 Mitigation > > > > - The Vulnerability framework should include position in cloud in the > > calculation, e.g. Œunder cloud infrastructure¹, Œon cloud > infrastructure¹, > > Œpublic instance¹ > > > > - The Vulnerability framework should include factor for type of > > deployment, e.g. Œprivate¹, Œpublic¹, Œtrusted¹, Œuntrusted¹, or maybe > > Œpaas¹ Œiaas¹. > > > > That is indeed something to think about as Openstack usage can be so > different, but then it can also be a great source of confusion. Some > bugs are indeed much more critical for public instance than under cloud > users, but most advisory are impacting all usage. > > > > > > Any thoughts? I suggest we flesh out the requirements before diving into > > designing a methodology, but I¹m open to suggestions. > > > > It would be great if we could take into account the ease of > exploitation. Thinking about OSSA 2014-012 (Remote code execution in > Glance Sheepdog backend) it could have use a "Fix this asap" red light > compared to other bugs that are more specifics, hard to exploit, like > the ones that requires social engineering. > > Best regards, > Tristan > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1299012 at bugs.launchpad.net Tue Jun 10 14:30:59 2014 From: 1299012 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 10 Jun 2014 14:30:59 -0000 Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method chaining References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com> Message-ID: <20140610143100.20605.32846.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/84945 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=33fd4cf8b308fd078e632eed9f398b91ed77b35b Submitter: Jenkins Branch: master commit 33fd4cf8b308fd078e632eed9f398b91ed77b35b Author: guang-yee Date: Wed Apr 2 21:41:11 2014 -0700 Make sure all the auth plugins agree on the shared identity attributes. Note: this patch also corrected some of the external auth tests where an auth request consists of two methods with two different identities. Closes-Bug: #1299012 Change-Id: I5d7dd42d373879322823b16b215f11a015b734f8 ** Changed in: keystone 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/1299012 Title: V3 api authentication method chaining Status in OpenStack Identity (Keystone): Fix Committed Status in OpenStack Security Advisories: Invalid Bug description: When using authentication method chaining for token creation (POST) in Keystone V3 api , it is possible to use authentication credentials for two different users . For example, if i have an existing token for a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier for demo tenant) and i have a user say 'test131' in admin tenant Now i can make an authentication call using auth method chaining { "auth":{ "identity":{ "methods":[ "password", "token" ], "token":{ "id":"6bb934a0120f097a32b5d3cc71f83beb" }, "password":{ "user":{ "domain":{ "id":"default" }, "name":"test131", "password":"test131" } } } } } The call will succeed even though two different users authentication credentials are used. The generated token will get properties of test131 user although the expirary date is set by demo user token. If we change the methods sequence, the generated token will get all properties from demo users token. This is an undesired security behaviour - token should not be allowed to generate using credentials from two different users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299012/+subscriptions From rpodolyaka at mirantis.com Tue Jun 10 14:37:26 2014 From: rpodolyaka at mirantis.com (Roman Podoliaka) Date: Tue, 10 Jun 2014 14:37:26 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140610143726.20078.75405.malone@chaenomeles.canonical.com> Kyle, just reproduced this on Neutron master (d6634da6eb073e4a17d8b877c2662a15cbf0a4be) on two-nodes setup: 1 control + 1 compute node. Restart of neutron-openvswitch-agent on the compute node fixes the problem. Here is what I see in neutron-openvswitch-agent logs on the compute node: http://paste.openstack.org/show/83533/ (14:31 is the moment I restarted ovs service). -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Confirmed Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From gerrit2 at review.openstack.org Tue Jun 10 15:08:59 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Jun 2014 15:08:59 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit f1594626712dbc8a86f3ec9319ed2f95fae7ece5 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Tue Jun 10 16:52:53 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Jun 2014 16:52:53 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit b41ecd7f96bfa107edd35745ae8e293e28da9d43 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From Travis_McPeak at symantec.com Tue Jun 10 16:53:07 2014 From: Travis_McPeak at symantec.com (Travis McPeak) Date: Tue, 10 Jun 2014 09:53:07 -0700 Subject: [Openstack-security] OpenStack Security Vulnerability Impact Metrics Message-ID: This sounds really good Doug! I agree that neither of those traditional scoring metrics really take into account important factors of cloud deployments. In particular I think the position in the cloud is extremely important. I¹d be interested in working with you and the community to get some better way of scoring vulnerabilities for the cloud. Thanks, -Travis On 6/10/14, 4:55 AM, "openstack-security-request at lists.openstack.org" wrote: >- The Vulnerability framework should include position in cloud in the >calculation, e.g. ?under cloud infrastructure?, ?on cloud infrastructure?, >?public instance? From gerrit2 at review.openstack.org Tue Jun 10 19:22:09 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Jun 2014 19:22:09 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 991e1b4588f4e42d9226dd3600354ca7cb9be155 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1290486 at bugs.launchpad.net Tue Jun 10 19:21:02 2014 From: 1290486 at bugs.launchpad.net (Kyle Mestery) Date: Tue, 10 Jun 2014 19:21:02 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140610192102.25975.33917.malone@wampee.canonical.com> Roman, can you file a new bug to track this issue? I am not sure this is the same issue. Also, please put in detailed steps of how you reproduced this. I've verified this fix does indeed work. You are 100% sure you're running the latest code on the control node as well? ** Changed in: neutron Status: Confirmed => 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/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Fix Committed Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From 1290486 at bugs.launchpad.net Tue Jun 10 19:21:31 2014 From: 1290486 at bugs.launchpad.net (Kyle Mestery) Date: Tue, 10 Jun 2014 19:21:31 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140610192132.3832.76574.malone@soybean.canonical.com> Moving back to "Fix Committed" state. Roman will file a new bug to track the new issue with the L3 agent. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Fix Committed Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From gerrit2 at review.openstack.org Tue Jun 10 23:26:56 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Jun 2014 23:26:56 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 7dac77476893e6b4ca05f7efe7714b47c826b7ef Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Wed Jun 11 02:00:49 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Jun 2014 02:00:49 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change If698fc1d0751cded556825b081539da4dd51275e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/95989 Log: commit 8f7ce60e8299463a9f213ed9470c316d2f74b413 Author: Adam Young Date: Tue May 27 21:51:12 2014 -0400 Kerberos as method name To date kerberos has been supported by the "external" method name. However, the Client plugin architecture needs to refer to the method name , and we do not want to expose to the client the difference between kerberos as performed by an external module or an eventual kerberos-in-eventlet style implementation. If the "external" plugin is missing, the old code would throw an exception attempting to process "REMOTE_USER" behavior. If only 'Kerberos" is specified, this is checked and skipped. Blueprint: kerberos-authentication SecurityImpact: Minimal, as Kerberos is already used via external, this just changes the main way it is named. Change-Id: If698fc1d0751cded556825b081539da4dd51275e From gerrit2 at review.openstack.org Wed Jun 11 02:18:55 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Jun 2014 02:18:55 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change If698fc1d0751cded556825b081539da4dd51275e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/95989 Log: commit 858248f3ee694c254af2ae313bdafb23e7c29a5c Author: Adam Young Date: Tue May 27 21:51:12 2014 -0400 Kerberos as method name To date kerberos has been supported by the "external" method name. However, the Client plugin architecture needs to refer to the method name , and we do not want to expose to the client the difference between kerberos as performed by an external module or an eventual kerberos-in-eventlet style implementation. If the "external" plugin is missing, the old code would throw an exception attempting to process "REMOTE_USER" behavior. If only 'Kerberos" is specified, this is checked and skipped. Blueprint: kerberos-authentication SecurityImpact: Minimal, as Kerberos is already used via external, this just changes the main way it is named. Change-Id: If698fc1d0751cded556825b081539da4dd51275e From gmurphy at redhat.com Wed Jun 11 03:16:21 2014 From: gmurphy at redhat.com (Grant Murphy) Date: Tue, 10 Jun 2014 23:16:21 -0400 (EDT) Subject: [Openstack-security] OpenStack Security Vulnerability Impact Metrics In-Reply-To: References: Message-ID: <535547221.19877429.1402456581741.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Douglas Chivers" > To: openstack-security at lists.openstack.org > Sent: Tuesday, June 10, 2014 9:54:37 PM > Subject: [Openstack-security] OpenStack Security Vulnerability Impact Metrics > > > To kick off the discussion of vulnerability metrics for OpenStack, I have > taken a look at the two commonest vulnerability scoring frameworks, OWASP > and CVSSv2, and looked over the relevant chapter in the security guide > (http://docs.openstack.org/security-guide/content/ch012_configuration-manag > ement.html). > > > OWASP (https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) uses > a fairly simple set of characteristics to define the risk of > avulnerability. The Likelihood of the risk is calculated based on factors > such as the ease of discovery and exploitation of the vulnerability, and > the skill, motive and opportunity of the threat actor. The Technical > Impact of the risk is calculated separately from the Business Impact of > the risk, where the Technical Impact is based on loss of confidentiality, > availability, integrity and accountability(?!) and business impact is > based on financial and reputational damage and compliance violations. > OWASP gives impacts for each of these categories, with an associated > score. These are averaged to come up with likelihood, technical and > business risk - the relevance of the technical or business risk is decided > by the reviewer based on the scenario. > > CVSS (http://www.first.org/cvss/cvss-guide#i1.1) calculates a metric based > on three sets of metrics: Base Metrics, which are the fundamental > characteristics of the vulnerability, Temporal Metrics, which are > characteristics that change over time, and Environmental Metrics, which > are dependant on a user¹s specific environment. The characteristics, such > as ŒAccess Complexity¹, ŒAuthentication Required¹, have sets of specific > answers, as for OWASP. Each answer has a specific score associated with > it, which are combined to calculate the CVSS score. > > The Security Guide has a brief section under Triage, for vulnerability > assessment, which bases a Critical/High/Medium/Low score on a combination > of vulnerability type and attacker location. The metric uses a limited set > of vulnerabilities: Information Disclosure, Denial of Service and > Privilege Elevation. > > > Neither OWASP nor CVSS are cloud-aware, and the method described in the > security guide is very basic, so clearly none of the three is an off the > shelf solution. Due to the complexity of the maths involved in calculating > the CVSS score I would consider extending OWASP so it is applicable to > common cloud deployments. > > > Before we try and define a framework for vulnerability assessment, I > suggest we make sure the requirements are clearly defined, here are a few: > > - Define ŒThreat¹, ŒRisk¹, ŒVulnerability, etc - threat and risk are often > used interchangeably, and do not appear to be defined in the security > guide. > > - The Vulnerability framework should include position in cloud in the > calculation, e.g. Œunder cloud infrastructure¹, Œon cloud infrastructure¹, > Œpublic instance¹ > > - The Vulnerability framework should include factor for type of > deployment, e.g. Œprivate¹, Œpublic¹, Œtrusted¹, Œuntrusted¹, or maybe > Œpaas¹ Œiaas¹. > > > Any thoughts? I suggest we flesh out the requirements before diving into > designing a methodology, but I¹m open to suggestions. Hi Doug, Great work! I just thought I'd share how Red Hat currently classifies vulnerabilities: https://access.redhat.com/site/security/updates/classification/ We are currently applying CVSS2 scores and impact classifications to our OpenStack offerings. An example is here: https://rhn.redhat.com/errata/RHSA-2014-0455.html As you mentioned CVSS2 doesn't really make a whole heap of sense for OpenStack but FWIW the impact Red Hat assigns is not always directly derived from CVSS2 score. And whilst I agree we need a repeatable and objective process here I will also like to note that in my experience these scoring systems don't always capture all the edge cases. So IMO having a mechanism that gives the VMT the discretion to bump up the impact of a vulnerability based on the situation is probably something worth considering. On a (kind of) related topic: I would like to start including the classification of the underlying flaw in our advisories. Something similar to CWE maybe? From a metrics perspective I would find this more useful for driving proactive initiatives to prevent recurrences. - Grant > > Doug > > _____________________ > Doug Chivers > HP Security Architect > doug.chivers at hp.com > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > From 1319639 at bugs.launchpad.net Tue Jun 10 19:49:35 2014 From: 1319639 at bugs.launchpad.net (John Griffith) Date: Tue, 10 Jun 2014 19:49:35 -0000 Subject: [Openstack-security] [Bug 1319639] Re: Standard random number generators (using shuffle ) should not be used to generate randomness References: <20140515051014.31551.82176.malonedeb@soybean.canonical.com> Message-ID: <20140610194936.27468.87983.launchpad@gac.canonical.com> ** Changed in: cinder Milestone: juno-1 => juno-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319639 Title: Standard random number generators (using shuffle ) should not be used to generate randomness Status in Cinder: Triaged Bug description: In cinder code : /cinder/utils.py . Below two lines of code used shuffle to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. Could we use a crytographic randomness generator to provide sufficient entropy to instead of it?  # 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.  r.shuffle(password) ----------------> This line of code has described issue.  password = password[:length]  length -= len(password) # finally shuffle to ensure first x characters aren't from a # predictable group r.shuffle(password) ----------------> This line of code has described issue. return ''.join(password) To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1319639/+subscriptions From thierry.carrez+lp at gmail.com Wed Jun 11 13:42:44 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Jun 2014 13:42:44 -0000 Subject: [Openstack-security] [Bug 1319943] Re: libvirt driver's to_xml method logs iscsi auth_password if debug References: <20140515172919.15967.70050.malonedeb@gac.canonical.com> Message-ID: <20140611134248.26302.80629.launchpad@wampee.canonical.com> ** Changed in: nova Status: Fix Committed => Fix Released ** Changed in: nova Milestone: None => juno-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/1319943 Title: libvirt driver's to_xml method logs iscsi auth_password if debug Status in OpenStack Compute (Nova): Fix Released Bug description: If you have debug logging enabled the libvirt driver's to_xml method logs the iscsi auth_password in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1319943/+subscriptions From thierry.carrez+lp at gmail.com Wed Jun 11 14:59:42 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Jun 2014 14:59:42 -0000 Subject: [Openstack-security] [Bug 1315556] Re: Disabling a domain does not disable the projects in that domain References: <20140502222034.18381.89762.malonedeb@chaenomeles.canonical.com> Message-ID: <20140611145944.28011.61435.launchpad@gac.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => juno-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/1315556 Title: Disabling a domain does not disable the projects in that domain Status in OpenStack Identity (Keystone): Fix Released Bug description: User from an enabled domain can still get a token scoped to a project in a disabled domain. Steps to reproduce. 1. create domains "domainA" and "domainB" 2. create user "userA" and project "projectA" in "domainA" 3. create user "userB" and project "projectB" in "domainB" 4. assign "userA" some role for "projectB" 5. disable "domainB" 6. authenticate to get a token for "userA" scoped to "projectB". This should fail as "projectB"'s domain ("domainB") is disabled. Looks like the fix would be the check for the project domain to make sure it is also enabled. See https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L112 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1315556/+subscriptions From thierry.carrez+lp at gmail.com Wed Jun 11 15:00:23 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Jun 2014 15:00:23 -0000 Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method chaining References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com> Message-ID: <20140611150027.20700.27862.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => juno-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/1299012 Title: V3 api authentication method chaining Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Advisories: Invalid Bug description: When using authentication method chaining for token creation (POST) in Keystone V3 api , it is possible to use authentication credentials for two different users . For example, if i have an existing token for a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier for demo tenant) and i have a user say 'test131' in admin tenant Now i can make an authentication call using auth method chaining { "auth":{ "identity":{ "methods":[ "password", "token" ], "token":{ "id":"6bb934a0120f097a32b5d3cc71f83beb" }, "password":{ "user":{ "domain":{ "id":"default" }, "name":"test131", "password":"test131" } } } } } The call will succeed even though two different users authentication credentials are used. The generated token will get properties of test131 user although the expirary date is set by demo user token. If we change the methods sequence, the generated token will get all properties from demo users token. This is an undesired security behaviour - token should not be allowed to generate using credentials from two different users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299012/+subscriptions From thierry.carrez+lp at gmail.com Wed Jun 11 15:00:01 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Jun 2014 15:00:01 -0000 Subject: [Openstack-security] [Bug 1236675] Re: Keystone getting oauth access token by brute-forcing oauth_verifier code References: <20131008030759.26826.41914.malonedeb@chaenomeles.canonical.com> Message-ID: <20140611150004.4686.56351.launchpad@soybean.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => juno-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/1236675 Title: Keystone getting oauth access token by brute-forcing oauth_verifier code Status in OpenStack Identity (Keystone): Fix Released Bug description: Title: Keystone getting oauth access token by brute-forcing oauth_verifier code Reporter: Phuong Cao Products: openstack/keystone Affects: keystone/master branch as of Oct 7th 2013 Description: Phuong Cao reported a vulnerability in OAuth SQL backend of keystone/master branch. How does the attack work? By creating many access token requests with oauth_verifier code selected from the range 1000 to 9999, an attacker can request a valid access token to a role and a project, overriding a user who actually request access to the role and the project. Before describing in detail how the attack works, this is how OAuth works (summarized from RFC5849) 1. Alice registers as a consumer with the Openstack admin. 2. Alice asks the Openstack admin a token with a specified role and a project on behalf of Bob (Bob is the owner of the project). 3. The Openstack admin returns to Alice a request token key. 4. Alice sends the request token key to Bob to ask for permissions to access the project. 5. Bob authorizes Alice's request token to have access to the project with the specified role. 6. Bob generates an oauth_verifier code ranging from 1000 to 9999, then sends back to Alice an oauth_verifier code. 7. Alice use the oauth_verifier code and the request token key to ask the Openstack admin for the access token to the project. This is how the attack works: At step 4, assuming an attacker can sniff Alice's request token key. This can be done by acting as a man in the middle if Alice interacts with Keystone using HTTP requests, or acting as a local user to list the process arguments if Alice is interacts with Keystone using openstack commandline tools (this case is similar to CVE 2013-2013). Now the attacker has Alice's request token key, he/she need to wait for Bob to authorizes Alice's request token (step 5), then repeatedly brute-forcing Keystone with the pair(oauth_verifier, Alice's request token key) using oauth_verifier from the range 1000 to 9999. Since the oauth_verifier is in a short range, and Openstack/Keystone doesn't have any mechanism to limit number of requests, the attacker can bruteforce for the valid oauth_verifier key until the request token expires. A more aggressive way is to keep brute-forcing Keystone until Bob authorizes Alice's request token, by doing this the attacker will have more chance getting the access token key before Alice. Where are the vulnerable code locations? Line 210 of sql.py file: https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210 In OAuth SQL backend of keystone/master branch, the oauth_verifier code, a fundamental part of OAuth1 protocol, is generated using random numbers from 1000 to 9999. This is a small range of numbers and it is easy to be guessed/brute-forced. This attack is classified as "CWE-330: Use of Insufficiently Random Values" (http://cwe.mitre.org/data/definitions/330.html). What are the possible fixes? We suggest using a long random string (e.g., 32-bit or 64-bit). Using os.urandom() is a good one, it has been recommended for generating random number for cryptographic purposes. A patch is attached in the attached file (please note: we haven't tested this patch). Where is the exploit code? We attach a snippet code that we modify from test_bad_verifier() Keystone test case. The snippet is a sketch of how oauth_verifier code brute-forcing can be implemented. What is the affected version? The keystone/master on github as of Oct 7th 2013 is affected. References: Link to oauth1 file and vulnerable code location (sql.py, line #210): https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210 CWE-330: Use of Insufficiently Random Values: (http://cwe.mitre.org/data/definitions/330.html). RFC5849: http://tools.ietf.org/html/rfc5849 os.urandom(): http://docs.python.org/2/library/os.html OAuth in keystone tutorial: http://www.unitedstack.com/blog/oauth-in-keystone/ # Patch --- /tmp/keystone/keystone/contrib/oauth1/backends/sql.py 2013-10-07 17:06:04.170603933 -0500 +++ /home/vagrant/keystone/keystone/contrib/oauth1/backends/sql.py 2013-10-07 17:01:39.124008733 -0500 @@ -17,6 +17,8 @@ import datetime import random import uuid +import os +import binascii from keystone.common import sql from keystone.common.sql import migration @@ -207,7 +209,7 @@ token_ref = self._get_request_token(session, request_token_id) token_dict = token_ref.to_dict() token_dict['authorizing_user_id'] = user_id - token_dict['verifier'] = str(random.randint(1000, 9999)) + token_dict['verifier'] = binascii.b2a_hex(os.urandom(16)) token_dict['role_ids'] = jsonutils.dumps(role_ids) new_token = RequestToken.from_dict(token_dict) # Test brute force class MaliciousOAuth1Tests(OAuth1Tests): # modified from test_bad_verifier() def test_bruteforce_verifier(self): # create consumer for oauth consumer = self._create_single_consumer() consumer_id = consumer.get('id') consumer_secret = consumer.get('secret') consumer = oauth1.Consumer(consumer_id, consumer_secret) url, headers = self._create_request_token(consumer, self.project_id) # get request token content = self.post(url, headers=headers) credentials = urlparse.parse_qs(content.result) request_key = credentials.get('oauth_token')[0] request_secret = credentials.get('oauth_token_secret')[0] request_token = oauth1.Token(request_key, request_secret) # authorize request token url = self._authorize_request_token(request_key) body = {'roles': [{'id': self.role_id}]} resp = self.put(url, body=body, expected_status=200) verifier = resp.result['token']['oauth_verifier'] self.assertIsNotNone(verifier) # we are not going to use received oauth_verifier here, instead, we brute-force to find the valid oauth_verifier for i in range(1000,10000): request_token.set_verifier(str(i)) url, headers = self._create_access_token(consumer, request_token) # We expect 401 status code for most of requests since most oauth_verifier code # that we try will be invalid. # The test will crash at the valid oauth_verifier code when returned status = 201, # which is different from the expected 401 status. r = self.post(url, headers=headers, expected_status=401) # Print out oauth_verifier, and raw response request that contains access token. if (r == 201): # We have found correct oauth_verifier code print 'oauth_verifier: {}, raw access_token response request: {}'.format(str(i), str(r)) We are looking forward hearing from you. Thank you. Best, Phuong Cao Research Assistant DEPEND group Coordinated Science Laboratory University of Illinois at Urbana Champaign Urbana, IL 61801, USA To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1236675/+subscriptions From thierry.carrez+lp at gmail.com Wed Jun 11 15:05:42 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Jun 2014 15:05:42 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20140611150546.20834.21196.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released ** Changed in: keystone Milestone: None => juno-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/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Dashboard (Horizon): New Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack API documentation site: Confirmed Status in Python client library for Keystone: Fix Released Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1174499/+subscriptions From robert.clark at hp.com Wed Jun 11 15:56:01 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 11 Jun 2014 15:56:01 +0000 Subject: [Openstack-security] OSSG Meetup - lock it in Message-ID: All, Those of you that are coming to the meetup please make sure that you've put your names down on the etherpad. https://etherpad.openstack.org/p/ossg-juno-meetup The chosen date is the week starting July 14th. The agenda topics are listed on the etherpad but here's the short version: * OSSN/OSSA - Ongoing Work * Baseline Security Review for $project * OSSG Book Cleanup * Threat Modelling * Security Anti-Patterns * Library Audit * Fuzz Testing * Gate Test Hackathon This is a _lot_ of ground to cover, please make sure you've put your name by all of the topics that you're interested in. Those of you that are leading a topic, please add a short one-two sentence description of what you'd like to achieve with it so people can put their names by them and we can get a good idea of what can be run in parallel and what must be run in series. We need to decide on the amount of time we need to get everything done, we initially thought that 3-4 days would be sufficient, I'm definitely thinking more to the 4 day end of that. Thoughts? -Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From bdpayne at acm.org Wed Jun 11 16:00:13 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 11 Jun 2014 09:00:13 -0700 Subject: [Openstack-security] Secure Logging Recommendations In-Reply-To: References: Message-ID: Paul, I really like this. Here's a few additional thoughts: 1) On the implementation side, doing this in Oslo seems like a good plan. At least doing as much of the security sensitive filtering stuff there. This is something we are basically asking all projects to do, so Oslo is the right answer. 2) On this point: "If confidential/sensitive data MUST be logged for root cause analysis, create an Oslo Config setting that disables security features, vividly informs the operator of this fact and make sure that the description accurately describes that this option should not be used for normal production purposes." I think that it would be nice if we just didn't do this at all. But, I understand the realities and we are likely to be more successful in our goals here if we can accommodate something like this. To that end, I could say that when the system is operating in this mode, we should prefix EVERY log line with a short string that makes it clear that this mode is for debug/test and that it shouldn't be used for production purposes. 3) CADF is interesting and appears to be getting some traction. I am not too familiar with this standard, though. It may be useful to have these logging guidelines reviewed by someone who has more familiarity with CADF to make sure that everything lines up nicely. 4) OSSG hasn't traditionally been through a process of "blessing" a document such as this. However, I would argue that it would be a good idea for us to figure out how to do this. I think that providing guidelines such as this are a valuable "next step" towards increasing influence and interactions with the dev teams. Cheers, -bryan On Fri, Jun 6, 2014 at 8:00 AM, Paul Montgomery < paul.montgomery at rackspace.com> wrote: > I created a first pass document describing some potential solutions to > OpenStack sensitive data logging leaks (such as credentials or auth tokens): > > https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines > > I would appreciate reviews and discussions in order to gain approval of > the OSSG and the security-minded community before making recommendations to > other projects (especially in the "Possible Implementation Options" > section). > > Thanks! > ---paulmo > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Wed Jun 11 18:22:31 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Jun 2014 18:22:31 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/99432 Log: commit 27178c8186d382a8b0d0784f6d4057433d54dbe4 Author: Morgan Fainberg Date: Wed Jun 11 10:13:32 2014 -0700 Do not expose Token IDs in debug output It is only very slightly less of a security issue to expose Token IDs in the logs than it is to expose password details. This change obscures the Token ID in the debug output in all cases to ensure that the ID is not presented in any of the logs that could be read by a unpriviledged source (e.g. lower priv log watchers, centralized logging, etc). The raw data elements from the token (e.g. user, roles, expiration etc) could be added into debug/trace level logging at a future time. SecurityImpact Change-Id: If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 From thierry.carrez+lp at gmail.com Wed Jun 11 20:05:14 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Jun 2014 20:05:14 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140611200518.8459.42988.launchpad@chaenomeles.canonical.com> ** Changed in: cinder Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From thierry.carrez+lp at gmail.com Wed Jun 11 20:06:20 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Jun 2014 20:06:20 -0000 Subject: [Openstack-security] [Bug 1319643] Re: Using random.random() should not be used to generate randomness used for security reasons References: <20140515052815.2825.61709.malonedeb@wampee.canonical.com> Message-ID: <20140611200623.8254.92473.launchpad@chaenomeles.canonical.com> ** Changed in: cinder Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319643 Title: Using random.random() should not be used to generate randomness used for security reasons Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Bug description: In cinder code : /cinder/transfer/api.py . Below line of code used random.random() to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. Could we use a crytographic randomness generator to provide sufficient entropy to instead of it? rndstr = "" random.seed(datetime.datetime.now().microsecond) while len(rndstr) < length: rndstr += hashlib.sha224(str(random.random())).hexdigest() ---------------> This line has described issues. return rndstr[0:length] To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1319643/+subscriptions From 1319943 at bugs.launchpad.net Thu Jun 12 01:55:12 2014 From: 1319943 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 12 Jun 2014 01:55:12 -0000 Subject: [Openstack-security] [Bug 1319943] Fix proposed to nova (stable/icehouse) References: <20140515172919.15967.70050.malonedeb@gac.canonical.com> Message-ID: <20140612015513.30000.13278.malone@gac.canonical.com> Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/99536 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319943 Title: libvirt driver's to_xml method logs iscsi auth_password if debug Status in OpenStack Compute (Nova): Fix Released Bug description: If you have debug logging enabled the libvirt driver's to_xml method logs the iscsi auth_password in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1319943/+subscriptions From gerrit2 at review.openstack.org Thu Jun 12 03:32:46 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Jun 2014 03:32:46 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit ce9d178794159fe024c447a34028ece1ec12e093 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Thu Jun 12 03:44:37 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Jun 2014 03:44:37 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit cb6bedccf8cb3ebc257962c11145d792455f5617 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Thu Jun 12 04:31:39 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Jun 2014 04:31:39 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/99432 Log: commit 74b39df685229957c86c98c3d595bfebb95bcea5 Author: Morgan Fainberg Date: Wed Jun 11 10:13:32 2014 -0700 Do not expose Token IDs in debug output It is only very slightly less of a security issue to expose Token IDs in the logs than it is to expose password details. This change obscures the Token ID in the debug output in all cases to ensure that the ID is not presented in any of the logs that could be read by a unpriviledged source (e.g. lower priv log watchers, centralized logging, etc). The raw data elements from the token (e.g. user, roles, expiration etc) could be added into debug/trace level logging at a future time. SecurityImpact Change-Id: If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 From gerrit2 at review.openstack.org Thu Jun 12 05:01:59 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Jun 2014 05:01:59 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/99432 Log: commit ae03f3311920f56163b30edd6ae0d89e8954ec8a Author: Morgan Fainberg Date: Wed Jun 11 10:13:32 2014 -0700 Do not expose Token IDs in debug output It is only very slightly less of a security issue to expose Token IDs in the logs than it is to expose password details. This change obscures the Token ID in the debug output in all cases to ensure that the ID is not presented in any of the logs that could be read by a unpriviledged source (e.g. lower priv log watchers, centralized logging, etc). The raw data elements from the token (e.g. user, roles, expiration etc) could be added into debug/trace level logging at a future time. SecurityImpact Change-Id: If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 From kuvaja at hp.com Thu Jun 12 07:37:16 2014 From: kuvaja at hp.com (Kuvaja, Erno) Date: Thu, 12 Jun 2014 07:37:16 +0000 Subject: [Openstack-security] Secure Logging Recommendations In-Reply-To: References: Message-ID: Hi all, I do agree with Bryan that it would be better not to log point 2 at all and I would suggest that if we provide this functionality to turn such on we should also make those logs at that point root/admin readable only. I would also like to add an item to Sensitive/Confidential data list. One should never log any URI or full request object. These might contain user sensitive information like credentials, data locations etc. Just a side note on the log levels. Lots of OPS are telling that currently getting anything valuable from the logs, they need to run the services on DEBUG log level. Based on this I really like the statement that DEBUG level should still never compromise the security of the information. - Erno (LP: jokke) From: Bryan D. Payne [mailto:bdpayne at acm.org] Sent: 11 June 2014 17:00 To: Paul Montgomery Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] Secure Logging Recommendations Paul, I really like this. Here's a few additional thoughts: 1) On the implementation side, doing this in Oslo seems like a good plan. At least doing as much of the security sensitive filtering stuff there. This is something we are basically asking all projects to do, so Oslo is the right answer. 2) On this point: "If confidential/sensitive data MUST be logged for root cause analysis, create an Oslo Config setting that disables security features, vividly informs the operator of this fact and make sure that the description accurately describes that this option should not be used for normal production purposes." I think that it would be nice if we just didn't do this at all. But, I understand the realities and we are likely to be more successful in our goals here if we can accommodate something like this. To that end, I could say that when the system is operating in this mode, we should prefix EVERY log line with a short string that makes it clear that this mode is for debug/test and that it shouldn't be used for production purposes. 3) CADF is interesting and appears to be getting some traction. I am not too familiar with this standard, though. It may be useful to have these logging guidelines reviewed by someone who has more familiarity with CADF to make sure that everything lines up nicely. 4) OSSG hasn't traditionally been through a process of "blessing" a document such as this. However, I would argue that it would be a good idea for us to figure out how to do this. I think that providing guidelines such as this are a valuable "next step" towards increasing influence and interactions with the dev teams. Cheers, -bryan On Fri, Jun 6, 2014 at 8:00 AM, Paul Montgomery > wrote: I created a first pass document describing some potential solutions to OpenStack sensitive data logging leaks (such as credentials or auth tokens): https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines I would appreciate reviews and discussions in order to gain approval of the OSSG and the security-minded community before making recommendations to other projects (especially in the "Possible Implementation Options" section). Thanks! ---paulmo _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Thu Jun 12 08:41:43 2014 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 12 Jun 2014 10:41:43 +0200 Subject: [Openstack-security] OSSG Meetup - lock it in In-Reply-To: References: Message-ID: <539967C7.8040700@openstack.org> Clark, Robert Graham wrote: > All, > > Those of you that are coming to the meetup please make sure that you've > put your names down on the etherpad. > > https://etherpad.openstack.org/p/ossg-juno-meetup > > The chosen date is the week starting July 14th. Please move it from "under discussion" to "future sprints" on: https://wiki.openstack.org/wiki/Sprints Cheers! -- Thierry Carrez (ttx) From ahmed.shohel at ericsson.com Thu Jun 12 10:35:21 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Thu, 12 Jun 2014 13:35:21 +0300 Subject: [Openstack-security] Security Threat modelling work for OpenStack Message-ID: <27C10253-A25D-4CED-8A64-1BCB8AD41E4F@ericsson.com> Hi, At OSSG, we are currently doing Threat Modelling of OpenStack and as a starter we have already performed initial work for Keystone. Work on Nova has also started. The current status of the work is located at https://wiki.openstack.org/wiki/Security/Threat_Analysis https://github.com/shohel02/OpenStack_Threat_Modelling.git https://github.com/criscad/OpenStack_Threat_Modelling.git In the mid review starting at July 14th, we will go through threat modelling process for Openstack projects, and for Keystone we go through a component break down and enumerate possible threats and attack vectors. Interested? Put your name in etherpad Threat Modelling section. We are especially hoping to get support and participation from Keystone core developers . I think there are some in this mailing list too :) https://etherpad.openstack.org/p/ossg-juno-meetup Cheers, Shohel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From richa.jha2 at gmail.com Wed Jun 11 12:55:22 2014 From: richa.jha2 at gmail.com (Richa Jha) Date: Wed, 11 Jun 2014 12:55:22 -0000 Subject: [Openstack-security] [Bug 1319640] Re: Console to instance persists even after logging out of Horizon References: <20140515051902.16303.85738.malonedeb@gac.canonical.com> Message-ID: <20140611125526.26528.73354.launchpad@wampee.canonical.com> ** Changed in: nova Status: Confirmed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319640 Title: Console to instance persists even after logging out of Horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Compute (Nova): Fix Released Bug description: Steps to Recreate the bug 1. Log in through Horizon dashboard 2. Create an instance and wait till it is running 3. Console the VM from drop down menu for the instance 4. Open Console on new window. 5. Now log out of the dashboard 6. Scenario 1 : Now you can see that Instance console session still persists 7. Copy the URL of console window. 8. Close the Console window 9. Scenario 2 : Reopen the window (In my case CTRL+SHIFT+T) on the browser - Will get access to the Instance Console. 10. Scenario 3: Pass on the copied URL to other LAN users and ask them to use it - Will get access to the Instance Console I assume it must have been like, Session for the console must exit once the console is closed. Must not allow multiple sessions (Refering to Scenario 3) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1319640/+subscriptions From vigneshvar.a.s at gmail.com Wed Jun 11 18:57:44 2014 From: vigneshvar.a.s at gmail.com (vigneshvar) Date: Wed, 11 Jun 2014 18:57:44 -0000 Subject: [Openstack-security] [Bug 1319640] Re: Console to instance persists even after logging out of Horizon References: <20140515051902.16303.85738.malonedeb@gac.canonical.com> Message-ID: <20140611185748.20320.90612.launchpad@wampee.canonical.com> ** Changed in: nova Status: Fix Released => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319640 Title: Console to instance persists even after logging out of Horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Compute (Nova): Confirmed Bug description: Steps to Recreate the bug 1. Log in through Horizon dashboard 2. Create an instance and wait till it is running 3. Console the VM from drop down menu for the instance 4. Open Console on new window. 5. Now log out of the dashboard 6. Scenario 1 : Now you can see that Instance console session still persists 7. Copy the URL of console window. 8. Close the Console window 9. Scenario 2 : Reopen the window (In my case CTRL+SHIFT+T) on the browser - Will get access to the Instance Console. 10. Scenario 3: Pass on the copied URL to other LAN users and ask them to use it - Will get access to the Instance Console I assume it must have been like, Session for the console must exit once the console is closed. Must not allow multiple sessions (Refering to Scenario 3) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1319640/+subscriptions From yaguang.tang at canonical.com Thu Jun 12 01:55:31 2014 From: yaguang.tang at canonical.com (Yaguang Tang) Date: Thu, 12 Jun 2014 01:55:31 -0000 Subject: [Openstack-security] [Bug 1319943] Re: libvirt driver's to_xml method logs iscsi auth_password if debug References: <20140515172919.15967.70050.malonedeb@gac.canonical.com> Message-ID: <20140612015533.19975.864.launchpad@wampee.canonical.com> ** Tags added: icehouse-backport-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1319943 Title: libvirt driver's to_xml method logs iscsi auth_password if debug Status in OpenStack Compute (Nova): Fix Released Bug description: If you have debug logging enabled the libvirt driver's to_xml method logs the iscsi auth_password in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1319943/+subscriptions From doug.chivers at hp.com Thu Jun 12 10:55:34 2014 From: doug.chivers at hp.com (Chivers, Douglas) Date: Thu, 12 Jun 2014 10:55:34 +0000 Subject: [Openstack-security] OSSG Meetup - lock it in Message-ID: Please can we add ŒDiscuss Vulnerability Impact Metrics¹ to the list. dg On 11/06/2014 16:56, "Clark, Robert Graham" wrote: >All, > >Those of you that are coming to the meetup please make sure that you've >put your names down on the etherpad. > >https://etherpad.openstack.org/p/ossg-juno-meetup > >The chosen date is the week starting July 14th. The agenda topics are >listed on the etherpad but here's the short version: > >* OSSN/OSSA - Ongoing Work >* Baseline Security Review for $project >* OSSG Book Cleanup >* Threat Modelling >* Security Anti-Patterns >* Library Audit >* Fuzz Testing >* Gate Test Hackathon > >This is a _lot_ of ground to cover, please make sure you've put your >name by all of the topics that you're interested in. > >Those of you that are leading a topic, please add a short one-two >sentence description of what you'd like to achieve with it so people can >put their names by them and we can get a good idea of what can be run in >parallel and what must be run in series. > >We need to decide on the amount of time we need to get everything done, >we initially thought that 3-4 days would be sufficient, I'm definitely >thinking more to the 4 day end of that. > >Thoughts? > >-Rob > From robert.clark at hp.com Thu Jun 12 12:03:21 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 12 Jun 2014 12:03:21 +0000 Subject: [Openstack-security] OSSG Meetup - lock it in In-Reply-To: References: Message-ID: Done. https://etherpad.openstack.org/p/ossg-juno-meetup > -----Original Message----- > From: Chivers, Douglas > Sent: 12 June 2014 11:56 > To: Clark, Robert Graham; openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] OSSG Meetup - lock it in > > Please can we add ŒDiscuss Vulnerability Impact Metrics¹ to the list. > > dg > > On 11/06/2014 16:56, "Clark, Robert Graham" > wrote: > > >All, > > > >Those of you that are coming to the meetup please make sure that you've > >put your names down on the etherpad. > > > >https://etherpad.openstack.org/p/ossg-juno-meetup > > > >The chosen date is the week starting July 14th. The agenda topics are > >listed on the etherpad but here's the short version: > > > >* OSSN/OSSA - Ongoing Work > >* Baseline Security Review for $project > >* OSSG Book Cleanup > >* Threat Modelling > >* Security Anti-Patterns > >* Library Audit > >* Fuzz Testing > >* Gate Test Hackathon > > > >This is a _lot_ of ground to cover, please make sure you've put your > >name by all of the topics that you're interested in. > > > >Those of you that are leading a topic, please add a short one-two > >sentence description of what you'd like to achieve with it so people > >can put their names by them and we can get a good idea of what can be > >run in parallel and what must be run in series. > > > >We need to decide on the amount of time we need to get everything done, > >we initially thought that 3-4 days would be sufficient, I'm definitely > >thinking more to the 4 day end of that. > > > >Thoughts? > > > >-Rob > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From robert.clark at hp.com Thu Jun 12 12:05:37 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 12 Jun 2014 12:05:37 +0000 Subject: [Openstack-security] Security Threat modelling work for OpenStack In-Reply-To: <27C10253-A25D-4CED-8A64-1BCB8AD41E4F@ericsson.com> References: <27C10253-A25D-4CED-8A64-1BCB8AD41E4F@ericsson.com> Message-ID: Doug CC'd has volunteered to help and will hopefully be coming to Seattle. -Rob From: Abu Shohel Ahmed [mailto:ahmed.shohel at ericsson.com] Sent: 12 June 2014 11:35 To: Openstack-security at lists.openstack.org , Subject: [Openstack-security] Security Threat modelling work for OpenStack Hi, At OSSG, we are currently doing Threat Modelling of OpenStack and as a starter we have already performed initial work for Keystone. Work on Nova has also started. The current status of the work is located at https://wiki.openstack.org/wiki/Security/Threat_Analysis https://github.com/shohel02/OpenStack_Threat_Modelling.git https://github.com/criscad/OpenStack_Threat_Modelling.git In the mid review starting at July 14th, we will go through threat modelling process for Openstack projects, and for Keystone we go through a component break down and enumerate possible threats and attack vectors. Interested? Put your name in etherpad Threat Modelling section. We are especially hoping to get support and participation from Keystone core developers . I think there are some in this mailing list too :) https://etherpad.openstack.org/p/ossg-juno-meetup Cheers, Shohel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From thierry.carrez+lp at gmail.com Thu Jun 12 12:35:24 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 12 Jun 2014 12:35:24 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140612123524.21474.45470.launchpad@gac.canonical.com> ** Also affects: neutron/icehouse Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): In Progress Status in OpenStack Neutron (virtual network service): Fix Committed Status in neutron icehouse series: New Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Committed Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From thierry.carrez+lp at gmail.com Thu Jun 12 12:55:30 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 12 Jun 2014 12:55:30 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140612125530.27263.48053.malone@chaenomeles.canonical.com> OK, this is confusing. Let me try to get an accurate picture of affected versions: oslo-incubator contains affected code in master (patched), stable/icehouse (in review) and stable/havana That code was copied in: Neutron: Juno (patched), Icehouse Ceilometer: Icehouse (in review), Havana Then it was adopted in: pyCADF all versions <= 0.5 (0.5.1 contains the fix) My understanding is that oslo.messaging is not affected. ** Changed in: ceilometer Status: In Progress => Invalid ** Also affects: ceilometer/havana Importance: Undecided Status: New ** Also affects: ceilometer/icehouse Importance: Undecided Status: New ** Changed in: ceilometer/icehouse Status: New => In Progress ** Also affects: oslo/havana Importance: Undecided Status: New ** Also affects: oslo/icehouse Importance: Undecided Status: New ** Changed in: oslo/icehouse Status: New => In Progress ** Changed in: pycadf Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: New Status in Ceilometer icehouse series: In Progress Status in OpenStack Neutron (virtual network service): Fix Committed Status in neutron icehouse series: New Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in oslo havana series: New Status in oslo icehouse series: In Progress Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From thierry.carrez+lp at gmail.com Thu Jun 12 13:03:34 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 12 Jun 2014 13:03:34 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140612130335.4824.34837.malone@wampee.canonical.com> Adjusted tasks to match. Here is how I would rewrite the advisory: ------ Title: User token leak to message queue in pyCADF notifier middleware Reporter: Zhi Kun Liu (IBM) Products: Neutron (2014.1 versions up to 2014.1.1) Ceilometer (2013.2 versions up to 2013.2.3, 2014.1 versions up to 2014.1.1) pyCADF library (all versions up to 0.5.0) Description: Zhi Kun Liu from IBM reported a vulnerability in the notifier middleware available in the PyCADF library and formerly copied into Neutron and Ceilometer code. An attacker with read access to the message queue may obtain authentication tokens used in REST requests (X_AUTH_TOKEN) that goes through the notifier middleware. All services using the notifier middleware configured after the auth_token middleware pipeline are impacted. ------ NB: that would mean from now on we support PyCADF, but I think now would be a good time to start. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: New Status in Ceilometer icehouse series: In Progress Status in OpenStack Neutron (virtual network service): Fix Committed Status in neutron icehouse series: New Status in Oslo - a Library of Common OpenStack Code: Fix Committed Status in oslo havana series: New Status in oslo icehouse series: In Progress Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From robert.clark at hp.com Thu Jun 12 13:51:47 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 12 Jun 2014 13:51:47 +0000 Subject: [Openstack-security] OpenStack Security Vulnerability Impact Metrics In-Reply-To: References: <539715D7.9070708@enovance.com> Message-ID: I’m glad you’re chiming in Matt, you had some interesting ideas on this a few summits back. I did a breakdown of OSSA’s at the last summit and found that I’m largely in agreement with the points you’ve made below. Ideally we want to be in a position where we can run typical analytics etc on OSSAs. +1 to OWASP, Doug was providing somewhat of a literature review. CVSSv3 was supposed to take virtualized environments into account but that’s never become an actual thing. From: matt [mailto:matt at nycresistor.com] Sent: 10 June 2014 15:37 To: Tristan Cacqueray Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OpenStack Security Vulnerability Impact Metrics I started making an attempt to role our vulnerability reporting into a more useful format two summits ago with this: https://github.com/openfly/openstack/blob/master/vulnerabilities/apr_2013/vulndb.json Any attempt to quantify risk for OpenStack starts with the collection of data, and the presentation of that data in a usable format. Today, we really don't have vulnerability information for OpenStack in a usable format. We also need to discuss the mechanism by which we will endeavour to collect information on actual exploitation of openstack adopters. I think that discussion is what we'd need to focus on before we can come up with a risk model. Get us using the same tools on the same data, and we'll have a much better time discussing which risk assessment model is right for OpenStack. As stated earlier, OWASP's risk metrics are based on the threat profile of web applications. This is well and good for horizon, but it wouldn't address the most damning vulnerabilities we've seen in keystone or the primacy of a hypervisor escape vulnerability in any threat matrix. I'd be down to collaborate on putting our vulnerability metrics together into a more usable format. Whatever we believe that to be. -Matt Joyce On Tue, Jun 10, 2014 at 10:27 AM, Tristan Cacqueray > wrote: Hi Doug, On 06/10/2014 07:54 AM, Chivers, Douglas wrote: > > Neither OWASP nor CVSS are cloud-aware, and the method described in the > security guide is very basic, so clearly none of the three is an off the > shelf solution. Due to the complexity of the maths involved in calculating > the CVSS score I would consider extending OWASP so it is applicable to > common cloud deployments. > Many thanks for this very nice summary, and it is what we (the VMT) also found out: we don't want to spend that much time on complexity calculation that might even not apply correctly for OpenStack. > > Before we try and define a framework for vulnerability assessment, I > suggest we make sure the requirements are clearly defined, here are a few: > > - Define ŒThreat¹, ŒRisk¹, ŒVulnerability, etc - threat and risk are often > used interchangeably, and do not appear to be defined in the security > guide. > Doesn't the impact description already cover those ? Maybe we could formalize those. Several project break down the description in different parts, e.g. FreeBSD: 1 Background, 2 Problem description 3 Impact 4 Workaround Xen is doing this kind of breakdown: 1 Issue description 2 Impact 3 Vulnerable systems 4 Mitigation > - The Vulnerability framework should include position in cloud in the > calculation, e.g. Œunder cloud infrastructure¹, Œon cloud infrastructure¹, > Œpublic instance¹ > > - The Vulnerability framework should include factor for type of > deployment, e.g. Œprivate¹, Œpublic¹, Œtrusted¹, Œuntrusted¹, or maybe > Œpaas¹ Œiaas¹. > That is indeed something to think about as Openstack usage can be so different, but then it can also be a great source of confusion. Some bugs are indeed much more critical for public instance than under cloud users, but most advisory are impacting all usage. > > Any thoughts? I suggest we flesh out the requirements before diving into > designing a methodology, but I¹m open to suggestions. > It would be great if we could take into account the ease of exploitation. Thinking about OSSA 2014-012 (Remote code execution in Glance Sheepdog backend) it could have use a "Fix this asap" red light compared to other bugs that are more specifics, hard to exploit, like the ones that requires social engineering. Best regards, Tristan _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From ahmed.shohel at ericsson.com Thu Jun 12 14:23:41 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Thu, 12 Jun 2014 17:23:41 +0300 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: References: <538DF4FF.5070106@redhat.com> <27C49E3A44E36C42B89B9012C5CF527C21D0AF13@SZXEMA511-MBX.china.huawei.com> Message-ID: Hi, Just to be confirmed from today meeting is from 1700-1800 UTC in #openstack-meeting-alt ? Cheers, Shohel On 04 Jun 2014, at 11:35, Clark, Robert Graham wrote: > Hi Xiaoyu, > > As you¹ll know, it¹s virtually impossible to find a meeting time that is > appropriate for everyone, especially when we have members spread all over > the world. > > I don¹t believe that the time we have chosen will work for our friends in > APAC, however, the mailing list is being used more-and-more and we publish > all the minutes from our meetings here: > > https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity > > > If our APAC numbers increase significantly we could look into options for > another meeting or look again at the timings but we¹re never going to be > able to find a time that suits everyone. > > Hope this helps > -Rob > > > > > > On 04/06/2014 09:30, "Gexiaoyu" wrote: > >> Hi Rob >> >> I'm interested in the meeting, Is there a appropriate time that APAC guys >> can attend. >> >> Thanks, >> Xiaoyu >> >> -----Original Message----- >> From: Clark, Robert Graham [mailto:robert.clark at hp.com] >> Sent: Wednesday, June 04, 2014 1:44 AM >> To: Nathan Kinder; openstack-security at lists.openstack.org >> Subject: Re: [Openstack-security] [OSSG] Meeting Time >> >> Great. >> >> Lets keep the normal session for this week so we can tell the people who >> attend about the change in time for next week. >> >> >> >>> -----Original Message----- >>> From: Nathan Kinder [mailto:nkinder at redhat.com] >>> Sent: 03 June 2014 17:17 >>> To: openstack-security at lists.openstack.org >>> Subject: Re: [Openstack-security] [OSSG] Meeting Time >>> >>> >>> >>> On 06/03/2014 08:50 AM, Brant Knudson wrote: >>>> >>>> That time works for me. - Brant >>> >>> Same here. >>> >>> -NGK >>> >>>> >>>> >>>> On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham >>>> > wrote: >>>> >>>> Sorry, long week. >>>> >>>> Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. >>>> >>>> >>>> From: Bryan Payne >>> >>> >> >>>> Date: Friday, 30 May 2014 17:32 >>>> To: Robert Clark >>> >>> >> >>>> Cc: "openstack-security at lists.openstack.org >>>> >> >> security at lists.openstack.org >>>> >" >>>> >>> >> >> security at lists.openstack.org >>>> >> >>>> Subject: Re: [Openstack-security] [OSSG] Meeting Time >>>> >>>> I'm guessing you really mean: >>>> Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? >>>> >>>> Personally... This isn't ideal for me, as I have a daily meeting >>>> from 1730 - 1800. Having said that, I can make this work, if >>>> needed. >>>> >>>> -bryan >>>> >>>> >>>> On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham >>>> >>> >>> >> wrote: >>>> Hi All, >>>> >>>> I think we're all agreed that we could do with some extra time >> to >>>> have OSSG discussions, I'm glad to say that we now have more to >>>> say >>>> than we used to! - I'd like to extend the meeting out to an hour >>>> with the obvious caveat that we'll end when possible. >>>> >>>> I'd like to propose that we bring the meeting forward by an hour >> >>>> and >>>> extend it to an hour, making the meeting 1700-1800UTC this >> should >>>> mean that our west coast friends don't have to get up too early >>>> while allowing our EMEA folks to finish work too late. >>>> >>>> Looking at the availability on >>>> >>> >> https://wiki.openstack.org/wiki/Meetings> / >>> Meetings#OpenStack_Project_.26_Release_Status_meeting> >>>> this should work just fine but we'll have to move to holding the >>>> meeting #openstack-meeting-alt >>>> >>>> So the proposal I'm making is: >>>> Thursdays 1800 UTC in #openstack-meeting-alt >>>> >>>> I'm more than happy to hear other proposals if there's a >>>> better/more >>>> suitable time for everyone. >>>> >>>> -Rob >>>> >>>> _______________________________________________ >>>> Openstack-security mailing list >>>> Openstack-security at lists.openstack.org >>>> >> >> security at lists.openstack.org >>>> > >>>> >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>>> >>>> >>>> _______________________________________________ >>>> Openstack-security mailing list >>>> Openstack-security at lists.openstack.org >>>> >>>> >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Openstack-security mailing list >>>> Openstack-security at lists.openstack.org >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>>> >>> >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From robert.clark at hp.com Thu Jun 12 14:52:35 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 12 Jun 2014 14:52:35 +0000 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: References: <538DF4FF.5070106@redhat.com> <27C49E3A44E36C42B89B9012C5CF527C21D0AF13@SZXEMA511-MBX.china.huawei.com> Message-ID: That is correct :) From: Abu Shohel Ahmed [mailto:ahmed.shohel at ericsson.com] Sent: 12 June 2014 15:24 To: Clark, Robert Graham Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [OSSG] Meeting Time Hi, Just to be confirmed from today meeting is from 1700-1800 UTC in #openstack-meeting-alt ? Cheers, Shohel On 04 Jun 2014, at 11:35, Clark, Robert Graham > wrote: Hi Xiaoyu, As you¹ll know, it¹s virtually impossible to find a meeting time that is appropriate for everyone, especially when we have members spread all over the world. I don¹t believe that the time we have chosen will work for our friends in APAC, however, the mailing list is being used more-and-more and we publish all the minutes from our meetings here: https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity If our APAC numbers increase significantly we could look into options for another meeting or look again at the timings but we¹re never going to be able to find a time that suits everyone. Hope this helps -Rob On 04/06/2014 09:30, "Gexiaoyu" > wrote: Hi Rob I'm interested in the meeting, Is there a appropriate time that APAC guys can attend. Thanks, Xiaoyu -----Original Message----- From: Clark, Robert Graham [mailto:robert.clark at hp.com] Sent: Wednesday, June 04, 2014 1:44 AM To: Nathan Kinder; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [OSSG] Meeting Time Great. Lets keep the normal session for this week so we can tell the people who attend about the change in time for next week. -----Original Message----- From: Nathan Kinder [mailto:nkinder at redhat.com] Sent: 03 June 2014 17:17 To: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [OSSG] Meeting Time On 06/03/2014 08:50 AM, Brant Knudson wrote: That time works for me. - Brant Same here. -NGK On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham > wrote: Sorry, long week. Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. From: Bryan Payne >> Date: Friday, 30 May 2014 17:32 To: Robert Clark >> Cc: "openstack-security at lists.openstack.org >" >> Subject: Re: [Openstack-security] [OSSG] Meeting Time I'm guessing you really mean: Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? Personally... This isn't ideal for me, as I have a daily meeting from 1730 - 1800. Having said that, I can make this work, if needed. -bryan On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham >> wrote: Hi All, I think we're all agreed that we could do with some extra time to have OSSG discussions, I'm glad to say that we now have more to say than we used to! - I'd like to extend the meeting out to an hour with the obvious caveat that we'll end when possible. I'd like to propose that we bring the meeting forward by an hour and extend it to an hour, making the meeting 1700-1800UTC this should mean that our west coast friends don't have to get up too early while allowing our EMEA folks to finish work too late. Looking at the availability on https://wiki.openstack.org/wiki/Meetings this should work just fine but we'll have to move to holding the meeting #openstack-meeting-alt So the proposal I'm making is: Thursdays 1800 UTC in #openstack-meeting-alt I'm more than happy to hear other proposals if there's a better/more suitable time for everyone. -Rob _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From sriram at sriramhere.com Thu Jun 12 15:02:04 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 12 Jun 2014 08:02:04 -0700 Subject: [Openstack-security] [OSSG] Meeting Time In-Reply-To: References: <538DF4FF.5070106@redhat.com> <27C49E3A44E36C42B89B9012C5CF527C21D0AF13@SZXEMA511-MBX.china.huawei.com> Message-ID: I will be missing this since I am at HP Discover this week. On Thu, Jun 12, 2014 at 7:23 AM, Abu Shohel Ahmed wrote: > Hi, > > Just to be confirmed from today meeting is from 1700-1800 UTC in > #openstack-meeting-alt ? > > Cheers, > Shohel > > On 04 Jun 2014, at 11:35, Clark, Robert Graham > wrote: > > Hi Xiaoyu, > > As you¹ll know, it¹s virtually impossible to find a meeting time that is > appropriate for everyone, especially when we have members spread all over > the world. > > I don¹t believe that the time we have chosen will work for our friends in > APAC, however, the mailing list is being used more-and-more and we publish > all the minutes from our meetings here: > > https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity > > > If our APAC numbers increase significantly we could look into options for > another meeting or look again at the timings but we¹re never going to be > able to find a time that suits everyone. > > Hope this helps > -Rob > > > > > > On 04/06/2014 09:30, "Gexiaoyu" wrote: > > Hi Rob > > I'm interested in the meeting, Is there a appropriate time that APAC guys > can attend. > > Thanks, > Xiaoyu > > -----Original Message----- > From: Clark, Robert Graham [mailto:robert.clark at hp.com] > Sent: Wednesday, June 04, 2014 1:44 AM > To: Nathan Kinder; openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > Great. > > Lets keep the normal session for this week so we can tell the people who > attend about the change in time for next week. > > > > -----Original Message----- > From: Nathan Kinder [mailto:nkinder at redhat.com] > Sent: 03 June 2014 17:17 > To: openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > > > On 06/03/2014 08:50 AM, Brant Knudson wrote: > > > That time works for me. - Brant > > > Same here. > > -NGK > > > > On Fri, May 30, 2014 at 11:35 AM, Clark, Robert Graham > > wrote: > > Sorry, long week. > > Yes the proposal is 1700-1800 UTC in #openstack-meeting-alt. > > > From: Bryan Payne >> > Date: Friday, 30 May 2014 17:32 > To: Robert Clark >> > Cc: "openstack-security at lists.openstack.org > > > security at lists.openstack.org > > >" > > > security at lists.openstack.org > > >> > Subject: Re: [Openstack-security] [OSSG] Meeting Time > > I'm guessing you really mean: > Thursdays at 1700 - 1800 UTC in #openstack-meeting-alt ? > > Personally... This isn't ideal for me, as I have a daily meeting > from 1730 - 1800. Having said that, I can make this work, if > needed. > > -bryan > > > On Fri, May 30, 2014 at 8:25 AM, Clark, Robert Graham > >> wrote: > Hi All, > > I think we're all agreed that we could do with some extra time > > to > > have OSSG discussions, I'm glad to say that we now have more to > say > than we used to! - I'd like to extend the meeting out to an hour > with the obvious caveat that we'll end when possible. > > I'd like to propose that we bring the meeting forward by an hour > > > and > extend it to an hour, making the meeting 1700-1800UTC this > > should > > mean that our west coast friends don't have to get up too early > while allowing our EMEA folks to finish work too late. > > Looking at the availability on > > > https://wiki.openstack.org/wiki/Meetings / > > Meetings#OpenStack_Project_.26_Release_Status_meeting> > > this should work just fine but we'll have to move to holding the > meeting #openstack-meeting-alt > > So the proposal I'm making is: > Thursdays 1800 UTC in #openstack-meeting-alt > > I'm more than happy to hear other proposals if there's a > better/more > suitable time for everyone. > > -Rob > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > > > security at lists.openstack.org > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -- Thanks, -Sriram 425-610-8465 www.sriramhere.com | www.clouddon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry.carrez+lp at gmail.com Thu Jun 12 14:43:38 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 12 Jun 2014 14:43:38 -0000 Subject: [Openstack-security] [Bug 1262759] Re: ICMPv6 RAs should only be permitted from known routers References: <20131219170628.26400.87374.malonedeb@chaenomeles.canonical.com> Message-ID: <20140612144342.22082.74448.launchpad@gac.canonical.com> ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1262759 Title: ICMPv6 RAs should only be permitted from known routers Status in OpenStack Neutron (virtual network service): Fix Released Status in OpenStack Security Advisories: Invalid Bug description: ICMPv6 is now allowed in from any host but other hosts can offer bogus routes. Change security group/port filtering to respect known routers: - tenant routers attached to subnets and passing v6 - physical routers on provider networks provided on the network (as some sort of admin configurable list for that network). (Security issue: One VM sharing a neutron network can divert outgoing traffic from other VMs.) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1262759/+subscriptions From thierry.carrez+lp at gmail.com Thu Jun 12 14:41:49 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 12 Jun 2014 14:41:49 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140612144153.5071.71561.launchpad@soybean.canonical.com> ** Changed in: neutron Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From thierry.carrez+lp at gmail.com Thu Jun 12 14:50:03 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 12 Jun 2014 14:50:03 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140612145007.21743.24768.launchpad@gac.canonical.com> ** Changed in: neutron Status: Fix Committed => Fix Released ** Changed in: neutron Milestone: None => juno-1 ** Changed in: oslo Status: Fix Committed => Fix Released ** Changed in: oslo Milestone: None => juno-1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: New Status in Ceilometer icehouse series: In Progress Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: New Status in oslo icehouse series: In Progress Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From gerrit2 at review.openstack.org Thu Jun 12 16:48:36 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Jun 2014 16:48:36 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/99432 Log: commit 299c88048468615d0fecf5e21a3fc4f17f428215 Author: Morgan Fainberg Date: Wed Jun 11 10:13:32 2014 -0700 Do not expose Token IDs in debug output It is only very slightly less of a security issue to expose Token IDs in the logs than it is to expose password details. This change obscures the Token ID in the debug output in all cases to ensure that the ID is not presented in any of the logs that could be read by a unpriviledged source (e.g. lower priv log watchers, centralized logging, etc). SHA1 is no longer allowed as a hashing mode for CMS token hashing. This is because SHA1 is being used to obscure tokens in the session object debug. This is done to prevent the debug output from being potentially exposing a valid token (PKI->sha1-short-id) in some configurations of Keystone / auth_token middleware. The raw data elements from the token (e.g. user, roles, expiration etc) could be added into debug/trace level logging at a future time. SecurityImpact Change-Id: If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 From gerrit2 at review.openstack.org Thu Jun 12 17:01:29 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Jun 2014 17:01:29 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I774170ff1649bd3b55c6849ed07824bcddecea75 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/99715 Log: commit 857803885a851735a70835127dfb0a7001ff9c00 Author: Morgan Fainberg Date: Thu Jun 12 09:54:00 2014 -0700 SHA1 is not valid for CMS hashing SHA1 is not a valid target for CMS hashing since it is being used to obscure the tokens in the debug output of the keystoneclient session object. This is to prevent a case where the debug output could contain a valid token. Sample config has also been updated. SecurityImpact Change-Id: I774170ff1649bd3b55c6849ed07824bcddecea75 From gerrit2 at review.openstack.org Thu Jun 12 17:04:16 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Jun 2014 17:04:16 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I774170ff1649bd3b55c6849ed07824bcddecea75 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/99715 Log: commit a421b44224a3a7a5ffcdd8537079e481087cbfca Author: Morgan Fainberg Date: Thu Jun 12 09:54:00 2014 -0700 SHA1 is not valid for CMS hashing SHA1 is not a valid target for CMS hashing since it is being used to obscure the tokens in the debug output of the keystoneclient session object. This is to prevent a case where the debug output could contain a valid token. This change is to match with the Keystoneclient change: https://review.openstack.org/#/c/99432/ Sample config has also been updated. SecurityImpact Change-Id: I774170ff1649bd3b55c6849ed07824bcddecea75 From robert.clark at hp.com Thu Jun 12 17:51:20 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 12 Jun 2014 17:51:20 +0000 Subject: [Openstack-security] OSSG Meeting Minutes - 12 Jun 2014 Message-ID: Great meeting today! Meeting started by hyakuhei at 17:02:20 UTC (full logs). Meeting summary 1. OpenStack Security Notes (hyakuhei, 17:06:22) * https://review.openstack.org/#/c/99420/ (nkinder, 17:07:08) 2. Gate tests (hyakuhei, 17:13:08) * https://etherpad.openstack.org/p/ossg-juno-meetup (hyakuhei, 17:19:30) * ACTION: viraptor_ and tmcpeak to come up with a basic blueprint for security gate jobs, likely to be info-only to start with and applying only the most basic of tests. (hyakuhei, 17:27:28) 3. OSSG Meetup (hyakuhei, 17:28:48) * http://www.westinseattle.com/ (hyakuhei, 17:34:25) 4. General / Any other business / Gripes (hyakuhei, 17:43:48) * https://etherpad.openstack.org/p/ossg-juno-meetup updated (hyakuhei, 17:48:20) Meeting ended at 17:49:20 UTC (full logs). Action items 1. viraptor_ and tmcpeak to come up with a basic blueprint for security gate jobs, likely to be info-only to start with and applying only the most basic of tests. Action items, by person 1. tmcpeak * viraptor_ and tmcpeak to come up with a basic blueprint for security gate jobs, likely to be info-only to start with and applying only the most basic of tests. 2. viraptor_ * viraptor_ and tmcpeak to come up with a basic blueprint for security gate jobs, likely to be info-only to start with and applying only the most basic of tests. People present (lines said) 1. hyakuhei (120) 2. tmcpeak (63) 3. nkinder (56) 4. bdpayne (17) 5. shohel__ (11) 6. dg_ (8) 7. viraptor_ (5) 8. chair6 (4) 9. tkelsey (3) 10. openstack (3) 11. CristianF (2) 12. From nkinder at redhat.com Thu Jun 12 17:53:02 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 12 Jun 2014 10:53:02 -0700 Subject: [Openstack-security] Secure Logging Recommendations In-Reply-To: References: Message-ID: <5399E8FE.2040505@redhat.com> On 06/12/2014 12:37 AM, Kuvaja, Erno wrote: > Hi all, > > > > I do agree with Bryan that it would be better not to log point 2 at all > and I would suggest that if we provide this functionality to turn such > on we should also make those logs at that point root/admin readable only. I would really prefer that we just don't have an option to allow logging of things like credentials (passwords/tokens) in the first place. This seems like something that we should be firmly against. > > > > I would also like to add an item to Sensitive/Confidential data list. > One should never log any URI or full request object. These might contain > user sensitive information like credentials, data locations etc. > > > > Just a side note on the log levels. Lots of OPS are telling that > currently getting anything valuable from the logs, they need to run the > services on DEBUG log level. Based on this I really like the statement > that DEBUG level should still never compromise the security of the > information. +1. > > > > - Erno (LP: jokke) > > > > *From:*Bryan D. Payne [mailto:bdpayne at acm.org] > *Sent:* 11 June 2014 17:00 > *To:* Paul Montgomery > *Cc:* openstack-security at lists.openstack.org > *Subject:* Re: [Openstack-security] Secure Logging Recommendations > > > > Paul, > > > > I really like this. Here's a few additional thoughts: > > > > 1) On the implementation side, doing this in Oslo seems like a good > plan. At least doing as much of the security sensitive filtering stuff > there. This is something we are basically asking all projects to do, so > Oslo is the right answer. > > > > 2) On this point: > > > > "If confidential/sensitive data MUST be logged for root cause analysis, > create an Oslo Config setting that disables security features, vividly > informs the operator of this fact and make sure that the description > accurately describes that this option should not be used for normal > production purposes." > > > > I think that it would be nice if we just didn't do this at all. But, I > understand the realities and we are likely to be more successful in our > goals here if we can accommodate something like this. To that end, I > could say that when the system is operating in this mode, we > should prefix EVERY log line with a short string that makes it clear > that this mode is for debug/test and that it shouldn't be used for > production purposes. > > > > 3) CADF is interesting and appears to be getting some traction. I am > not too familiar with this standard, though. It may be useful to have > these logging guidelines reviewed by someone who has more familiarity > with CADF to make sure that everything lines up nicely. > > > > 4) OSSG hasn't traditionally been through a process of "blessing" > a document such as this. However, I would argue that it would be a good > idea for us to figure out how to do this. I think that providing > guidelines such as this are a valuable "next step" towards increasing > influence and interactions with the dev teams. > > > > Cheers, > > -bryan > > > > > > On Fri, Jun 6, 2014 at 8:00 AM, Paul Montgomery > > > wrote: > > I created a first pass document describing some potential solutions > to OpenStack sensitive data logging leaks (such as credentials or > auth tokens): > > > > https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines > > > > I would appreciate reviews and discussions in order to gain approval > of the OSSG and the security-minded community before making > recommendations to other projects (especially in the "Possible > Implementation Options" section). > > > > Thanks! > > ---paulmo > > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > From Priti_Desai at symantec.com Thu Jun 12 18:00:15 2014 From: Priti_Desai at symantec.com (Priti Desai) Date: Thu, 12 Jun 2014 11:00:15 -0700 Subject: [Openstack-security] Secure Logging Recommendations In-Reply-To: References: Message-ID: I agree on making logs in (2) only readable by root/admin. It might be tricky to enforce it for already deployed services. I would like to add an item on collecting DEBUG logs for a particular request. I did not find any notion of START and END of log messages in Keystone which makes it very hard to troubleshoot, also adds complexity in Monitoring and Notification of services. Cheers Priti From: , Erno > Date: Thursday, June 12, 2014 12:37 AM To: "Bryan D. Payne" >, Paul Montgomery > Cc: "openstack-security at lists.openstack.org" > Subject: Re: [Openstack-security] Secure Logging Recommendations Hi all, I do agree with Bryan that it would be better not to log point 2 at all and I would suggest that if we provide this functionality to turn such on we should also make those logs at that point root/admin readable only. I would also like to add an item to Sensitive/Confidential data list. One should never log any URI or full request object. These might contain user sensitive information like credentials, data locations etc. Just a side note on the log levels. Lots of OPS are telling that currently getting anything valuable from the logs, they need to run the services on DEBUG log level. Based on this I really like the statement that DEBUG level should still never compromise the security of the information. - Erno (LP: jokke) From: Bryan D. Payne [mailto:bdpayne at acm.org] Sent: 11 June 2014 17:00 To: Paul Montgomery Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] Secure Logging Recommendations Paul, I really like this. Here's a few additional thoughts: 1) On the implementation side, doing this in Oslo seems like a good plan. At least doing as much of the security sensitive filtering stuff there. This is something we are basically asking all projects to do, so Oslo is the right answer. 2) On this point: "If confidential/sensitive data MUST be logged for root cause analysis, create an Oslo Config setting that disables security features, vividly informs the operator of this fact and make sure that the description accurately describes that this option should not be used for normal production purposes." I think that it would be nice if we just didn't do this at all. But, I understand the realities and we are likely to be more successful in our goals here if we can accommodate something like this. To that end, I could say that when the system is operating in this mode, we should prefix EVERY log line with a short string that makes it clear that this mode is for debug/test and that it shouldn't be used for production purposes. 3) CADF is interesting and appears to be getting some traction. I am not too familiar with this standard, though. It may be useful to have these logging guidelines reviewed by someone who has more familiarity with CADF to make sure that everything lines up nicely. 4) OSSG hasn't traditionally been through a process of "blessing" a document such as this. However, I would argue that it would be a good idea for us to figure out how to do this. I think that providing guidelines such as this are a valuable "next step" towards increasing influence and interactions with the dev teams. Cheers, -bryan On Fri, Jun 6, 2014 at 8:00 AM, Paul Montgomery > wrote: I created a first pass document describing some potential solutions to OpenStack sensitive data logging leaks (such as credentials or auth tokens): https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines I would appreciate reviews and discussions in order to gain approval of the OSSG and the security-minded community before making recommendations to other projects (especially in the "Possible Implementation Options" section). Thanks! ---paulmo _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1316271 at bugs.launchpad.net Thu Jun 12 19:18:53 2014 From: 1316271 at bugs.launchpad.net (Stanislaw Pitucha) Date: Thu, 12 Jun 2014 19:18:53 -0000 Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts can SSH to compute node References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20140612191855.4793.25337.launchpad@wampee.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Stanislaw Pitucha (stanislaw-pitucha) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From gerrit2 at review.openstack.org Thu Jun 12 22:35:21 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Jun 2014 22:35:21 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change If698fc1d0751cded556825b081539da4dd51275e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/95989 Log: commit 6e39f581fd78407493658b6260b3683e9de7dfee Author: Adam Young Date: Tue May 27 21:51:12 2014 -0400 Kerberos as method name To date kerberos has been supported by the "external" method name. However, the Client plugin architecture needs to refer to the method name , and we do not want to expose to the client the difference between kerberos as performed by an external module or an eventual kerberos-in-eventlet style implementation. If the "external" plugin is missing, the old code would throw an exception attempting to process "REMOTE_USER" behavior. If only 'Kerberos" is specified, this is checked and skipped. Blueprint: kerberos-authentication SecurityImpact: Minimal, as Kerberos is already used via external, this just changes the main way it is named. Change-Id: If698fc1d0751cded556825b081539da4dd51275e From gerrit2 at review.openstack.org Fri Jun 13 00:57:40 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 13 Jun 2014 00:57:40 +0000 Subject: [Openstack-security] [stackforge/kite] SecurityImpact review request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80903 Log: commit ada7e34c35b4a3d3c2ad277e6aa97c38304499ac Author: Jamie Lennox Date: Tue Dec 3 12:33:28 2013 +1000 Add ticket handling to KDS Adds creation of tickets to transmit communication keys between peers. SecurityImpact Change-Id: I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 From gerrit2 at review.openstack.org Fri Jun 13 02:37:34 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 13 Jun 2014 02:37:34 +0000 Subject: [Openstack-security] [stackforge/kite] SecurityImpact review request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80903 Log: commit cd3c481a492bcbdd5a5f3cf716dcecaf89909dcc Author: Jamie Lennox Date: Tue Dec 3 12:33:28 2013 +1000 Add ticket handling to KDS Adds creation of tickets to transmit communication keys between peers. SecurityImpact Change-Id: I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 From gerrit2 at review.openstack.org Fri Jun 13 06:36:09 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 13 Jun 2014 06:36:09 +0000 Subject: [Openstack-security] [stackforge/kite] SecurityImpact review request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80903 Log: commit 6b54c09bad2b12b720e03fb6d12c76fd57413b3b Author: Jamie Lennox Date: Tue Dec 3 12:33:28 2013 +1000 Add ticket handling to KDS Adds creation of tickets to transmit communication keys between peers. SecurityImpact Change-Id: I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 From 1320098 at bugs.launchpad.net Fri Jun 13 06:48:12 2014 From: 1320098 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 13 Jun 2014 06:48:12 -0000 Subject: [Openstack-security] [Bug 1320098] Re: neutronclient debug logging includes keystone auth token References: <20140516064420.2758.66631.malonedeb@wampee.canonical.com> Message-ID: <20140613064814.27199.67272.launchpad@chaenomeles.canonical.com> ** Changed in: python-neutronclient Assignee: Xu Han Peng (xuhanp) => Feng Ju (jufeng) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320098 Title: neutronclient debug logging includes keystone auth token Status in Python client library for Neutron: In Progress Bug description: neutronclient is logging the auth token in the nova logs. Since the logs are world-readable, this means anyone user on this system can see the auth token, which they can then use to get OpenStack administrator access. To manage notifications about this bug go to: https://bugs.launchpad.net/python-neutronclient/+bug/1320098/+subscriptions From devoid at anl.gov Fri Jun 13 16:08:49 2014 From: devoid at anl.gov (Scott Devoid) Date: Fri, 13 Jun 2014 16:08:49 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20140613160849.21671.62517.malone@gac.canonical.com> Hi vaibhav, are you still working 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/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 devoid at anl.gov Fri Jun 13 16:14:14 2014 From: devoid at anl.gov (Scott Devoid) Date: Fri, 13 Jun 2014 16:14:14 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20140613161414.21814.5794.malone@gac.canonical.com> I would propose the following behavior: When os-quota-sets is updated, nova-api checks the quota tables to see if the quota-set for the project ID already exists in the table. If it does exist, then update with the new quota value. Otherwise, use keystoneclient to confirm that the project ID exists. If it does not exist, return an appropriate error to the API. Otherwise update the new quota value. This will catch the error except for cases where the quota table is already corrupted with quotas that apply to no projects. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From paul.montgomery at RACKSPACE.COM Fri Jun 13 19:51:38 2014 From: paul.montgomery at RACKSPACE.COM (Paul Montgomery) Date: Fri, 13 Jun 2014 19:51:38 +0000 Subject: [Openstack-security] Secure Logging Recommendations In-Reply-To: References: Message-ID: All, Thank you so much for the great input and discussion! I made edits to the document based on feedback received including: * Added a note indicating that the Oslo implementation path is the community desired implementation path to date. * Removed the concept of an Oslo Config option to disable log security (which would have enabled logging of some sensitive data). * Don't log URI or full request objects which could contain credential or data location information. * Added a discussion point, based on feedback, about the possibility of enabling AUDIT log setting to log some sensitive data (AUDIT would not be a recommended production setting in this form obviously). Thanks! https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines From: Priti Desai > Date: Thursday, June 12, 2014 1:00 PM To: "Kuvaja, Erno" >, "Bryan D. Payne" >, Paul Montgomery > Cc: "openstack-security at lists.openstack.org" > Subject: Re: [Openstack-security] Secure Logging Recommendations I agree on making logs in (2) only readable by root/admin. It might be tricky to enforce it for already deployed services. I would like to add an item on collecting DEBUG logs for a particular request. I did not find any notion of START and END of log messages in Keystone which makes it very hard to troubleshoot, also adds complexity in Monitoring and Notification of services. Cheers Priti From: , Erno > Date: Thursday, June 12, 2014 12:37 AM To: "Bryan D. Payne" >, Paul Montgomery > Cc: "openstack-security at lists.openstack.org" > Subject: Re: [Openstack-security] Secure Logging Recommendations Hi all, I do agree with Bryan that it would be better not to log point 2 at all and I would suggest that if we provide this functionality to turn such on we should also make those logs at that point root/admin readable only. I would also like to add an item to Sensitive/Confidential data list. One should never log any URI or full request object. These might contain user sensitive information like credentials, data locations etc. Just a side note on the log levels. Lots of OPS are telling that currently getting anything valuable from the logs, they need to run the services on DEBUG log level. Based on this I really like the statement that DEBUG level should still never compromise the security of the information. - Erno (LP: jokke) From: Bryan D. Payne [mailto:bdpayne at acm.org] Sent: 11 June 2014 17:00 To: Paul Montgomery Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] Secure Logging Recommendations Paul, I really like this. Here's a few additional thoughts: 1) On the implementation side, doing this in Oslo seems like a good plan. At least doing as much of the security sensitive filtering stuff there. This is something we are basically asking all projects to do, so Oslo is the right answer. 2) On this point: "If confidential/sensitive data MUST be logged for root cause analysis, create an Oslo Config setting that disables security features, vividly informs the operator of this fact and make sure that the description accurately describes that this option should not be used for normal production purposes." I think that it would be nice if we just didn't do this at all. But, I understand the realities and we are likely to be more successful in our goals here if we can accommodate something like this. To that end, I could say that when the system is operating in this mode, we should prefix EVERY log line with a short string that makes it clear that this mode is for debug/test and that it shouldn't be used for production purposes. 3) CADF is interesting and appears to be getting some traction. I am not too familiar with this standard, though. It may be useful to have these logging guidelines reviewed by someone who has more familiarity with CADF to make sure that everything lines up nicely. 4) OSSG hasn't traditionally been through a process of "blessing" a document such as this. However, I would argue that it would be a good idea for us to figure out how to do this. I think that providing guidelines such as this are a valuable "next step" towards increasing influence and interactions with the dev teams. Cheers, -bryan On Fri, Jun 6, 2014 at 8:00 AM, Paul Montgomery > wrote: I created a first pass document describing some potential solutions to OpenStack sensitive data logging leaks (such as credentials or auth tokens): https://wiki.openstack.org/wiki/Security/Guidelines/logging_guidelines I would appreciate reviews and discussions in order to gain approval of the OSSG and the security-minded community before making recommendations to other projects (especially in the "Possible Implementation Options" section). Thanks! ---paulmo _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Fri Jun 13 21:40:24 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 13 Jun 2014 21:40:24 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/99432 Log: commit 6500d795d58e2c642677547329908ba816ef1463 Author: Morgan Fainberg Date: Wed Jun 11 10:13:32 2014 -0700 Do not expose Token IDs in debug output It is only very slightly less of a security issue to expose Token IDs in the logs than it is to expose password details. This change obscures the Token ID in the debug output in all cases to ensure that the ID is not presented in any of the logs that could be read by a unprivileged source (e.g. lower priv log watchers, centralized logging, etc). The main use case is to ensure that it is possible to correlate a token to the various requests made. In some cases this has shown where a token has expired (tokens weren't properly refreshed). This use case for debugging eliminates simple redaction of the token id from the logs. SHA1 is no longer allowed as a hashing mode for CMS token hashing. This is because SHA1 is being used to obscure tokens in the session object debug. This is done to prevent the debug output from being potentially exposing a valid token (PKI->sha1-short-id) in some configurations of Keystone / auth_token middleware. The raw data elements from the token (e.g. user, roles, expiration etc) could be added into debug/trace level logging at a future time. SecurityImpact Change-Id: If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 From gerrit2 at review.openstack.org Sat Jun 14 14:35:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 14 Jun 2014 14:35:02 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 92466ba19517e13702b0535f324d62347b2cea5a Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1299012 at bugs.launchpad.net Sat Jun 14 18:33:37 2014 From: 1299012 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 14 Jun 2014 18:33:37 -0000 Subject: [Openstack-security] [Bug 1299012] Related fix merged to keystone (master) References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com> Message-ID: <20140614183337.26732.2565.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/97852 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=7f5e120ab8e73fc77360a4adb2f73f2516bae8a0 Submitter: Jenkins Branch: master commit 7f5e120ab8e73fc77360a4adb2f73f2516bae8a0 Author: Morgan Fainberg Date: Wed Jun 4 09:37:12 2014 -0700 Use translation hints Use the _LI() function instead of _() for new LOG.info messages. Change-Id: I6af25a33018e76b321488cacea65885fa597abbf Related-Bug: #1299012 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1299012 Title: V3 api authentication method chaining Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Advisories: Invalid Bug description: When using authentication method chaining for token creation (POST) in Keystone V3 api , it is possible to use authentication credentials for two different users . For example, if i have an existing token for a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier for demo tenant) and i have a user say 'test131' in admin tenant Now i can make an authentication call using auth method chaining { "auth":{ "identity":{ "methods":[ "password", "token" ], "token":{ "id":"6bb934a0120f097a32b5d3cc71f83beb" }, "password":{ "user":{ "domain":{ "id":"default" }, "name":"test131", "password":"test131" } } } } } The call will succeed even though two different users authentication credentials are used. The generated token will get properties of test131 user although the expirary date is set by demo user token. If we change the methods sequence, the generated token will get all properties from demo users token. This is an undesired security behaviour - token should not be allowed to generate using credentials from two different users. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299012/+subscriptions From 1321080 at bugs.launchpad.net Mon Jun 16 06:50:07 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 Jun 2014 06:50:07 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140616065007.31870.77526.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/94770 Committed: https://git.openstack.org/cgit/openstack/oslo-incubator/commit/?id=354a9f99d177fd14d86e099ee3ffa91b9d12b5bd Submitter: Jenkins Branch: stable/icehouse commit 354a9f99d177fd14d86e099ee3ffa91b9d12b5bd Author: Gordon Chung Date: Tue May 20 12:30:41 2014 -0400 remove token from notifier middleware notifier middleware is capturing token and sending it to MQ. this is not advisable so we should filter it out. Change-Id: Ia1bfa1bd24989681db1d2f385defc12e69a01f8d Closes-Bug: #1321080 (cherry picked from commit 09281ccf7837b70962ad2dfbaa1e84722ad987e8) ** Changed in: ceilometer/icehouse Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: New Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: New Status in oslo icehouse series: In Progress Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1118066 at bugs.launchpad.net Mon Jun 16 13:22:58 2014 From: 1118066 at bugs.launchpad.net (vaibhav) Date: Mon, 16 Jun 2014 13:22:58 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20140616132301.28939.58268.launchpad@soybean.canonical.com> ** Changed in: nova Assignee: vaibhav (vaibhav-bhatkar) => (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/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 1118066 at bugs.launchpad.net Mon Jun 16 13:27:23 2014 From: 1118066 at bugs.launchpad.net (vaibhav) Date: Mon, 16 Jun 2014 13:27:23 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> <20140613161414.21814.5794.malone@gac.canonical.com> Message-ID: Hi Scott, We fixed the bug keystone way in "Manila" but it was decided later that the bug would not be fixed. Will send you the link of the fix tomorrow as I am travelling today. BTW, keystoneclient is the only way to go as we are not sure what keystone database is used in the background. Administrator might have configured keystone to use LDAP. Vaibhav On Fri, Jun 13, 2014 at 9:44 PM, Scott Devoid wrote: > I would propose the following behavior: > > When os-quota-sets is updated, nova-api checks the quota tables to see > if the quota-set for the project ID already exists in the table. If it > does exist, then update with the new quota value. Otherwise, use > keystoneclient to confirm that the project ID exists. If it does not > exist, return an appropriate error to the API. Otherwise update the new > quota value. > > This will catch the error except for cases where the quota table is > already corrupted with quotas that apply to no projects. > > -- > You received this bug notification because you are a bug assignee. > 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 > -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From thierry.carrez+lp at gmail.com Mon Jun 16 14:04:00 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 16 Jun 2014 14:04:00 -0000 Subject: [Openstack-security] [Bug 1329737] Re: Valid tokens remain after token's user was deleted References: <20140613111922.26567.45578.malonedeb@chaenomeles.canonical.com> Message-ID: <20140616140401.24358.45387.launchpad@chaenomeles.canonical.com> ** Also affects: ossa Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329737 Title: Valid tokens remain after token's user was deleted Status in OpenStack Identity (Keystone): Triaged Status in OpenStack Security Advisories: New Bug description: When user is deleted, deleted user's tokens are expired after committing transaction for deleting user. If database dies while tokens are being expired, remaining tokens will lose the chance to expire until 24 hours later. (Because user is already deleted.) In this case, remaining tokens are able to used to authenticate despite the fact that token's user was deleted. I think this case is dangerous from the security point of view. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1329737/+subscriptions From thierry.carrez+lp at gmail.com Mon Jun 16 14:12:32 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 16 Jun 2014 14:12:32 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140616141234.412.63154.launchpad@gac.canonical.com> ** Changed in: oslo/icehouse Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: New Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: New Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From thierry.carrez+lp at gmail.com Mon Jun 16 14:19:37 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 16 Jun 2014 14:19:37 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140616141941.22922.26954.launchpad@wampee.canonical.com> ** Changed in: ceilometer/havana Assignee: (unassigned) => Grant Murphy (gmurphy) ** Changed in: neutron/icehouse Assignee: (unassigned) => Grant Murphy (gmurphy) ** Changed in: oslo/havana Assignee: (unassigned) => Grant Murphy (gmurphy) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: New Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: New Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From thierry.carrez+lp at gmail.com Mon Jun 16 14:44:23 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 16 Jun 2014 14:44:23 -0000 Subject: [Openstack-security] [Bug 1329737] Re: Valid tokens remain after token's user was deleted References: <20140613111922.26567.45578.malonedeb@chaenomeles.canonical.com> Message-ID: <20140616144424.1069.48788.malone@gac.canonical.com> Agreed this corner case needs to be better handled in future versions of keystone. ** Changed in: ossa Status: New => Won't Fix ** Information type changed from Public Security to Public ** Summary changed: - Valid tokens remain after token's user was deleted + Valid tokens may remain after token's user was deleted -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329737 Title: Valid tokens may remain after token's user was deleted Status in OpenStack Identity (Keystone): Triaged Status in OpenStack Security Advisories: Won't Fix Bug description: When user is deleted, deleted user's tokens are expired after committing transaction for deleting user. If database dies while tokens are being expired, remaining tokens will lose the chance to expire until 24 hours later. (Because user is already deleted.) In this case, remaining tokens are able to used to authenticate despite the fact that token's user was deleted. I think this case is dangerous from the security point of view. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1329737/+subscriptions From 1329737 at bugs.launchpad.net Fri Jun 13 16:18:49 2014 From: 1329737 at bugs.launchpad.net (Dolph Mathews) Date: Fri, 13 Jun 2014 16:18:49 -0000 Subject: [Openstack-security] [Bug 1329737] Re: Valid tokens remain after token's user was deleted References: <20140613111922.26567.45578.malonedeb@chaenomeles.canonical.com> Message-ID: <20140613161849.4370.53803.malone@wampee.canonical.com> We'll be utilizing https://blueprints.launchpad.net/keystone/+spec /revocation-events in Juno, which will better address this. ** Tags added: security ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => Medium ** Changed in: keystone Milestone: None => juno-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329737 Title: Valid tokens remain after token's user was deleted Status in OpenStack Identity (Keystone): Triaged Bug description: When user is deleted, deleted user's tokens are expired after committing transaction for deleting user. If database dies while tokens are being expired, remaining tokens will lose the chance to expire until 24 hours later. (Because user is already deleted.) In this case, remaining tokens are able to used to authenticate despite the fact that token's user was deleted. I think this case is dangerous from the security point of view. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1329737/+subscriptions From enikanorov at mirantis.com Mon Jun 16 11:40:31 2014 From: enikanorov at mirantis.com (Eugene Nikanorov) Date: Mon, 16 Jun 2014 11:40:31 -0000 Subject: [Openstack-security] [Bug 1278843] Re: Neutron doesn't report using a stale CA certificate References: <20140211121101.2015.95668.malonedeb@chaenomeles.canonical.com> Message-ID: <20140616114033.763.44344.launchpad@gac.canonical.com> ** Changed in: neutron Importance: Undecided => High ** Changed in: neutron Status: New => Confirmed ** Tags removed: instance neutron ** Tags added: icehouse-backport-potential security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1278843 Title: Neutron doesn't report using a stale CA certificate Status in OpenStack Neutron (virtual network service): Confirmed Bug description: It seems that when the CA certificate cashed locally by Neutron in /var/lib/neutron/keystone-signing/ is stale (does not match the current CA cert used by keystone), it is not possible to start a new instance. This is understandable. However, the stacktrace error you get while trying to start as instance in such a situation is a hugely misleading: "ERROR: Error: unsupported operand type(s) for +: 'NoneType' and 'str'" It's rather tricky to debug the issue. To reproduce just redo the pki-setup for keystone on a deployed and otherwise healthy openstack cluster. This will create a new CA cert for keystone, however neutron-server will be completely oblivious to this fact and will still insist on using it's local copy of the cacert. I'm running Havana on rhel6.4 ---------- /var/log/nova/compute.log on the compute node when trying to start a vm OpenStack (nova:4668) ERROR: Instance failed network setup after 1 attempt(s) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager Traceback (most recent call last): 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1238, in _allocate_network_async 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager dhcp_options=dhcp_options) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/api.py", line 49, in wrapper 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager res = f(self, context, *args, **kwargs) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 358, in allocate_for_instance 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager LOG.exception(msg, port_id) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 323, in allocate_for_instance 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager port_req_body) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 392, in _populate_neutron_extension_values 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager self._refresh_neutron_extensions_cache() 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 376, in _refresh_neutron_extensions_cache 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager extensions_list = neutron.list_extensions()['extensions'] 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 108, in with_params 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager ret = self.function(instance, *args, **kwargs) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 286, in list_extensions 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager return self.get(self.extensions_path, params=_params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1183, in get 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager headers=headers, params=params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1168, in retry_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager headers=headers, params=params) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1103, in do_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager resp, replybody = self.httpclient.do_request(action, method, body=body) 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 188, in do_request 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager self.authenticate() 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 224, in authenticate 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager token_url = self.auth_url + "/tokens" 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' 2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager ---------------- /var/log/neutron/server.log on the controller when trying to start a vm OpenStack (neutron:29274) DEBUG: Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User- Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role OpenStack (neutron:29274) INFO: Starting new HTTP connection (1): openstack OpenStack (neutron:29274) DEBUG: received {u'_context_roles': [u'admin'], u'_context_read_deleted': u'no', u'_context_tenant_id': None, u'args': {u'agent_state': {u'agent_state': {u'topic': u'N/A', u'binary' : u'neutron-openvswitch-agent', u'host': u'node001', u'agent_type': u'Open vSwitch agent', u'configurations': {u'tunnel_types': [], u'tunneling_ip': u'', u'bridge_mappings': {u'ph-eth0': u'br0'}, u'l2_popula tion': False, u'devices': 0}}}, u'time': u'2014-02-11T12:06:32.434133'}, u'namespace': None, u'_unique_id': u'ae5c6b608f6547f7b630dace2c5411bd', u'_context_is_admin': True, u'version': u'1.0', u'_context_pro ject_id': None, u'_context_timestamp': u'2014-02-11 12:00:14.386557', u'_context_user_id': None, u'method': u'report_state'} OpenStack (neutron:29274) DEBUG: unpacked context: {'user_id': None, 'roles': [u'admin'], 'tenant_id': None, 'is_admin': True, 'timestamp': u'2014-02-11 12:00:14.386557', 'project_id': None, 'read_deleted': u'no'} OpenStack (neutron:29274) DEBUG: "GET /v2.0/tokens/revoked HTTP/1.1" 200 1234 OpenStack (neutron:29274) WARNING: Verify error: Command 'openssl' returned non-zero exit status 4 OpenStack (neutron:29274) DEBUG: Token validation failure. Traceback (most recent call last):   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 808, in _validate_user_token     verified = self.verify_signed_token(user_token)   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1165, in verify_signed_token     if self.is_signed_token_revoked(signed_text):   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1127, in is_signed_token_revoked     revocation_list = self.token_revocation_list   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1217, in token_revocation_list     self.token_revocation_list = self.fetch_revocation_list()   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1247, in fetch_revocation_list     return self.cms_verify(data['signed'])   File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1160, in cms_verify     raise err CalledProcessError: Command 'openssl' returned non-zero exit status 4 OpenStack (neutron:29274) DEBUG: Marking token c5e1c4ed4d0ab0db8bbaffbb33e139ba as unauthorized in memcache OpenStack (neutron:29274) WARNING: Authorization failed for token c5e1c4ed4d0ab0db8bbaffbb33e139ba OpenStack (neutron:29274) INFO: Invalid user token - rejecting request To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1278843/+subscriptions From 1316271 at bugs.launchpad.net Mon Jun 16 16:08:59 2014 From: 1316271 at bugs.launchpad.net (Robert Clark) Date: Mon, 16 Jun 2014 16:08:59 -0000 Subject: [Openstack-security] [Bug 1316271] Re: Network Security: VM hosts can SSH to compute node References: <20140505190222.27207.36590.malonedeb@gac.canonical.com> Message-ID: <20140616160902.31445.25606.launchpad@soybean.canonical.com> ** Changed in: ossn Importance: Undecided => High ** Changed in: ossn Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1316271 Title: Network Security: VM hosts can SSH to compute node Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: Hi guys, We're still using nova-network and we'll be using it for a while and we noticed that the VM guests can contact the compute nodes on all ports ... The one we're the most preoccupied with is SSH. We've written the following patch in order to isolate the VM guests from the VM hosts. --- linux_net.py.orig 2014-05-05 17:25:10.171746968 +0000 +++ linux_net.py 2014-05-05 18:42:54.569209220 +0000 @@ -805,6 +805,24 @@ @utils.synchronized('lock_gateway', external=True) +def isolate_compute_from_guest(network_ref): + if not network_ref: + return + + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-p tcp -d %s --dport 8775 ' + '-j ACCEPT' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('INPUT', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.ipv4['filter'].add_rule('FORWARD', + '-d %s ' + '-j DROP' % network_ref['dhcp_server']) + iptables_manager.apply() + def initialize_gateway_device(dev, network_ref): if not network_ref: return @@ -1046,6 +1064,7 @@ try: _execute('kill', '-HUP', pid, run_as_root=True) _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) return except Exception as exc: # pylint: disable=W0703 LOG.error(_('Hupping dnsmasq threw %s'), exc) @@ -1098,6 +1117,7 @@ _add_dnsmasq_accept_rules(dev) + isolate_compute_from_guest(network_ref) @utils.synchronized('radvd_start') def update_ra(context, dev, network_ref): To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1316271/+subscriptions From 1320056 at bugs.launchpad.net Mon Jun 16 16:12:04 2014 From: 1320056 at bugs.launchpad.net (Robert Clark) Date: Mon, 16 Jun 2014 16:12:04 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140616161206.337.70421.launchpad@gac.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Tim Kelsey (tim-kelsey) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From jsbryant at us.ibm.com Mon Jun 16 17:33:43 2014 From: jsbryant at us.ibm.com (Jay Bryant) Date: Mon, 16 Jun 2014 17:33:43 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140616173345.28939.79147.launchpad@soybean.canonical.com> ** Changed in: cinder Milestone: juno-1 => juno-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From 1175904 at bugs.launchpad.net Mon Jun 16 18:38:59 2014 From: 1175904 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 Jun 2014 18:38:59 -0000 Subject: [Openstack-security] [Bug 1175904] Re: passlib trunc_password MAX_PASSWORD_LENGTH password truncation References: <20130503065124.14566.73303.malonedeb@gac.canonical.com> Message-ID: <20140616183859.24259.47917.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/77325 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=94a2053cd05cabee2e4233ef33e1f116201d9368 Submitter: Jenkins Branch: master commit 94a2053cd05cabee2e4233ef33e1f116201d9368 Author: Li Ma Date: Fri Feb 28 18:54:35 2014 -0800 Password trunction makes password insecure The trunc_password function attempts to correct and truncate password. It is not recommended to 'fix' invalid input and continue on processing and logging it. Instead, strict check is introduced to validate password. If a password exceeds the maximum length, an HTTP 403 Forbidden error is thrown. In order to keep compatibility, an option 'strict_password_check' is also introduced to let operator decide which method to use. DocImpact Change-Id: I560daa843b94a05412af59a059de5a98bad2925e Closes-Bug: #1175904 ** Changed in: keystone 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/1175904 Title: passlib trunc_password MAX_PASSWORD_LENGTH password truncation Status in OpenStack Identity (Keystone): Fix Committed Bug description: Grant Murphy originally reported: * Insecure / bad practice The trunc_password function attempts to correct and truncate passwords that are over the MAX_PASSWORD_LENGTH value (default 4096). As the MAX_PASSWORD_LENGTH field is globally mutable it could be modified to restrict all passwords to length = 1. This scenario might be unlikely but generally speaking we should not try to 'fix' invalid input and continue on processing as if nothing happened. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175904/+subscriptions From gerrit2 at review.openstack.org Mon Jun 16 19:23:27 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Jun 2014 19:23:27 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/99432 Log: commit 6e1ae752de4984246466e47aa72c2b4471aa30f9 Author: Morgan Fainberg Date: Wed Jun 11 10:13:32 2014 -0700 Do not expose Token IDs in debug output It is only very slightly less of a security issue to expose Token IDs in the logs than it is to expose password details. This change obscures the Token ID in the debug output in all cases to ensure that the ID is not presented in any of the logs that could be read by a unprivileged source (e.g. lower priv log watchers, centralized logging, etc). The main use case is to ensure that it is possible to correlate a token to the various requests made. In some cases this has shown where a token has expired (tokens weren't properly refreshed). This use case for debugging eliminates simple redaction of the token id from the logs. SHA1 is no longer allowed as a hashing mode for CMS token hashing. This is because SHA1 is being used to obscure tokens in the session object debug. This is done to prevent the debug output from being potentially exposing a valid token (PKI->sha1-short-id) in some configurations of Keystone / auth_token middleware. The raw data elements from the token (e.g. user, roles, expiration etc) could be added into debug/trace level logging at a future time. SecurityImpact Change-Id: If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 From gerrit2 at review.openstack.org Mon Jun 16 19:41:56 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Jun 2014 19:41:56 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change If698fc1d0751cded556825b081539da4dd51275e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/95989 Log: commit 705302663dacc423f5ede440d474356fa5c4cf56 Author: Adam Young Date: Tue May 27 21:51:12 2014 -0400 Kerberos as method name To date kerberos has been supported by the "external" method name. However, the Client plugin architecture needs to refer to the method name , and we do not want to expose to the client the difference between kerberos as performed by an external module or an eventual kerberos-in-eventlet style implementation. If the "external" plugin is missing, the old code would throw an exception attempting to process "REMOTE_USER" behavior. If only 'Kerberos" is specified, this is checked and skipped. Blueprint: kerberos-authentication SecurityImpact: Minimal, as Kerberos is already used via external, this just changes the main way it is named. Change-Id: If698fc1d0751cded556825b081539da4dd51275e From 1321080 at bugs.launchpad.net Tue Jun 17 04:29:22 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 17 Jun 2014 04:29:22 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140617042922.29784.69403.malone@soybean.canonical.com> Fix proposed to branch: stable/havana Review: https://review.openstack.org/100414 ** Changed in: ceilometer/havana Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: In Progress Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: New Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: New Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From robert.clark at hp.com Tue Jun 17 17:30:49 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 17 Jun 2014 17:30:49 +0000 Subject: [Openstack-security] OSSN-0018 Review Request Message-ID: Hi Guys, Can you review this OSSN please? https://review.openstack.org/#/c/100008 -Rob Robert Clark Security Architect HP Cloud Services -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From gerrit2 at review.openstack.org Tue Jun 17 21:25:43 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Jun 2014 21:25:43 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 8ceea2bebcbe3106de4d6b19b6cbe7be7e6a066b Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Tue Jun 17 21:42:49 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Jun 2014 21:42:49 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit f886cedcfdc4b1e08db6db259de97b4a830be655 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Tue Jun 17 21:43:38 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Jun 2014 21:43:38 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit a3cb72314b8e9a467018d15a3be8f287d2aa3317 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From gerrit2 at review.openstack.org Wed Jun 18 01:05:04 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 18 Jun 2014 01:05:04 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit fd55ab132d1910699180aea1c9e521c68aff2c9f Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From peter.kardosd at gmail.com Wed Jun 18 07:43:48 2014 From: peter.kardosd at gmail.com (=?UTF-8?Q?Peter_Kardo=C5=A1?=) Date: Wed, 18 Jun 2014 09:43:48 +0200 Subject: [Openstack-security] How to disable spoofing filter? Message-ID: To whom it may concern, we use OpenStack IceHouse and I want to ask if is possible for some network ports turn off spoofing filter. We need this scenario: one or two VM need behave as router and interconnecting more networks (not with NAT but with routing), but spoofing filter don’t allow this feature. I can modify it direct by iptables but every time I change security group settings in iptables is refreshed again spoofing filter for the following networks port. I can't find any information about this problem on internet or in your manual. Thank you Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Wed Jun 18 13:28:53 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 18 Jun 2014 13:28:53 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 0f646dadb548d8bf703984a6aef7fb241fecec38 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e (cherry picked from commit fd55ab132d1910699180aea1c9e521c68aff2c9f) From gerrit2 at review.openstack.org Wed Jun 18 17:12:54 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 18 Jun 2014 17:12:54 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/99432 Log: commit a4bc0127f553f801d97832d437d3c1464ed8bab5 Author: Morgan Fainberg Date: Wed Jun 18 10:05:58 2014 -0700 Do not expose Token IDs in debug output Exposing the raw Token ID in the debug log is almost as bad as exposing the username/password as a valid token conveys authorization as long as the token is valid. This change obscures the token from the debug logging and if the token contains a unique tracking id in the token_data, it will add that into the log-line. The unique token tracking id will allow for correlating a specific token to any and all requests made with that token. SecurityImpact Change-Id: If5b196a734e7a0f0b3fa892d5c0436812a5bbd85 From thomas at goirand.fr Wed Jun 18 17:11:46 2014 From: thomas at goirand.fr (Thomas Goirand) Date: Wed, 18 Jun 2014 17:11:46 -0000 Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should not be world-readable References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com> Message-ID: <20140618171146.1487.69587.malone@wampee.canonical.com> IMHO 2 things should be fixed here: - the /var/lib/nova/instances/_base containing folder should *not* have the world bit x, because otherwise anyone with a login on the system can list files in the folder. - the images in the folder shouldn't be world readable. A patch to fix this issue should address both. Both are of IMO low importance security issues. Low importance because there's a very narrow use case for using a computer for both multi-user system accounts and running a nova compute load. Though narrow, having OpenStack used instead of something like Virtualbox is still a possibility we shouldn't discard, so it shall be fixed ASAP. As explained on IRC, yes, distributions could potentially address the issue for the folder's rights. Though it's IMO preferable to not off- load this kind of things to downstream. Distributions typically would only create /var/lib/nova, and nothing else. Also, in Neutron, I've set the rights for /var/lib/neutron to: drwxr-x--- Is it the view of the project that I should do the same for Nova and everything else? It is my understanding that by doing so, a lot of things would break. Already, in Neutron, this breaks dnsmasq unless dhcp.py is patched to add --user=neutron (which I think is preferable than leaving the folder as world readable). Thoughts welcome. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (Nova): New Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions From 1129748 at bugs.launchpad.net Wed Jun 18 17:35:24 2014 From: 1129748 at bugs.launchpad.net (Matt Joyce) Date: Wed, 18 Jun 2014 17:35:24 -0000 Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should not be world-readable References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com> Message-ID: <20140618173524.11153.15652.malone@soybean.canonical.com> I guess the question then is, is OpenStack requiring specific users and groups to exist on the OS to ensure that this works? We'll need to know the name of the qemu user and the openstack user ( defined in conf is fine ), but we'll also need to avoid conflicting existing users that could lead to hazards. We'll also need a shared group for folks accessing this directory path. What should that group be called? Again this falls into does this become a requirement of running openstack? Might be a question relevant to defcore... but either way, while I agree it would be VERY nice to have this handled in openstack, I fear the potential for conflicting existing distribution decisions in name space. Compromise Approach: We allow for conf based definitions of qemu user, openstack user, and new _base access group. But we verify what we can to ensure we don't conflict existing groups and users. ( this may be difficul in the case of the qemu user ). Thoughts? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (Nova): New Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions From gerrit2 at review.openstack.org Wed Jun 18 20:50:47 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 18 Jun 2014 20:50:47 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change If698fc1d0751cded556825b081539da4dd51275e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/95989 Log: commit 66108d55c8d8cda9d5e7710e6d3c1bbab064dae2 Author: Adam Young Date: Tue May 27 21:51:12 2014 -0400 Kerberos as method name To date kerberos has been supported by the "external" method name. However, the Client plugin architecture needs to refer to the method name, and we do not want to expose to the client the difference between kerberos as performed by an external module or an eventual kerberos-in-eventlet style implementation. If the "external" plugin is missing, the old code would throw an exception attempting to process "REMOTE_USER" behavior. Now, if only 'kerberos' is specified, this is checked and skipped. Blueprint: kerberos-authentication SecurityImpact: Minimal, as Kerberos is already used via external, this just changes the main way it is named. Change-Id: If698fc1d0751cded556825b081539da4dd51275e From gerrit2 at review.openstack.org Wed Jun 18 21:04:16 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 18 Jun 2014 21:04:16 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit f2f7eba2d00801bf61e11c277e54f5c160c2da59 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1175904 at bugs.launchpad.net Thu Jun 19 05:06:17 2014 From: 1175904 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 19 Jun 2014 05:06:17 -0000 Subject: [Openstack-security] [Bug 1175904] Related fix merged to keystone (master) References: <20130503065124.14566.73303.malonedeb@gac.canonical.com> Message-ID: <20140619050617.25899.44963.malone@gac.canonical.com> Reviewed: https://review.openstack.org/98942 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=b3f4e299e8c47ede4e39744fa8c46f66fb1f4173 Submitter: Jenkins Branch: master commit b3f4e299e8c47ede4e39744fa8c46f66fb1f4173 Author: Li Ma Date: Wed Jun 18 19:16:52 2014 -0700 Fix the typo and reformat the comments for the added option Change-Id: I01c471976f2c6d80bfe629b61ab75b81d6cabb1a Related-Bug: #1175904 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175904 Title: passlib trunc_password MAX_PASSWORD_LENGTH password truncation Status in OpenStack Identity (Keystone): Fix Committed Bug description: Grant Murphy originally reported: * Insecure / bad practice The trunc_password function attempts to correct and truncate passwords that are over the MAX_PASSWORD_LENGTH value (default 4096). As the MAX_PASSWORD_LENGTH field is globally mutable it could be modified to restrict all passwords to length = 1. This scenario might be unlikely but generally speaking we should not try to 'fix' invalid input and continue on processing as if nothing happened. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175904/+subscriptions From 1321080 at bugs.launchpad.net Thu Jun 19 05:41:17 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 19 Jun 2014 05:41:17 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140619054117.25602.93484.malone@gac.canonical.com> Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/101097 ** Changed in: neutron/icehouse Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: In Progress Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: New Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From rpodolyaka at mirantis.com Thu Jun 19 09:48:14 2014 From: rpodolyaka at mirantis.com (Roman Podoliaka) Date: Thu, 19 Jun 2014 09:48:14 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140619094814.11019.50851.malone@soybean.canonical.com> Sorry for a long reply, wasn't subscribed for the notifications and missed you comments :( So I've double-checked I'm running the neutron master. This doesn't seem to be an L3-agent issue. I'm running Neutron master as of commit 24718e6f1764e95f0c393ba042546e3584981b31 (Ubuntu 14.04, 3.13.0-29-generic, OVS 2.0.1+git20140120-0ubuntu2). Steps to reproduce: 1. Run tripleo devtest story. This will give you a 3 node cluster - 1 controller node + 2 compute nodes. Neutron ML2 plugin is used, OVS agents are run on each node. 2. SSH to a controller node. 3. Start pinging the VM using its private IP address from a DHCP agent namespace. 4. SSH to a compute node running the VM. 5. Restart the OVS. 6. The ping stops working until neutron-openvswitch-agent is restarted on the compute node. Right after OVS restart I see this in neutron-openvswitch-agent log: http://paste.openstack.org/show/84472/ The complete log is here http://paste.openstack.org/show/84473/ (there are some errors, but I'm not sure they are related to this problem, 'WAS HERE' is a string I log to ensure the code of your fix is executed) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From enikanorov at mirantis.com Thu Jun 19 10:08:40 2014 From: enikanorov at mirantis.com (Eugene Nikanorov) Date: Thu, 19 Jun 2014 10:08:40 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140619100843.7636.9762.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Assignee: Kyle Mestery (mestery) => Eugene Nikanorov (enikanorov) ** Changed in: neutron Status: Fix Released => New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): New Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Triaged Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From gerrit2 at review.openstack.org Thu Jun 19 18:52:19 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Jun 2014 18:52:19 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change If698fc1d0751cded556825b081539da4dd51275e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/95989 Log: commit 346f456c5b104a64eb6f6ce4fcdf81024be2f15a Author: Adam Young Date: Tue May 27 21:51:12 2014 -0400 Kerberos as method name To date kerberos has been supported by the "external" method name. However, the Client plugin architecture needs to refer to the method name, and we do not want to expose to the client the difference between kerberos as performed by an external module or an eventual kerberos-in-eventlet style implementation. If the "external" plugin is missing, the old code would throw an exception attempting to process "REMOTE_USER" behavior. Now, if only 'kerberos' is specified, this is checked and skipped. Blueprint: kerberos-authentication SecurityImpact: Minimal, as Kerberos is already used via external, this just changes the main way it is named. Change-Id: If698fc1d0751cded556825b081539da4dd51275e From gerrit2 at review.openstack.org Thu Jun 19 19:52:18 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Jun 2014 19:52:18 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change If698fc1d0751cded556825b081539da4dd51275e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/95989 Log: commit 52cd113433e73f018064455cf4b3e89d31a89b95 Author: Adam Young Date: Tue May 27 21:51:12 2014 -0400 Kerberos as method name To date kerberos has been supported by the "external" method name. However, the Client plugin architecture needs to refer to the method name, and we do not want to expose to the client the difference between kerberos as performed by an external module or an eventual kerberos-in-eventlet style implementation. If the "external" plugin is missing, the old code would throw an exception attempting to process "REMOTE_USER" behavior. Now, if only 'kerberos' is specified, this is checked and skipped. Blueprint: kerberos-authentication SecurityImpact: Minimal, as Kerberos is already used via external, this just changes the main way it is named. Change-Id: If698fc1d0751cded556825b081539da4dd51275e From gerrit2 at review.openstack.org Thu Jun 19 20:59:27 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 19 Jun 2014 20:59:27 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change If698fc1d0751cded556825b081539da4dd51275e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/95989 Log: commit 37d133aa2ee455caec80bdadbd102b0568f0c00f Author: Adam Young Date: Tue May 27 21:51:12 2014 -0400 Kerberos as method name To date kerberos has been supported by the "external" method name. However, the Client plugin architecture needs to refer to the method name, and we do not want to expose to the client the difference between kerberos as performed by an external module or an eventual kerberos-in-eventlet style implementation. If the "external" plugin is missing, the old code would throw an exception attempting to process "REMOTE_USER" behavior. Now, if only 'kerberos' is specified, this is checked and skipped. Blueprint: kerberos-authentication SecurityImpact: Minimal, as Kerberos is already used via external, this just changes the main way it is named. Change-Id: If698fc1d0751cded556825b081539da4dd51275e From 1290486 at bugs.launchpad.net Fri Jun 20 02:26:31 2014 From: 1290486 at bugs.launchpad.net (James Polley) Date: Fri, 20 Jun 2014 02:26:31 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140620022635.32411.91046.launchpad@chaenomeles.canonical.com> ** Changed in: tripleo Status: Triaged => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): New Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Fix Released Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From 1321080 at bugs.launchpad.net Fri Jun 20 03:31:28 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 Jun 2014 03:31:28 -0000 Subject: [Openstack-security] [Bug 1321080] Fix merged to neutron (stable/icehouse) References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140620033129.29146.81831.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/101097 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=0324965a0c2987e5cad6276f011682dec184205f Submitter: Jenkins Branch: stable/icehouse commit 0324965a0c2987e5cad6276f011682dec184205f Author: Grant Murphy Date: Thu Jun 19 02:30:13 2014 +0000 remove token from notifier middleware oslo-incubator sync to address the security bug in middleware (as below). notifier middleware is capturing token and sending it to MQ. this is not advisable so we should filter it out. Change-Id: Ia1bfa1bd24989681db1d2f385defc12e69a01f8d Closes-Bug: #1321080 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: In Progress Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: New Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From markmc at redhat.com Fri Jun 20 12:28:30 2014 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 20 Jun 2014 12:28:30 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140620122834.10992.45394.launchpad@gac.canonical.com> ** Changed in: oslo/havana Status: New => In Progress ** Changed in: oslo/havana Importance: Undecided => Critical -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: In Progress Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: In Progress Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1321080 at bugs.launchpad.net Fri Jun 20 12:36:10 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 20 Jun 2014 12:36:10 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140620123610.10947.72200.malone@gac.canonical.com> Reviewed: https://review.openstack.org/100414 Committed: https://git.openstack.org/cgit/openstack/oslo-incubator/commit/?id=d97bd2a564cb06c613678407fd074985be73f4d5 Submitter: Jenkins Branch: stable/havana commit d97bd2a564cb06c613678407fd074985be73f4d5 Author: Gordon Chung Date: Tue May 20 12:30:41 2014 -0400 remove token from notifier middleware notifier middleware is capturing token and sending it to MQ. this is not advisable so we should filter it out. Change-Id: Ia1bfa1bd24989681db1d2f385defc12e69a01f8d Closes-Bug: #1321080 (cherry picked from commit 09281ccf7837b70962ad2dfbaa1e84722ad987e8) ** Changed in: ceilometer/havana Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Committed Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: In Progress Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From gmurphy at redhat.com Sat Jun 21 07:33:29 2014 From: gmurphy at redhat.com (Grant Murphy) Date: Sat, 21 Jun 2014 07:33:29 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140621073333.6608.11676.launchpad@soybean.canonical.com> ** Changed in: oslo/havana Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Committed Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: Fix Committed Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From thang.g.pham at gmail.com Sat Jun 21 16:53:53 2014 From: thang.g.pham at gmail.com (Thang Pham) Date: Sat, 21 Jun 2014 16:53:53 -0000 Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone References: <20130207064604.19234.83660.malonedeb@gac.canonical.com> Message-ID: <20140621165353.28754.7179.malone@wampee.canonical.com> There is a blueprint to validate tenant and user IDs that is pending: https://blueprints.launchpad.net/nova/+spec/validate-tenant-user-with- keystone. It should resolve this bug and well as many other identical bugs. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1118066 Title: Nova should confirm quota requests against Keystone Status in OpenStack Compute (Nova): Confirmed Bug description: os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/ against Keystone to ensure that :tenant does exist. POST requests to a non-existant tenant should fail with a 400 error code. GET requests to a non-existant tenant may fail with a 400 error code. Current behavior is to return 200 with the default quotas. A slightly incompatible change would be to return a 302 redirect to /v2/:tenant /os-quota-sets/defaults in this case. Edit (2014-01-22) Original Description -------------------- GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist returns 200 with the default quotas. Moreover POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist with updated quotas succeeds and that metadata is saved! I'm not sure if this is a bug or not. I cannot find any documentation on this interface. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions From gmurphy at redhat.com Sun Jun 22 23:49:22 2014 From: gmurphy at redhat.com (Grant Murphy) Date: Sun, 22 Jun 2014 19:49:22 -0400 (EDT) Subject: [Openstack-security] [openstack-dev] Periodic Security Checks In-Reply-To: References: Message-ID: <2037577167.1890432.1403480962080.JavaMail.zimbra@redhat.com> Adding openstack-security to the thread. In case folks on OSSG don't monitor this list. ----- Original Message ----- > From: "Alexandr Naumchev" > To: openstack-dev at lists.openstack.org > Cc: "Amey Ghadigaonkar" , "Vasiliy Artemev" , "David Yuan" > > Sent: Sunday, June 22, 2014 4:33:35 AM > Subject: [openstack-dev] Periodic Security Checks > > Hello! > We have blueprints here: > > https://blueprints.launchpad.net/horizon/+spec/periodic-security-checks > > and here: > > https://blueprints.launchpad.net/nova/+spec/periodic-security-checks/ > > And we already have some code. Is it necessary to approve the blueprint > before contributing the code? In any case, could someone review the > aforementioned blueprints? > Thanks! > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > From 1321080 at bugs.launchpad.net Mon Jun 23 05:21:42 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 23 Jun 2014 05:21:42 -0000 Subject: [Openstack-security] [Bug 1321080] Fix proposed to ceilometer (stable/havana) References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140623052142.6863.98089.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/havana Review: https://review.openstack.org/101799 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Committed Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: Fix Committed Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From gmurphy at redhat.com Mon Jun 23 06:29:25 2014 From: gmurphy at redhat.com (Grant Murphy) Date: Mon, 23 Jun 2014 06:29:25 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140623062929.16614.90179.launchpad@wampee.canonical.com> ** Changed in: neutron/icehouse Status: In Progress => Fix Committed ** Changed in: ceilometer/havana Status: Fix Committed => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: In Progress Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: Fix Committed Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From 1320056 at bugs.launchpad.net Mon Jun 23 13:29:18 2014 From: 1320056 at bugs.launchpad.net (Doug Chivers) Date: Mon, 23 Jun 2014 13:29:18 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140623132920.13892.62656.launchpad@gac.canonical.com> ** Changed in: ossn Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From 1321080 at bugs.launchpad.net Mon Jun 23 14:57:13 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 23 Jun 2014 14:57:13 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140623145713.29278.72549.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/101799 Committed: https://git.openstack.org/cgit/openstack/ceilometer/commit/?id=264f3b0d9640edeac743f339786e0a3b22c0f6c2 Submitter: Jenkins Branch: stable/havana commit 264f3b0d9640edeac743f339786e0a3b22c0f6c2 Author: Grant Murphy Date: Mon Jun 23 05:07:54 2014 +0000 remove token from notifier middleware oslo-incubator sync to address the security bug in middleware (as below). notifier middleware is capturing token and sending it to MQ. this is not advisable so we should filter it out. Change-Id: Ia1bfa1bd24989681db1d2f385defc12e69a01f8d Closes-Bug: #1321080 ** Changed in: ceilometer/havana Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Committed Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: Fix Committed Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From robert.clark at hp.com Mon Jun 23 17:12:16 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 23 Jun 2014 17:12:16 +0000 Subject: [Openstack-security] Periodic Security Checks In-Reply-To: <2037577167.1890432.1403480962080.JavaMail.zimbra@redhat.com> References: <2037577167.1890432.1403480962080.JavaMail.zimbra@redhat.com> Message-ID: I think this is very interesting and would love to see the code for it. The blueprint mentions performing checks beyond what Open Attestation provides, "add dynamic check to verify memory" - this is probably a stretch goal as process memory verification is extremely complex. I'm not aware of anyone doing it well though I'd love to be corrected on that point. I also wonder how, if working outside of Open Attestation (and I'm assuming outside of TPM) how you will assert that attestations are accurate. I'm sure the intel guys will have a lot to contribute here and I'm excited to see people working to improve Compute security with cool projects such as this one. -Rob > -----Original Message----- > From: Grant Murphy [mailto:gmurphy at redhat.com] > Sent: 23 June 2014 00:49 > To: OpenStack Development Mailing List (not for usage questions); > openstack-security at lists.openstack.org > Cc: Vasiliy Artemev; David Yuan > Subject: Re: [Openstack-security] [openstack-dev] Periodic Security Checks > > Adding openstack-security to the thread. In case folks on OSSG don't > monitor this list. > > ----- Original Message ----- > > From: "Alexandr Naumchev" > > To: openstack-dev at lists.openstack.org > > Cc: "Amey Ghadigaonkar" , "Vasiliy Artemev" > , "David Yuan" > > > > Sent: Sunday, June 22, 2014 4:33:35 AM > > Subject: [openstack-dev] Periodic Security Checks > > > > Hello! > > We have blueprints here: > > > > https://blueprints.launchpad.net/horizon/+spec/periodic-security-check > > s > > > > and here: > > > > https://blueprints.launchpad.net/nova/+spec/periodic-security-checks/ > > > > And we already have some code. Is it necessary to approve the > > blueprint before contributing the code? In any case, could someone > > review the aforementioned blueprints? > > Thanks! > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From gerrit2 at review.openstack.org Mon Jun 23 22:27:04 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 23 Jun 2014 22:27:04 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 54e288494d3712046de52e94a63343bc90aa1237 Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From tristan.cacqueray at enovance.com Tue Jun 24 05:58:52 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Tue, 24 Jun 2014 05:58:52 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request (CVE-2014-4615) References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140624055854.7104.55270.launchpad@chaenomeles.canonical.com> ** Summary changed: - auth token is exposed in meter http.request + auth token is exposed in meter http.request (CVE-2014-4615) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: auth token is exposed in meter http.request (CVE-2014-4615) Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Committed Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: Fix Committed Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Triaged Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From robert.clark at hp.com Tue Jun 24 08:59:10 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 24 Jun 2014 08:59:10 +0000 Subject: [Openstack-security] FW: [openstack-dev] [hacking] community consensus and removing rules In-Reply-To: References: Message-ID: HI Security peeps, I know some of you are looking at how to add something to hacking, this thread has some useful relevant information. -Rob From: Joe Gordon > Reply-To: OpenStack List > Date: Tuesday, 24 June 2014 03:55 To: OpenStack List > Subject: [openstack-dev] [hacking] community consensus and removing rules Hi All, After Friday's thread on removing several hacking rules. H402 and H803 are lines up to removed in the next few days, while Ben has volunteered to work on H305. In addition to helping clarify if we can remove a few specific rules, the thread touched on the bigger issue of how do make sure the rules in hacking reflect the communities lazy consensus of what should be enforced. The hacking repo has consists primarily of two distinct things, HACKING.rst the OpenStack Style Guide that is published at [0], and hacking the tool. Hacking the style guide's goal is as Sean puts it [1]: "OpenStack has a set of style guidelines for clarity. OpenStack is a very large code base (over 1 Million lines of python), spanning dozens of git trees, with over a thousand developers contributing every 12 months. As such common style helps developers understand code in reviews, move between projects smoothly, and overall make the code more maintainable." While hacking the tool is there to move the burden of enforcing the style guide off of human reviewers, as human reviewers are our most constrained resource today. In the past when evaluating if we should add a new rule to hacking the tool, we followed the guidelines in [2]. Where consensus was met if the rule was already in HACKING.rst or there was lazy consensus on this mailing list. In retrospect this was a mistake, as this policy makes the assumption that the folks read HACKING.rst and have done a review to decide if any sections should be changed. For example we have a few unenforced sections that we may not want to keep [3][4]. Going forward I propose: * Any addition or removal of a rule requires a ML thread and/or an oslo-specs blueprint (I am not sure which one makes the most sense here, but I am leaning towards the ML). * Only accept new rules that are already being used as a local rule in at least one repository. * Add a new directory, contrib, for local rules that multiple projects use but are not generally considered acceptable to be enabled by default. This way we can reduce the amount of cut and pasted code (thank you to Ben Nemec for this idea). While turning off rules at the repository level has always been recommended as hacking is a tool to help projects and not a mechanism to dictate style, having rules enabled in hacking does have implications. So we need a mechanism to track which rules folks don't find useful so we can make sure they are not enabled by default (either move them to contrib or remove them entirely). We can track individual repositories hacking ignore lists and periodically reevaluate the rules with the most ignores. This means projects vote on which rules to remove by maintaining there ignore list in tox.ini. I put together a tiny script to do this and here are my findings so far. rule: number of ignores H803: 19 H302: 14 H904: 14 H305: 13 H405: 12 H307: 11 H404: 9 H402: 6 H: 4 H233: 3 H202: 3 H306: 2 H301: 2 H303: 1 H703: 1 H304: 1 H237: 1 H4: 1 H201: 1 H701: 1 H102: 1 H702: 1 Interestingly, of the two rules we just agreed to remove, H402 is not even close to the top of the most skipped list. Of the top 3 most skipped rules * H803: The first line of the commit message must not end with a period and must be followed by a single blank line. * Removing, as previously discussed * H302: Do not import objects, only modules (*) * This has been around for a long time, should we move this to contrib? * H904: Wrap long lines in parentheses and not a backslash for line continuation. * Although this has been in HACKING.rst for a while, the rule was added in hacking 0.9. So its still unclear if this is skipped because folks don't like it or because they haven't gotten around to fixing it up yet. Thoughts? best, Joe Gordon [0] http://docs.openstack.org/developer/hacking/ [1] https://review.openstack.org/#/c/102014/2/HACKING.rst [2] http://docs.openstack.org/developer/hacking/readme.html#adding-additional-checks [3] http://docs.openstack.org/developer/hacking/#dictionaries-lists [4] http://docs.openstack.org/developer/hacking/#calling-methods -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From Darren.Moffat at Oracle.COM Tue Jun 24 10:46:18 2014 From: Darren.Moffat at Oracle.COM (Darren J Moffat) Date: Tue, 24 Jun 2014 11:46:18 +0100 Subject: [Openstack-security] Periodic Security Checks In-Reply-To: References: <2037577167.1890432.1403480962080.JavaMail.zimbra@redhat.com> Message-ID: <53A956FA.80603@Oracle.COM> Is this intended only for checking the OpenStack infrastructure or for checking the hosted guest VMs as well ? Why does the scheduling of the checks even have to be part of OpenStack ? Why can't the operating system that OpenStack is running on provide that ? Any reason this is limited to "security" rather than being a generic mechanism ? Eg one that can stop scheduling to given nodes based on reported hardware faults. -- Darren J Moffat From tim.kelsey at hp.com Tue Jun 24 10:41:41 2014 From: tim.kelsey at hp.com (Tim Kelsey) Date: Tue, 24 Jun 2014 10:41:41 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140624104141.28961.3352.malone@soybean.canonical.com> Hello all, so im working on the OSSN documenting this issue. I would just like to confirm that the plan for Juno is to update the relevant drivers so that by default they don't use the SSHPool auto-accept policy? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From duncan.thomas at gmail.com Tue Jun 24 11:44:48 2014 From: duncan.thomas at gmail.com (Duncan Thomas) Date: Tue, 24 Jun 2014 11:44:48 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140624114448.29442.37370.malone@soybean.canonical.com> @Tim Kelsey: I think the plan is to make the policy configurable, with auto-add (but fail if changed) as the default, which is secure enough for most people but can be bumped up by sufficiently paranoid installed who do the work to collect the keys first. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From matt at mattfischer.com Tue Jun 24 12:04:40 2014 From: matt at mattfischer.com (Matt Fischer) Date: Tue, 24 Jun 2014 12:04:40 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140624120440.7290.70437.malone@chaenomeles.canonical.com> This is still an issue in Icehouse. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From fungi at yuggoth.org Tue Jun 24 12:39:15 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 24 Jun 2014 12:39:15 -0000 Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not work References: <20140612080140.21505.11780.malonedeb@gac.canonical.com> Message-ID: <20140624123915.16514.40768.malone@wampee.canonical.com> Updated to a public bug, no advisory, tagged as possible security hardening feature/improvement. ** Information type changed from Private Security to Public ** Tags added: security ** No longer affects: ossa -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329214 Title: tgtadm iscsi chap does not work Status in Cinder: New Bug description: When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume has record chap user and chap passwd. By testing, I found that tgtadm iscsi chap does not work. Is it a security bug for iscsi_helper tgtadm? My detail test work is as follows. 1. Test details as follows without modify the source code: 1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191) 2) create a vm VM-A and a cinder volume VOLUME-A, attach VOLUME-A to VM-A 3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . iscsiadm -m discovery -t sendtargets -p 10.250.10.190 iscsiadm -m node -T iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login 2. Test details as follows with modify the source code: 1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. type, name, passwd = chap_auth.split() self._execute('tgtadm', '--lld', 'iscsi', '--mode', 'account', '--op', 'new', '--user', name, '--password', passwd) self._execute('tgtadm', '--lld', 'iscsi', '--mode', 'account', '--op', 'bind', '--tid', tid, '--user', name ) 2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows. root at devaio1:/etc/iscsi# iscsiadm -m node -T iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple) iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260]. iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure) iscsiadm: Could not log into all portals To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1329214/+subscriptions From edmondsw at us.ibm.com Tue Jun 24 13:34:45 2014 From: edmondsw at us.ibm.com (Matthew Edmonds) Date: Tue, 24 Jun 2014 13:34:45 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140624133445.6863.77598.malone@chaenomeles.canonical.com> @duncan-thomas: The decision in IRC was that it would be ok to default to a special policy where we auto-add on first connect only and then reject thereafter. But that assumes it's possible to distinguish a first connect, and I'm not sure that's possible. Lacking that, the default needs to be a normal reject policy. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From duncan.thomas at gmail.com Tue Jun 24 14:03:17 2014 From: duncan.thomas at gmail.com (Duncan Thomas) Date: Tue, 24 Jun 2014 14:03:17 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> <20140624133445.6863.77598.malone@chaenomeles.canonical.com> Message-ID: First connect means 'we haven't cached the key yet'.... that's the only sane definition it the ssh world. On 24 June 2014 14:34, Matthew Edmonds wrote: > @duncan-thomas: The decision in IRC was that it would be ok to default > to a special policy where we auto-add on first connect only and then > reject thereafter. But that assumes it's possible to distinguish a first > connect, and I'm not sure that's possible. Lacking that, the default > needs to be a normal reject policy. > > -- > You received this bug notification because you are a member of Cinder > Bug Team, which is subscribed to Cinder. > https://bugs.launchpad.net/bugs/1320056 > > Title: > Cinder utils SSHPool should allow customized ssh host keys and missing > policy > > Status in Cinder: > Fix Released > Status in OpenStack Security Advisories: > Won't Fix > Status in OpenStack Security Notes: > In Progress > > Bug description: > In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as > default. This may lead security issue without being notified. The > utility should allow customized usage when create the pool or session. > Also the host_keys file should be allowed to be customized so that any > driver utilizing the SSHPool should have their customized security > setting or delegate to customer's scenario & configuration to > determine the policy and key files. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions -- Duncan Thomas -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From nkinder at redhat.com Tue Jun 24 18:36:51 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 24 Jun 2014 18:36:51 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140624183651.28832.10579.malone@soybean.canonical.com> There is an outstanding patch to address this for Juno, and I think we should look at proposing it for backport (if it's not intrusive) once it is accepted: https://review.openstack.org/101792 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From jsbryant at us.ibm.com Tue Jun 24 18:47:07 2014 From: jsbryant at us.ibm.com (Jay Bryant) Date: Tue, 24 Jun 2014 18:47:07 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140624184707.6967.41767.malone@chaenomeles.canonical.com> Matt, Duncan and Tim, Here is an excerpt from the spec I wrote for this change: https://review.openstack.org/#/c/100697/1/specs/juno/configurable-ssh- host-key-policy.rst 41 The solution would require two new configuration items as well as 42 a change to the current default behavior. First, there would need 43 to a 'strict_ssh_host_key_policy' configuration option with possible 44 settings of 'false' (default) or 'true'. When this option is set to 45 'false' it will automatically accept the host key on the first connection 46 and then will throw an exception if the host key changes in the future. 47 This is where the default behavior changes from the current functionality. 48 49 In the case that 'strict_ssh_host_key_policy' is set to 'true' then a 50 second option 'ssh_host_keys_file' must be configured. When the strict 51 configuration is used it is assumed that the administrator is going to 52 have pre-configured ssh host keys and any deviation from those expected 53 keys will be handled with an exception. So, that was the plan that John approved though he noted that he is mixed on the default proposal. The agreement in IRC was that we would reject a connection if it changed after the host key was added to known hosts. As far as first connection is concerned, it looks like I get get a list of known keys with get_host_keys . If we don't have the key yet we accept it. If we do have the key we do strict checking on 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/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From 1004114 at bugs.launchpad.net Tue Jun 24 20:08:40 2014 From: 1004114 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 24 Jun 2014 20:08:40 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140624200840.16849.61236.malone@wampee.canonical.com> Nathan: keystoneclient doesn't get named releases like the services do, so there wouldn't be anything to backport. You should be able to run the latest version of keystoneclient (including middleware.auth_token) with any supported service release, however. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From dstanek at dstanek.com Tue Jun 24 20:51:56 2014 From: dstanek at dstanek.com (David Stanek) Date: Tue, 24 Jun 2014 20:51:56 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20140624205156.7179.245.malone@chaenomeles.canonical.com> That patch needs a little work to be approved. I'll upload a new patch to address the outstanding comments unless someone i already working on 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/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From duncan.thomas at gmail.com Tue Jun 24 22:19:35 2014 From: duncan.thomas at gmail.com (Duncan Thomas) Date: Tue, 24 Jun 2014 22:19:35 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> <20140624184707.6967.41767.malone@chaenomeles.canonical.com> Message-ID: @Jay: Works for me -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From 1329214 at bugs.launchpad.net Wed Jun 25 03:26:10 2014 From: 1329214 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 25 Jun 2014 03:26:10 -0000 Subject: [Openstack-security] [Bug 1329214] Re: tgtadm iscsi chap does not work References: <20140612080140.21505.11780.malonedeb@gac.canonical.com> Message-ID: <20140625032610.17147.30777.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/102420 ** Changed in: cinder Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1329214 Title: tgtadm iscsi chap does not work Status in Cinder: In Progress Bug description: When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume has record chap user and chap passwd. By testing, I found that tgtadm iscsi chap does not work. Is it a security bug for iscsi_helper tgtadm? My detail test work is as follows. 1. Test details as follows without modify the source code: 1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191) 2) create a vm VM-A and a cinder volume VOLUME-A, attach VOLUME-A to VM-A 3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . iscsiadm -m discovery -t sendtargets -p 10.250.10.190 iscsiadm -m node -T iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login 2. Test details as follows with modify the source code: 1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. type, name, passwd = chap_auth.split() self._execute('tgtadm', '--lld', 'iscsi', '--mode', 'account', '--op', 'new', '--user', name, '--password', passwd) self._execute('tgtadm', '--lld', 'iscsi', '--mode', 'account', '--op', 'bind', '--tid', tid, '--user', name ) 2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows. root at devaio1:/etc/iscsi# iscsiadm -m node -T iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple) iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260]. iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure) iscsiadm: Could not log into all portals To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1329214/+subscriptions From mriedem at us.ibm.com Wed Jun 25 18:06:20 2014 From: mriedem at us.ibm.com (Matt Riedemann) Date: Wed, 25 Jun 2014 18:06:20 -0000 Subject: [Openstack-security] [Bug 1320028] Re: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com> Message-ID: <20140625180620.14047.54327.malone@gac.canonical.com> partial oslo sync https://review.openstack.org/#/c/102594/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320028 Title: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: If debug logging is enabled, the _run_iscsiadm function in volume.py logs the iscsi node.session.auth.password in plain text. 2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req- d21bb680-feb9-4242-9d18-057af79d26e8 0 3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n', 'node.session.auth.password', '-v', u'password'): stdout= stderr= _run_iscsiadm /usr/lib/python2.7/site- packages/nova/virt/libvirt/volume.py:248 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1320028/+subscriptions From tristan.cacqueray at enovance.com Wed Jun 25 19:08:38 2014 From: tristan.cacqueray at enovance.com (Tristan Cacqueray) Date: Wed, 25 Jun 2014 19:08:38 -0000 Subject: [Openstack-security] [Bug 1321080] Re: auth token is exposed in meter http.request (CVE-2014-4615) References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140625190841.16983.19925.launchpad@wampee.canonical.com> ** Changed in: ossa Status: Triaged => In Progress ** Summary changed: - auth token is exposed in meter http.request (CVE-2014-4615) + [OSSA 2014-021] auth token is exposed in meter http.request (CVE-2014-4615) ** Changed in: ossa Status: In Progress => Fix Committed ** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: [OSSA 2014-021] auth token is exposed in meter http.request (CVE-2014-4615) Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Committed Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: Fix Committed Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Fix Released Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From vasart at gmail.com Wed Jun 25 21:34:34 2014 From: vasart at gmail.com (Vasiliy Artemev) Date: Wed, 25 Jun 2014 17:34:34 -0400 Subject: [Openstack-security] Periodic Security Checks In-Reply-To: <53A956FA.80603@Oracle.COM> References: <2037577167.1890432.1403480962080.JavaMail.zimbra@redhat.com> <53A956FA.80603@Oracle.COM> Message-ID: >> Why does the scheduling of the checks even have to be part of OpenStack? Why can't the operating system that OpenStack is running on provide that? Because "trusted pool" concept is a part of OpenStack, not operating system. Users with sensitive workloads may choose to use the "trusted pool" concept to have more control over where their data is run. Similarly, these security checks are deeply intertwined with OpenStack/Nova functionality. What is the good of having a security check in the operating system level if Nova just blindly runs on any physical machine anyway? >> Any reason this is limited to "security" rather than being a generic mechanism? So, right now you should read "periodic security check" as "periodic update of trusted pool". But that is only for now. The reason this is limited to security is because APL's goal for working with OpenStack is to improve its security. Due to scoping concerns the first version will only target security checks; however, developers are welcome to extend it in the future to include other aspects of computing pools. (Translation: "pull requests accepted") 2014-06-24 6:46 GMT-04:00 Darren J Moffat : > Is this intended only for checking the OpenStack infrastructure or for > checking the hosted guest VMs as well ? > > Why does the scheduling of the checks even have to be part of OpenStack ? > Why can't the operating system that OpenStack is running on provide that ? > > Any reason this is limited to "security" rather than being a generic > mechanism ? Eg one that can stop scheduling to given nodes based on > reported hardware faults. > > -- > Darren J Moffat > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.kelsey at hp.com Thu Jun 26 09:28:40 2014 From: tim.kelsey at hp.com (Tim Kelsey) Date: Thu, 26 Jun 2014 09:28:40 -0000 Subject: [Openstack-security] [Bug 1320056] Re: Cinder utils SSHPool should allow customized ssh host keys and missing policy References: <20140516032022.25328.55432.malonedeb@chaenomeles.canonical.com> Message-ID: <20140626092840.16818.43412.malone@wampee.canonical.com> Thanks for the information all, @Jay: thanks for the detail and additional background as well. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320056 Title: Cinder utils SSHPool should allow customized ssh host keys and missing policy Status in Cinder: Fix Released Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: In Progress Bug description: In cinder/utils.py, SSHPool is using paramiko.AutoAddPolicy() as default. This may lead security issue without being notified. The utility should allow customized usage when create the pool or session. Also the host_keys file should be allowed to be customized so that any driver utilizing the SSHPool should have their customized security setting or delegate to customer's scenario & configuration to determine the policy and key files. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1320056/+subscriptions From 1321080 at bugs.launchpad.net Thu Jun 26 13:00:51 2014 From: 1321080 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 26 Jun 2014 13:00:51 -0000 Subject: [Openstack-security] [Bug 1321080] Fix merged to ceilometer (stable/icehouse) References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140626130052.16514.52491.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/96944 Committed: https://git.openstack.org/cgit/openstack/ceilometer/commit/?id=2b6454f9f4e0585949ab68a91ed405755438d76e Submitter: Jenkins Branch: stable/icehouse commit 2b6454f9f4e0585949ab68a91ed405755438d76e Author: gordon chung Date: Fri May 30 17:11:18 2014 -0400 remove token from notifier middleware notifier middleware is capturing token and sending it to MQ. this is not advisable so we should filter it out. Change-Id: Ia1bfa1bd24989681db1d2f385defc12e69a01f8d Closes-Bug: #1321080 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: [OSSA 2014-021] auth token is exposed in meter http.request (CVE-2014-4615) Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Committed Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: Fix Committed Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Fix Released Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From gerrit2 at review.openstack.org Thu Jun 26 23:53:05 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 26 Jun 2014 23:53:05 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 67a54c7461746f2919aa47f31999b5b601742e0d Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From fungi at yuggoth.org Thu Jun 26 23:49:29 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 26 Jun 2014 23:49:29 -0000 Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token is exposed in meter http.request (CVE-2014-4615) References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com> Message-ID: <20140626234930.17014.54486.launchpad@wampee.canonical.com> ** CVE added: http://www.cve.mitre.org/cgi- bin/cvename.cgi?name=2014-4615 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1321080 Title: [OSSA 2014-021] auth token is exposed in meter http.request (CVE-2014-4615) Status in OpenStack Telemetry (Ceilometer): Invalid Status in Ceilometer havana series: Fix Committed Status in Ceilometer icehouse series: Fix Committed Status in OpenStack Neutron (virtual network service): Fix Released Status in neutron icehouse series: Fix Committed Status in Oslo - a Library of Common OpenStack Code: Fix Released Status in oslo havana series: Fix Committed Status in oslo icehouse series: Fix Committed Status in OpenStack Security Advisories: Fix Released Status in pyCADF: Fix Released Bug description: auth token is exposed in meter http.request # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'User-Agent: python-ceilometerclient' http://0.0.0.0:8777/v2/meters/http.request ----------- snip.. {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0", snip... auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478". But it is exposed in "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478" To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1321080/+subscriptions From fungi at yuggoth.org Fri Jun 27 11:13:43 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 27 Jun 2014 11:13:43 -0000 Subject: [Openstack-security] [Bug 1334938] Re: established floating ip connection won't get disconnected after disassociating floating ip References: <20140627031928.26375.32794.malonedeb@wampee.canonical.com> Message-ID: <20140627111344.19437.39324.launchpad@gac.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334938 Title: established floating ip connection won't get disconnected after disassociating floating ip Status in OpenStack Compute (Nova): New Bug description: Established connections via floating ip won't get disconnected after we disassociating that floating ip. As mentioned in maillist by Vish, we should move clean_conntrack() from migration code to remove_floating_ip. https://github.com/openstack/nova/blob/master/nova/network/floating_ips.py#L575 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334938/+subscriptions From fungi at yuggoth.org Fri Jun 27 11:13:23 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 27 Jun 2014 11:13:23 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140627111324.18849.65484.launchpad@gac.canonical.com> ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): New Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From enikanorov at mirantis.com Fri Jun 27 11:27:07 2014 From: enikanorov at mirantis.com (Eugene Nikanorov) Date: Fri, 27 Jun 2014 11:27:07 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140627112708.314.45714.launchpad@soybean.canonical.com> ** Tags added: l3-ipam-dhcp ** Changed in: neutron Importance: Undecided => High -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): New Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From nkinder at redhat.com Fri Jun 27 13:57:23 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 27 Jun 2014 13:57:23 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140627135723.19371.23411.launchpad@gac.canonical.com> ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): New Status in OpenStack Security Notes: New Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From priti_desai at symantec.com Fri Jun 27 14:09:33 2014 From: priti_desai at symantec.com (Priti Desai) Date: Fri, 27 Jun 2014 14:09:33 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140627140937.348.94402.launchpad@soybean.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Priti Desai (priti-desai) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): New Status in OpenStack Security Notes: New Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions From gerrit2 at review.openstack.org Fri Jun 27 21:16:12 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 27 Jun 2014 21:16:12 +0000 Subject: [Openstack-security] [openstack/ironic] SecurityImpact review request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81391 Log: commit 1d2b6c1fe99d8155a6793f99cbee0d6377c172ed Author: Josh Gachnang Date: Wed Mar 19 16:47:38 2014 -0700 Adding swift temp url support This patch will allow properly configured Glance servers to return a temporary URL for an object hosted on Swift. It will require Glance to use Swift as its backend. A temporary URL will let the agent download an image from Glance without requiring an auth_token, which gives access more than just Glance. The easiest way to use it is to enable direct_url in Glance, but you can set the appropriate config options to avoid needing to enable it. We/I need to add a note in the docs about Swift being a possible dependency for Ironic deploys using IPA, along with how to set the Temp URL key. Swift perfomance concerns will be addressed in this blueprint: https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads SecurityImpact DocImpact Implements: blueprint swift-temp-urls Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e From 1320028 at bugs.launchpad.net Fri Jun 27 21:34:26 2014 From: 1320028 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 27 Jun 2014 21:34:26 -0000 Subject: [Openstack-security] [Bug 1320028] Re: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com> Message-ID: <20140627213426.19036.64342.malone@gac.canonical.com> Reviewed: https://review.openstack.org/97305 Committed: https://git.openstack.org/cgit/openstack/oslo-incubator/commit/?id=5e3d3a544f803c453cb86a7df04becd6a7b1a4c3 Submitter: Jenkins Branch: master commit 5e3d3a544f803c453cb86a7df04becd6a7b1a4c3 Author: Brad Pokorny Date: Mon Jun 2 18:06:37 2014 +0000 Mask passwords included without quotes at the ends of commands The current password masking doesn't scrub passwords from commands in the case where the password doesn't have quotes around it and the password is the last string in the command. This commit updates one of the regular expressions to catch this case. Adds tests to ensure passwords at the ends of commands are properly sanitized. Change-Id: Id57a0cb05cd76ef8c26def738305ade6b085aaa7 Closes-Bug: #1320028 ** Changed in: oslo 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/1320028 Title: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Bug description: If debug logging is enabled, the _run_iscsiadm function in volume.py logs the iscsi node.session.auth.password in plain text. 2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req- d21bb680-feb9-4242-9d18-057af79d26e8 0 3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n', 'node.session.auth.password', '-v', u'password'): stdout= stderr= _run_iscsiadm /usr/lib/python2.7/site- packages/nova/virt/libvirt/volume.py:248 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1320028/+subscriptions From 1320028 at bugs.launchpad.net Fri Jun 27 21:39:25 2014 From: 1320028 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 27 Jun 2014 21:39:25 -0000 Subject: [Openstack-security] [Bug 1320028] Fix merged to nova (master) References: <20140515234022.31230.32833.malonedeb@soybean.canonical.com> Message-ID: <20140627213926.32546.62138.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/102594 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=eb7b63d79d28581a7dd23645488de323b99f8463 Submitter: Jenkins Branch: master commit eb7b63d79d28581a7dd23645488de323b99f8463 Author: Matt Riedemann Date: Wed Jun 25 09:20:25 2014 -0700 Sync log and processutils from oslo This is mainly to pick up two changes in processutils: 85f1784 Move nova.utils.cpu_count() to processutils module cdcc19c Mask passwords that are included in commands Commit cdcc19c touches the log module so when copying processutils over we also copy log, otherwise no other dependencies are copied. Going through the commit history on both and the diff from nova, there are no other commits sync'ed over that require changes to other dependent modules. Commit 85f1784 is targeted so we can remove the redundant code from nova.utils. Changes: processutils ------------ 85f1784 Move nova.utils.cpu_count() to processutils module cdcc19c Mask passwords that are included in commands 8a0f567 Remove str() from LOG.* and exceptions 51778f9 Allow passing environment variables to execute() log --- 109e325 Use oslo.messaging to publish log errors de4adbc pep8: fixed multiple violations eac71f5 Fix common.log.ContextFormatter for Python 3 d78b633 Fixes a simple spelling mistake 621d831 always log a traceback in the sys.excepthook 90ae24b Remove redundant default=None for config options af36c2a Fix logging setup for Python 3.4 cdcc19c Mask passwords that are included in commands Partial-Bug: #1320028 Related-Bug: #1333370 Change-Id: I8d12661782e8ad065b01aa582e42c142cc2f4076 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1320028 Title: libvirt volume.py's _run_iscsiadm function logs iscsi node.session.auth.password if debug Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: Fix Committed Bug description: If debug logging is enabled, the _run_iscsiadm function in volume.py logs the iscsi node.session.auth.password in plain text. 2014-05-13 08:12:21.915 29013 DEBUG nova.virt.libvirt.volume [req- d21bb680-feb9-4242-9d18-057af79d26e8 0 3112d0d7268b458bb5c997c33cd8a8c0] iscsiadm ('--op', 'update', '-n', 'node.session.auth.password', '-v', u'password'): stdout= stderr= _run_iscsiadm /usr/lib/python2.7/site- packages/nova/virt/libvirt/volume.py:248 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1320028/+subscriptions From thierry.carrez+lp at gmail.com Mon Jun 30 14:24:03 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 30 Jun 2014 14:24:03 -0000 Subject: [Openstack-security] [Bug 1328488] Re: oslo apiclient logs sensitive data References: <20140610105701.26336.80011.malonedeb@wampee.canonical.com> Message-ID: <20140630142404.32507.61321.launchpad@soybean.canonical.com> ** Tags added: security ** Information type changed from Public Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1328488 Title: oslo apiclient logs sensitive data Status in Oslo - a Library of Common OpenStack Code: New 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/+bug/1328488/+subscriptions From 1290486 at bugs.launchpad.net Mon Jun 30 19:24:22 2014 From: 1290486 at bugs.launchpad.net (Kyle Mestery) Date: Mon, 30 Jun 2014 19:24:22 -0000 Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com> Message-ID: <20140630192422.26346.35403.malone@wampee.canonical.com> Roman and James, you're both working in TripleO, and yet one of you is saying this bug isn't fixed, and one is saying it is fixed. We need to coordinate on IRC to see what's going on here, as I can no longer reproduce this at all. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1290486 Title: neutron-openvswitch-agent does not recreate flows after ovsdb-server restarts Status in OpenStack Neutron (virtual network service): New Status in neutron icehouse series: Fix Released Status in tripleo - openstack on openstack: Fix Released Bug description: The DHCP requests were not being responded to after they were seen on the undercloud network interface. The neutron services were restarted in an attempt to ensure they had the newest configuration and knew they were supposed to respond to the requests. Rather than using the heat stack create (called in devtest_overcloud.sh) to test, it was simple to use the following to directly boot a baremetal node. nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \ --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \ bm-test1 Whilst the baremetal node was attempting to pxe boot a restart of the neutron services was performed. This allowed the baremetal node to boot. It has been observed that a neutron restart was needed for each subsequent reboot of the baremetal nodes to succeed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1290486/+subscriptions From bdpayne at acm.org Mon Jun 30 20:57:31 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Mon, 30 Jun 2014 13:57:31 -0700 Subject: [Openstack-security] eavesdrop on #openstack-security Message-ID: I've put in a request to starting logging the communication on #openstack-security. The logs will be available at http://eavesdrop.openstack.org/irclogs/. I think that this will be useful since so many of us are working on different sides of the globe. If you have any questions or concerns, please let me know. Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1334938 at bugs.launchpad.net Sat Jun 28 06:26:36 2014 From: 1334938 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 28 Jun 2014 06:26:36 -0000 Subject: [Openstack-security] [Bug 1334938] Re: established floating ip connection won't get disconnected after disassociating floating ip References: <20140627031928.26375.32794.malonedeb@wampee.canonical.com> Message-ID: <20140628062639.348.74537.launchpad@soybean.canonical.com> ** Changed in: nova Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334938 Title: established floating ip connection won't get disconnected after disassociating floating ip Status in OpenStack Compute (Nova): In Progress Bug description: Established connections via floating ip won't get disconnected after we disassociating that floating ip. As mentioned in maillist by Vish, we should move clean_conntrack() from migration code to remove_floating_ip. https://github.com/openstack/nova/blob/master/nova/network/floating_ips.py#L575 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1334938/+subscriptions From 1334926 at bugs.launchpad.net Mon Jun 30 07:15:52 2014 From: 1334926 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 30 Jun 2014 07:15:52 -0000 Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working once connected even after it is disociated References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com> Message-ID: <20140630071552.6901.20079.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/103475 ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1334926 Title: floatingip still working once connected even after it is disociated Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Security Notes: New Bug description: After we create an SSH connection to a VM via its floating ip, even though we have removed the floating ip association, we can still access the VM via that connection. Namely, SSH is not disconnected when the floating ip is not valid To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1334926/+subscriptions