From gerrit2 at review.openstack.org Fri Nov 1 13:52:19 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 01 Nov 2013 13:52:19 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit ffc5029109cde528870ca6a2b6cdae21c2f56978 Author: Dan Genin Date: Fri Oct 25 16:38:19 2013 -0400 Add ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From 1231263 at bugs.launchpad.net Fri Nov 1 17:04:15 2013 From: 1231263 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 01 Nov 2013 17:04:15 -0000 Subject: [Openstack-security] [Bug 1231263] Fix proposed to nova (stable/havana) References: <20130926055439.7490.27811.malonedeb@gac.canonical.com> Message-ID: <20131101170415.12674.88675.malone@chaenomeles.canonical.com> Fix proposed to branch: stable/havana Review: https://review.openstack.org/54954 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1231263 Title: Clear text password has been print in log by some API call Status in OpenStack Compute (Nova): Fix Committed Bug description: In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova. i.e: 2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': , 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103 2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926 This is not secue which the password should be replaced by *** To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1231263/+subscriptions From btang at us.ibm.com Fri Nov 1 18:05:55 2013 From: btang at us.ibm.com (Brent Tang) Date: Fri, 01 Nov 2013 18:05:55 -0000 Subject: [Openstack-security] [Bug 1247217] [NEW] Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Public bug reported: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub- string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). ** Affects: nova Importance: Undecided Status: Confirmed ** Tags: api security ** 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/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Confirmed Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From mriedem at us.ibm.com Fri Nov 1 18:15:33 2013 From: mriedem at us.ibm.com (Matt Riedemann) Date: Fri, 01 Nov 2013 18:15:33 -0000 Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131101181534.10053.56343.launchpad@soybean.canonical.com> ** Tags added: api ** Changed in: nova Status: New => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Confirmed Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From bdpayne at acm.org Fri Nov 1 18:36:27 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Fri, 01 Nov 2013 18:36:27 -0000 Subject: [Openstack-security] OSSG Meetup at Summit Next Week Message-ID: <20131101183627.18513.58508.launchpad@wampee.canonical.com> Are you coming to the OpenStack Summit next week? If so, then please join the rest of the OpenStack Security Group (OSSG) for lunch on Tuesday, November 5th. We'll be meeting outside of the Nova room by the developer's summit area at 12:45p. From there we'll assess the group size and decide where to go for food. The OpenStack Security Group has grown significantly over the past 6 months. This is a great opportunity to meet others interested in OpenStack security and help shape the future of our group! I hope to see you all there. Cheers, -bryan -- This message was sent from Launchpad by Bryan D. Payne (https://launchpad.net/~bdpayne) to each member of the OpenStack Security Group team using the "Contact this team" link on the OpenStack Security Group team page (https://launchpad.net/~openstack-ossg). For more information see https://help.launchpad.net/YourAccount/ContactingPeople From 1168252 at bugs.launchpad.net Fri Nov 1 18:32:55 2013 From: 1168252 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 01 Nov 2013 18:32:55 -0000 Subject: [Openstack-security] [Bug 1168252] Fix merged to devstack (master) References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com> Message-ID: <20131101183255.12839.38040.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/53248 Committed: http://github.com/openstack-dev/devstack/commit/d561b70930f7184ade05953faa11a47dc250a16c Submitter: Jenkins Branch: master commit d561b70930f7184ade05953faa11a47dc250a16c Author: Dean Troyer Date: Tue Oct 22 17:46:00 2013 -0500 Set keystone.conf to mode 0600 Set keystone.conf readable only by owner Fixes CVE-2013-1977 Fixed bug: 1168252 Change-Id: Idd13b7a58e257565052c54f72c65d8dceb23f27a -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1168252 Title: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) Status in devstack - openstack dev environments: Confirmed Status in OpenStack Security Notes: Fix Released Status in Gentoo Linux: Fix Released Bug description: The password configuration of LDAP and admin_token in keystone.conf should be secret to protect security information: [ldap] # url = ldap://localhost # user = dc=Manager,dc=example,dc=com # password = None <- should be secrect # suffix = cn=example,cn=com # use_dumb_member = False # allow_subtree_delete = False # dumb_member = cn=dumb,dc=example,dc=com [DEFAULT] admin_token = passw0rd <- should be secrect To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1168252/+subscriptions From robert.clark at hp.com Fri Nov 1 19:05:13 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 1 Nov 2013 19:05:13 +0000 Subject: [Openstack-security] List of steps to perform to prepare or condition long term keys? In-Reply-To: Message-ID: Credential rolling is important, it forms a pillar of many password management programs and compliance targets. For the most part people will take care of this using configuration management like Puppet or Chef, on smaller scales I guess there are more options. I¹m hoping that CloudKeep can be used in intelligent ways to fix peoples here but that¹s some way off being production ready. I think you¹re right to point this out, it could be addressed better in the security guide. Cheers -Rob On 25/10/2013 08:25, "Jeffrey Walton" wrote: >I was reading through the OpenStack Security Guide dated Oct 25 2013 >for Havana (http://docs.openstack.org/sec/). Good job on that, by the >way. > >Does anyone have a list of steps to perform to prepare or condition >long term keys? For example, SSH keys should be regenerated, Samba's >secret should probably be recreated (if present), Ubuntu's Snake Oil >key should probably be deleted (if present), etc. > >I'm interested in both the bare metal OS and VM instances. (VM >instances are somewhat covered under Chapter 43). > >Thanks in advance. > >_______________________________________________ >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 Fri Nov 1 19:10:25 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 1 Nov 2013 19:10:25 +0000 Subject: [Openstack-security] Certmonger In-Reply-To: Message-ID: Support for ADCS and EJBCA would make sense. I wasn’t aware of the Chef-SSL project, quite interesting. In my experience the hard part with CA operations is actually the Registration Authority, ensuring that the requesting party has a right to the certificate is one of the main roles of the RA and with client-side generation (without out-of-band attestation) you quickly run into a chicken and egg type problem. A long time ago I wrote half of a very light weight restful CA with a very simple API and delegated certificate issuing (So you could grant permissions to create certificates on certain sub domains) - I keep threatening to turn it into something real. I’m not convinced that any of the platforms out there meet the needs we have very well. I should look more closely at Certmonger, maybe this will fit the bill! From: Bryan Payne > Date: Tuesday, 29 October 2013 19:20 To: "ayoung at redhat.com" > Cc: "openstack-security at lists.openstack.org" > Subject: Re: [Openstack-security] Certmonger We need an approach for SSL everywhere: it is one of the issues rasied in the security guide. Thus, the default deployment needs to show how to set that up. Makes sense to me. -bryan From davanum at gmail.com Fri Nov 1 20:37:55 2013 From: davanum at gmail.com (Davanum Srinivas (DIMS)) Date: Fri, 01 Nov 2013 20:37:55 -0000 Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131101203755.12643.53301.malone@chaenomeles.canonical.com> Go for it. +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/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Confirmed Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From ayoung at redhat.com Sat Nov 2 15:55:52 2013 From: ayoung at redhat.com (Adam Young) Date: Sat, 02 Nov 2013 11:55:52 -0400 Subject: [Openstack-security] Certmonger In-Reply-To: References: Message-ID: <52752088.9020307@redhat.com> On 11/01/2013 03:10 PM, Clark, Robert Graham wrote: > Support for ADCS and EJBCA would make sense. Good to hear it. I'd come across them, but didn't know how well supported they were. > > I wasn’t aware of the Chef-SSL project, quite interesting. In my experience the hard part with CA operations is actually the Registration Authority, ensuring that the requesting party has a right to the certificate is one of the main roles of the RA and with client-side generation (without out-of-band attestation) you quickly run into a chicken and egg type problem. Dogtag, EJBCA and ADCS I think all have solutions to this, which are somewhat different. I suspect that could be abstracted away from the Certmonger piece. > > A long time ago I wrote half of a very light weight restful CA with a very simple API and delegated certificate issuing (So you could grant permissions to create certificates on certain sub domains) - I keep threatening to turn it into something real. I’m not convinced that any of the platforms out there meet the needs we have very well. I should look more closely at Certmonger, maybe this will fit the bill! Certmaster is the equivalent: https://fedorahosted.org/certmaster/ XML-RPC based, so a RESTful augmentation would be very nice. THen again, we also have Barbican. Lets make sure we are not duplicating effort. > > From: Bryan Payne > > Date: Tuesday, 29 October 2013 19:20 > To: "ayoung at redhat.com" > > Cc: "openstack-security at lists.openstack.org" > > Subject: Re: [Openstack-security] Certmonger > > > We need an approach for SSL everywhere: it is one of the issues rasied in the security guide. Thus, the default deployment needs to show how to set that up. > > Makes sense to me. > -bryan From 1231263 at bugs.launchpad.net Sun Nov 3 07:15:14 2013 From: 1231263 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 03 Nov 2013 07:15:14 -0000 Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been print in log by some API call References: <20130926055439.7490.27811.malonedeb@gac.canonical.com> Message-ID: <20131103071514.18513.12072.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/54954 Committed: http://github.com/openstack/nova/commit/5a385f23101dc99e0bc97975e664d3ef242888d3 Submitter: Jenkins Branch: stable/havana commit 5a385f23101dc99e0bc97975e664d3ef242888d3 Author: Davanum Srinivas Date: Thu Oct 3 22:28:58 2013 -0400 Sanitize passwords when logging payload in wsgi adminPass (or admin_pass) can be either part of a json object or an xml element or xml attribute. The patch includes regexps to support all these cases and adds tests as well Change-Id: Ic119f986a03863c1d13b566b4c005f3bc77d83d0 Closes-Bug: 1231263 (cherry picked from commit c6d82083295e9b1b42f22d3a2d25a1ab7d341a13) ** Tags added: in-stable-havana -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1231263 Title: Clear text password has been print in log by some API call Status in OpenStack Compute (Nova): Fix Committed Bug description: In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova. i.e: 2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': , 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103 2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926 This is not secue which the password should be replaced by *** To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1231263/+subscriptions From robert.clark at hp.com Sun Nov 3 17:03:02 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Sun, 3 Nov 2013 17:03:02 +0000 Subject: [Openstack-security] Security bods at the summit, Monday meet up? Message-ID: Hi Guys, Wondering if anyone wants to meet up for a drink or two on Monday night? Everyone welcome, I wasn’t thinking about going far as I don’t know the area, that said, if people want to go for an adventure, I’m game! -Rob From ldbragst at us.ibm.com Mon Nov 4 22:50:46 2013 From: ldbragst at us.ibm.com (Lance Bragstad) Date: Mon, 04 Nov 2013 22:50:46 -0000 Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131104225046.23852.99083.malone@gac.canonical.com> I linked the bug # in my commit message but it hasn't shown up yet? Just FYI for everyone following: https://review.openstack.org/#/c/55193/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Confirmed Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From bdpayne at acm.org Tue Nov 5 01:39:24 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 05 Nov 2013 01:39:24 -0000 Subject: [Openstack-security] Reminder: OSSG Lunch Today Message-ID: <20131105013924.24061.70161.launchpad@gac.canonical.com> Just a quick reminder that the OSSG lunch meeting is today at 12:45p. We'll be meeting outside of the Nova room (AWE Level 2, Room 204-205) and then walking to one of the restaurants here in the Expo Center. I'm looking forward to seeing you all there. Cheers, -bryan -- This message was sent from Launchpad by Bryan D. Payne (https://launchpad.net/~bdpayne) to each member of the OpenStack Security Group team using the "Contact this team" link on the OpenStack Security Group team page (https://launchpad.net/~openstack-ossg). For more information see https://help.launchpad.net/YourAccount/ContactingPeople From robert.clark at hp.com Tue Nov 5 02:59:09 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 5 Nov 2013 02:59:09 +0000 Subject: [Openstack-security] Certmonger In-Reply-To: <52752088.9020307@redhat.com> Message-ID: On 02/11/2013 15:55, "Adam Young" wrote: > > > >On 11/01/2013 03:10 PM, Clark, Robert Graham wrote: >> Support for ADCS and EJBCA would make sense. >Good to hear it. I'd come across them, but didn't know how well >supported they were. > >> >> I wasn¹t aware of the Chef-SSL project, quite interesting. In my >>experience the hard part with CA operations is actually the Registration >>Authority, ensuring that the requesting party has a right to the >>certificate is one of the main roles of the RA and with client-side >>generation (without out-of-band attestation) you quickly run into a >>chicken and egg type problem. >Dogtag, EJBCA and ADCS I think all have solutions to this, which are >somewhat different. I suspect that could be abstracted away from the >Certmonger piece. They do but they¹re all horrible. EJBCA requires identity profiles for every request, a major headache and very hard to manage in dynamic environments. ADCS only works nicely if all your machines are domain joined in just the right way, Dogtag I¹m not sure about but I suspect it has similar constraints. >> >> A long time ago I wrote half of a very light weight restful CA with a >>very simple API and delegated certificate issuing (So you could grant >>permissions to create certificates on certain sub domains) - I keep >>threatening to turn it into something real. I¹m not convinced that any >>of the platforms out there meet the needs we have very well. I should >>look more closely at Certmonger, maybe this will fit the bill! >Certmaster is the equivalent: > >https://fedorahosted.org/certmaster/ > >XML-RPC based, so a RESTful augmentation would be very nice. > >THen again, we also have Barbican. Lets make sure we are not >duplicating effort. Interesting, I¹m keen to understand more about the x509 stuff in Barbican and I¹ve added Certmaster to the list of things to look into. > >> >> From: Bryan Payne > >> Date: Tuesday, 29 October 2013 19:20 >> To: "ayoung at redhat.com" >>> >> Cc: >>"openstack-security at lists.openstack.org>penstack.org>" >>>penstack.org>> >> Subject: Re: [Openstack-security] Certmonger >> >> >> We need an approach for SSL everywhere: it is one of the issues rasied >>in the security guide. Thus, the default deployment needs to show how >>to set that up. >> >> Makes sense to me. >> -bryan > From nkinder at redhat.com Tue Nov 5 04:52:05 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 04 Nov 2013 20:52:05 -0800 Subject: [Openstack-security] Certmonger In-Reply-To: References: Message-ID: <52787975.3010308@redhat.com> On 11/04/2013 06:59 PM, Clark, Robert Graham wrote: > > On 02/11/2013 15:55, "Adam Young" wrote: > >> >> >> On 11/01/2013 03:10 PM, Clark, Robert Graham wrote: >>> Support for ADCS and EJBCA would make sense. >> Good to hear it. I'd come across them, but didn't know how well >> supported they were. >> >>> I wasn¹t aware of the Chef-SSL project, quite interesting. In my >>> experience the hard part with CA operations is actually the Registration >>> Authority, ensuring that the requesting party has a right to the >>> certificate is one of the main roles of the RA and with client-side >>> generation (without out-of-band attestation) you quickly run into a >>> chicken and egg type problem. >> Dogtag, EJBCA and ADCS I think all have solutions to this, which are >> somewhat different. I suspect that could be abstracted away from the >> Certmonger piece. > They do but they¹re all horrible. EJBCA requires identity profiles for > every request, a major headache and very hard to manage in dynamic > environments. ADCS only works nicely if all your machines are domain > joined in just the right way, Dogtag I¹m not sure about but I suspect it > has similar constraints. Dogtag is fairly flexible. What approach are you thinking of for proving that the requesting party is allowed to request a certificate? I do agree with Adam that using Certmonger as an abstraction layer is a good idea. -NGK > > >>> A long time ago I wrote half of a very light weight restful CA with a >>> very simple API and delegated certificate issuing (So you could grant >>> permissions to create certificates on certain sub domains) - I keep >>> threatening to turn it into something real. I¹m not convinced that any >>> of the platforms out there meet the needs we have very well. I should >>> look more closely at Certmonger, maybe this will fit the bill! >> Certmaster is the equivalent: >> >> https://fedorahosted.org/certmaster/ >> >> XML-RPC based, so a RESTful augmentation would be very nice. >> >> THen again, we also have Barbican. Lets make sure we are not >> duplicating effort. > Interesting, I¹m keen to understand more about the x509 stuff in Barbican > and I¹ve added Certmaster to the list of things to look into. > >>> From: Bryan Payne > >>> Date: Tuesday, 29 October 2013 19:20 >>> To: "ayoung at redhat.com" >>> > >>> Cc: >>> "openstack-security at lists.openstack.org>> penstack.org>" >>> >> penstack.org>> >>> Subject: Re: [Openstack-security] Certmonger >>> >>> >>> We need an approach for SSL everywhere: it is one of the issues rasied >>> in the security guide. Thus, the default deployment needs to show how >>> to set that up. >>> >>> Makes sense to me. >>> -bryan > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From sriram at sriramhere.com Tue Nov 5 06:24:09 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Tue, 5 Nov 2013 14:24:09 +0800 Subject: [Openstack-security] OSSG Lunch Meeting Notes Message-ID: Some of the items discussed, followed by Action Items: 1) How can one get invovled - Wiki will direct 2) Where to pick up security tasks from? - wiki is the starting point - people sign up via mailing list 3) threat analysis - Static Analysis, Formal Verification on projects was proposed by James. - - static analysis on python is not very useful; whole projects will take a long time - 4) Threat modeling - - *Action item* (James Kempf) : share the results from Folsom for TM around Keystone - Rob can get resources towards this - get started with core or knowledgeable people - Ideally, Secuirty Reviews Per month per project. Review coordinator prepares the arch diagram before the review day 5) security review - HP's review process; what it translates to for OpenStack? 6) Attacker model - single or many - 7) Tracking the CVEs, publish in the format - *Action Item*: Daniel (Red Hat) to start discussin in the mailing list - Format: 8) Getting the word out (wiki, how to contribute, what is going on) - Minutes for the meet - Community Manager - Sprints: - Running the sprint *Action Items:* - Eric Windisch to Identify topic to set the sprint/ hackathon and time. Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Tue Nov 5 06:50:27 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 5 Nov 2013 14:50:27 +0800 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: References: Message-ID: Someone left an OpenStack registration bag at the lunch (with a L t-shirt in it). If you'd like it back, just come find me :-) -bryan On Tue, Nov 5, 2013 at 2:24 PM, Sriram Subramanian wrote: > Some of the items discussed, followed by Action Items: > > 1) How can one get invovled - Wiki will direct > 2) Where to pick up security tasks from? > - wiki is the starting point > - people sign up via mailing list > > > 3) threat analysis > - Static Analysis, Formal Verification on projects was proposed by > James. > - > - static analysis on python is not very useful; whole projects will > take a long time > - > 4) Threat modeling - > - > *Action item* (James Kempf) : share the results from Folsom for TM around > Keystone > > - Rob can get resources towards this > - get started with core or knowledgeable people > - Ideally, Secuirty Reviews Per month per project. Review coordinator > prepares the arch diagram before the review day > > 5) security review - HP's review process; what it translates to for > OpenStack? > > 6) Attacker model > - single or many > - > 7) Tracking the CVEs, publish in the format > > - *Action Item*: Daniel (Red Hat) to start discussin in the mailing list > - Format: > 8) > Getting the word out (wiki, how to contribute, what is going on) > - Minutes for the meet > - Community Manager > - Sprints: > - Running the sprint > > *Action Items:* > - Eric Windisch to Identify topic to set the sprint/ hackathon and time. > > Thanks, > -Sriram > > _______________________________________________ > 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 mriedem at us.ibm.com Tue Nov 5 21:55:50 2013 From: mriedem at us.ibm.com (Matt Riedemann) Date: Tue, 05 Nov 2013 21:55:50 -0000 Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131105215550.18513.26060.launchpad@wampee.canonical.com> ** Also affects: oslo Importance: Undecided Status: New ** Changed in: oslo 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/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Confirmed Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From 1247217 at bugs.launchpad.net Wed Nov 6 02:09:49 2013 From: 1247217 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 06 Nov 2013 02:09:49 -0000 Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131106020952.12947.32406.launchpad@chaenomeles.canonical.com> ** Changed in: oslo Assignee: (unassigned) => Lance Bragstad (ldbragst) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Confirmed Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From robert.clark at hp.com Wed Nov 6 16:06:12 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 6 Nov 2013 16:06:12 +0000 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: Message-ID: Thanks for the great notes Sriram. I’ve made the ‘how to contribute’ part of the wiki more prominent: https://wiki.openstack.org/wiki/Security/How_To_Contribute To clarify, when we have the ball rolling on Threat Modelling for major projects, I can commit some security-architect resources to take part in the discussions. Cheers -Rob From: Sriram Subramanian > Date: Tuesday, 5 November 2013 14:24 To: "openstack-security at lists.openstack.org" > Subject: [Openstack-security] OSSG Lunch Meeting Notes Some of the items discussed, followed by Action Items: 1) How can one get invovled - Wiki will direct 2) Where to pick up security tasks from? - wiki is the starting point - people sign up via mailing list 3) threat analysis - Static Analysis, Formal Verification on projects was proposed by James. - - static analysis on python is not very useful; whole projects will take a long time - 4) Threat modeling - - Action item (James Kempf) : share the results from Folsom for TM around Keystone - Rob can get resources towards this - get started with core or knowledgeable people - Ideally, Secuirty Reviews Per month per project. Review coordinator prepares the arch diagram before the review day 5) security review - HP's review process; what it translates to for OpenStack? 6) Attacker model - single or many - 7) Tracking the CVEs, publish in the format - Action Item: Daniel (Red Hat) to start discussin in the mailing list - Format: 8) Getting the word out (wiki, how to contribute, what is going on) - Minutes for the meet - Community Manager - Sprints: - Running the sprint Action Items: - Eric Windisch to Identify topic to set the sprint/ hackathon and time. Thanks, -Sriram From robert.clark at hp.com Wed Nov 6 16:08:12 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 6 Nov 2013 16:08:12 +0000 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted Message-ID: Hi All, I’m looking for help with the OpenStack Security Notes. I currently am struggling to keep up with them and do all the other things I’m involved in. Individually they don’t take that much time so with one or two people helping out they wouldn’t be a significant burden. If anyone wants to run the management of this project and publishing the OSSNs I’d be happy to support them in an editorial capacity. Cheers -Rob From james.kempf at ericsson.com Thu Nov 7 00:18:05 2013 From: james.kempf at ericsson.com (James Kempf) Date: Thu, 7 Nov 2013 00:18:05 +0000 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: References: Message-ID: Hi Rob, Shohel (cc-ed) from Ericsson will be driving this. He will be setting up a chat/teleconference sometime late next week to get started. jak > -----Original Message----- > From: Clark, Robert Graham [mailto:robert.clark at hp.com] > Sent: Thursday, November 07, 2013 12:06 AM > To: Sriram Subramanian; openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes > > Thanks for the great notes Sriram. > > I've made the 'how to contribute' part of the wiki more prominent: > https://wiki.openstack.org/wiki/Security/How_To_Contribute > > To clarify, when we have the ball rolling on Threat Modelling for major > projects, I can commit some security-architect resources to take part in > the discussions. > > Cheers > -Rob > > > From: Sriram Subramanian > > > Date: Tuesday, 5 November 2013 14:24 > To: "openstack-security at lists.openstack.org security at lists.openstack.org>" security at lists.openstack.org security at lists.openstack.org>> > Subject: [Openstack-security] OSSG Lunch Meeting Notes > > Some of the items discussed, followed by Action Items: > > 1) How can one get invovled - Wiki will direct > 2) Where to pick up security tasks from? > - wiki is the starting point > - people sign up via mailing list > > > 3) threat analysis > - Static Analysis, Formal Verification on projects was proposed by > James. > - > - static analysis on python is not very useful; whole projects will > take a long time > - > 4) Threat modeling - > - > Action item (James Kempf) : share the results from Folsom for TM around > Keystone > > - Rob can get resources towards this > - get started with core or knowledgeable people > - Ideally, Secuirty Reviews Per month per project. Review coordinator > prepares the arch diagram before the review day > > 5) security review - HP's review process; what it translates to for > OpenStack? > > 6) Attacker model > - single or many > - > 7) Tracking the CVEs, publish in the format > > - Action Item: Daniel (Red Hat) to start discussin in the mailing list > - Format: > 8) > Getting the word out (wiki, how to contribute, what is going on) > - Minutes for the meet > - Community Manager > - Sprints: > - Running the sprint > > Action Items: > - Eric Windisch to Identify topic to set the sprint/ hackathon and time. > > Thanks, > -Sriram > > _______________________________________________ > 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 Thu Nov 7 04:59:44 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 7 Nov 2013 04:59:44 +0000 Subject: [Openstack-security] Icehouse Vulnerability Management Message-ID: For those (like me) who missed it, here is a link to the minutes from the VMT meeting at the OpenStack Summit this morning. https://etherpad.openstack.org/p/IcehouseVMT There are several topics here that I’m sure will interest many people in the group, looking forward to some more discussion. -Rob From bdpayne at acm.org Thu Nov 7 05:47:09 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 7 Nov 2013 13:47:09 +0800 Subject: [Openstack-security] Icehouse Vulnerability Management In-Reply-To: References: Message-ID: Thanks Rob. I just added some comments in there that are similar to what I mentioned during the session itself. -bryan On Thu, Nov 7, 2013 at 12:59 PM, Clark, Robert Graham wrote: > For those (like me) who missed it, here is a link to the minutes from the > VMT meeting at the OpenStack Summit this morning. > > https://etherpad.openstack.org/p/IcehouseVMT > > There are several topics here that I’m sure will interest many people in > the group, looking forward to some more discussion. > > -Rob > > _______________________________________________ > 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 pavuluri.kanthi at gmail.com Thu Nov 7 08:41:10 2013 From: pavuluri.kanthi at gmail.com (Kanthi P) Date: Thu, 7 Nov 2013 10:41:10 +0200 Subject: [Openstack-security] Fwd: Quantum security groups in Havana In-Reply-To: References: Message-ID: Hi, I am trying to boot a VM which has a network without subnet in Havana, but it throws an exception saying that subnet is mandatory if quantum security groups are enabled. Here are the commands I used. neutron net-create testNet [lcc at lcc devstack]$ neutron net-show testNet +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | id | 47208beb-2801-4729-bc7b-6532717232fc | | name | testNet | | provider:network_type | local | | provider:physical_network | | | provider:segmentation_id | | | router:external | False | | shared | False | | status | ACTIVE | | subnets | | | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d | +---------------------------+--------------------------------------+ nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1 Here is the piece of code which generated this exception nova/network/neutronv2/api.py if (security_groups and not ( network['subnets'] and network.get('port_security_enabled', True))): raise exception.SecurityGroupCannotBeApplied() Can someone please explain why do we need this check? To my understanding subnet is used for two purposes in terms of security groups 1. To allow dhcp traffic if dhcp is enabled on the subnet, example given below -A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp --sport 67 --dport 68 -j RETURN 2. To avoid ip spoof -A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP Can we remove this so that we can have guests which has nic with just MAC address, guest can configure its own ipaddress. Later if needed they can enable their own security rules via quantum api. -------------- next part -------------- An HTML attachment was scrubbed... URL: From myleshosford at gmail.com Thu Nov 7 10:14:09 2013 From: myleshosford at gmail.com (Myles Hosford) Date: Thu, 7 Nov 2013 10:14:09 +0000 Subject: [Openstack-security] CSP to Improve Horizon Security Message-ID: Hi, I was initially going to file this on https://bugs.launchpad.net/ossn/ as a bug, but its not a exploitable vulnerability and more a defence in depth / increase security posture recommendation for Horizon I thought the list would be best place to spark initial discussion, its also very similar in nature to the HSTS header issue https://bugs.launchpad.net/ossn/+bug/1191050 , but probably a lot more work to implement :-( Although Horizon does a very good job of escaping user input and does not have a track record of Cross-Site Scripting vulnerabilities, its security posture could be increased long term by the use of the Content-Security-Policy header. This would protect against any new functionality tat falls short of current XSS filtering, and also framework and middleware vulns that Horizon doesn't really have control over. Its use when configured correctly pretty much eradicates XSS bugs (along with some other cross-site includes) and is a huge step forward in client-side browser security. If your not familiar with the CSP header and how it works, it basically prevents inline JavaScript, and has fine grain control regarding where client-side script is loaded from. The reason I said in the first paragraph that its probably a lot more work is that the web application needs to move any JavaScript it uses into .js files and include those from within the HTML, so something that was originally[1]: Becomes: // amazing.jsfunction doAmazingThings() { alert('YOU AM AMAZING!');} document.addEventListener('DOMContentReady', function () { document.getElementById('amazing') .addEventListener('click', doAmazingThings);}); Once you have moved all your JS out of the HTML and into .js files, you can set the CSP header to only load script from your domain: Content-Security-Policy: default-src 'none'; script-src https://horizon.mycloud.net; So with that set, even if you had a parameter vulnerable to reflected XSS as follows: https://horizon.mycloud.net/login/user=admin It wouldn't get executed - demonstrating the excellent defence in depth. Finally, as the CSP may be organisation specific, it may be best to allow the exact policy to be configureable and a note in the security guide, but for this even to be a possibility the JavaScript needs to be cleaned up and moved out :-( Heres a few posts on how twitter have gone about it: https://blog.twitter.com/2011/improving-browser-security-csp https://blog.twitter.com/2013/csp-to-the-rescue-leveraging-the-browser-for-security I'm happy to provide more help, test and work with anyone if this moves forward, and Hi, I'm Myles :-) [1] Example taken from http://www.html5rocks.com/en/tutorials/security/content-security-policy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavuluri.kanthi at gmail.com Thu Nov 7 20:23:15 2013 From: pavuluri.kanthi at gmail.com (Kanthi P) Date: Thu, 7 Nov 2013 22:23:15 +0200 Subject: [Openstack-security] Neutron security groups for L2 networks in Havana Message-ID: Hi, I am trying to boot a VM which has a network without subnet in Havana, but it throws an exception saying that subnet is mandatory if quantum security groups are enabled. Here are the commands I used. neutron net-create testNet neutron net-show testNet +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | id | 47208beb-2801-4729-bc7b-6532717232fc | | name | testNet | | provider:network_type | local | | provider:physical_network | | | provider:segmentation_id | | | router:external | False | | shared | False | | status | ACTIVE | | subnets | | | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d | +---------------------------+--------------------------------------+ nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1 Here is the piece of code which generated this exception nova/network/neutronv2/api.py if (security_groups and not ( network['subnets'] and network.get('port_security_enabled', True))): raise exception.SecurityGroupCannotBeApplied() Can someone please explain why do we need this check? To my understanding subnet is used for two purposes in terms of security groups 1. To allow dhcp traffic if dhcp is enabled on the subnet, example given below -A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp --sport 67 --dport 68 -j RETURN 2. To avoid ip spoof -A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP Can we remove this so that we can have guests which has nic with just MAC address, guest can configure its own ipaddress. Later if needed they can enable their own security rules via quantum api. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriram at sriramhere.com Thu Nov 7 21:15:18 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Fri, 8 Nov 2013 05:15:18 +0800 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: References: Message-ID: Rob - I can do this. As you will be available to support in editorial capacity, I'd assume it will be a release management kind of activity? Let us try chatting little bit today during the summit in terms of exact tasks, else chat via email. thanks, -Sriram On Thu, Nov 7, 2013 at 12:08 AM, Clark, Robert Graham wrote: > Hi All, > > I’m looking for help with the OpenStack Security Notes. I currently am > struggling to keep up with them and do all the other things I’m involved > in. Individually they don’t take that much time so with one or two people > helping out they wouldn’t be a significant burden. > > If anyone wants to run the management of this project and publishing the > OSSNs I’d be happy to support them in an editorial capacity. > > Cheers > -Rob > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Fri Nov 8 02:06:42 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 8 Nov 2013 02:06:42 +0000 Subject: [Openstack-security] Security in OpenStack Thesis. Message-ID: I stumbled over this while doing some related research, looks interesting enough to share. http://www.slideshare.net/oldbam/security-issues-in-openstack From kseifried at redhat.com Fri Nov 8 04:57:54 2013 From: kseifried at redhat.com (Kurt Seifried) Date: Thu, 07 Nov 2013 21:57:54 -0700 Subject: [Openstack-security] Security in OpenStack Thesis. In-Reply-To: References: Message-ID: <527C6F52.30506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/07/2013 07:06 PM, Clark, Robert Graham wrote: > I stumbled over this while doing some related research, looks > interesting enough to share. > > http://www.slideshare.net/oldbam/security-issues-in-openstack Interesting, one major takeaway: MD5 bad (and we already knew that, right? ;). - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSfG9SAAoJEBYNRVNeJnmTUb0QAMg4k4tGZLcTu3enUkxPpGAX RPU0S2YuXBHsGo1KzWnxruTFBupwGQYwVPQDEbpv159e59bvlZDweGqYSzjc92HP 6UKd9JGES57mkQw0DMHaC2BDD1Nk4yDlW32cjtAcFOCmj0la1mxyBgU/JVabPlIK nkVg5k0uvwEZB6IDSpVRCTykhubyM37KB0U4/VFKJxGRFUIW1GWkSSD0i1bwGr5r e99Chh7p28kGdtTI7mY6aPJaP7eUs6dlJBWs7/BevcSaTAVA4C96+RO5MG8sdhSB 3VcN/G0SCFMTQbGf+PICxsH4CzI452xVBKu0iUio3iHaAY/ZZUHFnPuX74wVep56 LIEWTkh4hUUNF4IEHcPCnbHOBU9KHsUdyG8qTL8xW5UvUbaeBdpI7c42pMJzObHk cBvMWF2zIEYlFqY60WP5LvI2f9m580Jf6PXRrdQcsgLmoxFRjUlLHomuGTObpQq2 C4ExxwpAmKV4AQ7Sam+3FB4Bsnf1K6KtsyGXQRjMuIBMGRQjL0qD/RtP9MbPLEc8 nlGFLGhM27H7FEh/0UXrLg8G2ebuzifNboPcaKdNVa2qUp2w+Q0NCL7ChhN9yjhC OJeCN9s+S/S0ca3TZveExFIeqlfhznh2ml+VYKjEiUIsNCVjCLZvBfngfZZnFrt8 lcwV3odrI+4gdyIO9jro =9yx9 -----END PGP SIGNATURE----- From 1247217 at bugs.launchpad.net Fri Nov 8 00:41:53 2013 From: 1247217 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 08 Nov 2013 00:41:53 -0000 Subject: [Openstack-security] [Bug 1247217] Fix merged to oslo-incubator (master) References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131108004154.10165.6424.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/55193 Committed: http://github.com/openstack/oslo-incubator/commit/76b0cd10c414ae71e6f041adb431460b3337c63d Submitter: Jenkins Branch: master commit 76b0cd10c414ae71e6f041adb431460b3337c63d Author: Lance Bragstad Date: Mon Nov 4 22:35:36 2013 +0000 Add mask password impl from other projects A couple of different projects have an implementation for 'masking' passwords in logs and wsgi output. This seems like something that should go into Oslo-incubator as a common implementation. This implementation is based off the following two implementations in Keystone and Nova: https://review.openstack.org/#/c/26487/12 https://review.openstack.org/#/c/49664/ Partial-Bug: #1247217 Change-Id: I2b1bbb4d3ddaa163573b685b3e3a5e8a3977e390 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Confirmed Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From robert.clark at hp.com Fri Nov 8 05:57:42 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 8 Nov 2013 05:57:42 +0000 Subject: [Openstack-security] Talk Reminder Message-ID: Shameless plug, for anyone left in Hong Kong: http://openstacksummitnovember2013.sched.org/event/5c207054e9b39199f7b6cca4 c51f5d45#.Unx9IJQnimQ Often ignored or hidden away in risk registers the consequences of hypervisor breakouts are incredibly high. In this presentation I describe potential exploitation vectors in common virtualization stacks before diving into hands on, practical guidance for securing your hypervisor and addressing breakout vulnerabilities when they occur. Friday November 8, 2013 3:10pm - 3:50pm Expo Breakout Room 2 (AsiaWorld-Expo ) From robert.clark at hp.com Fri Nov 8 06:00:36 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 8 Nov 2013 06:00:36 +0000 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: Message-ID: Thanks for the support, I’ll put you and the other two people who want to help together in the next day or two and we’ll work out how to take this forward. The aspiration is that we’ll be producing an OSSN every one to two weeks, so the expectation is that we’ll need more than one person working on this in the future! Unfortunately I’m at a wedding during the next OSSG meeting, lets see if we can knock a few emails around to work out a light-weight process for taking this forward. Cheers -Rob From: Sriram Subramanian > Date: Friday, 8 November 2013 05:15 To: Robert Clark > Cc: "openstack-security at lists.openstack.org" > Subject: Re: [Openstack-security] OpenStack Security Notes - Contributors Wanted Rob - I can do this. As you will be available to support in editorial capacity, I'd assume it will be a release management kind of activity? Let us try chatting little bit today during the summit in terms of exact tasks, else chat via email. thanks, -Sriram On Thu, Nov 7, 2013 at 12:08 AM, Clark, Robert Graham > wrote: Hi All, I’m looking for help with the OpenStack Security Notes. I currently am struggling to keep up with them and do all the other things I’m involved in. Individually they don’t take that much time so with one or two people helping out they wouldn’t be a significant burden. If anyone wants to run the management of this project and publishing the OSSNs I’d be happy to support them in an editorial capacity. Cheers -Rob _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -- Thanks, -Sriram From noloader at gmail.com Fri Nov 8 07:02:19 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 8 Nov 2013 02:02:19 -0500 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: References: Message-ID: Hi Robert, I'd be happy to help out with spare cycles. Jeff On Wed, Nov 6, 2013 at 11:08 AM, Clark, Robert Graham wrote: > Hi All, > > I’m looking for help with the OpenStack Security Notes. I currently am struggling to keep up with them and do all the other things I’m involved in. Individually they don’t take that much time so with one or two people helping out they wouldn’t be a significant burden. > > If anyone wants to run the management of this project and publishing the OSSNs I’d be happy to support them in an editorial capacity. > > Cheers > -Rob > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From arosen at nicira.com Fri Nov 8 07:42:50 2013 From: arosen at nicira.com (Aaron Rosen) Date: Thu, 7 Nov 2013 23:42:50 -0800 Subject: [Openstack-security] Neutron security groups for L2 networks in Havana In-Reply-To: References: Message-ID: On Thu, Nov 7, 2013 at 12:23 PM, Kanthi P wrote: > Hi, > > I am trying to boot a VM which has a network without subnet in Havana, but > it throws an exception saying that subnet is mandatory if quantum security > groups are enabled. > > Here are the commands I used. > > neutron net-create testNet > neutron net-show testNet > +---------------------------+--------------------------------------+ > | Field | Value | > +---------------------------+--------------------------------------+ > | admin_state_up | True | > | id | 47208beb-2801-4729-bc7b-6532717232fc | > | name | testNet | > | provider:network_type | local | > | provider:physical_network | | > | provider:segmentation_id | | > | router:external | False | > | shared | False | > | status | ACTIVE | > | subnets | | > | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d | > +---------------------------+--------------------------------------+ > > nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic > net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1 > > Here is the piece of code which generated this exception > > nova/network/neutronv2/api.py > > if (security_groups and not ( > network['subnets'] > and network.get('port_security_enabled', True))): > > raise exception.SecurityGroupCannotBeApplied() > > > Can someone please explain why do we need this check? > Hi Kanthi, We need this check because because in order to enforce security groups the port needs to have an ip_address (i.e: network needs a subnet) since Security groups only map to L3/4 headers. Today, nova automatically adds a default security group to all instances when booted. Hopefully we can punt this task off to neutron in this release by moving the port-creation up on the stack to nova-api instead of nova-compute though this isn't the case right now. Aaron > > To my understanding subnet is used for two purposes in terms of security > groups > 1. To allow dhcp traffic if dhcp is enabled on the subnet, example given > below > -A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp > --sport 67 --dport 68 -j RETURN > 2. To avoid ip spoof > -A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP > > Can we remove this so that we can have guests which has nic with just MAC > address, guest can configure its own ipaddress. Later if needed they can > enable their own security rules via quantum api. > > _______________________________________________ > 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 pavuluri.kanthi at gmail.com Fri Nov 8 09:45:54 2013 From: pavuluri.kanthi at gmail.com (Kanthi P) Date: Fri, 8 Nov 2013 11:45:54 +0200 Subject: [Openstack-security] Neutron security groups for L2 networks in Havana In-Reply-To: References: Message-ID: Hi Aaron, Thanks for the reply ! Yes security groups are mapped to L3/L4 headers, these security rules are being converted to iptables. If we remove the subnet check, we will be able to launch instances without ipaddress, they just have the mac address. Users can configure their own ipaddress after they are booted. If we use neutron security groups, it provides a default group (on port basis) which blocks all ingress and allows all egress traffic. Later users can configure security groups based on the ip address what they provided to the vnics. I mean to say, ports will have subnet but just that this subnet is not known to openstack during the instance boot time. On Fri, Nov 8, 2013 at 9:42 AM, Aaron Rosen wrote: > > > > On Thu, Nov 7, 2013 at 12:23 PM, Kanthi P wrote: > >> Hi, >> >> I am trying to boot a VM which has a network without subnet in Havana, >> but it throws an exception saying that subnet is mandatory if quantum >> security groups are enabled. >> >> Here are the commands I used. >> >> neutron net-create testNet >> neutron net-show testNet >> +---------------------------+--------------------------------------+ >> | Field | Value | >> +---------------------------+--------------------------------------+ >> | admin_state_up | True | >> | id | 47208beb-2801-4729-bc7b-6532717232fc | >> | name | testNet | >> | provider:network_type | local | >> | provider:physical_network | | >> | provider:segmentation_id | | >> | router:external | False | >> | shared | False | >> | status | ACTIVE | >> | subnets | | >> | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d | >> +---------------------------+--------------------------------------+ >> >> nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic >> net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1 >> >> Here is the piece of code which generated this exception >> >> nova/network/neutronv2/api.py >> >> if (security_groups and not ( >> network['subnets'] >> and network.get('port_security_enabled', True))): >> >> raise exception.SecurityGroupCannotBeApplied() >> >> >> Can someone please explain why do we need this check? >> > > Hi Kanthi, > > We need this check because because in order to enforce security groups the > port needs to have an ip_address (i.e: network needs a subnet) since > Security groups only map to L3/4 headers. Today, nova automatically adds a > default security group to all instances when booted. Hopefully we can punt > this task off to neutron in this release by moving the port-creation up on > the stack to nova-api instead of nova-compute though this isn't the case > right now. > > Aaron > >> >> To my understanding subnet is used for two purposes in terms of security >> groups >> 1. To allow dhcp traffic if dhcp is enabled on the subnet, example given >> below >> -A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp >> --sport 67 --dport 68 -j RETURN >> 2. To avoid ip spoof >> -A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP >> >> Can we remove this so that we can have guests which has nic with just MAC >> address, guest can configure its own ipaddress. Later if needed they can >> enable their own security rules via quantum api. >> >> _______________________________________________ >> 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 sriram at sriramhere.com Fri Nov 8 10:59:53 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Fri, 8 Nov 2013 18:59:53 +0800 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: References: Message-ID: Perfect. Rob - please send those emails out. Jeff and I will try to get this rolling, Safe travels! On Fri, Nov 8, 2013 at 3:02 PM, Jeffrey Walton wrote: > Hi Robert, > > I'd be happy to help out with spare cycles. > > Jeff > > On Wed, Nov 6, 2013 at 11:08 AM, Clark, Robert Graham > wrote: > > Hi All, > > > > I’m looking for help with the OpenStack Security Notes. I currently am > struggling to keep up with them and do all the other things I’m involved > in. Individually they don’t take that much time so with one or two people > helping out they wouldn’t be a significant burden. > > > > If anyone wants to run the management of this project and publishing the > OSSNs I’d be happy to support them in an editorial capacity. > > > > Cheers > > -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 > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmed.shohel at ericsson.com Mon Nov 11 13:31:34 2013 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Mon, 11 Nov 2013 15:31:34 +0200 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: References: Message-ID: <6158F534-FD36-4DDF-82E9-66CF898C953B@ericsson.com> Hi all, We can have a way forward discussion related to threat analysis in the next OSSG IRC meeting (this Thursday). Things we could discuss in the meeting e.g., - Threat analysis process in general - Work items: OpenStack project to target - Time frame - Team members - Way of working See you in the next meeting. Thanks, Shohel James Kempf kirjoitti Nov 7, 2013 kello 2:18 AM: > Hi Rob, > > Shohel (cc-ed) from Ericsson will be driving this. He will be setting up a chat/teleconference sometime late next week to get started. > > jak > >> -----Original Message----- >> From: Clark, Robert Graham [mailto:robert.clark at hp.com] >> Sent: Thursday, November 07, 2013 12:06 AM >> To: Sriram Subramanian; openstack-security at lists.openstack.org >> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >> >> Thanks for the great notes Sriram. >> >> I've made the 'how to contribute' part of the wiki more prominent: >> https://wiki.openstack.org/wiki/Security/How_To_Contribute >> >> To clarify, when we have the ball rolling on Threat Modelling for major >> projects, I can commit some security-architect resources to take part in >> the discussions. >> >> Cheers >> -Rob >> >> >> From: Sriram Subramanian >> > >> Date: Tuesday, 5 November 2013 14:24 >> To: "openstack-security at lists.openstack.org> security at lists.openstack.org>" > security at lists.openstack.org> security at lists.openstack.org>> >> Subject: [Openstack-security] OSSG Lunch Meeting Notes >> >> Some of the items discussed, followed by Action Items: >> >> 1) How can one get invovled - Wiki will direct >> 2) Where to pick up security tasks from? >> - wiki is the starting point >> - people sign up via mailing list >> >> >> 3) threat analysis >> - Static Analysis, Formal Verification on projects was proposed by >> James. >> - >> - static analysis on python is not very useful; whole projects will >> take a long time >> - >> 4) Threat modeling - >> - >> Action item (James Kempf) : share the results from Folsom for TM around >> Keystone >> >> - Rob can get resources towards this >> - get started with core or knowledgeable people >> - Ideally, Secuirty Reviews Per month per project. Review coordinator >> prepares the arch diagram before the review day >> >> 5) security review - HP's review process; what it translates to for >> OpenStack? >> >> 6) Attacker model >> - single or many >> - >> 7) Tracking the CVEs, publish in the format >> >> - Action Item: Daniel (Red Hat) to start discussin in the mailing list >> - Format: >> 8) >> Getting the word out (wiki, how to contribute, what is going on) >> - Minutes for the meet >> - Community Manager >> - Sprints: >> - Running the sprint >> >> Action Items: >> - Eric Windisch to Identify topic to set the sprint/ hackathon and time. >> >> Thanks, >> -Sriram >> >> _______________________________________________ >> 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: 3902 bytes Desc: not available URL: From robert.clark at hp.com Mon Nov 11 13:43:11 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 11 Nov 2013 13:43:11 +0000 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: <6158F534-FD36-4DDF-82E9-66CF898C953B@ericsson.com> Message-ID: I know a few people (me included) won’t be able to make the OSSG meeting this week. Is there any way we can follow this up by email? From: Abu Shohel Ahmed > Date: Monday, 11 November 2013 21:31 To: "openstack-security at lists.openstack.org" > Cc: Robert Clark >, Sriram Subramanian >, James Kempf > Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes Hi all, We can have a way forward discussion related to threat analysis in the next OSSG IRC meeting (this Thursday). Things we could discuss in the meeting e.g., - Threat analysis process in general - Work items: OpenStack project to target - Time frame - Team members - Way of working See you in the next meeting. Thanks, Shohel James Kempf kirjoitti Nov 7, 2013 kello 2:18 AM: Hi Rob, Shohel (cc-ed) from Ericsson will be driving this. He will be setting up a chat/teleconference sometime late next week to get started. jak -----Original Message----- From: Clark, Robert Graham [mailto:robert.clark at hp.com] Sent: Thursday, November 07, 2013 12:06 AM To: Sriram Subramanian; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes Thanks for the great notes Sriram. I've made the 'how to contribute' part of the wiki more prominent: https://wiki.openstack.org/wiki/Security/How_To_Contribute To clarify, when we have the ball rolling on Threat Modelling for major projects, I can commit some security-architect resources to take part in the discussions. Cheers -Rob From: Sriram Subramanian > Date: Tuesday, 5 November 2013 14:24 To: "openstack-security at lists.openstack.org>" >> Subject: [Openstack-security] OSSG Lunch Meeting Notes Some of the items discussed, followed by Action Items: 1) How can one get invovled - Wiki will direct 2) Where to pick up security tasks from? - wiki is the starting point - people sign up via mailing list 3) threat analysis - Static Analysis, Formal Verification on projects was proposed by James. - - static analysis on python is not very useful; whole projects will take a long time - 4) Threat modeling - - Action item (James Kempf) : share the results from Folsom for TM around Keystone - Rob can get resources towards this - get started with core or knowledgeable people - Ideally, Secuirty Reviews Per month per project. Review coordinator prepares the arch diagram before the review day 5) security review - HP's review process; what it translates to for OpenStack? 6) Attacker model - single or many - 7) Tracking the CVEs, publish in the format - Action Item: Daniel (Red Hat) to start discussin in the mailing list - Format: 8) Getting the word out (wiki, how to contribute, what is going on) - Minutes for the meet - Community Manager - Sprints: - Running the sprint Action Items: - Eric Windisch to Identify topic to set the sprint/ hackathon and time. Thanks, -Sriram _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From ahmed.shohel at ericsson.com Mon Nov 11 13:47:19 2013 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Mon, 11 Nov 2013 15:47:19 +0200 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: References: Message-ID: <2E70BD5A-9DA1-43A8-AEAA-9835F7E4CE55@ericsson.com> Hi Rob, Certainly, the meeting transcript should be available in https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity After the meeting, we will sent the meeting notes to the OSSG mailing list. …shohel Clark, Robert Graham kirjoitti Nov 11, 2013 kello 3:43 PM: > I know a few people (me included) won’t be able to make the OSSG meeting this week. > > Is there any way we can follow this up by email? > > From: Abu Shohel Ahmed > Date: Monday, 11 November 2013 21:31 > To: "openstack-security at lists.openstack.org" > Cc: Robert Clark , Sriram Subramanian , James Kempf > Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes > > Hi all, > > We can have a way forward discussion related to threat analysis in the next > OSSG IRC meeting (this Thursday). Things we could discuss in the > meeting e.g., > - Threat analysis process in general > - Work items: OpenStack project to target > - Time frame > - Team members > - Way of working > > See you in the next meeting. > > Thanks, > Shohel > > > > James Kempf kirjoitti Nov 7, 2013 kello 2:18 AM: > >> Hi Rob, >> >> Shohel (cc-ed) from Ericsson will be driving this. He will be setting up a chat/teleconference sometime late next week to get started. >> >> jak >> >>> -----Original Message----- >>> From: Clark, Robert Graham [mailto:robert.clark at hp.com] >>> Sent: Thursday, November 07, 2013 12:06 AM >>> To: Sriram Subramanian; openstack-security at lists.openstack.org >>> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >>> >>> Thanks for the great notes Sriram. >>> >>> I've made the 'how to contribute' part of the wiki more prominent: >>> https://wiki.openstack.org/wiki/Security/How_To_Contribute >>> >>> To clarify, when we have the ball rolling on Threat Modelling for major >>> projects, I can commit some security-architect resources to take part in >>> the discussions. >>> >>> Cheers >>> -Rob >>> >>> >>> From: Sriram Subramanian >>> > >>> Date: Tuesday, 5 November 2013 14:24 >>> To: "openstack-security at lists.openstack.org>> security at lists.openstack.org>" >> security at lists.openstack.org>> security at lists.openstack.org>> >>> Subject: [Openstack-security] OSSG Lunch Meeting Notes >>> >>> Some of the items discussed, followed by Action Items: >>> >>> 1) How can one get invovled - Wiki will direct >>> 2) Where to pick up security tasks from? >>> - wiki is the starting point >>> - people sign up via mailing list >>> >>> >>> 3) threat analysis >>> - Static Analysis, Formal Verification on projects was proposed by >>> James. >>> - >>> - static analysis on python is not very useful; whole projects will >>> take a long time >>> - >>> 4) Threat modeling - >>> - >>> Action item (James Kempf) : share the results from Folsom for TM around >>> Keystone >>> >>> - Rob can get resources towards this >>> - get started with core or knowledgeable people >>> - Ideally, Secuirty Reviews Per month per project. Review coordinator >>> prepares the arch diagram before the review day >>> >>> 5) security review - HP's review process; what it translates to for >>> OpenStack? >>> >>> 6) Attacker model >>> - single or many >>> - >>> 7) Tracking the CVEs, publish in the format >>> >>> - Action Item: Daniel (Red Hat) to start discussin in the mailing list >>> - Format: >>> 8) >>> Getting the word out (wiki, how to contribute, what is going on) >>> - Minutes for the meet >>> - Community Manager >>> - Sprints: >>> - Running the sprint >>> >>> Action Items: >>> - Eric Windisch to Identify topic to set the sprint/ hackathon and time. >>> >>> Thanks, >>> -Sriram >>> >>> _______________________________________________ >>> 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: 3902 bytes Desc: not available URL: From sriram at sriramhere.com Mon Nov 11 22:13:05 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 11 Nov 2013 14:13:05 -0800 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: <2E70BD5A-9DA1-43A8-AEAA-9835F7E4CE55@ericsson.com> References: <2E70BD5A-9DA1-43A8-AEAA-9835F7E4CE55@ericsson.com> Message-ID: Shohel, Could you please send any relevant links for those who are new to the threat model analysis process? Most of the links I used while at Microsoft are internal-only. thanks, -Sriram On Mon, Nov 11, 2013 at 5:47 AM, Abu Shohel Ahmed wrote: > Hi Rob, > > Certainly, the meeting transcript should be available in > https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity > After the meeting, we will sent the meeting notes to the OSSG mailing list. > > …shohel > > Clark, Robert Graham kirjoitti Nov 11, 2013 kello 3:43 PM: > > I know a few people (me included) won’t be able to make the OSSG meeting > this week. > > Is there any way we can follow this up by email? > > From: Abu Shohel Ahmed > Date: Monday, 11 November 2013 21:31 > To: "openstack-security at lists.openstack.org" < > openstack-security at lists.openstack.org> > Cc: Robert Clark , Sriram Subramanian < > sriram at sriramhere.com>, James Kempf > > Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes > > Hi all, > > We can have a way forward discussion related to threat analysis in the > next > OSSG IRC meeting (this Thursday). Things we could discuss in the > meeting e.g., > - Threat analysis process in general > - Work items: OpenStack project to target > - Time frame > - Team members > - Way of working > > See you in the next meeting. > > Thanks, > Shohel > > > > James Kempf kirjoitti Nov 7, 2013 kello 2:18 AM: > > Hi Rob, > > Shohel (cc-ed) from Ericsson will be driving this. He will be setting up a > chat/teleconference sometime late next week to get started. > > jak > > -----Original Message----- > > From: Clark, Robert Graham [mailto:robert.clark at hp.com > ] > > Sent: Thursday, November 07, 2013 12:06 AM > > To: Sriram Subramanian; openstack-security at lists.openstack.org > > Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes > > > Thanks for the great notes Sriram. > > > I've made the 'how to contribute' part of the wiki more prominent: > > https://wiki.openstack.org/wiki/Security/How_To_Contribute > > > To clarify, when we have the ball rolling on Threat Modelling for major > > projects, I can commit some security-architect resources to take part in > > the discussions. > > > Cheers > > -Rob > > > > From: Sriram Subramanian > > > >> > > Date: Tuesday, 5 November 2013 14:24 > > To: "openstack-security at lists.openstack.org > > security at lists.openstack.org>" > security at lists.openstack.org > > security at lists.openstack.org>> > > Subject: [Openstack-security] OSSG Lunch Meeting Notes > > > Some of the items discussed, followed by Action Items: > > > 1) How can one get invovled - Wiki will direct > > 2) Where to pick up security tasks from? > > - wiki is the starting point > > - people sign up via mailing list > > > > 3) threat analysis > > - Static Analysis, Formal Verification on projects was proposed by > > James. > > - > > - static analysis on python is not very useful; whole projects will > > take a long time > > - > > 4) Threat modeling - > > - > > Action item (James Kempf) : share the results from Folsom for TM around > > Keystone > > > - Rob can get resources towards this > > - get started with core or knowledgeable people > > - Ideally, Secuirty Reviews Per month per project. Review coordinator > > prepares the arch diagram before the review day > > > 5) security review - HP's review process; what it translates to for > > OpenStack? > > > 6) Attacker model > > - single or many > > - > > 7) Tracking the CVEs, publish in the format > > > - Action Item: Daniel (Red Hat) to start discussin in the mailing list > > - Format: > > 8) > > Getting the word out (wiki, how to contribute, what is going on) > > - Minutes for the meet > > - Community Manager > > - Sprints: > > - Running the sprint > > > Action Items: > > - Eric Windisch to Identify topic to set the sprint/ hackathon and time. > > > Thanks, > > -Sriram > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Nov 12 01:43:08 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 12 Nov 2013 01:43:08 -0000 Subject: [Openstack-security] [Bug 1246160] Re: shuffle method bring potential security issue References: <20131030014106.17323.98896.malonedeb@chaenomeles.canonical.com> Message-ID: <20131112014309.18776.15468.launchpad@wampee.canonical.com> ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Invalid ** 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/1246160 Title: shuffle method bring potential security issue Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Invalid Bug description: In the /nova/utils.py, line 328, the source code is below r.shuffle(password) This code is using shuffle method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246160/+subscriptions From fungi at yuggoth.org Tue Nov 12 01:44:40 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 12 Nov 2013 01:44:40 -0000 Subject: [Openstack-security] [Bug 1246159] Re: seed method brings potential security issue References: <20131030013717.19024.324.malonedeb@gac.canonical.com> Message-ID: <20131112014441.18776.16128.launchpad@wampee.canonical.com> ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Invalid ** 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/1246159 Title: seed method brings potential security issue Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Invalid Bug description: In the /cinder/transfer/apil.py, line 86, the source code is below random.seed(datetime.datetime.now().microsecond) This code is using seed method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246159/+subscriptions From fungi at yuggoth.org Tue Nov 12 01:45:23 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 12 Nov 2013 01:45:23 -0000 Subject: [Openstack-security] [Bug 1246158] Re: randint method brings potential security issue References: <20131030013205.19024.89786.malonedeb@gac.canonical.com> Message-ID: <20131112014524.24172.31920.launchpad@gac.canonical.com> ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Invalid ** 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/1246158 Title: randint method brings potential security issue Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Invalid Bug description: In the /keystone/contrib/oauth1/backends/sql.py, line 210, the source code is below token_dict['verifier'] = str(random.randint(1000, 9999)) This code is using randint method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246158/+subscriptions From fungi at yuggoth.org Tue Nov 12 18:06:57 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 12 Nov 2013 18:06:57 -0000 Subject: [Openstack-security] [Bug 1250101] Re: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands References: <20131111144450.24249.16674.malonedeb@gac.canonical.com> Message-ID: <20131112180657.10165.35356.malone@soybean.canonical.com> I too agree, so switched it to public with no associated advisory. ** Changed in: ossa Status: Incomplete => Invalid ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1250101 Title: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands Status in Cinder: New Status in Oslo - a Library of Common OpenStack Code: Invalid Status in OpenStack Security Advisories: Invalid Bug description: The patch https://github.com/openstack/cinder/commit/688c515b9d662486395d36c303ca599376a1dc0d added the find command to etc/cinder/rootwrap.d/volume.filters. This introduces a security hole as the find command is able to call exec, and so the cinder user can run any command as root. For example: vagrant at controller:~$ sudo -u cinder bash cinder at controller:~$ id uid=109(cinder) gid=115(cinder) groups=115(cinder) cinder at controller:~$ sudo /usr/bin/cinder-rootwrap /etc/cinder/rootwrap.conf find /etc/hosts -exec bash \; root at controller:~# id uid=0(root) gid=0(root) groups=0(root) I guess the way to fix this is to add a FindFilter to Oslo that rejects calls to find with the -exec or -execdir argument. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1250101/+subscriptions From hshaik at gmail.com Thu Nov 14 01:59:01 2013 From: hshaik at gmail.com (Hassan Shaik) Date: Wed, 13 Nov 2013 17:59:01 -0800 Subject: [Openstack-security] Enabling SSL/HTTPS for REST API Message-ID: Hello Openstack security experts, I am trying to enable SSL/HTTPS in openstack REST API for all services (nova/glance endpoint URL). However, I see the documentation to enable SSL on keystone service alone. http://docs.openstack.org/grizzly/openstack-compute/admin/content//keystone-ssl.html http://docs.openstack.org/developer/keystone/configuration.html 1. Am I missing something? Is SSL/HTTPS supported for nova/glance API too? 2. Also, when I try to enable SSL in keystone service, all nova/glance CLI fail to work after the change. And, the debug shows it is trying to make use of http even after enabling SSL. # nova --debug list REQ: curl -i *http*://openstack-ip:5000/v2.0/tokens -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "password": "admin_pass"}}}' Appreciate your help. Thanks, Hassan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Thu Nov 14 03:28:34 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 13 Nov 2013 19:28:34 -0800 Subject: [Openstack-security] Enabling SSL/HTTPS for REST API In-Reply-To: References: Message-ID: <52844362.8050904@redhat.com> On 11/13/2013 05:59 PM, Hassan Shaik wrote: > Hello Openstack security experts, > > I am trying to enable SSL/HTTPS in openstack REST API for all services > (nova/glance endpoint URL). However, I see the documentation to enable > SSL on keystone service alone. > > http://docs.openstack.org/grizzly/openstack-compute/admin/content//keystone-ssl.html > http://docs.openstack.org/developer/keystone/configuration.html > > 1. Am I missing something? Is SSL/HTTPS supported for nova/glance API too? > 2. Also, when I try to enable SSL in keystone service, all nova/glance > CLI fail to work after the change. And, the debug shows it is trying > to make use of http even after enabling SSL. Do you have "auth_protocol" set to http in the [keystone_authtoken] section of nova.conf? You can try commenting that out, or setting it to https. Thanks, -NGK > > # nova --debug list > > REQ: curl -i *http*://openstack-ip:5000/v2.0/tokens -X POST -H > "Content-Type: application/json" -H "Accept: application/json" -H > "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", > "passwordCredentials": {"username": "admin", "password": "admin_pass"}}}' > > Appreciate your help. > > Thanks, > Hassan > > > _______________________________________________ > 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 bdpayne at acm.org Thu Nov 14 06:00:04 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 13 Nov 2013 22:00:04 -0800 Subject: [Openstack-security] Enabling SSL/HTTPS for REST API In-Reply-To: References: Message-ID: Hassan, In a production setting, the preferred way to do this is with an SSL terminator. There are some details in the OpenStack Security Guide: http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html Cheers, -bryan On Wed, Nov 13, 2013 at 5:59 PM, Hassan Shaik wrote: > Hello Openstack security experts, > > I am trying to enable SSL/HTTPS in openstack REST API for all services > (nova/glance endpoint URL). However, I see the documentation to enable SSL > on keystone service alone. > > > http://docs.openstack.org/grizzly/openstack-compute/admin/content//keystone-ssl.html > http://docs.openstack.org/developer/keystone/configuration.html > > 1. Am I missing something? Is SSL/HTTPS supported for nova/glance API too? > 2. Also, when I try to enable SSL in keystone service, all nova/glance CLI > fail to work after the change. And, the debug shows it is trying to make > use of http even after enabling SSL. > > # nova --debug list > > REQ: curl -i *http*://openstack-ip:5000/v2.0/tokens -X POST -H > "Content-Type: application/json" -H "Accept: application/json" -H > "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", > "passwordCredentials": {"username": "admin", "password": "admin_pass"}}}' > > Appreciate your help. > > Thanks, > Hassan > > _______________________________________________ > 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 sriram at sriramhere.com Thu Nov 14 07:00:36 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Wed, 13 Nov 2013 23:00:36 -0800 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: References: Message-ID: Rob - any emails yet? Are we meeting tomorrow? On Fri, Nov 8, 2013 at 2:59 AM, Sriram Subramanian wrote: > Perfect. > > Rob - please send those emails out. Jeff and I will try to get this > rolling, Safe travels! > > > On Fri, Nov 8, 2013 at 3:02 PM, Jeffrey Walton wrote: > >> Hi Robert, >> >> I'd be happy to help out with spare cycles. >> >> Jeff >> >> On Wed, Nov 6, 2013 at 11:08 AM, Clark, Robert Graham >> wrote: >> > Hi All, >> > >> > I’m looking for help with the OpenStack Security Notes. I currently am >> struggling to keep up with them and do all the other things I’m involved >> in. Individually they don’t take that much time so with one or two people >> helping out they wouldn’t be a significant burden. >> > >> > If anyone wants to run the management of this project and publishing >> the OSSNs I’d be happy to support them in an editorial capacity. >> > >> > Cheers >> > -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 >> > > > > -- > Thanks, > -Sriram > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From hshaik at gmail.com Thu Nov 14 08:35:15 2013 From: hshaik at gmail.com (Hassan Shaik) Date: Thu, 14 Nov 2013 00:35:15 -0800 Subject: [Openstack-security] Enabling SSL/HTTPS for REST API In-Reply-To: References: Message-ID: Thanks Bryan & Nathan for your replies. Bryan, 1. does this mean SSL support is not present for nova/glance API directly? 2. Also, do we need to make use of SSL proxy terminator along with enabling SSL in keystone service (which seems to have SSL functionality implemented for this service)? 3. From the given link, I see the virtual host entries for 80 (Dashboard) and for 8447 (nova compute) ports. Do we need to add for other end point URL (excluding keystone service) as well, right? Regards, Hassan On Wed, Nov 13, 2013 at 10:00 PM, Bryan D. Payne wrote: > Hassan, > > In a production setting, the preferred way to do this is with an SSL > terminator. There are some details in the OpenStack Security Guide: > > http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html > > Cheers, > -bryan > > > > > On Wed, Nov 13, 2013 at 5:59 PM, Hassan Shaik wrote: > >> Hello Openstack security experts, >> >> I am trying to enable SSL/HTTPS in openstack REST API for all services >> (nova/glance endpoint URL). However, I see the documentation to enable SSL >> on keystone service alone. >> >> >> http://docs.openstack.org/grizzly/openstack-compute/admin/content//keystone-ssl.html >> http://docs.openstack.org/developer/keystone/configuration.html >> >> 1. Am I missing something? Is SSL/HTTPS supported for nova/glance API too? >> 2. Also, when I try to enable SSL in keystone service, all nova/glance >> CLI fail to work after the change. And, the debug shows it is trying to >> make use of http even after enabling SSL. >> >> # nova --debug list >> >> REQ: curl -i *http*://openstack-ip:5000/v2.0/tokens -X POST -H >> "Content-Type: application/json" -H "Accept: application/json" -H >> "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", >> "passwordCredentials": {"username": "admin", "password": "admin_pass"}}}' >> >> Appreciate your help. >> >> Thanks, >> Hassan >> >> _______________________________________________ >> 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 markmc at redhat.com Thu Nov 14 12:07:10 2013 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 14 Nov 2013 12:07:10 -0000 Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131114120713.24280.12255.launchpad@gac.canonical.com> ** Changed in: nova Importance: Undecided => High ** Changed in: oslo 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/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From ahmed.shohel at ericsson.com Thu Nov 14 17:40:36 2013 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Thu, 14 Nov 2013 19:40:36 +0200 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: References: <2E70BD5A-9DA1-43A8-AEAA-9835F7E4CE55@ericsson.com> Message-ID: <0D8F4B1D-EE90-4206-A411-91CA38CDE285@ericsson.com> Hi Sriram, To get started, I have create an Wiki Page. https://wiki.openstack.org/wiki/Security/Threat_Analysis Currently, consisting of a process diagram and links to relevant literature. The wiki page can be enriched together as the time goes and we proceed with our work. We have also linked in the Wiki, a security quick study report for Keystone Folsom release which James has promised in the Summit. The report itself is quite old now compared to the current keystone release. So the most important task now, is to define a common process through which we can do evaluation of OpenStack Components. See you in today's meeting. We can discuss about how we can proceed with this activity. Thanks, Shohel Sriram Subramanian kirjoitti Nov 12, 2013 kello 12:13 AM: > Shohel, > > Could you please send any relevant links for those who are new to the threat model analysis process? Most of the links I used while at Microsoft are internal-only. > > thanks, > -Sriram > > > On Mon, Nov 11, 2013 at 5:47 AM, Abu Shohel Ahmed wrote: > Hi Rob, > > Certainly, the meeting transcript should be available in https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity > After the meeting, we will sent the meeting notes to the OSSG mailing list. > > …shohel > > Clark, Robert Graham kirjoitti Nov 11, 2013 kello 3:43 PM: > >> I know a few people (me included) won’t be able to make the OSSG meeting this week. >> >> Is there any way we can follow this up by email? >> >> From: Abu Shohel Ahmed >> Date: Monday, 11 November 2013 21:31 >> To: "openstack-security at lists.openstack.org" >> Cc: Robert Clark , Sriram Subramanian , James Kempf >> >> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >> >> Hi all, >> >> We can have a way forward discussion related to threat analysis in the next >> OSSG IRC meeting (this Thursday). Things we could discuss in the >> meeting e.g., >> - Threat analysis process in general >> - Work items: OpenStack project to target >> - Time frame >> - Team members >> - Way of working >> >> See you in the next meeting. >> >> Thanks, >> Shohel >> >> >> >> James Kempf kirjoitti Nov 7, 2013 kello 2:18 AM: >> >>> Hi Rob, >>> >>> Shohel (cc-ed) from Ericsson will be driving this. He will be setting up a chat/teleconference sometime late next week to get started. >>> >>> jak >>> >>>> -----Original Message----- >>>> From: Clark, Robert Graham [mailto:robert.clark at hp.com] >>>> Sent: Thursday, November 07, 2013 12:06 AM >>>> To: Sriram Subramanian; openstack-security at lists.openstack.org >>>> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >>>> >>>> Thanks for the great notes Sriram. >>>> >>>> I've made the 'how to contribute' part of the wiki more prominent: >>>> https://wiki.openstack.org/wiki/Security/How_To_Contribute >>>> >>>> To clarify, when we have the ball rolling on Threat Modelling for major >>>> projects, I can commit some security-architect resources to take part in >>>> the discussions. >>>> >>>> Cheers >>>> -Rob >>>> >>>> >>>> From: Sriram Subramanian >>>> > >>>> Date: Tuesday, 5 November 2013 14:24 >>>> To: "openstack-security at lists.openstack.org>>> security at lists.openstack.org>" >>> security at lists.openstack.org>>> security at lists.openstack.org>> >>>> Subject: [Openstack-security] OSSG Lunch Meeting Notes >>>> >>>> Some of the items discussed, followed by Action Items: >>>> >>>> 1) How can one get invovled - Wiki will direct >>>> 2) Where to pick up security tasks from? >>>> - wiki is the starting point >>>> - people sign up via mailing list >>>> >>>> >>>> 3) threat analysis >>>> - Static Analysis, Formal Verification on projects was proposed by >>>> James. >>>> - >>>> - static analysis on python is not very useful; whole projects will >>>> take a long time >>>> - >>>> 4) Threat modeling - >>>> - >>>> Action item (James Kempf) : share the results from Folsom for TM around >>>> Keystone >>>> >>>> - Rob can get resources towards this >>>> - get started with core or knowledgeable people >>>> - Ideally, Secuirty Reviews Per month per project. Review coordinator >>>> prepares the arch diagram before the review day >>>> >>>> 5) security review - HP's review process; what it translates to for >>>> OpenStack? >>>> >>>> 6) Attacker model >>>> - single or many >>>> - >>>> 7) Tracking the CVEs, publish in the format >>>> >>>> - Action Item: Daniel (Red Hat) to start discussin in the mailing list >>>> - Format: >>>> 8) >>>> Getting the word out (wiki, how to contribute, what is going on) >>>> - Minutes for the meet >>>> - Community Manager >>>> - Sprints: >>>> - Running the sprint >>>> >>>> Action Items: >>>> - Eric Windisch to Identify topic to set the sprint/ hackathon and time. >>>> >>>> Thanks, >>>> -Sriram >>>> >>>> _______________________________________________ >>>> Openstack-security mailing list >>>> Openstack-security at lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > > > > > -- > Thanks, > -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3902 bytes Desc: not available URL: From sriram at sriramhere.com Thu Nov 14 19:04:49 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 14 Nov 2013 11:04:49 -0800 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: <0D8F4B1D-EE90-4206-A411-91CA38CDE285@ericsson.com> References: <2E70BD5A-9DA1-43A8-AEAA-9835F7E4CE55@ericsson.com> <0D8F4B1D-EE90-4206-A411-91CA38CDE285@ericsson.com> Message-ID: Thanks Shohel, I am at the IRC #openstack-meeting. Anyone out there? thanks, -sriram On Thu, Nov 14, 2013 at 9:40 AM, Abu Shohel Ahmed wrote: > Hi Sriram, > > To get started, I have create an Wiki Page. > > https://wiki.openstack.org/wiki/Security/Threat_Analysis > > Currently, consisting of a process diagram and links to relevant > literature. > The wiki page can be enriched together as the time goes and we proceed > with our work. > > We have also linked in the Wiki, a security quick study report for > Keystone Folsom > release which James has promised in the Summit. The report itself is > quite old now > compared to the current keystone release. So the most important task now, > is to define > a common process through which we can do evaluation of OpenStack > Components. > > See you in today's meeting. We can discuss about how we can proceed with > this > activity. > > Thanks, > Shohel > > > Sriram Subramanian kirjoitti Nov 12, 2013 kello 12:13 AM: > > Shohel, > > Could you please send any relevant links for those who are new to the > threat model analysis process? Most of the links I used while at Microsoft > are internal-only. > > thanks, > -Sriram > > > On Mon, Nov 11, 2013 at 5:47 AM, Abu Shohel Ahmed < > ahmed.shohel at ericsson.com> wrote: > >> Hi Rob, >> >> Certainly, the meeting transcript should be available in >> https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity >> After the meeting, we will sent the meeting notes to the OSSG mailing >> list. >> >> …shohel >> >> Clark, Robert Graham kirjoitti Nov 11, 2013 kello 3:43 PM: >> >> I know a few people (me included) won’t be able to make the OSSG >> meeting this week. >> >> Is there any way we can follow this up by email? >> >> From: Abu Shohel Ahmed >> Date: Monday, 11 November 2013 21:31 >> To: "openstack-security at lists.openstack.org" < >> openstack-security at lists.openstack.org> >> Cc: Robert Clark , Sriram Subramanian < >> sriram at sriramhere.com>, James Kempf >> >> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >> >> Hi all, >> >> We can have a way forward discussion related to threat analysis in the >> next >> OSSG IRC meeting (this Thursday). Things we could discuss in the >> meeting e.g., >> - Threat analysis process in general >> - Work items: OpenStack project to target >> - Time frame >> - Team members >> - Way of working >> >> See you in the next meeting. >> >> Thanks, >> Shohel >> >> >> >> James Kempf kirjoitti Nov 7, 2013 kello 2:18 AM: >> >> Hi Rob, >> >> Shohel (cc-ed) from Ericsson will be driving this. He will be setting up >> a chat/teleconference sometime late next week to get started. >> >> jak >> >> -----Original Message----- >> >> From: Clark, Robert Graham [mailto:robert.clark at hp.com >> ] >> >> Sent: Thursday, November 07, 2013 12:06 AM >> >> To: Sriram Subramanian; openstack-security at lists.openstack.org >> >> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >> >> >> Thanks for the great notes Sriram. >> >> >> I've made the 'how to contribute' part of the wiki more prominent: >> >> https://wiki.openstack.org/wiki/Security/How_To_Contribute >> >> >> To clarify, when we have the ball rolling on Threat Modelling for major >> >> projects, I can commit some security-architect resources to take part in >> >> the discussions. >> >> >> Cheers >> >> -Rob >> >> >> >> From: Sriram Subramanian >> >> >> >> >> >> Date: Tuesday, 5 November 2013 14:24 >> >> To: "openstack-security at lists.openstack.org >> >> security at lists.openstack.org>" > >> security at lists.openstack.org >> >> security at lists.openstack.org>> >> >> Subject: [Openstack-security] OSSG Lunch Meeting Notes >> >> >> Some of the items discussed, followed by Action Items: >> >> >> 1) How can one get invovled - Wiki will direct >> >> 2) Where to pick up security tasks from? >> >> - wiki is the starting point >> >> - people sign up via mailing list >> >> >> >> 3) threat analysis >> >> - Static Analysis, Formal Verification on projects was proposed by >> >> James. >> >> - >> >> - static analysis on python is not very useful; whole projects will >> >> take a long time >> >> - >> >> 4) Threat modeling - >> >> - >> >> Action item (James Kempf) : share the results from Folsom for TM around >> >> Keystone >> >> >> - Rob can get resources towards this >> >> - get started with core or knowledgeable people >> >> - Ideally, Secuirty Reviews Per month per project. Review coordinator >> >> prepares the arch diagram before the review day >> >> >> 5) security review - HP's review process; what it translates to for >> >> OpenStack? >> >> >> 6) Attacker model >> >> - single or many >> >> - >> >> 7) Tracking the CVEs, publish in the format >> >> >> - Action Item: Daniel (Red Hat) to start discussin in the mailing list >> >> - Format: >> >> 8) >> >> Getting the word out (wiki, how to contribute, what is going on) >> >> - Minutes for the meet >> >> - Community Manager >> >> - Sprints: >> >> - Running the sprint >> >> >> Action Items: >> >> - Eric Windisch to Identify topic to set the sprint/ hackathon and time. >> >> >> Thanks, >> >> -Sriram >> >> >> _______________________________________________ >> >> Openstack-security mailing list >> >> Openstack-security at lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> >> >> > > > -- > Thanks, > -Sriram > > > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Nov 14 20:05:53 2013 From: ayoung at redhat.com (Adam Young) Date: Thu, 14 Nov 2013 15:05:53 -0500 Subject: [Openstack-security] Enabling SSL/HTTPS for REST API In-Reply-To: References: Message-ID: <52852D21.2080903@redhat.com> On 11/13/2013 08:59 PM, Hassan Shaik wrote: > Hello Openstack security experts, > > I am trying to enable SSL/HTTPS in openstack REST API for all services > (nova/glance endpoint URL). However, I see the documentation to enable > SSL on keystone service alone. > > http://docs.openstack.org/grizzly/openstack-compute/admin/content//keystone-ssl.html > http://docs.openstack.org/developer/keystone/configuration.html > > 1. Am I missing something? Is SSL/HTTPS supported for nova/glance API too? http://andymc-stack.co.uk/2013/07/apache2-mod_wsgi-openstack-pt-2-nova-api-os-compute-nova-api-ec2/ http://andymc-stack.co.uk/2013/07/apache2-mod_wsgi-openstack-pt-3-glance-api-glance-registry/#comment-23 People have suggested that the glance one is broken, and comes up Read Only. I suspect SELinux issues there > 2. Also, when I try to enable SSL in keystone service, all nova/glance > CLI fail to work after the change. And, the debug shows it is trying > to make use of http even after enabling SSL. > > # nova --debug list > > REQ: curl -i *http*://openstack-ip:5000/v2.0/tokens -X POST -H > "Content-Type: application/json" -H "Accept: application/json" -H > "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", > "passwordCredentials": {"username": "admin", "password": "admin_pass"}}}' Need to set the Auth endpoint to https when registering it with Keystone. > > Appreciate your help. > > Thanks, > Hassan > > > _______________________________________________ > 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 hshaik at gmail.com Fri Nov 15 01:15:25 2013 From: hshaik at gmail.com (Hassan Shaik) Date: Thu, 14 Nov 2013 17:15:25 -0800 Subject: [Openstack-security] Enabling SSL/HTTPS for REST API In-Reply-To: References: Message-ID: Also, Can the SSL proxy terminator (based on Apache httpd) reside on the same controller box? I think, httpd wont be able to listen on same virtual host ports. In that case, it should be on different server. If someone have tried this in their setups, please share the details on how you set this up. Appreciate your help. Regards, Hassan On Thu, Nov 14, 2013 at 12:35 AM, Hassan Shaik wrote: > Thanks Bryan & Nathan for your replies. > > Bryan, > 1. does this mean SSL support is not present for nova/glance API directly? > 2. Also, do we need to make use of SSL proxy terminator along with > enabling SSL in keystone service (which seems to have SSL functionality > implemented for this service)? > 3. From the given link, I see the virtual host entries for 80 (Dashboard) > and for 8447 (nova compute) ports. Do we need to add for other end point > URL (excluding keystone service) as well, right? > > > > Regards, > Hassan > > > On Wed, Nov 13, 2013 at 10:00 PM, Bryan D. Payne wrote: > >> Hassan, >> >> In a production setting, the preferred way to do this is with an SSL >> terminator. There are some details in the OpenStack Security Guide: >> >> http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html >> >> Cheers, >> -bryan >> >> >> >> >> On Wed, Nov 13, 2013 at 5:59 PM, Hassan Shaik wrote: >> >>> Hello Openstack security experts, >>> >>> I am trying to enable SSL/HTTPS in openstack REST API for all services >>> (nova/glance endpoint URL). However, I see the documentation to enable SSL >>> on keystone service alone. >>> >>> >>> http://docs.openstack.org/grizzly/openstack-compute/admin/content//keystone-ssl.html >>> http://docs.openstack.org/developer/keystone/configuration.html >>> >>> 1. Am I missing something? Is SSL/HTTPS supported for nova/glance API >>> too? >>> 2. Also, when I try to enable SSL in keystone service, all nova/glance >>> CLI fail to work after the change. And, the debug shows it is trying to >>> make use of http even after enabling SSL. >>> >>> # nova --debug list >>> >>> REQ: curl -i *http*://openstack-ip:5000/v2.0/tokens -X POST -H >>> "Content-Type: application/json" -H "Accept: application/json" -H >>> "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", >>> "passwordCredentials": {"username": "admin", "password": "admin_pass"}}}' >>> >>> Appreciate your help. >>> >>> Thanks, >>> Hassan >>> >>> _______________________________________________ >>> 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 bdpayne at acm.org Fri Nov 15 04:51:39 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 14 Nov 2013 20:51:39 -0800 Subject: [Openstack-security] Enabling SSL/HTTPS for REST API In-Reply-To: References: Message-ID: With the terminator, you would have apache (or whatever terminator you choose) listen on the user facing interface / port. And then it can pass off the connection to the service over localhost or a unix socket or wsgi. -bryan On Thu, Nov 14, 2013 at 5:15 PM, Hassan Shaik wrote: > Also, Can the SSL proxy terminator (based on Apache httpd) reside on the > same controller box? I think, httpd wont be able to listen on same virtual > host ports. In that case, it should be on different server. If someone have > tried this in their setups, please share the details on how you set this up. > > Appreciate your help. > > Regards, > Hassan > > > On Thu, Nov 14, 2013 at 12:35 AM, Hassan Shaik wrote: > >> Thanks Bryan & Nathan for your replies. >> >> Bryan, >> 1. does this mean SSL support is not present for nova/glance API >> directly? >> 2. Also, do we need to make use of SSL proxy terminator along with >> enabling SSL in keystone service (which seems to have SSL functionality >> implemented for this service)? >> 3. From the given link, I see the virtual host entries for 80 (Dashboard) >> and for 8447 (nova compute) ports. Do we need to add for other end point >> URL (excluding keystone service) as well, right? >> >> >> >> Regards, >> Hassan >> >> >> On Wed, Nov 13, 2013 at 10:00 PM, Bryan D. Payne wrote: >> >>> Hassan, >>> >>> In a production setting, the preferred way to do this is with an SSL >>> terminator. There are some details in the OpenStack Security Guide: >>> >>> >>> http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html >>> >>> Cheers, >>> -bryan >>> >>> >>> >>> >>> On Wed, Nov 13, 2013 at 5:59 PM, Hassan Shaik wrote: >>> >>>> Hello Openstack security experts, >>>> >>>> I am trying to enable SSL/HTTPS in openstack REST API for all services >>>> (nova/glance endpoint URL). However, I see the documentation to enable SSL >>>> on keystone service alone. >>>> >>>> >>>> http://docs.openstack.org/grizzly/openstack-compute/admin/content//keystone-ssl.html >>>> http://docs.openstack.org/developer/keystone/configuration.html >>>> >>>> 1. Am I missing something? Is SSL/HTTPS supported for nova/glance API >>>> too? >>>> 2. Also, when I try to enable SSL in keystone service, all nova/glance >>>> CLI fail to work after the change. And, the debug shows it is trying to >>>> make use of http even after enabling SSL. >>>> >>>> # nova --debug list >>>> >>>> REQ: curl -i *http*://openstack-ip:5000/v2.0/tokens -X POST -H >>>> "Content-Type: application/json" -H "Accept: application/json" -H >>>> "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", >>>> "passwordCredentials": {"username": "admin", "password": "admin_pass"}}}' >>>> >>>> Appreciate your help. >>>> >>>> Thanks, >>>> Hassan >>>> >>>> _______________________________________________ >>>> 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 ahmed.shohel at ericsson.com Fri Nov 15 09:44:01 2013 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Fri, 15 Nov 2013 11:44:01 +0200 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: References: <2E70BD5A-9DA1-43A8-AEAA-9835F7E4CE55@ericsson.com> <0D8F4B1D-EE90-4206-A411-91CA38CDE285@ericsson.com> Message-ID: <050F8A8C-59F1-4E08-B0E4-2105674CF33A@ericsson.com> Hi all, Yesterday, we had a good introduction discussion related to this work. I have added more content i.e., an Example Threat analysis work. in the Wiki page. https://wiki.openstack.org/wiki/Security/Threat_Analysis To get the momentum, we should first discuss who are interested to work on this activity. Then we can form a small team to make things faster and concentrated work. Please drop an email, if you are interested. From Ericsson side, we will have more people working in this activity ( e.g., Mats Näslund and Bengt Sahlin (CC:ed)). I will be on vacation for next five weeks, during this time Bengt Sahlin will organize discussion and way forward for this activity from our side. Thanks, Shohel Sriram Subramanian kirjoitti Nov 14, 2013 kello 9:04 PM: > Thanks Shohel, > > I am at the IRC #openstack-meeting. Anyone out there? > > thanks, > -sriram > > > On Thu, Nov 14, 2013 at 9:40 AM, Abu Shohel Ahmed wrote: > Hi Sriram, > > To get started, I have create an Wiki Page. > > https://wiki.openstack.org/wiki/Security/Threat_Analysis > > Currently, consisting of a process diagram and links to relevant literature. > The wiki page can be enriched together as the time goes and we proceed with our work. > > We have also linked in the Wiki, a security quick study report for Keystone Folsom > release which James has promised in the Summit. The report itself is quite old now > compared to the current keystone release. So the most important task now, is to define > a common process through which we can do evaluation of OpenStack Components. > > See you in today's meeting. We can discuss about how we can proceed with this > activity. > > Thanks, > Shohel > > > Sriram Subramanian kirjoitti Nov 12, 2013 kello 12:13 AM: > >> Shohel, >> >> Could you please send any relevant links for those who are new to the threat model analysis process? Most of the links I used while at Microsoft are internal-only. >> >> thanks, >> -Sriram >> >> >> On Mon, Nov 11, 2013 at 5:47 AM, Abu Shohel Ahmed wrote: >> Hi Rob, >> >> Certainly, the meeting transcript should be available in https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity >> After the meeting, we will sent the meeting notes to the OSSG mailing list. >> >> …shohel >> >> Clark, Robert Graham kirjoitti Nov 11, 2013 kello 3:43 PM: >> >>> I know a few people (me included) won’t be able to make the OSSG meeting this week. >>> >>> Is there any way we can follow this up by email? >>> >>> From: Abu Shohel Ahmed >>> Date: Monday, 11 November 2013 21:31 >>> To: "openstack-security at lists.openstack.org" >>> Cc: Robert Clark , Sriram Subramanian , James Kempf >>> >>> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >>> >>> Hi all, >>> >>> We can have a way forward discussion related to threat analysis in the next >>> OSSG IRC meeting (this Thursday). Things we could discuss in the >>> meeting e.g., >>> - Threat analysis process in general >>> - Work items: OpenStack project to target >>> - Time frame >>> - Team members >>> - Way of working >>> >>> See you in the next meeting. >>> >>> Thanks, >>> Shohel >>> >>> >>> >>> James Kempf kirjoitti Nov 7, 2013 kello 2:18 AM: >>> >>>> Hi Rob, >>>> >>>> Shohel (cc-ed) from Ericsson will be driving this. He will be setting up a chat/teleconference sometime late next week to get started. >>>> >>>> jak >>>> >>>>> -----Original Message----- >>>>> From: Clark, Robert Graham [mailto:robert.clark at hp.com] >>>>> Sent: Thursday, November 07, 2013 12:06 AM >>>>> To: Sriram Subramanian; openstack-security at lists.openstack.org >>>>> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >>>>> >>>>> Thanks for the great notes Sriram. >>>>> >>>>> I've made the 'how to contribute' part of the wiki more prominent: >>>>> https://wiki.openstack.org/wiki/Security/How_To_Contribute >>>>> >>>>> To clarify, when we have the ball rolling on Threat Modelling for major >>>>> projects, I can commit some security-architect resources to take part in >>>>> the discussions. >>>>> >>>>> Cheers >>>>> -Rob >>>>> >>>>> >>>>> From: Sriram Subramanian >>>>> > >>>>> Date: Tuesday, 5 November 2013 14:24 >>>>> To: "openstack-security at lists.openstack.org>>>> security at lists.openstack.org>" >>>> security at lists.openstack.org>>>> security at lists.openstack.org>> >>>>> Subject: [Openstack-security] OSSG Lunch Meeting Notes >>>>> >>>>> Some of the items discussed, followed by Action Items: >>>>> >>>>> 1) How can one get invovled - Wiki will direct >>>>> 2) Where to pick up security tasks from? >>>>> - wiki is the starting point >>>>> - people sign up via mailing list >>>>> >>>>> >>>>> 3) threat analysis >>>>> - Static Analysis, Formal Verification on projects was proposed by >>>>> James. >>>>> - >>>>> - static analysis on python is not very useful; whole projects will >>>>> take a long time >>>>> - >>>>> 4) Threat modeling - >>>>> - >>>>> Action item (James Kempf) : share the results from Folsom for TM around >>>>> Keystone >>>>> >>>>> - Rob can get resources towards this >>>>> - get started with core or knowledgeable people >>>>> - Ideally, Secuirty Reviews Per month per project. Review coordinator >>>>> prepares the arch diagram before the review day >>>>> >>>>> 5) security review - HP's review process; what it translates to for >>>>> OpenStack? >>>>> >>>>> 6) Attacker model >>>>> - single or many >>>>> - >>>>> 7) Tracking the CVEs, publish in the format >>>>> >>>>> - Action Item: Daniel (Red Hat) to start discussin in the mailing list >>>>> - Format: >>>>> 8) >>>>> Getting the word out (wiki, how to contribute, what is going on) >>>>> - Minutes for the meet >>>>> - Community Manager >>>>> - Sprints: >>>>> - Running the sprint >>>>> >>>>> Action Items: >>>>> - Eric Windisch to Identify topic to set the sprint/ hackathon and time. >>>>> >>>>> Thanks, >>>>> -Sriram >>>>> >>>>> _______________________________________________ >>>>> Openstack-security mailing list >>>>> Openstack-security at lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >> >> >> >> >> -- >> Thanks, >> -Sriram > > > > > -- > Thanks, > -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3902 bytes Desc: not available URL: From thierry.carrez+lp at gmail.com Fri Nov 15 11:05:37 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 15 Nov 2013 11:05:37 -0000 Subject: [Openstack-security] [Bug 1236125] Re: PowerVM driver ignores host keys References: <20131007013845.5908.7483.malonedeb@soybean.canonical.com> Message-ID: <20131115110537.19741.6270.malone@chaenomeles.canonical.com> @eric: that would be awesome. For each project someone needs to go over all internal communications and fix them all. Once we get to a good baseline for a project we can declare the management network hostile and consider any regression in that area as a vulnerability. ** 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/1236125 Title: PowerVM driver ignores host keys Status in OpenStack Compute (Nova): New Bug description: Nova's PowerVM driver is currently set to AutoAdd any host key over SSH. As per the SSH protocol, host key fingerprints should be verified either by comparing with known hosts (like through a known_hosts file) or having a person verify its the host they wish to connect with. In particular, https://github.com/openstack/nova/blob/master/nova/virt/powervm/common.py uses paramiko.AutoAddPolicy() which will automatically accept any host key. Doing so allows Nova to be susceptible to a man-in-the-middle. There should instead be an option in nova.conf to specify a known_hosts file and the paramiko policy to use. That way someone could set the policy to Reject and specify a file with known_hosts which are acceptable. Communication therefore would never occur to unknown hosts and allow a potential release of a user/pwd. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1236125/+subscriptions From fungi at yuggoth.org Fri Nov 15 15:55:37 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 15 Nov 2013 15:55:37 -0000 Subject: [Openstack-security] [Bug 1251518] Re: Glance needs a config option to limit the number of additional image properties References: <20131115051405.19741.28287.malonedeb@chaenomeles.canonical.com> Message-ID: <20131115155537.27582.99169.malone@gac.canonical.com> I agree, this falls to operator best practices and public service hardening issues. Contrary to popular belief, private security bugs get less attention and generally take longer to fix than regular public bugs (due to the strictly limited set of people allowed to see and work through them). ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251518 Title: Glance needs a config option to limit the number of additional image properties Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Advisories: Invalid Bug description: Impact: The vulnerability occurs when glance is directly exposed to users. If users can only hit glance via the compute API, then no vulnerability. Nova has a configuration option quota_metadata_items (default value 128) that's documented to limit the number of metadata items that can be put on an instance. (I verified that it also applies to image metadata using a havana devstack.) Glance does not appear to have such an option (I was able to put >500 additional properties on an image using the glanceclient). I think this is a DOS attack vector, since someone could fill the glance database with garbage and slow everything down. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1251518/+subscriptions From fungi at yuggoth.org Fri Nov 15 16:03:23 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 15 Nov 2013 16:03:23 -0000 Subject: [Openstack-security] [Bug 1251518] Re: Glance needs a config option to limit the number of additional image properties References: <20131115051405.19741.28287.malonedeb@chaenomeles.canonical.com> Message-ID: <20131115160326.10162.73537.launchpad@soybean.canonical.com> ** Changed in: ossa Status: Incomplete => Invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251518 Title: Glance needs a config option to limit the number of additional image properties Status in OpenStack Image Registry and Delivery Service (Glance): Triaged Status in OpenStack Security Advisories: Invalid Bug description: Impact: The vulnerability occurs when glance is directly exposed to users. If users can only hit glance via the compute API, then no vulnerability. Nova has a configuration option quota_metadata_items (default value 128) that's documented to limit the number of metadata items that can be put on an instance. (I verified that it also applies to image metadata using a havana devstack.) Glance does not appear to have such an option (I was able to put >500 additional properties on an image using the glanceclient). I think this is a DOS attack vector, since someone could fill the glance database with garbage and slow everything down. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1251518/+subscriptions From sriram at sriramhere.com Sat Nov 16 05:40:12 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Fri, 15 Nov 2013 21:40:12 -0800 Subject: [Openstack-security] OSSG Lunch Meeting Notes In-Reply-To: <050F8A8C-59F1-4E08-B0E4-2105674CF33A@ericsson.com> References: <2E70BD5A-9DA1-43A8-AEAA-9835F7E4CE55@ericsson.com> <0D8F4B1D-EE90-4206-A411-91CA38CDE285@ericsson.com> <050F8A8C-59F1-4E08-B0E4-2105674CF33A@ericsson.com> Message-ID: Shohel, Thanks for the wiki entry and introducing Bengt and Mats. Hello there! I am definitely interested in this work. Enjoy your vacation, looking forward to working with Bengt thanks, -Sriram On Fri, Nov 15, 2013 at 1:44 AM, Abu Shohel Ahmed wrote: > Hi all, > > Yesterday, we had a good introduction discussion related to this work. > I have added more content i.e., an Example Threat analysis work. > in the Wiki page. > > https://wiki.openstack.org/wiki/Security/Threat_Analysis > > To get the momentum, we should first discuss who are interested to work > on this activity. Then we can form a small team to make things faster and > concentrated work. Please drop an email, if you are interested. > > From Ericsson side, we will have more people working in this activity ( > e.g., > Mats Näslund and Bengt Sahlin (CC:ed)). I will be on vacation for next > five weeks, > during this time Bengt Sahlin will organize discussion and way forward > for this activity from our side. > > Thanks, > Shohel > > > Sriram Subramanian kirjoitti Nov 14, 2013 kello 9:04 PM: > > Thanks Shohel, > > I am at the IRC #openstack-meeting. Anyone out there? > > thanks, > -sriram > > > On Thu, Nov 14, 2013 at 9:40 AM, Abu Shohel Ahmed < > ahmed.shohel at ericsson.com> wrote: > >> Hi Sriram, >> >> To get started, I have create an Wiki Page. >> >> https://wiki.openstack.org/wiki/Security/Threat_Analysis >> >> Currently, consisting of a process diagram and links to relevant >> literature. >> The wiki page can be enriched together as the time goes and we proceed >> with our work. >> >> We have also linked in the Wiki, a security quick study report for >> Keystone Folsom >> release which James has promised in the Summit. The report itself is >> quite old now >> compared to the current keystone release. So the most important task now, >> is to define >> a common process through which we can do evaluation of OpenStack >> Components. >> >> See you in today's meeting. We can discuss about how we can proceed with >> this >> activity. >> >> Thanks, >> Shohel >> >> >> Sriram Subramanian kirjoitti Nov 12, 2013 kello 12:13 AM: >> >> Shohel, >> >> Could you please send any relevant links for those who are new to the >> threat model analysis process? Most of the links I used while at Microsoft >> are internal-only. >> >> thanks, >> -Sriram >> >> >> On Mon, Nov 11, 2013 at 5:47 AM, Abu Shohel Ahmed < >> ahmed.shohel at ericsson.com> wrote: >> >>> Hi Rob, >>> >>> Certainly, the meeting transcript should be available in >>> https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity >>> After the meeting, we will sent the meeting notes to the OSSG mailing >>> list. >>> >>> …shohel >>> >>> Clark, Robert Graham kirjoitti Nov 11, 2013 kello 3:43 PM: >>> >>> I know a few people (me included) won’t be able to make the OSSG >>> meeting this week. >>> >>> Is there any way we can follow this up by email? >>> >>> From: Abu Shohel Ahmed >>> Date: Monday, 11 November 2013 21:31 >>> To: "openstack-security at lists.openstack.org" < >>> openstack-security at lists.openstack.org> >>> Cc: Robert Clark , Sriram Subramanian < >>> sriram at sriramhere.com>, James Kempf >>> >>> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >>> >>> Hi all, >>> >>> We can have a way forward discussion related to threat analysis in >>> the next >>> OSSG IRC meeting (this Thursday). Things we could discuss in the >>> meeting e.g., >>> - Threat analysis process in general >>> - Work items: OpenStack project to target >>> - Time frame >>> - Team members >>> - Way of working >>> >>> See you in the next meeting. >>> >>> Thanks, >>> Shohel >>> >>> >>> >>> James Kempf kirjoitti Nov 7, 2013 kello 2:18 AM: >>> >>> Hi Rob, >>> >>> Shohel (cc-ed) from Ericsson will be driving this. He will be setting up >>> a chat/teleconference sometime late next week to get started. >>> >>> jak >>> >>> -----Original Message----- >>> >>> From: Clark, Robert Graham [mailto:robert.clark at hp.com >>> ] >>> >>> Sent: Thursday, November 07, 2013 12:06 AM >>> >>> To: Sriram Subramanian; openstack-security at lists.openstack.org >>> >>> Subject: Re: [Openstack-security] OSSG Lunch Meeting Notes >>> >>> >>> Thanks for the great notes Sriram. >>> >>> >>> I've made the 'how to contribute' part of the wiki more prominent: >>> >>> https://wiki.openstack.org/wiki/Security/How_To_Contribute >>> >>> >>> To clarify, when we have the ball rolling on Threat Modelling for major >>> >>> projects, I can commit some security-architect resources to take part in >>> >>> the discussions. >>> >>> >>> Cheers >>> >>> -Rob >>> >>> >>> >>> From: Sriram Subramanian >>> >>> >>> >> >>> >>> Date: Tuesday, 5 November 2013 14:24 >>> >>> To: "openstack-security at lists.openstack.org >>> >>> security at lists.openstack.org>" >> >>> security at lists.openstack.org >>> >>> security at lists.openstack.org>> >>> >>> Subject: [Openstack-security] OSSG Lunch Meeting Notes >>> >>> >>> Some of the items discussed, followed by Action Items: >>> >>> >>> 1) How can one get invovled - Wiki will direct >>> >>> 2) Where to pick up security tasks from? >>> >>> - wiki is the starting point >>> >>> - people sign up via mailing list >>> >>> >>> >>> 3) threat analysis >>> >>> - Static Analysis, Formal Verification on projects was proposed by >>> >>> James. >>> >>> - >>> >>> - static analysis on python is not very useful; whole projects will >>> >>> take a long time >>> >>> - >>> >>> 4) Threat modeling - >>> >>> - >>> >>> Action item (James Kempf) : share the results from Folsom for TM around >>> >>> Keystone >>> >>> >>> - Rob can get resources towards this >>> >>> - get started with core or knowledgeable people >>> >>> - Ideally, Secuirty Reviews Per month per project. Review coordinator >>> >>> prepares the arch diagram before the review day >>> >>> >>> 5) security review - HP's review process; what it translates to for >>> >>> OpenStack? >>> >>> >>> 6) Attacker model >>> >>> - single or many >>> >>> - >>> >>> 7) Tracking the CVEs, publish in the format >>> >>> >>> - Action Item: Daniel (Red Hat) to start discussin in the mailing list >>> >>> - Format: >>> >>> 8) >>> >>> Getting the word out (wiki, how to contribute, what is going on) >>> >>> - Minutes for the meet >>> >>> - Community Manager >>> >>> - Sprints: >>> >>> - Running the sprint >>> >>> >>> Action Items: >>> >>> - Eric Windisch to Identify topic to set the sprint/ hackathon and time. >>> >>> >>> Thanks, >>> >>> -Sriram >>> >>> >>> _______________________________________________ >>> >>> Openstack-security mailing list >>> >>> Openstack-security at lists.openstack.org >>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >>> >>> >>> >> >> >> -- >> Thanks, >> -Sriram >> >> >> > > > -- > Thanks, > -Sriram > > > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kausum_Kumar at symantec.com Tue Nov 19 01:15:39 2013 From: Kausum_Kumar at symantec.com (Kausum Kumar) Date: Mon, 18 Nov 2013 17:15:39 -0800 Subject: [Openstack-security] Processes accessing Configuration files Message-ID: <9065C6D302D32541A89AC47EEA8ADC58071306F0F6@TUS1XCHEVSPIN39.SYMC.SYMANTEC.COM> Hi All, I am trying to map what configuration and input files are been accessed by what processes and how. I am looking from a security perspective, as to what process/application/user can access for read and/or write certain files. Is there such a mapping available somewhere beside the obvious process access configurations? Thanks, Kausum -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Tue Nov 19 01:18:08 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Mon, 18 Nov 2013 17:18:08 -0800 Subject: [Openstack-security] Processes accessing Configuration files In-Reply-To: <9065C6D302D32541A89AC47EEA8ADC58071306F0F6@TUS1XCHEVSPIN39.SYMC.SYMANTEC.COM> References: <9065C6D302D32541A89AC47EEA8ADC58071306F0F6@TUS1XCHEVSPIN39.SYMC.SYMANTEC.COM> Message-ID: I'd suggest checking the selinux policies for openstack in RedHat and/or Fedora. -bryan On Mon, Nov 18, 2013 at 5:15 PM, Kausum Kumar wrote: > Hi All, > > > > I am trying to map what configuration and input files are been accessed by > what processes and how. I am looking from a security perspective, as to > what process/application/user can access for read and/or write certain > files. > > > > Is there such a mapping available somewhere beside the obvious process > access configurations? > > > > Thanks, > > Kausum > > _______________________________________________ > 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 ayoung at redhat.com Tue Nov 19 01:29:24 2013 From: ayoung at redhat.com (Adam Young) Date: Mon, 18 Nov 2013 20:29:24 -0500 Subject: [Openstack-security] Processes accessing Configuration files In-Reply-To: References: <9065C6D302D32541A89AC47EEA8ADC58071306F0F6@TUS1XCHEVSPIN39.SYMC.SYMANTEC.COM> Message-ID: <528ABEF4.9000809@redhat.com> On 11/18/2013 08:18 PM, Bryan D. Payne wrote: > I'd suggest checking the selinux policies for openstack in RedHat > and/or Fedora. > -bryan Probably, for completeness, should mention that the Debian default is AppArmour, not SELinux. THe major difference between them is that AppAroun is path based, where as SELinux is Inode based. > > > On Mon, Nov 18, 2013 at 5:15 PM, Kausum Kumar > > wrote: > > Hi All, > > I am trying to map what configuration and input files are been > accessed by what processes and how. I am looking from a security > perspective, as to what process/application/user can access for > read and/or write certain files. > > Is there such a mapping available somewhere beside the obvious > process access configurations? > > Thanks, > > Kausum > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Tue Nov 19 01:33:05 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Mon, 18 Nov 2013 17:33:05 -0800 Subject: [Openstack-security] Processes accessing Configuration files In-Reply-To: <528ABEF4.9000809@redhat.com> References: <9065C6D302D32541A89AC47EEA8ADC58071306F0F6@TUS1XCHEVSPIN39.SYMC.SYMANTEC.COM> <528ABEF4.9000809@redhat.com> Message-ID: Sure, I was just suggesting that those selinux policies could be a useful source of information about the expected behavior of the various services. -bryan On Mon, Nov 18, 2013 at 5:29 PM, Adam Young wrote: > On 11/18/2013 08:18 PM, Bryan D. Payne wrote: > > I'd suggest checking the selinux policies for openstack in RedHat and/or > Fedora. > -bryan > > > Probably, for completeness, should mention that the Debian default is > AppArmour, not SELinux. THe major difference between them is that AppAroun > is path based, where as SELinux is Inode based. > > > > > > > On Mon, Nov 18, 2013 at 5:15 PM, Kausum Kumar wrote: > >> Hi All, >> >> >> >> I am trying to map what configuration and input files are been accessed >> by what processes and how. I am looking from a security perspective, as to >> what process/application/user can access for read and/or write certain >> files. >> >> >> >> Is there such a mapping available somewhere beside the obvious process >> access configurations? >> >> >> >> Thanks, >> >> Kausum >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> > > > _______________________________________________ > Openstack-security mailing listOpenstack-security at lists.openstack.orghttp://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 ayoung at redhat.com Tue Nov 19 01:47:40 2013 From: ayoung at redhat.com (Adam Young) Date: Mon, 18 Nov 2013 20:47:40 -0500 Subject: [Openstack-security] Processes accessing Configuration files In-Reply-To: References: <9065C6D302D32541A89AC47EEA8ADC58071306F0F6@TUS1XCHEVSPIN39.SYMC.SYMANTEC.COM> <528ABEF4.9000809@redhat.com> Message-ID: <528AC33C.70604@redhat.com> On 11/18/2013 08:33 PM, Bryan D. Payne wrote: > Sure, I was just suggesting that those selinux policies could be a > useful source of information about the expected behavior of the > various services. > > -bryan > > > On Mon, Nov 18, 2013 at 5:29 PM, Adam Young > wrote: > > On 11/18/2013 08:18 PM, Bryan D. Payne wrote: >> I'd suggest checking the selinux policies for openstack in RedHat >> and/or Fedora. >> -bryan > > Probably, for completeness, should mention that the Debian default > is AppArmour, not SELinux. THe major difference between them is > that AppAroun is path based, where as SELinux is Inode based. > And I should learn to type: AppArmor: https://wiki.ubuntu.com/AppArmor > > > > >> >> >> On Mon, Nov 18, 2013 at 5:15 PM, Kausum Kumar >> > wrote: >> >> Hi All, >> >> I am trying to map what configuration and input files are >> been accessed by what processes and how. I am looking from a >> security perspective, as to what process/application/user can >> access for read and/or write certain files. >> >> Is there such a mapping available somewhere beside the >> obvious process access configurations? >> >> Thanks, >> >> Kausum >> >> >> _______________________________________________ >> 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: From dotalton at cisco.com Tue Nov 19 02:42:22 2013 From: dotalton at cisco.com (Don Talton (dotalton)) Date: Tue, 19 Nov 2013 02:42:22 +0000 Subject: [Openstack-security] Processes accessing Configuration files In-Reply-To: <9065C6D302D32541A89AC47EEA8ADC58071306F0F6@TUS1XCHEVSPIN39.SYMC.SYMANTEC.COM> References: <9065C6D302D32541A89AC47EEA8ADC58071306F0F6@TUS1XCHEVSPIN39.SYMC.SYMANTEC.COM> Message-ID: <57ED724085B72141BB091CF1314E471F017F5BB5@xmb-rcd-x15.cisco.com> The linux 'lsof' tool may also help. From: Kausum Kumar [mailto:Kausum_Kumar at symantec.com] Sent: Monday, November 18, 2013 6:16 PM To: openstack-security at lists.openstack.org Subject: [Openstack-security] Processes accessing Configuration files Hi All, I am trying to map what configuration and input files are been accessed by what processes and how. I am looking from a security perspective, as to what process/application/user can access for read and/or write certain files. Is there such a mapping available somewhere beside the obvious process access configurations? Thanks, Kausum -------------- next part -------------- An HTML attachment was scrubbed... URL: From kseifried at redhat.com Tue Nov 19 02:47:33 2013 From: kseifried at redhat.com (Kurt Seifried) Date: Mon, 18 Nov 2013 19:47:33 -0700 Subject: [Openstack-security] Processes accessing Configuration files In-Reply-To: <57ED724085B72141BB091CF1314E471F017F5BB5@xmb-rcd-x15.cisco.com> References: <9065C6D302D32541A89AC47EEA8ADC58071306F0F6@TUS1XCHEVSPIN39.SYMC.SYMANTEC.COM> <57ED724085B72141BB091CF1314E471F017F5BB5@xmb-rcd-x15.cisco.com> Message-ID: <528AD145.10004@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The quickest way to handle this is to look at the audit subsystem and invoke auditing, you can also use inotify (like pynotify) to track specific files. If as you mentioned the use case is creating AppArmour profiles then you'll want to look at our SELinux policies and a dump of the file system permissions (e.g. which files have which permissions applied to them). If you need assistance with thins ping me, I've used both for some time. Sadly there is no tool to convert policies (that I know of), but with dumps of file permissions and the selinux policies you should be able to convert it without to much pain. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSitFEAAoJEBYNRVNeJnmTlP0P/3IK7CO2X8icIXAkJUyo/9IB IN2Fes3hQ3TQ2zVc6HG+z/5hgSMiDIKDeLK6PXHGNlJ+gwfRGtPquQEgtKNyP1fF FM9kStVBrckzOkkO3D9yEwkCpM+1AKEdxcy3ZlJa9R/inITH3nVrBQj3YIZks99F WM+w8HjfybWE3lWRg0NXP75lDfZHRao7TOFn4s4PgLTVxVw6CLP403f7g6Y9ltTd nyW+PPEjJRp+MAguYx0/cHmoxyq/lNEWJjpdnGeObiBqCsLv49iMi2O3sRInUPr6 l/8HIoy/n/IcJIXxlPr73vtS+tNbKpfxADHbUTRZMClKvsNugUc7zPgGStYLcmbG CB27kkcarZL8lUqTj6KFA9Zmjp16rWWjnPEqX6pOb0uifOFLrILwIA9OyA9x5TS4 4dh9tvPCO3w52yuiv2Y/1R0e6tC0zCMKSZkpDndT04b4EdeXP+BebWMpajRa7Q4f ZQQhK6BbV2D++FcsbtRrXNs/3cflfN2Uihyw375tIZPyRDrxIxlnRuzBrKiSmD98 wANYr+8NxNCNqylIi1jCGLaZUHJSns8ek3GawRGq9E7hoCDgqX3AbgcbWZjX7ZA7 vFE3cQiDIAILNuqjzE/2jQUGNkt3bURZEzdtxToJj9KrGhzhk8/bU2+J7OAnub/3 aoC/JhmBtYmv1LdW4fUb =U0tS -----END PGP SIGNATURE----- From sriram at sriramhere.com Tue Nov 19 06:00:05 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 18 Nov 2013 22:00:05 -0800 Subject: [Openstack-security] Fwd: [openstack-dev] [Nova] Security vulnerability contacts In-Reply-To: <20131118202036.GZ2304@yuggoth.org> References: <528A5378.5020102@redhat.com> <20131118202036.GZ2304@yuggoth.org> Message-ID: Dear OSSG, I am seeing some kind of duplication of efforts here or did I miss something? My understanding was, we were also looking for people with strong project expertise to be security reviewers. This call for volunteers appears to be the same. What am i missing here? thanks, -Sriram ---------- Forwarded message ---------- From: Jeremy Stanley Date: Mon, Nov 18, 2013 at 12:20 PM Subject: Re: [openstack-dev] [Nova] Security vulnerability contacts To: openstack-dev at lists.openstack.org On 2013-11-18 11:27:28 -0800 (-0800), Sriram Subramanian wrote: > Thanks for the initiative. We at the OpenStack Security Group are > doing large part of these tasks now and are looking for more help > (particularly around reviews from people that are intimate to the > project internals). Here are some pointers on how to get involved. > You probably are inviting more volunteers for OSSG, I am just > trying to make it clearer. If not, we need to work to make sure > the efforts are aligned and not duplicated. As I understood his initial E-mail, he's looking for experienced Nova core reviewers with some background in security so that the vulnerability management team can use them as an initial point of contact to help develop, backport or review proposed fixes for embargoed security vulnerabilities prior to their announcement. Note that this is not something we're (VMT hat on) only seeking from Nova. All the official OpenStack projects which receive security support are strongly encouraged to groom core security developers/reviewers so that we can have some redundancy and additional bandwidth on those sorts of interactions (rather than now where we usually just contact the PTL and hope he/she is around). As discussed at the summit, we're going to work on putting together a more detailed prerequisites list for determining whether a given project is under security support. https://etherpad.openstack.org/p/IcehouseVMT -- Jeremy Stanley _______________________________________________ OpenStack-dev mailing list OpenStack-dev at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Tue Nov 19 06:06:31 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Mon, 18 Nov 2013 22:06:31 -0800 Subject: [Openstack-security] Fwd: [openstack-dev] [Nova] Security vulnerability contacts In-Reply-To: References: <528A5378.5020102@redhat.com> <20131118202036.GZ2304@yuggoth.org> Message-ID: Sriram, There is a difference. OSSG is looking to groom people to help improve the security of the projects by (1) being an active developer on the project, and (2) providing a security voice for issues that come up on the project (think architectural / design issues). This is all about being proactive about improving the security of the codebase through best practices. VMT is looking for each project to pick some people from the core devs to help triage and fix reported security vulnerabilities. That is what Russell is talking about in this thread. To put it another way. If OSSG does it's job well, then there will be less work for VMT :-) Cheers, -bryan On Mon, Nov 18, 2013 at 10:00 PM, Sriram Subramanian wrote: > Dear OSSG, > > I am seeing some kind of duplication of efforts here or did I miss > something? My understanding was, we were also looking for people with > strong project expertise to be security reviewers. This call for volunteers > appears to be the same. What am i missing here? > > thanks, > -Sriram > > ---------- Forwarded message ---------- > From: Jeremy Stanley > Date: Mon, Nov 18, 2013 at 12:20 PM > Subject: Re: [openstack-dev] [Nova] Security vulnerability contacts > To: openstack-dev at lists.openstack.org > > > On 2013-11-18 11:27:28 -0800 (-0800), Sriram Subramanian wrote: > > Thanks for the initiative. We at the OpenStack Security Group are > > doing large part of these tasks now and are looking for more help > > (particularly around reviews from people that are intimate to the > > project internals). Here are some pointers on how to get involved. > > You probably are inviting more volunteers for OSSG, I am just > > trying to make it clearer. If not, we need to work to make sure > > the efforts are aligned and not duplicated. > > As I understood his initial E-mail, he's looking for experienced > Nova core reviewers with some background in security so that the > vulnerability management team can use them as an initial point of > contact to help develop, backport or review proposed fixes for > embargoed security vulnerabilities prior to their announcement. > > Note that this is not something we're (VMT hat on) only seeking from > Nova. All the official OpenStack projects which receive security > support are strongly encouraged to groom core security > developers/reviewers so that we can have some redundancy and > additional bandwidth on those sorts of interactions (rather than now > where we usually just contact the PTL and hope he/she is around). As > discussed at the summit, we're going to work on putting together a > more detailed prerequisites list for determining whether a given > project is under security support. > > https://etherpad.openstack.org/p/IcehouseVMT > -- > Jeremy Stanley > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Thanks, > -Sriram > > _______________________________________________ > 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 sriram at sriramhere.com Tue Nov 19 06:17:02 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 18 Nov 2013 22:17:02 -0800 Subject: [Openstack-security] Fwd: [openstack-dev] [Nova] Security vulnerability contacts In-Reply-To: References: <528A5378.5020102@redhat.com> <20131118202036.GZ2304@yuggoth.org> Message-ID: OK, makes sense. I thought at soon we will be doing (2) too. But makes sense now. Thanks! On Mon, Nov 18, 2013 at 10:06 PM, Bryan D. Payne wrote: > Sriram, > > There is a difference. > > OSSG is looking to groom people to help improve the security of the > projects by (1) being an active developer on the project, and (2) providing > a security voice for issues that come up on the project (think > architectural / design issues). This is all about being proactive about > improving the security of the codebase through best practices. > > VMT is looking for each project to pick some people from the core devs to > help triage and fix reported security vulnerabilities. That is what > Russell is talking about in this thread. > > To put it another way. If OSSG does it's job well, then there will be > less work for VMT :-) > > Cheers, > -bryan > > > > > > On Mon, Nov 18, 2013 at 10:00 PM, Sriram Subramanian < > sriram at sriramhere.com> wrote: > >> Dear OSSG, >> >> I am seeing some kind of duplication of efforts here or did I miss >> something? My understanding was, we were also looking for people with >> strong project expertise to be security reviewers. This call for volunteers >> appears to be the same. What am i missing here? >> >> thanks, >> -Sriram >> >> ---------- Forwarded message ---------- >> From: Jeremy Stanley >> Date: Mon, Nov 18, 2013 at 12:20 PM >> Subject: Re: [openstack-dev] [Nova] Security vulnerability contacts >> To: openstack-dev at lists.openstack.org >> >> >> On 2013-11-18 11:27:28 -0800 (-0800), Sriram Subramanian wrote: >> > Thanks for the initiative. We at the OpenStack Security Group are >> > doing large part of these tasks now and are looking for more help >> > (particularly around reviews from people that are intimate to the >> > project internals). Here are some pointers on how to get involved. >> > You probably are inviting more volunteers for OSSG, I am just >> > trying to make it clearer. If not, we need to work to make sure >> > the efforts are aligned and not duplicated. >> >> As I understood his initial E-mail, he's looking for experienced >> Nova core reviewers with some background in security so that the >> vulnerability management team can use them as an initial point of >> contact to help develop, backport or review proposed fixes for >> embargoed security vulnerabilities prior to their announcement. >> >> Note that this is not something we're (VMT hat on) only seeking from >> Nova. All the official OpenStack projects which receive security >> support are strongly encouraged to groom core security >> developers/reviewers so that we can have some redundancy and >> additional bandwidth on those sorts of interactions (rather than now >> where we usually just contact the PTL and hope he/she is around). As >> discussed at the summit, we're going to work on putting together a >> more detailed prerequisites list for determining whether a given >> project is under security support. >> >> https://etherpad.openstack.org/p/IcehouseVMT >> -- >> Jeremy Stanley >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> -- >> Thanks, >> -Sriram >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Tue Nov 19 13:46:48 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 19 Nov 2013 13:46:48 +0000 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: References: Message-ID: Hi All, I've had a little downtime recently due to being horribly ill - I'm glad to say I've been feeling much better recently but I have a rather impressive pile of emails that I'm currently wading through. I have 3-4 people wanting to help out with the OSSNs, I've been really impressed with the response and I'm looking forward to seeing how this works moving forward. I'll send an email around those of you who wanted to help. My general thought is that I'll stay on to help out with OSSNs and generally co-ordinate the project. I'm looking for authors and editors to collaborate on individual OSSNs. My role would be to identify and accept new OSSNs, to occasionally author my own OSSNs and regularly edit/+1 the OSSNs of others. So, to those of you who are interested in helping out, are you anticipating authoring (which normally includes some amount of research) or editing? We currently have 3 OSSNs waiting to be written, https://bugs.launchpad.net/ossn/+bugs perhaps between you it would be possible to make a start on 1-2 of them. Each OSSN follows the same template Short title describing the issue --- ### Summary ### [One or two sentences discussing the issue, where it comes from and who it may affect.] ### Affected Services / Software ### [Freeform keywords, metadata, comma separated] Keystone, DevStack, Deployment ### Discussion ### [As much text as is required to describe the problem to a reasonably technical audience. This section should be written carefully and reviewed for content, grammar, spelling etc. When writing these sections consider that the OSSN will later be included in the OpenStack Security Guide, writing well here makes the process of mixing the OSSN into the Security Guide much easier later on. Code Snippets are welcome if they help illustrate the problem. ### Recommended Actions ### [Actions that should be taken to remediate or work around the problem, note that this will often include configuration snippets] ### Contacts / References ### This OSSN : [The URL of the OSSN] Original LaunchPad Bug : [The URL of the original Launchpad Bug, if there was one] OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg CVE: [Any CVE] [Any other References] From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: 14 November 2013 07:01 To: noloader at gmail.com Cc: Clark, Robert Graham; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OpenStack Security Notes - Contributors Wanted Rob - any emails yet? Are we meeting tomorrow? On Fri, Nov 8, 2013 at 2:59 AM, Sriram Subramanian wrote: Perfect. Rob - please send those emails out. Jeff and I will try to get this rolling, Safe travels! On Fri, Nov 8, 2013 at 3:02 PM, Jeffrey Walton wrote: Hi Robert, I'd be happy to help out with spare cycles. Jeff On Wed, Nov 6, 2013 at 11:08 AM, Clark, Robert Graham wrote: > Hi All, > > I'm looking for help with the OpenStack Security Notes. I currently am struggling to keep up with them and do all the other things I'm involved in. Individually they don't take that much time so with one or two people helping out they wouldn't be a significant burden. > > If anyone wants to run the management of this project and publishing the OSSNs I'd be happy to support them in an editorial capacity. > > Cheers > -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 -- Thanks, -Sriram -- Thanks, -Sriram -------------- 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 fungi at yuggoth.org Tue Nov 19 15:12:11 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 19 Nov 2013 15:12:11 +0000 Subject: [Openstack-security] Fwd: [openstack-dev] [Nova] Security vulnerability contacts In-Reply-To: References: <528A5378.5020102@redhat.com> <20131118202036.GZ2304@yuggoth.org> Message-ID: <20131119151209.GA2304@yuggoth.org> On 2013-11-18 22:17:02 -0800 (-0800), Sriram Subramanian wrote: > OK, makes sense. I thought at soon we will be doing (2) too. But > makes sense now. Thanks! We are hoping that the OSSG puts together a small team of operational security specialists with whom the VMT can consult when there are questions about whether a particular bug should be considered a vulnerability rather than a security hardening opportunity, to help double-check our assertions of exploitability and so on. Also, it's not like there needs to be any particular role separation there--I'd encourage code-minded OSSG members to attain core status in various projects and help us from the review/fix side of things--and similarly security-minded core reviewers should strongly consider getting involved in the OSSG to pitch in on the design/planning/auditing end of the spectrum too. There is already some of this going on of course, but more can't hurt! -- Jeremy Stanley From nkinder at redhat.com Tue Nov 19 16:35:17 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 19 Nov 2013 08:35:17 -0800 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: References: Message-ID: <528B9345.9020706@redhat.com> On 11/19/2013 05:46 AM, Clark, Robert Graham wrote: > > Hi All, > > I've had a little downtime recently due to being horribly ill - I'm > glad to say I've been feeling much better recently but I have a rather > impressive pile of emails that I'm currently wading through. I have > 3-4 people wanting to help out with the OSSNs, I've been really > impressed with the response and I'm looking forward to seeing how this > works moving forward. I'll send an email around those of you who > wanted to help. > > My general thought is that I'll stay on to help out with OSSNs and > generally co-ordinate the project. I'm looking for authors and editors > to collaborate on individual OSSNs. My role would be to identify and > accept new OSSNs, to occasionally author my own OSSNs and regularly > edit/+1 the OSSNs of others. > > So, to those of you who are interested in helping out, are you > anticipating authoring (which normally includes some amount of > research) or editing? > I am fine with authoring. > > We currently have 3 OSSNs waiting to be written, > https://bugs.launchpad.net/ossn/+bugs perhaps between you it would be > possible to make a start on 1-2 of them. Each OSSN follows the same > template > I would be happy to work on this one: https://bugs.launchpad.net/ossn/+bug/1237989 Thanks, -NGK > > Short title describing the issue > > --- > > ### Summary ### > [One or two sentences discussing the issue, where it comes from and > who it may affect.] > > ### Affected Services / Software ### > [Freeform keywords, metadata, comma separated] Keystone, DevStack, > Deployment > > ### Discussion ### > > [As much text as is required to describe the problem to a reasonably > technical audience. This section should be written carefully and > reviewed for content, grammar, spelling etc. When writing these > sections consider that the OSSN will later be included in the > OpenStack Security Guide, writing well here makes the process of > mixing the OSSN into the Security Guide much easier later on. Code > Snippets are welcome if they help illustrate the problem. > > ### Recommended Actions ### > [Actions that should be taken to remediate or work around the problem, > note that this will often include configuration snippets] > > ### Contacts / References ### > This OSSN :[The URL of the OSSN] > Original LaunchPad Bug : [The URL of the original Launchpad Bug, if > there was one] > OpenStack Security ML : openstack-security at lists.openstack.org > OpenStack Security Group :https://launchpad.net/~openstack-ossg > > CVE: [Any CVE] > > [Any other References] > > *From:*Sriram Subramanian [mailto:sriram at sriramhere.com] > *Sent:* 14 November 2013 07:01 > *To:* noloader at gmail.com > *Cc:* Clark, Robert Graham; openstack-security at lists.openstack.org > *Subject:* Re: [Openstack-security] OpenStack Security Notes - > Contributors Wanted > > Rob - any emails yet? Are we meeting tomorrow? > > On Fri, Nov 8, 2013 at 2:59 AM, Sriram Subramanian > > wrote: > > Perfect. > > Rob - please send those emails out. Jeff and I will try to get this > rolling, Safe travels! > > On Fri, Nov 8, 2013 at 3:02 PM, Jeffrey Walton > wrote: > > Hi Robert, > > I'd be happy to help out with spare cycles. > > Jeff > > > On Wed, Nov 6, 2013 at 11:08 AM, Clark, Robert Graham > > wrote: > > Hi All, > > > > I'm looking for help with the OpenStack Security Notes. I currently > am struggling to keep up with them and do all the other things I'm > involved in. Individually they don't take that much time so with one > or two people helping out they wouldn't be a significant burden. > > > > If anyone wants to run the management of this project and publishing > the OSSNs I'd be happy to support them in an editorial capacity. > > > > Cheers > > -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 > > > > -- > > Thanks, > > -Sriram > > > > -- > > Thanks, > > -Sriram > > > > _______________________________________________ > 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 binhou at cn.ibm.com Tue Nov 12 03:14:44 2013 From: binhou at cn.ibm.com (Bin Hou) Date: Tue, 12 Nov 2013 03:14:44 -0000 Subject: [Openstack-security] [Bug 1246159] Re: seed method brings potential security issue References: <20131030013717.19024.324.malonedeb@gac.canonical.com> Message-ID: <20131112031444.24061.93878.malone@gac.canonical.com> Jeremy, Could you put your comments and help me to understand what the reasons are to resolve this bug as invalid? Thanks Bin -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246159 Title: seed method brings potential security issue Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Invalid Bug description: In the /cinder/transfer/apil.py, line 86, the source code is below random.seed(datetime.datetime.now().microsecond) This code is using seed method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246159/+subscriptions From mriedem at us.ibm.com Tue Nov 12 17:28:28 2013 From: mriedem at us.ibm.com (Matt Riedemann) Date: Tue, 12 Nov 2013 17:28:28 -0000 Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131112172828.23823.61336.malone@gac.canonical.com> Nove oslo sync patch is here: https://review.openstack.org/#/c/56059/ ** Changed in: nova Status: Confirmed => In Progress ** Changed in: nova Assignee: (unassigned) => Lance Bragstad (ldbragst) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From 1247217 at bugs.launchpad.net Tue Nov 12 17:34:20 2013 From: 1247217 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 12 Nov 2013 17:34:20 -0000 Subject: [Openstack-security] [Bug 1247217] Fix proposed to nova (master) References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131112173420.24098.66222.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/56069 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From 890411 at bugs.launchpad.net Tue Nov 12 22:04:09 2013 From: 890411 at bugs.launchpad.net (Arvind Tiwari) Date: Tue, 12 Nov 2013 22:04: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: <20131112220412.12674.19593.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Assignee: (unassigned) => Arvind Tiwari (arvind-tiwari) -- 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): Confirmed 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 1247217 at bugs.launchpad.net Wed Nov 13 06:06:09 2013 From: 1247217 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 13 Nov 2013 06:06:09 -0000 Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131113060609.18679.40820.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/56154 ** Changed in: oslo Assignee: Lance Bragstad (ldbragst) => Christopher Yeoh (cyeoh-0) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From 1247217 at bugs.launchpad.net Thu Nov 14 12:12:52 2013 From: 1247217 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 14 Nov 2013 12:12:52 -0000 Subject: [Openstack-security] [Bug 1247217] Fix merged to oslo-incubator (master) References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131114121252.10266.85181.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/56154 Committed: http://github.com/openstack/oslo-incubator/commit/25c5854d67547ee177cc84341eaf9c8eb7c10834 Submitter: Jenkins Branch: master commit 25c5854d67547ee177cc84341eaf9c8eb7c10834 Author: Chris Yeoh Date: Wed Nov 13 16:35:36 2013 +1030 Adds admin_password as key to be sanitized when logging The Nova V3 API is moving to use admin_password instead of admin_pass (both are currently in use). So adding admin_password as a key that the value should be sanitized for when logging. Change-Id: I0eb66c948516624db8b770498ae541025545d981 Partial-Bug: #1247217 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): In Progress Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From 1251518 at bugs.launchpad.net Fri Nov 15 16:10:43 2013 From: 1251518 at bugs.launchpad.net (Mark Washenberger) Date: Fri, 15 Nov 2013 16:10:43 -0000 Subject: [Openstack-security] [Bug 1251518] Re: Glance needs a config option to limit the number of additional image properties References: <20131115051405.19741.28287.malonedeb@chaenomeles.canonical.com> Message-ID: <20131115161046.7385.5504.launchpad@wampee.canonical.com> ** Changed in: glance Status: New => Triaged ** Changed in: glance Importance: Undecided => Critical ** Changed in: glance Milestone: None => icehouse-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/1251518 Title: Glance needs a config option to limit the number of additional image properties Status in OpenStack Image Registry and Delivery Service (Glance): Triaged Status in OpenStack Security Advisories: Invalid Bug description: Impact: The vulnerability occurs when glance is directly exposed to users. If users can only hit glance via the compute API, then no vulnerability. Nova has a configuration option quota_metadata_items (default value 128) that's documented to limit the number of metadata items that can be put on an instance. (I verified that it also applies to image metadata using a havana devstack.) Glance does not appear to have such an option (I was able to put >500 additional properties on an image using the glanceclient). I think this is a DOS attack vector, since someone could fill the glance database with garbage and slow everything down. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1251518/+subscriptions From 1251518 at bugs.launchpad.net Fri Nov 15 16:30:50 2013 From: 1251518 at bugs.launchpad.net (Alex Meade) Date: Fri, 15 Nov 2013 16:30:50 -0000 Subject: [Openstack-security] [Bug 1251518] Re: Glance needs a config option to limit the number of additional image properties References: <20131115051405.19741.28287.malonedeb@chaenomeles.canonical.com> Message-ID: <20131115163053.10228.81203.launchpad@soybean.canonical.com> ** Changed in: glance Assignee: (unassigned) => Alex Meade (alex-meade) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251518 Title: Glance needs a config option to limit the number of additional image properties Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Advisories: Invalid Bug description: Impact: The vulnerability occurs when glance is directly exposed to users. If users can only hit glance via the compute API, then no vulnerability. Nova has a configuration option quota_metadata_items (default value 128) that's documented to limit the number of metadata items that can be put on an instance. (I verified that it also applies to image metadata using a havana devstack.) Glance does not appear to have such an option (I was able to put >500 additional properties on an image using the glanceclient). I think this is a DOS attack vector, since someone could fill the glance database with garbage and slow everything down. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1251518/+subscriptions From 1251518 at bugs.launchpad.net Fri Nov 15 16:40:34 2013 From: 1251518 at bugs.launchpad.net (Alex Meade) Date: Fri, 15 Nov 2013 16:40:34 -0000 Subject: [Openstack-security] [Bug 1251518] Re: Glance needs a config option to limit the number of additional image properties References: <20131115051405.19741.28287.malonedeb@chaenomeles.canonical.com> Message-ID: <20131115164036.19840.39036.launchpad@chaenomeles.canonical.com> ** Changed in: glance Status: Triaged => 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/1251518 Title: Glance needs a config option to limit the number of additional image properties Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Advisories: Invalid Bug description: Impact: The vulnerability occurs when glance is directly exposed to users. If users can only hit glance via the compute API, then no vulnerability. Nova has a configuration option quota_metadata_items (default value 128) that's documented to limit the number of metadata items that can be put on an instance. (I verified that it also applies to image metadata using a havana devstack.) Glance does not appear to have such an option (I was able to put >500 additional properties on an image using the glanceclient). I think this is a DOS attack vector, since someone could fill the glance database with garbage and slow everything down. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1251518/+subscriptions From 1236125 at bugs.launchpad.net Mon Nov 18 05:51:53 2013 From: 1236125 at bugs.launchpad.net (Joe Gordon) Date: Mon, 18 Nov 2013 05:51:53 -0000 Subject: [Openstack-security] [Bug 1236125] Re: PowerVM driver ignores host keys References: <20131007013845.5908.7483.malonedeb@soybean.canonical.com> Message-ID: <20131118055153.19974.75052.malone@chaenomeles.canonical.com> Sounds like this will end up being part of a bigger blueprint ** Changed in: nova Status: New => Triaged ** Changed in: nova Importance: Undecided => Low -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1236125 Title: PowerVM driver ignores host keys Status in OpenStack Compute (Nova): Triaged Bug description: Nova's PowerVM driver is currently set to AutoAdd any host key over SSH. As per the SSH protocol, host key fingerprints should be verified either by comparing with known hosts (like through a known_hosts file) or having a person verify its the host they wish to connect with. In particular, https://github.com/openstack/nova/blob/master/nova/virt/powervm/common.py uses paramiko.AutoAddPolicy() which will automatically accept any host key. Doing so allows Nova to be susceptible to a man-in-the-middle. There should instead be an option in nova.conf to specify a known_hosts file and the paramiko policy to use. That way someone could set the policy to Reject and specify a file with known_hosts which are acceptable. Communication therefore would never occur to unknown hosts and allow a potential release of a user/pwd. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1236125/+subscriptions From 1251518 at bugs.launchpad.net Mon Nov 18 16:48:59 2013 From: 1251518 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 18 Nov 2013 16:48:59 -0000 Subject: [Openstack-security] [Bug 1251518] Fix proposed to glance (master) References: <20131115051405.19741.28287.malonedeb@chaenomeles.canonical.com> Message-ID: <20131118164859.9846.28508.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/56981 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251518 Title: Glance needs a config option to limit the number of additional image properties Status in OpenStack Image Registry and Delivery Service (Glance): In Progress Status in OpenStack Security Advisories: Invalid Bug description: Impact: The vulnerability occurs when glance is directly exposed to users. If users can only hit glance via the compute API, then no vulnerability. Nova has a configuration option quota_metadata_items (default value 128) that's documented to limit the number of metadata items that can be put on an instance. (I verified that it also applies to image metadata using a havana devstack.) Glance does not appear to have such an option (I was able to put >500 additional properties on an image using the glanceclient). I think this is a DOS attack vector, since someone could fill the glance database with garbage and slow everything down. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1251518/+subscriptions From robert.clark at hp.com Tue Nov 19 16:54:28 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 19 Nov 2013 16:54:28 +0000 Subject: [Openstack-security] OpenStack Security Group representation to the VMT Message-ID: Deciding whether or not something is an exploitable vulnerability and how it should be handled are difficult tasks, not least in the OpenStack world where most people run different deployment types, have different attack models and threats to consider. Over the last 6 months I've occasionally been roped in to help the VMT make decisions about how security vulnerabilities should be handled. At the VMT session this summit, it was suggested that the OSSG involvement with the VMT should be more formalised. I couldn't agree more with this statement, I'd like to continue working with the VMT as I've found the work rewarding and beneficial. HP now operates OpenStack clouds in the Public, Hybrid and Private scopes, meaning that I and my security team are well positioned to address the concerns of most cloud deployers. If the OSSG were to start being involved with the VMT more regularly it's likely that we'd need more than one person to cover VMT engagements. I have the resource within my security team to do this but it would likely make sense for this to be someone from another organisation, being in a different time zone would also likely be beneficial. I believe that Joel Coffman from APL has volunteered to work with the VMT too, is there any objection within the OSSG to the proposal that we start with myself and Joel providing support to the VMT? There will be scope to change the team around and also for Joel or I to draw on the expertise from others in the OSSG for individual issues. If members of the OSSG agree this is a reasonable first step to further involvement with the VMT, I'll start a discussion with them to work out the best way forward. Regards -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 bdpayne at acm.org Tue Nov 19 16:56:58 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 19 Nov 2013 08:56:58 -0800 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: +1 -bryan On Tue, Nov 19, 2013 at 8:54 AM, Clark, Robert Graham wrote: > Deciding whether or not something is an exploitable vulnerability and > how it should be handled are difficult tasks, not least in the OpenStack > world where most people run different deployment types, have different > attack models and threats to consider. > > Over the last 6 months I've occasionally been roped in to help the VMT > make decisions about how security vulnerabilities should be handled. At > the VMT session this summit, it was suggested that the OSSG involvement > with the VMT should be more formalised. I couldn't agree more with this > statement, I'd like to continue working with the VMT as I've found the > work rewarding and beneficial. HP now operates OpenStack clouds in the > Public, Hybrid and Private scopes, meaning that I and my security team > are well positioned to address the concerns of most cloud deployers. > > If the OSSG were to start being involved with the VMT more regularly > it's likely that we'd need more than one person to cover VMT > engagements. I have the resource within my security team to do this but > it would likely make sense for this to be someone from another > organisation, being in a different time zone would also likely be > beneficial. > > I believe that Joel Coffman from APL has volunteered to work with the > VMT too, is there any objection within the OSSG to the proposal that we > start with myself and Joel providing support to the VMT? There will be > scope to change the team around and also for Joel or I to draw on the > expertise from others in the OSSG for individual issues. > > If members of the OSSG agree this is a reasonable first step to further > involvement with the VMT, I'll start a discussion with them to work out > the best way forward. > > Regards > -Rob > > Robert Clark > Security Architect > HP Cloud Services > > > _______________________________________________ > 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 Nov 19 16:55:44 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 19 Nov 2013 16:55:44 -0000 Subject: [Openstack-security] [Bug 1237989] Re: user can update his password without knowing the old password References: <20131010124138.28096.87746.malonedeb@chaenomeles.canonical.com> Message-ID: <20131119165547.19947.43585.launchpad@chaenomeles.canonical.com> ** Changed in: ossn Assignee: (unassigned) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: New Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions From fungi at yuggoth.org Tue Nov 19 17:01:59 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 19 Nov 2013 17:01:59 -0000 Subject: [Openstack-security] [Bug 1246159] Re: seed method brings potential security issue References: <20131030013717.19024.324.malonedeb@gac.canonical.com> Message-ID: <20131119170200.7028.11933.malone@wampee.canonical.com> I marked the OSSA task as invalid because we won't be releasing a security advisory. The bug task for this in Nova is still very much open. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1246159 Title: seed method brings potential security issue Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Invalid Bug description: In the /cinder/transfer/apil.py, line 86, the source code is below random.seed(datetime.datetime.now().microsecond) This code is using seed method to generate a random number, Standard random number generators should not be used to generate randomness used for security reasons. For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1246159/+subscriptions From arosen at nicira.com Tue Nov 19 17:11:28 2013 From: arosen at nicira.com (Aaron Rosen) Date: Tue, 19 Nov 2013 09:11:28 -0800 Subject: [Openstack-security] Neutron security groups for L2 networks in Havana In-Reply-To: References: Message-ID: Hi Kanthi, The issue is that the nova-api says that by default every instance needs to be in a default security group that blocks all ingress traffic from outside and allows all ingress from instances that belong to the same security group. If an instance does not have an ip address we are unable to enforce the instance->instance communication of members that are part of the same security group (or at least the iptables implementation in place doesn't). There is an extension in neutron that implements port_security that allows one to disable this so that one can do L2 networking as you want to. Though unfortunately, this does not work correctly at this time with nova as currently it's calling into neutron to create the security group and attach it to the instance anways. See: https://bugs.launchpad.net/nova/+bug/1175464 . I'm hoping to resolve this issue in the next few weeks. Best, Aaron On Fri, Nov 8, 2013 at 1:45 AM, Kanthi P wrote: > Hi Aaron, > > Thanks for the reply ! > Yes security groups are mapped to L3/L4 headers, these security rules are > being converted to iptables. > > If we remove the subnet check, we will be able to launch instances without > ipaddress, they just have the mac address. > Users can configure their own ipaddress after they are booted. > > If we use neutron security groups, it provides a default group (on port > basis) which blocks all ingress and allows all egress traffic. > > Later users can configure security groups based on the ip address what > they provided to the vnics. > > I mean to say, ports will have subnet but just that this subnet is not > known to openstack during the instance boot time. > > > > > On Fri, Nov 8, 2013 at 9:42 AM, Aaron Rosen wrote: > >> >> >> >> On Thu, Nov 7, 2013 at 12:23 PM, Kanthi P wrote: >> >>> Hi, >>> >>> I am trying to boot a VM which has a network without subnet in Havana, >>> but it throws an exception saying that subnet is mandatory if quantum >>> security groups are enabled. >>> >>> Here are the commands I used. >>> >>> neutron net-create testNet >>> neutron net-show testNet >>> +---------------------------+--------------------------------------+ >>> | Field | Value | >>> +---------------------------+--------------------------------------+ >>> | admin_state_up | True | >>> | id | 47208beb-2801-4729-bc7b-6532717232fc | >>> | name | testNet | >>> | provider:network_type | local | >>> | provider:physical_network | | >>> | provider:segmentation_id | | >>> | router:external | False | >>> | shared | False | >>> | status | ACTIVE | >>> | subnets | | >>> | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d | >>> +---------------------------+--------------------------------------+ >>> >>> nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic >>> net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1 >>> >>> Here is the piece of code which generated this exception >>> >>> nova/network/neutronv2/api.py >>> >>> if (security_groups and not ( >>> network['subnets'] >>> and network.get('port_security_enabled', True))): >>> >>> raise exception.SecurityGroupCannotBeApplied() >>> >>> >>> Can someone please explain why do we need this check? >>> >> >> Hi Kanthi, >> >> We need this check because because in order to enforce security groups >> the port needs to have an ip_address (i.e: network needs a subnet) since >> Security groups only map to L3/4 headers. Today, nova automatically adds a >> default security group to all instances when booted. Hopefully we can punt >> this task off to neutron in this release by moving the port-creation up on >> the stack to nova-api instead of nova-compute though this isn't the case >> right now. >> >> Aaron >> >>> >>> To my understanding subnet is used for two purposes in terms of security >>> groups >>> 1. To allow dhcp traffic if dhcp is enabled on the subnet, example given >>> below >>> -A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp >>> --sport 67 --dport 68 -j RETURN >>> 2. To avoid ip spoof >>> -A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP >>> >>> Can we remove this so that we can have guests which has nic with just >>> MAC address, guest can configure its own ipaddress. Later if needed they >>> can enable their own security rules via quantum api. >>> >>> _______________________________________________ >>> 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 sriram at sriramhere.com Tue Nov 19 18:58:02 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Tue, 19 Nov 2013 10:58:02 -0800 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: <528B9345.9020706@redhat.com> References: <528B9345.9020706@redhat.com> Message-ID: Darn, you beat me on that bug:) I will take https://bugs.launchpad.net/ossn/+bug/1227575 Thanks, -Sriram On Tue, Nov 19, 2013 at 8:35 AM, Nathan Kinder wrote: > On 11/19/2013 05:46 AM, Clark, Robert Graham wrote: > > Hi All, > > > > I’ve had a little downtime recently due to being horribly ill - I’m glad > to say I’ve been feeling much better recently but I have a rather > impressive pile of emails that I’m currently wading through. I have 3-4 > people wanting to help out with the OSSNs, I’ve been really impressed with > the response and I’m looking forward to seeing how this works moving > forward. I’ll send an email around those of you who wanted to help. > > > > My general thought is that I’ll stay on to help out with OSSNs and > generally co-ordinate the project. I’m looking for authors and editors to > collaborate on individual OSSNs. My role would be to identify and accept > new OSSNs, to occasionally author my own OSSNs and regularly edit/+1 the > OSSNs of others. > > > > So, to those of you who are interested in helping out, are you > anticipating authoring (which normally includes some amount of research) or > editing? > > I am fine with authoring. > > > > We currently have 3 OSSNs waiting to be written, > https://bugs.launchpad.net/ossn/+bugs perhaps between you it would be > possible to make a start on 1-2 of them. Each OSSN follows the same template > > I would be happy to work on this one: > > https://bugs.launchpad.net/ossn/+bug/1237989 > > Thanks, > -NGK > > > > Short title describing the issue > > --- > > ### Summary ### > [One or two sentences discussing the issue, where it comes from and who it > may affect.] > > ### Affected Services / Software ### > [Freeform keywords, metadata, comma separated] Keystone, DevStack, > Deployment > > ### Discussion ### > > [As much text as is required to describe the problem to a reasonably > technical audience. This section should be written carefully and reviewed > for content, grammar, spelling etc. When writing these sections consider > that the OSSN will later be included in the OpenStack Security Guide, > writing well here makes the process of mixing the OSSN into the Security > Guide much easier later on. Code Snippets are welcome if they help > illustrate the problem. > > ### Recommended Actions ### > [Actions that should be taken to remediate or work around the problem, > note that this will often include configuration snippets] > > ### Contacts / References ### > This OSSN : [The URL of the OSSN] > Original LaunchPad Bug : [The URL of the original Launchpad Bug, if there > was one] > OpenStack Security ML : openstack-security at lists.openstack.org > OpenStack Security Group : https://launchpad.net/~openstack-ossg > CVE: [Any CVE] > > [Any other References] > > > > > > > > *From:* Sriram Subramanian [mailto:sriram at sriramhere.com] > > *Sent:* 14 November 2013 07:01 > *To:* noloader at gmail.com > *Cc:* Clark, Robert Graham; openstack-security at lists.openstack.org > *Subject:* Re: [Openstack-security] OpenStack Security Notes - > Contributors Wanted > > > > Rob - any emails yet? Are we meeting tomorrow? > > > > On Fri, Nov 8, 2013 at 2:59 AM, Sriram Subramanian > wrote: > > Perfect. > > > > Rob - please send those emails out. Jeff and I will try to get this > rolling, Safe travels! > > > > On Fri, Nov 8, 2013 at 3:02 PM, Jeffrey Walton wrote: > > Hi Robert, > > I'd be happy to help out with spare cycles. > > Jeff > > > On Wed, Nov 6, 2013 at 11:08 AM, Clark, Robert Graham > wrote: > > Hi All, > > > > I’m looking for help with the OpenStack Security Notes. I currently am > struggling to keep up with them and do all the other things I’m involved > in. Individually they don’t take that much time so with one or two people > helping out they wouldn’t be a significant burden. > > > > If anyone wants to run the management of this project and publishing the > OSSNs I’d be happy to support them in an editorial capacity. > > > > Cheers > > -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 > > > > -- > > Thanks, > > -Sriram > > > > > > -- > > Thanks, > > -Sriram > > > _______________________________________________ > Openstack-security mailing listOpenstack-security at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriram at sriramhere.com Tue Nov 19 19:03:33 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Tue, 19 Nov 2013 11:03:33 -0800 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: +1. I also wanted to know if it is OK for someone to join these calls as observers (as a learning experience). On Tue, Nov 19, 2013 at 8:56 AM, Bryan D. Payne wrote: > +1 > > -bryan > > > On Tue, Nov 19, 2013 at 8:54 AM, Clark, Robert Graham > wrote: > >> Deciding whether or not something is an exploitable vulnerability and >> how it should be handled are difficult tasks, not least in the OpenStack >> world where most people run different deployment types, have different >> attack models and threats to consider. >> >> Over the last 6 months I've occasionally been roped in to help the VMT >> make decisions about how security vulnerabilities should be handled. At >> the VMT session this summit, it was suggested that the OSSG involvement >> with the VMT should be more formalised. I couldn't agree more with this >> statement, I'd like to continue working with the VMT as I've found the >> work rewarding and beneficial. HP now operates OpenStack clouds in the >> Public, Hybrid and Private scopes, meaning that I and my security team >> are well positioned to address the concerns of most cloud deployers. >> >> If the OSSG were to start being involved with the VMT more regularly >> it's likely that we'd need more than one person to cover VMT >> engagements. I have the resource within my security team to do this but >> it would likely make sense for this to be someone from another >> organisation, being in a different time zone would also likely be >> beneficial. >> >> I believe that Joel Coffman from APL has volunteered to work with the >> VMT too, is there any objection within the OSSG to the proposal that we >> start with myself and Joel providing support to the VMT? There will be >> scope to change the team around and also for Joel or I to draw on the >> expertise from others in the OSSG for individual issues. >> >> If members of the OSSG agree this is a reasonable first step to further >> involvement with the VMT, I'll start a discussion with them to work out >> the best way forward. >> >> Regards >> -Rob >> >> Robert Clark >> Security Architect >> HP Cloud Services >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Tue Nov 19 19:18:51 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 19 Nov 2013 11:18:51 -0800 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: > > I also wanted to know if it is OK for someone to join these calls as > observers (as a learning experience). > Unfortunately not. The primary purpose of all of this is to minimize the number of people that know about vulnerabilities in OpenStack before they are fixed. Hence the aim to keep the number of people involved to a small group. -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Tue Nov 19 19:27:21 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 19 Nov 2013 19:27:21 +0000 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: Bryan is right, the idea is to keep the group very small as some of the vulnerabilities can have significant impact on deployers. However, I'm sure there will be times when you and other significant OSSG contributors will be brought in to help on specific issues where you have expertise that will be very useful. Cheers -Rob From: bdpayne at gmail.com [mailto:bdpayne at gmail.com] On Behalf Of Bryan D. Payne Sent: 19 November 2013 19:19 To: Sriram Subramanian Cc: Clark, Robert Graham; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OpenStack Security Group representation to the VMT I also wanted to know if it is OK for someone to join these calls as observers (as a learning experience). Unfortunately not. The primary purpose of all of this is to minimize the number of people that know about vulnerabilities in OpenStack before they are fixed. Hence the aim to keep the number of people involved to a small group. -bryan -------------- 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 nkinder at redhat.com Tue Nov 19 19:32:39 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 19 Nov 2013 11:32:39 -0800 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: References: <528B9345.9020706@redhat.com> Message-ID: <528BBCD7.6050306@redhat.com> On 11/19/2013 10:58 AM, Sriram Subramanian wrote: > Darn, you beat me on that bug:) Sorry. :) I've previously discussed this bug with some of the Keystone developers, so it seemed like one that I can easily handle. I'm just about finished writing up the first draft. This is my first OSSN, so I'd love for it to get a thorough review. Thanks, -NGK > > I will take https://bugs.launchpad.net/ossn/+bug/1227575 > > Thanks, > -Sriram > > > On Tue, Nov 19, 2013 at 8:35 AM, Nathan Kinder > wrote: > > On 11/19/2013 05:46 AM, Clark, Robert Graham wrote: >> >> Hi All, >> >> I’ve had a little downtime recently due to being horribly ill - >> I’m glad to say I’ve been feeling much better recently but I have >> a rather impressive pile of emails that I’m currently wading >> through. I have 3-4 people wanting to help out with the OSSNs, >> I’ve been really impressed with the response and I’m looking >> forward to seeing how this works moving forward. I’ll send an >> email around those of you who wanted to help. >> >> My general thought is that I’ll stay on to help out with OSSNs >> and generally co-ordinate the project. I’m looking for authors >> and editors to collaborate on individual OSSNs. My role would be >> to identify and accept new OSSNs, to occasionally author my own >> OSSNs and regularly edit/+1 the OSSNs of others. >> >> So, to those of you who are interested in helping out, are you >> anticipating authoring (which normally includes some amount of >> research) or editing? >> > I am fine with authoring. > >> We currently have 3 OSSNs waiting to be written, >> https://bugs.launchpad.net/ossn/+bugs perhaps between you it >> would be possible to make a start on 1-2 of them. Each OSSN >> follows the same template >> > I would be happy to work on this one: > > https://bugs.launchpad.net/ossn/+bug/1237989 > > Thanks, > -NGK > >> Short title describing the issue >> >> --- >> >> ### Summary ### >> [One or two sentences discussing the issue, where it comes from >> and who it may affect.] >> >> ### Affected Services / Software ### >> [Freeform keywords, metadata, comma separated] Keystone, >> DevStack, Deployment >> >> ### Discussion ### >> >> [As much text as is required to describe the problem to a >> reasonably technical audience. This section should be written >> carefully and reviewed for content, grammar, spelling etc. When >> writing these sections consider that the OSSN will later be >> included in the OpenStack Security Guide, writing well here makes >> the process of mixing the OSSN into the Security Guide much >> easier later on. Code Snippets are welcome if they help >> illustrate the problem. >> >> ### Recommended Actions ### >> [Actions that should be taken to remediate or work around the >> problem, note that this will often include configuration snippets] >> >> ### Contacts / References ### >> This OSSN :[The URL of the OSSN] >> Original LaunchPad Bug : [The URL of the original Launchpad Bug, >> if there was one] >> OpenStack Security ML : openstack-security at lists.openstack.org >> >> OpenStack Security Group :https://launchpad.net/~openstack-ossg >> >> CVE: [Any CVE] >> >> [Any other References] >> >> *From:*Sriram Subramanian [mailto:sriram at sriramhere.com] >> *Sent:* 14 November 2013 07:01 >> *To:* noloader at gmail.com >> *Cc:* Clark, Robert Graham; >> openstack-security at lists.openstack.org >> >> *Subject:* Re: [Openstack-security] OpenStack Security Notes - >> Contributors Wanted >> >> Rob - any emails yet? Are we meeting tomorrow? >> >> On Fri, Nov 8, 2013 at 2:59 AM, Sriram Subramanian >> > wrote: >> >> Perfect. >> >> Rob - please send those emails out. Jeff and I will try to get >> this rolling, Safe travels! >> >> On Fri, Nov 8, 2013 at 3:02 PM, Jeffrey Walton >> > wrote: >> >> Hi Robert, >> >> I'd be happy to help out with spare cycles. >> >> Jeff >> >> >> On Wed, Nov 6, 2013 at 11:08 AM, Clark, Robert Graham >> > wrote: >> > Hi All, >> > >> > I’m looking for help with the OpenStack Security Notes. I >> currently am struggling to keep up with them and do all the other >> things I’m involved in. Individually they don’t take that much >> time so with one or two people helping out they wouldn’t be a >> significant burden. >> > >> > If anyone wants to run the management of this project and >> publishing the OSSNs I’d be happy to support them in an editorial >> capacity. >> > >> > Cheers >> > -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 >> >> >> >> -- >> >> Thanks, >> >> -Sriram >> >> >> >> -- >> >> Thanks, >> >> -Sriram >> >> >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > > -- > Thanks, > -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriram at sriramhere.com Tue Nov 19 19:39:17 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Tue, 19 Nov 2013 11:39:17 -0800 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: Thought so, makes sense. thanks! On Tue, Nov 19, 2013 at 11:27 AM, Clark, Robert Graham wrote: > Bryan is right, the idea is to keep the group very small as some of the > vulnerabilities can have significant impact on deployers. > > > > However, I’m sure there will be times when you and other significant OSSG > contributors will be brought in to help on specific issues where you have > expertise that will be very useful. > > > > Cheers > > -Rob > > > > *From:* bdpayne at gmail.com [mailto:bdpayne at gmail.com] *On Behalf Of *Bryan > D. Payne > *Sent:* 19 November 2013 19:19 > *To:* Sriram Subramanian > *Cc:* Clark, Robert Graham; openstack-security at lists.openstack.org > *Subject:* Re: [Openstack-security] OpenStack Security Group > representation to the VMT > > > > I also wanted to know if it is OK for someone to join these calls as > observers (as a learning experience). > > > > Unfortunately not. The primary purpose of all of this is to minimize the > number of people that know about vulnerabilities in OpenStack before they > are fixed. Hence the aim to keep the number of people involved to a small > group. > > > > -bryan > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at windisch.us Tue Nov 19 19:39:58 2013 From: eric at windisch.us (Eric Windisch) Date: Tue, 19 Nov 2013 14:39:58 -0500 Subject: [Openstack-security] Security Guide - No longer on Lulu? Message-ID: It seems the Lulu link for the Security Guide is dead (was: http://www.lulu.com/commerce/index.php?fBuyContent=13956188) Searching on Lulu itself no longer finds the guide, either. It would be great if we could get the book back onto lulu, available for purchase somewhere else, and/or remove the Lulu link from the book's homepage (http://docs.openstack.org/sec/) If appropriate, I can reraise this with the docs group, if they're now the owners. Regards, Eric Windisch -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Tue Nov 19 19:55:16 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 19 Nov 2013 11:55:16 -0800 Subject: [Openstack-security] Security Guide - No longer on Lulu? In-Reply-To: References: Message-ID: Hmm, I wasn't aware of this. I'm cc'ing the docs list as they will know more, but it's worth keeping both groups aware of what's happening here. -bryan On Tue, Nov 19, 2013 at 11:39 AM, Eric Windisch wrote: > It seems the Lulu link for the Security Guide is dead (was: > http://www.lulu.com/commerce/index.php?fBuyContent=13956188) > > Searching on Lulu itself no longer finds the guide, either. > > It would be great if we could get the book back onto lulu, available for > purchase somewhere else, and/or remove the Lulu link from the book's > homepage (http://docs.openstack.org/sec/) > > If appropriate, I can reraise this with the docs group, if they're now the > owners. > > Regards, > Eric Windisch > > _______________________________________________ > 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 fungi at yuggoth.org Tue Nov 19 20:10:21 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 19 Nov 2013 20:10:21 +0000 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: <20131119201021.GF2304@yuggoth.org> On 2013-11-19 11:03:33 -0800 (-0800), Sriram Subramanian wrote: > I also wanted to know if it is OK for someone to join these calls > as observers (as a learning experience). As Bryan already mentioned, the VMT attempts to minimize exposure of embargoed vulnerability reports and bug fixes to the absolute fewest number of people required to debate and fix them. This is by design. Also, we don't use phone calls for this sort of thing, as the OpenStack project contributors tend to work very asynchronously from a wide variety of timezones/schedules. The majority of the discussion happens in private security bug comments on Launchpad at the moment, with some occasional interaction via IRC private messages (mostly to get the attention of subscribers we add to bugs in case they don't notice the updates from LP). We may switch to other tools to accomplish this over time, but I expect the general workflow to remain more or less the same. -- Jeremy Stanley From bdpayne at acm.org Tue Nov 19 20:22:23 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 19 Nov 2013 12:22:23 -0800 Subject: [Openstack-security] [Openstack-docs] Security Guide - No longer on Lulu? In-Reply-To: References: Message-ID: Thanks Anne. The links are now working for me. -bryan On Tue, Nov 19, 2013 at 12:04 PM, Anne Gentle wrote: > Hi Eric and everyone, > > I'm going to the Lulu link on http://docs.openstack.org/sec/ and finding > the printed copy available for purchase just fine. However it seems I need > to set to public access. I've done that now, let me know if you're able to > click through. > > Also, if anyone wants to buy 50 copies or more, they can go through me to > get a 50% off discount. > > Thanks, > > Anne > > > On Tue, Nov 19, 2013 at 1:55 PM, Bryan D. Payne wrote: > >> Hmm, I wasn't aware of this. I'm cc'ing the docs list as they will >> know more, but it's worth keeping both groups aware of what's happening >> here. >> -bryan >> >> >> On Tue, Nov 19, 2013 at 11:39 AM, Eric Windisch wrote: >> >>> It seems the Lulu link for the Security Guide is dead (was: >>> http://www.lulu.com/commerce/index.php?fBuyContent=13956188) >>> >>> Searching on Lulu itself no longer finds the guide, either. >>> >>> It would be great if we could get the book back onto lulu, available for >>> purchase somewhere else, and/or remove the Lulu link from the book's >>> homepage (http://docs.openstack.org/sec/) >>> >>> If appropriate, I can reraise this with the docs group, if they're now >>> the owners. >>> >>> Regards, >>> Eric Windisch >>> >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >>> >> >> _______________________________________________ >> Openstack-docs mailing list >> Openstack-docs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs >> >> > > > -- > Anne Gentle > annegentle at justwriteclick.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Tue Nov 19 20:45:15 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 19 Nov 2013 20:45:15 -0000 Subject: [Openstack-security] [Bug 1237989] Re: user can update his password without knowing the old password References: <20131010124138.28096.87746.malonedeb@chaenomeles.canonical.com> Message-ID: <20131119204518.7028.70806.launchpad@wampee.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/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: In Progress Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions From nkinder at redhat.com Tue Nov 19 21:51:32 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 19 Nov 2013 21:51:32 -0000 Subject: [Openstack-security] [Bug 1237989] Re: user can update his password without knowing the old password References: <20131010124138.28096.87746.malonedeb@chaenomeles.canonical.com> Message-ID: <20131119215132.19469.39091.malone@chaenomeles.canonical.com> Authenticated users are able to update passwords without providing their current password --- ### Summary ### An authenticated user is able to change their password without providing their current password. This allows compromised authentication tokens to be used to permanently compromise a user account. ### Affected Services / Software ### Horizon, Keystone, Identity, Grizzly ### Discussion ### Horizon allows a user to change their own password, which uses the Identity API to perform the password change. A user is required to supply their current password to successfully perform a password change. This requirement prevents a malicious user from stealing a users authentication token and changing that user's password to permanently compromise their account. With this additional password check, a compromised authentication token only compromises the user account until the token is no longer valid due to expiration or revocation. When using the Identity v3 API, a user is able to successfully change their password without supplying the correct current password. This leaves users vulnerable to permanently compromised accounts if their authentication token is compromised. The Identity v2 API is not vulnerable to this issue, as it has a separate API call for updating user passwords that properly validates the current password. ### Recommended Actions ### In the OpenStack Grizzly release, a user is allowed to update the attributes in their own entry by default. It is recommended that you restrict user updates to only be allowed by admin users. This is done by setting the "update_user" policy to "admin_required" in Keystone's policy.json file. Here is an example snippet of a properly configured policy.json file: ---- begin example policy.json snippet ---- "identity:get_user": [["rule:admin_required"]], "identity:list_users": [["rule:admin_required"]], "identity:create_user": [["rule:admin_required"]], "identity:update_user": [["rule:admin_required"]], "identity:delete_user": [["rule:admin_required"]], ---- end example policy.json snippet ---- This change has the side-effect of restricting a user from updating any of their own attributes, not just their password. In the OpenStack Havana release, the default policy is to only allow admin users to update attributes in user entries. In addition, Horizon will not allow a user to change their own password if it is using the Identity v3 API, even if Keystone is configured to allow users to update their own entries. Despite this restriction in Horizon, it is recommended to leave the default "update_user" policy setting as is, as an attacker could target Keystone directly without using Horizon to initiate a password change. ### Contacts / References ### This OSSN : https://bugs.launchpad.net/ossn/+bug/1237989 Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1237989 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg CVE: CVE-2013-4471 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: In Progress Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions From noloader at gmail.com Tue Nov 19 23:31:11 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 19 Nov 2013 18:31:11 -0500 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: On Tue, Nov 19, 2013 at 2:18 PM, Bryan D. Payne wrote: >> I also wanted to know if it is OK for someone to join these calls as >> observers (as a learning experience). > > > Unfortunately not. The primary purpose of all of this is to minimize the > number of people that know about vulnerabilities in OpenStack before they > are fixed. Hence the aim to keep the number of people involved to a small > group. Is there an upper bound on the time-before-disclosure? I've seen Apple, IBM, and Microsoft and others take [literally] years to fix vulnerabilities. In this case, only the VMT and adversaries will know about the hole. I believe leaving a vulnerability unmitigated for years is a detriment to the deployment base, and not a benefit. Jeff From rbryant at redhat.com Tue Nov 19 23:38:05 2013 From: rbryant at redhat.com (Russell Bryant) Date: Tue, 19 Nov 2013 18:38:05 -0500 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: <528BF65D.9020804@redhat.com> On 11/19/2013 06:31 PM, Jeffrey Walton wrote: > On Tue, Nov 19, 2013 at 2:18 PM, Bryan D. Payne wrote: >>> I also wanted to know if it is OK for someone to join these calls as >>> observers (as a learning experience). >> >> >> Unfortunately not. The primary purpose of all of this is to minimize the >> number of people that know about vulnerabilities in OpenStack before they >> are fixed. Hence the aim to keep the number of people involved to a small >> group. > Is there an upper bound on the time-before-disclosure? > > I've seen Apple, IBM, and Microsoft and others take [literally] years > to fix vulnerabilities. In this case, only the VMT and adversaries > will know about the hole. I believe leaving a vulnerability > unmitigated for years is a detriment to the deployment base, and not a > benefit. https://wiki.openstack.org/wiki/Vulnerability_Management -- Russell Bryant From bdpayne at acm.org Tue Nov 19 23:42:15 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 19 Nov 2013 15:42:15 -0800 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: > > Is there an upper bound on the time-before-disclosure? > While I'm not aware of a formal policy, from my experience the VMT has done a good job of getting fixes in place ASAP. -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Nov 20 00:58:53 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 20 Nov 2013 00:58:53 +0000 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: References: Message-ID: <20131120005849.GI2304@yuggoth.org> On 2013-11-19 18:31:11 -0500 (-0500), Jeffrey Walton wrote: > Is there an upper bound on the time-before-disclosure? > > I've seen Apple, IBM, and Microsoft and others take [literally] > years to fix vulnerabilities. In this case, only the VMT and > adversaries will know about the hole. I believe leaving a > vulnerability unmitigated for years is a detriment to the > deployment base, and not a benefit. Personally (VMT hat off) I'm a "full disclosure" fan. I think the sooner vulnerabilities are publicized, the faster they get attention and get fixed. Working on and fixing things completely in the open, particularly since that's how the rest of OpenStack already operates, gets huge efficiency gains. All that aside (VMT hat back on) many of our downstream distributors and member companies running public infrastructure want a heads-up so they have a couple business days to get fixes or mitigation into place before we go public with a major security flaw... "responsible disclosure." I suspect there's a balance to be struck here between "full disclosure" and "responsible disclosure," and would not be opposed to a policy for how long we're able to sit on an unfixed but embargoed vulnerability before it becomes a public vulnerability. For example, the linux-distros vulnerability notification list mandates "14 to 19 days" as a maximum acceptable embargo period. If this is something the community is keen on, we can discuss options within the VMT to enact a policy change like this (comments, Thierry? Mikal?). Keep in mind, however, that we don't delay advisories and fixes at the request of an outside party or for public image reasons. For bugs which encounter delays, the common causes I've seen are one of... * we have trouble finding security reviewers who can confirm the reported bug and identify all affected stable releases * the bug is confirmed and we suspect we know its impact/reach, but can't interest developers in working on a fix * the developers involved aren't sure how to fix it in some supported stable branch in a backward-compatible manner * a fix is proposed but we have trouble finding core reviewers for that project to test and pre-approve it * unrelated regressions in our stable release branches prevent us from reliably gating the preapproved changes so they can be merged Hopefully that helps clarify the situation. If you have related questions, don't hesitate to ask! -- Jeremy Stanley From robert.clark at hp.com Wed Nov 20 07:33:02 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 20 Nov 2013 07:33:02 +0000 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: <528BBCD7.6050306@redhat.com> References: <528B9345.9020706@redhat.com> <528BBCD7.6050306@redhat.com> Message-ID: Great job on the OSSN Nathan, it looks very good, I've put one comment on it for a very minor change and then I'd say it's ready for publishing. I'm wondering - should I continue to publish OSSNs when they're ready or would you like to submit direct to the mailing lists? From: Nathan Kinder [mailto:nkinder at redhat.com] Sent: 19 November 2013 19:33 To: Sriram Subramanian Cc: Clark, Robert Graham; noloader at gmail.com; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OpenStack Security Notes - Contributors Wanted On 11/19/2013 10:58 AM, Sriram Subramanian wrote: Darn, you beat me on that bug:) Sorry. :) I've previously discussed this bug with some of the Keystone developers, so it seemed like one that I can easily handle. I'm just about finished writing up the first draft. This is my first OSSN, so I'd love for it to get a thorough review. Thanks, -NGK I will take https://bugs.launchpad.net/ossn/+bug/1227575 Thanks, -Sriram On Tue, Nov 19, 2013 at 8:35 AM, Nathan Kinder > wrote: On 11/19/2013 05:46 AM, Clark, Robert Graham wrote: Hi All, I've had a little downtime recently due to being horribly ill - I'm glad to say I've been feeling much better recently but I have a rather impressive pile of emails that I'm currently wading through. I have 3-4 people wanting to help out with the OSSNs, I've been really impressed with the response and I'm looking forward to seeing how this works moving forward. I'll send an email around those of you who wanted to help. My general thought is that I'll stay on to help out with OSSNs and generally co-ordinate the project. I'm looking for authors and editors to collaborate on individual OSSNs. My role would be to identify and accept new OSSNs, to occasionally author my own OSSNs and regularly edit/+1 the OSSNs of others. So, to those of you who are interested in helping out, are you anticipating authoring (which normally includes some amount of research) or editing? I am fine with authoring. We currently have 3 OSSNs waiting to be written, https://bugs.launchpad.net/ossn/+bugs perhaps between you it would be possible to make a start on 1-2 of them. Each OSSN follows the same template I would be happy to work on this one: https://bugs.launchpad.net/ossn/+bug/1237989 Thanks, -NGK Short title describing the issue --- ### Summary ### [One or two sentences discussing the issue, where it comes from and who it may affect.] ### Affected Services / Software ### [Freeform keywords, metadata, comma separated] Keystone, DevStack, Deployment ### Discussion ### [As much text as is required to describe the problem to a reasonably technical audience. This section should be written carefully and reviewed for content, grammar, spelling etc. When writing these sections consider that the OSSN will later be included in the OpenStack Security Guide, writing well here makes the process of mixing the OSSN into the Security Guide much easier later on. Code Snippets are welcome if they help illustrate the problem. ### Recommended Actions ### [Actions that should be taken to remediate or work around the problem, note that this will often include configuration snippets] ### Contacts / References ### This OSSN : [The URL of the OSSN] Original LaunchPad Bug : [The URL of the original Launchpad Bug, if there was one] OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg CVE: [Any CVE] [Any other References] From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: 14 November 2013 07:01 To: noloader at gmail.com Cc: Clark, Robert Graham; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OpenStack Security Notes - Contributors Wanted Rob - any emails yet? Are we meeting tomorrow? On Fri, Nov 8, 2013 at 2:59 AM, Sriram Subramanian > wrote: Perfect. Rob - please send those emails out. Jeff and I will try to get this rolling, Safe travels! On Fri, Nov 8, 2013 at 3:02 PM, Jeffrey Walton > wrote: Hi Robert, I'd be happy to help out with spare cycles. Jeff On Wed, Nov 6, 2013 at 11:08 AM, Clark, Robert Graham > wrote: > Hi All, > > I'm looking for help with the OpenStack Security Notes. I currently am struggling to keep up with them and do all the other things I'm involved in. Individually they don't take that much time so with one or two people helping out they wouldn't be a significant burden. > > If anyone wants to run the management of this project and publishing the OSSNs I'd be happy to support them in an editorial capacity. > > Cheers > -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 -- Thanks, -Sriram -- Thanks, -Sriram _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Nov 20 11:02:25 2013 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 20 Nov 2013 12:02:25 +0100 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: <20131120005849.GI2304@yuggoth.org> References: <20131120005849.GI2304@yuggoth.org> Message-ID: <528C96C1.7020002@openstack.org> Jeremy Stanley wrote: > If this is something the community is keen on, we can discuss > options within the VMT to enact a policy change like this (comments, > Thierry? Mikal?). I would really like to get to the point where we can have at least a target time-to-fix based on the vulnerability severity (like "High should be fixed and pushed out in less than 20 days"). That way we can at least measure how good or bad we are doing. The key to that, IMHO, is to have someone whose *primary* job is to make sure we reach those objectives - a security coordinator. I'm confident we'll soon have the resources to make that happen. And before anyone says "hey, I can help", please consider it's an extremely specific and time-consuming job. I'd definitely consider new candidates, but we have had a number of people trying to help the VMT in the past and most of them failed to handle more than one vulnerability over the course of their involvement... so I'm getting picky. People with open source SRT experience are definitely preferred, since they know what this thankless job is about :) > Keep in mind, however, that we don't delay > advisories and fixes at the request of an outside party or for > public image reasons. [...] Right, the current policy is a middle ground reflecting what our community is capable of delivering. As we improve on that we'll be able to cover a larger scope and have more aggressive deadlines... but there is no point in promising things that our community isn't capable of delivering. -- Thierry Carrez (ttx) From robert.clark at hp.com Wed Nov 20 14:38:35 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 20 Nov 2013 14:38:35 +0000 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: <528C96C1.7020002@openstack.org> References: <20131120005849.GI2304@yuggoth.org> <528C96C1.7020002@openstack.org> Message-ID: [...] > I would really like to get to the point where we can have at least a > target time-to-fix based on the vulnerability severity (like "High should > be fixed and pushed out in less than 20 days"). That way we can at least > measure how good or bad we are doing. The key to that, IMHO, is to > have someone whose *primary* job is to make sure we reach those > objectives - a security coordinator. I'm confident we'll soon have the > resources to make that happen. A target time to fix, once a vulnerability has been confirmed would be a good step to take. I'm not sure it could ever be something more than a guideline though with so much difference between the projects it'll be virtually impossible to impose any sort of cross-project time limit. > > And before anyone says "hey, I can help", please consider it's an > extremely specific and time-consuming job. I'd definitely consider new > candidates, but we have had a number of people trying to help the VMT > in the past and most of them failed to handle more than one > vulnerability over the course of their involvement... so I'm getting picky. > People with open source SRT experience are definitely preferred, since > they know what this thankless job is about :) I can second this. I think this is almost a full time job, as time goes on I expect that the number of vulnerabilities identified in OpenStack will increase somewhat and the ideal candidate would not only be very good security wise but intimately familiar with the OpenStack projects, where fixes need to be made and the right people to engage with to make fixes happen quickly - there aren't many people around that fit the bill! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From fungi at yuggoth.org Wed Nov 20 14:59:59 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 20 Nov 2013 14:59:59 +0000 Subject: [Openstack-security] OpenStack Security Group representation to the VMT In-Reply-To: <528C96C1.7020002@openstack.org> References: <20131120005849.GI2304@yuggoth.org> <528C96C1.7020002@openstack.org> Message-ID: <20131120145958.GK2304@yuggoth.org> On 2013-11-20 12:02:25 +0100 (+0100), Thierry Carrez wrote: [...] > Right, the current policy is a middle ground reflecting what our > community is capable of delivering. As we improve on that we'll be > able to cover a larger scope and have more aggressive deadlines... > but there is no point in promising things that our community isn't > capable of delivering. Right--the alternative I was driving at was whether there should be some age after which a vulnerability becomes public regardless of whether or not it's fixed. I expect that to be a contentious proposition, but it makes a good straw man/devil's advocate position to point out that there are things the VMT can control (such as public disclosure timeline) and things they can't (getting bugs fixed by a certain deadline). Any time-based policies we enact would have to be for the former, since as you and Robert pointed out any statements on the latter would be at best guidelines to measure our security response performance as a community. -- Jeremy Stanley From nkinder at redhat.com Wed Nov 20 15:53:54 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 20 Nov 2013 07:53:54 -0800 Subject: [Openstack-security] OpenStack Security Notes - Contributors Wanted In-Reply-To: References: <528B9345.9020706@redhat.com> <528BBCD7.6050306@redhat.com> Message-ID: <528CDB12.5050203@redhat.com> On 11/19/2013 11:33 PM, Clark, Robert Graham wrote: > > Great job on the OSSN Nathan, it looks very good, I've put one comment > on it for a very minor change and then I'd say it's ready for publishing. > Thanks for the review! I'll make that correction this morning. > > I'm wondering - should I continue to publish OSSNs when they're ready > or would you like to submit direct to the mailing lists? > I'm happy to submit them myself. Just let me know what lists you've been publishing to so I make sure that I don't miss any of them. Thanks, -NGK > > *From:*Nathan Kinder [mailto:nkinder at redhat.com] > *Sent:* 19 November 2013 19:33 > *To:* Sriram Subramanian > *Cc:* Clark, Robert Graham; noloader at gmail.com; > openstack-security at lists.openstack.org > *Subject:* Re: [Openstack-security] OpenStack Security Notes - > Contributors Wanted > > On 11/19/2013 10:58 AM, Sriram Subramanian wrote: > > Darn, you beat me on that bug:) > > Sorry. :) I've previously discussed this bug with some of the > Keystone developers, so it seemed like one that I can easily handle. > I'm just about finished writing up the first draft. This is my first > OSSN, so I'd love for it to get a thorough review. > > Thanks, > -NGK > > I will take https://bugs.launchpad.net/ossn/+bug/1227575 > > Thanks, > > -Sriram > > On Tue, Nov 19, 2013 at 8:35 AM, Nathan Kinder > wrote: > > On 11/19/2013 05:46 AM, Clark, Robert Graham wrote: > > Hi All, > > I've had a little downtime recently due to being horribly > ill - I'm glad to say I've been feeling much better > recently but I have a rather impressive pile of emails > that I'm currently wading through. I have 3-4 people > wanting to help out with the OSSNs, I've been really > impressed with the response and I'm looking forward to > seeing how this works moving forward. I'll send an email > around those of you who wanted to help. > > My general thought is that I'll stay on to help out with > OSSNs and generally co-ordinate the project. I'm looking > for authors and editors to collaborate on individual > OSSNs. My role would be to identify and accept new OSSNs, > to occasionally author my own OSSNs and regularly edit/+1 > the OSSNs of others. > > So, to those of you who are interested in helping out, are > you anticipating authoring (which normally includes some > amount of research) or editing? > > I am fine with authoring. > > > > We currently have 3 OSSNs waiting to be written, > https://bugs.launchpad.net/ossn/+bugs perhaps between you > it would be possible to make a start on 1-2 of them. Each > OSSN follows the same template > > I would be happy to work on this one: > > https://bugs.launchpad.net/ossn/+bug/1237989 > > Thanks, > -NGK > > > > Short title describing the issue > > --- > > ### Summary ### > [One or two sentences discussing the issue, where it comes > from and who it may affect.] > > ### Affected Services / Software ### > [Freeform keywords, metadata, comma separated] Keystone, > DevStack, Deployment > > ### Discussion ### > > [As much text as is required to describe the problem to a > reasonably technical audience. This section should be > written carefully and reviewed for content, grammar, > spelling etc. When writing these sections consider that > the OSSN will later be included in the OpenStack Security > Guide, writing well here makes the process of mixing the > OSSN into the Security Guide much easier later on. Code > Snippets are welcome if they help illustrate the problem. > > ### Recommended Actions ### > [Actions that should be taken to remediate or work around > the problem, note that this will often include > configuration snippets] > > ### Contacts / References ### > This OSSN : [The URL of the OSSN] > Original LaunchPad Bug : [The URL of the original > Launchpad Bug, if there was one] > OpenStack Security ML : > openstack-security at lists.openstack.org > > OpenStack Security Group : > https://launchpad.net/~openstack-ossg > > CVE: [Any CVE] > > [Any other References] > > *From:*Sriram Subramanian [mailto:sriram at sriramhere.com] > *Sent:* 14 November 2013 07:01 > *To:* noloader at gmail.com > *Cc:* Clark, Robert Graham; > openstack-security at lists.openstack.org > > *Subject:* Re: [Openstack-security] OpenStack Security > Notes - Contributors Wanted > > Rob - any emails yet? Are we meeting tomorrow? > > On Fri, Nov 8, 2013 at 2:59 AM, Sriram Subramanian > > wrote: > > Perfect. > > Rob - please send those emails out. Jeff and I will try to > get this rolling, Safe travels! > > On Fri, Nov 8, 2013 at 3:02 PM, Jeffrey Walton > > wrote: > > Hi Robert, > > I'd be happy to help out with spare cycles. > > Jeff > > > On Wed, Nov 6, 2013 at 11:08 AM, Clark, Robert Graham > > wrote: > > Hi All, > > > > I'm looking for help with the OpenStack Security Notes. > I currently am struggling to keep up with them and do all > the other things I'm involved in. Individually they don't > take that much time so with one or two people helping out > they wouldn't be a significant burden. > > > > If anyone wants to run the management of this project > and publishing the OSSNs I'd be happy to support them in > an editorial capacity. > > > > Cheers > > -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 > > > > -- > > Thanks, > > -Sriram > > > > -- > > Thanks, > > -Sriram > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > -- > > Thanks, > > -Sriram > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Wed Nov 20 15:57:59 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 20 Nov 2013 15:57:59 -0000 Subject: [Openstack-security] [Bug 1237989] Re: user can update his password without knowing the old password References: <20131010124138.28096.87746.malonedeb@chaenomeles.canonical.com> Message-ID: <20131120155800.19770.92131.malone@chaenomeles.canonical.com> Authenticated users are able to update passwords without providing their current password --- ### Summary ### An authenticated user is able to change their password without providing their current password. This allows compromised authentication tokens to be used to permanently compromise a user account. ### Affected Services / Software ### Horizon, Keystone, Identity, Grizzly ### Discussion ### Horizon allows a user to change their own password, which uses the Identity API to perform the password change. A user is required to supply their current password to successfully perform a password change. This requirement prevents a malicious user from stealing a user's authentication token and changing that user's password to permanently compromise their account. With this additional password check, a compromised authentication token only compromises the user account until the token is no longer valid due to expiration or revocation. When using the Identity v3 API, a user is able to successfully change their password without supplying the correct current password. This leaves users vulnerable to permanently compromised accounts if their authentication token is compromised. The Identity v2 API is not vulnerable to this issue, as it has a separate API call for updating user passwords that properly validates the current password. ### Recommended Actions ### In the OpenStack Grizzly release, a user is allowed to update the attributes in their own entry by default. It is recommended that you restrict user updates to only be allowed by admin users. This is done by setting the "update_user" policy to "admin_required" in Keystone's policy.json file. Here is an example snippet of a properly configured policy.json file: ---- begin example policy.json snippet ---- "identity:get_user": [["rule:admin_required"]], "identity:list_users": [["rule:admin_required"]], "identity:create_user": [["rule:admin_required"]], "identity:update_user": [["rule:admin_required"]], "identity:delete_user": [["rule:admin_required"]], ---- end example policy.json snippet ---- This change has the side-effect of restricting a user from updating any of their own attributes, not just their password. In the OpenStack Havana release, the default policy is to only allow admin users to update attributes in user entries. In addition, Horizon will not allow a user to change their own password if it is using the Identity v3 API, even if Keystone is configured to allow users to update their own entries. Despite this restriction in Horizon, it is recommended to leave the default "update_user" policy setting as is, as an attacker could target Keystone directly without using Horizon to initiate a password change. ### Contacts / References ### This OSSN : https://bugs.launchpad.net/ossn/+bug/1237989 Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1237989 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg CVE: CVE-2013-4471 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: In Progress Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions From thierry.carrez+lp at gmail.com Wed Nov 20 15:55:42 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 20 Nov 2013 15:55:42 -0000 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com> Message-ID: <20131120155543.27699.48854.launchpad@gac.canonical.com> ** 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/1227575 Title: DoS style attack on noVNC server can lead to service interruption or disruption Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Notes: New Bug description: There is no limiting on the number of VNC sessions that can be created for a single user's VNC token. Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server results in many connection timeouts. Due to these connection timeout error, other users trying to access their VM's VNC console cannot do so. A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors Script: http://paste.openstack.org/show/47254/ Script output.... connections get timed out after a while ------------------- .... .. Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out -------------------- Impact: 1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail. This can cause serious problems to users already having a running VNC session or trying to create new sessions. 2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol also gets affected after the connection timeout errors. For example: Before running the sumulate thousands of connections program: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 | +-------+---------------------------------------------------------------------------------+ real 0m0.751s user 0m0.376s sys 0m0.084s rohit at precise-dev-102:~/tools/websocket-client-0.7.0$ After running the program, the response time is quite high: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 | +-------+---------------------------------------------------------------------------------+ real 3m9.231s user 0m0.424s sys 0m0.108s Possible solutions: 1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple connections for the same token, and return an error code to the user. 2. Make the number of sessions allowed per instance configurable, limited by some count of sessions. However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class, which can lead to maintenance issues. Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token for reconnection. This would first need contribution to the websockify project code, and then update Nova. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions From bdpayne at acm.org Wed Nov 20 17:45:18 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 20 Nov 2013 17:45:18 -0000 Subject: [Openstack-security] OSSG: Help Wanted! Message-ID: <20131120174518.10094.79106.launchpad@soybean.canonical.com> Now that the summit is behind us it's time to look forward to how the OpenStack Security Group can work to improve the security of the Icehouse release, and promote general security awareness throughout the community. As the last IRC meeting (minutes here: https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity), we discussed that there are many areas where OSSG could use your help. I'm including the list below with hopes of reaching the broader OSSG community. If you haven't yet found a way to be involved in the group, now is the perfect time to step up and make an impact. Please send any questions to me, or just speak up at our regular IRC meeting (Thursdays at 1800 UTC). Here's a quick list of the areas where you can help: * OpenStack Security Notes (OSSN): more contributors, goal to publish 1 per week - we have had some people step up for this, but more are always welcome * OpenStack Security Guide (aka "The Book"): 2-3 editors, push ahead with improvements * OSSG Community Manager: group visibility, emails, newsletter, etc... - we have filled this role, watch for a separate announcement shortly * Threat Analysis: new effort by Ericson - https://wiki.openstack.org/wiki/Security/Threat_Analysis - Ericson leading the way, more help is always welcome * OSSA / OSSN: posting, archiving, structured feeds... joint with VMT * Dev Sprints: tbd, led by Eric Windisch - need devs to be involved - stay tuned for the topic / dates / etc * OSSG reps to the VMT - thanks to Rob Clark (HP) and Joel Coffman (APL) for taking this on * All integrated projects need security devs!! For more ideas of how you can contribute please see https://wiki.openstack.org/wiki/Security/How_To_Contribute. Cheers, -bryan PS... It's also worth noting that the OSSG has now grown to over 100 members. Please help me turn that interest into action! -- This message was sent from Launchpad by Bryan D. Payne (https://launchpad.net/~bdpayne) to each member of the OpenStack Security Group team using the "Contact this team" link on the OpenStack Security Group team page (https://launchpad.net/~openstack-ossg). For more information see https://help.launchpad.net/YourAccount/ContactingPeople From noloader at gmail.com Wed Nov 20 19:58:28 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 20 Nov 2013 14:58:28 -0500 Subject: [Openstack-security] Copy/Paste Protection for Object Store Message-ID: I've been mulling over copy/paste attacks for data in the object store. In this use case, imagine the object store holds an encrypted copy of a document or spreadsheet. The organization would encrypt the document before storing it in the object store. Are there any sever side controls available to ensure a new copy of an encrypted document is not replaced with an old copy? For example, is there server side functionality or hook that allows an organization to enforce the new document's signed time stamp is fresher than existing document's time stamp? Thanks in advance. From bdpayne at acm.org Wed Nov 20 21:21:49 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 20 Nov 2013 13:21:49 -0800 Subject: [Openstack-security] OSSG Community Manager Message-ID: I'd like to welcome Nathan Kinder to the OpenStack Security Group. Nathan is somewhat new to OpenStack, but is jumping in feet first. You may have noticed him in our recent meeting, or as the author of the latest OSSN. As the Community Manager, Nathan will take the lead on ensuring that the work happening in OSSG is known by others in the community. And he'll help us focus our involvement in conferences and other such events. Nathan's Bio: Nathan is a Manager in Software Engineering at Red Hat, where he manages the development of the Red Hat Directory Server and Red Hat Certificate System products. He has been a developer on the 389 Directory Server project since it's inception, and has a long history of working with LDAP and X.509 certificate management. Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Nov 21 16:20:43 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 21 Nov 2013 16:20:43 -0000 Subject: [Openstack-security] [Bug 1251647] Re: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason References: <20131115144107.27303.99752.malonedeb@gac.canonical.com> Message-ID: <20131121162044.19869.52151.launchpad@chaenomeles.canonical.com> ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251647 Title: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason Status in Orchestration API (Heat): Triaged Status in OpenStack Security Advisories: Invalid Bug description: In the following commit: https://github.com/openstack/heat/commit/58cd52624b50476ed5ed1c5c0ba7cb1b4d7ba66d ... a decision was introduced to encrypt authentication information using unauthenticated AES-CFB. There's a few things I don't like about that commit, but suffice to say that heat/engine/auth.py should probably not be a place where symmetric crypto decisions are made. I've been told that there's a new public API for symmetric encryption, SymmetricCrypto that lives in openstack/common/crypto/utils.py: https://github.com/openstack/oslo- incubator/blob/master/openstack/common/crypto/utils.py#L99 I think that also gets a few things wrong, but at the very least Heat should use a centralized thing for encrypting stuff. (I'd love to complain about and work on SymmetricCrypto too, but that's not this ticket :) To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1251647/+subscriptions From bdpayne at acm.org Thu Nov 21 17:08:02 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 21 Nov 2013 17:08:02 -0000 Subject: [Openstack-security] [Bug 1251647] Re: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason References: <20131115144107.27303.99752.malonedeb@gac.canonical.com> Message-ID: <20131121170802.7313.81950.malone@wampee.canonical.com> I completely agree with the OP that this is a bad security practice. I would also be interested in a discussion about his concerns about the implementation in Oslo. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251647 Title: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason Status in Orchestration API (Heat): Triaged Status in OpenStack Security Advisories: Invalid Bug description: In the following commit: https://github.com/openstack/heat/commit/58cd52624b50476ed5ed1c5c0ba7cb1b4d7ba66d ... a decision was introduced to encrypt authentication information using unauthenticated AES-CFB. There's a few things I don't like about that commit, but suffice to say that heat/engine/auth.py should probably not be a place where symmetric crypto decisions are made. I've been told that there's a new public API for symmetric encryption, SymmetricCrypto that lives in openstack/common/crypto/utils.py: https://github.com/openstack/oslo- incubator/blob/master/openstack/common/crypto/utils.py#L99 I think that also gets a few things wrong, but at the very least Heat should use a centralized thing for encrypting stuff. (I'd love to complain about and work on SymmetricCrypto too, but that's not this ticket :) To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1251647/+subscriptions From nkinder at redhat.com Thu Nov 21 18:00:24 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 21 Nov 2013 10:00:24 -0800 Subject: [Openstack-security] OSSG Community Manager In-Reply-To: References: Message-ID: <528E4A38.9020004@redhat.com> On 11/20/2013 01:21 PM, Bryan D. Payne wrote: > I'd like to welcome Nathan Kinder to the OpenStack Security Group. > Nathan is somewhat new to OpenStack, but is jumping in feet first. > You may have noticed him in our recent meeting, or as the author of > the latest OSSN. > > As the Community Manager, Nathan will take the lead on ensuring that > the work happening in OSSG is known by others in the community. And > he'll help us focus our involvement in conferences and other such events. Thanks for the intro Bryan. I'm excited to be a part of the team! -NGK > > Nathan's Bio: > Nathan is a Manager in Software Engineering at Red Hat, where he > manages the development of the Red Hat Directory Server and Red Hat > Certificate System products. He has been a developer on the 389 > Directory Server project since it's inception, and has a long history > of working with LDAP and X.509 certificate management. > > Cheers, > -bryan > > > _______________________________________________ > 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 sriram at sriramhere.com Thu Nov 21 17:59:31 2013 From: sriram at sriramhere.com (SriramHere) Date: Thu, 21 Nov 2013 17:59:31 -0000 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com> Message-ID: <20131121175931.27272.32913.malone@gac.canonical.com> I'll start preparing an OSSN for this. ** Changed in: ossn Assignee: (unassigned) => SriramHere (sriramhere) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1227575 Title: DoS style attack on noVNC server can lead to service interruption or disruption Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Notes: New Bug description: There is no limiting on the number of VNC sessions that can be created for a single user's VNC token. Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server results in many connection timeouts. Due to these connection timeout error, other users trying to access their VM's VNC console cannot do so. A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors Script: http://paste.openstack.org/show/47254/ Script output.... connections get timed out after a while ------------------- .... .. Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out -------------------- Impact: 1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail. This can cause serious problems to users already having a running VNC session or trying to create new sessions. 2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol also gets affected after the connection timeout errors. For example: Before running the sumulate thousands of connections program: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 | +-------+---------------------------------------------------------------------------------+ real 0m0.751s user 0m0.376s sys 0m0.084s rohit at precise-dev-102:~/tools/websocket-client-0.7.0$ After running the program, the response time is quite high: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 | +-------+---------------------------------------------------------------------------------+ real 3m9.231s user 0m0.424s sys 0m0.108s Possible solutions: 1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple connections for the same token, and return an error code to the user. 2. Make the number of sessions allowed per instance configurable, limited by some count of sessions. However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class, which can lead to maintenance issues. Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token for reconnection. This would first need contribution to the websockify project code, and then update Nova. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions From robert.clark at hp.com Thu Nov 21 19:05:55 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 21 Nov 2013 19:05:55 +0000 Subject: [Openstack-security] OSSG Community Manager In-Reply-To: References: Message-ID: You mean not only will we have a community manager of awesomeness but I'll also have someone to beat up about Dogtag!? Fantastic! Welcome on-board Nathan, looking forward to working with you. Good work on the OSSN! From: Bryan D. Payne [mailto:bdpayne at acm.org] Sent: 20 November 2013 21:22 To: openstack-security at lists.openstack.org Subject: [Openstack-security] OSSG Community Manager I'd like to welcome Nathan Kinder to the OpenStack Security Group. Nathan is somewhat new to OpenStack, but is jumping in feet first. You may have noticed him in our recent meeting, or as the author of the latest OSSN. As the Community Manager, Nathan will take the lead on ensuring that the work happening in OSSG is known by others in the community. And he'll help us focus our involvement in conferences and other such events. Nathan's Bio: Nathan is a Manager in Software Engineering at Red Hat, where he manages the development of the Red Hat Directory Server and Red Hat Certificate System products. He has been a developer on the 389 Directory Server project since it's inception, and has a long history of working with LDAP and X.509 certificate management. Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Thu Nov 21 19:44:25 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 21 Nov 2013 19:44:25 +0000 Subject: [Openstack-security] Missed OSSG Meeting. Message-ID: For those of you who, like me, somehow managed to turn up an hour late! http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-11-21-18.00.log.html First off I'd like to Nathan for taking on the roll of Community Manager, I'm looking forward to working with you Nathan. I thought it was nice to see that the OSSG is mentioned on the How To Contribute landing page for OpenStack https://wiki.openstack.org/wiki/CLA#Contributors_License_Agreement I notice there's some discussion of editing the Security Guide. I've done a number of edits previously, if nothing else it's a good way of getting used to the OpenStack commit process: https://wiki.openstack.org/wiki/Gerrit_Workflow Threat analysis is a thing! https://wiki.openstack.org/wiki/Security/Threat_analysis -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Thu Nov 21 19:56:53 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 21 Nov 2013 11:56:53 -0800 Subject: [Openstack-security] Missed OSSG Meeting. In-Reply-To: References: Message-ID: > > I thought it was nice to see that the OSSG is mentioned on the How To > Contribute landing page for OpenStack > https://wiki.openstack.org/wiki/CLA#Contributors_License_Agreement > Yeah, I added that a while back :-) -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kseifried at redhat.com Thu Nov 21 21:01:23 2013 From: kseifried at redhat.com (Kurt Seifried) Date: Thu, 21 Nov 2013 21:01:23 -0000 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com> Message-ID: <20131121210123.27432.89482.malone@gac.canonical.com> This appears to be a security issue, a single user can prevent any access for all other users to the system, with no way (currently) to prevent it. Why was this classed as security hardening and not a security flaw (am I missing something, like it can't be exploited outside of a non standard/unsafe config or something?). -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1227575 Title: DoS style attack on noVNC server can lead to service interruption or disruption Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Notes: New Bug description: There is no limiting on the number of VNC sessions that can be created for a single user's VNC token. Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server results in many connection timeouts. Due to these connection timeout error, other users trying to access their VM's VNC console cannot do so. A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors Script: http://paste.openstack.org/show/47254/ Script output.... connections get timed out after a while ------------------- .... .. Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out -------------------- Impact: 1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail. This can cause serious problems to users already having a running VNC session or trying to create new sessions. 2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol also gets affected after the connection timeout errors. For example: Before running the sumulate thousands of connections program: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 | +-------+---------------------------------------------------------------------------------+ real 0m0.751s user 0m0.376s sys 0m0.084s rohit at precise-dev-102:~/tools/websocket-client-0.7.0$ After running the program, the response time is quite high: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 | +-------+---------------------------------------------------------------------------------+ real 3m9.231s user 0m0.424s sys 0m0.108s Possible solutions: 1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple connections for the same token, and return an error code to the user. 2. Make the number of sessions allowed per instance configurable, limited by some count of sessions. However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class, which can lead to maintenance issues. Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token for reconnection. This would first need contribution to the websockify project code, and then update Nova. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions From thierry.carrez+lp at gmail.com Fri Nov 22 09:14:37 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 22 Nov 2013 09:14:37 -0000 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com> Message-ID: <20131122091437.27582.27210.malone@gac.canonical.com> This one is a classic DoS attack on an endpoint, without amplification. There are two ways of mitigating that issue in a public cloud setting: externally (by deploying rate-limiting proxies) or internally (by adding a rate-limiting feature in Nova novnc proxy itself). Adding a feature to a stable release in not an option for us. So we pursue two different axis: - warn users of current stable versions to use rate-limiting proxies to also cover access to the noVNC servers (this is not the first, nor the last place in OpenStack where DoS needs to be mitigated externally). This is what the OSSN that Sriram prepares will recommend - introduce a new feature to be able to mitigate that within the noVNC proxy, to be shipped in the Icehouse release In summary, this is definitely a vulnerability, but since it can't be closed without adding a disrupting change in stable releases (which is what an OSSA would have been for), we opted for a "known issue warning + best practice on how to mitigate it" (OSSN) + feature-fix in next version. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1227575 Title: DoS style attack on noVNC server can lead to service interruption or disruption Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Notes: New Bug description: There is no limiting on the number of VNC sessions that can be created for a single user's VNC token. Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server results in many connection timeouts. Due to these connection timeout error, other users trying to access their VM's VNC console cannot do so. A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors Script: http://paste.openstack.org/show/47254/ Script output.... connections get timed out after a while ------------------- .... .. Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out -------------------- Impact: 1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail. This can cause serious problems to users already having a running VNC session or trying to create new sessions. 2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol also gets affected after the connection timeout errors. For example: Before running the sumulate thousands of connections program: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 | +-------+---------------------------------------------------------------------------------+ real 0m0.751s user 0m0.376s sys 0m0.084s rohit at precise-dev-102:~/tools/websocket-client-0.7.0$ After running the program, the response time is quite high: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 | +-------+---------------------------------------------------------------------------------+ real 3m9.231s user 0m0.424s sys 0m0.108s Possible solutions: 1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple connections for the same token, and return an error code to the user. 2. Make the number of sessions allowed per instance configurable, limited by some count of sessions. However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class, which can lead to maintenance issues. Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token for reconnection. This would first need contribution to the websockify project code, and then update Nova. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions From nkinder at redhat.com Fri Nov 22 22:12:16 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 22 Nov 2013 22:12:16 -0000 Subject: [Openstack-security] [Bug 1237989] Re: user can update his password without knowing the old password References: <20131010124138.28096.87746.malonedeb@chaenomeles.canonical.com> Message-ID: <20131122221216.19538.6690.malone@chaenomeles.canonical.com> Published on OpenStack and OpenStack-Dev mailing lists on 22 Nov 2013. ** 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/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: Fix Released Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions From gerrit2 at review.openstack.org Sun Nov 24 03:08:01 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 24 Nov 2013 03:08:01 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ic633e427fde7d161427ff6b59c83535cff374fd5 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/58124 Log: commit 82e116ad5c60f47dd669701de0838ef0ed462069 Author: Simo Sorce Date: Mon Oct 14 16:28:05 2013 +1000 Initial KDS service The Key Distribution Service is used to register keys for services and distribute tickets to contact othe services. The KDS is used to digitally sign and optionally encrypt messages sent over the message queue by the rpc modules. KDS is designed to split off into its own service: the concept is incubating in Keystone, but there is very little/none of it that interacts with core Keystone. It implements the service described in this document: https://wiki.openstack.org/wiki/MessageSecurity#A_Key_Distribution_Server_in_Keystone DocImpact SecurityImpact blueprint key-distribution-server Change-Id: Ic633e427fde7d161427ff6b59c83535cff374fd5 Co-Authored-By: Jamie Lennox Co-Authored-By: Adam Young From thomas at suse.de Mon Nov 25 19:31:32 2013 From: thomas at suse.de (Thomas Biege) Date: Mon, 25 Nov 2013 20:31:32 +0100 Subject: [Openstack-security] OSSG Community Manager In-Reply-To: References: Message-ID: <5293A594.4070008@suse.de> Hello Nathan, welcome to the OSSG! Best, Thomas Am 20.11.13 22:21, schrieb Bryan D. Payne: > I'd like to welcome Nathan Kinder to the OpenStack Security Group. > Nathan is somewhat new to OpenStack, but is jumping in feet first. You > may have noticed him in our recent meeting, or as the author of the > latest OSSN. > > As the Community Manager, Nathan will take the lead on ensuring that the > work happening in OSSG is known by others in the community. And he'll > help us focus our involvement in conferences and other such events. > > Nathan's Bio: > Nathan is a Manager in Software Engineering at Red Hat, where he manages > the development of the Red Hat Directory Server and Red Hat Certificate > System products. He has been a developer on the 389 Directory Server > project since it's inception, and has a long history of working with > LDAP and X.509 certificate management. > > Cheers, > -bryan > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Thomas Biege , Team Leader MaintenanceSecurity, CSSLP SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 21284 (AG Nürnberg) -- Wer aufhoert besser werden zu wollen, hoert auf gut zu sein. -- Marie von Ebner-Eschenbach -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 560 bytes Desc: OpenPGP digital signature URL: From robert.clark at hp.com Mon Nov 25 19:31:31 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 25 Nov 2013 19:31:31 +0000 Subject: [Openstack-security] No OSSG meeting this Thursday Message-ID: Hi all, Due to Thursday being a US holiday, I'd like to remind you all that the OSSG meeting this week is cancelled and wish you all a happy Thanks Giving! Cheers -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From sriram at sriramhere.com Tue Nov 26 04:08:28 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 25 Nov 2013 20:08:28 -0800 Subject: [Openstack-security] No OSSG meeting this Thursday In-Reply-To: References: Message-ID: Happy Thanks Giving everybody! I will be missing the Dec 5th meeting as I will be traveling. Will catch up from the logs. Thanks! On Mon, Nov 25, 2013 at 11:31 AM, Clark, Robert Graham wrote: > Hi all, > > > > Due to Thursday being a US holiday, I’d like to remind you all that the > OSSG meeting this week is cancelled and wish you all a happy Thanks Giving! > > > > Cheers > > -Rob > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry.carrez+lp at gmail.com Wed Nov 27 11:25:38 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 27 Nov 2013 11:25:38 -0000 Subject: [Openstack-security] [Bug 1236125] Re: PowerVM driver ignores host keys References: <20131007013845.5908.7483.malonedeb@soybean.canonical.com> Message-ID: <20131127112542.9464.20161.launchpad@chaenomeles.canonical.com> ** Changed in: nova Status: Triaged => 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/1236125 Title: PowerVM driver ignores host keys Status in OpenStack Compute (Nova): Won't Fix Bug description: Nova's PowerVM driver is currently set to AutoAdd any host key over SSH. As per the SSH protocol, host key fingerprints should be verified either by comparing with known hosts (like through a known_hosts file) or having a person verify its the host they wish to connect with. In particular, https://github.com/openstack/nova/blob/master/nova/virt/powervm/common.py uses paramiko.AutoAddPolicy() which will automatically accept any host key. Doing so allows Nova to be susceptible to a man-in-the-middle. There should instead be an option in nova.conf to specify a known_hosts file and the paramiko policy to use. That way someone could set the policy to Reject and specify a file with known_hosts which are acceptable. Communication therefore would never occur to unknown hosts and allow a potential release of a user/pwd. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1236125/+subscriptions From kseifried at redhat.com Thu Nov 28 21:40:25 2013 From: kseifried at redhat.com (Kurt Seifried) Date: Thu, 28 Nov 2013 21:40:25 -0000 Subject: [Openstack-security] [Bug 1236125] Re: PowerVM driver ignores host keys References: <20131007013845.5908.7483.malonedeb@soybean.canonical.com> Message-ID: <20131128214025.31322.73385.malone@chaenomeles.canonical.com> Depending on the documentation this sounds like it might be a security vulnerability. Even if the code is removed it was present and vulnerable (and thus a CVE may be needed). -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1236125 Title: PowerVM driver ignores host keys Status in OpenStack Compute (Nova): Won't Fix Bug description: Nova's PowerVM driver is currently set to AutoAdd any host key over SSH. As per the SSH protocol, host key fingerprints should be verified either by comparing with known hosts (like through a known_hosts file) or having a person verify its the host they wish to connect with. In particular, https://github.com/openstack/nova/blob/master/nova/virt/powervm/common.py uses paramiko.AutoAddPolicy() which will automatically accept any host key. Doing so allows Nova to be susceptible to a man-in-the-middle. There should instead be an option in nova.conf to specify a known_hosts file and the paramiko policy to use. That way someone could set the policy to Reject and specify a file with known_hosts which are acceptable. Communication therefore would never occur to unknown hosts and allow a potential release of a user/pwd. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1236125/+subscriptions From kseifried at redhat.com Fri Nov 29 03:28:00 2013 From: kseifried at redhat.com (Kurt Seifried) Date: Fri, 29 Nov 2013 03:28:00 -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: <20131129032800.32442.10413.malone@gac.canonical.com> Ping, I assume this is not being treated as security flaw, can anyone confirm that? thanks. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/890411 Title: Tenant role conflicts/overlaps can be a security issue Status in OpenStack Identity (Keystone): Confirmed 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 gerrit2 at review.openstack.org Fri Nov 29 05:55:33 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 29 Nov 2013 05:55:33 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40692 Log: commit b775259ef1c06884985521fbba7cabc30884565a Author: Simo Sorce Date: Wed Aug 7 14:16:28 2013 -0400 Key Distribution Server API for distribution of keys in support of: https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation SecurityImpact Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df From noloader at gmail.com Fri Nov 29 08:49:20 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 29 Nov 2013 03:49:20 -0500 Subject: [Openstack-security] Fwd: [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df In-Reply-To: References: Message-ID: Does anyone know if there's going to be any calls covering Message Security as proposed at https://wiki.openstack.org/wiki/MessageSecurity? I'd be very interested in listening in. Thanks in advance, Jeff FYI|PS: Dr. Rogaway is providing royalty free, irrevocable licenses for OCB mode in open source projects (http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm). OpenSSL's grant can be found at http://wiki.openssl.org/images/6/66/OCB-patent-grant-OpenSSL.pdf. OCB is the most efficient AE and AEAD mode available (as far as I know). When operating in OCB mode, there's no need for combining privacy modes like CBC with integrity protections like HMACs; nor is there a need for key derivation functions to ensure key independence. Other AEAD choices include the usual suspects, such as CCM, EAX and GCM mode. But they are less efficient than OCB due to Dr. Rogaway's patent. And +1 for not choosing a mode like EAX Prime for message security like the smart grid ;) ---------- Forwarded message ---------- From: Date: Fri, Nov 29, 2013 at 12:55 AM Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df To: openstack-security at lists.openstack.org Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40692 Log: commit b775259ef1c06884985521fbba7cabc30884565a Author: Simo Sorce Date: Wed Aug 7 14:16:28 2013 -0400 Key Distribution Server API for distribution of keys in support of: https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation SecurityImpact Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df From nkinder at redhat.com Sat Nov 30 19:44:25 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Sat, 30 Nov 2013 11:44:25 -0800 Subject: [Openstack-security] Fwd: [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df In-Reply-To: References: Message-ID: <529A4019.20808@redhat.com> On 11/29/2013 12:49 AM, Jeffrey Walton wrote: > Does anyone know if there's going to be any calls covering Message > Security as proposed at > https://wiki.openstack.org/wiki/MessageSecurity? I'd be very > interested in listening in. Hi Jeff, I'm not sure if there are any actual calls scheduled, but this was a discussion topic on the Keystone weekly IRC meeting last week. I expect that it will be a topic this coming week as well. You might want to join in: https://wiki.openstack.org/wiki/Meetings#Keystone_team_meeting The document you reference needs some updating, as I feel that it dives into some low-level detail without providing enough high-level background for those who aren't familiar with similar key distribution schemes. I plan to take a pass at cleaning this up in the next few days. Is there anything in particular about this effort that you want to discuss, or do you just want to follow what is happening? Thanks, -NGK > > Thanks in advance, > > Jeff > > FYI|PS: Dr. Rogaway is providing royalty free, irrevocable licenses > for OCB mode in open source projects > (http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm). OpenSSL's grant > can be found at > http://wiki.openssl.org/images/6/66/OCB-patent-grant-OpenSSL.pdf. > > OCB is the most efficient AE and AEAD mode available (as far as I > know). When operating in OCB mode, there's no need for combining > privacy modes like CBC with integrity protections like HMACs; nor is > there a need for key derivation functions to ensure key independence. > > Other AEAD choices include the usual suspects, such as CCM, EAX and > GCM mode. But they are less efficient than OCB due to Dr. Rogaway's > patent. > > And +1 for not choosing a mode like EAX Prime for message security > like the smart grid ;) > > ---------- Forwarded message ---------- > From: > Date: Fri, Nov 29, 2013 at 12:55 AM > Subject: [Openstack-security] [openstack/identity-api] SecurityImpact > review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df > To: openstack-security at lists.openstack.org > > Hi, I'd like you to take a look at this patch for potential > SecurityImpact. > https://review.openstack.org/40692 > > Log: > commit b775259ef1c06884985521fbba7cabc30884565a > Author: Simo Sorce > Date: Wed Aug 7 14:16:28 2013 -0400 > > Key Distribution Server > > API for distribution of keys in support of: > https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation > > SecurityImpact > > Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > From annegentle at justwriteclick.com Tue Nov 19 20:04:52 2013 From: annegentle at justwriteclick.com (Anne Gentle) Date: Tue, 19 Nov 2013 20:04:52 -0000 Subject: [Openstack-security] [Openstack-docs] Security Guide - No longer on Lulu? In-Reply-To: References: Message-ID: Hi Eric and everyone, I'm going to the Lulu link on http://docs.openstack.org/sec/ and finding the printed copy available for purchase just fine. However it seems I need to set to public access. I've done that now, let me know if you're able to click through. Also, if anyone wants to buy 50 copies or more, they can go through me to get a 50% off discount. Thanks, Anne On Tue, Nov 19, 2013 at 1:55 PM, Bryan D. Payne wrote: > Hmm, I wasn't aware of this. I'm cc'ing the docs list as they will know > more, but it's worth keeping both groups aware of what's happening here. > -bryan > > > On Tue, Nov 19, 2013 at 11:39 AM, Eric Windisch wrote: > >> It seems the Lulu link for the Security Guide is dead (was: >> http://www.lulu.com/commerce/index.php?fBuyContent=13956188) >> >> Searching on Lulu itself no longer finds the guide, either. >> >> It would be great if we could get the book back onto lulu, available for >> purchase somewhere else, and/or remove the Lulu link from the book's >> homepage (http://docs.openstack.org/sec/) >> >> If appropriate, I can reraise this with the docs group, if they're now >> the owners. >> >> Regards, >> Eric Windisch >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> > > _______________________________________________ > Openstack-docs mailing list > Openstack-docs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs > > -- Anne Gentle annegentle at justwriteclick.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1237989 at bugs.launchpad.net Wed Nov 20 07:20:51 2013 From: 1237989 at bugs.launchpad.net (Robert Clark) Date: Wed, 20 Nov 2013 07:20:51 -0000 Subject: [Openstack-security] [Bug 1237989] Re: user can update his password without knowing the old password References: <20131010124138.28096.87746.malonedeb@chaenomeles.canonical.com> Message-ID: <20131120071320.27699.568.launchpad@gac.canonical.com> ** Changed in: ossn Importance: Undecided => Critical -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: In Progress Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions From 1237989 at bugs.launchpad.net Wed Nov 20 07:35:46 2013 From: 1237989 at bugs.launchpad.net (Robert Clark) Date: Wed, 20 Nov 2013 07:35:46 -0000 Subject: [Openstack-security] [Bug 1237989] Re: user can update his password without knowing the old password References: <20131010124138.28096.87746.malonedeb@chaenomeles.canonical.com> Message-ID: <20131120072935.7251.69947.malone@wampee.canonical.com> Great OSSN, I'd say it'd ready to publish pretty much. In the third sentence of the discussion "a users" needs to read "a user's" -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1237989 Title: user can update his password without knowing the old password Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Security Notes: In Progress Bug description: a user logged into horizon can change his password without needing to type in the correct old password. It's just required to type in anything as the old password. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1237989/+subscriptions From mriedem at us.ibm.com Thu Nov 21 23:35:46 2013 From: mriedem at us.ibm.com (Matt Riedemann) Date: Thu, 21 Nov 2013 23:35:46 -0000 Subject: [Openstack-security] [Bug 1236125] Re: PowerVM driver ignores host keys References: <20131007013845.5908.7483.malonedeb@soybean.canonical.com> Message-ID: <20131121232614.19947.5363.malone@chaenomeles.canonical.com> So unless you want to do something to fix this in havana, I think it can be marked as 'won't fix' due to this: https://review.openstack.org/#/c/57774/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1236125 Title: PowerVM driver ignores host keys Status in OpenStack Compute (Nova): Triaged Bug description: Nova's PowerVM driver is currently set to AutoAdd any host key over SSH. As per the SSH protocol, host key fingerprints should be verified either by comparing with known hosts (like through a known_hosts file) or having a person verify its the host they wish to connect with. In particular, https://github.com/openstack/nova/blob/master/nova/virt/powervm/common.py uses paramiko.AutoAddPolicy() which will automatically accept any host key. Doing so allows Nova to be susceptible to a man-in-the-middle. There should instead be an option in nova.conf to specify a known_hosts file and the paramiko policy to use. That way someone could set the policy to Reject and specify a file with known_hosts which are acceptable. Communication therefore would never occur to unknown hosts and allow a potential release of a user/pwd. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1236125/+subscriptions From _ at lvh.cc Fri Nov 22 10:11:01 2013 From: _ at lvh.cc (Laurens Van Houtven) Date: Fri, 22 Nov 2013 10:11:01 -0000 Subject: [Openstack-security] [Bug 1251647] Re: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason References: <20131115144107.27303.99752.malonedeb@gac.canonical.com> Message-ID: <20131122100334.20011.75715.malone@chaenomeles.canonical.com> Should my opinion on what has to happen in Oslo go here? I think the resolution for *this* ticket is that Heat should use https://github.com/openstack/oslo- incubator/blob/master/openstack/common/crypto/utils.py#L99. Then, we make *that* good. So, my opinions on that, which I think should also be in a different ticket: Crypto issues: - The crypto primitive should probably be NaCl/libsodium's crypto_secretbox(_open). That's Salsa20 with a Poly1305-AES authenticator, but you shouldn't care too much about that :) - os.urandom should be used exclusively as a CSPRNG. User-level CPRNGs can certainly be done right, but there's plenty of ways to get them wrong. (Say, PyCrypto2.6.0, sometimes, when forking. And I don't even want to remember what I have to do to use RAND_bytes(3) properly in all cases). Since you eventually always rely on /dev/(u)random to get your seed anyway, I don't see the point. FWIW, cperciva disagrees with me, and he's smarter than me; but tptacek agrees with me, and he's smarter than me too. cperciva's arguments *might* be valid in Heat, since he's suggesting same-host entropy use leaks. I'm not convinced those are real attacks. I am convinced that your CSPRNG being broken leads to real attacks ;) - The padding routine in Oslo isn't constant time. This leaks information about the ciphertext length mod block size. In a system emitting a limited number of messages with predictable sizes, that's pretty bad. - The unpadding routine in Oslo blindly unpads the ordinal value of the last byte worth of bytes from the plaintext. That's a lot of options for generating valid (parseable) truncated messages. This is not an exhaustive list. All of the above issues would be fixed by leaving crypto up to NaCl/libsodium, except for key generation (which possibly isn't broken in the first place). API issues: - For a symmetric key API, there should not be separate "authenticate" and "encrypt" methods. There should be *only* encrypt, and that should /mean/ encrypt-and-then-MAC-the-ciphertext (EtM). Alternatively, you can also call it "encrypt_and_authenticate" :) The existence of *just* "authenticate" for authenticated plaintext messages is fine. There is no reason to expose the unauthenticated encryption foot-gun. Also, having them be separate methods means that people can get it wrong, for example, they could MtE (first MAC, append MAC to plaintext, then encrypt both), or they could E&M (encrypt plaintext, MAC plaintext, concatenate both). All of these are footguns. The public API should not let you get it wrong. - The verb "sign" should be reserved for public key signatures. These two groups of issues are orthogonal. cheers lvh -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251647 Title: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason Status in Orchestration API (Heat): Triaged Status in OpenStack Security Advisories: Invalid Bug description: In the following commit: https://github.com/openstack/heat/commit/58cd52624b50476ed5ed1c5c0ba7cb1b4d7ba66d ... a decision was introduced to encrypt authentication information using unauthenticated AES-CFB. There's a few things I don't like about that commit, but suffice to say that heat/engine/auth.py should probably not be a place where symmetric crypto decisions are made. I've been told that there's a new public API for symmetric encryption, SymmetricCrypto that lives in openstack/common/crypto/utils.py: https://github.com/openstack/oslo- incubator/blob/master/openstack/common/crypto/utils.py#L99 I think that also gets a few things wrong, but at the very least Heat should use a centralized thing for encrypting stuff. (I'd love to complain about and work on SymmetricCrypto too, but that's not this ticket :) To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1251647/+subscriptions From mhu at enovance.com Fri Nov 22 10:41:06 2013 From: mhu at enovance.com (Matthieu Huin) Date: Fri, 22 Nov 2013 10:41:06 -0000 Subject: [Openstack-security] [Bug 1240382] Re: python-oauth2 dependency is unmaintained and has security issues References: <20131016072040.28005.15743.malonedeb@chaenomeles.canonical.com> Message-ID: <20131122103439.19947.78639.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Assignee: (unassigned) => Matthieu Huin (mhu-s) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1240382 Title: python-oauth2 dependency is unmaintained and has security issues Status in OpenStack Identity (Keystone): Confirmed Bug description: oauth2 is not maintained and have 2 CVE issues CVE-2013-4346 and CVE-2013-4347 and is not Python3 compatible can you remove this dependency (maybe switching to requests ? ) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240382/+subscriptions From 1240382 at bugs.launchpad.net Fri Nov 22 15:42:42 2013 From: 1240382 at bugs.launchpad.net (Dolph Mathews) Date: Fri, 22 Nov 2013 15:42:42 -0000 Subject: [Openstack-security] [Bug 1240382] Re: python-oauth2 dependency is unmaintained and has security issues References: <20131016072040.28005.15743.malonedeb@chaenomeles.canonical.com> Message-ID: <20131122154242.7251.9838.malone@wampee.canonical.com> Not sure if we want to merge these two bugs or not, but downstream issue in ubuntu is tracked in bug 1223010 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1240382 Title: python-oauth2 dependency is unmaintained and has security issues Status in OpenStack Identity (Keystone): Confirmed Bug description: oauth2 is not maintained and have 2 CVE issues CVE-2013-4346 and CVE-2013-4347 and is not Python3 compatible can you remove this dependency (maybe switching to requests ? ) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240382/+subscriptions From 1236675 at bugs.launchpad.net Fri Nov 22 15:40:20 2013 From: 1236675 at bugs.launchpad.net (Dolph Mathews) Date: Fri, 22 Nov 2013 15:40:20 -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: <20131122154021.19974.98389.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1236675 Title: Keystone getting oauth access token by brute-forcing oauth_verifier code Status in OpenStack Identity (Keystone): Confirmed 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 1251518 at bugs.launchpad.net Mon Nov 25 09:42:32 2013 From: 1251518 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 25 Nov 2013 09:42:32 -0000 Subject: [Openstack-security] [Bug 1251518] Re: Glance needs a config option to limit the number of additional image properties References: <20131115051405.19741.28287.malonedeb@chaenomeles.canonical.com> Message-ID: <20131125094232.27825.86380.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/56981 Committed: http://github.com/openstack/glance/commit/f63d2f67ed1e7b8246b36bd08517a55a702a48a9 Submitter: Jenkins Branch: master commit f63d2f67ed1e7b8246b36bd08517a55a702a48a9 Author: Alex Meade Date: Fri Nov 15 22:42:55 2013 +0000 Add config option to limit image properties This patch adds the image_property_quota config option. This allows a deployer to limit the number of image properties allowed on an image. The default value is 128, as is currently the limit enforced by nova. Users will only be able to update an image if the result of the transaction would be under this limit. This behavior is intended to be similar to 'quota_metadata_items' in nova. This is for both Glance v1 and v2. Fixes bug 1251518 docImpact Change-Id: I4aa9504deae836404f11c9ada71a91f85caeba4c ** Changed in: glance 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/1251518 Title: Glance needs a config option to limit the number of additional image properties Status in OpenStack Image Registry and Delivery Service (Glance): Fix Committed Status in OpenStack Security Advisories: Invalid Bug description: Impact: The vulnerability occurs when glance is directly exposed to users. If users can only hit glance via the compute API, then no vulnerability. Nova has a configuration option quota_metadata_items (default value 128) that's documented to limit the number of metadata items that can be put on an instance. (I verified that it also applies to image metadata using a havana devstack.) Glance does not appear to have such an option (I was able to put >500 additional properties on an image using the glanceclient). I think this is a DOS attack vector, since someone could fill the glance database with garbage and slow everything down. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1251518/+subscriptions From aswad.rangnekar at nttdata.com Fri Nov 29 05:51:13 2013 From: aswad.rangnekar at nttdata.com (Aswad Rangnekar) Date: Fri, 29 Nov 2013 05:51:13 -0000 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com> Message-ID: <20131129055113.18719.1884.malone@chaenomeles.canonical.com> Hi, I have analyzed that; single sessionid is shared between multiple tcp connections for SPICE console. Now I am trying to figure out how to get this unique sessionid in NovaWebSocketProxy class. It is possible to solve this issue if this sessionid is available in NovaWebSocketProxy class. Please suggest if anybody has a workaround for this scenario -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1227575 Title: DoS style attack on noVNC server can lead to service interruption or disruption Status in OpenStack Compute (Nova): In Progress Status in OpenStack Security Notes: New Bug description: There is no limiting on the number of VNC sessions that can be created for a single user's VNC token. Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server results in many connection timeouts. Due to these connection timeout error, other users trying to access their VM's VNC console cannot do so. A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors Script: http://paste.openstack.org/show/47254/ Script output.... connections get timed out after a while ------------------- .... .. Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... Received 'RFB 003.008 ' Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out Creating Connection Receiving... timed out -------------------- Impact: 1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail. This can cause serious problems to users already having a running VNC session or trying to create new sessions. 2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol also gets affected after the connection timeout errors. For example: Before running the sumulate thousands of connections program: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 | +-------+---------------------------------------------------------------------------------+ real 0m0.751s user 0m0.376s sys 0m0.084s rohit at precise-dev-102:~/tools/websocket-client-0.7.0$ After running the program, the response time is quite high: $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5 novnc +-------+---------------------------------------------------------------------------------+ | Type | Url | +-------+---------------------------------------------------------------------------------+ | novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 | +-------+---------------------------------------------------------------------------------+ real 3m9.231s user 0m0.424s sys 0m0.108s Possible solutions: 1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple connections for the same token, and return an error code to the user. 2. Make the number of sessions allowed per instance configurable, limited by some count of sessions. However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class, which can lead to maintenance issues. Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token for reconnection. This would first need contribution to the websockify project code, and then update Nova. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions