From 1175904 at bugs.launchpad.net Sat Mar 1 02:59:16 2014 From: 1175904 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 01 Mar 2014 02:59:16 -0000 Subject: [Openstack-security] [Bug 1175904] Re: passlib trunc_password MAX_PASSWORD_LENGTH password truncation References: <20130503065124.14566.73303.malonedeb@gac.canonical.com> Message-ID: <20140301025917.13292.65787.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/77325 ** Changed in: keystone Status: Confirmed => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175904 Title: passlib trunc_password MAX_PASSWORD_LENGTH password truncation Status in OpenStack Identity (Keystone): In Progress Bug description: Grant Murphy originally reported: * Insecure / bad practice The trunc_password function attempts to correct and truncate passwords that are over the MAX_PASSWORD_LENGTH value (default 4096). As the MAX_PASSWORD_LENGTH field is globally mutable it could be modified to restrict all passwords to length = 1. This scenario might be unlikely but generally speaking we should not try to 'fix' invalid input and continue on processing as if nothing happened. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175904/+subscriptions From gerrit2 at review.openstack.org Sat Mar 1 09:23:48 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 01 Mar 2014 09:23:48 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77346 Log: commit d1e9ab6615e080c2595087b8cd464cae68904a39 Author: Daniel Gollub Date: Sat Feb 22 21:37:59 2014 +0100 Replace HTTPSConnection in zadara driver Replace HTTPSConnection in zadara driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the SAN would not pass the verification. Old behaviour can be force by using `san_ssl_insecure=True`. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b From 1188189 at bugs.launchpad.net Sat Mar 1 09:23:42 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Sat, 01 Mar 2014 09:23:42 -0000 Subject: [Openstack-security] [Bug 1188189] Fix proposed to cinder (master) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140301092342.13156.41676.malone@wampee.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/77346 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1188189 at bugs.launchpad.net Sat Mar 1 15:32:32 2014 From: 1188189 at bugs.launchpad.net (John Griffith) Date: Sat, 01 Mar 2014 15:32:32 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140301153232.26802.26661.malone@chaenomeles.canonical.com> So Daniel I have to say AWESOME job picking this up and running with it. I'm working on figuring out how to do this without breaking existing setups; although maybe somebody already has an idea off the top of their head. I did want to clarify though, I think we need to make sure that everywhere this is proposed it doesn't break existing setups or upgrades. I'm not sure I was clear about that in the one version but it's going to be a critical piece of this. If we can automate the switch (which I think and hope we can) then at the very least we're going to need a very BOLD and EXPLICIT warning and instructions in the Release Notes and in the documents on how to keep from losing your cloud. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From gerrit2 at review.openstack.org Sun Mar 2 08:49:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 02 Mar 2014 08:49:02 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77414 Log: commit 38daa6e0b289af3782f0842c366fbf92fc6c462f Author: Daniel Gollub Date: Sun Mar 2 09:33:38 2014 +0100 Replace HTTPSConnection in NEC plugin Replace HTTPSConnection in NEC plugin PFC driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the NEC PFC driver would not pass the verification. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 From 1188189 at bugs.launchpad.net Sun Mar 2 08:48:56 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 02 Mar 2014 08:48:56 -0000 Subject: [Openstack-security] [Bug 1188189] Fix proposed to neutron (master) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140302084856.13348.74706.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/77414 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From gerrit2 at review.openstack.org Sun Mar 2 09:37:06 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 02 Mar 2014 09:37:06 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77414 Log: commit f397a529fb34ea2f36c2c034f87006958863d99c Author: Daniel Gollub Date: Sun Mar 2 09:33:38 2014 +0100 Replace HTTPSConnection in NEC plugin Replace HTTPSConnection in NEC plugin PFC driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the NEC PFC driver would not pass the verification. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 From gerrit2 at review.openstack.org Sun Mar 2 10:15:11 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 02 Mar 2014 10:15:11 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77414 Log: commit 2e63198abb1659527609daaceeea24ea35b7b4ea Author: Daniel Gollub Date: Sun Mar 2 09:33:38 2014 +0100 Replace HTTPSConnection in NEC plugin Replace HTTPSConnection in NEC plugin PFC driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the NEC PFC driver would not pass the verification. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 From bdpayne at acm.org Sun Mar 2 22:18:41 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Sun, 2 Mar 2014 14:18:41 -0800 Subject: [Openstack-security] Process for OSSG Lead Elections In-Reply-To: References: Message-ID: While this list has been quiet, I have had a few side conversations with people. Based on the feedback I've received, I changed the meeting attendance requirement to need 3+ meetings to be considered active. I did not change the timeline. I will put together a list of the active members in a Google Doc. If, after seeing the list, someone believes I have made a mistake then just let me know. We are scheduled to begin this process tomorrow. I'll send out a reminder email at that time. Cheers, -bryan On Thu, Feb 27, 2014 at 12:35 PM, Bryan D. Payne wrote: > As discussed in the past two OSSG meetings, Rob and I will be stepping > down as the co-leaders of OSSG at the summit in May. We would like to have > an election process to choose the next leader as this is a community driven > group. > > I've been working out the specific details for the election, which is > largely based on the PTL / TC election process used by the broader > OpenStack community. To ensure that everyone is up to speed, please review > the election process: > https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014 > > We began discussing this in the OSSG meeting today. Some initial areas of > discussion were around the following points: > > 1) Is attending a single IRC meeting sufficient to be considered an > "active member"? Perhaps we should increase this requirement to 3 or more > meetings? > > 2) Does the current proposed timeline work? > > There may be other items that catch people's eyes as well. Please use > this thread to discuss the process and suggest improvements. I will help > mediate that discussion with the goal of arriving at something we all feel > comfortable with. > > Cheers, > -bryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1188189 at bugs.launchpad.net Mon Mar 3 03:26:07 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 03 Mar 2014 03:26:07 -0000 Subject: [Openstack-security] [Bug 1188189] Fix merged to cinder (master) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140303032608.26866.83301.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/75667 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=0f9652d92e175a1f7dc3c2a37ab444b8f189375a Submitter: Jenkins Branch: master commit 0f9652d92e175a1f7dc3c2a37ab444b8f189375a Author: Daniel Gollub Date: Sun Feb 23 09:30:00 2014 +0100 Replace httplib.HTTPSConnection in unittests SSL Verification is from now on enabled by default for the TestOpenStackClient. So far no unittests was making actively use of httplib.HTTPSConnection. Intention is to reduce noise of audits/scanners which look for Python 2.x httplib.HTTPSConnection missing SSL verification. By completely abandoning the use of httplib.HTTPSConnection. Change-Id: Ic0352cf453d5c41f09084a6d68b3393b8ddda84a Partial-Bug: 1188189 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1188189 at bugs.launchpad.net Mon Mar 3 05:44:22 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 03 Mar 2014 05:44:22 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140303054426.27043.51443.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Assignee: Daniel Gollub (d-gollub) => Kevin Benton (kevinbenton) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From gerrit2 at review.openstack.org Mon Mar 3 15:07:24 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 03 Mar 2014 15:07:24 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit 17e39124b85469e7575d2bbe088102e8cfd28847 Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From marc.w.heckmann at gmail.com Mon Mar 3 16:35:38 2014 From: marc.w.heckmann at gmail.com (Marc Heckmann) Date: Mon, 3 Mar 2014 11:35:38 -0500 Subject: [Openstack-security] [Nova] RBAC policy not enforced when adding a security group rule using EC2 API? Message-ID: Hi, I sent this to the general list last week, but it hasn't seemed to get any traction there, so I'm trying here. Sorry for the cross posting. It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons. The Nova API security group implementation does enforce RBAC on these functions. Does anyone know why? Thanks in advance. -m From gerrit2 at review.openstack.org Mon Mar 3 17:49:40 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 03 Mar 2014 17:49:40 +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 e0663574f4db03b167f07a57e98a982cb46c7f0a Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From bdpayne at acm.org Mon Mar 3 18:19:09 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Mon, 3 Mar 2014 10:19:09 -0800 Subject: [Openstack-security] OSSG Lead Candidacy Kickoff Message-ID: Starting today, and going through March 12, we are accepting candidates for the OSSG Lead election. You can view the complete details on the election process here: https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014 Some relavent details: * Candidates must be active members (as defined in the above link) of OSSG. * Candidates must announce their intention to run by posting a message to this list with the subject "OSSG Lead Candidacy". Either Rob or I will respond to verify that the candidate is an active member and added to the election. All candidates will be added to the election page linked above. Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Mon Mar 3 18:45:43 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Mon, 3 Mar 2014 10:45:43 -0800 Subject: [Openstack-security] [Nova] RBAC policy not enforced when adding a security group rule using EC2 API? In-Reply-To: References: Message-ID: Marc, This sounds like a Nova bug. Have you filed a bug with the Nova project for this? That is probably the best way to get this in front of the right eyes. https://bugs.launchpad.net/nova/+bugs Cheers, -bryan On Mon, Mar 3, 2014 at 8:35 AM, Marc Heckmann wrote: > Hi, > > I sent this to the general list last week, but it hasn't seemed to get > any traction there, so I'm trying here. Sorry for the cross posting. > > It seems that when using the EC2 API, the security group > implementation does not enforce RBAC policy for the add_rules, > remove_rules, destroy and other functions (in compute/api.py). Only > the add_to_instance and remove_from_instance functions enforce RBAC. > This seems like an oversight for obvious reasons. > > The Nova API security group implementation does enforce RBAC on these > functions. > > Does anyone know why? > > Thanks in advance. > > -m > > _______________________________________________ > 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 Mon Mar 3 18:50:52 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 3 Mar 2014 10:50:52 -0800 Subject: [Openstack-security] OSSG Lead Candidacy Message-ID: Dear OSSG members, I would like to be nominated for the OSSG leader election. Throwing in my hat here! -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Mon Mar 3 19:05:21 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Mon, 3 Mar 2014 11:05:21 -0800 Subject: [Openstack-security] OSSG Lead Candidacy In-Reply-To: References: Message-ID: I confirm that Sriram meets all of the requirements to be a candidate. I have added him to https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014. -bryan On Mon, Mar 3, 2014 at 10:50 AM, Sriram Subramanian wrote: > Dear OSSG members, > > I would like to be nominated for the OSSG leader election. Throwing in my > hat here! > > -- > 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 gerrit2 at review.openstack.org Mon Mar 3 19:26:27 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 03 Mar 2014 19:26:27 +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 ddcd10bfe50e13dc171938d46e9ec23452901931 Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From sriram at sriramhere.com Mon Mar 3 19:27:13 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 3 Mar 2014 11:27:13 -0800 Subject: [Openstack-security] OSSG Lead Candidacy In-Reply-To: References: Message-ID: Thanks for the confirmation Bryan! On Mon, Mar 3, 2014 at 11:05 AM, Bryan D. Payne wrote: > I confirm that Sriram meets all of the requirements to be a candidate. I > have added him to > https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014. > -bryan > > > On Mon, Mar 3, 2014 at 10:50 AM, Sriram Subramanian > wrote: > >> Dear OSSG members, >> >> I would like to be nominated for the OSSG leader election. Throwing in my >> hat here! >> >> -- >> 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 Mon Mar 3 19:35:24 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 3 Mar 2014 19:35:24 +0000 Subject: [Openstack-security] OSSG Lead Candidacy In-Reply-To: References: Message-ID: Thanks for getting the ball rolling Sriram, I imagine we'll have more candidates come forward now. Good luck everyone :) From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: 03 March 2014 19:27 To: Bryan D. Payne Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OSSG Lead Candidacy Thanks for the confirmation Bryan! On Mon, Mar 3, 2014 at 11:05 AM, Bryan D. Payne > wrote: I confirm that Sriram meets all of the requirements to be a candidate. I have added him to https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014. -bryan On Mon, Mar 3, 2014 at 10:50 AM, Sriram Subramanian > wrote: Dear OSSG members, I would like to be nominated for the OSSG leader election. Throwing in my hat here! -- 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 gerrit2 at review.openstack.org Mon Mar 3 20:02:45 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 03 Mar 2014 20:02:45 +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 e26ea52eef628d66ce8bb5f55aa0b41820a5209c Author: Dan Genin Date: Thu Jan 2 09:45:11 2014 -0500 Adds ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. VM rescue and migration are not supported at present. The proposed code provides data-at-rest security for all ephemeral storage disks, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turns encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 DocImpact SecurityImpact From gerrit2 at review.openstack.org Tue Mar 4 06:10:38 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 04 Mar 2014 06:10:38 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77414 Log: commit 57dd79068db3eaeb1b3dc9a0dbab1645b28e20b2 Author: Daniel Gollub Date: Sun Mar 2 09:33:38 2014 +0100 Replace HTTPSConnection in NEC plugin Replace HTTPSConnection in NEC plugin PFC driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the NEC PFC driver would not pass the verification. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 From 1188189 at bugs.launchpad.net Tue Mar 4 06:10:31 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 04 Mar 2014 06:10:31 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140304061035.13520.42187.launchpad@gac.canonical.com> ** Changed in: neutron Assignee: Kevin Benton (kevinbenton) => Daniel Gollub (d-gollub) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From gerrit2 at review.openstack.org Tue Mar 4 08:42:54 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 04 Mar 2014 08:42:54 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77414 Log: commit 66b33db35bc8d9b75a9c265adcdd5245e88ca3e4 Author: Daniel Gollub Date: Sun Mar 2 09:33:38 2014 +0100 Replace HTTPSConnection in NEC plugin Replace HTTPSConnection in NEC plugin PFC driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the NEC PFC driver would not pass the verification. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 From skywalker.nick at gmail.com Sat Mar 1 02:06:27 2014 From: skywalker.nick at gmail.com (Li Ma) Date: Sat, 01 Mar 2014 02:06:27 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20140301020627.7594.49579.malone@soybean.canonical.com> Any progress here? +1 add a configuration option to let users decide which algorithm to apply, and make it MD5 by default. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From skywalker.nick at gmail.com Sat Mar 1 02:35:55 2014 From: skywalker.nick at gmail.com (Li Ma) Date: Sat, 01 Mar 2014 02:35:55 -0000 Subject: [Openstack-security] [Bug 1175904] Re: passlib trunc_password MAX_PASSWORD_LENGTH password truncation References: <20130503065124.14566.73303.malonedeb@gac.canonical.com> Message-ID: <20140301023557.13593.80609.launchpad@gac.canonical.com> ** Changed in: keystone Assignee: (unassigned) => Li Ma (nick-ma-z) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175904 Title: passlib trunc_password MAX_PASSWORD_LENGTH password truncation Status in OpenStack Identity (Keystone): Confirmed Bug description: Grant Murphy originally reported: * Insecure / bad practice The trunc_password function attempts to correct and truncate passwords that are over the MAX_PASSWORD_LENGTH value (default 4096). As the MAX_PASSWORD_LENGTH field is globally mutable it could be modified to restrict all passwords to length = 1. This scenario might be unlikely but generally speaking we should not try to 'fix' invalid input and continue on processing as if nothing happened. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175904/+subscriptions From 1174499 at bugs.launchpad.net Sat Mar 1 03:29:47 2014 From: 1174499 at bugs.launchpad.net (Adam Young) Date: Sat, 01 Mar 2014 03:29:47 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> <20140301020627.7594.49579.malone@soybean.canonical.com> Message-ID: <5311542B.40506@redhat.com> On 02/28/2014 09:06 PM, Li Ma wrote: > Any progress here? > > +1 add a configuration option to let users decide which algorithm to > apply, and make it MD5 by default. > Goal is to get away from on line token validation all together. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From d.gollub at telekom.de Sat Mar 1 06:19:12 2014 From: d.gollub at telekom.de (Daniel Gollub) Date: Sat, 01 Mar 2014 06:19:12 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140301061912.13255.19608.malone@gac.canonical.com> For the record: * quantum/plugins/bigswitch/plugin.py: Bigswitch plugin, calls to network controller this one has an ongoing blueprint bsn-certificate-enforcement https://review.openstack.org/#/c/70906/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From yangxurong at huawei.com Sat Mar 1 15:43:34 2014 From: yangxurong at huawei.com (Xurong Yang) Date: Sat, 01 Mar 2014 15:43:34 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140301154339.8309.78686.launchpad@soybean.canonical.com> ** Changed in: nova Assignee: (unassigned) => Xurong Yang (idopra) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From d.gollub at telekom.de Sat Mar 1 16:21:29 2014 From: d.gollub at telekom.de (Daniel Gollub) Date: Sat, 01 Mar 2014 16:21:29 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140301162129.13853.7135.malone@gac.canonical.com> Random idea: Maybe this is something which should be discussed/handled by the individual OpenStack distributors/vendors? They could handle this inside their packages of cinder (or other components)? With pre-/post-scripts while upgrading the package? All other automatic approaches were it disables SSL verification - or tolerates failing verification would let us end-up with the same security issue again - I guess. I do not have a better idea either. But maybe we could use the Icehouse release and stress this fundamental change in Upgrade notes/instruction. And switch to SSL verification by default across all the identified OpenStack components. Introducing some logic like: if the configured HTTPS URL holds an IP address instead of a DNS name, "very likely" SSL verification is not going to succeed so the code falls back to ssl_insecure=True .... or something like that - I would not recommend to do. Since it would silently hide the fact that the current setup is not as secure as one would think. Not quite sure if just logging that SSL verification failed and continuing with ssl_insecure=True would "solve" it either in a correct fashion. Maybe security- and release folks should decide to go once through this burden with the Icehouse release or not. And try to warn the admins ahead in Release Notes and Upgrade Instruction to verify if their setup would pass SSL verification - or not. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1250101 at bugs.launchpad.net Sun Mar 2 20:28:21 2014 From: 1250101 at bugs.launchpad.net (OpenStack Infra) Date: Sun, 02 Mar 2014 20:28:21 -0000 Subject: [Openstack-security] [Bug 1250101] Related fix merged to cinder (master) References: <20131111144450.24249.16674.malonedeb@gac.canonical.com> Message-ID: <20140302202821.26666.37040.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/76529 Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=2c44cfa2db0cd1a5ba6c02581b34136d7ee5d4fb Submitter: Jenkins Branch: master commit 2c44cfa2db0cd1a5ba6c02581b34136d7ee5d4fb Author: Daniel Gollub Date: Wed Feb 19 07:41:24 2014 +0100 Restrict rootwrap find filter for IBM NAS and GPFS Additional make the name of the filter unique, so it does not override any other rule. Like the find rule of the NetAppNFS driver. Rootwrap is making use of plain python ConfigParser which handles INI files with key=value pair like fashion. Where the key is unique. Related-Bug: 1250101 Change-Id: I56a96084dc736e73e3e9533803f65956699891a0 -- 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: Fix Committed 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 daniel.crompton at gmail.com Tue Mar 4 09:59:09 2014 From: daniel.crompton at gmail.com (=?UTF-8?Q?Dani=C3=ABl_W=2E_Crompton?=) Date: Tue, 4 Mar 2014 10:59:09 +0100 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext In-Reply-To: <20140224215331.851.7846.malone@gac.canonical.com> References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> <20140224215331.851.7846.malone@gac.canonical.com> Message-ID: A shadow like password wouldn't be possible as it needs to be reversible. And as it's reversible anybody with access to the file would be able to reverse it with the encryption scheme. Making it security by obscurity. This could probably best be solved with something like a pkcs7 key exchange, although this would be a little more work. D. On Mar 4, 2014 10:35 AM, "Matt Fischer" wrote: > I see this bug is old and Wishlisted so it may never get fixed, but I'd > like to add that plaintext passwords are generally a no-no when the > service account auth is managed by Corporate AD or LDAP. It may > complicate some deployments but it would be nice to have a solution to > this. > > -- > You received this bug notification because you are a member of OpenStack > Security Group, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1158328 > > Title: > passwords in config files stored in plaintext > > Status in OpenStack Compute (Nova): > Confirmed > > Bug description: > The credentials for database conenctions and the keystone authtoken > are stored in plaintext within the nova.conf and apipaste config > files. > > These values should be encrypted. A scheme similar to /etc/shadow > would be great. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions > > _______________________________________________ > 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 mhu at enovance.com Tue Mar 4 10:16:21 2014 From: mhu at enovance.com (Matthieu Huin) Date: Tue, 04 Mar 2014 10:16:21 -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: <20140304101621.12875.64926.malone@wampee.canonical.com> I -- 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 mhu at enovance.com Tue Mar 4 10:16:59 2014 From: mhu at enovance.com (Matthieu Huin) Date: Tue, 04 Mar 2014 10:16:59 -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: <20140304101659.13156.58828.malone@wampee.canonical.com> I agree that a 8 character long hex string is a good compromise. Shall this be pushed on ? -- 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 adrian.otto at rackspace.com Tue Mar 4 14:51:55 2014 From: adrian.otto at rackspace.com (Adrian Otto) Date: Tue, 4 Mar 2014 14:51:55 +0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext In-Reply-To: References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> <20140224215331.851.7846.malone@gac.canonical.com>, Message-ID: <14DF2790-6CF8-4D5D-9405-AADCE4AEA613@rackspace.com> I see Barbican as the right tool for this job. The configuration file can get the secret identifier, and the secret itself can be stored in Barbican where it can be centrally fortified, access controlled, access logged, and could be revoked. The service would use an HTTPS request to retrieve the secret from its encrypted remote storage in Barbican on an as-needed basis. -- Adrian On Mar 4, 2014, at 2:01 AM, "Daniël W. Crompton" > wrote: A shadow like password wouldn't be possible as it needs to be reversible. And as it's reversible anybody with access to the file would be able to reverse it with the encryption scheme. Making it security by obscurity. This could probably best be solved with something like a pkcs7 key exchange, although this would be a little more work. D. On Mar 4, 2014 10:35 AM, "Matt Fischer" > wrote: I see this bug is old and Wishlisted so it may never get fixed, but I'd like to add that plaintext passwords are generally a no-no when the service account auth is managed by Corporate AD or LDAP. It may complicate some deployments but it would be nice to have a solution to this. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in OpenStack Compute (Nova): Confirmed Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions _______________________________________________ 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 andrew.laski at rackspace.com Tue Mar 4 18:57:10 2014 From: andrew.laski at rackspace.com (Andrew Laski) Date: Tue, 04 Mar 2014 18:57:10 -0000 Subject: [Openstack-security] [Bug 1175193] Re: Instance actions history is unbounded References: <20130501143332.32195.9096.malonedeb@gac.canonical.com> Message-ID: <20140304185710.13934.80326.malone@gac.canonical.com> Moving to medium since I have not seen any reports of issues with this, nor have I seen this cropping up in a large deployment I help maintain. ** Changed in: nova Importance: High => Medium ** Changed in: nova Assignee: Andrew Laski (alaski) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175193 Title: Instance actions history is unbounded Status in OpenStack Compute (Nova): Confirmed Bug description: Grizzly included a new feature to keep a history of actions performed on an instance. The history kept in the database is unbounded. As a result, a malicious user could perform actions in a loop and cause the database to grow without bounds. Some of the quicker actions that could be used to exploit this are pause, unpause, or change password. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1175193/+subscriptions From 1188189 at bugs.launchpad.net Tue Mar 4 23:17:36 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 04 Mar 2014 23:17:36 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140304231739.14146.90658.launchpad@gac.canonical.com> ** Changed in: neutron Assignee: Daniel Gollub (d-gollub) => Kevin Benton (kevinbenton) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From abhishek.kekane at nttdata.com Wed Mar 5 07:41:27 2014 From: abhishek.kekane at nttdata.com (Abhishek Kekane) Date: Wed, 05 Mar 2014 07:41:27 -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: <20140305074127.12842.47572.malone@wampee.canonical.com> Hi, One possible solution to limit the console sessions for both vnc and spice consoles is that we can query to compute node to know how many tcp connections are established for a given console graphics port of the vm using netstat command. If the number of established tcp connections exceeds that of configured value, then it is possible to restrict users from connecting to the console. sudo netstat -pnt | awk '{print $4}' | egrep '^127.0.0.1:5900$’ 127.0.0.1 : vncserver_listen parameter from nova.conf 5900: graphics port either for spice or vnc. For this to work, we need to know whether the tcp connections per spice console is governed by libvirt or there are any other external factors involved that could vary the count of the tcp connections. Once we know count of tcp connections are bound to libvirt then we can write the logic in the libvirt driver to return tcp connections count accordingly per console type (spice or vnc). Also need to check how this would work for other hypervisors. Advantage: 1. No need to persist connection data per vm per session saving disk space Disadvantage: 1. One additional rpc call to the compute node per console Please let me know your suggestions on the same. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/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 Wed Mar 5 12:34:39 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 05 Mar 2014 12:34:39 -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: <20140305123441.13253.8698.launchpad@wampee.canonical.com> ** Changed in: nova Milestone: icehouse-3 => icehouse-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/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 Wed Mar 5 17:15:36 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 05 Mar 2014 17:15:36 -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: <20140305171539.13664.62397.launchpad@gac.canonical.com> ** Changed in: cinder Status: Fix Committed => Fix Released ** Changed in: cinder Milestone: None => icehouse-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1250101 Title: Cinder's rootwrap filters allow to run find as root, which allows arbitrary commands Status in Cinder: Fix Released 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 thierry.carrez+lp at gmail.com Wed Mar 5 19:54:47 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 05 Mar 2014 19:54:47 -0000 Subject: [Openstack-security] [Bug 1279849] Re: keystone password creation and verification mismatch References: <20140213153829.1383.20321.malonedeb@chaenomeles.canonical.com> Message-ID: <20140305195451.7656.4444.launchpad@soybean.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1279849 Title: keystone password creation and verification mismatch Status in OpenStack Identity (Keystone): Fix Released Bug description: In keystone stable/Havana release, password for a user can be set during user creation process. Now if a user initially do a sha512 hash of his password and sent it to the keystone server over the wire, then hash_password method of keystone/common/utils.py def hash_password(password): ~ | """Hash a password. Hard.""" ~ | password_utf8 = trunc_password(password).encode('utf-8') ~ | if passlib.hash.sha512_crypt.identify(password_utf8): ~ | return password_utf8 ~ | h = passlib.hash.sha512_crypt.encrypt(password_utf8, ~ | rounds=CONF.crypt_strength) ~ | return h will not do any hashing, or it directly store the password in DB. However, during authentication, the user needs to provide the clear text password for authentication because during authentication it always does sha512 over the password field (it does not check the password is already hashed) def check_password(password, hashed): ""Check that a plaintext password matches hashed. hashpw returns the salt value concatenated with the actual hash value. It extracts the actual salt if this value is then passed as the salt. """ if password is None or hashed is None: return False password_utf8 = trunc_password(password).encode('utf-8') return passlib.hash.sha512_crypt.verify(password_utf8, hashed) Now in this case, 1) user chooses a password which is similar to a sha512 output, now keystone thinks it is already hashed, so it will store it as it is. User provides the sha512 during authentication but he cannot login this time cause now the password is hashed before matching. There should be consistency for both password creation and verification process. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1279849/+subscriptions From gerrit2 at review.openstack.org Wed Mar 5 20:17:16 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 05 Mar 2014 20:17:16 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie6a6620685995add56f38dc34c9a0a733558146a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76476 Log: commit 58564740225eb949fe2da431355ec96fd8782c7d Author: Daniel Gollub Date: Wed Feb 26 06:56:13 2014 +0100 Replace httplib.HTTPSConnection in ec2_token httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. Implementation got adapted to make use of the requests module instead. SSL Verification is from now on enabled by default. Can be disabled via an additional introduced configuration option: `keystone_ec2_insecure=True` SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: Ie6a6620685995add56f38dc34c9a0a733558146a From 1188189 at bugs.launchpad.net Wed Mar 5 20:08:15 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 05 Mar 2014 20:08:15 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140305200820.8280.45625.launchpad@soybean.canonical.com> ** Changed in: neutron Assignee: Kevin Benton (kevinbenton) => Mark McClain (markmcclain) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1188189 at bugs.launchpad.net Thu Mar 6 07:12:30 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 06 Mar 2014 07:12:30 -0000 Subject: [Openstack-security] [Bug 1188189] Fix merged to neutron (master) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140306071230.8048.85283.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/70906 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7255e056092f034daaeb4246a812900645d46911 Submitter: Jenkins Branch: master commit 7255e056092f034daaeb4246a812900645d46911 Author: Kevin Benton Date: Sun Feb 2 20:46:18 2014 -0800 BigSwitch: Add SSL Certificate Validation This patch adds the option to use SSL certificate validation on the backend controller using SSH-style sticky authentication, individual trusted certificates, and/or certificate authorities. Also adds caching of connections to deal with increased overhead of TLS/SSL handshake. Default is now sticky-style enforcement. Partial-Bug: 1188189 Implements: blueprint bsn-certificate-enforcement Change-Id: If0bab196495c4944a53e0e394c956cca36269883 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From gerrit2 at review.openstack.org Thu Mar 6 07:28:39 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 06 Mar 2014 07:28:39 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie6a6620685995add56f38dc34c9a0a733558146a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76476 Log: commit 3dd635cf95aeeada179b19579eb76dd0a018bd50 Author: Daniel Gollub Date: Wed Feb 26 06:56:13 2014 +0100 Replace httplib.HTTPSConnection in ec2_token httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. Implementation got adapted to make use of the requests module instead. SSL Verification is from now on enabled by default. Can be disabled via an additional introduced configuration option: `keystone_ec2_insecure=True` SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: Ie6a6620685995add56f38dc34c9a0a733558146a From malini.k.bhandaru at intel.com Thu Mar 6 11:25:26 2014 From: malini.k.bhandaru at intel.com (Bhandaru, Malini K) Date: Thu, 6 Mar 2014 11:25:26 +0000 Subject: [Openstack-security] OSSG Lead Candidacy Kickoff In-Reply-To: References: Message-ID: Hello OSSG Members! I would be honored to lead our efforts as a group to making OpenStack more secure and making OSSG a first class OpenStack citizen. Bryan and Robert have done an excellent job in raising the visibility of security as a cross cutting issue across OpenStack projects, publishing a book, and chasing the nuances of each security issue in OSSAs and OSSNs. Their shoes will be hard to fill. We have a great team and strong regulars and I hope to grow this core to include cores across the projects to be our security eyes, ears and feature design sanitizers. A little about myself: Malini Bhandaru is an Architect and Engineering Manager with the Open Source Technology Center in the Software and Services group at Intel. Over her five year tenure at Intel she has worked on Xeon server power and performance aspects, faster implementations of hashing and encryption algorithms, and more recently on OpenStack. She is proud to be an author of the OpenStack Security Guide, of championing a key manager in OpenStack, and in assisting other Intel cloud efforts. Prior to Intel she has worked on remote monitoring and management, e-commerce, speech recognition, and other products. Malini has a Ph.D. in Computer Science, Artificial Intelligence, from the University of Massachusetts, Amherst. She enjoys gardening, cooking, and long walks. Thanks! Hopping off my soap box Malini From: Bryan D. Payne [mailto:bdpayne at acm.org] Sent: Monday, March 03, 2014 10:19 AM To: openstack-security at lists.openstack.org Subject: [Openstack-security] OSSG Lead Candidacy Kickoff Starting today, and going through March 12, we are accepting candidates for the OSSG Lead election. You can view the complete details on the election process here: https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014 Some relevant details: * Candidates must be active members (as defined in the above link) of OSSG. * Candidates must announce their intention to run by posting a message to this list with the subject "OSSG Lead Candidacy". Either Rob or I will respond to verify that the candidate is an active member and added to the election. All candidates will be added to the election page linked above. Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry.carrez+lp at gmail.com Thu Mar 6 15:19:55 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 06 Mar 2014 15:19:55 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140306151957.12804.53886.launchpad@wampee.canonical.com> ** Changed in: oslo 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/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From bdpayne at acm.org Thu Mar 6 16:53:29 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 6 Mar 2014 08:53:29 -0800 Subject: [Openstack-security] OSSG Lead Candidacy Kickoff In-Reply-To: References: Message-ID: I confirm that Malini meets all of the requirements to be a candidate. I have added her to https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014. -bryan On Thu, Mar 6, 2014 at 3:25 AM, Bhandaru, Malini K < malini.k.bhandaru at intel.com> wrote: > Hello OSSG Members! > > > > I would be honored to lead our efforts as a group to making OpenStack more > secure and making OSSG a first class OpenStack citizen. > > Bryan and Robert have done an excellent job in raising the visibility of > security as a cross cutting issue > > across OpenStack projects, publishing a book, and chasing the nuances of > each security issue in OSSAs and OSSNs. > > Their shoes will be hard to fill. We have a great team and strong > regulars and I hope to grow this core to include cores across the projects > to be our security eyes, ears and feature design sanitizers. > > > > A little about myself: > > Malini Bhandaru is an Architect and Engineering Manager with the Open > Source Technology Center in the Software and Services group at Intel. Over > her five year tenure at Intel she has worked on Xeon server power and > performance aspects, faster implementations of hashing and encryption > algorithms, and more recently on OpenStack. She is proud to be an author of > the OpenStack Security Guide, of championing a key manager in OpenStack, > and in assisting other Intel cloud efforts. Prior to Intel she has worked > on remote monitoring and management, e-commerce, speech recognition, and > other products. Malini has a Ph.D. in Computer Science, Artificial > Intelligence, from the University of Massachusetts, Amherst. She enjoys > gardening, cooking, and long walks. > > > > Thanks! > > Hopping off my soap box > > Malini > > > > *From:* Bryan D. Payne [mailto:bdpayne at acm.org] > *Sent:* Monday, March 03, 2014 10:19 AM > *To:* openstack-security at lists.openstack.org > *Subject:* [Openstack-security] OSSG Lead Candidacy Kickoff > > > > Starting today, and going through March 12, we are accepting candidates > for the OSSG Lead election. You can view the complete details on the > election process here: > > https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014 > > Some relevant details: > > > * Candidates must be active members (as defined in the above link) of OSSG. > > * Candidates must announce their intention to run by posting a message to > this list with the subject "OSSG Lead Candidacy". Either Rob or I will > respond to verify that the candidate is an active member and added to the > election. All candidates will be added to the election page linked above. > > > > Cheers, > > -bryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry.carrez+lp at gmail.com Thu Mar 6 17:01:19 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 06 Mar 2014 17:01:19 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140306170121.27012.14029.launchpad@chaenomeles.canonical.com> ** Changed in: oslo Milestone: None => icehouse-3 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From thierry.carrez+lp at gmail.com Thu Mar 6 17:13:08 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 06 Mar 2014 17:13:08 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140306171310.8085.88549.launchpad@soybean.canonical.com> ** Changed in: oslo Milestone: icehouse-3 => icehouse-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From sriram at sriramhere.com Fri Mar 7 03:29:18 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 6 Mar 2014 19:29:18 -0800 Subject: [Openstack-security] OSSG Lead Candidacy Kickoff In-Reply-To: References: Message-ID: Malini, I would love you to be the OSSG lead - I wasn't aware that you would be interested. In that context, I would be happy to withdraw my nomination. Bryan - please remove my name from the candidates list :) thanks, -Sriram On Thu, Mar 6, 2014 at 8:53 AM, Bryan D. Payne wrote: > I confirm that Malini meets all of the requirements to be a candidate. I > have added her to > https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014. > > -bryan > > > On Thu, Mar 6, 2014 at 3:25 AM, Bhandaru, Malini K < > malini.k.bhandaru at intel.com> wrote: > >> Hello OSSG Members! >> >> >> >> I would be honored to lead our efforts as a group to making OpenStack >> more secure and making OSSG a first class OpenStack citizen. >> >> Bryan and Robert have done an excellent job in raising the visibility of >> security as a cross cutting issue >> >> across OpenStack projects, publishing a book, and chasing the nuances of >> each security issue in OSSAs and OSSNs. >> >> Their shoes will be hard to fill. We have a great team and strong >> regulars and I hope to grow this core to include cores across the projects >> to be our security eyes, ears and feature design sanitizers. >> >> >> >> A little about myself: >> >> Malini Bhandaru is an Architect and Engineering Manager with the Open >> Source Technology Center in the Software and Services group at Intel. Over >> her five year tenure at Intel she has worked on Xeon server power and >> performance aspects, faster implementations of hashing and encryption >> algorithms, and more recently on OpenStack. She is proud to be an author of >> the OpenStack Security Guide, of championing a key manager in OpenStack, >> and in assisting other Intel cloud efforts. Prior to Intel she has worked >> on remote monitoring and management, e-commerce, speech recognition, and >> other products. Malini has a Ph.D. in Computer Science, Artificial >> Intelligence, from the University of Massachusetts, Amherst. She enjoys >> gardening, cooking, and long walks. >> >> >> >> Thanks! >> >> Hopping off my soap box >> >> Malini >> >> >> >> *From:* Bryan D. Payne [mailto:bdpayne at acm.org] >> *Sent:* Monday, March 03, 2014 10:19 AM >> *To:* openstack-security at lists.openstack.org >> *Subject:* [Openstack-security] OSSG Lead Candidacy Kickoff >> >> >> >> Starting today, and going through March 12, we are accepting candidates >> for the OSSG Lead election. You can view the complete details on the >> election process here: >> >> https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014 >> >> Some relevant details: >> >> >> * Candidates must be active members (as defined in the above link) of >> OSSG. >> >> * Candidates must announce their intention to run by posting a message to >> this list with the subject "OSSG Lead Candidacy". Either Rob or I will >> respond to verify that the candidate is an active member and added to the >> election. All candidates will be added to the election page linked above. >> >> >> >> Cheers, >> >> -bryan >> > > > _______________________________________________ > 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 Fri Mar 7 15:55:27 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Fri, 7 Mar 2014 17:55:27 +0200 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG References: <39586D6C-0734-45E2-B14B-C8F98D5ACD6F@ericsson.com> Message-ID: Hi all, Yesterday’s OSSG meeting, i promised to give the current status of the activity. The activity is ongoing. Based on feed back from last IRC call, we have updated the Threat Modelling framework. The wiki page is updated now.. https://wiki.openstack.org/wiki/Security/Threat_Analysis We are almost finishing the analysis for Auth_token middleware, Token manager and token service. We looking for reviewer of those documents. There is a meeting today at 17.00 GMT in ##openstack-threat-analysis (unofficial channel) Thanks, Shohel We are going to have a OpenStack Threat m > From: Abu Shohel Ahmed > Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - OSSG > Date: 21 Feb 2014 13:15:08 GMT+2 > To: "openstack-security at lists.openstack.org" > Cc: Sriram Subramanian , "Clark, Robert Graham" > > Hi guys, > > Sorry for not including the whole OSSG in the initial call. So, we are having an initial call > for Threat modelling of OpenStack (first one is Keystone) today, 21 Feb, 17.00 UTC. Let’s > have the discussion today then decide what time suits us best for later meetings. It is in Free node > channel ##openstack-threat-analysis (unofficial channel). > > Today’s topics of discussion: > 1. Threat modelling process > https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > > First, we t need to agree on this, so we have conformity around the whole work. Please feel > free to provide your feedback. > > 2. Some concrete example use of the modelling process > Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > > (Now this documents are work in progress work, things are not always in order and complete) > > > See you in the meeting, > Shohel > > > > > On 20 Feb 2014, at 20:47, Sriram Subramanian wrote: > >> Damn - i missed the meeting again :(. I will check the logs to catch up. Sorry >> >> >> On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham wrote: >> Including the whole security group as there was significant interest during the OSSG weekly meeting. >> >> >> >> From: Sriram Subramanian [mailto:sriram at sriramhere.com] >> Sent: 20 February 2014 16:35 >> To: Abu Shohel Ahmed >> Cc: Clark, Robert Graham; Grant Murphy; Mats Näslund; Makan Pourzandi >> Subject: Re: OpenStack Threat Analysis activity - OSSG >> >> >> >> Shohel, >> >> >> >> Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are we meeting tomorrow? >> >> >> >> thanks, >> >> -Sriram >> >> >> >> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed wrote: >> >> Hi, >> >> From our last week’s, it becomes clear that we need set up a way of working process in place >> to take this activity forward. >> >> So here are some ideas (Please also share yours): >> >> 1. WoW: >> >> In the short time frame, >> >> - First, We should define the purpose and the concrete output of this work ( which i think, most of us here has some ideas, if we still have question - >> we can clear that up before moving forward). >> >> - Second issue is, how we can do threat analysis contribution in an effective manner. Here comes the collaboration issues within >> this group. For this, I have created a free node IRC channel ##openstack-threat-analysis ( unofficial channel, as you can see from name). >> Lets start biweekly (15 days) meetings from this week. Lets vote for what is the suitable time for meeting for all of us. >> I propose Friday at 17.00 UTC. However, i am happy to schedule the meeting based on most people preference. >> >> In the longer time frame, we should think about setting up a Threat analysis working group (could be under OSSG) to perform threat modelling of all OpenStack components >> - Define a clear out from this working group e.g., Threat documentation, Design guidance. >> - Engage developers and security minded people to the work. >> >> >> 2. Now on the technical side, >> >> First and foremost, we should agree on a threat modelling process that can be applied for all OpenStack services and internal components. We have some ideas that >> can be applied for this work… Here is the link of our proposal : >> >> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >> >> and here are two concrete implementation of applying the threat modelling process… >> >> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >> >> (These are work in progress documents, so by no means provide a complete picture) >> >> Lets discuss what do you guys think about the Modelling steps and its applicability with OpenStack (e.g., Keystone) >> >> >> >> Thanks, >> Shohel >> >> >> >> >> >> >> >> -- >> >> Thanks, >> >> -Sriram >> >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> >> >> >> -- >> 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: 4163 bytes Desc: not available URL: From sriram at sriramhere.com Fri Mar 7 17:56:07 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Fri, 7 Mar 2014 09:56:07 -0800 Subject: [Openstack-security] OSSG Lead Candidacy Kickoff Message-ID: <531a086b.a9bd440a.6278.ffff9182@mx.google.com> OSSG, Malini was kind enough to point out that election needs choices. In that context, I will continue in the election process. Apologies for the confusion. No matter what the result is, we will be working on making OpenStack more secure. Go OSSG! Thanks, Sriram -----Original Message----- From: "Sriram Subramanian" Sent: ‎3/‎6/‎2014 7:29 PM To: "Bryan D. Payne" Cc: "Bhandaru, Malini K" ; "openstack-security at lists.openstack.org" Subject: Re: [Openstack-security] OSSG Lead Candidacy Kickoff Malini, I would love you to be the OSSG lead - I wasn't aware that you would be interested. In that context, I would be happy to withdraw my nomination. Bryan - please remove my name from the candidates list :) thanks, -Sriram On Thu, Mar 6, 2014 at 8:53 AM, Bryan D. Payne wrote: I confirm that Malini meets all of the requirements to be a candidate. I have added her to https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014. -bryan On Thu, Mar 6, 2014 at 3:25 AM, Bhandaru, Malini K wrote: Hello OSSG Members! I would be honored to lead our efforts as a group to making OpenStack more secure and making OSSG a first class OpenStack citizen. Bryan and Robert have done an excellent job in raising the visibility of security as a cross cutting issue across OpenStack projects, publishing a book, and chasing the nuances of each security issue in OSSAs and OSSNs. Their shoes will be hard to fill. We have a great team and strong regulars and I hope to grow this core to include cores across the projects to be our security eyes, ears and feature design sanitizers. A little about myself: Malini Bhandaru is an Architect and Engineering Manager with the Open Source Technology Center in the Software and Services group at Intel. Over her five year tenure at Intel she has worked on Xeon server power and performance aspects, faster implementations of hashing and encryption algorithms, and more recently on OpenStack. She is proud to be an author of the OpenStack Security Guide, of championing a key manager in OpenStack, and in assisting other Intel cloud efforts. Prior to Intel she has worked on remote monitoring and management, e-commerce, speech recognition, and other products. Malini has a Ph.D. in Computer Science, Artificial Intelligence, from the University of Massachusetts, Amherst. She enjoys gardening, cooking, and long walks. Thanks! Hopping off my soap box Malini From: Bryan D. Payne [mailto:bdpayne at acm.org] Sent: Monday, March 03, 2014 10:19 AM To: openstack-security at lists.openstack.org Subject: [Openstack-security] OSSG Lead Candidacy Kickoff Starting today, and going through March 12, we are accepting candidates for the OSSG Lead election. You can view the complete details on the election process here: https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014 Some relevant details: * Candidates must be active members (as defined in the above link) of OSSG. * Candidates must announce their intention to run by posting a message to this list with the subject "OSSG Lead Candidacy". Either Rob or I will respond to verify that the candidate is an active member and added to the election. All candidates will be added to the election page linked above. Cheers, -bryan _______________________________________________ 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 annasort at us.ibm.com Fri Mar 7 20:03:22 2014 From: annasort at us.ibm.com (Anna A Sortland) Date: Fri, 7 Mar 2014 15:03:22 -0500 Subject: [Openstack-security] All LDAP users returned using keystone v3/users API Message-ID: The current keystone LDAP community driver returns all users that exist in LDAP via the API call v3/users, instead of returning just users that have role grants (similar processing is true for groups). This could potentially be a very large number of users. We have seen large companies with LDAP servers containing hundreds and thousands of users. We are aware of the filters available in keystone.conf ([ldap].user_filter and [ldap].query_scope) to cut down on the number of results, but they do not provide sufficient filtering (for example, it is not possible to set user_filter to members of certain known groups for OpenLDAP without creating a memberOf overlay on the LDAP server). What was the reason the LDAP driver was written this way, instead of returning just the users that have OpenStack-known roles? Was the creation of a separate API for this function considered? Are other exploiters of OpenStack (or users of Horizon) experiencing this issue? If so, what was their approach to overcome this issue? We have been prototyping a keystone extension that provides an API that provides this filtering capability, but it seems like a function that should be generally available in keystone. Anna Sortland Cloud Systems Software Development IBM Rochester, MN annasort at us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Fri Mar 7 21:43:18 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 07 Mar 2014 13:43:18 -0800 Subject: [Openstack-security] All LDAP users returned using keystone v3/users API In-Reply-To: References: Message-ID: <531A3D76.8060302@redhat.com> On 03/07/2014 12:03 PM, Anna A Sortland wrote: > The current keystone LDAP community driver returns all users that exist > in LDAP via the API call v3/users, instead of returning just users that > have role grants (similar processing is true for groups). This could > potentially be a very large number of users. We have seen large > companies with LDAP servers containing hundreds and thousands of users. > We are aware of the filters available in keystone.conf > ([ldap].user_filter and [ldap].query_scope) to cut down on the number of > results, but they do not provide sufficient filtering (for example, it > is not possible to set user_filter to members of certain known groups > for OpenLDAP without creating a memberOf overlay on the LDAP server). > What was the reason the LDAP driver was written this way, instead of > returning just the users that have OpenStack-known roles? What attributes would you filter on? It seems to me that LDAP would need to have knowledge of the roles to be able to filter based on the roles. This is not necessarily the case, as identity and assignment can be split in Keystone such that identity is in LDAP and role assignment is in SQL. I believe it was designed this way to deal with deployments where LDAP already exists and there is no need (or possibility) of adding role info into LDAP. Without filtering based on a role attribute in LDAP, I don't think that there is a good solution if you have OpenStack and non-OpenStack users mixed in the same container in LDAP. If you want to first find all of the users that have a role assigned to them in the assignments backend, then pull their information from LDAP, I think that you will end up with one LDAP search operation per user. This also isn't a very scalable solution. > Was the > creation of a separate API for this function considered? > > Are other exploiters of OpenStack (or users of Horizon) experiencing > this issue? If so, what was their approach to overcome this issue? We > have been prototyping a keystone extension that provides an API that > provides this filtering capability, but it seems like a function that > should be generally available in keystone. I'm curious to know how your prototype is looking to handle this. Thanks, -NGK > > > > Anna Sortland > Cloud Systems Software Development > IBM Rochester, MN > annasort at us.ibm.com > > > > _______________________________________________ > 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 Fri Mar 7 22:40:06 2014 From: sriram at sriramhere.com (SriramHere) Date: Fri, 07 Mar 2014 22:40:06 -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: <20140307224006.27138.37284.malone@chaenomeles.canonical.com> Nathan, I've incorporated the review comments in the OSSN (https://wiki.openstack.org/wiki/OSSN/1227575). Apologize in the delay. I think OSSN is ready to be published now. Please let me know thanks, -Sriram -- 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 malini.k.bhandaru at intel.com Sat Mar 8 02:04:55 2014 From: malini.k.bhandaru at intel.com (Malini Bhandaru) Date: Sat, 08 Mar 2014 02:04:55 -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: <20140308020455.12804.15544.malone@wampee.canonical.com> https://wiki.openstack.org/wiki/OSSN/1227575 Nathan and Sriram .. I read the bug report and it mentions noVNC and SPICE, so I incorporated both in the messaging. Worried that I may have blotched the OSSN. More do I wish it was it git/gerrit. However .. need some clarification .. Per http://docs.openstack.org/trunk/config-reference/content/getting- started-with-vnc-proxy.html Which is the entity that becomes unresponsive? 1) The noVNC Proxy host? (the middle wheel in bottom that hosts the Nova console auth) Or 2) The compute node, top right? What is meant by "no amplification" ? That means damage is limited right, then answer should be (2) above. But if it is two, each compute node would need to be listed and rate limited? -- 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 Sat Mar 8 03:59:13 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Sat, 08 Mar 2014 03:59: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: <20140308035913.7567.44110.malone@soybean.canonical.com> @malini-k-bhandaru > I read the bug report and it mentions noVNC and SPICE, so I incorporated both in the messaging. Good call. I've adjusted some wording slightly, but the additions you made look good overall. > Which is the entity that becomes unresponsive? > 1) The noVNC Proxy host? (the middle wheel in bottom that hosts the Nova console auth) > Or > 2) The compute node, top right? The responsiveness of the nova-novncproxy service is what we are most concerned about. It is true that a host running nova-compute compute node has to deal with the incoming VNC connections as well, but there are usually many compute nodes and instances are balanced across them. If the nova-novncproxy service is the bottleneck, then the compute node itself won't become non-responsive. > What is meant by "no amplification" ? As I understand it, it's a when the volume of traffic in an attack is amplified. This typically involves getting many other services to reflect traffic at the target. For a real world example, lookup "smurf attack". > That means damage is limited right, then answer should be (2) above. It's not limited (which is the main issue here). It just means it's not amplified. That is, the attacker needs to be able to open enough connections themself to overcome the resources of the system running nova-novncproxy. > But if it is two, each compute node would need to be listed and rate limited? As I mentioned above, the nova-novncproxy service is the main concern. It wouldn't hurt to mention that a compute node could be affected too. I've just added this to the note draft on the wiki. -- 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 Sat Mar 8 04:23:28 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Sat, 08 Mar 2014 04:23:28 -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: <20140308042328.14214.34530.malone@gac.canonical.com> Here's an updated OSSN draft that covers all of the issues mentioned in my previous comment (in the appropriate e-mail format). I also removed the reference to rate-limiting in the Security Guide, as it doesn't actually contain any information on how to do rate limiting. It only mentioned that QOSaaS plans to offer rate limiting, which isn't applicable here. If this looks fine to everyone else, I'll go ahead and publish it. ----------------------------------------------------------------------------------------- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit on the number of noVNC or SPICE console sessions that can be established against a single user token. This enables launching a Denial of Service (DoS) style attack by establishing many console sessions against a single virtual machine instance through the console proxy. This can cause instance access timeouts and general service response degradation on the console host. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -- 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 malini.k.bhandaru at intel.com Sat Mar 8 05:34:09 2014 From: malini.k.bhandaru at intel.com (Bhandaru, Malini K) Date: Sat, 8 Mar 2014 05:34:09 +0000 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption In-Reply-To: <20140308042328.14214.34530.malone@gac.canonical.com> References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com> <20140308042328.14214.34530.malone@gac.canonical.com> Message-ID: +1 I totally like it. Glad you added that last line on how we expect to handle it in future release. -----Original Message----- From: Nathan Kinder [mailto:nkinder at redhat.com] Sent: Friday, March 07, 2014 8:23 PM To: openstack-security at lists.openstack.org Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption Here's an updated OSSN draft that covers all of the issues mentioned in my previous comment (in the appropriate e-mail format). I also removed the reference to rate-limiting in the Security Guide, as it doesn't actually contain any information on how to do rate limiting. It only mentioned that QOSaaS plans to offer rate limiting, which isn't applicable here. If this looks fine to everyone else, I'll go ahead and publish it. ----------------------------------------------------------------------------------------- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit on the number of noVNC or SPICE console sessions that can be established against a single user token. This enables launching a Denial of Service (DoS) style attack by establishing many console sessions against a single virtual machine instance through the console proxy. This can cause instance access timeouts and general service response degradation on the console host. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -- 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 _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From malini.k.bhandaru at intel.com Sat Mar 8 05:34:09 2014 From: malini.k.bhandaru at intel.com (Malini Bhandaru) Date: Sat, 08 Mar 2014 05:34:09 -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> <20140308042328.14214.34530.malone@gac.canonical.com> Message-ID: +1 I totally like it. Glad you added that last line on how we expect to handle it in future release. -----Original Message----- From: Nathan Kinder [mailto:nkinder at redhat.com] Sent: Friday, March 07, 2014 8:23 PM To: openstack-security at lists.openstack.org Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC server can lead to service interruption or disruption Here's an updated OSSN draft that covers all of the issues mentioned in my previous comment (in the appropriate e-mail format). I also removed the reference to rate-limiting in the Security Guide, as it doesn't actually contain any information on how to do rate limiting. It only mentioned that QOSaaS plans to offer rate limiting, which isn't applicable here. If this looks fine to everyone else, I'll go ahead and publish it. ----------------------------------------------------------------------------------------- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit on the number of noVNC or SPICE console sessions that can be established against a single user token. This enables launching a Denial of Service (DoS) style attack by establishing many console sessions against a single virtual machine instance through the console proxy. This can cause instance access timeouts and general service response degradation on the console host. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -- 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 _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-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/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 sriram at sriramhere.com Sat Mar 8 06:02:43 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Fri, 7 Mar 2014 22:02:43 -0800 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption Message-ID: <531ab2b6.e891420a.594d.ffff945b@mx.google.com> Thanks Nathan, good to publish! -----Original Message----- From: "Nathan Kinder" Sent: ‎3/‎7/‎2014 8:33 PM To: "openstack-security at lists.openstack.org" Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption Here's an updated OSSN draft that covers all of the issues mentioned in my previous comment (in the appropriate e-mail format). I also removed the reference to rate-limiting in the Security Guide, as it doesn't actually contain any information on how to do rate limiting. It only mentioned that QOSaaS plans to offer rate limiting, which isn't applicable here. If this looks fine to everyone else, I'll go ahead and publish it. ----------------------------------------------------------------------------------------- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit on the number of noVNC or SPICE console sessions that can be established against a single user token. This enables launching a Denial of Service (DoS) style attack by establishing many console sessions against a single virtual machine instance through the console proxy. This can cause instance access timeouts and general service response degradation on the console host. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -- 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 _______________________________________________ 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 Sat Mar 8 06:02:43 2014 From: sriram at sriramhere.com (SriramHere) Date: Sat, 08 Mar 2014 06:02:43 -0000 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com> Message-ID: <531ab2b6.e891420a.594d.ffff945b@mx.google.com> Thanks Nathan, good to publish! -----Original Message----- From: "Nathan Kinder" Sent: ‎3/‎7/‎2014 8:33 PM To: "openstack-security at lists.openstack.org" Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption Here's an updated OSSN draft that covers all of the issues mentioned in my previous comment (in the appropriate e-mail format). I also removed the reference to rate-limiting in the Security Guide, as it doesn't actually contain any information on how to do rate limiting. It only mentioned that QOSaaS plans to offer rate limiting, which isn't applicable here. If this looks fine to everyone else, I'll go ahead and publish it. ----------------------------------------------------------------------------------------- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit on the number of noVNC or SPICE console sessions that can be established against a single user token. This enables launching a Denial of Service (DoS) style attack by establishing many console sessions against a single virtual machine instance through the console proxy. This can cause instance access timeouts and general service response degradation on the console host. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -- 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 _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-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/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 Sat Mar 8 20:47:53 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Sat, 8 Mar 2014 20:47:53 +0000 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption In-Reply-To: <531ab2b6.e891420a.594d.ffff945b@mx.google.com> References: <531ab2b6.e891420a.594d.ffff945b@mx.google.com> Message-ID: The OSSN looks great, but I think perhaps the summary could be tweaked to be a little shorter and maybe flow a little better… There is currently no limit to the number of noVNC or SPICE console sessions that can be established by a single user. The console host has limited resources and an attacker launching many sessions may be able to exhaust the available resources, resulting in a Denial of Service (DoS) condition. Other than that it’s hot-to-trot, as they say. -Rob From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: 08 March 2014 06:03 To: Bug 1227575; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption Thanks Nathan, good to publish! ________________________________ From: Nathan Kinder Sent: ‎3/‎7/‎2014 8:33 PM To: openstack-security at lists.openstack.org Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption Here's an updated OSSN draft that covers all of the issues mentioned in my previous comment (in the appropriate e-mail format). I also removed the reference to rate-limiting in the Security Guide, as it doesn't actually contain any information on how to do rate limiting. It only mentioned that QOSaaS plans to offer rate limiting, which isn't applicable here. If this looks fine to everyone else, I'll go ahead and publish it. ----------------------------------------------------------------------------------------- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit on the number of noVNC or SPICE console sessions that can be established against a single user token. This enables launching a Denial of Service (DoS) style attack by establishing many console sessions against a single virtual machine instance through the console proxy. This can cause instance access timeouts and general service response degradation on the console host. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -- 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 _______________________________________________ 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 1227575 at bugs.launchpad.net Sat Mar 8 20:47:53 2014 From: 1227575 at bugs.launchpad.net (Robert Clark) Date: Sat, 08 Mar 2014 20:47:53 -0000 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com> <531ab2b6.e891420a.594d.ffff945b@mx.google.com> Message-ID: The OSSN looks great, but I think perhaps the summary could be tweaked to be a little shorter and maybe flow a little better… There is currently no limit to the number of noVNC or SPICE console sessions that can be established by a single user. The console host has limited resources and an attacker launching many sessions may be able to exhaust the available resources, resulting in a Denial of Service (DoS) condition. Other than that it’s hot-to-trot, as they say. -Rob From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: 08 March 2014 06:03 To: Bug 1227575; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption Thanks Nathan, good to publish! ________________________________ From: Nathan Kinder Sent: ‎3/‎7/‎2014 8:33 PM To: openstack-security at lists.openstack.org Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption Here's an updated OSSN draft that covers all of the issues mentioned in my previous comment (in the appropriate e-mail format). I also removed the reference to rate-limiting in the Security Guide, as it doesn't actually contain any information on how to do rate limiting. It only mentioned that QOSaaS plans to offer rate limiting, which isn't applicable here. If this looks fine to everyone else, I'll go ahead and publish it. ----------------------------------------------------------------------------------------- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit on the number of noVNC or SPICE console sessions that can be established against a single user token. This enables launching a Denial of Service (DoS) style attack by establishing many console sessions against a single virtual machine instance through the console proxy. This can cause instance access timeouts and general service response degradation on the console host. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -- 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 _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-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/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 sriram at sriramhere.com Sun Mar 9 04:05:48 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Sat, 8 Mar 2014 20:05:48 -0800 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack onnoVNCserver can lead to service interruption or disruption Message-ID: <531be8d6.43da440a.189e.3eed@mx.google.com> I'll make those corrections, thanks Rob. -----Original Message----- From: "Clark, Robert Graham" Sent: ‎3/‎8/‎2014 12:51 PM To: "Sriram Subramanian" ; "Bug 1227575" <1227575 at bugs.launchpad.net>; "openstack-security at lists.openstack.org" Subject: RE: [Openstack-security] [Bug 1227575] Re: DoS style attack onnoVNCserver can lead to service interruption or disruption The OSSN looks great, but I think perhaps the summary could be tweaked to be a little shorter and maybe flow a little better… There is currently no limit to the number of noVNC or SPICE console sessions that can be established by a single user. The console host has limited resources and an attacker launching many sessions may be able to exhaust the available resources, resulting in a Denial of Service (DoS) condition. Other than that it’s hot-to-trot, as they say. -Rob From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: 08 March 2014 06:03 To: Bug 1227575; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption Thanks Nathan, good to publish! From: Nathan Kinder Sent: ‎3/‎7/‎2014 8:33 PM To: openstack-security at lists.openstack.org Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNCserver can lead to service interruption or disruption Here's an updated OSSN draft that covers all of the issues mentioned in my previous comment (in the appropriate e-mail format). I also removed the reference to rate-limiting in the Security Guide, as it doesn't actually contain any information on how to do rate limiting. It only mentioned that QOSaaS plans to offer rate limiting, which isn't applicable here. If this looks fine to everyone else, I'll go ahead and publish it. ----------------------------------------------------------------------------------------- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit on the number of noVNC or SPICE console sessions that can be established against a single user token. This enables launching a Denial of Service (DoS) style attack by establishing many console sessions against a single virtual machine instance through the console proxy. This can cause instance access timeouts and general service response degradation on the console host. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -- 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 [The entire original message is not included.] -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Sun Mar 9 16:12:02 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Sun, 9 Mar 2014 16:12:02 +0000 Subject: [Openstack-security] OSSG Lead Candidacy Message-ID: Friends, After speaking at length with Bryan and others (both in the OSSG and at my company, HP) I am delighted to join Malini and Sriram in announcing myself as a candidate for leading the OSSG. Of course this means I can no longer be an election official and as such I humbly request that Bryan validate me as 'active' and include me in the official list of candidates. What an amazing journey we've been on over the last two years. We've got a lot done in this time, establishing the OSSN process and publishing over 20 pieces of guidance, working with the VMT to assess and triage vulnerabilities, producing the worlds first (and best!) book on OpenStack security and grown our membership numbers to over 100. In the future I'd like to see us take on more ambitious projects, to further ramp up OSSN releases and continue to develop the security guide - but beyond our current functions I want us to embrace security reviews, to really engage with development teams on security and work together to find more security issues and improve the security architecture that underpins OpenStack. I believe that through conducting group reviews and defining good processes for doing so, we can raise the bar in OpenStack Security together, improving OpenStack as a whole. I want to see the OSSG get involved in more projects, try new things and extend our capabilities, my role at HP has changed recently and I'm now 100% dedicated to OpenStack facing projects - this means more time from me, and more help from my security team in lifting some of the load. If elected I'll look to delegate responsibility wherever possible so that everyone can contribute as much as they want to and those who like me, have a specific mandate to improve OpenStack security are given the tools and support they need to make it happen. Thanks, -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Sun Mar 9 17:02:56 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Sun, 09 Mar 2014 10:02:56 -0700 Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack onnoVNCserver can lead to service interruption or disruption In-Reply-To: <531be8d6.43da440a.189e.3eed@mx.google.com> References: <531be8d6.43da440a.189e.3eed@mx.google.com> Message-ID: <531C9EC0.4050203@redhat.com> On 03/08/2014 08:05 PM, Sriram Subramanian wrote: > I'll make those corrections, thanks Rob. I've already taken care of it and have published the completed OSSN to the mailing lists and the wiki. Thanks, -NGK > ------------------------------------------------------------------------ > From: Clark, Robert Graham > Sent: ‎3/‎8/‎2014 12:51 PM > To: Sriram Subramanian ; Bug 1227575 > ; > openstack-security at lists.openstack.org > > Subject: RE: [Openstack-security] [Bug 1227575] Re: DoS style attack > onnoVNCserver can lead to service interruption or disruption > > The OSSN looks great, but I think perhaps the summary could be tweaked > to be a little shorter and maybe flow a little better… > > > > There is currently no limit to the number of noVNC or SPICE console > sessions that can be established by a single user. The console host has > limited resources and an attacker launching many sessions may be able to > exhaust the available resources, resulting in a Denial of Service (DoS) > condition. > > > > Other than that it’s hot-to-trot, as they say. > > > > -Rob > From nkinder at redhat.com Sun Mar 9 16:55:41 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Sun, 09 Mar 2014 16:55:41 -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: <20140309165542.8172.77112.malone@soybean.canonical.com> I've adjusted the "Summary" section as suggested by Rob. I've gone ahead and published the following OSSN to the following locations: https://wiki.openstack.org/wiki/OSSN/OSSN-0008 openstack at lists.openstack.org openstack-dev at lists.openstack.org Thanks everyone for the reviews and contributions to this OSSN! -------------------------------------------------------------------------- DoS style attack on noVNC server can lead to service interruption or disruption --- ### Summary ### There is currently no limit to the number of noVNC or SPICE console sessions that can be established by a single user. The console host has limited resources and an attacker launching many sessions may be able to exhaust the available resources, resulting in a Denial of Service (DoS) condition. ### Affected Services / Software ### Horizon, Nova, noVNC proxy, SPICE console, Grizzly, Havana ### Discussion ### Currently with a single user token, no restrictions are enforced on the number or frequency of noVNC or SPICE console sessions that may be established. While a user can only access their own virtual machine instances, resources can be exhausted on the console proxy host by creating an excessive number of simultaneous console sessions. This can result in timeouts for subsequent connection requests to instances using the same console proxy. Not only would this prevent the user from accessing their own instances, but other legitimate users would also be deprived of console access. Further, other services running on the noVNC proxy and Compute hosts may degrade in responsiveness. By taking advantage of this lack of restrictions around noVNC or SPICE console connections, a single user could cause the console proxy endpoint to become unresponsive, resulting in a Denial Of Service (DoS) style attack. It should be noted that there is no amplification effect. ### Recommended Actions ### For current stable OpenStack releases (Grizzly, Havana), users need to workaround this vulnerability by using rate-limiting proxies to cover access to the noVNC proxy service. Rate-limiting is a common mechanism to prevent DoS and Brute-Force attacks. For example, if you are using a proxy such as Repose, enable the rate limiting feature by following these steps: https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter Future OpenStack releases are looking to add the ability to restrict noVNC and SPICE console connections. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0008 Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1227575 OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg ** Changed in: ossn Status: New => 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/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: Fix Released 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 Mon Mar 10 02:48:19 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Sun, 9 Mar 2014 19:48:19 -0700 Subject: [Openstack-security] OSSG Lead Candidacy In-Reply-To: References: Message-ID: I confirm that Rob meets all of the requirements to be a candidate. I have added him to https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014. And I have removed Rob from being an election official. -bryan On Sun, Mar 9, 2014 at 9:12 AM, Clark, Robert Graham wrote: > Friends, > > > > After speaking at length with Bryan and others (both in the OSSG and at my > company, HP) I am delighted to join Malini and Sriram in announcing myself > as a candidate for leading the OSSG. Of course this means I can no longer > be an election official and as such I humbly request that Bryan validate me > as 'active' and include me in the official list of candidates. > > > > What an amazing journey we've been on over the last two years. We've got a > lot done in this time, establishing the OSSN process and publishing over 20 > pieces of guidance, working with the VMT to assess and triage > vulnerabilities, producing the worlds first (and best!) book on OpenStack > security and grown our membership numbers to over 100. > > > > In the future I'd like to see us take on more ambitious projects, to > further ramp up OSSN releases and continue to develop the security guide - > but beyond our current functions I want us to embrace security reviews, to > really engage with development teams on security and work together to find > more security issues and improve the security architecture that underpins > OpenStack. I believe that through conducting group reviews and defining > good processes for doing so, we can raise the bar in OpenStack Security > together, improving OpenStack as a whole. > > > > I want to see the OSSG get involved in more projects, try new things and > extend our capabilities, my role at HP has changed recently and I'm now > 100% dedicated to OpenStack facing projects - this means more time from me, > and more help from my security team in lifting some of the load. If elected > I'll look to delegate responsibility wherever possible so that everyone can > contribute as much as they want to and those who like me, have a specific > mandate to improve OpenStack security are given the tools and support they > need to make it happen. > > > > Thanks, > > -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 fungi at yuggoth.org Mon Mar 10 15:12:11 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 10 Mar 2014 15:12:11 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140310151211.26371.18691.malone@chaenomeles.canonical.com> Tagging security. The OSSG may decide this is worth drafting a note about, for broader visibility within the community. ** Tags added: security ** Information type changed from Public Security to Public ** 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/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From annasort at us.ibm.com Mon Mar 10 18:05:20 2014 From: annasort at us.ibm.com (Anna A Sortland) Date: Mon, 10 Mar 2014 14:05:20 -0400 Subject: [Openstack-security] All LDAP users returned using keystone v3/users API In-Reply-To: <531A3D76.8060302@redhat.com> References: <531A3D76.8060302@redhat.com> Message-ID: On 03/07/2014 12:03 PM, Anna A Sortland wrote: > The current keystone LDAP community driver returns all users that exist > in LDAP via the API call v3/users, instead of returning just users that > have role grants (similar processing is true for groups). This could > potentially be a very large number of users. We have seen large > companies with LDAP servers containing hundreds and thousands of users. > We are aware of the filters available in keystone.conf > ([ldap].user_filter and [ldap].query_scope) to cut down on the number of > results, but they do not provide sufficient filtering (for example, it > is not possible to set user_filter to members of certain known groups > for OpenLDAP without creating a memberOf overlay on the LDAP server). > What was the reason the LDAP driver was written this way, instead of > returning just the users that have OpenStack-known roles? What attributes would you filter on? It seems to me that LDAP would need to have knowledge of the roles to be able to filter based on the roles. This is not necessarily the case, as identity and assignment can be split in Keystone such that identity is in LDAP and role assignment is in SQL. I believe it was designed this way to deal with deployments where LDAP already exists and there is no need (or possibility) of adding role info into LDAP. That's our main use case. The users and groups are in LDAP and role assignments are in SQL. You would filter on role grants and this information is in SQL backend. So new API would need to query both identity and assignment drivers. Without filtering based on a role attribute in LDAP, I don't think that there is a good solution if you have OpenStack and non-OpenStack users mixed in the same container in LDAP. If you want to first find all of the users that have a role assigned to them in the assignments backend, then pull their information from LDAP, I think that you will end up with one LDAP search operation per user. This also isn't a very scalable solution. > Was the > creation of a separate API for this function considered? > > Are other exploiters of OpenStack (or users of Horizon) experiencing > this issue? If so, what was their approach to overcome this issue? We > have been prototyping a keystone extension that provides an API that > provides this filtering capability, but it seems like a function that > should be generally available in keystone. I'm curious to know how your prototype is looking to handle this. The prototype basically first calls assignment API list_role_assignments() to get a list of users and groups with role grants. It then iterates the retrieved list and calls identity API list_users_in_group() to get the list of users in these groups with grants and get_user() to get users that have role grants but do not belong to the groups with role grants (a call for each user). Both calls ignore groups and users that are not found in the LDAP registry but exist in SQL (this could be the result of a user or group being removed from LDAP, but the corresponding role grant was not revoked). Then the code removes duplicates if any and returns the combined list. The new extension API is /v3/my_new_extension/users. Maybe the better naming would be v3/roles/users (list users with any role) - compare to existing v3/roles/​{role_id}​/users (list users with a specified role). Another alternative that we've tried is just a new identity driver that inherits from keystone.identity.backends.ldap.LDAPIdentity and overrides just the list_users() function. That's probably not the best approach from OpenStack standards point of view but I would like to get community's feedback on whether this is acceptable. Thanks, -NGK > > > > Anna Sortland > Cloud Systems Software Development > IBM Rochester, MN > annasort at us.ibm.com Anna Sortland Cloud Systems Software Development IBM Rochester, MN annasort at us.ibm.com From: Nathan Kinder To: Anna A Sortland/Rochester/IBM at IBMUS, openstack-security at lists.openstack.org, Date: 03/07/2014 03:43 PM Subject: Re: [Openstack-security] All LDAP users returned using keystone v3/users API On 03/07/2014 12:03 PM, Anna A Sortland wrote: > The current keystone LDAP community driver returns all users that exist > in LDAP via the API call v3/users, instead of returning just users that > have role grants (similar processing is true for groups). This could > potentially be a very large number of users. We have seen large > companies with LDAP servers containing hundreds and thousands of users. > We are aware of the filters available in keystone.conf > ([ldap].user_filter and [ldap].query_scope) to cut down on the number of > results, but they do not provide sufficient filtering (for example, it > is not possible to set user_filter to members of certain known groups > for OpenLDAP without creating a memberOf overlay on the LDAP server). > What was the reason the LDAP driver was written this way, instead of > returning just the users that have OpenStack-known roles? What attributes would you filter on? It seems to me that LDAP would need to have knowledge of the roles to be able to filter based on the roles. This is not necessarily the case, as identity and assignment can be split in Keystone such that identity is in LDAP and role assignment is in SQL. I believe it was designed this way to deal with deployments where LDAP already exists and there is no need (or possibility) of adding role info into LDAP. Without filtering based on a role attribute in LDAP, I don't think that there is a good solution if you have OpenStack and non-OpenStack users mixed in the same container in LDAP. If you want to first find all of the users that have a role assigned to them in the assignments backend, then pull their information from LDAP, I think that you will end up with one LDAP search operation per user. This also isn't a very scalable solution. > Was the > creation of a separate API for this function considered? > > Are other exploiters of OpenStack (or users of Horizon) experiencing > this issue? If so, what was their approach to overcome this issue? We > have been prototyping a keystone extension that provides an API that > provides this filtering capability, but it seems like a function that > should be generally available in keystone. I'm curious to know how your prototype is looking to handle this. Thanks, -NGK > > > > Anna Sortland > Cloud Systems Software Development > IBM Rochester, MN > annasort at us.ibm.com > > > > _______________________________________________ > 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 geekinutah at gmail.com Mon Mar 10 23:07:29 2014 From: geekinutah at gmail.com (Michael H Wilson) Date: Mon, 10 Mar 2014 23:07:29 -0000 Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session token in URL and insecurely sets the session cookie References: <20130703161152.14968.85936.malonedeb@gac.canonical.com> Message-ID: <20140310230730.13017.69034.malone@wampee.canonical.com> @parthipan Much appreciated. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1197459 Title: noVNC contains the session token in URL and insecurely sets the session cookie Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Bug description: The VNC Console connection in Nova works by having the user connect to the API which returns a URL such as: https://example.com:443/?token=abc Where the token has a TTL which is then used to create a session from a WebSocket. However, URL's should not contain sensitive information such as session tokens with a TTL since URL's can be leaked through proxy logs or other types of attacks such as Cross-Site Scripting. Additionally, due to the session cookie being set with JavaScript it cannot securely be set to HttpOnly nor is it set with the Secure flag making it further susceptible to Cross- Site Scripting attacks or leakage through a non-SSL connection. To limit the exposure of the token being leaked through the URL the returned token from the API should be of a one-time use and only used as an authentication token in order to obtain a session. The session cookie should be set by a Web Service instead of the client in order to securely set the cookie with the HttpOnly flag to be set in addition to setting the Secure flag. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1197459/+subscriptions From 1158328 at bugs.launchpad.net Tue Mar 4 09:59:09 2014 From: 1158328 at bugs.launchpad.net (=?utf-8?q?Dani=C3=ABl_W=2E_Crompton?=) Date: Tue, 04 Mar 2014 09:59:09 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> <20140224215331.851.7846.malone@gac.canonical.com> Message-ID: A shadow like password wouldn't be possible as it needs to be reversible. And as it's reversible anybody with access to the file would be able to reverse it with the encryption scheme. Making it security by obscurity. This could probably best be solved with something like a pkcs7 key exchange, although this would be a little more work. D. On Mar 4, 2014 10:35 AM, "Matt Fischer" wrote: > I see this bug is old and Wishlisted so it may never get fixed, but I'd > like to add that plaintext passwords are generally a no-no when the > service account auth is managed by Corporate AD or LDAP. It may > complicate some deployments but it would be nice to have a solution to > this. > > -- > You received this bug notification because you are a member of OpenStack > Security Group, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1158328 > > Title: > passwords in config files stored in plaintext > > Status in OpenStack Compute (Nova): > Confirmed > > Bug description: > The credentials for database conenctions and the keystone authtoken > are stored in plaintext within the nova.conf and apipaste config > files. > > These values should be encrypted. A scheme similar to /etc/shadow > would be great. > > To manage notifications about this bug go to: > https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-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/1158328 Title: passwords in config files stored in plaintext Status in OpenStack Compute (Nova): Confirmed Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions From 1158328 at bugs.launchpad.net Tue Mar 4 14:51:55 2014 From: 1158328 at bugs.launchpad.net (Adrian Otto) Date: Tue, 04 Mar 2014 14:51:55 -0000 Subject: [Openstack-security] [Bug 1158328] Re: passwords in config files stored in plaintext References: <20130321141459.14228.40307.malonedeb@soybean.canonical.com> <20140224215331.851.7846.malone@gac.canonical.com> Message-ID: <14DF2790-6CF8-4D5D-9405-AADCE4AEA613@rackspace.com> I see Barbican as the right tool for this job. The configuration file can get the secret identifier, and the secret itself can be stored in Barbican where it can be centrally fortified, access controlled, access logged, and could be revoked. The service would use an HTTPS request to retrieve the secret from its encrypted remote storage in Barbican on an as-needed basis. -- Adrian On Mar 4, 2014, at 2:01 AM, "Daniël W. Crompton" > wrote: A shadow like password wouldn't be possible as it needs to be reversible. And as it's reversible anybody with access to the file would be able to reverse it with the encryption scheme. Making it security by obscurity. This could probably best be solved with something like a pkcs7 key exchange, although this would be a little more work. D. On Mar 4, 2014 10:35 AM, "Matt Fischer" > wrote: I see this bug is old and Wishlisted so it may never get fixed, but I'd like to add that plaintext passwords are generally a no-no when the service account auth is managed by Corporate AD or LDAP. It may complicate some deployments but it would be nice to have a solution to this. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in OpenStack Compute (Nova): Confirmed Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions _______________________________________________ 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 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1158328 Title: passwords in config files stored in plaintext Status in OpenStack Compute (Nova): Confirmed Bug description: The credentials for database conenctions and the keystone authtoken are stored in plaintext within the nova.conf and apipaste config files. These values should be encrypted. A scheme similar to /etc/shadow would be great. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1158328/+subscriptions From lilinguo8212 at gmail.com Fri Mar 7 08:18:43 2014 From: lilinguo8212 at gmail.com (Lee Li) Date: Fri, 07 Mar 2014 08:18:43 -0000 Subject: [Openstack-security] [Bug 1289195] Re: The duplicate security group name cause don't know witch security group use in instance References: <20140307080022.26596.61856.malonedeb@chaenomeles.canonical.com> Message-ID: <20140307081844.7951.64009.launchpad@soybean.canonical.com> ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1289195 Title: The duplicate security group name cause don't know witch security group use in instance Status in OpenStack Neutron (virtual network service): New Bug description: When create a security group, the duplicate name is allowed. In create a instance, which security group to use is designed by sg name, this may cause the user don't know witch sg is used and it may be not the user wanted. So the duplicate name of sg should be not allowed. In create instance, it's use set to filter the duplicate sg like: sg_names = list(set(sg_names)) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1289195/+subscriptions From 1289195 at bugs.launchpad.net Mon Mar 10 07:56:55 2014 From: 1289195 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 10 Mar 2014 07:56:55 -0000 Subject: [Openstack-security] [Bug 1289195] Re: The duplicate security group name cause don't know witch security group use in instance References: <20140307080022.26596.61856.malonedeb@chaenomeles.canonical.com> Message-ID: <20140310075655.13348.9382.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/79270 ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1289195 Title: The duplicate security group name cause don't know witch security group use in instance Status in OpenStack Neutron (virtual network service): In Progress Bug description: When create a security group, the duplicate name is allowed. In create a instance, which security group to use is designed by sg name, this may cause the user don't know witch sg is used and it may be not the user wanted. So the duplicate name of sg should be not allowed. In create instance, it's use set to filter the duplicate sg like: sg_names = list(set(sg_names)) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1289195/+subscriptions From jsbryant at us.ibm.com Mon Mar 10 15:17:36 2014 From: jsbryant at us.ibm.com (Jay Bryant) Date: Mon, 10 Mar 2014 15:17:36 -0000 Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set insecure file permissions References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com> Message-ID: <20140310151736.26433.37888.malone@chaenomeles.canonical.com> Removing Bill Owen as the assignee given that this is now resolved for GPFS. ** Changed in: cinder Assignee: Bill Owen (billowen) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260679 Title: Multiple drivers set insecure file permissions Status in Cinder: In Progress Status in OpenStack Security Notes: In Progress Bug description: GPFS from various places calls "chmod 666" as root: ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', path, run_as_root=True) ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', vol_path, run_as_root=True) the Huawei driver sets 777 permissions as root on some files: ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) the Scality driver sets 666 permissions on all volumes: cinder/volume/drivers/scality.py:     def _create_file(self, path, size):         with open(path, "ab") as f:             f.truncate(size)         os.chmod(path, 0o666) Similarly, the NFS and NEXENTA driver have an implementation of def _set_rw_permissions_for_all() that is being called on all newly created volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1260679/+subscriptions From 1244025 at bugs.launchpad.net Mon Mar 10 21:32:25 2014 From: 1244025 at bugs.launchpad.net (Ryu Ishimoto) Date: Mon, 10 Mar 2014 21:32:25 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140310213225.26371.85906.malone@chaenomeles.canonical.com> This change was replaced by https://review.openstack.org/#/c/78543/ . Note that the original patch was abandoned in favor of this because it was too big to be reviewed and preferred to be broken up into smaller bits. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From lilinguo8212 at gmail.com Tue Mar 11 02:39:47 2014 From: lilinguo8212 at gmail.com (Lee Li) Date: Tue, 11 Mar 2014 02:39:47 -0000 Subject: [Openstack-security] [Bug 1289195] Re: The duplicate security group name cause don't know witch security group use in instance References: <20140307080022.26596.61856.malonedeb@chaenomeles.canonical.com> Message-ID: <20140311023948.26907.42011.launchpad@chaenomeles.canonical.com> ** Description changed: When create a security group, the duplicate name is allowed. - In create a instance, which security group to use is designed by sg name, this may cause the user don't know witch sg is used and it may be not the user wanted. So the duplicate name of sg should be not allowed. + In create a instance, duplicate sg name will cause exception. + So the duplicate name of sg should be not allowed. - In create instance, it's use set to filter the duplicate sg like: - sg_names = list(set(sg_names)) + In nova.network.neutronv2.API:allocate_for_instance + for security_group in security_groups: + name_match = None + uuid_match = None + for user_security_group in user_security_groups: + if user_security_group['name'] == security_group: # if have duplicate sg name, the name_match will not be None for the second matching. + if name_match: + raise exception.NoUniqueMatch( + _("Multiple security groups found matching" + " '%s'. Use an ID to be more specific.") % + security_group) + + name_match = user_security_group['id'] + if user_security_group['id'] == security_group: + uuid_match = user_security_group['id'] ** Description changed: When create a security group, the duplicate name is allowed. - In create a instance, duplicate sg name will cause exception. - So the duplicate name of sg should be not allowed. + In create a instance, duplicate sg name will cause exception and the instance will be started fail. So the duplicate name of sg should be not allowed. In nova.network.neutronv2.API:allocate_for_instance for security_group in security_groups: - name_match = None - uuid_match = None - for user_security_group in user_security_groups: - if user_security_group['name'] == security_group: # if have duplicate sg name, the name_match will not be None for the second matching. - if name_match: - raise exception.NoUniqueMatch( - _("Multiple security groups found matching" - " '%s'. Use an ID to be more specific.") % - security_group) +     name_match = None +     uuid_match = None +     for user_security_group in user_security_groups: +         if user_security_group['name'] == security_group: # if have duplicate sg name, the name_match will not be None for the second matching. +             if name_match: +                 raise exception.NoUniqueMatch( +                     _("Multiple security groups found matching" +                        " '%s'. Use an ID to be more specific.") % +                     security_group) - name_match = user_security_group['id'] - if user_security_group['id'] == security_group: - uuid_match = user_security_group['id'] +             name_match = user_security_group['id'] +         if user_security_group['id'] == security_group: +             uuid_match = user_security_group['id'] ** Summary changed: - The duplicate security group name cause don't know witch security group use in instance + Duplicate security group name cause fail to start instance -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1289195 Title: Duplicate security group name cause fail to start instance Status in OpenStack Neutron (virtual network service): In Progress Bug description: When create a security group, the duplicate name is allowed. In create a instance, duplicate sg name will cause exception and the instance will be started fail. So the duplicate name of sg should be not allowed. In nova.network.neutronv2.API:allocate_for_instance for security_group in security_groups:     name_match = None     uuid_match = None     for user_security_group in user_security_groups:         if user_security_group['name'] == security_group: # if have duplicate sg name, the name_match will not be None for the second matching.             if name_match:                 raise exception.NoUniqueMatch(                     _("Multiple security groups found matching"                        " '%s'. Use an ID to be more specific.") %                     security_group)             name_match = user_security_group['id']         if user_security_group['id'] == security_group:             uuid_match = user_security_group['id'] To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1289195/+subscriptions From 1129748 at bugs.launchpad.net Tue Mar 11 10:13:52 2014 From: 1129748 at bugs.launchpad.net (Xavier Queralt) Date: Tue, 11 Mar 2014 10:13:52 -0000 Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should not be world-readable References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com> Message-ID: <20140311101354.26402.46117.launchpad@chaenomeles.canonical.com> ** Changed in: nova Assignee: Xavier Queralt (xqueralt) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (Nova): In Progress Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions From gerrit2 at review.openstack.org Tue Mar 11 15:26:44 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 11 Mar 2014 15:26:44 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77346 Log: commit 2c9a1132adf70e434e07e9c099d5a59347a95655 Author: Daniel Gollub Date: Sat Feb 22 21:37:59 2014 +0100 Replace HTTPSConnection in zadara driver Replace HTTPSConnection in zadara driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the SAN would not pass the verification. Old behaviour can be forced by using `san_ssl_insecure=True`. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b From gerrit2 at review.openstack.org Tue Mar 11 15:49:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 11 Mar 2014 15:49:02 +0000 Subject: [Openstack-security] [openstack/neutron] SecurityImpact review request change I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77414 Log: commit 61e6534f8b2ac1b31e7d5a9017d47ff2ba64cffa Author: Daniel Gollub Date: Sun Mar 2 09:33:38 2014 +0100 Replace HTTPSConnection in NEC plugin Replace HTTPSConnection in NEC plugin PFC driver with Requests. SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the NEC PFC driver would not pass the verification. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337 From 1188189 at bugs.launchpad.net Tue Mar 11 15:48:56 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 11 Mar 2014 15:48:56 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140311154900.26765.70539.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Assignee: Mark McClain (markmcclain) => Daniel Gollub (d-gollub) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1188189 at bugs.launchpad.net Tue Mar 11 18:43:59 2014 From: 1188189 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 11 Mar 2014 18:43:59 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140311184402.13286.81439.launchpad@gac.canonical.com> ** Changed in: keystone Milestone: None => icehouse-rc1 ** Changed in: keystone Importance: Medium => 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/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From yangxurong at huawei.com Wed Mar 12 08:43:24 2014 From: yangxurong at huawei.com (Xurong Yang) Date: Wed, 12 Mar 2014 08:43:24 -0000 Subject: [Openstack-security] [Bug 1289195] Re: Duplicate security group name cause fail to start instance References: <20140307080022.26596.61856.malonedeb@chaenomeles.canonical.com> Message-ID: <20140312084324.29843.17145.malone@gac.canonical.com> It should be using UUID instead of 'name' such as network_id port_id as name(not the key) can't differentiate security groups. so i think we should fix it in nova. ** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Assignee: (unassigned) => Xurong Yang (idopra) ** Changed in: nova Status: New => In Progress ** Changed in: neutron Status: Opinion => 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/1289195 Title: Duplicate security group name cause fail to start instance Status in OpenStack Neutron (virtual network service): Invalid Status in OpenStack Compute (Nova): In Progress Bug description: When create a security group, the duplicate name is allowed. In create a instance, duplicate sg name will cause exception and the instance will be started fail. So the duplicate name of sg should be not allowed. In nova.network.neutronv2.API:allocate_for_instance for security_group in security_groups:     name_match = None     uuid_match = None     for user_security_group in user_security_groups:         if user_security_group['name'] == security_group: # if have duplicate sg name, the name_match will not be None for the second matching.             if name_match:                 raise exception.NoUniqueMatch(                     _("Multiple security groups found matching"                        " '%s'. Use an ID to be more specific.") %                     security_group)             name_match = user_security_group['id']         if user_security_group['id'] == security_group:             uuid_match = user_security_group['id'] To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1289195/+subscriptions From edmondsw at us.ibm.com Wed Mar 12 12:15:27 2014 From: edmondsw at us.ibm.com (William M Edmonds) Date: Wed, 12 Mar 2014 08:15:27 -0400 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens In-Reply-To: <20140310151211.26371.18691.malone@chaenomeles.canonical.com> References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> <20140310151211.26371.18691.malone@chaenomeles.canonical.com> Message-ID: It seems like we need some discussion here. I added the following comment with several questions in the defect: caching tokens for 5 minutes by default may be all well and good for performance, but not so much for security. Consider the following cases: 1) If an admin detects that someone is using a token maliciously, they'll delete it and expect that to stop the usage immediately. But it won't. 2) If someone deletes the token they were using and then walks away, they should not have to worry about someone else stepping up and continuing to use that token. Is token caching really something we should be doing at all? By default? If so, should the default really be as high as 5 minutes? How did we settle on such a large value? Should we implement a notification mechanism for token revokation which would cause listening clients to update their cache immediately? (Note: someone may find a way to block the notification, so this isn't perfect...) W. Matthew Edmonds IBM Systems & Technology Group Email: edmondsw at us.ibm.com Phone: (919) 543-7538 / Tie-Line: 441-7538 From: Jeremy Stanley To: openstack-security at lists.openstack.org, Date: 03/10/2014 11:23 AM Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens Tagging security. The OSSG may decide this is worth drafting a note about, for broader visibility within the community. ** Tags added: security ** Information type changed from Public Security to Public ** 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/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From edmondsw at us.ibm.com Wed Mar 12 12:11:20 2014 From: edmondsw at us.ibm.com (Matthew Edmonds) Date: Wed, 12 Mar 2014 12:11:20 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312121120.18976.53218.malone@wampee.canonical.com> caching tokens for 5 minutes by default may be all well and good for performance, but not so much for security. Consider the following cases: 1) If an admin detects that someone is using a token maliciously, they'll delete it and expect that to stop the usage immediately. But it won't. 2) If someone deletes the token they were using and then walks away, they should not have to worry about someone else stepping up and continuing to use that token. Is token caching really something we should be doing at all? By default? If so, should the default really be as high as 5 minutes? How did we settle on such a large value? Should we implement a notification mechanism for token revokation which would cause listening clients to update their cache immediately? (Note: someone may find a way to block the notification, so this isn't perfect...) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From ahmed.shohel at ericsson.com Wed Mar 12 13:33:35 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Wed, 12 Mar 2014 15:33:35 +0200 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens In-Reply-To: <20140312121120.18976.53218.malone@wampee.canonical.com> References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> <20140312121120.18976.53218.malone@wampee.canonical.com> Message-ID: <912F2E8D-6CFB-496B-900C-EFDD3711C143@ericsson.com> I agree, we have also identified the issue during Keystone Threat Modelling. A system should be by default secure. However, the performance impact is always a question in this scenario. We can also have discussion around OpenStack’s philosophy 'everything will become eventually consistent’ - does it apply for security. For the time being, i am willing to volunteer for writing a OSSN on this, if we agree that this a topic to address. …shohel On 12 Mar 2014, at 14:11, Matthew Edmonds wrote: > caching tokens for 5 minutes by default may be all well and good for performance, but not so much for security. Consider the following cases: > 1) If an admin detects that someone is using a token maliciously, they'll delete it and expect that to stop the usage immediately. But it won't. > 2) If someone deletes the token they were using and then walks away, they should not have to worry about someone else stepping up and continuing to use that token. > > Is token caching really something we should be doing at all? By default? > > If so, should the default really be as high as 5 minutes? How did we > settle on such a large value? > > Should we implement a notification mechanism for token revokation which > would cause listening clients to update their cache immediately? (Note: > someone may find a way to block the notification, so this isn't > perfect...) > > -- > You received this bug notification because you are a member of OpenStack > Security Group, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1287301 > > Title: > Keystone client token cache doesn't respect revoked tokens > > Status in OpenStack Security Advisories: > Invalid > Status in Python client library for Keystone: > In Progress > > Bug description: > If we'll enable caching for keystoneclient tokens we'll be able to use > tokens that are already revoked if they are present in cache: > > https://github.com/openstack/python- > keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From robert.clark at hp.com Wed Mar 12 14:43:48 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Wed, 12 Mar 2014 14:43:48 +0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens In-Reply-To: References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> <20140310151211.26371.18691.malone@chaenomeles.canonical.com> Message-ID: Very good points raised here. I think this is going to come down to a decision to be made by the deployer - do I use token caching and for how long? Secure deployments will not use caching, deployments with moderate requirements might want to use a shorter cache life and isolated or low risk clouds may even use longer life caches. Personally I think there's good grounds here for not only an OSSN but also an entry in the OpenStack Security Guide, discussing the tradeoff and possible compensating controls/procedures. -Rob -----Original Message----- From: William M Edmonds [mailto:edmondsw at us.ibm.com] Sent: 12 March 2014 12:15 To: Bug 1287301 Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens It seems like we need some discussion here. I added the following comment with several questions in the defect: caching tokens for 5 minutes by default may be all well and good for performance, but not so much for security. Consider the following cases: 1) If an admin detects that someone is using a token maliciously, they'll delete it and expect that to stop the usage immediately. But it won't. 2) If someone deletes the token they were using and then walks away, they should not have to worry about someone else stepping up and continuing to use that token. Is token caching really something we should be doing at all? By default? If so, should the default really be as high as 5 minutes? How did we settle on such a large value? Should we implement a notification mechanism for token revokation which would cause listening clients to update their cache immediately? (Note: someone may find a way to block the notification, so this isn't perfect...) W. Matthew Edmonds IBM Systems & Technology Group Email: edmondsw at us.ibm.com Phone: (919) 543-7538 / Tie-Line: 441-7538 From: Jeremy Stanley To: openstack-security at lists.openstack.org, Date: 03/10/2014 11:23 AM Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens Tagging security. The OSSG may decide this is worth drafting a note about, for broader visibility within the community. ** Tags added: security ** Information type changed from Public Security to Public ** 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/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From edmondsw at us.ibm.com Wed Mar 12 16:01:08 2014 From: edmondsw at us.ibm.com (Matthew Edmonds) Date: Wed, 12 Mar 2014 16:01:08 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312160108.30048.66501.malone@gac.canonical.com> I don't believe this only affects PKI tokens, as stated in comment 2. I hit this with UUID tokens. ** Description changed: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 + + steps to recreate: + 1) get a token + 2) use it to make a request via keystoneclient using default properties (thus it will be cached) + 3) delete the token + 4) use the token to make another request via keystoneclient + + expected result: the token should not work (HTTP 401) + actual result: the token still works -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From bknudson at us.ibm.com Wed Mar 12 16:15:04 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Wed, 12 Mar 2014 16:15:04 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312161504.19108.95991.malone@wampee.canonical.com> d-w-chadwick , robert-clark : Based on the fix in https://review.openstack.org/#/c/78241/ , it looks like if the token is validated once and put in the cache, then after that the token is valid for the entire cache period (token_cache_time, which defaults to 5 mins) even if the token is revoked. With PKI tokens, we've now got the revocation list... should auth_token be checking the revocation list for both UUID and PKI tokens? With the latest change to set the revocation_cache_time to 5 minutes, then if a deployment is using the defaults there's nothing to gain by checking the revocation list... it'll be just as out of date as the cache. If someone was willing to set a lower time for revocation_cache_time then they'd have the shorter valid period for tokens. What I'm trying to figure out is -- if we take the fix in https://review.openstack.org/#/c/78241/ will that provide more flexibility for the deployer to pick how they want revocations to work with caching? They can set revocation_cache_time to 10 seconds and tokens will be valid for 10 seconds after they're revoked... but they can already do the same thing by setting a short cache time, and then the code would be using the normal flow for UUID tokens which validates them against keystone rather than getting the revocation list. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From edmondsw at us.ibm.com Wed Mar 12 16:35:15 2014 From: edmondsw at us.ibm.com (Matthew Edmonds) Date: Wed, 12 Mar 2014 16:35:15 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312163515.19151.6914.malone@wampee.canonical.com> setting a higher value for token_cache_time and a lower value for revocation_cache_time (assuming we start using the revocation list here as proposed by https://review.openstack.org/#/c/78241/) would allow you to gain the performance improvement of not having to re-request tokens as often while satisfying the security requirement that revocation take effect in a timely manner. Yes, the revocation list is being requested more frequently, and may offset some of the performance gains from caching tokens. But the revocation list can be used to validate any token, so multiple tokens could be validated over the life of the cached revocation list, instead of each token validation requiring a call back to keystone should token_cache_time be similarly reduced. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From bdpayne at acm.org Wed Mar 12 22:15:03 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 12 Mar 2014 15:15:03 -0700 Subject: [Openstack-security] Last day to submit candidacy for OSSG Lead Election Message-ID: Just a quick reminder that today is the last day to declare candidacy for the OSSG Lead election. I'll be sending out a list of people eligible to vote later today. And the election will begin tomorrow. Thanks, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Thu Mar 13 00:14:41 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 12 Mar 2014 17:14:41 -0700 Subject: [Openstack-security] OSSG election electorate Message-ID: After reviewing the members in Launchpad, I have found that 50 of the 125 members satisfy the election criteria to be an "active member". You can review my work in the Google Doc linked below. If you believe that you should be allowed to vote, please verify and report any problems to me as soon as possible. https://docs.google.com/spreadsheet/ccc?key=0AqnzHH5YYzZvdFlXWTZxYmZKc3NUTld0cThhUUpEb0E&usp=drive_web#gid=0 Thanks everyone! -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hui.xiang at canonical.com Thu Mar 13 02:34:10 2014 From: hui.xiang at canonical.com (Hui Xiang) Date: Thu, 13 Mar 2014 10:34:10 +0800 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG In-Reply-To: References: <39586D6C-0734-45E2-B14B-C8F98D5ACD6F@ericsson.com> Message-ID: Hi all, I am carefully asking you guys if it is possible to bring the meeting ##openstack-threat-analysis forward to 15.00 UTC, or more earlier? Because I am in UTC+8 timezone, always can't attend the OSSG meeting before due to sleepy, but I don't want to miss this meeting although I am not very familiar with the current topic, I want to contribute more here. But if you are inconvenient to reschedule the time, I can understand and will keep follow the info from email and community. Thanks for your understanding : ) On Fri, Mar 7, 2014 at 11:55 PM, Abu Shohel Ahmed wrote: > Hi all, > > Yesterday's OSSG meeting, i promised to give the current status of the > activity. > The activity is ongoing. Based on feed back from last IRC call, we have > updated the > Threat Modelling framework. > > The wiki page is updated now.. > https://wiki.openstack.org/wiki/Security/Threat_Analysis > > We are almost finishing the analysis for Auth_token middleware, Token > manager and token service. > We looking for reviewer of those documents. There is a meeting > today at 17.00 GMT in ##openstack-threat-analysis (unofficial channel) > > > Thanks, > Shohel > > > > > We are going to have a OpenStack Threat m > > > *From: *Abu Shohel Ahmed > *Subject: **Re: [Openstack-security] OpenStack Threat Analysis activity - > OSSG* > *Date: *21 Feb 2014 13:15:08 GMT+2 > *To: *"openstack-security at lists.openstack.org" < > openstack-security at lists.openstack.org> > *Cc: *Sriram Subramanian , "Clark, Robert Graham" < > robert.clark at hp.com> > > Hi guys, > > Sorry for not including the whole OSSG in the initial call. So, we are > having an initial call > for Threat modelling of OpenStack (first one is Keystone) today, 21 Feb, > 17.00 UTC. Let's > have the discussion today then decide what time suits us best for later > meetings. It is in Free node > channel ##openstack-threat-analysis (unofficial channel). > > Today's topics of discussion: > 1. Threat modelling process > > https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > > First, we t need to agree on this, so we have conformity > around the whole work. Please feel > free to provide your feedback. > > 2. Some concrete example use of the modelling process > Keystone over all : > https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > Keystone Token-provider: > https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > > (Now this documents are work in progress work, things are not > always in order and complete) > > > See you in the meeting, > Shohel > > > > > On 20 Feb 2014, at 20:47, Sriram Subramanian > wrote: > > Damn - i missed the meeting again :(. I will check the logs to catch up. > Sorry > > > On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham < > robert.clark at hp.com> wrote: > >> Including the whole security group as there was significant interest >> during the OSSG weekly meeting. >> >> >> >> *From:* Sriram Subramanian [mailto:sriram at sriramhere.com] >> *Sent:* 20 February 2014 16:35 >> *To:* Abu Shohel Ahmed >> *Cc:* Clark, Robert Graham; Grant Murphy; Mats Näslund; Makan Pourzandi >> *Subject:* Re: OpenStack Threat Analysis activity - OSSG >> >> >> >> Shohel, >> >> >> >> Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are >> we meeting tomorrow? >> >> >> >> thanks, >> >> -Sriram >> >> >> >> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed < >> ahmed.shohel at ericsson.com> wrote: >> >> Hi, >> >> From our last week's, it becomes clear that we need set up a way of >> working process in place >> to take this activity forward. >> >> So here are some ideas (Please also share yours): >> >> 1. WoW: >> >> In the short time frame, >> >> - First, We should define the purpose and the concrete output of >> this work ( which i think, most of us here has some ideas, if we still have >> question - >> we can clear that up before moving forward). >> >> - Second issue is, how we can do threat analysis contribution in >> an effective manner. Here comes the collaboration issues within >> this group. For this, I have created a free node IRC channel >> ##openstack-threat-analysis ( unofficial channel, as you can see from >> name). >> Lets start biweekly (15 days) meetings from this week. Lets vote >> for what is the suitable time for meeting for all of us. >> I propose Friday at 17.00 UTC. However, i am happy to schedule >> the meeting based on most people preference. >> >> In the longer time frame, we should think about setting up a >> Threat analysis working group (could be under OSSG) to perform threat >> modelling of all OpenStack components >> - Define a clear out from this working group e.g., Threat >> documentation, Design guidance. >> - Engage developers and security minded people to the work. >> >> >> 2. Now on the technical side, >> >> First and foremost, we should agree on a threat modelling >> process that can be applied for all OpenStack services and internal >> components. We have some ideas that >> can be applied for this work... Here is the link of our >> proposal : >> >> >> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >> >> and here are two concrete implementation of applying >> the threat modelling process... >> >> Keystone over all : >> https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >> Keystone Token-provider: >> https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >> >> (These are work in progress documents, so by no means >> provide a complete picture) >> >> Lets discuss what do you guys think about the >> Modelling steps and its applicability with OpenStack (e.g., Keystone) >> >> >> >> Thanks, >> Shohel >> >> >> >> >> >> -- >> >> Thanks, >> >> -Sriram >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> > > > -- > Thanks, > -Sriram > _______________________________________________ > 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 gongysh at unitedstack.com Tue Mar 11 08:33:10 2014 From: gongysh at unitedstack.com (yong sheng gong) Date: Tue, 11 Mar 2014 08:33:10 -0000 Subject: [Openstack-security] [Bug 1289195] Re: Duplicate security group name cause fail to start instance References: <20140307080022.26596.61856.malonedeb@chaenomeles.canonical.com> Message-ID: <20140311083310.26637.83810.malone@chaenomeles.canonical.com> It reads well: please use ID in this case! -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1289195 Title: Duplicate security group name cause fail to start instance Status in OpenStack Neutron (virtual network service): Opinion Bug description: When create a security group, the duplicate name is allowed. In create a instance, duplicate sg name will cause exception and the instance will be started fail. So the duplicate name of sg should be not allowed. In nova.network.neutronv2.API:allocate_for_instance for security_group in security_groups:     name_match = None     uuid_match = None     for user_security_group in user_security_groups:         if user_security_group['name'] == security_group: # if have duplicate sg name, the name_match will not be None for the second matching.             if name_match:                 raise exception.NoUniqueMatch(                     _("Multiple security groups found matching"                        " '%s'. Use an ID to be more specific.") %                     security_group)             name_match = user_security_group['id']         if user_security_group['id'] == security_group:             uuid_match = user_security_group['id'] To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1289195/+subscriptions From gongysh at unitedstack.com Tue Mar 11 08:33:52 2014 From: gongysh at unitedstack.com (yong sheng gong) Date: Tue, 11 Mar 2014 08:33:52 -0000 Subject: [Openstack-security] [Bug 1289195] Re: Duplicate security group name cause fail to start instance References: <20140307080022.26596.61856.malonedeb@chaenomeles.canonical.com> Message-ID: <20140311083352.26433.36794.malone@chaenomeles.canonical.com> If the ID will cover this case, I think the bug is invalid! ** Changed in: neutron Status: In Progress => Opinion -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1289195 Title: Duplicate security group name cause fail to start instance Status in OpenStack Neutron (virtual network service): Opinion Bug description: When create a security group, the duplicate name is allowed. In create a instance, duplicate sg name will cause exception and the instance will be started fail. So the duplicate name of sg should be not allowed. In nova.network.neutronv2.API:allocate_for_instance for security_group in security_groups:     name_match = None     uuid_match = None     for user_security_group in user_security_groups:         if user_security_group['name'] == security_group: # if have duplicate sg name, the name_match will not be None for the second matching.             if name_match:                 raise exception.NoUniqueMatch(                     _("Multiple security groups found matching"                        " '%s'. Use an ID to be more specific.") %                     security_group)             name_match = user_security_group['id']         if user_security_group['id'] == security_group:             uuid_match = user_security_group['id'] To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1289195/+subscriptions From 1287301 at bugs.launchpad.net Wed Mar 12 13:49:06 2014 From: 1287301 at bugs.launchpad.net (David Chadwick) Date: Wed, 12 Mar 2014 13:49:06 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312134906.14913.48982.malone@chaenomeles.canonical.com> Implementing security controls is always a balance between cost, usability, effectiveness etc. So there are no right answers. It all depends upon the risk aversion (or willingness) of the organisation. Therefore having configuration values for token cache time and revocation cache time seems to be the best way to deal with this (including allowing a zero cache time). The risk averse organisation can set low or zero values and take the cost and performance consequences of this, whereas the risk willing organisation can set much higher values and have lower costs, higher performance and a greater risk of revoked tokens being wrongly used. I dont really see what Matthew's problem is providing this is clearly documented (as Dolph agrees it should be) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From akornienko at mirantis.com Wed Mar 12 14:21:14 2014 From: akornienko at mirantis.com (Alexei Kornienko) Date: Wed, 12 Mar 2014 14:21:14 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312142114.29674.76792.malone@soybean.canonical.com> This particular issue has a simple solution and I proposed a fix to keystone client - https://review.openstack.org/#/c/78241/ With such fix we won't have to choose between cache efficiency and security for the cost of some additional computation -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From 1287301 at bugs.launchpad.net Wed Mar 12 14:47:58 2014 From: 1287301 at bugs.launchpad.net (Robert Clark) Date: Wed, 12 Mar 2014 14:47:58 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312144758.30127.30980.malone@soybean.canonical.com> Very good points raised here. I think this is going to come down to a decision to be made by the deployer - do I use token caching and for how long? Secure deployments will likely not use caching, deployments with moderate requirements might want to use a shorter cache life and isolated or low risk clouds may even use longer life caches. Personally I think there's good grounds here for not only an OSSN but also an entry in the OpenStack Security Guide, discussing the tradeoff and possible compensating controls/procedures. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From 1287301 at bugs.launchpad.net Wed Mar 12 18:41:27 2014 From: 1287301 at bugs.launchpad.net (David Chadwick) Date: Wed, 12 Mar 2014 18:41:27 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312184127.29910.60219.malone@gac.canonical.com> can I make a few assertions that might help in these deliberations. 1. If you dont cache tokens you dont need revocation lists. You get a fresh token each time. 2. There is no point in having a revocation cache time longer than a token cache time, because once a token cache time expires a new token has to be obtained. So if the token has been revoked you wont learn about it. 3. There is no point in having a revocation cache time equal to a token cache time because they will both expire at the same time, so even if the token has been revoked you still wont learn about it (until you get the next revocation list). 4. So the only sensible solution is to have a token cache time significantly longer than the revocation cache time (I would say at least twice as long, since the probability that a token has been revoked in the second half of its life is 50%. Using longer revocation times you decrease the probability that you will learn about the revocation. 5. If you have short token cache times, you probably dont need revocation lists. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From akornienko at mirantis.com Wed Mar 12 18:56:11 2014 From: akornienko at mirantis.com (Alexei Kornienko) Date: Wed, 12 Mar 2014 18:56:11 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312185611.30188.71233.malone@gac.canonical.com> d-w-chadwick I'm sorry but you are wrong in some of your assertions: 1. If you dont cache tokens you dont need revocation lists. You get a fresh token each time. Cache is needed to speed up validation. For UUID tokens validation requires HTTP request to keystone and for PKI tokens it requires a subprocess call to openssl. If you disable cache you are still able to use the same token until it's *expired*. Rest of the assertions has to be updated to separate token exparation and validation cache. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From 1287301 at bugs.launchpad.net Wed Mar 12 19:28:38 2014 From: 1287301 at bugs.launchpad.net (Dolph Mathews) Date: Wed, 12 Mar 2014 19:28:38 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140312192838.19151.90902.malone@wampee.canonical.com> Revocation lists are currently only required to prematurely invalidate PKI tokens, regardless of caching. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From gamoholic010 at gmail.com Thu Mar 13 05:12:13 2014 From: gamoholic010 at gmail.com (Amey Ghadigaonkar) Date: Thu, 13 Mar 2014 01:12:13 -0400 Subject: [Openstack-security] Blueprint for project related to runtime integrity checks Message-ID: Hi all, I, Amey Ghadigaonkar, had contacted the community regarding a project about run time integrity checks for OpenStack in the OSSG meeting held on 02.27.14 (transcript: http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-02-27-18.00.html ). I am submitting a blueprint to describe what our project is really about. We are quite enthusiastic to hear what the community thinks of our project. Please read on. *What we want do* Goal of this project is to develop a component that will perform periodical validations of run-time integrity of OpenStack code, services, and configurations. We aim to: 1. Develop a framework in Nova that allows periodic or user-triggered integrity measurements of compute nodes in the trusted pool. 2. The framework will allow specific integrity measures to be developed as plugins. 3. Adapt OpenAttestation as the first plugin to this framework. 4. Develop a Horizon component that will allow users to configure their choice of checks and schedule when these checks should be run. The results obtained from these checks will be stored and can be retrieved by users using the Horizon component. 5. As time and scoping permits, develop more run-time integrity check plugins such as checking that trusted nodes are running known good code or performing dynamic memory checks. We have attached a sample usecase diagram with this email to illustrate some simple usecases. *Suggestions/comments from the community* regarding the project are welcome and we consider these comments as *essential for success* of this project. Some issues that we would like to discuss with the community are: 1. Are there any potential architectural or technical concerns that you are aware of that might impact these goals? 2. Any listed functionality that you deem redundant or think that something specific should be added? 3. Do you have suggestions for good candidates for run-time integrity check plugins? 4. Any pointers to relevant documentation, mailing list discussions, or people that should be included in further discussions? 5. Any other general comments or suggestions? *Where we are right now* We are in the inception phase of the project and are negotiating its scope. We plan to submit an elaborate blueprint for the deliverable and its architecture before the Juno Release Design Summit in May. Development will start soon after the Summit. *Who we are* This project is a part of Practicum for Software Engineering course (17-677) at Carnegie Mellon University. There are four team members. We are students at Master of Science in Information Technology - Software Engineering (MSIT-SE) program in Carnegie Mellon University: 1. Alexandr Naumchev 2. Amey Ghadigaonkar 3. Fusheng Yuan 4. Vasilii Artemev Mentor: Dr. Bradley Schmerl, Senior Systems Scientist, School of Computer Science, Carnegie Mellon University. Client: Laura Glendenning. Software Engineer at Applied Physics Laboratory in Johns Hopkins University. *Future Work:* One of the extensions of this project would be to develop hooks to the framework from Ceilometer to enhance functionality provided by our component. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: useCase.png Type: image/png Size: 175449 bytes Desc: not available URL: From 1287301 at bugs.launchpad.net Thu Mar 13 12:29:21 2014 From: 1287301 at bugs.launchpad.net (Abu Shohel Ahmed) Date: Thu, 13 Mar 2014 12:29:21 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> <20140312163515.19151.6914.malone@wampee.canonical.com> Message-ID: <2240452D-4098-430F-8D7C-0D00BFAC8E8B@ericsson.com> Some pros and cons analysis on this topic. What are the related threats and their impacts. …shohel On 12 Mar 2014, at 18:35, Matthew Edmonds wrote: > setting a higher value for token_cache_time and a lower value for > revocation_cache_time (assuming we start using the revocation list here > as proposed by https://review.openstack.org/#/c/78241/) would allow you > to gain the performance improvement of not having to re-request tokens > as often while satisfying the security requirement that revocation take > effect in a timely manner. Yes, the revocation list is being requested > more frequently, and may offset some of the performance gains from > caching tokens. But the revocation list can be used to validate any > token, so multiple tokens could be validated over the life of the cached > revocation list, instead of each token validation requiring a call back > to keystone should token_cache_time be similarly reduced. > > -- > You received this bug notification because you are a member of OpenStack > Security Group, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1287301 > > Title: > Keystone client token cache doesn't respect revoked tokens > > Status in OpenStack Security Advisories: > Invalid > Status in Python client library for Keystone: > In Progress > > Bug description: > If we'll enable caching for keystoneclient tokens we'll be able to use > tokens that are already revoked if they are present in cache: > > https://github.com/openstack/python- > keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 > > steps to recreate: > 1) get a token > 2) use it to make a request via keystoneclient using default properties (thus it will be cached) > 3) delete the token > 4) use the token to make another request via keystoneclient > > expected result: the token should not work (HTTP 401) > actual result: the token still works > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security ** Attachment added: "Token_Access_scenario_CACHE Sheet1.pdf" https://bugs.launchpad.net/bugs/1287301/+attachment/4022028/+files/Token_Access_scenario_CACHE%20Sheet1.pdf -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From ahmed.shohel at ericsson.com Thu Mar 13 16:00:14 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Thu, 13 Mar 2014 18:00:14 +0200 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens In-Reply-To: <2240452D-4098-430F-8D7C-0D00BFAC8E8B@ericsson.com> References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> <20140312163515.19151.6914.malone@wampee.canonical.com> <2240452D-4098-430F-8D7C-0D00BFAC8E8B@ericsson.com> Message-ID: <00928F4E-5261-481C-9ACD-65169B227799@ericsson.com> The earlier link somehow did not showed in the email. Some analysis i have done on this topic: Threats Vs Performanace https://drive.google.com/file/d/0B1aEVfmQtqnoM0luMFpMMXh4RkE/edit?usp=sharing …shohel On 13 Mar 2014, at 14:29, Abu Shohel Ahmed <1287301 at bugs.launchpad.net> wrote: > Some pros and cons analysis on this topic. What are the related threats and > their impacts. > > > > > …shohel > > > On 12 Mar 2014, at 18:35, Matthew Edmonds wrote: > >> setting a higher value for token_cache_time and a lower value for >> revocation_cache_time (assuming we start using the revocation list here >> as proposed by https://review.openstack.org/#/c/78241/) would allow you >> to gain the performance improvement of not having to re-request tokens >> as often while satisfying the security requirement that revocation take >> effect in a timely manner. Yes, the revocation list is being requested >> more frequently, and may offset some of the performance gains from >> caching tokens. But the revocation list can be used to validate any >> token, so multiple tokens could be validated over the life of the cached >> revocation list, instead of each token validation requiring a call back >> to keystone should token_cache_time be similarly reduced. >> >> -- >> You received this bug notification because you are a member of OpenStack >> Security Group, which is subscribed to OpenStack. >> https://bugs.launchpad.net/bugs/1287301 >> >> Title: >> Keystone client token cache doesn't respect revoked tokens >> >> Status in OpenStack Security Advisories: >> Invalid >> Status in Python client library for Keystone: >> In Progress >> >> Bug description: >> If we'll enable caching for keystoneclient tokens we'll be able to use >> tokens that are already revoked if they are present in cache: >> >> https://github.com/openstack/python- >> keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 >> >> steps to recreate: >> 1) get a token >> 2) use it to make a request via keystoneclient using default properties (thus it will be cached) >> 3) delete the token >> 4) use the token to make another request via keystoneclient >> >> expected result: the token should not work (HTTP 401) >> actual result: the token still works >> >> To manage notifications about this bug go to: >> https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > ** Attachment added: "Token_Access_scenario_CACHE Sheet1.pdf" > https://bugs.launchpad.net/bugs/1287301/+attachment/4022028/+files/Token_Access_scenario_CACHE%20Sheet1.pdf > > -- > You received this bug notification because you are a member of OpenStack > Security Group, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1287301 > > Title: > Keystone client token cache doesn't respect revoked tokens > > Status in OpenStack Security Advisories: > Invalid > Status in Python client library for Keystone: > In Progress > > Bug description: > If we'll enable caching for keystoneclient tokens we'll be able to use > tokens that are already revoked if they are present in cache: > > https://github.com/openstack/python- > keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 > > steps to recreate: > 1) get a token > 2) use it to make a request via keystoneclient using default properties (thus it will be cached) > 3) delete the token > 4) use the token to make another request via keystoneclient > > expected result: the token should not work (HTTP 401) > actual result: the token still works > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From 1287301 at bugs.launchpad.net Thu Mar 13 16:00:14 2014 From: 1287301 at bugs.launchpad.net (Abu Shohel Ahmed) Date: Thu, 13 Mar 2014 16:00:14 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> <20140312163515.19151.6914.malone@wampee.canonical.com> <2240452D-4098-430F-8D7C-0D00BFAC8E8B@ericsson.com> Message-ID: <00928F4E-5261-481C-9ACD-65169B227799@ericsson.com> The earlier link somehow did not showed in the email. Some analysis i have done on this topic: Threats Vs Performanace https://drive.google.com/file/d/0B1aEVfmQtqnoM0luMFpMMXh4RkE/edit?usp=sharing …shohel On 13 Mar 2014, at 14:29, Abu Shohel Ahmed <1287301 at bugs.launchpad.net> wrote: > Some pros and cons analysis on this topic. What are the related threats and > their impacts. > > > > > …shohel > > > On 12 Mar 2014, at 18:35, Matthew Edmonds wrote: > >> setting a higher value for token_cache_time and a lower value for >> revocation_cache_time (assuming we start using the revocation list here >> as proposed by https://review.openstack.org/#/c/78241/) would allow you >> to gain the performance improvement of not having to re-request tokens >> as often while satisfying the security requirement that revocation take >> effect in a timely manner. Yes, the revocation list is being requested >> more frequently, and may offset some of the performance gains from >> caching tokens. But the revocation list can be used to validate any >> token, so multiple tokens could be validated over the life of the cached >> revocation list, instead of each token validation requiring a call back >> to keystone should token_cache_time be similarly reduced. >> >> -- >> You received this bug notification because you are a member of OpenStack >> Security Group, which is subscribed to OpenStack. >> https://bugs.launchpad.net/bugs/1287301 >> >> Title: >> Keystone client token cache doesn't respect revoked tokens >> >> Status in OpenStack Security Advisories: >> Invalid >> Status in Python client library for Keystone: >> In Progress >> >> Bug description: >> If we'll enable caching for keystoneclient tokens we'll be able to use >> tokens that are already revoked if they are present in cache: >> >> https://github.com/openstack/python- >> keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 >> >> steps to recreate: >> 1) get a token >> 2) use it to make a request via keystoneclient using default properties (thus it will be cached) >> 3) delete the token >> 4) use the token to make another request via keystoneclient >> >> expected result: the token should not work (HTTP 401) >> actual result: the token still works >> >> To manage notifications about this bug go to: >> https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > ** Attachment added: "Token_Access_scenario_CACHE Sheet1.pdf" > https://bugs.launchpad.net/bugs/1287301/+attachment/4022028/+files/Token_Access_scenario_CACHE%20Sheet1.pdf > > -- > You received this bug notification because you are a member of OpenStack > Security Group, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1287301 > > Title: > Keystone client token cache doesn't respect revoked tokens > > Status in OpenStack Security Advisories: > Invalid > Status in Python client library for Keystone: > In Progress > > Bug description: > If we'll enable caching for keystoneclient tokens we'll be able to use > tokens that are already revoked if they are present in cache: > > https://github.com/openstack/python- > keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 > > steps to recreate: > 1) get a token > 2) use it to make a request via keystoneclient using default properties (thus it will be cached) > 3) delete the token > 4) use the token to make another request via keystoneclient > > expected result: the token should not work (HTTP 401) > actual result: the token still works > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-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/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From ahmed.shohel at ericsson.com Thu Mar 13 16:18:48 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Thu, 13 Mar 2014 18:18:48 +0200 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG In-Reply-To: References: <39586D6C-0734-45E2-B14B-C8F98D5ACD6F@ericsson.com> Message-ID: Hi Hui Xiang, You are welcome to join the meeting and take part in the review / Threat modelling work we are currently working on. Or if you have some suggestion, please share with us. We will discuss the time schedule issue in the next meeting. I thinks it would be bit difficult cause we have some participants from US timezones. We are continuously updating the Wiki page ( although there is sometimes a lag) and related information, so that everyone is informed. Related information in the > https://wiki.openstack.org/wiki/Security/Threat_Analysis Thanks, Shohel On 13 Mar 2014, at 04:34, Hui Xiang wrote: > Hi all, > > I am carefully asking you guys if it is possible to bring the meeting ##openstack-threat-analysis forward to 15.00 UTC, or more earlier? Because I am in UTC+8 timezone, always can't attend the OSSG meeting before due to sleepy, but I don't want to miss this meeting although I am not very familiar with the current topic, I want to contribute more here. > > But if you are inconvenient to reschedule the time, I can understand and will keep follow the info from email and community. > > Thanks for your understanding : ) > > > On Fri, Mar 7, 2014 at 11:55 PM, Abu Shohel Ahmed wrote: > Hi all, > > Yesterday’s OSSG meeting, i promised to give the current status of the activity. > The activity is ongoing. Based on feed back from last IRC call, we have updated the > Threat Modelling framework. > > The wiki page is updated now.. > https://wiki.openstack.org/wiki/Security/Threat_Analysis > > We are almost finishing the analysis for Auth_token middleware, Token manager and token service. > We looking for reviewer of those documents. There is a meeting > today at 17.00 GMT in ##openstack-threat-analysis (unofficial channel) > > > Thanks, > Shohel > > > > > We are going to have a OpenStack Threat m > > >> From: Abu Shohel Ahmed >> Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - OSSG >> Date: 21 Feb 2014 13:15:08 GMT+2 >> To: "openstack-security at lists.openstack.org" >> Cc: Sriram Subramanian , "Clark, Robert Graham" >> >> Hi guys, >> >> Sorry for not including the whole OSSG in the initial call. So, we are having an initial call >> for Threat modelling of OpenStack (first one is Keystone) today, 21 Feb, 17.00 UTC. Let’s >> have the discussion today then decide what time suits us best for later meetings. It is in Free node >> channel ##openstack-threat-analysis (unofficial channel). >> >> Today’s topics of discussion: >> 1. Threat modelling process >> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >> >> First, we t need to agree on this, so we have conformity around the whole work. Please feel >> free to provide your feedback. >> >> 2. Some concrete example use of the modelling process >> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >> >> (Now this documents are work in progress work, things are not always in order and complete) >> >> >> See you in the meeting, >> Shohel >> >> >> >> >> On 20 Feb 2014, at 20:47, Sriram Subramanian wrote: >> >>> Damn - i missed the meeting again :(. I will check the logs to catch up. Sorry >>> >>> >>> On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham wrote: >>> Including the whole security group as there was significant interest during the OSSG weekly meeting. >>> >>> >>> >>> From: Sriram Subramanian [mailto:sriram at sriramhere.com] >>> Sent: 20 February 2014 16:35 >>> To: Abu Shohel Ahmed >>> Cc: Clark, Robert Graham; Grant Murphy; Mats Näslund; Makan Pourzandi >>> Subject: Re: OpenStack Threat Analysis activity - OSSG >>> >>> >>> >>> Shohel, >>> >>> >>> >>> Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are we meeting tomorrow? >>> >>> >>> >>> thanks, >>> >>> -Sriram >>> >>> >>> >>> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed wrote: >>> >>> Hi, >>> >>> From our last week’s, it becomes clear that we need set up a way of working process in place >>> to take this activity forward. >>> >>> So here are some ideas (Please also share yours): >>> >>> 1. WoW: >>> >>> In the short time frame, >>> >>> - First, We should define the purpose and the concrete output of this work ( which i think, most of us here has some ideas, if we still have question - >>> we can clear that up before moving forward). >>> >>> - Second issue is, how we can do threat analysis contribution in an effective manner. Here comes the collaboration issues within >>> this group. For this, I have created a free node IRC channel ##openstack-threat-analysis ( unofficial channel, as you can see from name). >>> Lets start biweekly (15 days) meetings from this week. Lets vote for what is the suitable time for meeting for all of us. >>> I propose Friday at 17.00 UTC. However, i am happy to schedule the meeting based on most people preference. >>> >>> In the longer time frame, we should think about setting up a Threat analysis working group (could be under OSSG) to perform threat modelling of all OpenStack components >>> - Define a clear out from this working group e.g., Threat documentation, Design guidance. >>> - Engage developers and security minded people to the work. >>> >>> >>> 2. Now on the technical side, >>> >>> First and foremost, we should agree on a threat modelling process that can be applied for all OpenStack services and internal components. We have some ideas that >>> can be applied for this work… Here is the link of our proposal : >>> >>> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >>> >>> and here are two concrete implementation of applying the threat modelling process… >>> >>> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >>> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >>> >>> (These are work in progress documents, so by no means provide a complete picture) >>> >>> Lets discuss what do you guys think about the Modelling steps and its applicability with OpenStack (e.g., Keystone) >>> >>> >>> >>> Thanks, >>> Shohel >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Thanks, >>> >>> -Sriram >>> >>> >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >>> >>> >>> >>> -- >>> Thanks, >>> -Sriram >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From bdpayne at acm.org Thu Mar 13 17:01:27 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 13 Mar 2014 10:01:27 -0700 Subject: [Openstack-security] OSSG Lead Election: Voting has begun Message-ID: Voting has now begun for the OSSG Lead Election. If you are in the electorate, you should have received an email with instructions on how to vote (subject of the email is "Poll: OSSG Lead Election"). If you think you should have received an email, but didn't, please check with me. Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From meghal at yahoo-inc.com Thu Mar 13 18:16:46 2014 From: meghal at yahoo-inc.com (Meghal Gosalia) Date: Thu, 13 Mar 2014 18:16:46 -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: <20140313181646.15012.69192.malone@chaenomeles.canonical.com> I have spice enabled in my havana environment and am using spice-html5proxy to connect to the spice server. If I use an URL with same token multiple times, previous connection drops and only last session stays active. Old tab shows "Error: Unexpected close while ready" in console.log under spice console on the browser. And latest tab has active connection to the spice server. Here is what I see in qemu logs, when I use same token again to connect to the server - red_client_destroy: destroy client with #channels 4 red_dispatcher_disconnect_display_peer: red_channel_client_disconnect: 0x7f42302a81a0 (channel 0x7f423021d0b0 type 2 id 0) red_channel_client_disconnect: 0x7f42302a81a0 (channel 0x7f423021d0b0 type 2 id 0) red_channel_client_disconnect: 0x7f42714a1dc0 (channel 0x7f4270efc460 type 3 id 0) red_channel_client_disconnect: 0x7f42714a1dc0 (channel 0x7f4270efc460 type 3 id 0) red_dispatcher_disconnect_cursor_peer: red_channel_client_disconnect: 0x7f42302660c0 (channel 0x7f423021d670 type 4 id 0) red_channel_client_disconnect: 0x7f42302660c0 (channel 0x7f423021d670 type 4 id 0) red_channel_client_disconnect: 0x7f42714740f0 (channel 0x7f4270ef2770 type 1 id 0) main_channel_client_on_disconnect: rcc=0x7f42714740f0 red_channel_client_disconnect: 0x7f42714740f0 (channel 0x7f4270ef2770 type 1 id 0) main_channel_link: add main channel client main_channel_handle_parsed: net test: latency 19.735000 ms, bitrate 25127601 bps (23.963548 Mbps) red_dispatcher_set_cursor_peer: inputs_connect: inputs channel client create So, does this mean that I am using certain qemu configuration (I do not see any) which does not allow to share connections? If qemu is not allowing multiple clients connecting to spice server, will I still see the DoS attack? -- 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: Fix Released 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 1227575 at bugs.launchpad.net Thu Mar 13 19:31:15 2014 From: 1227575 at bugs.launchpad.net (Tushar Patil) Date: Thu, 13 Mar 2014 19:31:15 -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: <20140313193115.29661.16678.malone@gac.canonical.com> Meghal: It looks like in the libvirt.xml of the instance, you are using sharePolicy=allow-exclusive in graphics element. Not sure though if you can specify this parameter for spice console graphics. Can you please share libvirt.xml of the instance if possible? -- 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: Fix Released 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 cristian.fiorentino at intel.com Thu Mar 13 19:55:19 2014 From: cristian.fiorentino at intel.com (Fiorentino, Cristian) Date: Thu, 13 Mar 2014 19:55:19 +0000 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG Message-ID: Hi Shohel and Everyone, I am new to OSSG, and I would be happy to support the OpenStack Threat Analysis activity. Most meeting time proposals in email thread below work for me. Thanks and Regards. Cristian. Date: Thu, 13 Mar 2014 18:18:48 +0200 From: Abu Shohel Ahmed To: Hui Xiang Cc: "Openstack-security at lists.openstack.org , " Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - OSSG Message-ID: Content-Type: text/plain; charset="windows-1252" Hi Hui Xiang, You are welcome to join the meeting and take part in the review / Threat modelling work we are currently working on. Or if you have some suggestion, please share with us. We will discuss the time schedule issue in the next meeting. I thinks it would be bit difficult cause we have some participants from US timezones. We are continuously updating the Wiki page ( although there is sometimes a lag) and related information, so that everyone is informed. Related information in the > https://wiki.openstack.org/wiki/Security/Threat_Analysis Thanks, Shohel On 13 Mar 2014, at 04:34, Hui Xiang wrote: > Hi all, > > I am carefully asking you guys if it is possible to bring the meeting ##openstack-threat-analysis forward to 15.00 UTC, or more earlier? Because I am in UTC+8 timezone, always can't attend the OSSG meeting before due to sleepy, but I don't want to miss this meeting although I am not very familiar with the current topic, I want to contribute more here. > > But if you are inconvenient to reschedule the time, I can understand and will keep follow the info from email and community. > > Thanks for your understanding : ) > > > On Fri, Mar 7, 2014 at 11:55 PM, Abu Shohel Ahmed wrote: > Hi all, > > Yesterday?s OSSG meeting, i promised to give the current status of the activity. > The activity is ongoing. Based on feed back from last IRC call, we have updated the > Threat Modelling framework. > > The wiki page is updated now.. > https://wiki.openstack.org/wiki/Security/Threat_Analysis > > We are almost finishing the analysis for Auth_token middleware, Token manager and token service. > We looking for reviewer of those documents. There is a meeting > today at 17.00 GMT in ##openstack-threat-analysis (unofficial channel) > > > Thanks, > Shohel > > > > > We are going to have a OpenStack Threat m > > >> From: Abu Shohel Ahmed >> Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - OSSG >> Date: 21 Feb 2014 13:15:08 GMT+2 >> To: "openstack-security at lists.openstack.org" >> Cc: Sriram Subramanian , "Clark, Robert Graham" >> >> Hi guys, >> >> Sorry for not including the whole OSSG in the initial call. So, we are having an initial call >> for Threat modelling of OpenStack (first one is Keystone) today, 21 Feb, 17.00 UTC. Let?s >> have the discussion today then decide what time suits us best for later meetings. It is in Free node >> channel ##openstack-threat-analysis (unofficial channel). >> >> Today?s topics of discussion: >> 1. Threat modelling process >> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >> >> First, we t need to agree on this, so we have conformity around the whole work. Please feel >> free to provide your feedback. >> >> 2. Some concrete example use of the modelling process >> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >> >> (Now this documents are work in progress work, things are not always in order and complete) >> >> >> See you in the meeting, >> Shohel >> >> >> >> >> On 20 Feb 2014, at 20:47, Sriram Subramanian wrote: >> >>> Damn - i missed the meeting again :(. I will check the logs to catch up. Sorry >>> >>> >>> On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham wrote: >>> Including the whole security group as there was significant interest during the OSSG weekly meeting. >>> >>> >>> >>> From: Sriram Subramanian [mailto:sriram at sriramhere.com] >>> Sent: 20 February 2014 16:35 >>> To: Abu Shohel Ahmed >>> Cc: Clark, Robert Graham; Grant Murphy; Mats N?slund; Makan Pourzandi >>> Subject: Re: OpenStack Threat Analysis activity - OSSG >>> >>> >>> >>> Shohel, >>> >>> >>> >>> Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are we meeting tomorrow? >>> >>> >>> >>> thanks, >>> >>> -Sriram >>> >>> >>> >>> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed wrote: >>> >>> Hi, >>> >>> From our last week?s, it becomes clear that we need set up a way of working process in place >>> to take this activity forward. >>> >>> So here are some ideas (Please also share yours): >>> >>> 1. WoW: >>> >>> In the short time frame, >>> >>> - First, We should define the purpose and the concrete output of this work ( which i think, most of us here has some ideas, if we still have question - >>> we can clear that up before moving forward). >>> >>> - Second issue is, how we can do threat analysis contribution in an effective manner. Here comes the collaboration issues within >>> this group. For this, I have created a free node IRC channel ##openstack-threat-analysis ( unofficial channel, as you can see from name). >>> Lets start biweekly (15 days) meetings from this week. Lets vote for what is the suitable time for meeting for all of us. >>> I propose Friday at 17.00 UTC. However, i am happy to schedule the meeting based on most people preference. >>> >>> In the longer time frame, we should think about setting up a Threat analysis working group (could be under OSSG) to perform threat modelling of all OpenStack components >>> - Define a clear out from this working group e.g., Threat documentation, Design guidance. >>> - Engage developers and security minded people to the work. >>> >>> >>> 2. Now on the technical side, >>> >>> First and foremost, we should agree on a threat modelling process that can be applied for all OpenStack services and internal components. We have some ideas that >>> can be applied for this work? Here is the link of our proposal : >>> >>> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >>> >>> and here are two concrete implementation of applying the threat modelling process? >>> >>> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >>> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >>> >>> (These are work in progress documents, so by no means provide a complete picture) >>> >>> Lets discuss what do you guys think about the Modelling steps and its applicability with OpenStack (e.g., Keystone) >>> >>> >>> >>> Thanks, >>> Shohel >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Thanks, >>> >>> -Sriram >>> >>> >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >>> >>> >>> >>> -- >>> Thanks, >>> -Sriram >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > From meghal at yahoo-inc.com Thu Mar 13 20:03:05 2014 From: meghal at yahoo-inc.com (Meghal Gosalia) Date: Thu, 13 Mar 2014 20:03:05 -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: <20140313200305.29688.1000.malone@gac.canonical.com> Here is the libvirt.xml of the instance: 5e5fa2d6-bc4e-4b6e-9d4c-73aaddf51380 instance-00000095 524288 1 OpenStack Foundation OpenStack Nova 2013.2.2 cbcaa281-fe93-11d5-b186-80c16e7d4ce0 5e5fa2d6-bc4e-4b6e-9d4c-73aaddf51380 hvm /var/nova/instances/5e5fa2d6-bc4e-4b6e-9d4c-73aaddf51380/kernel /var/nova/instances/5e5fa2d6-bc4e-4b6e-9d4c-73aaddf51380/ramdisk root=/dev/vda console=tty0 console=ttyS0 -- 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: Fix Released 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 1227575 at bugs.launchpad.net Thu Mar 13 20:23:11 2014 From: 1227575 at bugs.launchpad.net (Tushar Patil) Date: Thu, 13 Mar 2014 20:23:11 -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: <20140313202311.30145.95508.malone@gac.canonical.com> In my dev environment, by default 'console' element is present in the libvirt.xml. So I can verify it right now. But as per libvirt document here http://libvirt.org/formatdomain.html#elementsConsole it says "If the console is presented as a serial port, the target element has the same attributes as for a serial port. There is usually only 1 console." This could be one reason why libvirt is disconnecting previously opened client connections. -- 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: Fix Released 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 gerrit2 at review.openstack.org Thu Mar 13 20:46:37 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 13 Mar 2014 20:46:37 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Ie524125dc5f6f1076bfd47db3a414b178e4dac80 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80398 Log: commit 63ed801b7329aa07525b5e397f8ba27a3e1ba50f Author: Brant Knudson Date: Thu Mar 13 15:38:34 2014 -0500 Allow hash tokens with sha256 Tokens were always hashed with md5. This change allows tokens to be hashed with sha256. This is for security hardening. If the new 'hash_algorithm' configuration option is set to 'sha256' then the auth_token middleware will hash tokens using 'sha256'. Using this will require that the Keystone server is also configured to use sha256 for tokens. The 'hash_algorithm' option defaults to 'md5' for backwards compatibility. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80 From gerrit2 at review.openstack.org Thu Mar 13 20:53:28 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 13 Mar 2014 20:53:28 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Iafe3c975d59818c8f362647f7ea5149a03deee47 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80401 Log: commit acb3dc48a08e15edbfc4a7d64f4cd5e401368668 Author: Brant Knudson Date: Thu Mar 13 15:50:52 2014 -0500 Configurable token hash algorithm Tokens were always hashed with md5. This change allows tokens to be hashed with sha256. This is for security hardening. If the new 'hash_algorithm' configuration option in the [token] section is set to 'sha256' then PKI tokens will be hashed using the sha256 algorithm rather than the md5 algorithm. The 'hash_algorithm' option defaults to 'md5' for backwards compatibility. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47 From 1174499 at bugs.launchpad.net Thu Mar 13 20:46:34 2014 From: 1174499 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 13 Mar 2014 20:46:34 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20140313204634.30188.39240.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/80398 ** Changed in: python-keystoneclient Assignee: Dirk Mueller (dmllr) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From 1174499 at bugs.launchpad.net Thu Mar 13 20:53:25 2014 From: 1174499 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 13 Mar 2014 20:53:25 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20140313205325.29703.39952.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/80401 ** Changed in: keystone Assignee: Dirk Mueller (dmllr) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From gerrit2 at review.openstack.org Thu Mar 13 21:13:53 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 13 Mar 2014 21:13:53 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Iafe3c975d59818c8f362647f7ea5149a03deee47 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80401 Log: commit e458a285b181cd82fe7eb77b6bbab8f4475b08a0 Author: Brant Knudson Date: Thu Mar 13 15:50:52 2014 -0500 Configurable token hash algorithm Tokens were always hashed with md5. This change allows tokens to be hashed with sha256. This is for security hardening. If the new 'hash_algorithm' configuration option in the [token] section is set to 'sha256' then PKI tokens will be hashed using the sha256 algorithm rather than the md5 algorithm. The 'hash_algorithm' option defaults to 'md5' for backwards compatibility. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47 From 1227575 at bugs.launchpad.net Thu Mar 13 21:08:14 2014 From: 1227575 at bugs.launchpad.net (Tushar Patil) Date: Thu, 13 Mar 2014 21:08:14 -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: <20140313210814.18943.89684.malone@wampee.canonical.com> In my previous comment, I meant to say the console element is not present in the libvirt.xml of the instance. So I couldn't verify your 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: Fix Released 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 1227575 at bugs.launchpad.net Thu Mar 13 21:17:33 2014 From: 1227575 at bugs.launchpad.net (Tushar Patil) Date: Thu, 13 Mar 2014 21:17:33 -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: <20140313211733.15312.2262.malone@chaenomeles.canonical.com> I think it will be a good idea to ask Libvirt community if there's a possibility to add a new parameter to put restriction on the number of client connections one can open based on the type of the graphics (vnc/spice). since graphic type 'vnc' already has implemented sharedPolicy, it must be aware of the client connections, so adding logic to check the number of opened client connection should be a easy fix I guess. What do you guys think? -- 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: Fix Released 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 meghal at yahoo-inc.com Thu Mar 13 21:22:11 2014 From: meghal at yahoo-inc.com (Meghal Gosalia) Date: Thu, 13 Mar 2014 21:22:11 -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: <20140313212211.15374.46170.malone@chaenomeles.canonical.com> Tushar: Thanks for your response. I also believe, having a control at driver side would be a better approach to handle 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: Fix Released 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 hui.xiang at canonical.com Fri Mar 14 10:56:09 2014 From: hui.xiang at canonical.com (Hui Xiang) Date: Fri, 14 Mar 2014 18:56:09 +0800 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG In-Reply-To: References: Message-ID: Hi Shohel, Thanks for you update, I can understand the timezone problem, I will keep reading the wiki and if there are any questions I will post here, it's really appreciated to help to answer with that then. Thank you : ) On Fri, Mar 14, 2014 at 3:55 AM, Fiorentino, Cristian < cristian.fiorentino at intel.com> wrote: > Hi Shohel and Everyone, > > I am new to OSSG, and I would be happy to support the OpenStack Threat > Analysis activity. > Most meeting time proposals in email thread below work for me. > > Thanks and Regards. > Cristian. > > > Date: Thu, 13 Mar 2014 18:18:48 +0200 > From: Abu Shohel Ahmed > To: Hui Xiang > Cc: "Openstack-security at lists.openstack.org , " > > Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - > OSSG > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > Hi Hui Xiang, > > You are welcome to join the meeting and take part in the review / Threat > modelling work we are currently working on. Or if you have some suggestion, > please > share with us. > > We will discuss the time schedule issue in the next meeting. I thinks it > would be bit difficult cause we have some participants from US timezones. > > We are continuously updating the Wiki page ( although there is sometimes a > lag) and related information, so that everyone is informed. > > Related information in the > > https://wiki.openstack.org/wiki/Security/Threat_Analysis > > > Thanks, > Shohel > > On 13 Mar 2014, at 04:34, Hui Xiang wrote: > > > Hi all, > > > > I am carefully asking you guys if it is possible to bring the meeting > ##openstack-threat-analysis forward to 15.00 UTC, or more earlier? Because > I am in UTC+8 timezone, always can't attend the OSSG meeting before due to > sleepy, but I don't want to miss this meeting although I am not very > familiar with the current topic, I want to contribute more here. > > > > But if you are inconvenient to reschedule the time, I can understand > and will keep follow the info from email and community. > > > > Thanks for your understanding : ) > > > > > > On Fri, Mar 7, 2014 at 11:55 PM, Abu Shohel Ahmed < > ahmed.shohel at ericsson.com> wrote: > > Hi all, > > > > Yesterday?s OSSG meeting, i promised to give the current status of the > activity. > > The activity is ongoing. Based on feed back from last IRC call, we have > updated the > > Threat Modelling framework. > > > > The wiki page is updated now.. > > https://wiki.openstack.org/wiki/Security/Threat_Analysis > > > > We are almost finishing the analysis for Auth_token middleware, Token > manager and token service. > > We looking for reviewer of those documents. There is a meeting > > today at 17.00 GMT in ##openstack-threat-analysis (unofficial channel) > > > > > > Thanks, > > Shohel > > > > > > > > > > We are going to have a OpenStack Threat m > > > > > >> From: Abu Shohel Ahmed > >> Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - > OSSG > >> Date: 21 Feb 2014 13:15:08 GMT+2 > >> To: "openstack-security at lists.openstack.org" < > openstack-security at lists.openstack.org> > >> Cc: Sriram Subramanian , "Clark, Robert Graham" > > >> > >> Hi guys, > >> > >> Sorry for not including the whole OSSG in the initial call. So, we are > having an initial call > >> for Threat modelling of OpenStack (first one is Keystone) today, 21 > Feb, 17.00 UTC. Let?s > >> have the discussion today then decide what time suits us best for later > meetings. It is in Free node > >> channel ##openstack-threat-analysis (unofficial channel). > >> > >> Today?s topics of discussion: > >> 1. Threat modelling process > >> > https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > >> > >> First, we t need to agree on this, so we have conformity > around the whole work. Please feel > >> free to provide your feedback. > >> > >> 2. Some concrete example use of the modelling process > >> Keystone over all : > https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > >> Keystone Token-provider: > https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > >> > >> (Now this documents are work in progress work, things are not > always in order and complete) > >> > >> > >> See you in the meeting, > >> Shohel > >> > >> > >> > >> > >> On 20 Feb 2014, at 20:47, Sriram Subramanian > wrote: > >> > >>> Damn - i missed the meeting again :(. I will check the logs to catch > up. Sorry > >>> > >>> > >>> On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham < > robert.clark at hp.com> wrote: > >>> Including the whole security group as there was significant interest > during the OSSG weekly meeting. > >>> > >>> > >>> > >>> From: Sriram Subramanian [mailto:sriram at sriramhere.com] > >>> Sent: 20 February 2014 16:35 > >>> To: Abu Shohel Ahmed > >>> Cc: Clark, Robert Graham; Grant Murphy; Mats N?slund; Makan Pourzandi > >>> Subject: Re: OpenStack Threat Analysis activity - OSSG > >>> > >>> > >>> > >>> Shohel, > >>> > >>> > >>> > >>> Friday 17.00 UTC works - though 18.00 UTC would work better for me. > Are we meeting tomorrow? > >>> > >>> > >>> > >>> thanks, > >>> > >>> -Sriram > >>> > >>> > >>> > >>> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed < > ahmed.shohel at ericsson.com> wrote: > >>> > >>> Hi, > >>> > >>> From our last week?s, it becomes clear that we need set up a way of > working process in place > >>> to take this activity forward. > >>> > >>> So here are some ideas (Please also share yours): > >>> > >>> 1. WoW: > >>> > >>> In the short time frame, > >>> > >>> - First, We should define the purpose and the concrete output > of this work ( which i think, most of us here has some ideas, if we still > have question - > >>> we can clear that up before moving forward). > >>> > >>> - Second issue is, how we can do threat analysis contribution > in an effective manner. Here comes the collaboration issues within > >>> this group. For this, I have created a free node IRC channel > ##openstack-threat-analysis ( unofficial channel, as you can see from > name). > >>> Lets start biweekly (15 days) meetings from this week. Lets > vote for what is the suitable time for meeting for all of us. > >>> I propose Friday at 17.00 UTC. However, i am happy to schedule > the meeting based on most people preference. > >>> > >>> In the longer time frame, we should think about setting up a > Threat analysis working group (could be under OSSG) to perform threat > modelling of all OpenStack components > >>> - Define a clear out from this working group e.g., Threat > documentation, Design guidance. > >>> - Engage developers and security minded people to the work. > >>> > >>> > >>> 2. Now on the technical side, > >>> > >>> First and foremost, we should agree on a threat > modelling process that can be applied for all OpenStack services and > internal components. We have some ideas that > >>> can be applied for this work? Here is the link of > our proposal : > >>> > >>> > https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > >>> > >>> and here are two concrete implementation of > applying the threat modelling process? > >>> > >>> Keystone over all : > https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > >>> Keystone Token-provider: > https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > >>> > >>> (These are work in progress documents, so by no > means provide a complete picture) > >>> > >>> Lets discuss what do you guys think about the > Modelling steps and its applicability with OpenStack (e.g., Keystone) > >>> > >>> > >>> > >>> Thanks, > >>> Shohel > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> Thanks, > >>> > >>> -Sriram > >>> > >>> > >>> _______________________________________________ > >>> Openstack-security mailing list > >>> Openstack-security at lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > >>> > >>> > >>> > >>> > >>> -- > >>> Thanks, > >>> -Sriram > >>> _______________________________________________ > >>> 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 robert.clark at hp.com Fri Mar 14 11:19:09 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Fri, 14 Mar 2014 11:19:09 +0000 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG In-Reply-To: References: Message-ID: I think this is a very exciting project, I’ll do my best to be at the next meeting. Can you summarise for us on the email list, if there are gaps where resource, knowledge etc are required - there are lots of lurkers on the security list just waiting for the right opportunity to jump in and help with something. -Rob On 14 March 2014 at 10:58:07, Hui Xiang (hui.xiang at canonical.com) wrote: Hi Shohel, Thanks for you update, I can understand the timezone problem, I will keep reading the wiki and if there are any questions I will post here, it's really appreciated to help to answer with that then. Thank you : ) On Fri, Mar 14, 2014 at 3:55 AM, Fiorentino, Cristian > wrote: Hi Shohel and Everyone, I am new to OSSG, and I would be happy to support the OpenStack Threat Analysis activity. Most meeting time proposals in email thread below work for me. Thanks and Regards. Cristian. Date: Thu, 13 Mar 2014 18:18:48 +0200 From: Abu Shohel Ahmed > To: Hui Xiang > Cc: "Openstack-security at lists.openstack.org , " > Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - OSSG Message-ID: > Content-Type: text/plain; charset="windows-1252" Hi Hui Xiang, You are welcome to join the meeting and take part in the review / Threat modelling work we are currently working on. Or if you have some suggestion, please share with us. We will discuss the time schedule issue in the next meeting. I thinks it would be bit difficult cause we have some participants from US timezones. We are continuously updating the Wiki page ( although there is sometimes a lag) and related information, so that everyone is informed. Related information in the > https://wiki.openstack.org/wiki/Security/Threat_Analysis Thanks, Shohel On 13 Mar 2014, at 04:34, Hui Xiang > wrote: > Hi all, > > I am carefully asking you guys if it is possible to bring the meeting ##openstack-threat-analysis forward to 15.00 UTC, or more earlier? Because I am in UTC+8 timezone, always can't attend the OSSG meeting before due to sleepy, but I don't want to miss this meeting although I am not very familiar with the current topic, I want to contribute more here. > > But if you are inconvenient to reschedule the time, I can understand and will keep follow the info from email and community. > > Thanks for your understanding : ) > > > On Fri, Mar 7, 2014 at 11:55 PM, Abu Shohel Ahmed > wrote: > Hi all, > > Yesterday?s OSSG meeting, i promised to give the current status of the activity. > The activity is ongoing. Based on feed back from last IRC call, we have updated the > Threat Modelling framework. > > The wiki page is updated now.. > https://wiki.openstack.org/wiki/Security/Threat_Analysis > > We are almost finishing the analysis for Auth_token middleware, Token manager and token service. > We looking for reviewer of those documents. There is a meeting > today at 17.00 GMT in ##openstack-threat-analysis (unofficial channel) > > > Thanks, > Shohel > > > > > We are going to have a OpenStack Threat m > > >> From: Abu Shohel Ahmed > >> Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - OSSG >> Date: 21 Feb 2014 13:15:08 GMT+2 >> To: "openstack-security at lists.openstack.org" > >> Cc: Sriram Subramanian >, "Clark, Robert Graham" > >> >> Hi guys, >> >> Sorry for not including the whole OSSG in the initial call. So, we are having an initial call >> for Threat modelling of OpenStack (first one is Keystone) today, 21 Feb, 17.00 UTC. Let?s >> have the discussion today then decide what time suits us best for later meetings. It is in Free node >> channel ##openstack-threat-analysis (unofficial channel). >> >> Today?s topics of discussion: >> 1. Threat modelling process >> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >> >> First, we t need to agree on this, so we have conformity around the whole work. Please feel >> free to provide your feedback. >> >> 2. Some concrete example use of the modelling process >> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >> >> (Now this documents are work in progress work, things are not always in order and complete) >> >> >> See you in the meeting, >> Shohel >> >> >> >> >> On 20 Feb 2014, at 20:47, Sriram Subramanian > wrote: >> >>> Damn - i missed the meeting again :(. I will check the logs to catch up. Sorry >>> >>> >>> On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham > wrote: >>> Including the whole security group as there was significant interest during the OSSG weekly meeting. >>> >>> >>> >>> From: Sriram Subramanian [mailto:sriram at sriramhere.com] >>> Sent: 20 February 2014 16:35 >>> To: Abu Shohel Ahmed >>> Cc: Clark, Robert Graham; Grant Murphy; Mats N?slund; Makan Pourzandi >>> Subject: Re: OpenStack Threat Analysis activity - OSSG >>> >>> >>> >>> Shohel, >>> >>> >>> >>> Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are we meeting tomorrow? >>> >>> >>> >>> thanks, >>> >>> -Sriram >>> >>> >>> >>> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed > wrote: >>> >>> Hi, >>> >>> From our last week?s, it becomes clear that we need set up a way of working process in place >>> to take this activity forward. >>> >>> So here are some ideas (Please also share yours): >>> >>> 1. WoW: >>> >>> In the short time frame, >>> >>> - First, We should define the purpose and the concrete output of this work ( which i think, most of us here has some ideas, if we still have question - >>> we can clear that up before moving forward). >>> >>> - Second issue is, how we can do threat analysis contribution in an effective manner. Here comes the collaboration issues within >>> this group. For this, I have created a free node IRC channel ##openstack-threat-analysis ( unofficial channel, as you can see from name). >>> Lets start biweekly (15 days) meetings from this week. Lets vote for what is the suitable time for meeting for all of us. >>> I propose Friday at 17.00 UTC. However, i am happy to schedule the meeting based on most people preference. >>> >>> In the longer time frame, we should think about setting up a Threat analysis working group (could be under OSSG) to perform threat modelling of all OpenStack components >>> - Define a clear out from this working group e.g., Threat documentation, Design guidance. >>> - Engage developers and security minded people to the work. >>> >>> >>> 2. Now on the technical side, >>> >>> First and foremost, we should agree on a threat modelling process that can be applied for all OpenStack services and internal components. We have some ideas that >>> can be applied for this work? Here is the link of our proposal : >>> >>> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >>> >>> and here are two concrete implementation of applying the threat modelling process? >>> >>> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >>> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >>> >>> (These are work in progress documents, so by no means provide a complete picture) >>> >>> Lets discuss what do you guys think about the Modelling steps and its applicability with OpenStack (e.g., Keystone) >>> >>> >>> >>> Thanks, >>> Shohel >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Thanks, >>> >>> -Sriram >>> >>> >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >>> >>> >>> >>> -- >>> Thanks, >>> -Sriram >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From jsbryant at us.ibm.com Fri Mar 14 21:29:40 2014 From: jsbryant at us.ibm.com (Jay Bryant) Date: Fri, 14 Mar 2014 21:29:40 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140314212944.30160.14504.launchpad@soybean.canonical.com> ** Changed in: cinder Importance: Undecided => High ** Changed in: cinder Milestone: None => icehouse-rc1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From gerrit2 at review.openstack.org Fri Mar 14 23:58:58 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 14 Mar 2014 23:58:58 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Ie524125dc5f6f1076bfd47db3a414b178e4dac80 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80398 Log: commit f76a1982b5e8f347e9d00a101d7935b2fe485700 Author: Brant Knudson Date: Thu Mar 13 15:38:34 2014 -0500 Allow hash tokens with sha256 Tokens were always hashed with md5. This change allows tokens to be hashed with sha256. This is for security hardening. If the new 'hash_algorithm' configuration option is set to 'sha256' then the auth_token middleware will hash tokens using 'sha256'. Using this will require that the Keystone server is also configured to use sha256 for tokens. The 'hash_algorithm' option defaults to 'md5' for backwards compatibility. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80 From gerrit2 at review.openstack.org Sat Mar 15 00:07:42 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sat, 15 Mar 2014 00:07:42 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Ie524125dc5f6f1076bfd47db3a414b178e4dac80 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80398 Log: commit 3b51450f88b8e4ed6b90ad6bd4cebc415d7fb7c1 Author: Brant Knudson Date: Thu Mar 13 15:38:34 2014 -0500 Allow hash tokens with sha256 Tokens were always hashed with md5. This change allows tokens to be hashed with sha256. This is for security hardening. If the new 'hash_algorithm' configuration option is set to 'sha256' then the auth_token middleware will hash tokens using 'sha256'. Using this will require that the Keystone server is also configured to use sha256 for tokens. The 'hash_algorithm' option defaults to 'md5' for backwards compatibility. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80 From skywalker.nick at gmail.com Sat Mar 15 04:31:25 2014 From: skywalker.nick at gmail.com (Li Ma) Date: Sat, 15 Mar 2014 04:31:25 -0000 Subject: [Openstack-security] [Bug 1175904] Re: passlib trunc_password MAX_PASSWORD_LENGTH password truncation References: <20130503065124.14566.73303.malonedeb@gac.canonical.com> Message-ID: <20140315043126.18708.48479.malone@wampee.canonical.com> According to the discussion in review, I'll submit a new patch for Juno. Just leave a message here. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175904 Title: passlib trunc_password MAX_PASSWORD_LENGTH password truncation Status in OpenStack Identity (Keystone): In Progress Bug description: Grant Murphy originally reported: * Insecure / bad practice The trunc_password function attempts to correct and truncate passwords that are over the MAX_PASSWORD_LENGTH value (default 4096). As the MAX_PASSWORD_LENGTH field is globally mutable it could be modified to restrict all passwords to length = 1. This scenario might be unlikely but generally speaking we should not try to 'fix' invalid input and continue on processing as if nothing happened. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175904/+subscriptions From 1227575 at bugs.launchpad.net Sun Mar 16 16:18:54 2014 From: 1227575 at bugs.launchpad.net (Russell Bryant) Date: Sun, 16 Mar 2014 16:18:54 -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: <20140316161857.30288.19460.launchpad@gac.canonical.com> ** Changed in: nova Milestone: icehouse-rc1 => None ** Tags removed: ntt security ** Tags added: icehouse-rc-potential ** Tags added: console -- 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: Fix Released 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 gerrit2 at review.openstack.org Mon Mar 17 05:56:01 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Mar 2014 05:56:01 +0000 Subject: [Openstack-security] [stackforge/kite] SecurityImpact review request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80902 Log: commit ded20a5b2086a0aeab1727dc2dfb91f4a3fadf16 Author: Jamie Lennox Date: Tue Dec 3 12:33:28 2013 +1000 Add cryptographic key storage Adds a layer called Storage on top of the DB. The DB is a simple store retrieve interface and things going through Storage are correctly encrypted and stored to the database. Add some routes to allow setting a key through the storage interface. SecurityImpact Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From gerrit2 at review.openstack.org Mon Mar 17 05:56:06 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Mar 2014 05:56:06 +0000 Subject: [Openstack-security] [stackforge/kite] SecurityImpact review request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80903 Log: commit ec2eb8fa63872cd382bc38ec462bcc0488a6b9a3 Author: Jamie Lennox Date: Tue Dec 3 12:33:28 2013 +1000 Add ticket handling to KDS Adds creation of tickets to transmit communication keys between peers. SecurityImpact Change-Id: I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 From 1287301 at bugs.launchpad.net Mon Mar 17 15:25:22 2014 From: 1287301 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 17 Mar 2014 15:25:22 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140317152524.30406.73429.launchpad@soybean.canonical.com> ** Changed in: python-keystoneclient Assignee: Alexei Kornienko (alexei-kornienko) => Adam Young (ayoung) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From gerrit2 at review.openstack.org Mon Mar 17 15:47:11 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Mar 2014 15:47:11 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie6a6620685995add56f38dc34c9a0a733558146a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76476 Log: commit e5018d1b357e496da25d64fbf8324aa5a748fa35 Author: Daniel Gollub Date: Wed Feb 26 06:56:13 2014 +0100 Replace httplib.HTTPSConnection in ec2_token httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. Implementation got adapted to make use of the requests module instead. SSL Verification is from now on enabled by default. Can be disabled via an additional introduced configuration option: `keystone_ec2_insecure=True` SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: Ie6a6620685995add56f38dc34c9a0a733558146a From 1188189 at bugs.launchpad.net Mon Mar 17 15:47:06 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 17 Mar 2014 15:47:06 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140317154709.30461.64644.launchpad@gac.canonical.com> ** Changed in: keystone Assignee: Daniel Gollub (d-gollub) => Dolph Mathews (dolph) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From gerrit2 at review.openstack.org Mon Mar 17 15:55:55 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 17 Mar 2014 15:55:55 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Ie6a6620685995add56f38dc34c9a0a733558146a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/76476 Log: commit 5bd4c2984d329625a2a8442b316fa235dbb88a3d Author: Daniel Gollub Date: Wed Feb 26 06:56:13 2014 +0100 Replace httplib.HTTPSConnection in ec2_token httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. Implementation got adapted to make use of the requests module instead. SSL Verification is from now on enabled by default. Can be disabled via an additional introduced configuration option: `keystone_ec2_insecure=True` SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: Ie6a6620685995add56f38dc34c9a0a733558146a From 1188189 at bugs.launchpad.net Mon Mar 17 15:55:49 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 17 Mar 2014 15:55:49 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140317155553.30546.74623.launchpad@soybean.canonical.com> ** Changed in: keystone Assignee: Dolph Mathews (dolph) => Brant Knudson (blk-u) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From bknudson at us.ibm.com Mon Mar 17 16:12:37 2014 From: bknudson at us.ibm.com (Brant Knudson) Date: Mon, 17 Mar 2014 16:12:37 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140317161241.14500.95533.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Assignee: Brant Knudson (blk-u) => Daniel Gollub (d-gollub) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From sriram at sriramhere.com Mon Mar 17 19:09:24 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 17 Mar 2014 12:09:24 -0700 Subject: [Openstack-security] OSSG election electorate In-Reply-To: References: Message-ID: Dear Electorate, Gentle reminder to vote for the lead candidacy - voting ends on the 19th. Rob and Malini are great candidates, no doubt about it. However, if you prefer someone independent who is not attached to a vendor/ big company, you can vote for me. I am not employed by any of the big players, an entrepreneur / independent consultant. It doesn't matter whom you are voting for, please do vote. Just 2 more days to go, please vote! thanks, -Sriram On Wed, Mar 12, 2014 at 5:14 PM, Bryan D. Payne wrote: > After reviewing the members in Launchpad, I have found that 50 of the 125 > members satisfy the election criteria to be an "active member". You can > review my work in the Google Doc linked below. If you believe that you > should be allowed to vote, please verify and report any problems to me as > soon as possible. > > > https://docs.google.com/spreadsheet/ccc?key=0AqnzHH5YYzZvdFlXWTZxYmZKc3NUTld0cThhUUpEb0E&usp=drive_web#gid=0 > > Thanks everyone! > > -bryan > > _______________________________________________ > 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 1188189 at bugs.launchpad.net Mon Mar 17 22:01:22 2014 From: 1188189 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 17 Mar 2014 22:01:22 -0000 Subject: [Openstack-security] [Bug 1188189] Fix merged to keystone (master) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140317220123.14754.72691.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/76476 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=5bd4c2984d329625a2a8442b316fa235dbb88a3d Submitter: Jenkins Branch: master commit 5bd4c2984d329625a2a8442b316fa235dbb88a3d Author: Daniel Gollub Date: Wed Feb 26 06:56:13 2014 +0100 Replace httplib.HTTPSConnection in ec2_token httplib.HTTPSConnection is known to not verify SSL certificates in Python 2.x. Implementation got adapted to make use of the requests module instead. SSL Verification is from now on enabled by default. Can be disabled via an additional introduced configuration option: `keystone_ec2_insecure=True` SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: Ie6a6620685995add56f38dc34c9a0a733558146a -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From 1188189 at bugs.launchpad.net Tue Mar 18 00:27:19 2014 From: 1188189 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 18 Mar 2014 00:27:19 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140318002722.29979.33235.launchpad@gac.canonical.com> ** Changed in: keystone Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Committed Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From kseifried at redhat.com Tue Mar 18 02:08:34 2014 From: kseifried at redhat.com (Kurt Seifried) Date: Mon, 17 Mar 2014 20:08:34 -0600 Subject: [Openstack-security] OSSG election electorate In-Reply-To: References: Message-ID: <5327AAA2.7070808@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there a web page with a list of all the candidates and their statements? I nuked some emails and think I may be missing one or two candidates emails. This would probably be helpful to others as well (to see everything on a single page). Thanks. - -- 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 iQIcBAEBAgAGBQJTJ6qhAAoJEBYNRVNeJnmTS5kP/3btvSS4c8j44b3drd85CaF7 FxdhiuUgSVPWt6snkSRcW3K0jJNgJ1uLsuUxyQTllozYTGxThfGePUYlRY8GWyay xf6mVbx0BXhixbcYf7c3nZ1o2L7iCB+2atEZBCT0FHDHPk91jxSh1/POexJQdAHA wV+qNG2V+sTZPIuDLpiUxZRAFeMsuBRhDjpNMgjna/75ymjmUFYUksSlkEt6ivOW xXoeTHMI+Tz+q1E1Sri5SLpnvf85LXXPGYJt+sAnQTERdKWyJJFoo689bymtXbTF zLzu+QdjKWXZB0SeL/URuog6J7DDe/ZXWHRUNqeGcgspc4r5dD8HcthYj5dpBmU+ Xlm0qMi7VqVcLFCmntL0LzmFY/LDS9kLV6LXMb4oou0eM53QbsIR54A1AFKZUZ1b c+2xMCKLVA3vFuAECEMMxglov1OCOTs8MwtjJEUzrr/EBB9bwo8kzVLOE879pSoF NtXt50SRO7G1NqvOgszRgFAKVGSKli10aoLO98PEBIFC5+FuhzX4pVVCOlPGH8L7 U05e+Sg+ugXgj9YSYyLWkpxdgefq9NFBwbFwZTGuwPXrA5jN1XlTr4WCJeuQPilp 9e4tpdQcOhoAg1NJjnsJ1H3iJxvwsOwcgF9mXlONAF1D7DNGwqGcTbgvpFhI88yL qS754ITMLYd1mDrn9fVy =tQVY -----END PGP SIGNATURE----- From nathanael.i.burton.work at gmail.com Tue Mar 18 02:54:35 2014 From: nathanael.i.burton.work at gmail.com (Nathanael Burton) Date: Mon, 17 Mar 2014 22:54:35 -0400 Subject: [Openstack-security] OSSG election electorate In-Reply-To: <5327AAA2.7070808@redhat.com> References: <5327AAA2.7070808@redhat.com> Message-ID: https://wiki.openstack.org/wiki/Security/OSSG_Lead_Election_Spring_2014just lists the candidates. Statements from each are on the mailing list. On Mar 17, 2014 10:11 PM, "Kurt Seifried" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Is there a web page with a list of all the candidates and their > statements? I nuked some emails and think I may be missing one or two > candidates emails. This would probably be helpful to others as well > (to see everything on a single page). Thanks. > > > - -- > 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 > > iQIcBAEBAgAGBQJTJ6qhAAoJEBYNRVNeJnmTS5kP/3btvSS4c8j44b3drd85CaF7 > FxdhiuUgSVPWt6snkSRcW3K0jJNgJ1uLsuUxyQTllozYTGxThfGePUYlRY8GWyay > xf6mVbx0BXhixbcYf7c3nZ1o2L7iCB+2atEZBCT0FHDHPk91jxSh1/POexJQdAHA > wV+qNG2V+sTZPIuDLpiUxZRAFeMsuBRhDjpNMgjna/75ymjmUFYUksSlkEt6ivOW > xXoeTHMI+Tz+q1E1Sri5SLpnvf85LXXPGYJt+sAnQTERdKWyJJFoo689bymtXbTF > zLzu+QdjKWXZB0SeL/URuog6J7DDe/ZXWHRUNqeGcgspc4r5dD8HcthYj5dpBmU+ > Xlm0qMi7VqVcLFCmntL0LzmFY/LDS9kLV6LXMb4oou0eM53QbsIR54A1AFKZUZ1b > c+2xMCKLVA3vFuAECEMMxglov1OCOTs8MwtjJEUzrr/EBB9bwo8kzVLOE879pSoF > NtXt50SRO7G1NqvOgszRgFAKVGSKli10aoLO98PEBIFC5+FuhzX4pVVCOlPGH8L7 > U05e+Sg+ugXgj9YSYyLWkpxdgefq9NFBwbFwZTGuwPXrA5jN1XlTr4WCJeuQPilp > 9e4tpdQcOhoAg1NJjnsJ1H3iJxvwsOwcgF9mXlONAF1D7DNGwqGcTbgvpFhI88yL > qS754ITMLYd1mDrn9fVy > =tQVY > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 malini.k.bhandaru at intel.com Tue Mar 18 05:37:31 2014 From: malini.k.bhandaru at intel.com (Bhandaru, Malini K) Date: Tue, 18 Mar 2014 05:37:31 +0000 Subject: [Openstack-security] OSSG election electorate -- all pitches together Message-ID: ============================= Sriram's pitch ============================= Dear Electorate, Gentle reminder to vote for the lead candidacy - voting ends on the 19th. Rob and Malini are great candidates, no doubt about it. However, if you prefer someone independent who is not attached to a vendor/ big company, you can vote for me. I am not employed by any of the big players, an entrepreneur/ independent consultant. It doesn't matter whom you are voting for, please do vote. Just 2 more days to go, please vote! thanks, -Sriram ============================= Malini's pitch ============================= Hello OSSG Members! I would be honored to lead our efforts as a group to making OpenStack more secure and making OSSG a first class OpenStack citizen. Bryan and Robert have done an excellent job in raising the visibility of security as a cross cutting issue across OpenStack projects, publishing a book, and chasing the nuances of each security issue in OSSAs and OSSNs. Their shoes will be hard to fill. I am proud to be an author of the OpenStack Security Guide, of championing a key manager in OpenStack and being involved with Barbican, assisted in writing up some OSSNs, delivered a few keystone an nova patches, and aided in the design and review of John Hopkins Applied Physics Labs solution for encrypting volumes. We have a great team here in OSSG, strong regulars and I hope to grow this core to include cores across the projects to be our security eyes, ears and feature design sanitizers. I have the support of Intel and my team within in this endeavor, and expect to devote even more time to OpenStack. I am an Architect and Engineering Manager with the Open Source Technology Center at Intel. Over my five plus year tenure at Intel, I have worked on Xeon server power and performance aspects, faster implementations of hashing and encryption algorithms, and for a little less than 2 years on OpenStack. Prior to joining Intel I worked on remote monitoring and management, e-commerce, and speech recognition products. I have a Ph.D. in Computer Science, Artificial Intelligence, from the University of Massachusetts, Amherst. Last but not least, I enjoy gardening, cooking, and long walks. Thanks! Malini ============================= Rob's pitch ============================= Friends, After speaking at length with Bryan and others (both in the OSSG and at my company, HP) I am delighted to join Malini and Sriram in announcing myself as a candidate for leading the OSSG. Of course this means I can no longer be an election official and as such I humbly request that Bryan validate me as 'active' and include me in the official list of candidates. What an amazing journey we've been on over the last two years. We've got a lot done in this time, establishing the OSSN process and publishing over 20 pieces of guidance, working with the VMT to assess and triage vulnerabilities, producing the worlds first (and best!) book on OpenStack security and grown our membership numbers to over 100. In the future I'd like to see us take on more ambitious projects, to further ramp up OSSN releases and continue to develop the security guide - but beyond our current functions I want us to embrace security reviews, to really engage with development teams on security and work together to find more security issues and improve the security architecture that underpins OpenStack. I believe that through conducting group reviews and defining good processes for doing so, we can raise the bar in OpenStack Security together, improving OpenStack as a whole. I want to see the OSSG get involved in more projects, try new things and extend our capabilities, my role at HP has changed recently and I'm now 100% dedicated to OpenStack facing projects - this means more time from me, and more help from my security team in lifting some of the load. If elected I'll look to delegate responsibility wherever possible so that everyone can contribute as much as they want to and those who like me, have a specific mandate to improve OpenStack security are given the tools and support they need to make it happen. Thanks, -Rob ============================== -----Original Message----- From: Kurt Seifried [mailto:kseifried at redhat.com] Sent: Monday, March 17, 2014 7:09 PM To: Sriram Subramanian; Bryan D. Payne Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OSSG election electorate -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there a web page with a list of all the candidates and their statements? I nuked some emails and think I may be missing one or two candidates emails. This would probably be helpful to others as well (to see everything on a single page). Thanks. - -- 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 iQIcBAEBAgAGBQJTJ6qhAAoJEBYNRVNeJnmTS5kP/3btvSS4c8j44b3drd85CaF7 FxdhiuUgSVPWt6snkSRcW3K0jJNgJ1uLsuUxyQTllozYTGxThfGePUYlRY8GWyay xf6mVbx0BXhixbcYf7c3nZ1o2L7iCB+2atEZBCT0FHDHPk91jxSh1/POexJQdAHA wV+qNG2V+sTZPIuDLpiUxZRAFeMsuBRhDjpNMgjna/75ymjmUFYUksSlkEt6ivOW xXoeTHMI+Tz+q1E1Sri5SLpnvf85LXXPGYJt+sAnQTERdKWyJJFoo689bymtXbTF zLzu+QdjKWXZB0SeL/URuog6J7DDe/ZXWHRUNqeGcgspc4r5dD8HcthYj5dpBmU+ Xlm0qMi7VqVcLFCmntL0LzmFY/LDS9kLV6LXMb4oou0eM53QbsIR54A1AFKZUZ1b c+2xMCKLVA3vFuAECEMMxglov1OCOTs8MwtjJEUzrr/EBB9bwo8kzVLOE879pSoF NtXt50SRO7G1NqvOgszRgFAKVGSKli10aoLO98PEBIFC5+FuhzX4pVVCOlPGH8L7 U05e+Sg+ugXgj9YSYyLWkpxdgefq9NFBwbFwZTGuwPXrA5jN1XlTr4WCJeuQPilp 9e4tpdQcOhoAg1NJjnsJ1H3iJxvwsOwcgF9mXlONAF1D7DNGwqGcTbgvpFhI88yL qS754ITMLYd1mDrn9fVy =tQVY -----END PGP SIGNATURE----- _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From kseifried at redhat.com Tue Mar 18 08:13:23 2014 From: kseifried at redhat.com (Kurt Seifried) Date: Tue, 18 Mar 2014 02:13:23 -0600 Subject: [Openstack-security] OSSG election electorate -- all pitches together In-Reply-To: References: Message-ID: <53280023.4090005@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Are we allowed to ask candidates questions? My main one would be: is the time and effort for you to work with OpenStack being officially sanctioned by your employer, and if so to what degree. E.g. are you doing this on your own time, are you being 100% paid/committed to working with OpenStack, or something in between? The reason I ask is due to sustainability. I get that people are passionate about this (otherwise they wouldn't have stepped up), and qualified (otherwise they wouldn't even be here), but the time and effort is a serious aspect. And example of this is the roughly 2 year period where I was something like 1/3 of all OSS-Security mailing traffic due to handling CVE's (over 1000 a year). The only reason I could pull this off was because it was part of my job at Red Hat (I was given both time and resources to do it), there is no way I would have been able to sustain that commitment on my own time). So basically will the candidates have enough time/resources to do this properly, not just today or tomorrow or next week, but 6 months from now? Thanks. - -- 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 iQIcBAEBAgAGBQJTKAAjAAoJEBYNRVNeJnmTMbQQALf71kv2dqjBhu0zz5lICIXL vNzuR5mAzbHTEpfahEw1WI6TzH/b4FGcSGUXEwxPUNgS7jkFm4UiaSfoeXzm6Bmz 59n2x+SblbX2QsbiWsbnZ92wdWzJDkBqeLsAgYo5E2K6aAJW5laD9yNb/DxTlWFp RHZfwJhsObr4jOXvqCguKLi+fC1cKokfu0lZmJtmbeLesFWxfdkoc97FGZsFSXXN CxEWXjXiOAIcb7+0WxhTSN4QEqKGmmeYTEukVJAiQZ2v9rz4qjVQBTJ5YtM9gfZ2 lQbtuzBWGTGgk+L958Uxf/EDwd7jenXur4iVwS6M0xgX/xWt1J4WtwCdQtPfk8Jl 0AD+RgJ7tzdZPPVNfgZVj6sS0Nqn+Zl8H6qKW022P8Sx7rQn8M+jlDEU7ACXL72m IWQYYIQ20va7k1Yp8p39raE9ZO7d1xzYSxkYxrOJf16kw2v7pC3IxD/CkI0suwZ3 keGc+KZMLGeCYpjTJXWd/TWr+swIAMu6ILfIAxtIYUiJc9uLZ+/D/VOy+jhVLXLX U7SsPUNqevE+5Y6jcVTmowjhCLPzoG0PTJnBRATaJrLteDKCNQe/21Nj9D0rWjve ymhMSQvgL0YB5LxCoxnZWak5xLZY99nTFrMMAjXGEmzMhd+t7xqLuuK1fTAv38Bk /M9NL0eCZJL4N9HZO02F =XsW0 -----END PGP SIGNATURE----- From ahmed.shohel at ericsson.com Tue Mar 18 10:53:07 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Tue, 18 Mar 2014 12:53:07 +0200 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG In-Reply-To: References: Message-ID: Hi Rob and all, You rightly pointed out this is an exciting project which can help to secure all OpenStack projects. Now, for the status part, what we have done so far - We have defined modelling steps for Threat Analysis of OpenStack projects. - Templates for the report and analysis part - Performed threat modelling for some parts of Keystone. - Continued working with Keystone and more reports to come in the coming months for latest update please check https://wiki.openstack.org/wiki/Security/Threat_Analysis or https://github.com/shohel02/OpenStack_Threat_Modelling What are the gaps: - Engagement from Target project team (e.g. Keystone developers or other project). The engagement could be * Reviewing and clarifying the analysis report ( the generated reports are also good source of documentation for each project, we can help each other, currently we have some amount of engagement from the keystone developers) * Acknowledging the threats in relevant projects and defining way forward. - Engagement of more OSSG members in active way. The engagement could be * Aligning threat modelling process ( what to include what not to) * Sharing your earlier threat modelling experiences * Working collaboratively for the analysis part - Engament from all: * Everyone is welcome to contribute * Developers can help us to write DFD from code base * Existing core project members can help to review docs * Experienced members in OSSG can help to place quality control measure - Covering all core projects: * We need more interested people to form a team and starts working on threat modelling of other core projects ( e.g, Nova, Neutron and so on. The list is big) Lastly, - How to create a process which is easy to follow and produces best result From technical side, i was thinking of Gerrit with some control for each document to go through. And in the pipeline we attaches people from both OSSG and Target project team. Any other ideas. Thanks, Shohel On 14 Mar 2014, at 13:19, Clark, Robert Graham wrote: > I think this is a very exciting project, I’ll do my best to be at the next meeting. > > Can you summarise for us on the email list, if there are gaps where resource, knowledge etc are required - there are lots of lurkers on the security list just waiting for the right opportunity to jump in and help with something. > > -Rob > > On 14 March 2014 at 10:58:07, Hui Xiang (hui.xiang at canonical.com) wrote: > > Hi Shohel, > > Thanks for you update, I can understand the timezone problem, I will keep reading the wiki and if there are any questions I will post here, it's really appreciated to help to answer with that then. > > Thank you : ) > > > On Fri, Mar 14, 2014 at 3:55 AM, Fiorentino, Cristian > wrote: > Hi Shohel and Everyone, > > I am new to OSSG, and I would be happy to support the OpenStack Threat Analysis activity. > Most meeting time proposals in email thread below work for me. > > Thanks and Regards. > Cristian. > > > Date: Thu, 13 Mar 2014 18:18:48 +0200 > From: Abu Shohel Ahmed > > To: Hui Xiang > > Cc: "Openstack-security at lists.openstack.org , " > > > Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - > OSSG > Message-ID: > > Content-Type: text/plain; charset="windows-1252" > > Hi Hui Xiang, > > You are welcome to join the meeting and take part in the review / Threat modelling work we are currently working on. Or if you have some suggestion, please > share with us. > > We will discuss the time schedule issue in the next meeting. I thinks it would be bit difficult cause we have some participants from US timezones. > > We are continuously updating the Wiki page ( although there is sometimes a lag) and related information, so that everyone is informed. > > Related information in the >> https://wiki.openstack.org/wiki/Security/Threat_Analysis > > > Thanks, > Shohel > > On 13 Mar 2014, at 04:34, Hui Xiang > wrote: > >> Hi all, >> >> I am carefully asking you guys if it is possible to bring the meeting ##openstack-threat-analysis forward to 15.00 UTC, or more earlier? Because I am in UTC+8 timezone, always can't attend the OSSG meeting before due to sleepy, but I don't want to miss this meeting although I am not very familiar with the current topic, I want to contribute more here. >> >> But if you are inconvenient to reschedule the time, I can understand and will keep follow the info from email and community. >> >> Thanks for your understanding : ) >> >> >> On Fri, Mar 7, 2014 at 11:55 PM, Abu Shohel Ahmed > wrote: >> Hi all, >> >> Yesterday?s OSSG meeting, i promised to give the current status of the activity. >> The activity is ongoing. Based on feed back from last IRC call, we have updated the >> Threat Modelling framework. >> >> The wiki page is updated now.. >> https://wiki.openstack.org/wiki/Security/Threat_Analysis >> >> We are almost finishing the analysis for Auth_token middleware, Token manager and token service. >> We looking for reviewer of those documents. There is a meeting >> today at 17.00 GMT in ##openstack-threat-analysis (unofficial channel) >> >> >> Thanks, >> Shohel >> >> >> >> >> We are going to have a OpenStack Threat m >> >> >>> From: Abu Shohel Ahmed > >>> Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - OSSG >>> Date: 21 Feb 2014 13:15:08 GMT+2 >>> To: "openstack-security at lists.openstack.org" > >>> Cc: Sriram Subramanian >, "Clark, Robert Graham" > >>> >>> Hi guys, >>> >>> Sorry for not including the whole OSSG in the initial call. So, we are having an initial call >>> for Threat modelling of OpenStack (first one is Keystone) today, 21 Feb, 17.00 UTC. Let?s >>> have the discussion today then decide what time suits us best for later meetings. It is in Free node >>> channel ##openstack-threat-analysis (unofficial channel). >>> >>> Today?s topics of discussion: >>> 1. Threat modelling process >>> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >>> >>> First, we t need to agree on this, so we have conformity around the whole work. Please feel >>> free to provide your feedback. >>> >>> 2. Some concrete example use of the modelling process >>> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >>> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >>> >>> (Now this documents are work in progress work, things are not always in order and complete) >>> >>> >>> See you in the meeting, >>> Shohel >>> >>> >>> >>> >>> On 20 Feb 2014, at 20:47, Sriram Subramanian > wrote: >>> >>>> Damn - i missed the meeting again :(. I will check the logs to catch up. Sorry >>>> >>>> >>>> On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham > wrote: >>>> Including the whole security group as there was significant interest during the OSSG weekly meeting. >>>> >>>> >>>> >>>> From: Sriram Subramanian [mailto:sriram at sriramhere.com] >>>> Sent: 20 February 2014 16:35 >>>> To: Abu Shohel Ahmed >>>> Cc: Clark, Robert Graham; Grant Murphy; Mats N?slund; Makan Pourzandi >>>> Subject: Re: OpenStack Threat Analysis activity - OSSG >>>> >>>> >>>> >>>> Shohel, >>>> >>>> >>>> >>>> Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are we meeting tomorrow? >>>> >>>> >>>> >>>> thanks, >>>> >>>> -Sriram >>>> >>>> >>>> >>>> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed > wrote: >>>> >>>> Hi, >>>> >>>> From our last week?s, it becomes clear that we need set up a way of working process in place >>>> to take this activity forward. >>>> >>>> So here are some ideas (Please also share yours): >>>> >>>> 1. WoW: >>>> >>>> In the short time frame, >>>> >>>> - First, We should define the purpose and the concrete output of this work ( which i think, most of us here has some ideas, if we still have question - >>>> we can clear that up before moving forward). >>>> >>>> - Second issue is, how we can do threat analysis contribution in an effective manner. Here comes the collaboration issues within >>>> this group. For this, I have created a free node IRC channel ##openstack-threat-analysis ( unofficial channel, as you can see from name). >>>> Lets start biweekly (15 days) meetings from this week. Lets vote for what is the suitable time for meeting for all of us. >>>> I propose Friday at 17.00 UTC. However, i am happy to schedule the meeting based on most people preference. >>>> >>>> In the longer time frame, we should think about setting up a Threat analysis working group (could be under OSSG) to perform threat modelling of all OpenStack components >>>> - Define a clear out from this working group e.g., Threat documentation, Design guidance. >>>> - Engage developers and security minded people to the work. >>>> >>>> >>>> 2. Now on the technical side, >>>> >>>> First and foremost, we should agree on a threat modelling process that can be applied for all OpenStack services and internal components. We have some ideas that >>>> can be applied for this work? Here is the link of our proposal : >>>> >>>> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >>>> >>>> and here are two concrete implementation of applying the threat modelling process? >>>> >>>> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >>>> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >>>> >>>> (These are work in progress documents, so by no means provide a complete picture) >>>> >>>> Lets discuss what do you guys think about the Modelling steps and its applicability with OpenStack (e.g., Keystone) >>>> >>>> >>>> >>>> Thanks, >>>> Shohel >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> >>>> -Sriram >>>> >>>> >>>> _______________________________________________ >>>> Openstack-security mailing list >>>> Openstack-security at lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>>> >>>> >>>> >>>> >>>> -- >>>> Thanks, >>>> -Sriram >>>> _______________________________________________ >>>> Openstack-security mailing list >>>> Openstack-security at lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >> >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From thierry.carrez+lp at gmail.com Tue Mar 18 12:20:22 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Tue, 18 Mar 2014 12:20:22 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140318122022.30224.40895.malone@soybean.canonical.com> https://review.openstack.org/#/c/72093/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From doug.hellmann at dreamhost.com Tue Mar 18 12:21:19 2014 From: doug.hellmann at dreamhost.com (Doug Hellmann) Date: Tue, 18 Mar 2014 12:21:19 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140318122119.19075.62161.malone@wampee.canonical.com> See https://review.openstack.org/#/c/72093/ 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/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From tnurlygayanov at mirantis.com Tue Mar 18 12:32:36 2014 From: tnurlygayanov at mirantis.com (Timur Nurlygayanov) Date: Tue, 18 Mar 2014 12:32:36 -0000 Subject: [Openstack-security] [Bug 1284574] Re: Murano has too open dirs (o+w) References: <20140225103901.32520.60643.malonedeb@gac.canonical.com> Message-ID: <20140318123238.29750.55802.launchpad@gac.canonical.com> ** Changed in: fuel Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1284574 Title: Murano has too open dirs (o+w) Status in Fuel: OpenStack installer that works: Fix Released Bug description: murano-dashboard.spec Please change directory access 777 and 766 to rights 755 To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1284574/+subscriptions From robert.clark at hp.com Tue Mar 18 12:57:56 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 18 Mar 2014 12:57:56 +0000 Subject: [Openstack-security] [Job Advertisement] OpenStack Security Engineer Message-ID: It is my pleasure to announce that the security team at HP is looking for new hires from the OpenStack community. We are hiring in a number of areas, of security; pentesting, architecture and engineering but I think that one role will be of particular interest to this group; 'OpenStack Security Engineer' - we are looking to hire people whose primary focus will be designing new security features in OpenStack and engaging with the OpenStack security community on various issues - this will be a very visible, open-source oriented role, I hope that you'll all consider applying. The official job description is here: https://hp.taleo.net/careersection/jobdetail.ftl?job=1218470 but I'd suggest that anyone who's interested in knowing more should reach out to me directly. Cheers -Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From robert.clark at hp.com Tue Mar 18 13:05:25 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 18 Mar 2014 13:05:25 +0000 Subject: [Openstack-security] OSSG election electorate -- all pitches together In-Reply-To: <53280023.4090005@redhat.com> References: <53280023.4090005@redhat.com> Message-ID: > -----Original Message----- > From: Kurt Seifried [mailto:kseifried at redhat.com] > Sent: 18 March 2014 08:13 > Cc: openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] OSSG election electorate -- all > Are we allowed to ask candidates questions? My main one would be: is the > time and effort for you to work with OpenStack being officially sanctioned > by your employer, and if so to what degree. E.g. are you doing this on your > own time, are you being 100% paid/committed to working with OpenStack, > or something in between? > > The reason I ask is due to sustainability. > > I get that people are passionate about this (otherwise they wouldn't have > stepped up), and qualified (otherwise they wouldn't even be here), but the > time and effort is a serious aspect. And example of this is the roughly 2 year > period where I was something like 1/3 of all OSS-Security mailing traffic due > to handling CVE's (over 1000 a year). The only reason I could pull this off > was because it was part of my job at Red Hat (I was given both time and > resources to do it), there is no way I would have been able to sustain that > commitment on my own time). > > So basically will the candidates have enough time/resources to do this > properly, not just today or tomorrow or next week, but 6 months from > now? Thanks. This is a very good point, in fact it's the reason that my announcement for candidacy was delayed for a couple of days - I was working with the leadership in my organisation to get agreement on the time and resources I'll have available to engage with the OSSG. Until now Bryan and I have shared the load, having a single person leading requires lots more time, I wanted to get firm commitments from my team before I proposed myself for candidacy. I'm happy that I have a good appreciation of the amount of time the OSSG requires in order to grow beyond where it is today and I'm more than satisfied with the support I've received from my organisation in terms of resource, headcount etc. -Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From gamoholic010 at gmail.com Tue Mar 18 13:24:56 2014 From: gamoholic010 at gmail.com (Amey Ghadigaonkar) Date: Tue, 18 Mar 2014 09:24:56 -0400 Subject: [Openstack-security] Email still awaiting moderator approval Message-ID: Hi all, I had sent an email titled *"Blueprint for project related to runtime integrity checks"* to this list on 03/18/14 and it is still waiting for moderator approval since the message exceeded the size limit of 40Kb. Can the moderators please approve that email? Sincerely, Amey Ghadigaonkar. MS in IT - Software Engineering School of Computer Science Carnegie Mellon University -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmed.shohel at ericsson.com Thu Mar 13 12:29:21 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Thu, 13 Mar 2014 14:29:21 +0200 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens In-Reply-To: <20140312163515.19151.6914.malone@wampee.canonical.com> References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> <20140312163515.19151.6914.malone@wampee.canonical.com> Message-ID: <2240452D-4098-430F-8D7C-0D00BFAC8E8B@ericsson.com> Some pros and cons analysis on this topic. What are the related threats and their impacts. -------------- next part -------------- A non-text attachment was scrubbed... Name: Token_Access_scenario_CACHE Sheet1.pdf Type: application/pdf Size: 51896 bytes Desc: not available URL: -------------- next part -------------- …shohel On 12 Mar 2014, at 18:35, Matthew Edmonds wrote: > setting a higher value for token_cache_time and a lower value for > revocation_cache_time (assuming we start using the revocation list here > as proposed by https://review.openstack.org/#/c/78241/) would allow you > to gain the performance improvement of not having to re-request tokens > as often while satisfying the security requirement that revocation take > effect in a timely manner. Yes, the revocation list is being requested > more frequently, and may offset some of the performance gains from > caching tokens. But the revocation list can be used to validate any > token, so multiple tokens could be validated over the life of the cached > revocation list, instead of each token validation requiring a call back > to keystone should token_cache_time be similarly reduced. > > -- > You received this bug notification because you are a member of OpenStack > Security Group, which is subscribed to OpenStack. > https://bugs.launchpad.net/bugs/1287301 > > Title: > Keystone client token cache doesn't respect revoked tokens > > Status in OpenStack Security Advisories: > Invalid > Status in Python client library for Keystone: > In Progress > > Bug description: > If we'll enable caching for keystoneclient tokens we'll be able to use > tokens that are already revoked if they are present in cache: > > https://github.com/openstack/python- > keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 > > steps to recreate: > 1) get a token > 2) use it to make a request via keystoneclient using default properties (thus it will be cached) > 3) delete the token > 4) use the token to make another request via keystoneclient > > expected result: the token should not work (HTTP 401) > actual result: the token still works > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From aghadiga at andrew.cmu.edu Tue Mar 18 13:15:41 2014 From: aghadiga at andrew.cmu.edu (Amey Ghadigaonkar) Date: Tue, 18 Mar 2014 09:15:41 -0400 Subject: [Openstack-security] Email still awaiting moderator approval Message-ID: Hi all, I had sent an email titled *"Blueprint for project related to runtime integrity checks"* to this list on 03/18/14 and it is still waiting for moderator approval since the message exceeded the size limit of 40Kb. Can the moderators please approve that email? Sincerely, Amey Ghadigaonkar. MS in IT - Software Engineering School of Computer Science Carnegie Mellon University -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.clark at hp.com Tue Mar 18 13:30:04 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Tue, 18 Mar 2014 13:30:04 +0000 Subject: [Openstack-security] Email still awaiting moderator approval In-Reply-To: References: Message-ID: Done, sorry for the delay. -Rob From: Amey Ghadigaonkar [mailto:gamoholic010 at gmail.com] Sent: 18 March 2014 13:25 To: openstack-security at lists.openstack.org Cc: Alexandr Naumchev; David Yuan; Bradley Schmerl; Laura Glendenning; Vasilii Artemev Subject: [Openstack-security] Email still awaiting moderator approval Hi all, I had sent an email titled "Blueprint for project related to runtime integrity checks" to this list on 03/18/14 and it is still waiting for moderator approval since the message exceeded the size limit of 40Kb. Can the moderators please approve that email? Sincerely, Amey Ghadigaonkar. MS in IT - Software Engineering School of Computer Science Carnegie Mellon University -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6187 bytes Desc: not available URL: From gerrit2 at review.openstack.org Tue Mar 18 14:05:59 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 18 Mar 2014 14:05:59 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Iafe3c975d59818c8f362647f7ea5149a03deee47 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80401 Log: commit 2ea401f7474bd125ce06a9c1da798f5a8f9d219e Author: Brant Knudson Date: Thu Mar 13 15:50:52 2014 -0500 Configurable token hash algorithm Tokens were always hashed with md5. This change allows tokens to be hashed with sha256. This is for security hardening. If the new 'hash_algorithm' configuration option in the [token] section is set to 'sha256' then PKI tokens will be hashed using the sha256 algorithm rather than the md5 algorithm. The 'hash_algorithm' option defaults to 'md5' for backwards compatibility. The hash_algorithm is also set on all generated tokens and also included in the revocation list. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47 From bdpayne at acm.org Tue Mar 18 15:41:24 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 18 Mar 2014 08:41:24 -0700 Subject: [Openstack-security] OSSG election electorate -- all pitches together In-Reply-To: <53280023.4090005@redhat.com> References: <53280023.4090005@redhat.com> Message-ID: > > Are we allowed to ask candidates questions? > I don't see any problem with this. In fact, it sounds like a great way to make a more informed decision. Thanks for starting the discussion. -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry.carrez+lp at gmail.com Tue Mar 18 16:38:36 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Tue, 18 Mar 2014 16:38:36 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140318163836.15347.14963.malone@chaenomeles.canonical.com> Now repushed as https://review.openstack.org/#/c/81295/ -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From sriram at sriramhere.com Tue Mar 18 17:58:20 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Tue, 18 Mar 2014 10:58:20 -0700 Subject: [Openstack-security] OSSG election electorate -- all pitches together In-Reply-To: References: <53280023.4090005@redhat.com> Message-ID: Kurt, Great question and very important one too. Here is my answer: I am my own employer - which gives me flexibility in choosing where to spend my time on (which is the good part). There is also a downside to this, when sometimes I am involved in a different project, which might take my time away from OSSG. To an extent, I mitigate this by having visibility for next 3 months on my pipeline, but not longer than that. I agree there is some uncertainty, but there is no interference from upper management or no sudden change of priorities due to changes in the Org. You make the call! Thanks, -Sriram PS: This is my quintessential dilemma: how to contribute to OpenStack independently effectively without being employed by a bigger employer. This is little bit better than 2 years ago when I was with an employer which was NOT in for open source contributions:) On Tue, Mar 18, 2014 at 8:41 AM, Bryan D. Payne wrote: > Are we allowed to ask candidates questions? >> > > I don't see any problem with this. In fact, it sounds like a great way to > make a more informed decision. Thanks for starting the discussion. > > -bryan > > _______________________________________________ > 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 skywalker.nick at gmail.com Wed Mar 19 13:13:35 2014 From: skywalker.nick at gmail.com (Li Ma) Date: Wed, 19 Mar 2014 13:13:35 -0000 Subject: [Openstack-security] [Bug 1187107] Re: quantum-ns-metadata-proxy runs as root References: <20130603194234.27198.32504.malonedeb@gac.canonical.com> Message-ID: <20140319131338.14500.61873.launchpad@chaenomeles.canonical.com> ** Changed in: neutron Assignee: Li Ma (nick-ma-z) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1187107 Title: quantum-ns-metadata-proxy runs as root Status in OpenStack Neutron (virtual network service): Triaged Bug description: # ps -ef | grep quantum-ns-metadata-proxy root 10239 1 0 19:01 ? 00:00:00 python /usr/bin/quantum-ns-metadata-proxy --pid_file=/var/lib/quantum/external/pids/7a44de32-3ac0-4f3e-92cc-1a37d8211db8.pid --router_id=7a44de32-3ac0-4f3e-92cc-1a37d8211db8 --state_path=/var/lib/quantum --debug --log-file=quantum-ns-metadata-proxy7a44de32-3ac0-4f3e-92cc-1a37d8211db8.log --log-dir=/var/log/quantum Root is needed to open the namespace, but the quantum-ns-metadata-proxy does not need root - it listens on 9697 by default not 80. I tried changing /etc/quantum/rootwrap.d/l3.filters for it to run as quantum instead: metadata_proxy: CommandFilter, /usr/bin/quantum-ns-metadata-proxy, quantum but it still runs as root. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1187107/+subscriptions From 1244025 at bugs.launchpad.net Wed Mar 19 16:08:36 2014 From: 1244025 at bugs.launchpad.net (Tomoe Sugihara) Date: Wed, 19 Mar 2014 16:08:36 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140319160840.19151.84407.launchpad@wampee.canonical.com> ** Changed in: neutron Assignee: Brandon Berg (bberg-s) => Tomoe Sugihara (tomoe) ** Changed in: neutron/havana Assignee: (unassigned) => Tomoe Sugihara (tomoe) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From 1244025 at bugs.launchpad.net Wed Mar 19 19:11:14 2014 From: 1244025 at bugs.launchpad.net (Tomoe Sugihara) Date: Wed, 19 Mar 2014 19:11:14 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140319191114.14657.37105.malone@chaenomeles.canonical.com> I have updated a patch https://review.openstack.org/#/c/78543/ to fix this on icehouse (or master). -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From gerrit2 at review.openstack.org Thu Mar 20 00:32:00 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 20 Mar 2014 00:32:00 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Iafe3c975d59818c8f362647f7ea5149a03deee47 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80401 Log: commit e52e33216b12d55ad8a553920b741eae6fadef66 Author: Brant Knudson Date: Thu Mar 13 15:50:52 2014 -0500 Configurable token hash algorithm Tokens were always hashed with md5. This change allows tokens to be hashed with sha256. This is for security hardening. If the new 'hash_algorithm' configuration option in the [token] section is set to 'sha256' then PKI tokens will be hashed using the sha256 algorithm rather than the md5 algorithm. The 'hash_algorithm' option defaults to 'md5' for backwards compatibility. The hash_algorithm is also set on all generated tokens and also included in the revocation list. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47 From gerrit2 at review.openstack.org Thu Mar 20 00:53:56 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 20 Mar 2014 00:53:56 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Iafe3c975d59818c8f362647f7ea5149a03deee47 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80401 Log: commit bcb55b6cf61719c6e247345fb2e26edf1b6bf6c4 Author: Brant Knudson Date: Thu Mar 13 15:50:52 2014 -0500 Configurable token hash algorithm Tokens were always hashed with md5. This change allows tokens to be hashed with sha256. This is for security hardening. If the new 'hash_algorithm' configuration option in the [token] section is set to 'sha256' then PKI tokens will be hashed using the sha256 algorithm rather than the md5 algorithm. The 'hash_algorithm' option defaults to 'md5' for backwards compatibility. The hash_algorithm is also set on all generated tokens and also included in the revocation list. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47 From gerrit2 at review.openstack.org Thu Mar 20 01:38:38 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 20 Mar 2014 01:38:38 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change Ie524125dc5f6f1076bfd47db3a414b178e4dac80 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80398 Log: commit 2f91927ca6c8f97309ff9fbe498d55b4483147dc Author: Brant Knudson Date: Thu Mar 13 15:38:34 2014 -0500 Allow hash tokens with sha256 Tokens were always hashed with md5. This change allows tokens to be hashed with sha256 or any other algorithm supported by hashlib. This is for security hardening. If the new 'hash_algorithm' configuration option is set to 'sha256' then the auth_token middleware will hash tokens using 'sha256' when a) Tokens are stored to the cache. b) Tokens are hashed to compare against the revocation list. Using this will require that the Keystone server is also configured to use the same algorithm for tokens, otherwise the revocation list comparison isn't going to work. The 'hash_algorithm' option defaults to 'md5' for backwards compatibility. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80 From gerrit2 at review.openstack.org Thu Mar 20 03:55:36 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 20 Mar 2014 03:55:36 +0000 Subject: [Openstack-security] [openstack/python-keystoneclient] SecurityImpact review request change If9da3cbd0d5134961197c7387c7b39071bbf71b1 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/81695 Log: commit 58f9999116f575c404668a3fbc4d560d3db7f86c Author: Jamie Lennox Date: Thu Mar 20 13:48:27 2014 +1000 Add an exclude option to AuthToken middleware Allow certain paths to be excluded from the auth_token middleware check. The primary use I see for this option is version discovery URLs. We recommend that version discover urls (eg /, /v1, /v2) are accessible unauthenticated however the auth_token middleware is an all or nothing approach and will secure all requests that pass through it. This is an option I would see being set in a paste file or similar - rather than something that would be configured by an end user/administrator. SecurityImpact DocImpact: New option 'exclude' to auth_token middleware settings which will take a regular expression and, if it matches the path, allow a request to proceed unauthenticated. Change-Id: If9da3cbd0d5134961197c7387c7b39071bbf71b1 From 1244025 at bugs.launchpad.net Thu Mar 20 05:50:26 2014 From: 1244025 at bugs.launchpad.net (Tomoe Sugihara) Date: Thu, 20 Mar 2014 05:50:26 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140320055026.30715.38804.malone@gac.canonical.com> Hi Thierry, Mark, I'd like to discuss how to proceed to fix this security issue ASAP in Icehouse, and we have a patch https://review.openstack.org/#/c/78543/. However the patch is flagged with "-2" so it's not been reviewed. Given the severity of the issue, would it be possible for that review to be considered as a bug fix for Icehouse? or Should we request a FFE in order to fix this in Icehouse? Just to recap, The reason why it flagged as "-2" was because it missed the Icehouse-3 deadline. However, the patch was a replacement of the original one(https://review.openstack.org/#/c/74193/), which was submitted in mid Feb in time for FeatureProposalFreeze. We replaced the original one with 3 smaller patches because we were suggested to split into smaller patches right before the I-3 deadline. The patch is tricky in that it implements a blueprint and includes the fix for this issue. But, please note that the blueprint is just for implementing our plugin or just refactoring work to have feature parity of havana with a little extention API included. It doesn't touch the Neutron core code (except for a single migration script), so it shouldn't introduce any regressions in Neutron core. If you could suggest us how to proceed, that would be great. We have allotted dedicated resource to this one to react promptly. 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/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From bdpayne at acm.org Thu Mar 20 07:33:42 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 20 Mar 2014 00:33:42 -0700 Subject: [Openstack-security] OSSG Lead Election Results Message-ID: The results are in: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_87b7eac3e0b24bed Congrats to Rob Clark for being elected OSSG Lead for the Juno dev cycle. Thanks to everyone who participated! Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmed.shohel at ericsson.com Thu Mar 20 09:09:56 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Thu, 20 Mar 2014 11:09:56 +0200 Subject: [Openstack-security] OSSG Lead Election Results In-Reply-To: References: Message-ID: <3E039B37-4AA0-428F-82CF-C3A7DEF31D8E@ericsson.com> Congratulation Rob Clark. Happy to see OSSG is going strong. …shohel On 20 Mar 2014, at 09:33, Bryan D. Payne wrote: > The results are in: > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_87b7eac3e0b24bed > > Congrats to Rob Clark for being elected OSSG Lead for the Juno dev cycle. Thanks to everyone who participated! > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From hui.xiang at canonical.com Thu Mar 20 10:48:17 2014 From: hui.xiang at canonical.com (Hui Xiang) Date: Thu, 20 Mar 2014 18:48:17 +0800 Subject: [Openstack-security] OSSG Lead Election Results In-Reply-To: <3E039B37-4AA0-428F-82CF-C3A7DEF31D8E@ericsson.com> References: <3E039B37-4AA0-428F-82CF-C3A7DEF31D8E@ericsson.com> Message-ID: Rob, Congrats : ) Regards. On Thu, Mar 20, 2014 at 5:09 PM, Abu Shohel Ahmed wrote: > Congratulation Rob Clark. Happy to see OSSG is going strong. > > ...shohel > > On 20 Mar 2014, at 09:33, Bryan D. Payne wrote: > > The results are in: > http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_87b7eac3e0b24bed > > Congrats to Rob Clark for being elected OSSG Lead for the Juno dev cycle. > Thanks to everyone who participated! > > Cheers, > -bryan > _______________________________________________ > 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 thierry.carrez+lp at gmail.com Thu Mar 20 12:58:21 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Thu, 20 Mar 2014 12:58:21 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140320125821.30968.41640.malone@gac.canonical.com> >From the Security team perspective, we need to fix this both in icehouse and in havana, and the icehouse patch is way too featureful to be acceptable in the stable branch. So the decision to accept a feature freeze exception for this is a bit orthogonal to the idea of fixing the security issue. I see two ways out of this maze at this point: (1) Create a patch that fixes the security issue (and only the security issue) that we would apply to havana *and* icehouse (2) Create a patch that fixes the security issue (and only the security issue) that we would apply to havana. Approve an exception to feature freeze to push the complete new version (that also happen to fix the security issue) to icehouse. Given that in both cases we need to create a lightweight havana patch for the security issue (and that this patch is likely to be compatible with the current icehouse version as well), I'd very much prefer we let the neutron folks concentrate on bugfixing by not distracting them with a late feature freeze exception, and therefore follow solution (2) as a solution for this security issue. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From sriram at sriramhere.com Thu Mar 20 14:06:57 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 20 Mar 2014 07:06:57 -0700 Subject: [Openstack-security] OSSG Lead Election Results Message-ID: <532af60f.06d3440a.2d88.ffffafe8@mx.google.com> Bryan, Thanks for officiating the election. Congrats Rob, awesome! -----Original Message----- From: "Bryan D. Payne" Sent: ‎3/‎20/‎2014 12:37 AM To: "openstack-security at lists.openstack.org" Subject: [Openstack-security] OSSG Lead Election Results The results are in: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_87b7eac3e0b24bed Congrats to Rob Clark for being elected OSSG Lead for the Juno dev cycle. Thanks to everyone who participated! Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hui.xiang at canonical.com Wed Mar 19 10:59:07 2014 From: hui.xiang at canonical.com (Hui Xiang) Date: Wed, 19 Mar 2014 18:59:07 +0800 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG In-Reply-To: References: Message-ID: Hey Rob, Shohel, Thanks for your good advise : ), I can see from the wiki there're already some great modeling/reports/result docs of keystone, systematic and very detail, I completely agree with Shohel's gaps descriptions: Engagement from Target project team Engagement of more OSSG members in active way Engament from all Besides that, I have some questions to bother you: 1. I don't know the design process of you guys to output such valued docs, I mean how should I work together with you on this project and not falling far away, would there be milestones to indicate which phase it is during now. 2. In other projects, for example, If I want to connect the neutron team with OSSG to output these docs/codes, how should I do? by communicating with neutron cores or do some work by myself more proactive. 3. wish there are more background and the original intention to be added into the docs, that will be easier for people don't attend the meetings and unaware of some beautiful stories. 4. Wish the OSSG lead may help me grow fast, to the right direction and right way. Anyway, I want to contribute and involved more but as a new starter to this project and not very familiar with keystone, I am coming speed up but worried to lose your steps, forgive my long comments : ) Best Regards. On Tue, Mar 18, 2014 at 6:53 PM, Abu Shohel Ahmed wrote: > Hi Rob and all, > > You rightly pointed out this is an exciting project which can help to > secure all OpenStack projects. > > Now, for the status part, what we have done so far > - We have defined modelling steps for Threat Analysis of OpenStack > projects. > - Templates for the report and analysis part > - Performed threat modelling for some parts of Keystone. > - Continued working with Keystone and more reports to come in the coming > months > > for latest update please check > https://wiki.openstack.org/wiki/Security/Threat_Analysis > or > https://github.com/shohel02/OpenStack_Threat_Modelling > > > What are the gaps: > > - Engagement from Target project team (e.g. Keystone developers or other > project). > The engagement could be > * Reviewing and clarifying the analysis report ( the > generated reports > are also good source of documentation for each project, > we can help each other, > currently we have some amount of engagement from the > keystone developers) > * Acknowledging the threats in relevant projects and > defining way forward. > > - Engagement of more OSSG members in active way. The engagement could be > * Aligning threat modelling process ( what to include what > not to) > * Sharing your earlier threat modelling experiences > * Working collaboratively for the analysis part > > - Engament from all: > * Everyone is welcome to contribute > * Developers can help us to write DFD from code base > * Existing core project members can help to review docs > * Experienced members in OSSG can help to place quality > control measure > > - Covering all core projects: > * We need more interested people to form a team and starts > working on threat modelling of > other core projects ( e.g, Nova, Neutron and so on. The > list is big) > > Lastly, > - How to create a process which is easy to follow and produces best result > > From technical side, i was thinking of Gerrit with some control for > each document to go through. And in the > pipeline we attaches people from both OSSG and Target project team. > > Any other ideas. > > Thanks, > Shohel > > > > > > > > > > On 14 Mar 2014, at 13:19, Clark, Robert Graham > wrote: > > > I think this is a very exciting project, I'll do my best to be at the > next meeting. > > > > Can you summarise for us on the email list, if there are gaps where > resource, knowledge etc are required - there are lots of lurkers on the > security list just waiting for the right opportunity to jump in and help > with something. > > > > -Rob > > > > On 14 March 2014 at 10:58:07, Hui Xiang (hui.xiang at canonical.com hui.xiang at canonical.com>) wrote: > > > > Hi Shohel, > > > > Thanks for you update, I can understand the timezone problem, I will > keep reading the wiki and if there are any questions I will post here, it's > really appreciated to help to answer with that then. > > > > Thank you : ) > > > > > > On Fri, Mar 14, 2014 at 3:55 AM, Fiorentino, Cristian < > cristian.fiorentino at intel.com> > wrote: > > Hi Shohel and Everyone, > > > > I am new to OSSG, and I would be happy to support the OpenStack Threat > Analysis activity. > > Most meeting time proposals in email thread below work for me. > > > > Thanks and Regards. > > Cristian. > > > > > > Date: Thu, 13 Mar 2014 18:18:48 +0200 > > From: Abu Shohel Ahmed ahmed.shohel at ericsson.com>> > > To: Hui Xiang > > > Cc: "Openstack-security at lists.openstack.org Openstack-security at lists.openstack.org> , " > > Openstack-security at lists.openstack.org>> > > Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - > > OSSG > > Message-ID: EAB3FB86-814A-443E-82AE-06045108004B at ericsson.com>> > > Content-Type: text/plain; charset="windows-1252" > > > > Hi Hui Xiang, > > > > You are welcome to join the meeting and take part in the review / Threat > modelling work we are currently working on. Or if you have some suggestion, > please > > share with us. > > > > We will discuss the time schedule issue in the next meeting. I thinks it > would be bit difficult cause we have some participants from US timezones. > > > > We are continuously updating the Wiki page ( although there is sometimes > a lag) and related information, so that everyone is informed. > > > > Related information in the > >> https://wiki.openstack.org/wiki/Security/Threat_Analysis > > > > > > Thanks, > > Shohel > > > > On 13 Mar 2014, at 04:34, Hui Xiang hui.xiang at canonical.com>> wrote: > > > >> Hi all, > >> > >> I am carefully asking you guys if it is possible to bring the meeting > ##openstack-threat-analysis forward to 15.00 UTC, or more earlier? Because > I am in UTC+8 timezone, always can't attend the OSSG meeting before due to > sleepy, but I don't want to miss this meeting although I am not very > familiar with the current topic, I want to contribute more here. > >> > >> But if you are inconvenient to reschedule the time, I can understand > and will keep follow the info from email and community. > >> > >> Thanks for your understanding : ) > >> > >> > >> On Fri, Mar 7, 2014 at 11:55 PM, Abu Shohel Ahmed < > ahmed.shohel at ericsson.com> wrote: > >> Hi all, > >> > >> Yesterday?s OSSG meeting, i promised to give the current status of the > activity. > >> The activity is ongoing. Based on feed back from last IRC call, we > have updated the > >> Threat Modelling framework. > >> > >> The wiki page is updated now.. > >> https://wiki.openstack.org/wiki/Security/Threat_Analysis > >> > >> We are almost finishing the analysis for Auth_token middleware, Token > manager and token service. > >> We looking for reviewer of those documents. There is a meeting > >> today at 17.00 GMT in ##openstack-threat-analysis (unofficial channel) > >> > >> > >> Thanks, > >> Shohel > >> > >> > >> > >> > >> We are going to have a OpenStack Threat m > >> > >> > >>> From: Abu Shohel Ahmed ahmed.shohel at ericsson.com>> > >>> Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - > OSSG > >>> Date: 21 Feb 2014 13:15:08 GMT+2 > >>> To: "openstack-security at lists.openstack.org openstack-security at lists.openstack.org>" < > openstack-security at lists.openstack.org openstack-security at lists.openstack.org>> > >>> Cc: Sriram Subramanian sriram at sriramhere.com>>, "Clark, Robert Graham" > > >>> > >>> Hi guys, > >>> > >>> Sorry for not including the whole OSSG in the initial call. So, we are > having an initial call > >>> for Threat modelling of OpenStack (first one is Keystone) today, 21 > Feb, 17.00 UTC. Let?s > >>> have the discussion today then decide what time suits us best for > later meetings. It is in Free node > >>> channel ##openstack-threat-analysis (unofficial channel). > >>> > >>> Today?s topics of discussion: > >>> 1. Threat modelling process > >>> > https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > >>> > >>> First, we t need to agree on this, so we have conformity > around the whole work. Please feel > >>> free to provide your feedback. > >>> > >>> 2. Some concrete example use of the modelling process > >>> Keystone over all : > https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > >>> Keystone Token-provider: > https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > >>> > >>> (Now this documents are work in progress work, things are not > always in order and complete) > >>> > >>> > >>> See you in the meeting, > >>> Shohel > >>> > >>> > >>> > >>> > >>> On 20 Feb 2014, at 20:47, Sriram Subramanian > wrote: > >>> > >>>> Damn - i missed the meeting again :(. I will check the logs to catch > up. Sorry > >>>> > >>>> > >>>> On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham < > robert.clark at hp.com> wrote: > >>>> Including the whole security group as there was significant interest > during the OSSG weekly meeting. > >>>> > >>>> > >>>> > >>>> From: Sriram Subramanian [mailto:sriram at sriramhere.com sriram at sriramhere.com>] > >>>> Sent: 20 February 2014 16:35 > >>>> To: Abu Shohel Ahmed > >>>> Cc: Clark, Robert Graham; Grant Murphy; Mats N?slund; Makan Pourzandi > >>>> Subject: Re: OpenStack Threat Analysis activity - OSSG > >>>> > >>>> > >>>> > >>>> Shohel, > >>>> > >>>> > >>>> > >>>> Friday 17.00 UTC works - though 18.00 UTC would work better for me. > Are we meeting tomorrow? > >>>> > >>>> > >>>> > >>>> thanks, > >>>> > >>>> -Sriram > >>>> > >>>> > >>>> > >>>> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed < > ahmed.shohel at ericsson.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> From our last week?s, it becomes clear that we need set up a way of > working process in place > >>>> to take this activity forward. > >>>> > >>>> So here are some ideas (Please also share yours): > >>>> > >>>> 1. WoW: > >>>> > >>>> In the short time frame, > >>>> > >>>> - First, We should define the purpose and the concrete output > of this work ( which i think, most of us here has some ideas, if we still > have question - > >>>> we can clear that up before moving forward). > >>>> > >>>> - Second issue is, how we can do threat analysis contribution > in an effective manner. Here comes the collaboration issues within > >>>> this group. For this, I have created a free node IRC channel > ##openstack-threat-analysis ( unofficial channel, as you can see from > name). > >>>> Lets start biweekly (15 days) meetings from this week. Lets > vote for what is the suitable time for meeting for all of us. > >>>> I propose Friday at 17.00 UTC. However, i am happy to schedule > the meeting based on most people preference. > >>>> > >>>> In the longer time frame, we should think about setting up a > Threat analysis working group (could be under OSSG) to perform threat > modelling of all OpenStack components > >>>> - Define a clear out from this working group e.g., Threat > documentation, Design guidance. > >>>> - Engage developers and security minded people to the work. > >>>> > >>>> > >>>> 2. Now on the technical side, > >>>> > >>>> First and foremost, we should agree on a threat > modelling process that can be applied for all OpenStack services and > internal components. We have some ideas that > >>>> can be applied for this work? Here is the link of > our proposal : > >>>> > >>>> > https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > >>>> > >>>> and here are two concrete implementation of > applying the threat modelling process? > >>>> > >>>> Keystone over all : > https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > >>>> Keystone Token-provider: > https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > >>>> > >>>> (These are work in progress documents, so by no > means provide a complete picture) > >>>> > >>>> Lets discuss what do you guys think about the > Modelling steps and its applicability with OpenStack (e.g., Keystone) > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> Shohel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Thanks, > >>>> > >>>> -Sriram > >>>> > >>>> > >>>> _______________________________________________ > >>>> Openstack-security mailing list > >>>> Openstack-security at lists.openstack.org Openstack-security at lists.openstack.org> > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Thanks, > >>>> -Sriram > >>>> _______________________________________________ > >>>> Openstack-security mailing list > >>>> Openstack-security at lists.openstack.org Openstack-security at lists.openstack.org> > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > >>> > >> > >> > >> _______________________________________________ > >> Openstack-security mailing list > >> Openstack-security at lists.openstack.org 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 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 rzhnichkov at mirantis.com Thu Mar 20 06:43:03 2014 From: rzhnichkov at mirantis.com (Roman Zhnichkov) Date: Thu, 20 Mar 2014 06:43:03 -0000 Subject: [Openstack-security] [Bug 1272349] Re: We shouldn't assign public addresses for computes, ceph-osd and cinder-lvm roles References: <20140124141418.15657.35524.malonedeb@gac.canonical.com> Message-ID: <20140320064304.9788.48857.launchpad@soybean.canonical.com> ** Tags added: customer-found -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1272349 Title: We shouldn't assign public addresses for computes, ceph-osd and cinder-lvm roles Status in Fuel: OpenStack installer that works: Triaged Bug description: Fuel assigns public network to all nodes in the cloud. But, in fact, only controller nodes should have a public network. We should remove public network for roles: - computes - ceph-osd - cinder-lvm Exception: in case nova-network (multi host) computes required public network. To manage notifications about this bug go to: https://bugs.launchpad.net/fuel/+bug/1272349/+subscriptions From ahmed.shohel at ericsson.com Thu Mar 20 10:32:40 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Thu, 20 Mar 2014 12:32:40 +0200 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG In-Reply-To: References: Message-ID: <40643947-D6CC-439C-9482-DDFE65424089@ericsson.com> Hi Hui, Thanks for your interests. Some comments inline On 19 Mar 2014, at 12:59, Hui Xiang wrote: > Hey Rob, Shohel, > > Thanks for your good advise : ), I can see from the wiki there're already some great modeling/reports/result docs of keystone, systematic and very detail, > > I completely agree with Shohel's gaps descriptions: > Engagement from Target project team > Engagement of more OSSG members in active way > Engament from all > > Besides that, I have some questions to bother you: > 1. I don't know the design process of you guys to output such valued docs, I mean how should I work together with you on this project and not falling far away, would there be milestones to indicate which phase it is during now. The process currently we are following is defined in the wiki or here: https://wiki.openstack.org/wiki/File:Threat_modeling_process.pdf ( if you want add something to the process please do mention ) If you say about a project plan, yes we have one but not so formal one. Currently, we are going one by one, all the components based on the Keystone high level analysis file ( file in repo). As said earlier, there are multiple ways to contribute for example, in analysis ( read the docs from one of the file in git rep ../ananlysis_report/ and perform analysis, or working on finding new threats with existing published one , or writing DFD for new components (for example, we have not done anything yet for catalog driver, memcache or LDAP backend and many other parts of keystone)) and so on. Our biweekly meeting is also a good place to discuss this issue. i will take this issue in our regular meeting to discuss how to improve collaboration. > 2. In other projects, for example, If I want to connect the neutron team with OSSG to output these docs/codes, how should I do? by communicating with neutron cores or do some work by myself more proactive Here we should do more collaboration by any possible means. > 3. wish there are more background and the original intention to be added into the docs, that will be easier for people don't attend the meetings and unaware of some beautiful stories. ok, noted, we will improve this part. > 4. Wish the OSSG lead may help me grow fast, to the right direction and right way. > > Anyway, I want to contribute and involved more but as a new starter to this project and not very familiar with keystone, I am coming speed up but worried to lose your steps, forgive my long comments : ) > > Best Regards. > > thanks, shohel > > > On Tue, Mar 18, 2014 at 6:53 PM, Abu Shohel Ahmed wrote: > Hi Rob and all, > > You rightly pointed out this is an exciting project which can help to secure all OpenStack projects. > > Now, for the status part, what we have done so far > - We have defined modelling steps for Threat Analysis of OpenStack projects. > - Templates for the report and analysis part > - Performed threat modelling for some parts of Keystone. > - Continued working with Keystone and more reports to come in the coming months > > for latest update please check > https://wiki.openstack.org/wiki/Security/Threat_Analysis > or > https://github.com/shohel02/OpenStack_Threat_Modelling > > > What are the gaps: > > - Engagement from Target project team (e.g. Keystone developers or other project). > The engagement could be > * Reviewing and clarifying the analysis report ( the generated reports > are also good source of documentation for each project, we can help each other, > currently we have some amount of engagement from the keystone developers) > * Acknowledging the threats in relevant projects and defining way forward. > > - Engagement of more OSSG members in active way. The engagement could be > * Aligning threat modelling process ( what to include what not to) > * Sharing your earlier threat modelling experiences > * Working collaboratively for the analysis part > > - Engament from all: > * Everyone is welcome to contribute > * Developers can help us to write DFD from code base > * Existing core project members can help to review docs > * Experienced members in OSSG can help to place quality control measure > > - Covering all core projects: > * We need more interested people to form a team and starts working on threat modelling of > other core projects ( e.g, Nova, Neutron and so on. The list is big) > > Lastly, > - How to create a process which is easy to follow and produces best result > > From technical side, i was thinking of Gerrit with some control for each document to go through. And in the > pipeline we attaches people from both OSSG and Target project team. > > Any other ideas. > > Thanks, > Shohel > > > > > > > > > > On 14 Mar 2014, at 13:19, Clark, Robert Graham wrote: > > > I think this is a very exciting project, I’ll do my best to be at the next meeting. > > > > Can you summarise for us on the email list, if there are gaps where resource, knowledge etc are required - there are lots of lurkers on the security list just waiting for the right opportunity to jump in and help with something. > > > > -Rob > > > > On 14 March 2014 at 10:58:07, Hui Xiang (hui.xiang at canonical.com) wrote: > > > > Hi Shohel, > > > > Thanks for you update, I can understand the timezone problem, I will keep reading the wiki and if there are any questions I will post here, it's really appreciated to help to answer with that then. > > > > Thank you : ) > > > > > > On Fri, Mar 14, 2014 at 3:55 AM, Fiorentino, Cristian > wrote: > > Hi Shohel and Everyone, > > > > I am new to OSSG, and I would be happy to support the OpenStack Threat Analysis activity. > > Most meeting time proposals in email thread below work for me. > > > > Thanks and Regards. > > Cristian. > > > > > > Date: Thu, 13 Mar 2014 18:18:48 +0200 > > From: Abu Shohel Ahmed > > > To: Hui Xiang > > > Cc: "Openstack-security at lists.openstack.org , " > > > > > Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - > > OSSG > > Message-ID: > > > Content-Type: text/plain; charset="windows-1252" > > > > Hi Hui Xiang, > > > > You are welcome to join the meeting and take part in the review / Threat modelling work we are currently working on. Or if you have some suggestion, please > > share with us. > > > > We will discuss the time schedule issue in the next meeting. I thinks it would be bit difficult cause we have some participants from US timezones. > > > > We are continuously updating the Wiki page ( although there is sometimes a lag) and related information, so that everyone is informed. > > > > Related information in the > >> https://wiki.openstack.org/wiki/Security/Threat_Analysis > > > > > > Thanks, > > Shohel > > > > On 13 Mar 2014, at 04:34, Hui Xiang > wrote: > > > >> Hi all, > >> > >> I am carefully asking you guys if it is possible to bring the meeting ##openstack-threat-analysis forward to 15.00 UTC, or more earlier? Because I am in UTC+8 timezone, always can't attend the OSSG meeting before due to sleepy, but I don't want to miss this meeting although I am not very familiar with the current topic, I want to contribute more here. > >> > >> But if you are inconvenient to reschedule the time, I can understand and will keep follow the info from email and community. > >> > >> Thanks for your understanding : ) > >> > >> > >> On Fri, Mar 7, 2014 at 11:55 PM, Abu Shohel Ahmed > wrote: > >> Hi all, > >> > >> Yesterday?s OSSG meeting, i promised to give the current status of the activity. > >> The activity is ongoing. Based on feed back from last IRC call, we have updated the > >> Threat Modelling framework. > >> > >> The wiki page is updated now.. > >> https://wiki.openstack.org/wiki/Security/Threat_Analysis > >> > >> We are almost finishing the analysis for Auth_token middleware, Token manager and token service. > >> We looking for reviewer of those documents. There is a meeting > >> today at 17.00 GMT in ##openstack-threat-analysis (unofficial channel) > >> > >> > >> Thanks, > >> Shohel > >> > >> > >> > >> > >> We are going to have a OpenStack Threat m > >> > >> > >>> From: Abu Shohel Ahmed > > >>> Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - OSSG > >>> Date: 21 Feb 2014 13:15:08 GMT+2 > >>> To: "openstack-security at lists.openstack.org" > > >>> Cc: Sriram Subramanian >, "Clark, Robert Graham" > > >>> > >>> Hi guys, > >>> > >>> Sorry for not including the whole OSSG in the initial call. So, we are having an initial call > >>> for Threat modelling of OpenStack (first one is Keystone) today, 21 Feb, 17.00 UTC. Let?s > >>> have the discussion today then decide what time suits us best for later meetings. It is in Free node > >>> channel ##openstack-threat-analysis (unofficial channel). > >>> > >>> Today?s topics of discussion: > >>> 1. Threat modelling process > >>> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > >>> > >>> First, we t need to agree on this, so we have conformity around the whole work. Please feel > >>> free to provide your feedback. > >>> > >>> 2. Some concrete example use of the modelling process > >>> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > >>> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > >>> > >>> (Now this documents are work in progress work, things are not always in order and complete) > >>> > >>> > >>> See you in the meeting, > >>> Shohel > >>> > >>> > >>> > >>> > >>> On 20 Feb 2014, at 20:47, Sriram Subramanian > wrote: > >>> > >>>> Damn - i missed the meeting again :(. I will check the logs to catch up. Sorry > >>>> > >>>> > >>>> On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham > wrote: > >>>> Including the whole security group as there was significant interest during the OSSG weekly meeting. > >>>> > >>>> > >>>> > >>>> From: Sriram Subramanian [mailto:sriram at sriramhere.com] > >>>> Sent: 20 February 2014 16:35 > >>>> To: Abu Shohel Ahmed > >>>> Cc: Clark, Robert Graham; Grant Murphy; Mats N?slund; Makan Pourzandi > >>>> Subject: Re: OpenStack Threat Analysis activity - OSSG > >>>> > >>>> > >>>> > >>>> Shohel, > >>>> > >>>> > >>>> > >>>> Friday 17.00 UTC works - though 18.00 UTC would work better for me. Are we meeting tomorrow? > >>>> > >>>> > >>>> > >>>> thanks, > >>>> > >>>> -Sriram > >>>> > >>>> > >>>> > >>>> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed > wrote: > >>>> > >>>> Hi, > >>>> > >>>> From our last week?s, it becomes clear that we need set up a way of working process in place > >>>> to take this activity forward. > >>>> > >>>> So here are some ideas (Please also share yours): > >>>> > >>>> 1. WoW: > >>>> > >>>> In the short time frame, > >>>> > >>>> - First, We should define the purpose and the concrete output of this work ( which i think, most of us here has some ideas, if we still have question - > >>>> we can clear that up before moving forward). > >>>> > >>>> - Second issue is, how we can do threat analysis contribution in an effective manner. Here comes the collaboration issues within > >>>> this group. For this, I have created a free node IRC channel ##openstack-threat-analysis ( unofficial channel, as you can see from name). > >>>> Lets start biweekly (15 days) meetings from this week. Lets vote for what is the suitable time for meeting for all of us. > >>>> I propose Friday at 17.00 UTC. However, i am happy to schedule the meeting based on most people preference. > >>>> > >>>> In the longer time frame, we should think about setting up a Threat analysis working group (could be under OSSG) to perform threat modelling of all OpenStack components > >>>> - Define a clear out from this working group e.g., Threat documentation, Design guidance. > >>>> - Engage developers and security minded people to the work. > >>>> > >>>> > >>>> 2. Now on the technical side, > >>>> > >>>> First and foremost, we should agree on a threat modelling process that can be applied for all OpenStack services and internal components. We have some ideas that > >>>> can be applied for this work? Here is the link of our proposal : > >>>> > >>>> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing > >>>> > >>>> and here are two concrete implementation of applying the threat modelling process? > >>>> > >>>> Keystone over all : https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing > >>>> Keystone Token-provider: https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing > >>>> > >>>> (These are work in progress documents, so by no means provide a complete picture) > >>>> > >>>> Lets discuss what do you guys think about the Modelling steps and its applicability with OpenStack (e.g., Keystone) > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> Shohel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Thanks, > >>>> > >>>> -Sriram > >>>> > >>>> > >>>> _______________________________________________ > >>>> Openstack-security mailing list > >>>> Openstack-security at lists.openstack.org > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Thanks, > >>>> -Sriram > >>>> _______________________________________________ > >>>> Openstack-security mailing list > >>>> Openstack-security at lists.openstack.org > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > >>> > >> > >> > >> _______________________________________________ > >> Openstack-security mailing list > >> Openstack-security at lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > >> > >> > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From hui.xiang at canonical.com Thu Mar 20 10:47:31 2014 From: hui.xiang at canonical.com (Hui Xiang) Date: Thu, 20 Mar 2014 18:47:31 +0800 Subject: [Openstack-security] OpenStack Threat Analysis activity - OSSG In-Reply-To: <40643947-D6CC-439C-9482-DDFE65424089@ericsson.com> References: <40643947-D6CC-439C-9482-DDFE65424089@ericsson.com> Message-ID: Thanks shohel for your nice response, it's helpful : D On Thu, Mar 20, 2014 at 6:32 PM, Abu Shohel Ahmed wrote: > Hi Hui, > > Thanks for your interests. Some comments inline > > On 19 Mar 2014, at 12:59, Hui Xiang wrote: > > Hey Rob, Shohel, > > Thanks for your good advise : ), I can see from the wiki there're > already some great modeling/reports/result docs of keystone, systematic and > very detail, > > I completely agree with Shohel's gaps descriptions: > Engagement from Target project team > Engagement of more OSSG members in active way > Engament from all > > Besides that, I have some questions to bother you: > 1. I don't know the design process of you guys to output such > valued docs, I mean how should I work together with you on this project and > not falling far away, would there be milestones to indicate which phase it > is during now. > > The process currently we are following is defined in the wiki or here: > https://wiki.openstack.org/wiki/File:Threat_modeling_process.pdf > ( if you want add something to the process please do mention ) > > If you say about a project plan, yes we have one but not so formal one. > Currently, we are > going one by one, all the components based on the Keystone high level > analysis file ( file in repo). > As said earlier, there are multiple ways to contribute > for example, in analysis ( read the docs from one of the file > in git rep ../ananlysis_report/ and perform analysis, or working on > finding new threats with existing published one , > or writing DFD for new components (for example, we have not done anything > yet for catalog driver, > memcache or LDAP backend and many other parts of keystone)) and so on. > > Our biweekly meeting is also a good place to discuss this issue. i will > take this issue in our regular meeting to > discuss how to improve collaboration. > > 2. In other projects, for example, If I want to connect the neutron > team with OSSG to output these docs/codes, how should I do? by > communicating with neutron cores or do some work by myself more proactive > > Here we should do more collaboration by any possible means. > > 3. wish there are more background and the original intention to be > added into the docs, that will be easier for people don't attend the > meetings and unaware of some beautiful stories. > > ok, noted, we will improve this part. > > 4. Wish the OSSG lead may help me grow fast, to the right direction > and right way. > > Anyway, I want to contribute and involved more but as a new starter to > this project and not very familiar with keystone, I am coming speed up but > worried to lose your steps, forgive my long comments : ) > > Best Regards. > > > > > thanks, > shohel > > > > > On Tue, Mar 18, 2014 at 6:53 PM, Abu Shohel Ahmed < > ahmed.shohel at ericsson.com> wrote: > >> Hi Rob and all, >> >> You rightly pointed out this is an exciting project which can help to >> secure all OpenStack projects. >> >> Now, for the status part, what we have done so far >> - We have defined modelling steps for Threat Analysis of OpenStack >> projects. >> - Templates for the report and analysis part >> - Performed threat modelling for some parts of Keystone. >> - Continued working with Keystone and more reports to come in the coming >> months >> >> for latest update please check >> https://wiki.openstack.org/wiki/Security/Threat_Analysis >> or >> https://github.com/shohel02/OpenStack_Threat_Modelling >> >> >> What are the gaps: >> >> - Engagement from Target project team (e.g. Keystone developers or other >> project). >> The engagement could be >> * Reviewing and clarifying the analysis report ( the >> generated reports >> are also good source of documentation for each project, >> we can help each other, >> currently we have some amount of engagement from the >> keystone developers) >> * Acknowledging the threats in relevant projects and >> defining way forward. >> >> - Engagement of more OSSG members in active way. The engagement could be >> * Aligning threat modelling process ( what to include >> what not to) >> * Sharing your earlier threat modelling experiences >> * Working collaboratively for the analysis part >> >> - Engament from all: >> * Everyone is welcome to contribute >> * Developers can help us to write DFD from code base >> * Existing core project members can help to review docs >> * Experienced members in OSSG can help to place quality >> control measure >> >> - Covering all core projects: >> * We need more interested people to form a team and starts >> working on threat modelling of >> other core projects ( e.g, Nova, Neutron and so on. The >> list is big) >> >> Lastly, >> - How to create a process which is easy to follow and produces best result >> >> From technical side, i was thinking of Gerrit with some control for >> each document to go through. And in the >> pipeline we attaches people from both OSSG and Target project team. >> >> Any other ideas. >> >> Thanks, >> Shohel >> >> >> >> >> >> >> >> >> >> On 14 Mar 2014, at 13:19, Clark, Robert Graham >> wrote: >> >> > I think this is a very exciting project, I'll do my best to be at the >> next meeting. >> > >> > Can you summarise for us on the email list, if there are gaps where >> resource, knowledge etc are required - there are lots of lurkers on the >> security list just waiting for the right opportunity to jump in and help >> with something. >> > >> > -Rob >> > >> > On 14 March 2014 at 10:58:07, Hui Xiang (hui.xiang at canonical.com >> ) wrote: >> > >> > Hi Shohel, >> > >> > Thanks for you update, I can understand the timezone problem, I will >> keep reading the wiki and if there are any questions I will post here, it's >> really appreciated to help to answer with that then. >> > >> > Thank you : ) >> > >> > >> > On Fri, Mar 14, 2014 at 3:55 AM, Fiorentino, Cristian < >> cristian.fiorentino at intel.com> >> wrote: >> > Hi Shohel and Everyone, >> > >> > I am new to OSSG, and I would be happy to support the OpenStack Threat >> Analysis activity. >> > Most meeting time proposals in email thread below work for me. >> > >> > Thanks and Regards. >> > Cristian. >> > >> > >> > Date: Thu, 13 Mar 2014 18:18:48 +0200 >> > From: Abu Shohel Ahmed > ahmed.shohel at ericsson.com>> >> > To: Hui Xiang > >> > Cc: "Openstack-security at lists.openstack.org> Openstack-security at lists.openstack.org> , " >> > > Openstack-security at lists.openstack.org>> >> > Subject: Re: [Openstack-security] OpenStack Threat Analysis activity - >> > OSSG >> > Message-ID: > EAB3FB86-814A-443E-82AE-06045108004B at ericsson.com>> >> > Content-Type: text/plain; charset="windows-1252" >> > >> > Hi Hui Xiang, >> > >> > You are welcome to join the meeting and take part in the review / >> Threat modelling work we are currently working on. Or if you have some >> suggestion, please >> > share with us. >> > >> > We will discuss the time schedule issue in the next meeting. I thinks >> it would be bit difficult cause we have some participants from US timezones. >> > >> > We are continuously updating the Wiki page ( although there is >> sometimes a lag) and related information, so that everyone is informed. >> > >> > Related information in the >> >> https://wiki.openstack.org/wiki/Security/Threat_Analysis >> > >> > >> > Thanks, >> > Shohel >> > >> > On 13 Mar 2014, at 04:34, Hui Xiang > hui.xiang at canonical.com>> wrote: >> > >> >> Hi all, >> >> >> >> I am carefully asking you guys if it is possible to bring the meeting >> ##openstack-threat-analysis forward to 15.00 UTC, or more earlier? Because >> I am in UTC+8 timezone, always can't attend the OSSG meeting before due to >> sleepy, but I don't want to miss this meeting although I am not very >> familiar with the current topic, I want to contribute more here. >> >> >> >> But if you are inconvenient to reschedule the time, I can understand >> and will keep follow the info from email and community. >> >> >> >> Thanks for your understanding : ) >> >> >> >> >> >> On Fri, Mar 7, 2014 at 11:55 PM, Abu Shohel Ahmed < >> ahmed.shohel at ericsson.com> wrote: >> >> Hi all, >> >> >> >> Yesterday?s OSSG meeting, i promised to give the current status of >> the activity. >> >> The activity is ongoing. Based on feed back from last IRC call, we >> have updated the >> >> Threat Modelling framework. >> >> >> >> The wiki page is updated now.. >> >> https://wiki.openstack.org/wiki/Security/Threat_Analysis >> >> >> >> We are almost finishing the analysis for Auth_token middleware, Token >> manager and token service. >> >> We looking for reviewer of those documents. There is a meeting >> >> today at 17.00 GMT in ##openstack-threat-analysis (unofficial >> channel) >> >> >> >> >> >> Thanks, >> >> Shohel >> >> >> >> >> >> >> >> >> >> We are going to have a OpenStack Threat m >> >> >> >> >> >>> From: Abu Shohel Ahmed > ahmed.shohel at ericsson.com>> >> >>> Subject: Re: [Openstack-security] OpenStack Threat Analysis activity >> - OSSG >> >>> Date: 21 Feb 2014 13:15:08 GMT+2 >> >>> To: "openstack-security at lists.openstack.org> openstack-security at lists.openstack.org>" < >> openstack-security at lists.openstack.org> openstack-security at lists.openstack.org>> >> >>> Cc: Sriram Subramanian > sriram at sriramhere.com>>, "Clark, Robert Graham" > > >> >>> >> >>> Hi guys, >> >>> >> >>> Sorry for not including the whole OSSG in the initial call. So, we >> are having an initial call >> >>> for Threat modelling of OpenStack (first one is Keystone) today, 21 >> Feb, 17.00 UTC. Let?s >> >>> have the discussion today then decide what time suits us best for >> later meetings. It is in Free node >> >>> channel ##openstack-threat-analysis (unofficial channel). >> >>> >> >>> Today?s topics of discussion: >> >>> 1. Threat modelling process >> >>> >> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >> >>> >> >>> First, we t need to agree on this, so we have conformity >> around the whole work. Please feel >> >>> free to provide your feedback. >> >>> >> >>> 2. Some concrete example use of the modelling process >> >>> Keystone over all : >> https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >> >>> Keystone Token-provider: >> https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >> >>> >> >>> (Now this documents are work in progress work, things are not >> always in order and complete) >> >>> >> >>> >> >>> See you in the meeting, >> >>> Shohel >> >>> >> >>> >> >>> >> >>> >> >>> On 20 Feb 2014, at 20:47, Sriram Subramanian > > wrote: >> >>> >> >>>> Damn - i missed the meeting again :(. I will check the logs to catch >> up. Sorry >> >>>> >> >>>> >> >>>> On Thu, Feb 20, 2014 at 10:26 AM, Clark, Robert Graham < >> robert.clark at hp.com> wrote: >> >>>> Including the whole security group as there was significant interest >> during the OSSG weekly meeting. >> >>>> >> >>>> >> >>>> >> >>>> From: Sriram Subramanian [mailto:sriram at sriramhere.com> sriram at sriramhere.com>] >> >>>> Sent: 20 February 2014 16:35 >> >>>> To: Abu Shohel Ahmed >> >>>> Cc: Clark, Robert Graham; Grant Murphy; Mats N?slund; Makan Pourzandi >> >>>> Subject: Re: OpenStack Threat Analysis activity - OSSG >> >>>> >> >>>> >> >>>> >> >>>> Shohel, >> >>>> >> >>>> >> >>>> >> >>>> Friday 17.00 UTC works - though 18.00 UTC would work better for me. >> Are we meeting tomorrow? >> >>>> >> >>>> >> >>>> >> >>>> thanks, >> >>>> >> >>>> -Sriram >> >>>> >> >>>> >> >>>> >> >>>> On Wed, Feb 19, 2014 at 4:25 AM, Abu Shohel Ahmed < >> ahmed.shohel at ericsson.com> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> From our last week?s, it becomes clear that we need set up a way of >> working process in place >> >>>> to take this activity forward. >> >>>> >> >>>> So here are some ideas (Please also share yours): >> >>>> >> >>>> 1. WoW: >> >>>> >> >>>> In the short time frame, >> >>>> >> >>>> - First, We should define the purpose and the concrete output >> of this work ( which i think, most of us here has some ideas, if we still >> have question - >> >>>> we can clear that up before moving forward). >> >>>> >> >>>> - Second issue is, how we can do threat analysis contribution >> in an effective manner. Here comes the collaboration issues within >> >>>> this group. For this, I have created a free node IRC >> channel ##openstack-threat-analysis ( unofficial channel, as you can see >> from name). >> >>>> Lets start biweekly (15 days) meetings from this week. Lets >> vote for what is the suitable time for meeting for all of us. >> >>>> I propose Friday at 17.00 UTC. However, i am happy to >> schedule the meeting based on most people preference. >> >>>> >> >>>> In the longer time frame, we should think about setting up a >> Threat analysis working group (could be under OSSG) to perform threat >> modelling of all OpenStack components >> >>>> - Define a clear out from this working group e.g., Threat >> documentation, Design guidance. >> >>>> - Engage developers and security minded people to the work. >> >>>> >> >>>> >> >>>> 2. Now on the technical side, >> >>>> >> >>>> First and foremost, we should agree on a threat >> modelling process that can be applied for all OpenStack services and >> internal components. We have some ideas that >> >>>> can be applied for this work? Here is the link of >> our proposal : >> >>>> >> >>>> >> https://drive.google.com/file/d/0B1aEVfmQtqnoMmpPZ3hmUHpBa1k/edit?usp=sharing >> >>>> >> >>>> and here are two concrete implementation of >> applying the threat modelling process? >> >>>> >> >>>> Keystone over all : >> https://drive.google.com/file/d/0B1aEVfmQtqnobzB6M21uMEFXNUE/edit?usp=sharing >> >>>> Keystone Token-provider: >> https://drive.google.com/file/d/0B1aEVfmQtqnoejN1T1kybjlnMkk/edit?usp=sharing >> >>>> >> >>>> (These are work in progress documents, so by no >> means provide a complete picture) >> >>>> >> >>>> Lets discuss what do you guys think about the >> Modelling steps and its applicability with OpenStack (e.g., Keystone) >> >>>> >> >>>> >> >>>> >> >>>> Thanks, >> >>>> Shohel >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> >> >>>> Thanks, >> >>>> >> >>>> -Sriram >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Openstack-security mailing list >> >>>> Openstack-security at lists.openstack.org> Openstack-security at lists.openstack.org> >> >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Thanks, >> >>>> -Sriram >> >>>> _______________________________________________ >> >>>> Openstack-security mailing list >> >>>> Openstack-security at lists.openstack.org> Openstack-security at lists.openstack.org> >> >>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >>> >> >> >> >> >> >> _______________________________________________ >> >> Openstack-security mailing list >> >> Openstack-security at lists.openstack.org> 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> 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 robert.clark at hp.com Thu Mar 20 15:33:34 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Thu, 20 Mar 2014 15:33:34 +0000 Subject: [Openstack-security] OSSG Lead Election Results In-Reply-To: <532af60f.06d3440a.2d88.ffffafe8@mx.google.com> References: <532af60f.06d3440a.2d88.ffffafe8@mx.google.com> Message-ID: Thank you Bryan! I’d like to extend special thanks to Bryan, without whom this group would not be what it is today, he’s been a superb leader in this space and I look forward to continuing to work with him on the future of the OSSG. Malini and Sriram, your contributions to the OSSG have been substantial and running in the election is a great example of your commitment! Over the next few days I’m hoping to build a roadmap for the OSSG, bringing in those projects that need more attention and looking for suggestions on other awesome things we can get involved with – will discuss more at the meeting today -Rob From: Sriram Subramanian [mailto:sriram at sriramhere.com] Sent: 20 March 2014 14:07 To: Bryan D. Payne; openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OSSG Lead Election Results Bryan, Thanks for officiating the election. Congrats Rob, awesome! _____ From: Bryan D. Payne Sent: ‎3/‎20/‎2014 12:37 AM To: openstack-security at lists.openstack.org Subject: [Openstack-security] OSSG Lead Election Results The results are in: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_87b7eac3e0b24bed Congrats to Rob Clark for being elected OSSG Lead for the Juno dev cycle. Thanks to everyone who participated! Cheers, -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 1244025 at bugs.launchpad.net Thu Mar 20 15:31:58 2014 From: 1244025 at bugs.launchpad.net (Akihiro Motoki) Date: Thu, 20 Mar 2014 15:31:58 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140320153158.30785.16907.malone@gac.canonical.com> The proposed patch contains many feature changes and some security fixes. Before reading this bug, I thought this patch is a new feature proposal and this is the reason the patch has not been well reviewed after I-3 branch cut. I would suggest to split security fix from feature changes first. If all changes are required, the reason needs to be explained. SecurityImpact tag in the commit message will be appreciated too. After looking around the review, I could not understand how the issued report here will be fixed in the patch. I hope the commit message contains enough information how the patch fixes the issue. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From 1244025 at bugs.launchpad.net Thu Mar 20 16:10:30 2014 From: 1244025 at bugs.launchpad.net (Tomoe Sugihara) Date: Thu, 20 Mar 2014 16:10:30 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140320161030.22545.46482.malone@wampee.canonical.com> Thank you Thierry and Motoki san for following this up. I appreciate it. Thierry, I'll prepare a fix only patch for havana shortly. Motoki san, Yes, the patch is indeed a feature proposed in time for FeatureProposalFreeze before I-3, which happens to include this fix. We need to change most part of our plugin in icehouse due to our backend change, but it's basically a feature parity with a couple of new extension supported. So despite the amount of code change, it doesn't include much feature, just a feature parity on havana. As I described above, we submitted the original patch in mid Feb, but we were asked by reviewers to break it down into smaller patches right before the I-3 deadline, so we did it, but that took a couple of days and missed the I-3 deadline. So, we could apply the fix only patch for havana to icehouse, but our plugin in icehouse would still be broken because of the incompatibility with our new backend. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From 1244025 at bugs.launchpad.net Thu Mar 20 16:48:48 2014 From: 1244025 at bugs.launchpad.net (Akihiro Motoki) Date: Thu, 20 Mar 2014 16:48:48 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140320164848.9642.90241.malone@soybean.canonical.com> If the feature proposed patch is not included in Icehouse release, don't we need the same patch you will propose for Havana soon for Icehouse too (as long as midonet plugin is a part of Iceshouse release)? I think Icehouse midonet plugin still works with your old backend even if it does not work with your new backend. Generally speaking, FeatureProposeFreeze for I-3 is just a minimum requirement and it does not ensure the patch is well reviewed and merged. It is unfortunate the patch is not merged so far but it sometimes happens due to review burden. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From 1244025 at bugs.launchpad.net Thu Mar 20 17:13:23 2014 From: 1244025 at bugs.launchpad.net (Tomoe Sugihara) Date: Thu, 20 Mar 2014 17:13:23 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140320171323.30785.62153.malone@gac.canonical.com> Hello @amotoki, It just has to do with our internal constraints in which we cannot maintain the old backend with Icehouse. > Generally speaking, FeatureProposeFreeze for I-3 is just a minimum requirement and it does not ensure the patch is well reviewed and merged. It is unfortunate the patch is not merged so far but it sometimes happens due to review burden. Understood. Yes it was indeed unfortunate. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From bdpayne at acm.org Thu Mar 20 18:34:18 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 20 Mar 2014 18:34:18 -0000 Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set insecure file permissions References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com> Message-ID: <20140320183420.21824.37567.launchpad@wampee.canonical.com> ** Changed in: ossn 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/1260679 Title: Multiple drivers set insecure file permissions Status in Cinder: In Progress Status in OpenStack Security Notes: In Progress Bug description: GPFS from various places calls "chmod 666" as root: ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', path, run_as_root=True) ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', vol_path, run_as_root=True) the Huawei driver sets 777 permissions as root on some files: ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) the Scality driver sets 666 permissions on all volumes: cinder/volume/drivers/scality.py:     def _create_file(self, path, size):         with open(path, "ab") as f:             f.truncate(size)         os.chmod(path, 0o666) Similarly, the NFS and NEXENTA driver have an implementation of def _set_rw_permissions_for_all() that is being called on all newly created volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1260679/+subscriptions From thierry.carrez+lp at gmail.com Fri Mar 21 16:25:08 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Fri, 21 Mar 2014 16:25:08 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140321162508.6092.12035.malone@chaenomeles.canonical.com> Yes, let's decouple the two issues. We need the security patch for the current havana (stable/havana) and icehouse (master) branches in order to plug this long-standing security issue. Those should be proposed as bugfixes without introducing a new feature, configuration option or significant behavior change in order to be acceptable as a stable branch update. Please post the references of the reviews here when those will have been submitted to Gerrit. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From fungi at yuggoth.org Fri Mar 21 21:24:27 2014 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 21 Mar 2014 21:24:27 +0000 Subject: [Openstack-security] [Job Advertisement] OpenStack Security Engineer In-Reply-To: References: Message-ID: <20140321212423.GH2653@yuggoth.org> On 2014-03-18 12:57:56 +0000 (+0000), Clark, Robert Graham wrote: > It is my pleasure to announce that the security team at HP is looking > for new hires from the OpenStack community. [...] You probably also want to post it to http://www.openstack.org/community/jobs/ (I see "Seattle, WA HPCS- Software Engineer - Cloud Security at HP" posted there about a year ago, so I assume this is unrelated). That site was set up mainly to keep the number of job postings on OpenStack mailing lists to a minimum--otherwise we tend to get overrun with E-mails from recruiters trolling for OpenStack-specific job candidates. -- Jeremy Stanley From 1244025 at bugs.launchpad.net Mon Mar 24 01:38:40 2014 From: 1244025 at bugs.launchpad.net (Ryu Ishimoto) Date: Mon, 24 Mar 2014 01:38:40 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140324013840.21824.48867.malone@wampee.canonical.com> Akihiro, it's our fault for not mentioning that this also fixes the security bug in the commit comment or this page earlier. As you can see, the original patch that was submitted for this security bug has been largely neglected since November of 2013. A lot has changed in the backend since then, and we have been fixing issues on the backend side for faster response. For Icehouse, to work with the new backend that contains various fixes, the plugin had to be changed to fit the new API. This also made it difficult to do it incrementally as it was a completely overhaul of the API to put more logic in the backend side. Note that the main purpose of this patch is to achieve feature parity, with less code to maintain in the neutron side. It does contain quota and ext-gw-mode extensions since they were very minimal to implement but we can take them out as well. Since we shouldn't have this issue open for much longer, let's decide on this. We have a strong desire to keep our upstream version of Neutron as our primary de facto Neutron product. The only option to achieve this for Icehouse is to have this patch merged as FFE. We really want this, and we feel like we have done what we needed to do to get it in for Icehouse as a feature, but like you said, sometimes, it just doesn't work out, and we won't make a big fuss about it. If Mark decides that this patch should not go in as FFE, then let's close this bug and abandon the patches. Thierry, does that work for you? Thierry, as for the security issue itself, since we have been providing custom Neutron packages to customers that contain security fixes for Havana, and since the upstream version does not work with MidoNet, no one will be exposed to the security issues. This is not the way we want to provide the product, but it doesn't look like we have any choice at this moment, and hopefully this will change for Juno. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Confirmed Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From gerrit2 at review.openstack.org Mon Mar 24 07:06:00 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 24 Mar 2014 07:06:00 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77346 Log: commit 121114a0e0b78fa4ecb583efc92033dadd4ee07e Author: Daniel Gollub Date: Sat Feb 22 21:37:59 2014 +0100 Replace HTTPSConnection in zadara with Requests SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the SAN would not pass the verification. Old behaviour can be forced by using `san_ssl_insecure=True`. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b From gerrit2 at review.openstack.org Mon Mar 24 09:06:30 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 24 Mar 2014 09:06:30 +0000 Subject: [Openstack-security] [openstack/cinder] SecurityImpact review request change I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/77346 Log: commit 717d136a2ee6c1e173f21a0523ce5d6a93b37b61 Author: Daniel Gollub Date: Sat Feb 22 21:37:59 2014 +0100 Replace HTTPSConnection in zadara with Requests SSL Verification is from now on enabled by default. This changes the default behaviour and is the primary intention of this change: verify SSL certificates. This might break existing configuration/setups where the SSL certificate used by the SAN would not pass the verification. Old behaviour can be forced by using `san_ssl_insecure=True`. SecurityImpact DocImpact Partial-Bug: 1188189 Change-Id: I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b From thierry.carrez+lp at gmail.com Mon Mar 24 16:04:35 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 24 Mar 2014 16:04:35 -0000 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> Message-ID: <20140324160436.9863.84460.malone@wampee.canonical.com> OK, closing the security issue since this code is not actually used anywhere. ** Changed in: ossa Status: Confirmed => Won't Fix ** Information type changed from Public Security to Public -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress Status in neutron havana series: New Status in OpenStack Security Advisories: Won't Fix Bug description: When creating a security rule that specifies a remote security group (rather than a CIDR range), the Midonet plugin does not enforce this criterion. With an egress rule, for example, one of the criteria for a particular rule may be that only traffic to security group A will be allowed out. This criterion is ignored, and traffic will be allowed out regardless of the destination security group, provided that it conforms to the rule's other criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions From thierry.carrez+lp at gmail.com Tue Mar 25 12:32:20 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Tue, 25 Mar 2014 12:32:20 -0000 Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails to prevent ip netns exec References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com> Message-ID: <20140325123222.22276.34572.launchpad@wampee.canonical.com> ** Changed in: oslo Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1081795 Title: oslo.rootwrap IpFilter fails to prevent ip netns exec Status in Oslo - a Library of Common OpenStack Code: Fix Committed Bug description: This is an oslo.rootwrap bug. IpFilter is designed to allow any ip command, unless the second parameter is "netns" (in which case you only allow ip netns {list,add,delete}. The trick is it's trivial to work around this (just run 'ip -s netns exec'). Once that's fixed, Nova should update from using a CommandFilter to using the IpFilter for calling 'ip'. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo/+bug/1081795/+subscriptions From gerrit2 at review.openstack.org Tue Mar 25 16:33:48 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 25 Mar 2014 16:33:48 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit 7bf5492ddad613b99277452e470b60ac856d38d1 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From gerrit2 at review.openstack.org Tue Mar 25 16:34:53 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 25 Mar 2014 16:34:53 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82841 Log: commit 656e8a0966885fec49660253e6d95fbe8305f002 Author: David Ripton Date: Mon Mar 17 22:18:05 2014 -0400 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. Manually resolved one conflict in nova/virt/libvirt/imagebackend.py: snapshot_delete was removed in icehouse, but is still there in havana SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From 1287301 at bugs.launchpad.net Tue Mar 25 20:19:10 2014 From: 1287301 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 25 Mar 2014 20:19:10 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140325201912.22441.69996.launchpad@wampee.canonical.com> ** Changed in: python-keystoneclient Milestone: 0.7.0 => 0.7.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/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From 1174499 at bugs.launchpad.net Tue Mar 25 20:48:53 2014 From: 1174499 at bugs.launchpad.net (Dolph Mathews) Date: Tue, 25 Mar 2014 20:48:53 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20140325204855.9954.13044.launchpad@soybean.canonical.com> ** Changed in: python-keystoneclient Milestone: None => 0.8.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/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From 1174499 at bugs.launchpad.net Tue Mar 25 21:19:31 2014 From: 1174499 at bugs.launchpad.net (Dirk Mueller) Date: Tue, 25 Mar 2014 21:19:31 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20140325211931.6194.58206.malone@chaenomeles.canonical.com> Sorry, just came back from an extended leave, will refresh my patchset for this bug. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From nkinder at redhat.com Tue Mar 25 21:29:22 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 25 Mar 2014 14:29:22 -0700 Subject: [Openstack-security] SSL proxies vs. native SSL support Message-ID: <5331F532.4010306@redhat.com> Hi, The Security Guide currently recommends that SSL/TLS be used to protect the API endpoints (as it should). We specifically mention that SSL proxies should be used for this, as opposed to configuring SSL natively in the services themselves: http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html Is there any particular reason why we don't recommend configuring SSL/TLS natively in the services? It seems like that would be an ideal approach, as it eliminates the need for running proxies. It also keeps access to the unencrypted traffic closer to the actual services that need to access it, which is better from a security standpoint. I'm not sure that all of the integrated projects actually have working native SSL/TLS support, but I know that a number of them claim to have support. Shouldn't native support be the preferred recommendation from a security standpoint? Thanks, -NGK From bdpayne at acm.org Tue Mar 25 21:50:23 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Tue, 25 Mar 2014 14:50:23 -0700 Subject: [Openstack-security] SSL proxies vs. native SSL support In-Reply-To: <5331F532.4010306@redhat.com> References: <5331F532.4010306@redhat.com> Message-ID: A few thoughts come to mind: * For any production system, I suspect that you will be running a front end server in front of the actual endpoint. So, at a minimum, that server is where the TLS termination would happen. Depending on your setup, it may make more sense to terminate directly at that server (e.g., Apache or Nginx), or using a dedicated / purpose built TLS termination shim (e.g., Stud or Pound). * In many deployments, the control plane uses a different trust model than the external networks. Services on the control plane may not trust the same set of root certs that clients on the external network choose to trust. As such, the TLS setup would need to be different. Re-encrypting the connection at a proxy that sits on the boundary of the external network and the control plane serves to handle this use somewhat common use case. * In some cases it may be useful for purposes of load balancing, and auditing to be able to inspect the traffic at a proxy sitting between the external network and the control plane. * If there is no use case to inspect the traffic, and there is a common set of trusted root certs on both networks, then I see no problem just taking the TLS all the way back to the front-end server handling the endpoint (these would likely be deployed on the same machine... and could then just communicate the clear-text information over a unix socket or similar setup). If others agree, perhaps there is room to improve the wording in the book around this point? I do suspect that the setup described in the book is most common for real world deployments, but I don't see anything wrong with the other setup from a security standpoint. My two cents, -bryan On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder wrote: > Hi, > > The Security Guide currently recommends that SSL/TLS be used to protect > the API endpoints (as it should). We specifically mention that SSL > proxies should be used for this, as opposed to configuring SSL natively > in the services themselves: > > > http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html > > Is there any particular reason why we don't recommend configuring > SSL/TLS natively in the services? It seems like that would be an ideal > approach, as it eliminates the need for running proxies. It also keeps > access to the unencrypted traffic closer to the actual services that > need to access it, which is better from a security standpoint. > > I'm not sure that all of the integrated projects actually have working > native SSL/TLS support, but I know that a number of them claim to have > support. Shouldn't native support be the preferred recommendation from > a security standpoint? > > Thanks, > -NGK > > _______________________________________________ > 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 1274034 at bugs.launchpad.net Tue Mar 25 21:58:29 2014 From: 1274034 at bugs.launchpad.net (Kevin Bringard) Date: Tue, 25 Mar 2014 21:58:29 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140325215830.6059.12962.launchpad@chaenomeles.canonical.com> ** Tags added: havana-backport-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): Triaged Status in OpenStack Security Advisories: Invalid Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From nathanael.i.burton.work at gmail.com Wed Mar 26 02:17:14 2014 From: nathanael.i.burton.work at gmail.com (Nathanael Burton) Date: Tue, 25 Mar 2014 22:17:14 -0400 Subject: [Openstack-security] SSL proxies vs. native SSL support In-Reply-To: References: <5331F532.4010306@redhat.com> Message-ID: +1 to what Bryan said. I prefer to do SSL/TLS in things like Apache, nginx, etc because they typically pay much closer attention to SSL support, validation, and security (see all the changes to OpenStack services to switch out HTTPSConnection for requests). Additionally, performance of these are typically much better than SSL in Python (I've seen 5-10x or more improvements). Nate On Mar 25, 2014 5:54 PM, "Bryan D. Payne" wrote: > A few thoughts come to mind: > > * For any production system, I suspect that you will be running a front > end server in front of the actual endpoint. So, at a minimum, that server > is where the TLS termination would happen. Depending on your setup, it may > make more sense to terminate directly at that server (e.g., Apache or > Nginx), or using a dedicated / purpose built TLS termination shim (e.g., > Stud or Pound). > > * In many deployments, the control plane uses a different trust model than > the external networks. Services on the control plane may not trust the > same set of root certs that clients on the external network choose to > trust. As such, the TLS setup would need to be different. Re-encrypting > the connection at a proxy that sits on the boundary of the external network > and the control plane serves to handle this use somewhat common use case. > > * In some cases it may be useful for purposes of load balancing, and > auditing to be able to inspect the traffic at a proxy sitting between the > external network and the control plane. > > * If there is no use case to inspect the traffic, and there is a common > set of trusted root certs on both networks, then I see no problem just > taking the TLS all the way back to the front-end server handling the > endpoint (these would likely be deployed on the same machine... and could > then just communicate the clear-text information over a unix socket or > similar setup). > > If others agree, perhaps there is room to improve the wording in the book > around this point? I do suspect that the setup described in the book is > most common for real world deployments, but I don't see anything wrong with > the other setup from a security standpoint. > > My two cents, > -bryan > > > > On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder wrote: > >> Hi, >> >> The Security Guide currently recommends that SSL/TLS be used to protect >> the API endpoints (as it should). We specifically mention that SSL >> proxies should be used for this, as opposed to configuring SSL natively >> in the services themselves: >> >> >> http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html >> >> Is there any particular reason why we don't recommend configuring >> SSL/TLS natively in the services? It seems like that would be an ideal >> approach, as it eliminates the need for running proxies. It also keeps >> access to the unencrypted traffic closer to the actual services that >> need to access it, which is better from a security standpoint. >> >> I'm not sure that all of the integrated projects actually have working >> native SSL/TLS support, but I know that a number of them claim to have >> support. Shouldn't native support be the preferred recommendation from >> a security standpoint? >> >> Thanks, >> -NGK >> >> _______________________________________________ >> 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 gerrit2 at review.openstack.org Wed Mar 26 11:03:05 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 11:03:05 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit b6f41e2bc5640e98e863246dacd097ddb7705619 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From rcritten at redhat.com Wed Mar 26 13:18:05 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 26 Mar 2014 09:18:05 -0400 Subject: [Openstack-security] SSL proxies vs. native SSL support In-Reply-To: References: <5331F532.4010306@redhat.com> Message-ID: <5332D38D.6060601@redhat.com> Nathanael Burton wrote: > +1 to what Bryan said. I prefer to do SSL/TLS in things like Apache, > nginx, etc because they typically pay much closer attention to SSL > support, validation, and security (see all the changes to OpenStack > services to switch out HTTPSConnection for requests). Additionally, > performance of these are typically much better than SSL in Python (I've > seen 5-10x or more improvements). Should the effort then shift to running the services in these real web servers to take advantage of better SSL performance and not leave an exposed underbelly? I'm not sure I follow your reasoning on the HTTPConnection/requests change though. On the one hand these web servers pay closer attention to security and yet the OpenStack clients are replacing their insecure client library. So it seems to me that it is gaining attention. And really, that is where the big problem is anyway with some clients not doing any sort of validation now. Tempest takes a rather strange take on things too, providing a negative switch, disable_ssl_certificate_validation, but not providing a way to set the CA cert bundle. rob From gerrit2 at review.openstack.org Wed Mar 26 14:33:38 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 14:33:38 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit 473b885e4574c6d2893b5760dbef45664fcf886b Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From gerrit2 at review.openstack.org Wed Mar 26 14:51:18 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 14:51:18 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit 7b23f5f594bb329c3f75b9aac323f233304a7c89 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From gerrit2 at review.openstack.org Wed Mar 26 15:49:55 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 15:49:55 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit ccf34e208d4f6b9e5afd92a56f75bb43b4d29b75 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From bdpayne at acm.org Wed Mar 26 16:05:12 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 26 Mar 2014 09:05:12 -0700 Subject: [Openstack-security] SSL proxies vs. native SSL support In-Reply-To: <5332D38D.6060601@redhat.com> References: <5331F532.4010306@redhat.com> <5332D38D.6060601@redhat.com> Message-ID: > > Should the effort then shift to running the services in these real web > servers to take advantage of better SSL performance and not leave an > exposed underbelly? > Ideally yes, but that's a relatively big change for a relatively small gain. The "exposed underbelly" in this case isn't such a big deal in the grand scheme of things. Basically it is just transporting some information in the clear __within a local system__. > I'm not sure I follow your reasoning on the HTTPConnection/requests change > though. On the one hand these web servers pay closer attention to security > and yet the OpenStack clients are replacing their insecure client library. > So it seems to me that it is gaining attention. And really, that is where > the big problem is anyway with some clients not doing any sort of > validation now. > Requests is great, but it still doesn't get nearly the security / performance scrutiny that projects like Apache or Nginx receive. -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Wed Mar 26 16:52:20 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 16:52:20 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit 360f1e3c0a1e1facd834b41f4a2fb223ca8746d2 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From gerrit2 at review.openstack.org Wed Mar 26 17:11:16 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 17:11:16 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit 983bf8c91f78998b2d55f233e606d893b0bae2f0 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From gerrit2 at review.openstack.org Wed Mar 26 18:22:48 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 18:22:48 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit 673670fb3203f9cb4707d68ec5642d3018b870af Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From 1274034 at bugs.launchpad.net Wed Mar 26 18:16:31 2014 From: 1274034 at bugs.launchpad.net (Kevin Bringard) Date: Wed, 26 Mar 2014 18:16:31 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140326181631.22080.86616.malone@wampee.canonical.com> As another potential intermediate triage to this, we have added another spoofing rule to the spoof chains and call the spoof chain in the ingress rules. Effectively, if the DST IP address isn't the address we assigned to the VM, then drop it. In this scenario, the malicious VM can can still poison the ARP cache and effectively DoS the victim, but it shouldn't be able to see any of the victim's traffic as the packets headed to the malicious VM will get dropped at the hypervisor. I've attached a patch to the iptables_firewall.py from stable/havana which implements this. If folks don't disagree with this approach I'll submit the patch to be reviewed as well as look into getting it into icehouse (or maybe Juno, depending on if it's considered a new feature or bug fix). ** Patch added: "iptables_firewall.py.patch" https://bugs.launchpad.net/neutron/+bug/1274034/+attachment/4045291/+files/iptables_firewall.py.patch -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): Triaged Status in OpenStack Security Advisories: Invalid Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From gerrit2 at review.openstack.org Wed Mar 26 20:21:58 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 20:21:58 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit 0c13e1ad457df26cd627ced82c4d8a3ef49e297a Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From thierry.carrez+lp at gmail.com Wed Mar 26 20:41:49 2014 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 26 Mar 2014 20:41:49 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140326204155.30438.43075.launchpad@gac.canonical.com> ** Changed in: keystone Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From gerrit2 at review.openstack.org Wed Mar 26 22:21:21 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 22:21:21 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit 7fc3440cd3ad799a743797077aaffb0a3910d1e4 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From gerrit2 at review.openstack.org Wed Mar 26 22:28:50 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 22:28:50 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82841 Log: commit b5ea4aa9b982822262ac63b7943aee1fb7180567 Author: David Ripton Date: Mon Mar 17 22:18:05 2014 -0400 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. Manually resolved one conflict in nova/virt/libvirt/imagebackend.py: snapshot_delete was removed in icehouse, but is still there in havana SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From gerrit2 at review.openstack.org Wed Mar 26 22:58:47 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 22:58:47 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82841 Log: commit a84952c538a9f17bb3a1e6e553bbe60e5697d868 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Closes-bug: #1221190 Conflicts: nova/virt/libvirt/imagebackend.py Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a (cherry picked from commit 7fc3440cd3ad799a743797077aaffb0a3910d1e4) From gerrit2 at review.openstack.org Wed Mar 26 23:38:11 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 26 Mar 2014 23:38:11 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82841 Log: commit 3ebf229abcea0c79cda0be03c7bb27d136c1f725 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Closes-bug: #1221190 Conflicts: nova/virt/libvirt/imagebackend.py Manual tweaks to some mocking in test_imagebackend.py Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a (cherry picked from commit 7fc3440cd3ad799a743797077aaffb0a3910d1e4) From 1188189 at bugs.launchpad.net Thu Mar 27 03:50:14 2014 From: 1188189 at bugs.launchpad.net (John Griffith) Date: Thu, 27 Mar 2014 03:50:14 -0000 Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com> Message-ID: <20140327035018.30241.59585.launchpad@gac.canonical.com> ** Changed in: cinder Milestone: icehouse-rc1 => None -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1188189 Title: Some server-side 'SSL' communication fails to check certificates (use of HTTPSConnection) Status in Cinder: In Progress Status in OpenStack Identity (Keystone): Fix Released Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Fix Released Status in Python client library for Keystone: Fix Released Status in OpenStack Object Storage (Swift): Invalid Bug description: Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection objects. In Python 2.x those do not perform CA checks so client connections are vulnerable to MiM attacks. """ The following files use httplib.HTTPSConnection : keystone/middleware/s3_token.py keystone/middleware/ec2_token.py keystone/common/bufferedhttp.py vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py AFAICT HTTPSConnection does not validate server certificates and should be avoided. This is fixed in Python 3, however in 2.X no validation occurs. I suspect this is also applicable to most OpenStack modules that make HTTPS client calls. Similar problems were found in ovirt: https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533) With solutions for ovirt: http://gerrit.ovirt.org/#/c/7209/ http://gerrit.ovirt.org/#/c/7249/ """ To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1188189/+subscriptions From mathieu.rohon at gmail.com Thu Mar 27 09:13:44 2014 From: mathieu.rohon at gmail.com (Mathieu Rohon) Date: Thu, 27 Mar 2014 09:13:44 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140327091344.5806.39600.malone@chaenomeles.canonical.com> this looks like a good patch for a backport in havana, but if a VM clains that it owns the gateway IP, other VMs of the network will loose connectivity to other networks. I think that the ebtablemanager proposed by edouard is the long term solution. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): Triaged Status in OpenStack Security Advisories: Invalid Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From gerrit2 at review.openstack.org Thu Mar 27 09:59:11 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Mar 2014 09:59:11 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit d6c1fca9631ce6e4d3e30da18bd5de1c1a14e62d Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Closes-bug: #1221190 From gerrit2 at review.openstack.org Thu Mar 27 13:12:20 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Mar 2014 13:12:20 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit a61a9487e020c2032639e3745e5f28e98bf32121 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Co-atuhored-by: Nikola Dipanov Closes-bug: #1221190 Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a From 1287301 at bugs.launchpad.net Thu Mar 27 13:12:04 2014 From: 1287301 at bugs.launchpad.net (Dolph Mathews) Date: Thu, 27 Mar 2014 13:12:04 -0000 Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com> Message-ID: <20140327131206.5581.64549.launchpad@chaenomeles.canonical.com> ** Changed in: python-keystoneclient Milestone: 0.7.1 => None -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1287301 Title: Keystone client token cache doesn't respect revoked tokens Status in OpenStack Security Advisories: Invalid Status in Python client library for Keystone: In Progress Bug description: If we'll enable caching for keystoneclient tokens we'll be able to use tokens that are already revoked if they are present in cache: https://github.com/openstack/python- keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831 steps to recreate: 1) get a token 2) use it to make a request via keystoneclient using default properties (thus it will be cached) 3) delete the token 4) use the token to make another request via keystoneclient expected result: the token should not work (HTTP 401) actual result: the token still works To manage notifications about this bug go to: https://bugs.launchpad.net/ossa/+bug/1287301/+subscriptions From gerrit2 at review.openstack.org Thu Mar 27 13:22:02 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Mar 2014 13:22:02 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit fc3080034bf996291e222b8809c7d371547dbe39 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Co-atuhored-by: Nikola Dipanov Closes-bug: #1221190 Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a From gerrit2 at review.openstack.org Thu Mar 27 13:25:39 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Mar 2014 13:25:39 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit 9c6218b3faa7b4cf9b477ca9fd64be5a402a994d Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Co-authored-by: Nikola Dipanov Closes-bug: #1221190 Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a From cristian.fiorentino at intel.com Thu Mar 27 13:26:12 2014 From: cristian.fiorentino at intel.com (Fiorentino, Cristian) Date: Thu, 27 Mar 2014 13:26:12 +0000 Subject: [Openstack-security] Security Analysis for new Blueprints Message-ID: Dear All, Probably you are already aware that Nova is moving towards reviewing Blueprints using Gerrit, and proposing a new template with several sections as you can find here: https://github.com/openstack/nova-specs/blob/master/specs/template.rst On the other side, currently there is the effort being held by OSSG for performing a threat model analysis for OpenStack, which is great in my opinion and would lead to a baseline threat model analysis. But new features/Blueprints are being integrated all the time, and with them new potential Security risks at design time. (Please let me know if I am wrong, but I am not aware of required Security analysis for new Blueprints besides what the reviewers may identify during the approval process.) That said, I was wondering if it would be worth to push the inclusion of a "Security impact" section as part of the Blueprints definitions; and probably to start with the new Nova template approach. I am not talking about requesting a detailed threat model analysis at the Blueprint definition stage, but to document at least high level Security implications that the Blueprint owner could identify for leveraging Security analysis/reviews in earlier stages of features/components definitions. Any thoughts appreciated. Thanks and Regards. Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1274034 at bugs.launchpad.net Thu Mar 27 14:03:28 2014 From: 1274034 at bugs.launchpad.net (Kevin Bringard) Date: Thu, 27 Mar 2014 14:03:28 -0000 Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall anti-spoofing does not prevent ARP poisoning References: <20140129101504.12361.90017.malonedeb@gac.canonical.com> Message-ID: <20140327140328.30533.25134.malone@gac.canonical.com> Thanks for the feedback Mathieu, and I absolutely agree. It's meant to be a mitigation approach as it only filters L3 and prevents the malicious VM from actually gathering any data. They can still DoS the L2 segment by hijacking traffic destined for the gateway (or any other IP for that matter), and L2 filtering (which the ebtables approach would accomplish) is the only way to stop that aspect of it. There are also a few other things we're looking at to help beef up this area. One thing would be working to implement more robust port-security like features in the ovs-plugin-agent. As of OVS 1.10 they've implemented a drop_spoofed_arp flow action, which, while wouldn't necessarily address this specific issue, probably couldn't hurt to put on ports. Regardless, we're doing some more testing in house to make sure it doesn't have any unintended effects, but assuming that all goes well I'll work on getting this patch into havana/icehouse. The processing overhead of one more chain should have a miniscule effect on throughput, and it can't hurt to have another validation that the packets are indeed coming and going to the correct place. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1274034 Title: Neutron firewall anti-spoofing does not prevent ARP poisoning Status in OpenStack Neutron (virtual network service): Triaged Status in OpenStack Security Advisories: Invalid Bug description: The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning. When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature: - no-mac-spoofing - no-ip-spoofing - no-arp-spoofing - nova-no-nd-reflection - allow-dhcp-server Actually, the neutron firewall driver 'iptabes_firawall' handles only MAC and IP anti-spoofing rules. This is a security vulnerability, especially on shared networks. Reproduce an ARP cache poisoning and man in the middle: - Create a private network/subnet 10.0.0.0/24 - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4) - Log on VM1 and install ettercap [1] - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:' - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2] - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1 [1] http://ettercap.github.io/ettercap/ [2] http://paste.openstack.org/show/62112/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1274034/+subscriptions From gerrit2 at review.openstack.org Thu Mar 27 14:22:19 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Mar 2014 14:22:19 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82840 Log: commit dc8de426066969a3f0624fdc2a7b29371a2d55bf Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Co-authored-by: Nikola Dipanov Closes-bug: #1221190 Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a From rcritten at redhat.com Thu Mar 27 14:49:49 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 27 Mar 2014 10:49:49 -0400 Subject: [Openstack-security] SSL proxies vs. native SSL support In-Reply-To: References: <5331F532.4010306@redhat.com> <5332D38D.6060601@redhat.com> Message-ID: <53343A8D.3040608@redhat.com> Bryan D. Payne wrote: > Should the effort then shift to running the services in these real > web servers to take advantage of better SSL performance and not > leave an exposed underbelly? > > > Ideally yes, but that's a relatively big change for a relatively small > gain. The "exposed underbelly" in this case isn't such a big deal in > the grand scheme of things. Basically it is just transporting some > information in the clear __within a local system__. IMHO passwords should never be in the clear. > I'm not sure I follow your reasoning on the HTTPConnection/requests > change though. On the one hand these web servers pay closer > attention to security and yet the OpenStack clients are replacing > their insecure client library. So it seems to me that it is gaining > attention. And really, that is where the big problem is anyway with > some clients not doing any sort of validation now. > > > Requests is great, but it still doesn't get nearly the security / > performance scrutiny that projects like Apache or Nginx receive. Ok, not sure how that is relevant, though scary, as the client is common regardless of the SSL backend. rob From gerrit2 at review.openstack.org Thu Mar 27 14:58:11 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Mar 2014 14:58:11 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I10ec97c6e502c9799672cf2df50e3a0f65b679a9 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/83413 Log: commit c21acacad9220e27b0fe718599eba40f44187f5a Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Conflicts: nova/virt/libvirt/imagebackend.py Manual tweaks to some mocking in test_imagebackend.py Change-Id: I10ec97c6e502c9799672cf2df50e3a0f65b679a9 Co-authored-by: Nikola Dipanov Closes-bug: #1221190 From gerrit2 at review.openstack.org Thu Mar 27 15:01:30 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 27 Mar 2014 15:01:30 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I2016efdb3f49a44ec4d677ac596eacc97871f30a Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/82841 Log: commit 25e761acd56d4c820273fc0245ada06c500c1637 Author: David Ripton Date: Tue Jan 28 16:38:51 2014 -0500 Persist image format to a file, to prevent attacks based on changing it The attack is based on creating a raw image that looks like a qcow2 image, and taking advantage of the code that used 'qemu-img info' to autodetect the image format. Now we store the image format to a 'disk.info' file, for Qcow2 and Raw images, and only autodetect for images that have never been written to that file. SecurityImpact Conflicts: nova/virt/libvirt/imagebackend.py Manual tweaks to some mocking in test_imagebackend.py Change-Id: I2016efdb3f49a44ec4d677ac596eacc97871f30a Co-authored-by: Nikola Dipanov Closes-bug: #1221190 From d.w.chadwick at kent.ac.uk Thu Mar 27 15:09:38 2014 From: d.w.chadwick at kent.ac.uk (David Chadwick) Date: Thu, 27 Mar 2014 15:09:38 +0000 Subject: [Openstack-security] Security Analysis for new Blueprints In-Reply-To: References: Message-ID: <53343F32.8050807@kent.ac.uk> Hi Cristian I think it is a very good idea to have a security impact section as part of all Blueprints, but I am not sure how this procedure would work in practise, since anyone can write a Blueprint, and there is no vetting of them before they are published. I think some revised procedures would need to be agreed as a minimum before this could become a reality regards David On 27/03/2014 13:26, Fiorentino, Cristian wrote: > Dear All, > > > > Probably you are already aware that Nova is moving towards reviewing > Blueprints using Gerrit, and proposing a new template with several > sections as you can find here: > > https://github.com/openstack/nova-specs/blob/master/specs/template.rst > > > > On the other side, currently there is the effort being held by OSSG for > performing a threat model analysis for OpenStack, which is great in my > opinion and would lead to a baseline threat model analysis. > > But new features/Blueprints are being integrated all the time, and with > them new potential Security risks at design time. > > (Please let me know if I am wrong, but I am not aware of required > Security analysis for new Blueprints besides what the reviewers may > identify during the approval process.) > > > > That said, I was wondering if it would be worth to push the inclusion of > a “Security impact” section as part of the Blueprints definitions; and > probably to start with the new Nova template approach. > > I am not talking about requesting a detailed threat model analysis at > the Blueprint definition stage, but to document at least high level > Security implications that the Blueprint owner could identify for > leveraging Security analysis/reviews in earlier stages of > features/components definitions. > > > > Any thoughts appreciated. > > > > Thanks and Regards. > > Cristian. > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > From cristian.fiorentino at intel.com Thu Mar 27 15:15:53 2014 From: cristian.fiorentino at intel.com (Fiorentino, Cristian) Date: Thu, 27 Mar 2014 15:15:53 +0000 Subject: [Openstack-security] Security Analysis for new Blueprints In-Reply-To: References: Message-ID: Bryan, thanks much for the comments. I was also bringing this up now because the new Nova template is still being modified and under review; so it could be a good timing for proposing something there and probably to be ready for Juno. But if there is a related approach work in progress, probably then there is the need to grow the template in the future. If you may point me to any related effort, I would be happy to offer some help here. Regards. Cristian. From: bdpayne at gmail.com [mailto:bdpayne at gmail.com] On Behalf Of Bryan D. Payne Sent: Thursday, March 27, 2014 11:55 AM To: Fiorentino, Cristian Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] Security Analysis for new Blueprints Thanks for bringing this up. I completely agree that it would be nice to have a security impact section for the new blueprints. Ideally we could wire that in to notify this mailing list that a security review is needed. It may also be worth noting that OSSG has also been looking at some security design guidelines. If there's room to grow the template in the future, this could be a nice way to encourage people to think about key security aspects in their design (e.g., perhaps be going through a basic checklist of security considerations). This is still a work in progress, so it's not quite ready for prime time. But I just wanted to make sure that you were aware that we having been thinking about such things :-) Cheers, -bryan On Thu, Mar 27, 2014 at 6:26 AM, Fiorentino, Cristian wrote: Dear All, Probably you are already aware that Nova is moving towards reviewing Blueprints using Gerrit, and proposing a new template with several sections as you can find here: https://github.com/openstack/nova-specs/blob/master/specs/template.rst On the other side, currently there is the effort being held by OSSG for performing a threat model analysis for OpenStack, which is great in my opinion and would lead to a baseline threat model analysis. But new features/Blueprints are being integrated all the time, and with them new potential Security risks at design time. (Please let me know if I am wrong, but I am not aware of required Security analysis for new Blueprints besides what the reviewers may identify during the approval process.) That said, I was wondering if it would be worth to push the inclusion of a "Security impact" section as part of the Blueprints definitions; and probably to start with the new Nova template approach. I am not talking about requesting a detailed threat model analysis at the Blueprint definition stage, but to document at least high level Security implications that the Blueprint owner could identify for leveraging Security analysis/reviews in earlier stages of features/components definitions. Any thoughts appreciated. Thanks and Regards. Cristian. _______________________________________________ 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: 6708 bytes Desc: not available URL: From bdpayne at acm.org Thu Mar 27 15:33:03 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 27 Mar 2014 08:33:03 -0700 Subject: [Openstack-security] Security Analysis for new Blueprints In-Reply-To: References: Message-ID: > > I was also bringing this up now because the new Nova template is still > being modified and under review; so it could be a good timing for proposing > something there and probably to be ready for Juno. > > But if there is a related approach work in progress, probably then there > is the need to grow the template in the future. > I still think it would be valuable to get something about security review / security impact / etc into the first template. Where is this review process happening? I'd be happy to chime in over there. If you may point me to any related effort, I would be happy to offer some > help here. > This is the current work in progress that I referenced: https://wiki.openstack.org/wiki/Security/Guidelines -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.fiorentino at intel.com Thu Mar 27 15:52:14 2014 From: cristian.fiorentino at intel.com (Fiorentino, Cristian) Date: Thu, 27 Mar 2014 15:52:14 +0000 Subject: [Openstack-security] Security Analysis for new Blueprints In-Reply-To: References: Message-ID: Proposed changes to the new Nova Blueprint template is happening directly in Gerrit against the actual template: https://github.com/openstack/nova-specs/blob/master/specs/template.rst You may find several proposed changes in here: https://review.openstack.org/#/q/nova-specs,n,z Probably we could directly submit a proposal for a new "Security impact" section (as it fits with current template); including a short explanation and providing some links such as the Security guidelines provided below. Regards. Cristian. From: bdpayne at gmail.com [mailto:bdpayne at gmail.com] On Behalf Of Bryan D. Payne Sent: Thursday, March 27, 2014 12:33 PM To: Fiorentino, Cristian Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] Security Analysis for new Blueprints I was also bringing this up now because the new Nova template is still being modified and under review; so it could be a good timing for proposing something there and probably to be ready for Juno. But if there is a related approach work in progress, probably then there is the need to grow the template in the future. I still think it would be valuable to get something about security review / security impact / etc into the first template. Where is this review process happening? I'd be happy to chime in over there. If you may point me to any related effort, I would be happy to offer some help here. This is the current work in progress that I referenced: https://wiki.openstack.org/wiki/Security/Guidelines -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: 6708 bytes Desc: not available URL: From bdpayne at acm.org Thu Mar 27 16:29:29 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 27 Mar 2014 09:29:29 -0700 Subject: [Openstack-security] Security Analysis for new Blueprints In-Reply-To: References: Message-ID: I hope you don't mind, I went ahead and proposed a change: https://review.openstack.org/83467 Let me know what you think. Cheers, -bryan On Thu, Mar 27, 2014 at 8:52 AM, Fiorentino, Cristian < cristian.fiorentino at intel.com> wrote: > Proposed changes to the new Nova Blueprint template is happening directly > in Gerrit against the actual template: > > https://github.com/openstack/nova-specs/blob/master/specs/template.rst > > > > You may find several proposed changes in here: > > https://review.openstack.org/#/q/nova-specs,n,z > > > > Probably we could directly submit a proposal for a new "Security impact" > section (as it fits with current template); including a short explanation > and providing some links such as the Security guidelines provided below. > > > > Regards. > > Cristian. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.fiorentino at intel.com Thu Mar 27 16:44:16 2014 From: cristian.fiorentino at intel.com (Fiorentino, Cristian) Date: Thu, 27 Mar 2014 16:44:16 +0000 Subject: [Openstack-security] Security Analysis for new Blueprints In-Reply-To: References: Message-ID: +1 :) From: bdpayne at gmail.com [mailto:bdpayne at gmail.com] On Behalf Of Bryan D. Payne Sent: Thursday, March 27, 2014 1:29 PM To: Fiorentino, Cristian Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] Security Analysis for new Blueprints I hope you don't mind, I went ahead and proposed a change: https://review.openstack.org/83467 Let me know what you think. Cheers, -bryan On Thu, Mar 27, 2014 at 8:52 AM, Fiorentino, Cristian > wrote: Proposed changes to the new Nova Blueprint template is happening directly in Gerrit against the actual template: https://github.com/openstack/nova-specs/blob/master/specs/template.rst You may find several proposed changes in here: https://review.openstack.org/#/q/nova-specs,n,z Probably we could directly submit a proposal for a new "Security impact" section (as it fits with current template); including a short explanation and providing some links such as the Security guidelines provided below. Regards. Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Thu Mar 27 17:16:33 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Thu, 27 Mar 2014 10:16:33 -0700 Subject: [Openstack-security] No OSSG IRC meeting today Message-ID: Sorry for the late notice, but I have a conflict for today's OSSG IRC meeting. I haven't been able to find a replacement to lead the meeting, so I'm going to go ahead and cancel this week's meeting. If you have business to discuss, please use the mailing list. Otherwise, we'll return to our regularly scheduled meetings next week. Cheers, -bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Thu Mar 27 17:13:33 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 27 Mar 2014 17:13:33 -0000 Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set insecure file permissions References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com> Message-ID: <20140327171336.6092.67882.launchpad@chaenomeles.canonical.com> ** Changed in: ossn Status: In Progress => Confirmed ** Changed in: ossn Assignee: Nathan Kinder (nkinder) => (unassigned) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260679 Title: Multiple drivers set insecure file permissions Status in Cinder: In Progress Status in OpenStack Security Notes: Confirmed Bug description: GPFS from various places calls "chmod 666" as root: ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', path, run_as_root=True) ./cinder/volume/drivers/gpfs.py: self._execute('chmod', '666', vol_path, run_as_root=True) the Huawei driver sets 777 permissions as root on some files: ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True) the Scality driver sets 666 permissions on all volumes: cinder/volume/drivers/scality.py:     def _create_file(self, path, size):         with open(path, "ab") as f:             f.truncate(size)         os.chmod(path, 0o666) Similarly, the NFS and NEXENTA driver have an implementation of def _set_rw_permissions_for_all() that is being called on all newly created volumes. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1260679/+subscriptions From d.w.chadwick at kent.ac.uk Thu Mar 27 17:32:54 2014 From: d.w.chadwick at kent.ac.uk (David Chadwick) Date: Thu, 27 Mar 2014 17:32:54 +0000 Subject: [Openstack-security] Security Analysis for new Blueprints In-Reply-To: References: <53343F32.8050807@kent.ac.uk> Message-ID: <533460C6.7070501@kent.ac.uk> All Internet RFCs have to have a Security Considerations section, even if they say nothing. If we could get something similar added to blueprints and code changes by all the different OpenStack projects, this would be a good first step. Even if initially their content was only added on a best efforts basis by the author, and there was not any requirement for them to be checked by the OSSG, nevertheless it would establish a security conscious mode of working by authors, and would make it easier to introduce checking and sign off by the OSSG at a later stage. This could be a topic for discussion in Atlanta. regards David On 27/03/2014 15:21, Bryan D. Payne wrote: > I would love to get to the point where we could do the following: > > 1) flag a blueprint or code change as having a security impact > 2) have gerrit gate on accepting that artifact until a designated > security person performs the review and provides a +1 > > (1) is pretty straightforward to setup. (2) is harder. Not so much > because of gerrit (although I don't know how possible that would be with > gerrit), but because we would really need a set of core security > reviewers for each project taking this approach. I think this is > achievable, but the timeline is less clear to me. Part of it will > depend on the project's willingness to go down this path, of course. If > Nova wants to explore this, I'd be happy to have that discussion. If > not, doing (1) still does provide some value as it allows people to at > least stay aware of the security relevant changes in the system (of > course with the restriction that these are largely self-reported). > > -bryan > > > > On Thu, Mar 27, 2014 at 8:09 AM, David Chadwick > wrote: > > Hi Cristian > > I think it is a very good idea to have a security impact section as part > of all Blueprints, but I am not sure how this procedure would work in > practise, since anyone can write a Blueprint, and there is no vetting of > them before they are published. I think some revised procedures would > need to be agreed as a minimum before this could become a reality > > regards > > David > > On 27/03/2014 13:26, Fiorentino, Cristian wrote: > > Dear All, > > > > > > > > Probably you are already aware that Nova is moving towards reviewing > > Blueprints using Gerrit, and proposing a new template with several > > sections as you can find here: > > > > https://github.com/openstack/nova-specs/blob/master/specs/template.rst > > > > > > > > On the other side, currently there is the effort being held by > OSSG for > > performing a threat model analysis for OpenStack, which is great in my > > opinion and would lead to a baseline threat model analysis. > > > > But new features/Blueprints are being integrated all the time, and > with > > them new potential Security risks at design time. > > > > (Please let me know if I am wrong, but I am not aware of required > > Security analysis for new Blueprints besides what the reviewers may > > identify during the approval process.) > > > > > > > > That said, I was wondering if it would be worth to push the > inclusion of > > a “Security impact” section as part of the Blueprints definitions; and > > probably to start with the new Nova template approach. > > > > I am not talking about requesting a detailed threat model analysis at > > the Blueprint definition stage, but to document at least high level > > Security implications that the Blueprint owner could identify for > > leveraging Security analysis/reviews in earlier stages of > > features/components definitions. > > > > > > > > Any thoughts appreciated. > > > > > > > > Thanks and Regards. > > > > Cristian. > > > > > > > > _______________________________________________ > > Openstack-security mailing list > > Openstack-security at lists.openstack.org > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > From gerrit2 at review.openstack.org Fri Mar 28 00:14:28 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 28 Mar 2014 00:14:28 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I676e4235c4a4774f54ffef790a6441982281a612 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/83629 Log: commit 6f7e9a635b27670d48452081becba05d4a97ca92 Author: Brant Knudson Date: Thu Mar 27 19:10:10 2014 -0500 Configurable token hash algorithm Tokens were always hashed with md5. This change allows tokens to be hashed with sha256 (or any other algorithm supported by the keystoneclient token hash function). This is for security hardening. There's a new configuration option 'hash_algorithm' in the [token] section. If this is not set then the server's behavior is the same as before. If it's set to a hash algorithm (such as 'sha256'), then PKI tokens will be hashed using that algorithm. Also, the configured hash algorithm is set on the revocation list. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: I676e4235c4a4774f54ffef790a6441982281a612 From gerrit2 at review.openstack.org Fri Mar 28 00:15:43 2014 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 28 Mar 2014 00:15:43 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Iafe3c975d59818c8f362647f7ea5149a03deee47 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/80401 Log: commit 04c74b30d25e3a02aa25b30d1b6145574dbd9c06 Author: Brant Knudson Date: Thu Mar 27 19:10:10 2014 -0500 Configurable token hash algorithm Tokens were always hashed with md5. This change allows tokens to be hashed with sha256 (or any other algorithm supported by the keystoneclient token hash function). This is for security hardening. There's a new configuration option 'hash_algorithm' in the [token] section. If this is not set then the server's behavior is the same as before. If it's set to a hash algorithm (such as 'sha256'), then PKI tokens will be hashed using that algorithm. Also, the configured hash algorithm is set on the revocation list. SecurityImpact DocImpact Closes-Bug: #1174499 Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47 From 1174499 at bugs.launchpad.net Fri Mar 28 00:14:25 2014 From: 1174499 at bugs.launchpad.net (OpenStack Infra) Date: Fri, 28 Mar 2014 00:14:25 -0000 Subject: [Openstack-security] [Bug 1174499] Fix proposed to keystone (master) References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20140328001425.30599.48304.malone@gac.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/83629 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1174499 Title: Keystone token hashing is MD5 Status in OpenStack Identity (Keystone): In Progress Status in Python client library for Keystone: In Progress Bug description: https://github.com/openstack/python- keystoneclient/blob/master/keystoneclient/common/cms.py def cms_hash_token(token_id): """ return: for ans1_token, returns the hash of the passed in token otherwise, returns what it was passed in. """ if token_id is None: return None if is_ans1_token(token_id): hasher = hashlib.md5() hasher.update(token_id) return hasher.hexdigest() else: return token_id MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256. Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1174499/+subscriptions From dstanek at dstanek.com Fri Mar 28 01:07:59 2014 From: dstanek at dstanek.com (David Stanek) Date: Fri, 28 Mar 2014 01:07:59 -0000 Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE References: <20130503065127.14958.89453.malonedeb@gac.canonical.com> Message-ID: <20140328010759.22113.72381.malone@wampee.canonical.com> How should we proceed here? The patch submitted for this just hard codes the value of PASSLIB_MAX_PASSWORD_SIZE to 4096. Is that the correct thing to do or should we allow it to be configured? If it can be configured do we need to have boundaries we can validate against (like a lower bounds of 1024 and and upper bounds of 16384)? -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175905 Title: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE Status in OpenStack Identity (Keystone): Confirmed Bug description: Grant Murphy originally reported: * Usage of passlib The keystone server does not appear to sanitize the environment when starting. This means that an unintended value can be set for PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 4096 and potentially cause an unhandled passlib.exc.PasswordSizeError. We should ensure sensible defaults are applied here prior to loading passlib. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175905/+subscriptions From 1175905 at bugs.launchpad.net Fri Mar 28 17:56:08 2014 From: 1175905 at bugs.launchpad.net (Dolph Mathews) Date: Fri, 28 Mar 2014 17:56:08 -0000 Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE References: <20130503065127.14958.89453.malonedeb@gac.canonical.com> Message-ID: <20140328175608.5773.95291.malone@chaenomeles.canonical.com> I would assume it should be end-user configurable (which it is today), but that seems to be completely at odds with the bug report. I can't really think of a simpler solution than the one proposed above; I'd appreciate feedback from Grant Murphy on the patch itself. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175905 Title: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE Status in OpenStack Identity (Keystone): Confirmed Bug description: Grant Murphy originally reported: * Usage of passlib The keystone server does not appear to sanitize the environment when starting. This means that an unintended value can be set for PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 4096 and potentially cause an unhandled passlib.exc.PasswordSizeError. We should ensure sensible defaults are applied here prior to loading passlib. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175905/+subscriptions From nkinder at redhat.com Sat Mar 29 00:01:13 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 28 Mar 2014 17:01:13 -0700 Subject: [Openstack-security] OSSN repository is live! Message-ID: <53360D49.8050102@redhat.com> Hi, I'm happy to announce that our new OSSN git repository is live! I have pre-populated it with all of the previously published Security Notes as well as templates to aid in the creation of new Security Notes. The repository is located here: http://git.openstack.org/cgit/openstack/openstack-security-notes/ Now that we have this repository, we will use the normal Gerrit workflow [1] for reviewing OSSNs. Bryan Payne, Rob Clark, and myself have +2 review permission to start with. We can certainly discuss making changes to this, but it should be fine for now. It might be a good item for us to discuss in Atlanta at the Summit. Publishing of OSSNs is still a manual process. I would like to add automatic publishing jobs, which is something that I will be looking into. We can also potentially add check and gate jobs for things such as formatting if desired. I have updated the OSSN process wiki page [2] with details of the new review procedures. Thanks, -NGK [1] https://wiki.openstack.org/wiki/Gerrit_Workflow [2] https://wiki.openstack.org/wiki/Security/Security_Note_Process From sriram at sriramhere.com Sat Mar 29 02:25:31 2014 From: sriram at sriramhere.com (Sriram Subramanian) Date: Fri, 28 Mar 2014 19:25:31 -0700 Subject: [Openstack-security] OSSN repository is live! In-Reply-To: <53360D49.8050102@redhat.com> References: <53360D49.8050102@redhat.com> Message-ID: Great, this is awesome! thanks, -Sriram On Fri, Mar 28, 2014 at 5:01 PM, Nathan Kinder wrote: > Hi, > > I'm happy to announce that our new OSSN git repository is live! I have > pre-populated it with all of the previously published Security Notes as > well as templates to aid in the creation of new Security Notes. The > repository is located here: > > http://git.openstack.org/cgit/openstack/openstack-security-notes/ > > Now that we have this repository, we will use the normal Gerrit workflow > [1] for reviewing OSSNs. Bryan Payne, Rob Clark, and myself have +2 > review permission to start with. We can certainly discuss making > changes to this, but it should be fine for now. It might be a good item > for us to discuss in Atlanta at the Summit. > > Publishing of OSSNs is still a manual process. I would like to add > automatic publishing jobs, which is something that I will be looking > into. We can also potentially add check and gate jobs for things such > as formatting if desired. > > I have updated the OSSN process wiki page [2] with details of the new > review procedures. > > Thanks, > -NGK > > [1] https://wiki.openstack.org/wiki/Gerrit_Workflow > [2] https://wiki.openstack.org/wiki/Security/Security_Note_Process > > _______________________________________________ > 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 Sat Mar 29 02:34:15 2014 From: bdpayne at acm.org (Bryan D. Payne) Date: Fri, 28 Mar 2014 19:34:15 -0700 Subject: [Openstack-security] OSSN repository is live! In-Reply-To: <53360D49.8050102@redhat.com> References: <53360D49.8050102@redhat.com> Message-ID: Great news, thanks for setting this up! -bryan On Fri, Mar 28, 2014 at 5:01 PM, Nathan Kinder wrote: > Hi, > > I'm happy to announce that our new OSSN git repository is live! I have > pre-populated it with all of the previously published Security Notes as > well as templates to aid in the creation of new Security Notes. The > repository is located here: > > http://git.openstack.org/cgit/openstack/openstack-security-notes/ > > Now that we have this repository, we will use the normal Gerrit workflow > [1] for reviewing OSSNs. Bryan Payne, Rob Clark, and myself have +2 > review permission to start with. We can certainly discuss making > changes to this, but it should be fine for now. It might be a good item > for us to discuss in Atlanta at the Summit. > > Publishing of OSSNs is still a manual process. I would like to add > automatic publishing jobs, which is something that I will be looking > into. We can also potentially add check and gate jobs for things such > as formatting if desired. > > I have updated the OSSN process wiki page [2] with details of the new > review procedures. > > Thanks, > -NGK > > [1] https://wiki.openstack.org/wiki/Gerrit_Workflow > [2] https://wiki.openstack.org/wiki/Security/Security_Note_Process > > _______________________________________________ > 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 malini.k.bhandaru at intel.com Sat Mar 29 23:20:29 2014 From: malini.k.bhandaru at intel.com (Bhandaru, Malini K) Date: Sat, 29 Mar 2014 23:20:29 +0000 Subject: [Openstack-security] OSSN repository is live! In-Reply-To: <53360D49.8050102@redhat.com> References: <53360D49.8050102@redhat.com> Message-ID: Congratulations Nathan! Good work! Glad you will be exploring automated formating as a gate job. I know we plan to cover OSSNs in more detail in the security guide, but it would be good as a first pass for completeness to have an OSSN chapter in the OpenStack security guide that lists links to all published OSSNs (just a fetch, format, and include in doc) each time the build happens. Cheers Malini -----Original Message----- From: Nathan Kinder [mailto:nkinder at redhat.com] Sent: Friday, March 28, 2014 5:01 PM To: openstack-security at lists.openstack.org Subject: [Openstack-security] OSSN repository is live! Hi, I'm happy to announce that our new OSSN git repository is live! I have pre-populated it with all of the previously published Security Notes as well as templates to aid in the creation of new Security Notes. The repository is located here: http://git.openstack.org/cgit/openstack/openstack-security-notes/ Now that we have this repository, we will use the normal Gerrit workflow [1] for reviewing OSSNs. Bryan Payne, Rob Clark, and myself have +2 review permission to start with. We can certainly discuss making changes to this, but it should be fine for now. It might be a good item for us to discuss in Atlanta at the Summit. Publishing of OSSNs is still a manual process. I would like to add automatic publishing jobs, which is something that I will be looking into. We can also potentially add check and gate jobs for things such as formatting if desired. I have updated the OSSN process wiki page [2] with details of the new review procedures. Thanks, -NGK [1] https://wiki.openstack.org/wiki/Gerrit_Workflow [2] https://wiki.openstack.org/wiki/Security/Security_Note_Process _______________________________________________ Openstack-security mailing list Openstack-security at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security From nkinder at redhat.com Sat Mar 29 23:36:53 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Sat, 29 Mar 2014 16:36:53 -0700 Subject: [Openstack-security] OSSN repository is live! In-Reply-To: References: <53360D49.8050102@redhat.com> Message-ID: <53375915.1040304@redhat.com> On 03/29/2014 04:20 PM, Bhandaru, Malini K wrote: > Congratulations Nathan! Good work! > Glad you will be exploring automated formating as a gate job. > I know we plan to cover OSSNs in more detail in the security guide, but it would be good as a first pass for completeness to have an OSSN chapter in the OpenStack security guide that lists links to all published OSSNs > (just a fetch, format, and include in doc) each time the build happens. This is definitely a goal. Anne and I were discussing having an appendix to the Security Guide that would list published OSSNs associated with that particular OpenStack release. We might as well include the content, not just links. -NGK > > Cheers > Malini > > -----Original Message----- > From: Nathan Kinder [mailto:nkinder at redhat.com] > Sent: Friday, March 28, 2014 5:01 PM > To: openstack-security at lists.openstack.org > Subject: [Openstack-security] OSSN repository is live! > > Hi, > > I'm happy to announce that our new OSSN git repository is live! I have pre-populated it with all of the previously published Security Notes as well as templates to aid in the creation of new Security Notes. The repository is located here: > > http://git.openstack.org/cgit/openstack/openstack-security-notes/ > > Now that we have this repository, we will use the normal Gerrit workflow [1] for reviewing OSSNs. Bryan Payne, Rob Clark, and myself have +2 review permission to start with. We can certainly discuss making changes to this, but it should be fine for now. It might be a good item for us to discuss in Atlanta at the Summit. > > Publishing of OSSNs is still a manual process. I would like to add automatic publishing jobs, which is something that I will be looking into. We can also potentially add check and gate jobs for things such as formatting if desired. > > I have updated the OSSN process wiki page [2] with details of the new review procedures. > > Thanks, > -NGK > > [1] https://wiki.openstack.org/wiki/Gerrit_Workflow > [2] https://wiki.openstack.org/wiki/Security/Security_Note_Process > > _______________________________________________ > 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 Sun Mar 30 10:00:32 2014 From: robert.clark at hp.com (Clark, Robert Graham) Date: Sun, 30 Mar 2014 10:00:32 +0000 Subject: [Openstack-security] OSSN repository is live! In-Reply-To: References: <53360D49.8050102@redhat.com> Message-ID: +1 Lots of work has gone into this, thank you Nathan this is a big step forward for OSSNs From: Bryan D. Payne [mailto:bdpayne at acm.org] Sent: 29 March 2014 02:34 To: Nathan Kinder Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] OSSN repository is live! Great news, thanks for setting this up! -bryan On Fri, Mar 28, 2014 at 5:01 PM, Nathan Kinder > wrote: Hi, I'm happy to announce that our new OSSN git repository is live! I have pre-populated it with all of the previously published Security Notes as well as templates to aid in the creation of new Security Notes. The repository is located here: http://git.openstack.org/cgit/openstack/openstack-security-notes/ Now that we have this repository, we will use the normal Gerrit workflow [1] for reviewing OSSNs. Bryan Payne, Rob Clark, and myself have +2 review permission to start with. We can certainly discuss making changes to this, but it should be fine for now. It might be a good item for us to discuss in Atlanta at the Summit. Publishing of OSSNs is still a manual process. I would like to add automatic publishing jobs, which is something that I will be looking into. We can also potentially add check and gate jobs for things such as formatting if desired. I have updated the OSSN process wiki page [2] with details of the new review procedures. Thanks, -NGK [1] https://wiki.openstack.org/wiki/Gerrit_Workflow [2] https://wiki.openstack.org/wiki/Security/Security_Note_Process _______________________________________________ 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 gmurphy at redhat.com Mon Mar 31 04:23:23 2014 From: gmurphy at redhat.com (Grant Murphy) Date: Mon, 31 Mar 2014 04:23:23 -0000 Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE References: <20130503065127.14958.89453.malonedeb@gac.canonical.com> Message-ID: <20140331042324.5518.15063.malone@chaenomeles.canonical.com> So passlib defines the maximum password size as - MAX_PASSWORD_SIZE = int(os.environ.get("PASSLIB_MAX_PASSWORD_SIZE") or 4096) In this situation - import passlib.utils if CONF.identity.max_password_length > passlib.utils.MAX_PASSWORD_SIZE: # we might have problems. One potential alternative to the proposed fix is to explicitly set the PASSLIB_MAX_PASSWORD_SIZE to the size defined in the configuration file. This would also act as a failsafe for any cases where max password length checks were missed. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1175905 Title: passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE Status in OpenStack Identity (Keystone): Confirmed Bug description: Grant Murphy originally reported: * Usage of passlib The keystone server does not appear to sanitize the environment when starting. This means that an unintended value can be set for PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 4096 and potentially cause an unhandled passlib.exc.PasswordSizeError. We should ensure sensible defaults are applied here prior to loading passlib. If this is exploitable it will need a CVE, if not we should still harden it so it can't be monkeyed with in the future. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1175905/+subscriptions From ahmed.shohel at ericsson.com Mon Mar 31 08:00:44 2014 From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed) Date: Mon, 31 Mar 2014 11:00:44 +0300 Subject: [Openstack-security] OSSN repository is live! In-Reply-To: References: <53360D49.8050102@redhat.com> Message-ID: <854D4FA8-0523-40A1-8D6E-4C20D1CD50AF@ericsson.com> Hi Nathan, Great news! By the way, we are also planning to use GIT/GERRIT work flow for Threat modelling work. This will provide us clear process and visibility of the work chain. Could you please share, what is the process to achieve this. I mean, i can see a bug report related to this: https://bugs.launchpad.net/openstack-ci/+bug/1279074 Thanks, Shohel On 30 Mar 2014, at 13:00, Clark, Robert Graham wrote: > +1 > > Lots of work has gone into this, thank you Nathan this is a big step forward for OSSNs > > From: Bryan D. Payne [mailto:bdpayne at acm.org] > Sent: 29 March 2014 02:34 > To: Nathan Kinder > Cc: openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] OSSN repository is live! > > Great news, thanks for setting this up! > -bryan > > > On Fri, Mar 28, 2014 at 5:01 PM, Nathan Kinder wrote: > Hi, > > I'm happy to announce that our new OSSN git repository is live! I have > pre-populated it with all of the previously published Security Notes as > well as templates to aid in the creation of new Security Notes. The > repository is located here: > > http://git.openstack.org/cgit/openstack/openstack-security-notes/ > > Now that we have this repository, we will use the normal Gerrit workflow > [1] for reviewing OSSNs. Bryan Payne, Rob Clark, and myself have +2 > review permission to start with. We can certainly discuss making > changes to this, but it should be fine for now. It might be a good item > for us to discuss in Atlanta at the Summit. > > Publishing of OSSNs is still a manual process. I would like to add > automatic publishing jobs, which is something that I will be looking > into. We can also potentially add check and gate jobs for things such > as formatting if desired. > > I have updated the OSSN process wiki page [2] with details of the new > review procedures. > > Thanks, > -NGK > > [1] https://wiki.openstack.org/wiki/Gerrit_Workflow > [2] https://wiki.openstack.org/wiki/Security/Security_Note_Process > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4163 bytes Desc: not available URL: From nkinder at redhat.com Mon Mar 31 19:12:02 2014 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 31 Mar 2014 12:12:02 -0700 Subject: [Openstack-security] SSL proxies vs. native SSL support In-Reply-To: References: <5331F532.4010306@redhat.com> Message-ID: <5339BE02.4010606@redhat.com> On 03/25/2014 02:50 PM, Bryan D. Payne wrote: > A few thoughts come to mind: > > * For any production system, I suspect that you will be running a front > end server in front of the actual endpoint. So, at a minimum, that > server is where the TLS termination would happen. Depending on your > setup, it may make more sense to terminate directly at that server > (e.g., Apache or Nginx), or using a dedicated / purpose built TLS > termination shim (e.g., Stud or Pound). > > * In many deployments, the control plane uses a different trust model > than the external networks. Services on the control plane may not trust > the same set of root certs that clients on the external network choose > to trust. As such, the TLS setup would need to be different. > Re-encrypting the connection at a proxy that sits on the boundary of > the external network and the control plane serves to handle this use > somewhat common use case. > > * In some cases it may be useful for purposes of load balancing, and > auditing to be able to inspect the traffic at a proxy sitting between > the external network and the control plane. > > * If there is no use case to inspect the traffic, and there is a common > set of trusted root certs on both networks, then I see no problem just > taking the TLS all the way back to the front-end server handling the > endpoint (these would likely be deployed on the same machine... and > could then just communicate the clear-text information over a unix > socket or similar setup). A unix socket would definitely be ideal. As you say, if inspection of the encrypted traffic is not needed for something like load balancing, this sort of deployment would meet the goal of keeping clear-text traffic off of the network. It would also add some privilege separation by keeping access to the private key limited to the SSL terminator (vs. allowing the API endpoint process to access it). > > If others agree, perhaps there is room to improve the wording in the > book around this point? I do suspect that the setup described in the > book is most common for real world deployments, but I don't see anything > wrong with the other setup from a security standpoint. I do think that some re-wording and more detail would add clarity in this area. I think that each deployment will have different security requirements and concerns. The Security Guide should spell out the options, with limitations and concerns mentioned for each. This would allow the reader to make their own decision about what type of deployment would meet their requirements. I'm working on writing up some details in this area, so I'd be happy to submit some patches for this chapter of the Security Guide. -NGK > > My two cents, > -bryan > > > > On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder > wrote: > > Hi, > > The Security Guide currently recommends that SSL/TLS be used to protect > the API endpoints (as it should). We specifically mention that SSL > proxies should be used for this, as opposed to configuring SSL natively > in the services themselves: > > > http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html > > Is there any particular reason why we don't recommend configuring > SSL/TLS natively in the services? It seems like that would be an ideal > approach, as it eliminates the need for running proxies. It also keeps > access to the unencrypted traffic closer to the actual services that > need to access it, which is better from a security standpoint. > > I'm not sure that all of the integrated projects actually have working > native SSL/TLS support, but I know that a number of them claim to have > support. Shouldn't native support be the preferred recommendation from > a security standpoint? > > Thanks, > -NGK > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > From sbaker at redhat.com Mon Mar 24 00:47:39 2014 From: sbaker at redhat.com (Steve Baker) Date: Mon, 24 Mar 2014 00:47:39 -0000 Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString uses OS entropy source directly References: <20140110154958.26015.12359.malonedeb@gac.canonical.com> Message-ID: <20140324004739.9189.49863.malone@soybean.canonical.com> There appears to be nothing to fix here ** Changed in: heat Status: Confirmed => Invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1267912 Title: OS::Heat::RandomString uses OS entropy source directly Status in Orchestration API (Heat): Invalid Bug description: The RandomString resource documentation[1] suggests that it's useful for generating passwords and secrets. It doesn't mention the security guarantees, however. Heat seem to be using random.SystemRandom[2]. I'd like us to switch to something like PyCrypto or better yet, have Oslo provide a cryptographically secure random generator and use that. On Linux, random.SystemRandom reads from /dev/urandom which if I understand things correctly, can have its entropy depleted. So a Heat user could use a template that asks for a huge amount of randomness and empty the entropy pool of the entire system (not just Heat). This would probably be difficult to exploit, but I think it'd be safer use the entropy to seed a CSPRNG instead of using it directly. Which is exactly what PyCrypto seems to do. Regardless, the security guarantees and implications of OS::Heat::RandomString should be documented. [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81 To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions From 1031139 at bugs.launchpad.net Wed Mar 26 22:20:04 2014 From: 1031139 at bugs.launchpad.net (Melanie Witt) Date: Wed, 26 Mar 2014 22:20:04 -0000 Subject: [Openstack-security] [Bug 1031139] Re: quota-show does not handle alternatives for tenant_id as expected References: <20120730234300.27634.40825.malonedeb@gac.canonical.com> Message-ID: <20140326222004.9954.10499.malone@soybean.canonical.com> @scott-devoid Thanks for updating this with the data you gathered. Apologies for marking it as Fix Committed. I'm able to get the same behavior by following your steps, but there are two things I see so far: 1. The quota commands expect (in their help) tenant id only, not tenant name -- e.g. 'nova help quota-show'. If tenant id is omitted, the tenant name from the credentials gets translated to an id and used, which I think is causing confusion. All of the --tenant options are treated as ids, and tenant id and tenant name aren't intended to be interchangeable. 2. When a nonexistent tenant id is passed to quota-show, quota defaults are returned. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1031139 Title: quota-show does not handle alternatives for tenant_id as expected Status in Python client library for Nova: New Bug description: quota-show does not handle alternatives for tenant_id as expected ENV: Devstack trunk (Folsom) / nova d56b5fc3ad6dbfc56e0729174925fb146cef87fa , Mon Jul 30 21:59:56 2012 +0000 I'd expect the following command to work as $ env | grep TENANT -> OS_TENANT_NAME=demo $ nova --debug --os_username=admin --os_password=password quota-show usage: nova quota-show error: too few arguments I'd also expect the following to work: $ nova --debug --os_username=admin --os_password=password quota-show --os_tenant_name=demo usage: nova quota-show error: too few arguments What is more awesome, if in the event that I do provide the wrong tenant_id, it proceeds to use OS_TENANT_NAME returning those results: $nova --debug --os_username=admin --os_password=password quota-show gggggggggggggggggggggggggggggggggg REQ: curl -i http://10.1.11.219:8774/v2/04adebe40d214581b84118bcce264f0e/os-quota- sets/ggggggggggggggggggggggggggggggggggg -X GET -H "X-Auth-Project-Id: demo" -H "User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 10bd3f948df24039b2b88b98771b2b99" +-----------------------------+-------+ | Property | Value | +-----------------------------+-------+ | cores | 20 | | floating_ips | 10 | | gigabytes | 1000 | | injected_file_content_bytes | 10240 | | injected_files | 5 | | instances | 10 | | metadata_items | 128 | | ram | 51200 | | volumes | 10 | +-----------------------------+-------+ I also couldn't figure out how to get the quota-show to work as a member (non-admin) of a project. Let me know if you want any of these issues broken out in to additional bugs. To manage notifications about this bug go to: https://bugs.launchpad.net/python-novaclient/+bug/1031139/+subscriptions From 1299039 at bugs.launchpad.net Fri Mar 28 14:43:43 2014 From: 1299039 at bugs.launchpad.net (Abu Shohel Ahmed) Date: Fri, 28 Mar 2014 14:43:43 -0000 Subject: [Openstack-security] [Bug 1299039] [NEW] Token Scoping References: <20140328144343.5612.44045.malonedeb@chaenomeles.canonical.com> Message-ID: <20140328144343.5612.44045.malonedeb@chaenomeles.canonical.com> Public bug reported: In Havana Stable release for both V2.0 an V3, A scoped token can be used to get another scoped or un-scopped token. This can be exploited by anyone who has gained access to a scoped token. For example, 1. userA is related to two projects: Project1, Project2 2. userA creates tokenA scoped by Project1 3. userA shares the tokenA to a third party (malicious). 4. Third party can now make a token creation call to create a new tokenB scoped under projectB using tokenA. Although, we know that bearer token has all or nothing property, scoping the token can limit the exposure. A scoped token should not be allowed to create another scoped token. ** Affects: keystone Importance: Undecided Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1299039 Title: Token Scoping Status in OpenStack Identity (Keystone): New Bug description: In Havana Stable release for both V2.0 an V3, A scoped token can be used to get another scoped or un-scopped token. This can be exploited by anyone who has gained access to a scoped token. For example, 1. userA is related to two projects: Project1, Project2 2. userA creates tokenA scoped by Project1 3. userA shares the tokenA to a third party (malicious). 4. Third party can now make a token creation call to create a new tokenB scoped under projectB using tokenA. Although, we know that bearer token has all or nothing property, scoping the token can limit the exposure. A scoped token should not be allowed to create another scoped token. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299039/+subscriptions From 1299039 at bugs.launchpad.net Fri Mar 28 15:07:55 2014 From: 1299039 at bugs.launchpad.net (Dolph Mathews) Date: Fri, 28 Mar 2014 15:07:55 -0000 Subject: [Openstack-security] [Bug 1299039] Re: Token Scoping References: <20140328144343.5612.44045.malonedeb@chaenomeles.canonical.com> Message-ID: <20140328150755.5870.97455.malone@chaenomeles.canonical.com> Subscribed Adam Young, who has looked into this before, and I believe found a blocker to changing this behavior? ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => Wishlist -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1299039 Title: Token Scoping Status in OpenStack Identity (Keystone): Triaged Bug description: In Havana Stable release for both V2.0 an V3, A scoped token can be used to get another scoped or un-scopped token. This can be exploited by anyone who has gained access to a scoped token. For example, 1. userA is related to two projects: Project1, Project2 2. userA creates tokenA scoped by Project1 3. userA shares the tokenA to a third party (malicious). 4. Third party can now make a token creation call to create a new tokenB scoped under projectB using tokenA. Although, we know that bearer token has all or nothing property, scoping the token can limit the exposure. A scoped token should not be allowed to create another scoped token. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1299039/+subscriptions From 1300274 at bugs.launchpad.net Mon Mar 31 15:12:21 2014 From: 1300274 at bugs.launchpad.net (Abu Shohel Ahmed) Date: Mon, 31 Mar 2014 15:12:21 -0000 Subject: [Openstack-security] [Bug 1300274] [NEW] V3 Authentication Chaining - uniqueness of auth method names References: <20140331151221.30715.87577.malonedeb@gac.canonical.com> Message-ID: <20140331151221.30715.87577.malonedeb@gac.canonical.com> Public bug reported: In V3.0 API, we can chain authentication methods. An attacker can place the same authentication method multiple times in the methods filed. This will result in the same authentication method checking over and over (for loop in code). Using this, an attacker can achieve some sorts of Denial of Service. The methods field is not properly sanitized. { "auth":{ "identity":{ "methods":[ "password", "password", "password", "password", "password" ], "password":{ "user":{ "domain":{ "id":"default" }, "name":"demo", "password":"stack" } } } } } ** Affects: keystone Importance: Undecided Status: New ** Tags: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1300274 Title: V3 Authentication Chaining - uniqueness of auth method names Status in OpenStack Identity (Keystone): New Bug description: In V3.0 API, we can chain authentication methods. An attacker can place the same authentication method multiple times in the methods filed. This will result in the same authentication method checking over and over (for loop in code). Using this, an attacker can achieve some sorts of Denial of Service. The methods field is not properly sanitized. { "auth":{ "identity":{ "methods":[ "password", "password", "password", "password", "password" ], "password":{ "user":{ "domain":{ "id":"default" }, "name":"demo", "password":"stack" } } } } } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1300274/+subscriptions From 1300274 at bugs.launchpad.net Mon Mar 31 17:49:12 2014 From: 1300274 at bugs.launchpad.net (Dolph Mathews) Date: Mon, 31 Mar 2014 17:49:12 -0000 Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining - uniqueness of auth method names References: <20140331151221.30715.87577.malonedeb@gac.canonical.com> Message-ID: <20140331174913.30904.91030.launchpad@gac.canonical.com> ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => High ** Tags added: havana-backport-potential ** Tags added: icehouse-backport-potential -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1300274 Title: V3 Authentication Chaining - uniqueness of auth method names Status in OpenStack Identity (Keystone): Triaged Bug description: In V3.0 API, we can chain authentication methods. An attacker can place the same authentication method multiple times in the methods filed. This will result in the same authentication method checking over and over (for loop in code). Using this, an attacker can achieve some sorts of Denial of Service. The methods field is not properly sanitized. { "auth":{ "identity":{ "methods":[ "password", "password", "password", "password", "password" ], "password":{ "user":{ "domain":{ "id":"default" }, "name":"demo", "password":"stack" } } } } } To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1300274/+subscriptions