From gerrit2 at review.openstack.org Sun Dec 1 00:46:53 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 01 Dec 2013 00:46:53 +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 a0b3d822b72918aaf8b4010955aa563be723481d Author: Dan Genin Date: Sat Nov 30 19:45:31 2013 -0500 Add ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From gerrit2 at review.openstack.org Sun Dec 1 01:32:48 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Sun, 01 Dec 2013 01:32:48 +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 6bd32af1b19d43f8f82c86f7880c92b9be791a42 Author: Dan Genin Date: Sat Nov 30 19:45:31 2013 -0500 Add ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From noloader at gmail.com Mon Dec 2 00:32:57 2013 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 1 Dec 2013 19:32:57 -0500 Subject: [Openstack-security] Fwd: [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df In-Reply-To: <529A4019.20808@redhat.com> References: <529A4019.20808@redhat.com> Message-ID: Hi Nathan, Sorry about the late reply. > Is there anything in particular about this effort that you want to > discuss, or do you just want to follow what is happening? I'd like to follow and point out any issues that percolate up that I can spot. I'd be interested in knowing what the threats are. Are the adversaries passive, so that Message Security only want to limit information disclosure from, for example, a misconfigured KVM. Or are they active, where Message Security is trying to defend against someone trying to break out of their sandbox to {decrypt|inject|delete} other tenant traffic and control messages. Also, looking at the key derivations, I think the key derivation inputs should include a version number, too: Key Derivation inputs: Time.T = The time in the request TTL = Time To Leave, validity in seconds from Time.T Svc.A = the sender service name Svc.B = the receiver service name Key.A = the sender long term key Rnd.Salt = a random salt used for the extract function Rnd.Key = the Key used as input for the expand function Ls = Length of Signing Key (128bits) Le = Lenght of Encryption Key (128bits) Otherwise, it might work out that the protocol is susceptible to downgrade attacks like WinZip ("Attacking and Repairing the WinZip Encryption Scheme", http://homes.cs.washington.edu/~yoshi/papers/WinZip/winzip.pdf). I also think the Signature Scheme could benefit from a "usage" label on the "SignKey"): Signature = HMAC(SignKey, (Version || MetaData || Message)) Otherwise, you might be able to get one component to do things for another component under the same key because the same key is used for everything. Adding a usage label ensures distinct keys are used so other components can't accidentally use the same key. I'm not convinced the time-based scheme has helpful security properties. Time is notoriously difficult to use correctly, and everything I have rolled in practice uses counters. I'd also be interested in hearing more about Provisioning and Key Exchange. For what its worth, I like shared secret systems. They are orders of magnitude easier to work with than public key based stuff. Shared secret systems don't need to confer trust and can properly bind the channel (not to mention the perverted joke called PKI and PKIX using public CAs that don't warrant a damn thing). Most of the problems we have with shared secrets and passwords is due to our own mishandling of the sensitive data. Jeff On Sat, Nov 30, 2013 at 2:44 PM, Nathan Kinder wrote: > On 11/29/2013 12:49 AM, Jeffrey Walton wrote: >> Does anyone know if there's going to be any calls covering Message >> Security as proposed at >> https://wiki.openstack.org/wiki/MessageSecurity? I'd be very >> interested in listening in. > > Hi Jeff, > > I'm not sure if there are any actual calls scheduled, but this was a > discussion topic on the Keystone weekly IRC meeting last week. I expect > that it will be a topic this coming week as well. You might want to > join in: > > https://wiki.openstack.org/wiki/Meetings#Keystone_team_meeting > > The document you reference needs some updating, as I feel that it dives > into some low-level detail without providing enough high-level > background for those who aren't familiar with similar key distribution > schemes. I plan to take a pass at cleaning this up in the next few days. > > Is there anything in particular about this effort that you want to > discuss, or do you just want to follow what is happening? > > Thanks, > -NGK > >> >> Thanks in advance, >> >> Jeff >> >> FYI|PS: Dr. Rogaway is providing royalty free, irrevocable licenses >> for OCB mode in open source projects >> (http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm). OpenSSL's grant >> can be found at >> http://wiki.openssl.org/images/6/66/OCB-patent-grant-OpenSSL.pdf. >> >> OCB is the most efficient AE and AEAD mode available (as far as I >> know). When operating in OCB mode, there's no need for combining >> privacy modes like CBC with integrity protections like HMACs; nor is >> there a need for key derivation functions to ensure key independence. >> >> Other AEAD choices include the usual suspects, such as CCM, EAX and >> GCM mode. But they are less efficient than OCB due to Dr. Rogaway's >> patent. >> >> And +1 for not choosing a mode like EAX Prime for message security >> like the smart grid ;) >> >> ---------- Forwarded message ---------- >> From: >> Date: Fri, Nov 29, 2013 at 12:55 AM >> Subject: [Openstack-security] [openstack/identity-api] SecurityImpact >> review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df >> To: openstack-security at lists.openstack.org >> >> Hi, I'd like you to take a look at this patch for potential >> SecurityImpact. >> https://review.openstack.org/40692 >> >> Log: >> commit b775259ef1c06884985521fbba7cabc30884565a >> Author: Simo Sorce >> Date: Wed Aug 7 14:16:28 2013 -0400 >> >> Key Distribution Server >> >> API for distribution of keys in support of: >> https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation >> >> SecurityImpact >> >> Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df From gerrit2 at review.openstack.org Mon Dec 2 22:49:34 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 02 Dec 2013 22:49:34 +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 7958e2cc89835e1ee9c0702b6c3b5edc52f465b1 Author: Dan Genin Date: Mon Dec 2 17:41:39 2013 -0500 Add ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From gerrit2 at review.openstack.org Tue Dec 3 06:45:13 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Dec 2013 06:45:13 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit f3f7a94a1228562883cce230bdc541b83b989aea 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From gerrit2 at review.openstack.org Tue Dec 3 16:08:34 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Dec 2013 16:08:34 +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 bfabd8f0b7c29feff9f8b8b860e1a3406421f651 Author: Dan Genin Date: Tue Dec 3 11:10:12 2013 -0500 Add ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From gerrit2 at review.openstack.org Tue Dec 3 16:37:19 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 03 Dec 2013 16:37:19 +0000 Subject: [Openstack-security] [openstack/nova] SecurityImpact review request change I871af4018f99ddfcc8408708bdaaf480088ac477 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40467 Log: commit c4acbce41049dee120ec509279ce36eb6f44e574 Author: Dan Genin Date: Tue Dec 3 11:10:12 2013 -0500 Add ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From 1231263 at bugs.launchpad.net Tue Dec 3 23:08:30 2013 From: 1231263 at bugs.launchpad.net (Russell Bryant) Date: Tue, 03 Dec 2013 23:08:30 -0000 Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been print in log by some API call References: <20130926055439.7490.27811.malonedeb@gac.canonical.com> Message-ID: <20131203230832.17083.8194.launchpad@wampee.canonical.com> ** Changed in: nova Milestone: None => icehouse-1 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1231263 Title: Clear text password has been print in log by some API call Status in OpenStack Compute (Nova): Fix Committed Bug description: In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova. i.e: 2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': , 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103 2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926 This is not secue which the password should be replaced by *** To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1231263/+subscriptions From thierry.carrez+lp at gmail.com Wed Dec 4 10:08:08 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 04 Dec 2013 10:08:08 -0000 Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been print in log by some API call References: <20130926055439.7490.27811.malonedeb@gac.canonical.com> Message-ID: <20131204100812.17114.16814.launchpad@wampee.canonical.com> ** Changed in: nova 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/1231263 Title: Clear text password has been print in log by some API call Status in OpenStack Compute (Nova): Fix Released Bug description: In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova. i.e: 2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': , 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103 2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926 This is not secue which the password should be replaced by *** To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1231263/+subscriptions From thierry.carrez+lp at gmail.com Wed Dec 4 14:54:31 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 04 Dec 2013 14:54:31 -0000 Subject: [Openstack-security] [Bug 1251518] Re: Glance needs a config option to limit the number of additional image properties References: <20131115051405.19741.28287.malonedeb@chaenomeles.canonical.com> Message-ID: <20131204145434.30460.40176.launchpad@gac.canonical.com> ** Changed in: glance 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/1251518 Title: Glance needs a config option to limit the number of additional image properties Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in OpenStack Security Advisories: Invalid Bug description: Impact: The vulnerability occurs when glance is directly exposed to users. If users can only hit glance via the compute API, then no vulnerability. Nova has a configuration option quota_metadata_items (default value 128) that's documented to limit the number of metadata items that can be put on an instance. (I verified that it also applies to image metadata using a havana devstack.) Glance does not appear to have such an option (I was able to put >500 additional properties on an image using the glanceclient). I think this is a DOS attack vector, since someone could fill the glance database with garbage and slow everything down. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1251518/+subscriptions From gerrit2 at review.openstack.org Wed Dec 4 19:48:00 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 04 Dec 2013 19:48:00 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40692 Log: commit 88de5e38daf44d2c252ac8fa9d2e35e5e685d0c8 Author: Simo Sorce Date: Wed Aug 7 14:16:28 2013 -0400 Key Distribution Server API for distribution of keys in support of: https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation SecurityImpact Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df From gerrit2 at review.openstack.org Thu Dec 5 18:40:14 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 05 Dec 2013 18:40:14 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change I19384498839ae6abdf75ce3cd4df1c4618de480e Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/60312 Log: commit e9afe0ee314a9e0a480447218f62ed90fb05798b Author: Morgan Fainberg Date: Thu Dec 5 10:15:28 2013 -0800 Add in Encrypt and HMAC validation to KeyValueStore Add in the memcache_crypt functionality at the top level of the KeyValueStore implementation. This allows for either Encryption or HMAC validation of the data stored in the backend. This should provide a level of (optional) security when dealing with an external store for potentially sensitive data. The security is configured on a KeyValueStore by KeyValueStore basis (during the config step) instead of globally, making it optional on a case-by-case basis. DocImpact SecurityImpact bp: dogpile-kvs-backends Change-Id: I19384498839ae6abdf75ce3cd4df1c4618de480e From 1004114 at bugs.launchpad.net Thu Dec 5 19:33:34 2013 From: 1004114 at bugs.launchpad.net (Sergio Cazzolato) Date: Thu, 05 Dec 2013 19:33:34 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20131205193337.31382.79752.launchpad@chaenomeles.canonical.com> ** Changed in: python-keystoneclient Assignee: (unassigned) => Sergio Cazzolato (sergio-j-cazzolato) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From 1004114 at bugs.launchpad.net Thu Dec 5 20:26:10 2013 From: 1004114 at bugs.launchpad.net (Sergio Cazzolato) Date: Thu, 05 Dec 2013 20:26:10 -0000 Subject: [Openstack-security] [Bug 1004114] Re: Password logging References: <20120524190215.26515.18198.malonedeb@gac.canonical.com> Message-ID: <20131205202611.27681.19325.launchpad@gac.canonical.com> ** Changed in: python-keystoneclient Assignee: Sergio Cazzolato (sergio-j-cazzolato) => (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/1004114 Title: Password logging Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Identity (Keystone): Fix Released Status in Python client library for Keystone: In Progress Bug description: When the log level is set to DEBUG, keystoneclient's full-request logging mechanism kicks in, exposing plaintext passwords, etc. This bug is mostly out of the scope of Horizon, however Horizon can also be more secure in this regard. We should make sure that wherever we *are* handling sensitive data we use Django's error report filtering mechanisms so they don't appear in tracebacks, etc. (https://docs.djangoproject.com/en/dev/howto/error-reporting /#filtering-error-reports) Keystone may also want to look at respecting such annotations in their logging mechanism, i.e. if Django were properly annotating these data objects, keystoneclient could check for those annotations and properly sanitize the log output. If not this exact mechanism, then something similar would be wise. For the time being, it's also worth documenting in both projects that a log level of DEBUG will log passwords in plain text. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1004114/+subscriptions From gerrit2 at review.openstack.org Thu Dec 5 21:32:38 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 05 Dec 2013 21:32:38 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40692 Log: commit 7bcee877c2fb8edf61ab507c46fa84269917cc06 Author: Simo Sorce Date: Wed Aug 7 14:16:28 2013 -0400 Key Distribution Server API for distribution of keys in support of: https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation SecurityImpact Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df From 1175905 at bugs.launchpad.net Fri Dec 6 04:06:37 2013 From: 1175905 at bugs.launchpad.net (Tom Fifield) Date: Fri, 06 Dec 2013 04:06:37 -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: <20131206040639.27725.31993.launchpad@gac.canonical.com> ** Changed in: keystone Status: In Progress => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/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 anne.gentle at rackspace.com Fri Dec 6 17:10:26 2013 From: anne.gentle at rackspace.com (Anne Gentle) Date: Fri, 6 Dec 2013 11:10:26 -0600 Subject: [Openstack-security] Request: review of storage additions to the OpenStack Security Guide Message-ID: Hi all, There's a review I'd prefer some original authors take a look at before we push it through at https://review.openstack.org/#/c/58838/ We've looked at it as writers but I think it's best if subject matter experts take a look as well. Thanks, Anne -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.gentle at RACKSPACE.COM Fri Dec 6 21:27:44 2013 From: anne.gentle at RACKSPACE.COM (Anne Gentle) Date: Fri, 6 Dec 2013 21:27:44 +0000 Subject: [Openstack-security] Request: triage a doc bug Message-ID: Hi all, I'd like some of the original OpenStack Security Guide authors to triage this doc bug. https://bugs.launchpad.net/openstack-manuals/+bug/1253823 Is this a true concern? Please weigh in on the bug. This chapter says "The Identity service could alternatively be configured to provide UUID tokens which are significantly shorter but may be less secure depending on your specific deployment model." There's not meant to be any difference in security between using PKI versus UUID tokens. PKI tokens are supposed to save on network traffic and keystone server CPU (although I'm not sure that they do). Choosing PKI or UUID isn't a question of PKI is more secure. They're the same. ----------------------------------- Built: 2013-11-21T20:48:44 00:00 git SHA: 216e166bd12b79d533be12c139aaef740a2ff7f1 URL: http://docs.openstack.org/security-guide/content/ch024_authentication.html source File: file:/home/jenkins/workspace/openstack-security-guide/doc/security-guide/ch024_authentication.xml xml:id: ch024_authentication Anne Gentle Content Stacker my blog | my book | LinkedIn | Delicious | Twitter -------------- next part -------------- An HTML attachment was scrubbed... URL: From clint at fewbar.com Sat Dec 7 02:57:45 2013 From: clint at fewbar.com (Clint Byrum) Date: Sat, 07 Dec 2013 02:57:45 -0000 Subject: [Openstack-security] [Bug 1251647] Re: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason References: <20131115144107.27303.99752.malonedeb@gac.canonical.com> Message-ID: <20131207025747.17290.4847.launchpad@chaenomeles.canonical.com> ** Changed in: heat 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/1251647 Title: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason Status in Orchestration API (Heat): In Progress Status in OpenStack Security Advisories: Invalid Bug description: In the following commit: https://github.com/openstack/heat/commit/58cd52624b50476ed5ed1c5c0ba7cb1b4d7ba66d ... a decision was introduced to encrypt authentication information using unauthenticated AES-CFB. There's a few things I don't like about that commit, but suffice to say that heat/engine/auth.py should probably not be a place where symmetric crypto decisions are made. I've been told that there's a new public API for symmetric encryption, SymmetricCrypto that lives in openstack/common/crypto/utils.py: https://github.com/openstack/oslo- incubator/blob/master/openstack/common/crypto/utils.py#L99 I think that also gets a few things wrong, but at the very least Heat should use a centralized thing for encrypting stuff. (I'd love to complain about and work on SymmetricCrypto too, but that's not this ticket :) To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1251647/+subscriptions From shardy at redhat.com Mon Dec 2 14:15:55 2013 From: shardy at redhat.com (Steven Hardy) Date: Mon, 02 Dec 2013 14:15:55 -0000 Subject: [Openstack-security] [Bug 1221564] Re: Didn't associate a security-group to instances References: <20130906072005.20637.36919.malonedeb@soybean.canonical.com> Message-ID: <20131202141556.4872.51187.launchpad@wampee.canonical.com> ** Tags added: grizzly-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/1221564 Title: Didn't associate a security-group to instances Status in Orchestration API (Heat): Fix Released Bug description: Define a WikiDatabaseSecurityGroup as below : "WikiDatabaseSecurityGroup" : { "Type" : "AWS::EC2::SecurityGroup", "Properties" : { "GroupDescription" : "Enable HTTP access via port 80 plus SSH access", "SecurityGroupIngress" : [ {"IpProtocol" : "icmp", "FromPort" : "-1", "ToPort" : "-1", "CidrIp" : "0.0.0.0/0"}, {"IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0"}, {"IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : "0.0.0.0/0"} ] } }, refer it to instance properties as "SecurityGroups" : [ {"Ref" : "WikiDatabaseSecurityGroup"} ], in template WordPress_2_Instances_With_EBS_EIP.template. But when the instance is spawned, seems the security_group of this instance is not "WikiDatabaseSecurityGroup", but the "default" one. [root at oc2603148815 xianghui]# nova show wordpress_1-WikiDatabase-kpjsht332enl +--------------------------------------+------------------------------------------------------------+ | Property | Value | +--------------------------------------+------------------------------------------------------------+ | status | ACTIVE | | updated | 2013-08-20T09:32:06Z | | OS-EXT-STS:task_state | None | | OS-EXT-SRV-ATTR:host | oc2603148815.ibm.com | | key_name | userkey | | image | F17-x86_64-cfntools (53181c83-4e24-4888-be88-1f9e7ed4877c) | | hostId | 5c331878f9858b022f7d92f7f74714f1d58eef066dd6768a77e26264 | | OS-EXT-STS:vm_state | active | | OS-EXT-SRV-ATTR:instance_name | instance-0000008d | | OS-SRV-USG:launched_at | 2013-08-20T09:32:06.000000 | | OS-EXT-SRV-ATTR:hypervisor_hostname | oc2603148815.ibm.com | | flavor | m1.small (2) | | id | c7e59830-8ca7-43a3-8c17-d670c0263876 | | security_groups | [{u'name': u'default'}] | | OS-SRV-USG:terminated_at | None | | vlan-70 network | 70.0.0.20, 192.168.12.19 | | user_id | 22c367eb5eb34846acc0a2c0c4836f93 | | name | wordpress_1-WikiDatabase-kpjsht332enl | | created | 2013-08-20T09:31:52Z | | tenant_id | b21a96e16c3c438caab4a27a1f58a5b8 | | OS-DCF:diskConfig | MANUAL | | metadata | {} | | os-extended-volumes:volumes_attached | [{u'id': u'e190341f-4007-43ce-8099-2e4be1e606da'}] | | accessIPv4 | | | accessIPv6 | | | progress | 0 | | OS-EXT-STS:power_state | 1 | | OS-EXT-AZ:availability_zone | nova | | config_drive | | +--------------------------------------+------------------------------------------------------------+ By doing some investigation, the root cause has been found : instance port will be created by calling quantumclient.create_port in /heat/engine/resources/instance.py , but the security_group resource created by heat is not passed as a parameter. To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1221564/+subscriptions From 1251647 at bugs.launchpad.net Tue Dec 3 11:08:29 2013 From: 1251647 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 03 Dec 2013 11:08:29 -0000 Subject: [Openstack-security] [Bug 1251647] Re: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason References: <20131115144107.27303.99752.malonedeb@gac.canonical.com> Message-ID: <20131203110829.6371.21217.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/59685 ** Changed in: heat Status: Triaged => In Progress ** Changed in: heat Assignee: (unassigned) => Angus Salkeld (asalkeld) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251647 Title: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason Status in Orchestration API (Heat): In Progress Status in OpenStack Security Advisories: Invalid Bug description: In the following commit: https://github.com/openstack/heat/commit/58cd52624b50476ed5ed1c5c0ba7cb1b4d7ba66d ... a decision was introduced to encrypt authentication information using unauthenticated AES-CFB. There's a few things I don't like about that commit, but suffice to say that heat/engine/auth.py should probably not be a place where symmetric crypto decisions are made. I've been told that there's a new public API for symmetric encryption, SymmetricCrypto that lives in openstack/common/crypto/utils.py: https://github.com/openstack/oslo- incubator/blob/master/openstack/common/crypto/utils.py#L99 I think that also gets a few things wrong, but at the very least Heat should use a centralized thing for encrypting stuff. (I'd love to complain about and work on SymmetricCrypto too, but that's not this ticket :) To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1251647/+subscriptions From 1227575 at bugs.launchpad.net Tue Dec 3 23:09:06 2013 From: 1227575 at bugs.launchpad.net (Russell Bryant) Date: Tue, 03 Dec 2013 23:09: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: <20131203230908.30774.15527.launchpad@gac.canonical.com> ** Changed in: nova Milestone: icehouse-1 => icehouse-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/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 openstack at nemebean.com Wed Dec 4 19:00:12 2013 From: openstack at nemebean.com (Ben Nemec) Date: Wed, 04 Dec 2013 13:00:12 -0600 Subject: [Openstack-security] =?utf-8?q?=5Bopenstack-dev=5D_creating_a_def?= =?utf-8?q?ault_for_oslo_config_variables__within_a_project=3F?= In-Reply-To: <529F79A4.2070602@dague.net> References: <529E5389.1010102@dague.net> <81d27b8263de0a93ab48a48c15ee7ba3@localhost> <1386111048.25853.164.camel@sorcha> <529E64A2.1020502@dague.net> <05b1d9437c44dd36cbf82dc77cd6b5a3@localhost> <529E71DB.4040907@dague.net> <1386130110-sup-8766@clint-HP> <529F1B0C.5080704@dague.net> <5be015616964b5fc5d631daeac5c3bcc@localhost> <529F79A4.2070602@dague.net> Message-ID: On 2013-12-04 12:51, Sean Dague wrote: > On 12/04/2013 11:56 AM, Ben Nemec wrote: >> On 2013-12-04 06:07, Sean Dague wrote: >>> On 12/03/2013 11:21 PM, Clint Byrum wrote: >>>> Excerpts from Sean Dague's message of 2013-12-03 16:05:47 -0800: >>>>> On 12/03/2013 06:13 PM, Ben Nemec wrote: >>>>>> On 2013-12-03 17:09, Sean Dague wrote: >>>>>>> On 12/03/2013 05:50 PM, Mark McLoughlin wrote: >>>>>>>> On Tue, 2013-12-03 at 16:23 -0600, Ben Nemec wrote: >>>>>>>>> On 2013-12-03 15:56, Sean Dague wrote: >>>>>>>>>> This cinder patch - https://review.openstack.org/#/c/48935/ >>>>>>>>>> >>>>>>>>>> Is blocked on failing upgrade because the updated oslo >>>>>>>>>> lockutils won't >>>>>>>>>> function until there is a specific configuration variable >>>>>>>>>> added >>>>>>>>>> to the >>>>>>>>>> cinder.conf. >>>>>>>>>> >>>>>>>>>> That work around is proposed here - >>>>>>>>>> https://review.openstack.org/#/c/52070/3 >>>>>>>>>> >>>>>>>>>> However I think this is exactly the kind of forward breaks >>>>>>>>>> that we >>>>>>>>>> want >>>>>>>>>> to prevent with grenade, as cinder failing to function after a >>>>>>>>>> rolling >>>>>>>>>> upgrade because a config item wasn't added is exactly the kind >>>>>>>>>> of pain >>>>>>>>>> we are trying to prevent happening to ops. >>>>>>>>>> >>>>>>>>>> So the question is, how is this done correctly so that a >>>>>>>>>> default >>>>>>>>>> can be >>>>>>>>>> set in the cinder code for this value, and it not require a >>>>>>>>>> config >>>>>>>>>> change to work? >>>>>>>> >>>>>>>> You're absolutely correct, in principle - if the default value >>>>>>>> for >>>>>>>> lock_path worked for users before, we should absolutely continue >>>>>>>> to >>>>>>>> support it. >>>>>>>> >>>>>>>>> I don't know that I have a good answer on how to handle this, >>>>>>>>> but for >>>>>>>>> context this change is the result of a nasty bug in lockutils >>>>>>>>> that >>>>>>>>> meant >>>>>>>>> external locks were doing nothing if lock_path wasn't set. >>>>>>>>> Basically >>>>>>>>> it's something we should never have allowed in the first place. >>>>>>>>> >>>>>>>>> As far as setting this in code, it's important that all of the >>>>>>>>> processes >>>>>>>>> for a service are using the same value to avoid the same bad >>>>>>>>> situation >>>>>>>>> we were in before. For tests, we have a lockutils wrapper >>>>>>>>> (https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L282) >>>>>>>>> >>>>>>>>> that sets an environment variable to address this, but that >>>>>>>>> only >>>>>>>>> works if all of the processes are going to be spawned from >>>>>>>>> within >>>>>>>>> the same wrapper, and I'm not sure how secure that is for >>>>>>>>> production >>>>>>>>> deployments since it puts all of the lock files in a temporary >>>>>>>>> directory. >>>>>>>> >>>>>>>> Right, I don't think the previous default really "worked" - if >>>>>>>> you used >>>>>>>> the default, then external locking was broken. >>>>>>>> >>>>>>>> I suspect most distros do set a default - I see RDO has this in >>>>>>>> its >>>>>>>> default nova.conf: >>>>>>>> >>>>>>>> lock_path = /var/lib/nova/tmp >>>>>>>> >>>>>>>> So, yes - this is all terrible. >>>>>>>> >>>>>>>> IMHO, rather than raise an exception we should log a big fat >>>>>>>> warning >>>>>>>> about relying on the default and perhaps just treat the lock as >>>>>>>> an >>>>>>>> in-process lock in that case ... since that's essentially what >>>>>>>> it >>>>>>>> was >>>>>>>> before, right? >>>>>>> >>>>>>> So a default of lock_path = /tmp will work (FHS says that path >>>>>>> has >>>>>>> to be >>>>>>> there), even if not optimal. Could we make it a default value >>>>>>> like >>>>>>> that >>>>>>> instead of the current default which is null (and hence the >>>>>>> problem). >>>>>> >>>>>> IIRC, my initial fix was something similar to that, but it got >>>>>> shot >>>>>> down >>>>>> because putting the lock files in a known world writeable location >>>>>> was a >>>>>> security issue. >>>>>> >>>>>> Although maybe if we put them in a subdirectory of /tmp and >>>>>> ensured >>>>>> that >>>>>> the permissions were such that only the user running the service >>>>>> could >>>>>> use that directory, it might be acceptable? We could still log a >>>>>> warning if we wanted. >>>>>> >>>>>> This seems like it would have implications for people running >>>>>> services >>>>>> on Windows too, but we can probably find a way to make that work >>>>>> if we >>>>>> decide on a solution. >>>>> >>>>> How is that a security issue? Are the lock files being written with >>>>> some >>>>> sensitive data in them and have g or o permissions on? The sticky >>>>> bit >>>>> (+t) on /tmp will prevent other users from deleting the file. >>>>> >>>> >>>> Right, but it won't prevent users from creating a symlink with the >>>> same >>>> name. >>>> >>>> ln -s /var/lib/nova/instances/xxxxx/image.raw >>>> /tmp/well.known.location >>>> >>>> Now when you do >>>> >>>> with open('/tmp/well.known.location', 'w') as lockfile: >>>> lockfile.write('Stuff') >>>> >>>> Nova has just truncated the image file and written 'Stuff' to it. >>> >>> So that's the generic case (and the way people often write this). But >>> the oslo lockutils code doesn't work that way. While it does open the >>> file for write, it does not actually write, it's using fcntl to hold >>> locks. That's taking a data structure on the fd in kernel memory >>> (IIRC), >>> so it correctly gives it up if the process crashes. >>> >>> I'm not saying there isn't some other possible security vulnerability >>> here as well, but it's not jumping out at me. So I'd love to >>> understand >>> that, because if we can close that exposure we can provide a working >>> default, plus a strong recommendation for how to do that *right*. I'd >>> be >>> totally happy with printing WARNING level at startup if lock_path = >>> /tmp >>> that this should be adjusted. >> >> Full disclosure: I don't claim to be a security expert, so take my >> thoughts on this with a grain of salt. >> >> tldr: I still don't see a way to do this without breaking _something_. >> >> Unfortunately, while we don't actually write to the file, just opening >> it for write access truncates it. So there remains the issue Clint >> raised if someone can make that file a link. I suppose we could check >> for the bad things people might do, but I'm pretty sure that way lies >> madness. > > Fair point, more coffee before I make statements like that I guess :). > > Follow up question: could we change it to open in "a" mode instead. > Still requires write access, but won't truncate. > >> As a followup to my suggestion to have lockutils create something like >> /tmp/oslo-lock-path and make it accessible only to the owner, I think >> there's still a problem because a malicious user could create that >> directory ahead of time and when OpenStack is run for the first time >> it >> would happily use the existing directory and potentially overwrite any >> linked files in it. There might be ways to avoid that, but I suspect >> they would be racy (which I believe is why you're not supposed to use >> tmp paths that are known ahead of time). Granted, I'm not sure you >> should be installing to a system that already has malicious users on >> it, >> but I suspect security people would be less than thrilled with that >> answer. >> >> So the workable options that I see right now are to have it break on >> upgrade if lock_path is not set, or continue to break external locking >> by having it fall back to process locks when lock_path is not set, as >> Mark suggested. I'm not wild about either so I'd love to hear if >> anyone >> has a third option. > > Honestly, I'd love us to be clever and figure out a not dangerous way > through this, even if unwise (where we can yell at the user in the LOGs > loudly, and fail them in J if lock_dir=/tmp) that lets us progress > through this while gracefully bringing configs into line. Copying openstack-security since they should probably sign off on this. -Ben From 1247217 at bugs.launchpad.net Thu Dec 5 21:05:08 2013 From: 1247217 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Dec 2013 21:05:08 -0000 Subject: [Openstack-security] [Bug 1247217] Fix merged to nova (master) References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131205210508.31727.83271.malone@chaenomeles.canonical.com> Reviewed: https://review.openstack.org/56059 Committed: http://github.com/openstack/nova/commit/138f24dea3b1fa34a39eaa0e937b19657b287ccc Submitter: Jenkins Branch: master commit 138f24dea3b1fa34a39eaa0e937b19657b287ccc Author: Lance Bragstad Date: Thu Nov 14 15:40:05 2013 +0000 Sync log.py from Oslo-incubator This change syncs log.py and it's dependencies from Oslo-incubator to include the password sanitation fix that landed in Oslo with commit 76b0cd10c414ae71e6f041adb431460b3337c63d. The following is a list of the change IDs that this commit is bringing in from the last sync of Oslo-incubator with respect to the files we are touching. 2b40a10 python3: Fix UserString import c331e74 Enable multiple translation domains for gettextutils 89369c3 gettextutils: port to Python 3 6d49bca Translate all substitution elements of a Message object 3970d46 Fix typos in oslo 88db9c8 When translating if no locale is given use default locale 53ebd30 python3: use six.text_types for unicode() 25c5854 Adds admin_password as key to be sanitized when logging 2251cb5 Do not name variables as builtins 04c1b5a Type check for Message param to avoid AttributeError Change-Id: Ie4d5929604e3fc057ea09edbbf3adf16f8839a4e Partial-Bug: #1247217 ** Changed in: nova Status: In Progress => Fix Committed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Fix Committed Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From 1247217 at bugs.launchpad.net Thu Dec 5 21:05:56 2013 From: 1247217 at bugs.launchpad.net (OpenStack Infra) Date: Thu, 05 Dec 2013 21:05:56 -0000 Subject: [Openstack-security] [Bug 1247217] Fix merged to nova (master) References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131205210556.20250.40335.malone@wampee.canonical.com> Reviewed: https://review.openstack.org/56069 Committed: http://github.com/openstack/nova/commit/187140c2fcafb56752f0160832607e374a4a94ff Submitter: Jenkins Branch: master commit 187140c2fcafb56752f0160832607e374a4a94ff Author: Lance Bragstad Date: Thu Nov 14 15:44:15 2013 +0000 Use password masking utility provided in Oslo Implement the mask_password function provided in Oslo-incubator's log.py. Instead of having a specific version in Nova different from other projects that are essentially doing the same thing. Change-Id: I7e04b7d31d4d6959b17b1da9654553042eec70f1 Closes-Bug: #1247217 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Fix Committed Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From 1227575 at bugs.launchpad.net Sat Dec 7 13:31:03 2013 From: 1227575 at bugs.launchpad.net (Robert Clark) Date: Sat, 07 Dec 2013 13:31:03 -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: <20131207133106.17356.96124.launchpad@chaenomeles.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/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 1231263 at bugs.launchpad.net Sun Dec 8 11:28:58 2013 From: 1231263 at bugs.launchpad.net (Alan Pevec) Date: Sun, 08 Dec 2013 11:28:58 -0000 Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been print in log by some API call References: <20130926055439.7490.27811.malonedeb@gac.canonical.com> Message-ID: <20131208112858.17197.73687.launchpad@chaenomeles.canonical.com> ** Also affects: nova/havana Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1231263 Title: Clear text password has been print in log by some API call Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) havana series: Fix Committed Bug description: In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova. i.e: 2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': , 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103 2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926 This is not secue which the password should be replaced by *** To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1231263/+subscriptions From 1231263 at bugs.launchpad.net Sun Dec 8 11:37:17 2013 From: 1231263 at bugs.launchpad.net (Alan Pevec) Date: Sun, 08 Dec 2013 11:37:17 -0000 Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been print in log by some API call References: <20130926055439.7490.27811.malonedeb@gac.canonical.com> Message-ID: <20131208113719.8887.36817.launchpad@gac.canonical.com> ** Changed in: nova/havana Status: New => Fix Committed ** Changed in: nova/havana Milestone: None => 2013.2.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/1231263 Title: Clear text password has been print in log by some API call Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) havana series: Fix Committed Bug description: In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova. i.e: 2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': , 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103 2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926 This is not secue which the password should be replaced by *** To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1231263/+subscriptions From 1231263 at bugs.launchpad.net Sun Dec 8 12:34:36 2013 From: 1231263 at bugs.launchpad.net (Alan Pevec) Date: Sun, 08 Dec 2013 12:34:36 -0000 Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been print in log by some API call References: <20130926055439.7490.27811.malonedeb@gac.canonical.com> Message-ID: <20131208123439.25489.48599.launchpad@wampee.canonical.com> ** Changed in: nova/havana Importance: Undecided => Medium ** Tags removed: havana-backport-potential in-stable-havana ** Changed in: nova/havana Assignee: (unassigned) => Matt Riedemann (mriedem) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1231263 Title: Clear text password has been print in log by some API call Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) havana series: Fix Committed Bug description: In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova. i.e: 2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': , 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103 2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926 This is not secue which the password should be replaced by *** To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1231263/+subscriptions From gerrit2 at review.openstack.org Mon Dec 9 01:51:23 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 09 Dec 2013 01:51:23 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change I24c77188ebb05ef57b378798584e3829d55827f2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/60727 Log: commit 6f26d92af5b215c237d87f274a975bf295a2bc1d Author: Jamie Lennox Date: Mon Dec 9 11:41:03 2013 +1000 Add OS-SIMPLE-CERT extension This provides a very basic mechanism for retrieving the CA and signing certificate from the identity service. It aims to simply replicate the functionality provided by the v2.0 API. SecurityImpact Change-Id: I24c77188ebb05ef57b378798584e3829d55827f2 Partial-Bug: #1259011 From thierry.carrez+lp at gmail.com Mon Dec 9 16:07:31 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 09 Dec 2013 16:07:31 -0000 Subject: [Openstack-security] [Bug 1192966] Re: Potentially insecure dependency loading References: <20130620132537.19232.33035.malonedeb@gac.canonical.com> Message-ID: <20131209160732.17101.46192.launchpad@chaenomeles.canonical.com> ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1192966 Title: Potentially insecure dependency loading Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Security Advisories: Incomplete Status in OpenStack Object Storage (Swift): New Bug description: Grant Murphy and Dhiru Kholia from Red Hat Product Security Team reported the following potential issue. This is actually a setuptools issue but which we may be able to workaround, if we end up being affected: --- A security flaw was found in the way Python Setuptools, a collection of enhancements to the Python distutils module, that allows more easily to build and distribute Python packages, performed integrity checks when loading external resources, previously extracted from zipped Python Egg archives(formerly if the timestamp and file size of a particular resource expanded from the archive matched the original values, the resource was successfully loaded). A local attacker, with write permission into the Python's EGG cache (directory) could use this flaw to provide a specially-crafted resource (in expanded form) that, when loaded in an application requiring that resource to (be able to) run, would lead to arbitrary code execution with the privileges of the user running the application. It seems to be pretty common for Python applications to do something like os.evironment['PYTHON_EGG_CACHE'] = /tmp, prior to importing dependencies. If the dependency contains a .so Python must unpack it into the cache directory to be able to load it. However if an attacker pre-emptively places a .so in the same location as long as the file has the same timestamp and file size it will be loaded. --- Glance and Swift both set PYTHON_EGG_CACHE to '/tmp' : ./glance/glance/cmd/control.py: os.environ['PYTHON_EGG_CACHE'] = '/tmp' ./swift/swift/common/manager.py: os.environ['PYTHON_EGG_CACHE'] = '/tmp' If we are immediately vulnerable to this (i.e. if stuff loaded from those commands contains an .so, if I understand correctly), we could workaround it by setting it to /tmp/secure-dir-XXXXXX/ until setuptools upstream fixes this. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1192966/+subscriptions From robert.clark at hp.com Mon Dec 9 20:06:50 2013 From: robert.clark at hp.com (Clark, Robert Graham) Date: Mon, 9 Dec 2013 20:06:50 +0000 Subject: [Openstack-security] Deriving Instance UUID Message-ID: Guys, Is there any way you know of to infer or guess at the UUID of a compute instance belonging to another tenant? -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1168252 at bugs.launchpad.net Mon Dec 9 20:52:58 2013 From: 1168252 at bugs.launchpad.net (Dean Troyer) Date: Mon, 09 Dec 2013 20:52:58 -0000 Subject: [Openstack-security] [Bug 1168252] Re: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com> Message-ID: <20131209205300.17259.75573.launchpad@chaenomeles.canonical.com> ** Changed in: devstack Status: Confirmed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1168252 Title: keystone.conf should not be world-readable (to keep LDAP password and admin_token secret) Status in devstack - openstack dev environments: Fix Released Status in OpenStack Security Notes: Fix Released Status in Gentoo Linux: Fix Released Bug description: The password configuration of LDAP and admin_token in keystone.conf should be secret to protect security information: [ldap] # url = ldap://localhost # user = dc=Manager,dc=example,dc=com # password = None <- should be secrect # suffix = cn=example,cn=com # use_dumb_member = False # allow_subtree_delete = False # dumb_member = cn=dumb,dc=example,dc=com [DEFAULT] admin_token = passw0rd <- should be secrect To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1168252/+subscriptions From brian.schott at nimbisservices.com Mon Dec 9 21:16:11 2013 From: brian.schott at nimbisservices.com (Brian Schott) Date: Mon, 9 Dec 2013 16:16:11 -0500 Subject: [Openstack-security] Deriving Instance UUID In-Reply-To: References: Message-ID: <517C9FFA-AACA-419B-A873-61A5519B0894@nimbisservices.com> Rob, That is a hard question. The short answer is that it depends on the type of UUID. Type 1 () is mac address of the server + timestamp, so probability of guessing another UUID in the system is very high. Type 4 (random) has 122 bits, so probability of collision is extremely small and is also dependent on having a good random number generator. A poor implementation might be predictable. Type 5 (namespace) has fewer bits depending on the size of the namespace. http://en.wikipedia.org/wiki/Birthday_problem#Probability_table I think in general web url usage, a bare UUID as authentication mechanism isn't considered good practice, but it really depends on how many elements you have in the system, how it is protected from brute-force attacks, etc. Brian ------------------------------------------------- Brian Schott, CTO Nimbis Services, Inc. brian.schott at nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Dec 9, 2013, at 3:06 PM, Clark, Robert Graham wrote: > Guys, > > Is there any way you know of to infer or guess at the UUID of a compute instance belonging to another tenant? > > -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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3662 bytes Desc: not available URL: From cody.bunch at rackspace.com Mon Dec 9 21:23:10 2013 From: cody.bunch at rackspace.com (Cody Bunch) Date: Mon, 9 Dec 2013 21:23:10 +0000 Subject: [Openstack-security] Deriving Instance UUID In-Reply-To: <517C9FFA-AACA-419B-A873-61A5519B0894@nimbisservices.com> References: , <517C9FFA-AACA-419B-A873-61A5519B0894@nimbisservices.com> Message-ID: <327FAB32C28C564DAA23CE6D03789DBCA8CCD675@ORD1EXD01.RACKSPACE.CORP> Thanks! I'd replied, but seems I left the list off. The Nova sources (nova/openstack/common/uuidutils.py) use Pythons uuid.uuid4() to generate the uuids. The Python source for UUID4 seems to pull from a number of methods, going to (u)random or pythons random module, so heavily dependent on system(s) it's being run from: http://hg.python.org/cpython/file/ec8d2f54dcb2/Lib/uuid.py I did throw up a quick test to see if I can find a match... so far I've generated 20 million uuid's and not had a collision (didn't expect one, but it's good to see): https://gist.github.com/bunchc/7880710 It also seems that other services may use their own UUID generation or so, I've not looked into that however. -C ________________________________ From: Brian Schott [brian.schott at nimbisservices.com] Sent: Monday, December 09, 2013 3:16 PM To: Clark, Robert Graham Cc: openstack-security at lists.openstack.org Subject: Re: [Openstack-security] Deriving Instance UUID Rob, That is a hard question. The short answer is that it depends on the type of UUID. Type 1 () is mac address of the server + timestamp, so probability of guessing another UUID in the system is very high. Type 4 (random) has 122 bits, so probability of collision is extremely small and is also dependent on having a good random number generator. A poor implementation might be predictable. Type 5 (namespace) has fewer bits depending on the size of the namespace. http://en.wikipedia.org/wiki/Birthday_problem#Probability_table I think in general web url usage, a bare UUID as authentication mechanism isn't considered good practice, but it really depends on how many elements you have in the system, how it is protected from brute-force attacks, etc. Brian ------------------------------------------------- Brian Schott, CTO Nimbis Services, Inc. brian.schott at nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Dec 9, 2013, at 3:06 PM, Clark, Robert Graham > wrote: Guys, Is there any way you know of to infer or guess at the UUID of a compute instance belonging to another tenant? -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 brian.schott at nimbisservices.com Mon Dec 9 21:42:34 2013 From: brian.schott at nimbisservices.com (Brian Schott) Date: Mon, 9 Dec 2013 16:42:34 -0500 Subject: [Openstack-security] Deriving Instance UUID In-Reply-To: <327FAB32C28C564DAA23CE6D03789DBCA8CCD675@ORD1EXD01.RACKSPACE.CORP> References: , <517C9FFA-AACA-419B-A873-61A5519B0894@nimbisservices.com> <327FAB32C28C564DAA23CE6D03789DBCA8CCD675@ORD1EXD01.RACKSPACE.CORP> Message-ID: You probably have to wait about 100 years for that test ;-). However, you are right that this is system dependent. I came across this bug in mac os x when googling for the birthday problem table. After a fork, uuid_generate_random() generates the same UUID in every child! http://stackoverflow.com/questions/2759644/python-multiprocessing-doesnt-play-nicely-with-uuid-uuid4 http://bugs.python.org/issue8621 http://openradar.appspot.com/radar?id=334401 ------------------------------------------------- Brian Schott, CTO Nimbis Services, Inc. brian.schott at nimbisservices.com ph: 443-274-6064 fx: 443-274-6060 On Dec 9, 2013, at 4:23 PM, Cody Bunch wrote: > Thanks! I'd replied, but seems I left the list off. The Nova sources (nova/openstack/common/uuidutils.py) use Pythons uuid.uuid4() to generate the uuids. The Python source for UUID4 seems to pull from a number of methods, going to (u)random or pythons random module, so heavily dependent on system(s) it's being run from: > http://hg.python.org/cpython/file/ec8d2f54dcb2/Lib/uuid.py > > I did throw up a quick test to see if I can find a match... so far I've generated 20 million uuid's and not had a collision (didn't expect one, but it's good to see): > https://gist.github.com/bunchc/7880710 > > It also seems that other services may use their own UUID generation or so, I've not looked into that however. > > -C > From: Brian Schott [brian.schott at nimbisservices.com] > Sent: Monday, December 09, 2013 3:16 PM > To: Clark, Robert Graham > Cc: openstack-security at lists.openstack.org > Subject: Re: [Openstack-security] Deriving Instance UUID > > Rob, > > That is a hard question. The short answer is that it depends on the type of UUID. Type 1 () is mac address of the server + timestamp, so probability of guessing another UUID in the system is very high. Type 4 (random) has 122 bits, so probability of collision is extremely small and is also dependent on having a good random number generator. A poor implementation might be predictable. Type 5 (namespace) has fewer bits depending on the size of the namespace. > > http://en.wikipedia.org/wiki/Birthday_problem#Probability_table > > I think in general web url usage, a bare UUID as authentication mechanism isn't considered good practice, but it really depends on how many elements you have in the system, how it is protected from brute-force attacks, etc. > > Brian > > ------------------------------------------------- > Brian Schott, CTO > Nimbis Services, Inc. > brian.schott at nimbisservices.com > ph: 443-274-6064 fx: 443-274-6060 > > > > On Dec 9, 2013, at 3:06 PM, Clark, Robert Graham wrote: > >> Guys, >> >> Is there any way you know of to infer or guess at the UUID of a compute instance belonging to another tenant? >> >> -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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3662 bytes Desc: not available URL: From sriram at sriramhere.com Mon Dec 9 22:52:14 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 9 Dec 2013 14:52:14 -0800 Subject: [Openstack-security] Deriving Instance UUID In-Reply-To: References: <517C9FFA-AACA-419B-A873-61A5519B0894@nimbisservices.com> <327FAB32C28C564DAA23CE6D03789DBCA8CCD675@ORD1EXD01.RACKSPACE.CORP> Message-ID: Thanks for the reply all. If I have the UIUD of an instance of another tenant, what more can I do with it? In other words, what is the impact of someone guessing/ inferring UIUID of an instance that they don't belong to'? RBAC would prevent controlling the state of the VM. Is there anyway one can get access to the VM itself? Thanks, -Sriram On Mon, Dec 9, 2013 at 1:42 PM, Brian Schott < brian.schott at nimbisservices.com> wrote: > You probably have to wait about 100 years for that test ;-). However, you > are right that this is system dependent. I came across this bug in mac os > x when googling for the birthday problem table. After a fork, > uuid_generate_random() generates the same UUID in every child! > > > http://stackoverflow.com/questions/2759644/python-multiprocessing-doesnt-play-nicely-with-uuid-uuid4 > http://bugs.python.org/issue8621 > http://openradar.appspot.com/radar?id=334401 > > > ------------------------------------------------- > Brian Schott, CTO > Nimbis Services, Inc. > brian.schott at nimbisservices.com > ph: 443-274-6064 fx: 443-274-6060 > > > > On Dec 9, 2013, at 4:23 PM, Cody Bunch wrote: > > Thanks! I'd replied, but seems I left the list off. The Nova sources > (nova/openstack/common/uuidutils.py) use Pythons uuid.uuid4() to generate > the uuids. The Python source for UUID4 seems to pull from a number of > methods, going to (u)random or pythons random module, so heavily dependent > on system(s) it's being run from: > http://hg.python.org/cpython/file/ec8d2f54dcb2/Lib/uuid.py > > I did throw up a quick test to see if I can find a match... so far I've > generated 20 million uuid's and not had a collision (didn't expect one, but > it's good to see): > https://gist.github.com/bunchc/7880710 > > It also seems that other services may use their own UUID generation or so, > I've not looked into that however. > > -C > ------------------------------ > *From:* Brian Schott [brian.schott at nimbisservices.com] > *Sent:* Monday, December 09, 2013 3:16 PM > *To:* Clark, Robert Graham > *Cc:* openstack-security at lists.openstack.org > *Subject:* Re: [Openstack-security] Deriving Instance UUID > > Rob, > > That is a hard question. The short answer is that it depends on the type > of UUID. Type 1 () is mac address of the server + timestamp, so > probability of guessing another UUID in the system is very high. Type 4 > (random) has 122 bits, so probability of collision is extremely small and > is also dependent on having a good random number generator. A poor > implementation might be predictable. Type 5 (namespace) has fewer bits > depending on the size of the namespace. > > http://en.wikipedia.org/wiki/Birthday_problem#Probability_table > > I think in general web url usage, a bare UUID as authentication mechanism > isn't considered good practice, but it really depends on how many elements > you have in the system, how it is protected from brute-force attacks, etc. > > Brian > > ------------------------------------------------- > Brian Schott, CTO > Nimbis Services, Inc. > brian.schott at nimbisservices.com > ph: 443-274-6064 fx: 443-274-6060 > > > > On Dec 9, 2013, at 3:06 PM, Clark, Robert Graham > wrote: > > Guys, > > Is there any way you know of to infer or guess at the UUID of a compute > instance belonging to another tenant? > > -Rob > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > > -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerrit2 at review.openstack.org Tue Dec 10 01:22:50 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Dec 2013 01:22:50 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit 82353618bc957ceda227ee030d9b2eeebf23658d 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From gerrit2 at review.openstack.org Tue Dec 10 01:29:39 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Dec 2013 01:29:39 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit 00173653d6d07b85c4b10ed4dba98ebeda4560e7 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From fungi at yuggoth.org Tue Dec 10 01:37:57 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 10 Dec 2013 01:37:57 -0000 Subject: [Openstack-security] [Bug 1254619] Re: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" References: <20131125081604.9897.68214.malonedeb@gac.canonical.com> Message-ID: <20131210013758.17727.9310.launchpad@chaenomeles.canonical.com> ** Changed in: ossa Status: Incomplete => Invalid ** Information type changed from Private Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1254619 Title: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" Status in OpenStack Identity (Keystone): Triaged Status in OpenStack Security Advisories: Invalid Bug description: Hi there. Keystone allows the usage of external authentication. This external authentication makes possible for the deployers to integrate external euth methods in Keystone. When it is executed as a WSGI application (for example when executed behind apache using mod_wsgi) the authentication can be made by the web server and the user will be passed down using the REMOTE_USER environment variable. It is also possible to use external authn by creating a custom WSGI filter that will be pipelined. More details of this behaviour can be seen in [0]. [0] http://docs.openstack.org/developer/keystone/external-auth.html Since the Havana release, this code has been refactored and moved to a pluggable mechanism under keystone/auth/plugins/external.py. If I am not wrong, this was introduced in commit 88c319e6bce98082f9a90b8b27726793d5366326 [1]. This code is in stable/havana since that commit, and is currently in the trunk. [1] https://github.com/openstack/keystone/commit/88c319e6bce98082f9a90b8b27726793d5366326 During the review of [2] the ExternalDefault plugin I've realized that the way the plugin extracts the username can lead to impersonation. The excerpt of code that extracts the username is this one [3]:     names = remote_user.split('@')     username = names.pop(0)     domain_id = CONF.identity.default_domain_id     user_ref = auth_info.identity_api.get_user_by_name(username,                                                        domain_id) When Keystone is configured to use the defualt domain, the REMOTE_USER variable is splited by all the "@" and then only the leftfmost part is considered, while the leftovers are discarded. Since a username can contain "@" inside (for example when emails are used as usernames) "john" "john at example.org" and "john at foobar.net" will all get a token belonging to the "john" user. [2] https://review.openstack.org/#/c/50362 [3] https://github.com/openstack/keystone/blob/stable/havana/keystone/auth/plugins/external.py#L39 External authentication opens the door for any deployer to use any authentication mechanism. OpenStack does not ship any external authentication mechanism, but it is perfectly possible to use emails as the usernames (or usernames containing "@", as X509 certificate DNs). For example, a LDAP directory could be configured in Apache to let the users in, and set the REMOTE_USER as the username, instead of the user DN. It is possible to easily reproduce this using devstack as follows:     ubuntu at test-ks-vuln:~/devstack$ cat > localrc << EOF     > ENABLED_SERVICES=key,mysql     > APACHE_ENABLED_SERVICES+=keystone     > EOF     ubuntu at test-ks-vuln:~/devstack$ ./stack.sh     (...)     ubuntu at test-ks-vuln:~/devstack$ source openrc admin admin     ubuntu at test-ks-vuln:~/devstack$ keystone user-list     +----------------------------------+-------+---------+-------------------+     | id | name | enabled | email |     +----------------------------------+-------+---------+-------------------+     | dc90b499a1c0499997bd35ba19a2436c | admin | True | admin at example.com |     | 685cd73e645243c2ba81314cbc5ac89a | demo | True | demo at example.com |     +----------------------------------+-------+---------+-------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-list     +----------------------------------+--------------------+---------+     | id | name | enabled |     +----------------------------------+--------------------+---------+     | d5319bc5b7054e0589ad32048813ee1a | admin | True |     | badfa689e32a4d9fb7d102a7d92ad3b7 | demo | True |     | 110627ae8c534b548d70a5a159ff65ee | invisible_to_admin | True |     | 92484643deb246e680ee3d716a7dfeea | service | True |     +----------------------------------+--------------------+---------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-create --name external_users     +-------------+----------------------------------+     | Property | Value |     +-------------+----------------------------------+     | description | |     Listen 5000     | enabled | True |     Listen 5000     | id | 3ac4e3f06a3548378eb26e3be8dc3952 |     | name | external_users |     +-------------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john --tenant d5319bc5b7054e0589ad32048813ee1a --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     Listen 5000     | enabled | True |     | id | a8fe063e8a124f89ada9526d401aad98 |     | name | john |     | tenantId | d5319bc5b7054e0589ad32048813ee1a |     +----------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john at external_user.com --tenant 3ac4e3f06a3548378eb26e3be8dc3952 --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     | enabled | True |     | id | 6af78b4bdca646a68069d74cdf8e5334 |     | name | john at external_user.com |     | tenantId | 3ac4e3f06a3548378eb26e3be8dc3952 |     +----------+----------------------------------+ So far I've two different users. For the shake of simplicity I will use Apache's basic authentication, so it is needed to add the following excerpt to /etc/apache2/sites-enabled/keystone:     Listen 5001              WSGIDaemonProcess keystone-public2 processes=5 threads=1 user=ubuntu         WSGIProcessGroup keystone-public2         WSGIScriptAlias / /var/www/keystone/main         WSGIApplicationGroup %{GLOBAL}         ErrorLog /var/log/apache2/keystone         LogLevel debug         CustomLog /var/log/apache2/access.log combined                      AuthType Basic             AuthName "Restricted Files"             AuthBasicProvider file             AuthUserFile /opt/stack/htpasswd             Require valid-user               And then, create the external user, and authenticate with it:     ubuntu at test-ks-vuln:~/devstack$ sudo htpasswd -c /opt/stack/htpasswd john at external_user.com     New password:     Re-type new password:     Adding password for user john at external_user.com     ubuntu at test-ks-vuln:~/devstack$ sudo /etc/init.d/apache2 restart     * Restarting web server apache2     * ... waiting     ubuntu at test-ks-vuln:~/devstack$     ubuntu at test-ks-vuln:~$ curl --user john at external_user.com:secret -d '{"auth": {"identity":{ "methods": []}}}' -H "Content-type: application/json" http://172.16.0.63:5001/v3/auth/tokens |python -mjson.tool       % Total % Received % Xferd Average Speed Time Time Time Current                                      Dload Upload Total Spent Left Speed     100 1134 100 1095 100 39 2301 81 --:--:-- --:--:-- --:--:-- 2300     {         "token": {             "catalog": [                 {                     "endpoints": [                         {                             "id": "d0b2b692496a4d2c8a70e63543782aed",                             "interface": "internal",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         },                         {                             "id": "da7fe597a1b84529910e890807b47bdb",                             "interface": "admin",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:35357/v2.0"                         },                         {                             "id": "eeda9fbcffe94588ad15689d33f2c1e9",                             "interface": "public",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         }                     ],                     "id": "14a4bd4966b74503ab2fb47836101824",                     "type": "identity"                 }             ],             "expires_at": "2013-11-26T23:04:55.341085Z",             "extras": {},             "issued_at": "2013-11-25T23:04:55.341121Z",             "methods": [],             "project": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "d5319bc5b7054e0589ad32048813ee1a",                 "name": "admin"             },             "roles": [                 {                     "id": "9fe2ff9ee4384b1894a90878d3e92bab",                     "name": "_member_"                 }             ],             "user": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "a8fe063e8a124f89ada9526d401aad98",                 "name": "john"             }         }     } As you can see, I am getting the id for the user "john" (a8fe063e8a124f89ada9526d401aad98) instead of the user "john at example_user.com" (6af78b4bdca646a68069d74cdf8e5334). The patch in [2] should fix this issue (although it was initially unrelated) since it does not split the username when using the ExternalDefault plugin. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1254619/+subscriptions From gerrit2 at review.openstack.org Tue Dec 10 06:03:28 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Dec 2013 06:03:28 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit b4210d9ffa4c2e619295185e22b7146082f1acb2 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From thierry.carrez+lp at gmail.com Tue Dec 10 09:52:43 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Tue, 10 Dec 2013 09:52:43 -0000 Subject: [Openstack-security] [Bug 1254619] Re: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" References: <20131125081604.9897.68214.malonedeb@gac.canonical.com> Message-ID: <20131210095243.8994.43035.malone@gac.canonical.com> Adding ossn team as they might want to address this in a security note... ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1254619 Title: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" Status in OpenStack Identity (Keystone): Triaged Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: New Bug description: Hi there. Keystone allows the usage of external authentication. This external authentication makes possible for the deployers to integrate external euth methods in Keystone. When it is executed as a WSGI application (for example when executed behind apache using mod_wsgi) the authentication can be made by the web server and the user will be passed down using the REMOTE_USER environment variable. It is also possible to use external authn by creating a custom WSGI filter that will be pipelined. More details of this behaviour can be seen in [0]. [0] http://docs.openstack.org/developer/keystone/external-auth.html Since the Havana release, this code has been refactored and moved to a pluggable mechanism under keystone/auth/plugins/external.py. If I am not wrong, this was introduced in commit 88c319e6bce98082f9a90b8b27726793d5366326 [1]. This code is in stable/havana since that commit, and is currently in the trunk. [1] https://github.com/openstack/keystone/commit/88c319e6bce98082f9a90b8b27726793d5366326 During the review of [2] the ExternalDefault plugin I've realized that the way the plugin extracts the username can lead to impersonation. The excerpt of code that extracts the username is this one [3]:     names = remote_user.split('@')     username = names.pop(0)     domain_id = CONF.identity.default_domain_id     user_ref = auth_info.identity_api.get_user_by_name(username,                                                        domain_id) When Keystone is configured to use the defualt domain, the REMOTE_USER variable is splited by all the "@" and then only the leftfmost part is considered, while the leftovers are discarded. Since a username can contain "@" inside (for example when emails are used as usernames) "john" "john at example.org" and "john at foobar.net" will all get a token belonging to the "john" user. [2] https://review.openstack.org/#/c/50362 [3] https://github.com/openstack/keystone/blob/stable/havana/keystone/auth/plugins/external.py#L39 External authentication opens the door for any deployer to use any authentication mechanism. OpenStack does not ship any external authentication mechanism, but it is perfectly possible to use emails as the usernames (or usernames containing "@", as X509 certificate DNs). For example, a LDAP directory could be configured in Apache to let the users in, and set the REMOTE_USER as the username, instead of the user DN. It is possible to easily reproduce this using devstack as follows:     ubuntu at test-ks-vuln:~/devstack$ cat > localrc << EOF     > ENABLED_SERVICES=key,mysql     > APACHE_ENABLED_SERVICES+=keystone     > EOF     ubuntu at test-ks-vuln:~/devstack$ ./stack.sh     (...)     ubuntu at test-ks-vuln:~/devstack$ source openrc admin admin     ubuntu at test-ks-vuln:~/devstack$ keystone user-list     +----------------------------------+-------+---------+-------------------+     | id | name | enabled | email |     +----------------------------------+-------+---------+-------------------+     | dc90b499a1c0499997bd35ba19a2436c | admin | True | admin at example.com |     | 685cd73e645243c2ba81314cbc5ac89a | demo | True | demo at example.com |     +----------------------------------+-------+---------+-------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-list     +----------------------------------+--------------------+---------+     | id | name | enabled |     +----------------------------------+--------------------+---------+     | d5319bc5b7054e0589ad32048813ee1a | admin | True |     | badfa689e32a4d9fb7d102a7d92ad3b7 | demo | True |     | 110627ae8c534b548d70a5a159ff65ee | invisible_to_admin | True |     | 92484643deb246e680ee3d716a7dfeea | service | True |     +----------------------------------+--------------------+---------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-create --name external_users     +-------------+----------------------------------+     | Property | Value |     +-------------+----------------------------------+     | description | |     Listen 5000     | enabled | True |     Listen 5000     | id | 3ac4e3f06a3548378eb26e3be8dc3952 |     | name | external_users |     +-------------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john --tenant d5319bc5b7054e0589ad32048813ee1a --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     Listen 5000     | enabled | True |     | id | a8fe063e8a124f89ada9526d401aad98 |     | name | john |     | tenantId | d5319bc5b7054e0589ad32048813ee1a |     +----------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john at external_user.com --tenant 3ac4e3f06a3548378eb26e3be8dc3952 --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     | enabled | True |     | id | 6af78b4bdca646a68069d74cdf8e5334 |     | name | john at external_user.com |     | tenantId | 3ac4e3f06a3548378eb26e3be8dc3952 |     +----------+----------------------------------+ So far I've two different users. For the shake of simplicity I will use Apache's basic authentication, so it is needed to add the following excerpt to /etc/apache2/sites-enabled/keystone:     Listen 5001              WSGIDaemonProcess keystone-public2 processes=5 threads=1 user=ubuntu         WSGIProcessGroup keystone-public2         WSGIScriptAlias / /var/www/keystone/main         WSGIApplicationGroup %{GLOBAL}         ErrorLog /var/log/apache2/keystone         LogLevel debug         CustomLog /var/log/apache2/access.log combined                      AuthType Basic             AuthName "Restricted Files"             AuthBasicProvider file             AuthUserFile /opt/stack/htpasswd             Require valid-user               And then, create the external user, and authenticate with it:     ubuntu at test-ks-vuln:~/devstack$ sudo htpasswd -c /opt/stack/htpasswd john at external_user.com     New password:     Re-type new password:     Adding password for user john at external_user.com     ubuntu at test-ks-vuln:~/devstack$ sudo /etc/init.d/apache2 restart     * Restarting web server apache2     * ... waiting     ubuntu at test-ks-vuln:~/devstack$     ubuntu at test-ks-vuln:~$ curl --user john at external_user.com:secret -d '{"auth": {"identity":{ "methods": []}}}' -H "Content-type: application/json" http://172.16.0.63:5001/v3/auth/tokens |python -mjson.tool       % Total % Received % Xferd Average Speed Time Time Time Current                                      Dload Upload Total Spent Left Speed     100 1134 100 1095 100 39 2301 81 --:--:-- --:--:-- --:--:-- 2300     {         "token": {             "catalog": [                 {                     "endpoints": [                         {                             "id": "d0b2b692496a4d2c8a70e63543782aed",                             "interface": "internal",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         },                         {                             "id": "da7fe597a1b84529910e890807b47bdb",                             "interface": "admin",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:35357/v2.0"                         },                         {                             "id": "eeda9fbcffe94588ad15689d33f2c1e9",                             "interface": "public",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         }                     ],                     "id": "14a4bd4966b74503ab2fb47836101824",                     "type": "identity"                 }             ],             "expires_at": "2013-11-26T23:04:55.341085Z",             "extras": {},             "issued_at": "2013-11-25T23:04:55.341121Z",             "methods": [],             "project": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "d5319bc5b7054e0589ad32048813ee1a",                 "name": "admin"             },             "roles": [                 {                     "id": "9fe2ff9ee4384b1894a90878d3e92bab",                     "name": "_member_"                 }             ],             "user": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "a8fe063e8a124f89ada9526d401aad98",                 "name": "john"             }         }     } As you can see, I am getting the id for the user "john" (a8fe063e8a124f89ada9526d401aad98) instead of the user "john at example_user.com" (6af78b4bdca646a68069d74cdf8e5334). The patch in [2] should fix this issue (although it was initially unrelated) since it does not split the username when using the ExternalDefault plugin. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1254619/+subscriptions From pavuluri.kanthi at gmail.com Tue Dec 10 11:38:11 2013 From: pavuluri.kanthi at gmail.com (Kanthi P) Date: Tue, 10 Dec 2013 13:38:11 +0200 Subject: [Openstack-security] Neutron security groups for L2 networks in Havana In-Reply-To: References: Message-ID: Hi Aaron, I missed the latest mail of this thread in my mailbox, so pasting the content of your response below. *The issue is that the nova-api says that by default every instance needs tobe in a default security group that blocks all ingress traffic from outsideand allows all ingress from instances that belong to the same securitygroup. If an instance does not have an ip address we are unable to enforcethe instance->instance communication of members that are part of the samesecurity group (or at least the iptables implementation in place doesn't).There is an extension in neutron that implements port_security that allowsone to disable this so that one can do L2 networking as you want to. Thoughunfortunately, this does not work correctly at this time with nova ascurrently it's calling into neutron to create the security group and attachit to the instance anways. See: https://bugs.launchpad.net/nova/+bug/1175464 .I'm hoping to resolve this issue in the next few weeks.* *There is an extension in neutron that implements port_security that allows* *one to disable this so that one can do L2 networking as you want to. Though* *unfortunately, this does not work correctly at this time with nova as* *currently it's calling into neutron to create the security group and attach* *it to the instance anways. See: https://bugs.launchpad.net/nova/+bug/1175464 .* *I'm hoping to resolve this issue in the next few weeks.* Thanks a lot for the information. As per my understanding of the bug description and the code diff, the fix would prevent nova from adding 'default' security group if neutron is not specifying any security group, only for the case where there are plugins that implement port_security_api and have port_security_enabled=False I have two concerns here: 1. If we don't have any such plugins, then port_security is assumed to be enabled and again default security group would be added by nova, which mandates subnet and L2 networks does not work as expected. 2. If neutron provides security group(non default) via its own api or by means of security plugins, L2 networks still fail due to the same subnet issue. You may ask why security group is needed for L2 networks as the security rules are actually converted to iptables. The reason is that the vNIC may have ipaddress at later point of time and we can add security rules based on this ip then. I am just wondering why should the subnet be mandatory for the vNIC during the instance boot time. Regards, Kanthi On Fri, Nov 8, 2013 at 11:45 AM, Kanthi P wrote: > Hi Aaron, > > Thanks for the reply ! > Yes security groups are mapped to L3/L4 headers, these security rules are > being converted to iptables. > > If we remove the subnet check, we will be able to launch instances without > ipaddress, they just have the mac address. > Users can configure their own ipaddress after they are booted. > > If we use neutron security groups, it provides a default group (on port > basis) which blocks all ingress and allows all egress traffic. > > Later users can configure security groups based on the ip address what > they provided to the vnics. > > I mean to say, ports will have subnet but just that this subnet is not > known to openstack during the instance boot time. > > > > > On Fri, Nov 8, 2013 at 9:42 AM, Aaron Rosen wrote: > >> >> >> >> On Thu, Nov 7, 2013 at 12:23 PM, Kanthi P wrote: >> >>> Hi, >>> >>> I am trying to boot a VM which has a network without subnet in Havana, >>> but it throws an exception saying that subnet is mandatory if quantum >>> security groups are enabled. >>> >>> Here are the commands I used. >>> >>> neutron net-create testNet >>> neutron net-show testNet >>> +---------------------------+--------------------------------------+ >>> | Field | Value | >>> +---------------------------+--------------------------------------+ >>> | admin_state_up | True | >>> | id | 47208beb-2801-4729-bc7b-6532717232fc | >>> | name | testNet | >>> | provider:network_type | local | >>> | provider:physical_network | | >>> | provider:segmentation_id | | >>> | router:external | False | >>> | shared | False | >>> | status | ACTIVE | >>> | subnets | | >>> | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d | >>> +---------------------------+--------------------------------------+ >>> >>> nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic >>> net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1 >>> >>> Here is the piece of code which generated this exception >>> >>> nova/network/neutronv2/api.py >>> >>> if (security_groups and not ( >>> network['subnets'] >>> and network.get('port_security_enabled', True))): >>> >>> raise exception.SecurityGroupCannotBeApplied() >>> >>> >>> Can someone please explain why do we need this check? >>> >> >> Hi Kanthi, >> >> We need this check because because in order to enforce security groups >> the port needs to have an ip_address (i.e: network needs a subnet) since >> Security groups only map to L3/4 headers. Today, nova automatically adds a >> default security group to all instances when booted. Hopefully we can punt >> this task off to neutron in this release by moving the port-creation up on >> the stack to nova-api instead of nova-compute though this isn't the case >> right now. >> >> Aaron >> >>> >>> To my understanding subnet is used for two purposes in terms of security >>> groups >>> 1. To allow dhcp traffic if dhcp is enabled on the subnet, example given >>> below >>> -A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp >>> --sport 67 --dport 68 -j RETURN >>> 2. To avoid ip spoof >>> -A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP >>> >>> Can we remove this so that we can have guests which has nic with just >>> MAC address, guest can configure its own ipaddress. Later if needed they >>> can enable their own security rules via quantum api. >>> >>> _______________________________________________ >>> Openstack-security mailing list >>> Openstack-security at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikal at stillhq.com Tue Dec 10 14:58:44 2013 From: mikal at stillhq.com (Michael Still) Date: Tue, 10 Dec 2013 08:58:44 -0600 Subject: [Openstack-security] Deriving Instance UUID In-Reply-To: References: Message-ID: Well, if you have nova-dns turned on (I don't think anyone has this deployed), or some other DNS plugin, you might be leaking UUIDs to DNS. Is that the sort of thing you're looking for? Michael On Mon, Dec 9, 2013 at 2:06 PM, Clark, Robert Graham wrote: > Guys, > > > > Is there any way you know of to infer or guess at the UUID of a compute > instance belonging to another tenant? > > > > -Rob > > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Rackspace Australia From mikal at stillhq.com Tue Dec 10 15:02:06 2013 From: mikal at stillhq.com (Michael Still) Date: Tue, 10 Dec 2013 09:02:06 -0600 Subject: [Openstack-security] Deriving Instance UUID In-Reply-To: References: <517C9FFA-AACA-419B-A873-61A5519B0894@nimbisservices.com> <327FAB32C28C564DAA23CE6D03789DBCA8CCD675@ORD1EXD01.RACKSPACE.CORP> Message-ID: Hmmm. If you know the UUID of an instance, and can assume default configurations, then you know a bunch of information about how the files on the hypervisor disk are laid out. Assuming: - you're running an old release without patches (I'm thinking Folsom from memory?) - and have file injection turned on - and know the path to another instance's data - then that might make it possible to manipulate files in the instance directory This is very theoretical though, there's a lot of assumptions there. Michael On Mon, Dec 9, 2013 at 4:52 PM, Sriram Subramanian wrote: > Thanks for the reply all. > > If I have the UIUD of an instance of another tenant, what more can I do with > it? In other words, what is the impact of someone guessing/ inferring UIUID > of an instance that they don't belong to'? > > RBAC would prevent controlling the state of the VM. Is there anyway one can > get access to the VM itself? > > Thanks, > -Sriram > > > On Mon, Dec 9, 2013 at 1:42 PM, Brian Schott > wrote: >> >> You probably have to wait about 100 years for that test ;-). However, you >> are right that this is system dependent. I came across this bug in mac os x >> when googling for the birthday problem table. After a fork, >> uuid_generate_random() generates the same UUID in every child! >> >> >> http://stackoverflow.com/questions/2759644/python-multiprocessing-doesnt-play-nicely-with-uuid-uuid4 >> http://bugs.python.org/issue8621 >> http://openradar.appspot.com/radar?id=334401 >> >> >> ------------------------------------------------- >> Brian Schott, CTO >> Nimbis Services, Inc. >> brian.schott at nimbisservices.com >> ph: 443-274-6064 fx: 443-274-6060 >> >> >> >> On Dec 9, 2013, at 4:23 PM, Cody Bunch wrote: >> >> Thanks! I'd replied, but seems I left the list off. The Nova sources >> (nova/openstack/common/uuidutils.py) use Pythons uuid.uuid4() to generate >> the uuids. The Python source for UUID4 seems to pull from a number of >> methods, going to (u)random or pythons random module, so heavily dependent >> on system(s) it's being run from: >> http://hg.python.org/cpython/file/ec8d2f54dcb2/Lib/uuid.py >> >> I did throw up a quick test to see if I can find a match... so far I've >> generated 20 million uuid's and not had a collision (didn't expect one, but >> it's good to see): >> https://gist.github.com/bunchc/7880710 >> >> It also seems that other services may use their own UUID generation or so, >> I've not looked into that however. >> >> -C >> ________________________________ >> From: Brian Schott [brian.schott at nimbisservices.com] >> Sent: Monday, December 09, 2013 3:16 PM >> To: Clark, Robert Graham >> Cc: openstack-security at lists.openstack.org >> Subject: Re: [Openstack-security] Deriving Instance UUID >> >> Rob, >> >> That is a hard question. The short answer is that it depends on the type >> of UUID. Type 1 () is mac address of the server + timestamp, so probability >> of guessing another UUID in the system is very high. Type 4 (random) has >> 122 bits, so probability of collision is extremely small and is also >> dependent on having a good random number generator. A poor implementation >> might be predictable. Type 5 (namespace) has fewer bits depending on the >> size of the namespace. >> >> http://en.wikipedia.org/wiki/Birthday_problem#Probability_table >> >> I think in general web url usage, a bare UUID as authentication mechanism >> isn't considered good practice, but it really depends on how many elements >> you have in the system, how it is protected from brute-force attacks, etc. >> >> Brian >> >> ------------------------------------------------- >> Brian Schott, CTO >> Nimbis Services, Inc. >> brian.schott at nimbisservices.com >> ph: 443-274-6064 fx: 443-274-6060 >> >> >> >> On Dec 9, 2013, at 3:06 PM, Clark, Robert Graham >> wrote: >> >> Guys, >> >> Is there any way you know of to infer or guess at the UUID of a compute >> instance belonging to another tenant? >> >> -Rob >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> >> >> >> _______________________________________________ >> Openstack-security mailing list >> Openstack-security at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security >> > > > > -- > Thanks, > -Sriram > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -- Rackspace Australia From rbryant at redhat.com Tue Dec 10 15:09:49 2013 From: rbryant at redhat.com (Russell Bryant) Date: Tue, 10 Dec 2013 10:09:49 -0500 Subject: [Openstack-security] Deriving Instance UUID In-Reply-To: References: <517C9FFA-AACA-419B-A873-61A5519B0894@nimbisservices.com> <327FAB32C28C564DAA23CE6D03789DBCA8CCD675@ORD1EXD01.RACKSPACE.CORP> Message-ID: <52A72EBD.7020801@redhat.com> On 12/10/2013 10:02 AM, Michael Still wrote: > Hmmm. > > If you know the UUID of an instance, and can assume default > configurations, then you know a bunch of information about how the > files on the hypervisor disk are laid out. > > Assuming: > - you're running an old release without patches (I'm thinking Folsom > from memory?) > - and have file injection turned on > - and know the path to another instance's data > - then that might make it possible to manipulate files in the > instance directory > > This is very theoretical though, there's a lot of assumptions there. Assuming you can get at the host filesystem, right? And if you can get to the host filesystem, well ... there's plenty possibilities for bad things. -- Russell Bryant From eric at windisch.us Tue Dec 10 15:34:38 2013 From: eric at windisch.us (Eric Windisch) Date: Tue, 10 Dec 2013 10:34:38 -0500 Subject: [Openstack-security] Deriving Instance UUID In-Reply-To: References: Message-ID: On Mon, Dec 9, 2013 at 3:06 PM, Clark, Robert Graham wrote: > Guys, > > > > Is there any way you know of to infer or guess at the UUID of a compute > instance belonging to another tenant? > > You can infer or guess at the EC2 IDs. These are mapped in the database to the UUIDs which are considerably harder to guess directly. Reading through the EC2 API code, however, I don't see anything that would make it obviously simple for an attacker to get the UUID mapped to any arbitrary EC2 ID. Regards, Eric Windisch -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikal at stillhq.com Tue Dec 10 15:40:31 2013 From: mikal at stillhq.com (Michael Still) Date: Tue, 10 Dec 2013 09:40:31 -0600 Subject: [Openstack-security] Deriving Instance UUID In-Reply-To: <52A72EBD.7020801@redhat.com> References: <517C9FFA-AACA-419B-A873-61A5519B0894@nimbisservices.com> <327FAB32C28C564DAA23CE6D03789DBCA8CCD675@ORD1EXD01.RACKSPACE.CORP> <52A72EBD.7020801@redhat.com> Message-ID: Well, that's the Folsom with file injection bit. You can break out of the hypervisor using the bugs in file injection we fixed back then. Like I said, pretty theoretical. Michael On Tue, Dec 10, 2013 at 9:09 AM, Russell Bryant wrote: > On 12/10/2013 10:02 AM, Michael Still wrote: >> Hmmm. >> >> If you know the UUID of an instance, and can assume default >> configurations, then you know a bunch of information about how the >> files on the hypervisor disk are laid out. >> >> Assuming: >> - you're running an old release without patches (I'm thinking Folsom >> from memory?) >> - and have file injection turned on >> - and know the path to another instance's data >> - then that might make it possible to manipulate files in the >> instance directory >> >> This is very theoretical though, there's a lot of assumptions there. > > Assuming you can get at the host filesystem, right? And if you can get > to the host filesystem, well ... there's plenty possibilities for bad > things. > > -- > Russell Bryant > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security -- Rackspace Australia From mhu at enovance.com Tue Dec 10 17:00:57 2013 From: mhu at enovance.com (Matthieu Huin) Date: Tue, 10 Dec 2013 17:00:57 -0000 Subject: [Openstack-security] [Bug 1240382] Re: python-oauth2 dependency is unmaintained and has security issues References: <20131016072040.28005.15743.malonedeb@chaenomeles.canonical.com> Message-ID: <20131210170057.17290.57292.malone@chaenomeles.canonical.com> Some notes Steve Martinelli sent me to help: 1. The following are spots where we currently use the old library: https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/core.py#L33 (to 40 - plug points for the library) https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/core.py#L123 (splitting headers) https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/controllers.py#L181 (to 192 - verifying request for request token call) https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/controllers.py#L251 (to 267 - verifying request for access token call) https://github.com/openstack/keystone/blob/master/keystone/auth/plugins/oauth1.py#L57 (to 72 - verifying request for authenticate call) https://github.com/openstack/keystone/blob/master/keystone/tests/test_v3_oauth1.py (a bunch of places) 2a. The part that bugs me about oauthlib is the fact that you have to implement an interface (RequestValidator), https://oauthlib.readthedocs.org/en/latest/oauth1/server.html#implement-a-validator . At least this is my impression upon reading the docs. 2b. Actual RequestValidator class: https://github.com/idan/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py , raises a lot of not implemented exceptions. 3. I did find one instance of a coder that had to switch from using python-oauth2 to oauthlib, for a client application he was writing, it'll be handy for migrating the tests: https://github.com/gfairchild/yelpapi/commit/71b0a947d56445fe71750255827a07c56ce3f1e5 Indeed, the RequestValidator might be the tricky part. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1240382 Title: python-oauth2 dependency is unmaintained and has security issues Status in OpenStack Identity (Keystone): Confirmed Bug description: oauth2 is not maintained and have 2 CVE issues CVE-2013-4346 and CVE-2013-4347 and is not Python3 compatible can you remove this dependency (maybe switching to requests ? ) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240382/+subscriptions From gerrit2 at review.openstack.org Tue Dec 10 22:14:35 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Dec 2013 22:14:35 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change I24c77188ebb05ef57b378798584e3829d55827f2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/60727 Log: commit 208550140869f6a30e39883a49fe3d1d8b0a54d8 Author: Jamie Lennox Date: Mon Dec 9 11:41:03 2013 +1000 Add OS-SIMPLE-CERT extension This provides a very basic mechanism for retrieving the CA and signing certificate from the identity service. It aims to simply replicate the functionality provided by the v2.0 API. SecurityImpact Change-Id: I24c77188ebb05ef57b378798584e3829d55827f2 Partial-Bug: #1259011 From gerrit2 at review.openstack.org Tue Dec 10 23:09:56 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Dec 2013 23:09:56 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40692 Log: commit f97f4f2c33ca6cb7a13dd7047b44e4de4590a316 Author: Simo Sorce Date: Wed Aug 7 14:16:28 2013 -0400 Key Distribution Server API for distribution of keys in support of: https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation SecurityImpact DocImpact Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df From nkinder at redhat.com Tue Dec 10 23:13:55 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 10 Dec 2013 23:13:55 -0000 Subject: [Openstack-security] [Bug 1254619] Re: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" References: <20131125081604.9897.68214.malonedeb@gac.canonical.com> Message-ID: <20131210231355.25768.43297.malone@wampee.canonical.com> I think it makes sense to release an OSSN for this. I'll work on writing it up. ** Changed in: ossn Status: New => In Progress ** Changed in: ossn Assignee: (unassigned) => Nathan Kinder (nkinder) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1254619 Title: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" Status in OpenStack Identity (Keystone): Triaged Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: In Progress Bug description: Hi there. Keystone allows the usage of external authentication. This external authentication makes possible for the deployers to integrate external euth methods in Keystone. When it is executed as a WSGI application (for example when executed behind apache using mod_wsgi) the authentication can be made by the web server and the user will be passed down using the REMOTE_USER environment variable. It is also possible to use external authn by creating a custom WSGI filter that will be pipelined. More details of this behaviour can be seen in [0]. [0] http://docs.openstack.org/developer/keystone/external-auth.html Since the Havana release, this code has been refactored and moved to a pluggable mechanism under keystone/auth/plugins/external.py. If I am not wrong, this was introduced in commit 88c319e6bce98082f9a90b8b27726793d5366326 [1]. This code is in stable/havana since that commit, and is currently in the trunk. [1] https://github.com/openstack/keystone/commit/88c319e6bce98082f9a90b8b27726793d5366326 During the review of [2] the ExternalDefault plugin I've realized that the way the plugin extracts the username can lead to impersonation. The excerpt of code that extracts the username is this one [3]:     names = remote_user.split('@')     username = names.pop(0)     domain_id = CONF.identity.default_domain_id     user_ref = auth_info.identity_api.get_user_by_name(username,                                                        domain_id) When Keystone is configured to use the defualt domain, the REMOTE_USER variable is splited by all the "@" and then only the leftfmost part is considered, while the leftovers are discarded. Since a username can contain "@" inside (for example when emails are used as usernames) "john" "john at example.org" and "john at foobar.net" will all get a token belonging to the "john" user. [2] https://review.openstack.org/#/c/50362 [3] https://github.com/openstack/keystone/blob/stable/havana/keystone/auth/plugins/external.py#L39 External authentication opens the door for any deployer to use any authentication mechanism. OpenStack does not ship any external authentication mechanism, but it is perfectly possible to use emails as the usernames (or usernames containing "@", as X509 certificate DNs). For example, a LDAP directory could be configured in Apache to let the users in, and set the REMOTE_USER as the username, instead of the user DN. It is possible to easily reproduce this using devstack as follows:     ubuntu at test-ks-vuln:~/devstack$ cat > localrc << EOF     > ENABLED_SERVICES=key,mysql     > APACHE_ENABLED_SERVICES+=keystone     > EOF     ubuntu at test-ks-vuln:~/devstack$ ./stack.sh     (...)     ubuntu at test-ks-vuln:~/devstack$ source openrc admin admin     ubuntu at test-ks-vuln:~/devstack$ keystone user-list     +----------------------------------+-------+---------+-------------------+     | id | name | enabled | email |     +----------------------------------+-------+---------+-------------------+     | dc90b499a1c0499997bd35ba19a2436c | admin | True | admin at example.com |     | 685cd73e645243c2ba81314cbc5ac89a | demo | True | demo at example.com |     +----------------------------------+-------+---------+-------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-list     +----------------------------------+--------------------+---------+     | id | name | enabled |     +----------------------------------+--------------------+---------+     | d5319bc5b7054e0589ad32048813ee1a | admin | True |     | badfa689e32a4d9fb7d102a7d92ad3b7 | demo | True |     | 110627ae8c534b548d70a5a159ff65ee | invisible_to_admin | True |     | 92484643deb246e680ee3d716a7dfeea | service | True |     +----------------------------------+--------------------+---------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-create --name external_users     +-------------+----------------------------------+     | Property | Value |     +-------------+----------------------------------+     | description | |     Listen 5000     | enabled | True |     Listen 5000     | id | 3ac4e3f06a3548378eb26e3be8dc3952 |     | name | external_users |     +-------------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john --tenant d5319bc5b7054e0589ad32048813ee1a --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     Listen 5000     | enabled | True |     | id | a8fe063e8a124f89ada9526d401aad98 |     | name | john |     | tenantId | d5319bc5b7054e0589ad32048813ee1a |     +----------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john at external_user.com --tenant 3ac4e3f06a3548378eb26e3be8dc3952 --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     | enabled | True |     | id | 6af78b4bdca646a68069d74cdf8e5334 |     | name | john at external_user.com |     | tenantId | 3ac4e3f06a3548378eb26e3be8dc3952 |     +----------+----------------------------------+ So far I've two different users. For the shake of simplicity I will use Apache's basic authentication, so it is needed to add the following excerpt to /etc/apache2/sites-enabled/keystone:     Listen 5001              WSGIDaemonProcess keystone-public2 processes=5 threads=1 user=ubuntu         WSGIProcessGroup keystone-public2         WSGIScriptAlias / /var/www/keystone/main         WSGIApplicationGroup %{GLOBAL}         ErrorLog /var/log/apache2/keystone         LogLevel debug         CustomLog /var/log/apache2/access.log combined                      AuthType Basic             AuthName "Restricted Files"             AuthBasicProvider file             AuthUserFile /opt/stack/htpasswd             Require valid-user               And then, create the external user, and authenticate with it:     ubuntu at test-ks-vuln:~/devstack$ sudo htpasswd -c /opt/stack/htpasswd john at external_user.com     New password:     Re-type new password:     Adding password for user john at external_user.com     ubuntu at test-ks-vuln:~/devstack$ sudo /etc/init.d/apache2 restart     * Restarting web server apache2     * ... waiting     ubuntu at test-ks-vuln:~/devstack$     ubuntu at test-ks-vuln:~$ curl --user john at external_user.com:secret -d '{"auth": {"identity":{ "methods": []}}}' -H "Content-type: application/json" http://172.16.0.63:5001/v3/auth/tokens |python -mjson.tool       % Total % Received % Xferd Average Speed Time Time Time Current                                      Dload Upload Total Spent Left Speed     100 1134 100 1095 100 39 2301 81 --:--:-- --:--:-- --:--:-- 2300     {         "token": {             "catalog": [                 {                     "endpoints": [                         {                             "id": "d0b2b692496a4d2c8a70e63543782aed",                             "interface": "internal",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         },                         {                             "id": "da7fe597a1b84529910e890807b47bdb",                             "interface": "admin",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:35357/v2.0"                         },                         {                             "id": "eeda9fbcffe94588ad15689d33f2c1e9",                             "interface": "public",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         }                     ],                     "id": "14a4bd4966b74503ab2fb47836101824",                     "type": "identity"                 }             ],             "expires_at": "2013-11-26T23:04:55.341085Z",             "extras": {},             "issued_at": "2013-11-25T23:04:55.341121Z",             "methods": [],             "project": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "d5319bc5b7054e0589ad32048813ee1a",                 "name": "admin"             },             "roles": [                 {                     "id": "9fe2ff9ee4384b1894a90878d3e92bab",                     "name": "_member_"                 }             ],             "user": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "a8fe063e8a124f89ada9526d401aad98",                 "name": "john"             }         }     } As you can see, I am getting the id for the user "john" (a8fe063e8a124f89ada9526d401aad98) instead of the user "john at example_user.com" (6af78b4bdca646a68069d74cdf8e5334). The patch in [2] should fix this issue (although it was initially unrelated) since it does not split the username when using the ExternalDefault plugin. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1254619/+subscriptions From gerrit2 at review.openstack.org Tue Dec 10 23:41:43 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 10 Dec 2013 23:41:43 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit 69938304ab9f9c6e8b425055748a4af5cd60f4a3 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From gerrit2 at review.openstack.org Wed Dec 11 01:41:03 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Dec 2013 01:41:03 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change I24c77188ebb05ef57b378798584e3829d55827f2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/60727 Log: commit 79213cd88f42567bca2b0da3bbd094ee0fde70f7 Author: Jamie Lennox Date: Mon Dec 9 11:41:03 2013 +1000 Add OS-SIMPLE-CERT extension This provides a very basic mechanism for retrieving the CA and signing certificate from the identity service. It aims to simply replicate the functionality provided by the v2.0 API. SecurityImpact Change-Id: I24c77188ebb05ef57b378798584e3829d55827f2 Partial-Bug: #1259011 From gerrit2 at review.openstack.org Wed Dec 11 03:19:19 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Dec 2013 03:19:19 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit 7d03384a910ab32ee0aa39d3360f5f12b8590e25 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From thierry.carrez+lp at gmail.com Wed Dec 11 15:00:11 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Dec 2013 15:00:11 -0000 Subject: [Openstack-security] [Bug 1192966] Re: Potentially insecure dependency loading References: <20130620132537.19232.33035.malonedeb@gac.canonical.com> Message-ID: <20131211150011.17166.54762.launchpad@chaenomeles.canonical.com> ** No longer affects: ossa -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1192966 Title: Potentially insecure dependency loading Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Object Storage (Swift): New Bug description: Grant Murphy and Dhiru Kholia from Red Hat Product Security Team reported the following potential issue. This is actually a setuptools issue but which we may be able to workaround, if we end up being affected: --- A security flaw was found in the way Python Setuptools, a collection of enhancements to the Python distutils module, that allows more easily to build and distribute Python packages, performed integrity checks when loading external resources, previously extracted from zipped Python Egg archives(formerly if the timestamp and file size of a particular resource expanded from the archive matched the original values, the resource was successfully loaded). A local attacker, with write permission into the Python's EGG cache (directory) could use this flaw to provide a specially-crafted resource (in expanded form) that, when loaded in an application requiring that resource to (be able to) run, would lead to arbitrary code execution with the privileges of the user running the application. It seems to be pretty common for Python applications to do something like os.evironment['PYTHON_EGG_CACHE'] = /tmp, prior to importing dependencies. If the dependency contains a .so Python must unpack it into the cache directory to be able to load it. However if an attacker pre-emptively places a .so in the same location as long as the file has the same timestamp and file size it will be loaded. --- Glance and Swift both set PYTHON_EGG_CACHE to '/tmp' : ./glance/glance/cmd/control.py: os.environ['PYTHON_EGG_CACHE'] = '/tmp' ./swift/swift/common/manager.py: os.environ['PYTHON_EGG_CACHE'] = '/tmp' If we are immediately vulnerable to this (i.e. if stuff loaded from those commands contains an .so, if I understand correctly), we could workaround it by setting it to /tmp/secure-dir-XXXXXX/ until setuptools upstream fixes this. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1192966/+subscriptions From thierry.carrez+lp at gmail.com Wed Dec 11 14:58:30 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Dec 2013 14:58: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: <20131211145830.25867.47034.malone@wampee.canonical.com> Switching to public, and let's see what the OSSG guys think about this. ** Information type changed from Private Security to Public Security ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): New Status in OpenStack Security Advisories: Incomplete 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 Wed Dec 11 14:59:42 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Wed, 11 Dec 2013 14:59:42 -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: <20131211145943.6924.31429.malone@soybean.canonical.com> OSSG: please see backlog of the discussion on this. Do you think it warrants an advisory if the code is vulnerable but is not really found in the wild ? -- 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): New Status in OpenStack Security Advisories: Incomplete 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 Wed Dec 11 20:52:27 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 11 Dec 2013 12:52:27 -0800 Subject: [Openstack-security] [Bug 1244025] Re: Remote security group criteria don't work in Midonet plugin In-Reply-To: <20131211145943.6924.31429.malone@soybean.canonical.com> References: <20131024030525.12859.50542.malonedeb@gac.canonical.com> <20131211145943.6924.31429.malone@soybean.canonical.com> Message-ID: I have commented on the bug. Thanks for bringing this to OSSG's attention. Cheers, -bryan On Wed, Dec 11, 2013 at 6:59 AM, Thierry Carrez wrote: > OSSG: please see backlog of the discussion on this. Do you think it > warrants an advisory if the code is vulnerable but is not really found > in the wild ? > > -- > 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): > New > Status in OpenStack Security Advisories: > Incomplete > > 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 > > _______________________________________________ > Openstack-security mailing list > Openstack-security at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdpayne at acm.org Wed Dec 11 20:51:49 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 11 Dec 2013 20:51:49 -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: <20131211205149.8622.62584.malone@gac.canonical.com> After reading through this thread, I would recommend issuing an advisory. I think that it could be worded to say something like "real world deployments should have already been patched by Midokura, however users wanting to verify that they have the patch in place can take the following steps...". -- 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): New Status in OpenStack Security Advisories: Incomplete 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 Wed Dec 11 20:52:27 2013 From: bdpayne at acm.org (Bryan D. Payne) Date: Wed, 11 Dec 2013 20:52:27 -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> <20131211145943.6924.31429.malone@soybean.canonical.com> Message-ID: I have commented on the bug. Thanks for bringing this to OSSG's attention. Cheers, -bryan On Wed, Dec 11, 2013 at 6:59 AM, Thierry Carrez wrote: > OSSG: please see backlog of the discussion on this. Do you think it > warrants an advisory if the code is vulnerable but is not really found > in the wild ? > > -- > 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): > New > Status in OpenStack Security Advisories: > Incomplete > > 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 > > _______________________________________________ > 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/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): New Status in OpenStack Security Advisories: Incomplete 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 Wed Dec 11 23:46:55 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 11 Dec 2013 23:46:55 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40692 Log: commit 9ccf2d4f0ab8584f75e4affa917b62f8627ed694 Author: Simo Sorce Date: Wed Aug 7 14:16:28 2013 -0400 Key Distribution Server API for distribution of keys in support of: https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation SecurityImpact DocImpact Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df From gerrit2 at review.openstack.org Thu Dec 12 07:16:28 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Dec 2013 07:16:28 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit 909fcdddf1202641fbe870ef0eeb589e5793a72a 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From mhu at enovance.com Thu Dec 12 14:38:16 2013 From: mhu at enovance.com (Matthieu Huin) Date: Thu, 12 Dec 2013 14:38:16 -0000 Subject: [Openstack-security] [Bug 1240382] Re: python-oauth2 dependency is unmaintained and has security issues References: <20131016072040.28005.15743.malonedeb@chaenomeles.canonical.com> Message-ID: <20131212143817.25935.72787.malone@wampee.canonical.com> @pmakowski, had a quick look, seems to be a client lib. it could be useful for testing. 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/1240382 Title: python-oauth2 dependency is unmaintained and has security issues Status in OpenStack Identity (Keystone): Confirmed Bug description: oauth2 is not maintained and have 2 CVE issues CVE-2013-4346 and CVE-2013-4347 and is not Python3 compatible can you remove this dependency (maybe switching to requests ? ) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240382/+subscriptions From gerrit2 at review.openstack.org Thu Dec 12 16:15:34 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Dec 2013 16:15:34 +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 cbe5383107ae3a868d74ec0da944ac5a56b8521d Author: Dan Genin Date: Thu Dec 12 11:12:44 2013 -0500 Add ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From gerrit2 at review.openstack.org Thu Dec 12 16:24:08 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Dec 2013 16:24:08 +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 0d2ca05aac2257c615850f52d45e5a8ca3b3c4c2 Author: Dan Genin Date: Thu Dec 12 11:25:57 2013 -0500 Add ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From gerrit2 at review.openstack.org Thu Dec 12 16:35:15 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Dec 2013 16:35:15 +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 d529407fde849029546e8dc7140fa833172c9259 Author: Dan Genin Date: Thu Dec 12 11:25:57 2013 -0500 Add ephemeral storage encryption for LVM back-end images This patch adds ephemeral storage encryption for LVM back-end instances. Encryption is implemented by passing all data written to and read from the logical volumes through a dm-crypt layer. Most instance operations such as pause/continue, suspend/resume, reboot, etc. are supported. Snapshots are also supported but are not encrypted at present. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From gerrit2 at review.openstack.org Thu Dec 12 21:57:42 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Thu, 12 Dec 2013 21:57:42 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change I24c77188ebb05ef57b378798584e3829d55827f2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/60727 Log: commit 0b146236700e009951e365a9ada252bdba2dd196 Author: Jamie Lennox Date: Mon Dec 9 11:41:03 2013 +1000 Add OS-SIMPLE-CERT extension This provides a very basic mechanism for retrieving the CA and signing certificate from the identity service. It aims to simply replicate the functionality provided by the v2.0 API. SecurityImpact Change-Id: I24c77188ebb05ef57b378798584e3829d55827f2 Partial-Bug: #1259011 From gerrit2 at review.openstack.org Fri Dec 13 01:45:44 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Fri, 13 Dec 2013 01:45:44 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit e6306a12e17a462d6d3f41bf0d5d230b233b09e2 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From fungi at yuggoth.org Fri Dec 13 16:31:58 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 13 Dec 2013 16: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: <20131213163158.17135.9520.malone@chaenomeles.canonical.com> Bryan's suggestion seems reasonable. Brandon/Dave: What is the easiest means for Midonet users running your modified stable/havana distribution to directly detect and confirm that the issue has been patched? Check that MidonetPluginV2._bind_port_to_sgs() in neutron/plugins/midonet/plugin.py calls self.client.add_ip_addr_to_ip_addr_group() rather than self.client.add_port_to_port_group_by_name()? -- 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): New Status in OpenStack Security Advisories: Incomplete 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 Dec 16 00:19:05 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Dec 2013 00:19:05 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change I24c77188ebb05ef57b378798584e3829d55827f2 Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/60727 Log: commit 602aa6b90adb11103e2683a34fa4e0e13a3e8c69 Author: Jamie Lennox Date: Mon Dec 9 11:41:03 2013 +1000 Add OS-SIMPLE-CERT extension This provides a very basic mechanism for retrieving the CA and signing certificate from the identity service. It aims to simply replicate the functionality provided by the v2.0 API. SecurityImpact Change-Id: I24c77188ebb05ef57b378798584e3829d55827f2 Partial-Bug: #1259011 From gerrit2 at review.openstack.org Mon Dec 16 04:28:00 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Dec 2013 04:28:00 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit 9f117b8afc4c49dc15175cf79ebf477d1893355b 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From gerrit2 at review.openstack.org Mon Dec 16 04:28:12 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Dec 2013 04:28:12 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59604 Log: commit b083fd7bcfdc6ef342b34ec92aa071fb214519bc 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 blueprint: key-distribution-server Change-Id: I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 From gerrit2 at review.openstack.org Mon Dec 16 04:44:07 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Dec 2013 04:44:07 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59603 Log: commit df2432f655d8d87c177cf227290db88a968d626d 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. Adds the first real routes to the KDS to allow storing keys. SecurityImpact blueprint: key-distribution-server Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de From gerrit2 at review.openstack.org Mon Dec 16 04:44:14 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Dec 2013 04:44:14 +0000 Subject: [Openstack-security] [openstack/keystone] 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/59604 Log: commit d5e615ff1d79ea3b3b198a705839b69a17ad8c95 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 blueprint: key-distribution-server Change-Id: I4dbd23adb0bdd9011eb9a0b45e30dd862d390473 From 1251647 at bugs.launchpad.net Mon Dec 16 05:13:40 2013 From: 1251647 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 Dec 2013 05:13:40 -0000 Subject: [Openstack-security] [Bug 1251647] Fix proposed to heat (master) References: <20131115144107.27303.99752.malonedeb@gac.canonical.com> Message-ID: <20131216051341.7483.23082.malone@soybean.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/62295 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251647 Title: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason Status in Orchestration API (Heat): In Progress Status in OpenStack Security Advisories: Invalid Bug description: In the following commit: https://github.com/openstack/heat/commit/58cd52624b50476ed5ed1c5c0ba7cb1b4d7ba66d ... a decision was introduced to encrypt authentication information using unauthenticated AES-CFB. There's a few things I don't like about that commit, but suffice to say that heat/engine/auth.py should probably not be a place where symmetric crypto decisions are made. I've been told that there's a new public API for symmetric encryption, SymmetricCrypto that lives in openstack/common/crypto/utils.py: https://github.com/openstack/oslo- incubator/blob/master/openstack/common/crypto/utils.py#L99 I think that also gets a few things wrong, but at the very least Heat should use a centralized thing for encrypting stuff. (I'd love to complain about and work on SymmetricCrypto too, but that's not this ticket :) To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1251647/+subscriptions From 1251647 at bugs.launchpad.net Mon Dec 16 09:50:42 2013 From: 1251647 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 16 Dec 2013 09:50:42 -0000 Subject: [Openstack-security] [Bug 1251647] Fix merged to heat (master) References: <20131115144107.27303.99752.malonedeb@gac.canonical.com> Message-ID: <20131216095042.8529.32356.malone@gac.canonical.com> Reviewed: https://review.openstack.org/59684 Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=37919c6b955e9f9b87d4dc76056efce858c63b1d Submitter: Jenkins Branch: master commit 37919c6b955e9f9b87d4dc76056efce858c63b1d Author: Angus Salkeld Date: Tue Dec 3 21:24:36 2013 +1100 oslo: add the crypto module This is to be used instead of the hand rolled heat/common/crypt.py. Partial-bug: #1251647 Change-Id: I622b9d0c942075f99fdbaff470906123c631504a -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251647 Title: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason Status in Orchestration API (Heat): In Progress Status in OpenStack Security Advisories: Invalid Bug description: In the following commit: https://github.com/openstack/heat/commit/58cd52624b50476ed5ed1c5c0ba7cb1b4d7ba66d ... a decision was introduced to encrypt authentication information using unauthenticated AES-CFB. There's a few things I don't like about that commit, but suffice to say that heat/engine/auth.py should probably not be a place where symmetric crypto decisions are made. I've been told that there's a new public API for symmetric encryption, SymmetricCrypto that lives in openstack/common/crypto/utils.py: https://github.com/openstack/oslo- incubator/blob/master/openstack/common/crypto/utils.py#L99 I think that also gets a few things wrong, but at the very least Heat should use a centralized thing for encrypting stuff. (I'd love to complain about and work on SymmetricCrypto too, but that's not this ticket :) To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1251647/+subscriptions From gerrit2 at review.openstack.org Mon Dec 16 14:44:41 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Dec 2013 14:44:41 +0000 Subject: [Openstack-security] [openstack/keystone] SecurityImpact review request change Id61e71cb3ea7c6bc51783af067fbbbe4c9bffafe Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/61916 Log: commit 4e996ec0975a28f5ceabf8d77cefe460f576cabc Author: Steve Martinelli Date: Thu Dec 12 21:47:38 2013 -0600 trustee unable to perform role based operations on trust There was a typo in a conditional that checked the trustor twice, instead of trustee and trustor. The typo was preventing a trustee from being able to list or get or check roles that were delegated. Also, removed the spurious check of is_admin from said conditional (_is_trustor_trustee_admin), and renamed it to _is_trustor_trustee. An additional check, to see if a trust existed, was removed since it was repeated unnecessarily. Added a test to cover the gap that was discovered in the bug report. SecurityImpact Change-Id: Id61e71cb3ea7c6bc51783af067fbbbe4c9bffafe Closes-Bug: 1261104 From thierry.carrez+lp at gmail.com Mon Dec 16 16:53:43 2013 From: thierry.carrez+lp at gmail.com (Thierry Carrez) Date: Mon, 16 Dec 2013 16:53:43 -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: <20131216165345.7029.6745.launchpad@soybean.canonical.com> ** Changed in: ossa Importance: Undecided => Medium ** Changed in: ossa Status: Incomplete => Confirmed -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): 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 Dec 16 22:28:50 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Dec 2013 22:28:50 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40692 Log: commit f0c445eab574a4ba6e1ee71354945ef6bd2b73d4 Author: Simo Sorce Date: Wed Aug 7 14:16:28 2013 -0400 Key Distribution Server API for distribution of keys in support of: https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation SecurityImpact DocImpact Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df From 1231263 at bugs.launchpad.net Mon Dec 16 22:41:41 2013 From: 1231263 at bugs.launchpad.net (Alan Pevec) Date: Mon, 16 Dec 2013 22:41:41 -0000 Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been print in log by some API call References: <20130926055439.7490.27811.malonedeb@gac.canonical.com> Message-ID: <20131216224144.8887.67950.launchpad@gac.canonical.com> ** Changed in: nova/havana Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1231263 Title: Clear text password has been print in log by some API call Status in OpenStack Compute (Nova): Fix Released Status in OpenStack Compute (nova) havana series: Fix Released Bug description: In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova. i.e: 2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': , 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103 2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926 This is not secue which the password should be replaced by *** To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1231263/+subscriptions From gerrit2 at review.openstack.org Mon Dec 16 23:18:47 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Mon, 16 Dec 2013 23:18:47 +0000 Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review request change Ic00009e635f81427ba909a9ce4ba168f14ff51df Message-ID: Hi, I'd like you to take a look at this patch for potential SecurityImpact. https://review.openstack.org/40692 Log: commit 81506ce088335a43ae96aa9b485222bd3c03ed11 Author: Simo Sorce Date: Wed Aug 7 14:16:28 2013 -0400 Key Distribution Server API for distribution of keys in support of: https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation SecurityImpact DocImpact Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df From gerrit2 at review.openstack.org Tue Dec 17 13:37:54 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Dec 2013 13:37:54 +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 8985c973dbeb554d47ef6a74f0e6c412f6e53211 Author: Dan Genin Date: Tue Dec 17 08:31:24 2013 -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. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From gerrit2 at review.openstack.org Tue Dec 17 14:05:29 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Tue, 17 Dec 2013 14:05:29 +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 25d5c864200d12020b8821e3ee22ab0a054bbd5b Author: Dan Genin Date: Tue Dec 17 08:31:24 2013 -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. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From fungi at yuggoth.org Wed Dec 18 00:12:36 2013 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 18 Dec 2013 00:12:36 -0000 Subject: [Openstack-security] [Bug 1260525] Re: Incomplete XSS fix for ossa/1247675 References: <20131212225614.8529.85762.malonedeb@gac.canonical.com> Message-ID: <20131218001237.25578.2549.malone@wampee.canonical.com> Bug is now a public non-vulnerability, tagged as security hardening, no advisory. Thanks! ** Information type changed from Private Security to Public ** Tags added: security ** Changed in: ossa Status: Incomplete => Invalid -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1260525 Title: Incomplete XSS fix for ossa/1247675 Status in OpenStack Dashboard (Horizon): Confirmed Status in OpenStack Security Advisories: Invalid Bug description: The patch for https://bugs.launchpad.net/ossa/+bug/1247675 did not completely fix the reported issue. It failed to completely remove the use of html.strip_tags, which is not intended to be a security function, and does not properly sanitize output. https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/tables.py#L254 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1260525/+subscriptions From 1247217 at bugs.launchpad.net Wed Dec 18 15:51:45 2013 From: 1247217 at bugs.launchpad.net (Russell Bryant) Date: Wed, 18 Dec 2013 15:51:45 -0000 Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when logging payload in wsgi for API Extensions References: <20131101180555.24208.66851.malonedeb@gac.canonical.com> Message-ID: <20131218155148.16315.35619.launchpad@wampee.canonical.com> ** Changed in: nova Milestone: None => icehouse-2 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1247217 Title: Sanitize passwords when logging payload in wsgi for API Extensions Status in OpenStack Compute (Nova): Fix Committed Status in Oslo - a Library of Common OpenStack Code: In Progress Bug description: The fix for bug 1231263 ( https://bugs.launchpad.net/nova/+bug/1231263 ) addressed not logging the clear-text password in the nova wsgi.py module for the adminPass attribute for the Server Change Password REST API, but this only addressed that specific attribute. Since Nova has support for the ability to add REST API Extensions (in the contrib directory), there could any number of other password-related attributes in the request/response body for those additional extensions. Although it would not be possible to know all of the various sensitive attributes that these API's would pass in the request/response (the only way to totally eliminate the exposure would be to not log the request/response which is useful for debugging), I would like to propose a change similar to the one that was made in keystone (under https://bugs.launchpad.net/keystone/+bug/1166697) to mask the password in the log statement for any attribute that contains the "password" sub-string in it. The change would in essence be to update the _SANITIZE_KEYS / _SANITIZE_PATTERNS lists in the nova/api/openstack/wsgi.py module to include a pattern for the "password" sub-string. Also, for a slight performance benefit, it may be useful to put a check in to see if debug logging level is enabled around the debug statement that does the sanitize call (since the request/response bodies could be fairly large and wouldn't want to take the hit to do the pattern matches if debug isn't on). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1247217/+subscriptions From gerrit2 at review.openstack.org Wed Dec 18 21:45:23 2013 From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org) Date: Wed, 18 Dec 2013 21:45:23 +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 8b99087dd49ecf83bac729b88eeba59bbadea273 Author: Dan Genin Date: Tue Dec 17 08:31:24 2013 -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. The proposed code provides data-at-rest security for all ephemeral storage drives, preventing access to data while an instance is shut down, or in case the compute host is shut down while an instance is running. Options controlling the encryption state, cipher and key size are specified in the "ephemeral_storage_encryption" options group. The boolean "enabled" option turn encryption on and off and the "cipher" and "key_size" options specify the cipher and key size, respectively. Note: depends on cryptsetup being installed. Implements: blueprint encrypt-ephemeral-storage Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477 docImpact SecurityImpact From sriram at sriramhere.com Thu Dec 19 19:09:51 2013 From: sriram at sriramhere.com (SriramHere) Date: Thu, 19 Dec 2013 19:09:51 -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: <20131219190952.8259.60793.malone@soybean.canonical.com> Please review and comment on the OSSN published for this: https://wiki.openstack.org/wiki/OSSN/1227575. Content reproduced below. I wanted to know if links to some rate-limiting frameworks such as Repose would help. Not sure if we can link 3rd party tools in OSSNs. ================================================================================== DoS style attack on noVNC server can lead to service interruption or disruption === Summary=== Currently, there is no limiting on the number of VNC sessions that can be created for a single user's VNC token which enables one to cause a DoS attack on noVNC browser proxy by requesting multiple server. This prevents subsequent access to VM's VNC console. === Affected Services / Software === Horizon (VNC Console through browser), Nova (NoVNC proxy), Grizzly === Discussion === NoVNC Proxy is explained well here. Once a user gets token to access a VM's VNC console, there is no restriction in the number of times the user can try connecting to the VNC console using the same token. If multiple connection requests are made, any subsequent request could timeout. This could impact users already connected to the VNC sessions, or other users trying to make new connection. This could also impact overall responsiveness of other nova services running in the novnc host. Thus, a user could make the NoVNC proxy endpoint not responsive/ reachable, thereby resulting in a DoS attack. However, it is to be noted there is no amplification effect. === Recommended Actions === For current stable releases (Grizzly), users need to workaround this vulnerability by using rate-limiting proxies to cover access to NoVNC hosts. Rate-limiting is a common mechanism to prevent DoS/ Brute-Force attacks. You can find more discussion on rate-limiting around OpenStack Networking Best practices here. === Contacts / References === This OSSN : https://bugs.launchpad.net/ossn/+bug/1227575 Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+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 sriram at sriramhere.com Sat Dec 21 15:56:12 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Sat, 21 Dec 2013 07:56:12 -0800 Subject: [Openstack-security] Request to review OSSN Message-ID: Dear Nathan, Rob, Bryan/ OSSG, Sorry for bothering during the holidays. When you get a chance, please review/ comment on the OSSN: https://wiki.openstack.org/wiki/OSSN/1227575 https://bugs.launchpad.net/nova/+bug/1227575 I wanted to know if links to some rate-limiting frameworks such as Repose would help. I am not sure if we can link 3rd party tools in OSSNs. Happy Holidays! Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanael.i.burton.work at gmail.com Sat Dec 21 17:11:28 2013 From: nathanael.i.burton.work at gmail.com (Nathanael Burton) Date: Sat, 21 Dec 2013 12:11:28 -0500 Subject: [Openstack-security] Request to review OSSN In-Reply-To: References: Message-ID: I might be missing something obvious, but wouldn't making the VNC token from nova-consoleauth a one-time use token solve this problem? I.e. once a user successfully connects to their console with an authorized token it won't work for future connections. Then the rate-limiting of the Nova API would suffice, which should be presumed to already be in-place and configured. Does that break other things? Thanks, Nate On Dec 21, 2013 10:57 AM, "Sriram Subramanian" wrote: > Dear Nathan, Rob, Bryan/ OSSG, > > Sorry for bothering during the holidays. When you get a chance, please > review/ comment on the OSSN: > > https://wiki.openstack.org/wiki/OSSN/1227575 > https://bugs.launchpad.net/nova/+bug/1227575 > > I wanted to know if links to some rate-limiting frameworks such as Repose > would help. I am not sure if we can link 3rd party tools in OSSNs. > > Happy Holidays! > > 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 nkinder at redhat.com Sat Dec 21 17:19:05 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Sat, 21 Dec 2013 09:19:05 -0800 Subject: [Openstack-security] Request to review OSSN In-Reply-To: References: Message-ID: <52B5CD89.8000604@redhat.com> On 12/21/2013 07:56 AM, Sriram Subramanian wrote: > Dear Nathan, Rob, Bryan/ OSSG, > > Sorry for bothering during the holidays. When you get a chance, please > review/ comment on the OSSN: > > https://wiki.openstack.org/wiki/OSSN/1227575 > https://bugs.launchpad.net/nova/+bug/1227575 I'll have some time to take a look at this tomorrow. I tried to make some time to go over it yesterday, but the rush of trying to get things wrapped up before our end of year shutdown here kept me swamped. > > I wanted to know if links to some rate-limiting frameworks such as > Repose would help. I am not sure if we can link 3rd party tools in OSSNs. > > Happy Holidays! Happy Holidays to you too! -NGK > > Thanks, > -Sriram From sriram at sriramhere.com Sat Dec 21 18:03:35 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Sat, 21 Dec 2013 10:03:35 -0800 Subject: [Openstack-security] Request to review OSSN In-Reply-To: References: Message-ID: Nate, The fix won't make it until next release, hence the workaround is published as OSSN. On Sat, Dec 21, 2013 at 9:11 AM, Nathanael Burton < nathanael.i.burton.work at gmail.com> wrote: > I might be missing something obvious, but wouldn't making the VNC token > from nova-consoleauth a one-time use token solve this problem? I.e. once a > user successfully connects to their console with an authorized token it > won't work for future connections. Then the rate-limiting of the Nova API > would suffice, which should be presumed to already be in-place and > configured. Does that break other things? > > Thanks, > > Nate > On Dec 21, 2013 10:57 AM, "Sriram Subramanian" > wrote: > >> Dear Nathan, Rob, Bryan/ OSSG, >> >> Sorry for bothering during the holidays. When you get a chance, please >> review/ comment on the OSSN: >> >> https://wiki.openstack.org/wiki/OSSN/1227575 >> https://bugs.launchpad.net/nova/+bug/1227575 >> >> I wanted to know if links to some rate-limiting frameworks such as Repose >> would help. I am not sure if we can link 3rd party tools in OSSNs. >> >> Happy Holidays! >> >> 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 1251647 at bugs.launchpad.net Mon Dec 23 11:22:42 2013 From: 1251647 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 23 Dec 2013 11:22:42 -0000 Subject: [Openstack-security] [Bug 1251647] Fix merged to heat (master) References: <20131115144107.27303.99752.malonedeb@gac.canonical.com> Message-ID: <20131223112242.27062.41038.malone@soybean.canonical.com> Reviewed: https://review.openstack.org/62295 Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=f67cd2182823e4f4173aabd9c67e5ba3b0a20d92 Submitter: Jenkins Branch: master commit f67cd2182823e4f4173aabd9c67e5ba3b0a20d92 Author: Angus Salkeld Date: Mon Dec 16 19:59:18 2013 +1100 Add support for multiple encryption methods We use only one encrypt() method but it returns the method to decrypt the data. This way we can change the encryption mechanism but always have a way to know how to decrypt whatever is stored. Change-Id: I2315a33105a8766f69d02f0617af39a9dae19ddf Partial-bug: #1251647 -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1251647 Title: Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason Status in Orchestration API (Heat): In Progress Status in OpenStack Security Advisories: Invalid Bug description: In the following commit: https://github.com/openstack/heat/commit/58cd52624b50476ed5ed1c5c0ba7cb1b4d7ba66d ... a decision was introduced to encrypt authentication information using unauthenticated AES-CFB. There's a few things I don't like about that commit, but suffice to say that heat/engine/auth.py should probably not be a place where symmetric crypto decisions are made. I've been told that there's a new public API for symmetric encryption, SymmetricCrypto that lives in openstack/common/crypto/utils.py: https://github.com/openstack/oslo- incubator/blob/master/openstack/common/crypto/utils.py#L99 I think that also gets a few things wrong, but at the very least Heat should use a centralized thing for encrypting stuff. (I'd love to complain about and work on SymmetricCrypto too, but that's not this ticket :) To manage notifications about this bug go to: https://bugs.launchpad.net/heat/+bug/1251647/+subscriptions From sriram at sriramhere.com Tue Dec 24 00:43:17 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Mon, 23 Dec 2013 16:43:17 -0800 Subject: [Openstack-security] Fwd: [Openstack] Security Breach! Tenant A is seeing the VNC Consoles of Tenant B! In-Reply-To: References: Message-ID: Dear OSSG, Anybody seen this? Can we follow up with him for more details? thanks, -Sriram ---------- Forwarded message ---------- From: Martinx - ジェームズ Date: Sun, Dec 22, 2013 at 9:37 AM Subject: [Openstack] Security Breach! Tenant A is seeing the VNC Consoles of Tenant B! To: "openstack at lists.openstack.org" Stackers! I need a bit help here... My OpenStack Havana (Ubuntu 12.04.3) was working smoothly and, I don't know what had happened here but, now, I'm seeing some weird problems. Right now, the "Tenant A" is seeing the VNC Consoles of "Tenant B" !!! How is that even possible?! There is no authentication here to deal with this kind of things!? I'm really worried about this. Look: "Tenant A" Instances: [image: Inline images 1] "Tenant A" accessing the VNC Console of a "Tenant B" Instance!!! [image: Inline images 2] This is a very serious problem, since I'm giving to the "Tenant A", almost total access to "Tenant B" Instances!! This kind of situation should NEVER occur! What can I do to completely block this? I just started a new Instance for "Tenant A", and I'm seeing ANOTHER VNC Console from "Tenant B"!! Regards, Thiago _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack at lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Thanks, -Sriram -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Thu Dec 26 10:57:04 2013 From: thierry at openstack.org (Thierry Carrez) Date: Thu, 26 Dec 2013 11:57:04 +0100 Subject: [Openstack-security] Fwd: [Openstack] Security Breach! Tenant A is seeing the VNC Consoles of Tenant B! In-Reply-To: References: Message-ID: <52BC0B80.9030007@openstack.org> Sriram Subramanian wrote: > Anybody seen this? Can we follow up with him for more details? We had several people report the same type of "breach" in the past. It always boiled down to people misunderstanding the power of the "admin" users (which by default are not that much restricted by tenant boundaries). I would not be surprised if that was the case here. Especially if the reporter can't reproduce it on a "fresh" setup (where he would set up normal users). -- Thierry Carrez (ttx) From sriram at sriramhere.com Thu Dec 26 18:31:22 2013 From: sriram at sriramhere.com (Sriram Subramanian) Date: Thu, 26 Dec 2013 10:31:22 -0800 Subject: [Openstack-security] Fwd: [Openstack] Security Breach! Tenant A is seeing the VNC Consoles of Tenant B! In-Reply-To: <52BC0B80.9030007@openstack.org> References: <52BC0B80.9030007@openstack.org> Message-ID: Thierry, Thiago hasn't responded yet on the admin/ non-admin user part. Looks like that is the issue. I have pinged him to file a bug with more details, so that it will be acted upon. Thanks, -Sriram On Thu, Dec 26, 2013 at 2:57 AM, Thierry Carrez wrote: > Sriram Subramanian wrote: > > Anybody seen this? Can we follow up with him for more details? > > We had several people report the same type of "breach" in the past. It > always boiled down to people misunderstanding the power of the "admin" > users (which by default are not that much restricted by tenant boundaries). > > I would not be surprised if that was the case here. Especially if the > reporter can't reproduce it on a "fresh" setup (where he would set up > normal users). > > -- > Thierry Carrez (ttx) > > _______________________________________________ > 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 kseifried at redhat.com Thu Dec 26 20:38:44 2013 From: kseifried at redhat.com (Kurt Seifried) Date: Thu, 26 Dec 2013 13:38:44 -0700 Subject: [Openstack-security] Fwd: [Openstack] Security Breach! Tenant A is seeing the VNC Consoles of Tenant B! In-Reply-To: References: <52BC0B80.9030007@openstack.org> Message-ID: <52BC93D4.8090805@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/26/2013 11:31 AM, Sriram Subramanian wrote: > Thierry, Thiago hasn't responded yet on the admin/ non-admin user > part. Looks like that is the issue. I have pinged him to file a bug > with more details, so that it will be acted upon. > > Thanks, -Sriram > Is this something that needs to be better documented perhaps, or have a warning label? E.g. Python pickle(): http://docs.python.org/2/library/pickle.html "Warning The pickle module is not intended to be secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source." Perhaps something like "Warning the admin user is intended to blahblah don't hand it out to tenants/etc." - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSvJPTAAoJEBYNRVNeJnmTmewQAJYAYWVXtGj92iLuLjqQWvlG 8hKY1d10QJWqb/vWxTP8tFZ8EXYvRlhrNYpUl2TM0KeHoMrrjtZZIldYeWN0ERGz uYB9CvEwB59GehkFiTyfxt5Xxsv/wdCxoyaKCptDG8yyo2CnWfVoEWJn/33vd3N7 +N4ZjEaOUk7yLgw2djQasr/j/uCAQManNt/8x6MhsBdPASUIO7rAJowpw/dx+puF L7jaEdUZmaQBEagW8L58gZFZuBzpe8r5P41FkqzL8gPBB111//veHNsI3AmNczoI aK0AEdKj4B/0OICDS2sXCFu7yj3KuBb0astGjumNPhYOpgwv1Bbs4VzwBYiiPIaS i8A3iwXyNSnEWLuLdzZNMuB8qutFvilAhZlMOG8w9S6EX3sq7F/+TXFVIc0vaTHG JRukrdoqr7O728EhT2ieVyNBO6Wr1rfyg1Ao8naccuO6HwmdZhUOZKI406Kz7Dpr X3AkChHFLw3sEv8Q7gW4Yevn9yw4BWmfkDoy+Z3D/tFN895bbguoQiw0Q6TRqt+M zFiwqBWQp+DSA9JxwXeRAYNY+fKPIntfNMU8dc95h95VNJ2WUxLamNdg5UlDBiA2 TAJZA/E/r0Aw+blVwFcKTmW45Q3edO0lA+LrjGoXPc9OiiuCvitmHTEFxAL8A0Jx w5AYVY2WjI43Zplm2ib3 =OtzF -----END PGP SIGNATURE----- From nathanael.i.burton.work at gmail.com Thu Dec 26 23:16:15 2013 From: nathanael.i.burton.work at gmail.com (Nathanael Burton) Date: Thu, 26 Dec 2013 18:16:15 -0500 Subject: [Openstack-security] Fwd: [Openstack] Security Breach! Tenant A is seeing the VNC Consoles of Tenant B! In-Reply-To: References: <52BC0B80.9030007@openstack.org> Message-ID: I'm not so sure this is an 'admin' user or role issue. Certainly a user with the 'admin' role could get to the console of VMs in different tenants, but the problem as described seems to indicate the user is getting the wrong console (regardless of them being authorized or not). Issues like this most commonly occur when things get out of sync between the hypervisor and various nova services. I also wouldn't rule out a bug, but if so it's not a very obvious one from looking at the code and based on first-hand usage. Nate On Dec 26, 2013 1:32 PM, "Sriram Subramanian" wrote: > Thierry, Thiago hasn't responded yet on the admin/ non-admin user part. > Looks like that is the issue. I have pinged him to file a bug with more > details, so that it will be acted upon. > > Thanks, > -Sriram > > > On Thu, Dec 26, 2013 at 2:57 AM, Thierry Carrez wrote: > >> Sriram Subramanian wrote: >> > Anybody seen this? Can we follow up with him for more details? >> >> We had several people report the same type of "breach" in the past. It >> always boiled down to people misunderstanding the power of the "admin" >> users (which by default are not that much restricted by tenant >> boundaries). >> >> I would not be surprised if that was the case here. Especially if the >> reporter can't reproduce it on a "fresh" setup (where he would set up >> normal users). >> >> -- >> Thierry Carrez (ttx) >> >> _______________________________________________ >> 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: From mhu at enovance.com Mon Dec 30 09:11:59 2013 From: mhu at enovance.com (Matthieu Huin) Date: Mon, 30 Dec 2013 09:11:59 -0000 Subject: [Openstack-security] [Bug 1240382] Re: python-oauth2 dependency is unmaintained and has security issues References: <20131016072040.28005.15743.malonedeb@chaenomeles.canonical.com> Message-ID: <20131230091159.27230.67246.malone@soybean.canonical.com> Hi Thomas, I am having some trouble with the new library, as it implements oauth more strictly than the previous one. I am going to push my work as WIP, hopefully the community can provide some suggestions to go on with it. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1240382 Title: python-oauth2 dependency is unmaintained and has security issues Status in OpenStack Identity (Keystone): Confirmed Bug description: oauth2 is not maintained and have 2 CVE issues CVE-2013-4346 and CVE-2013-4347 and is not Python3 compatible can you remove this dependency (maybe switching to requests ? ) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240382/+subscriptions From pmakowski at espelida.com Tue Dec 10 18:01:17 2013 From: pmakowski at espelida.com (Philippe Makowski) Date: Tue, 10 Dec 2013 18:01:17 -0000 Subject: [Openstack-security] [Bug 1240382] Re: python-oauth2 dependency is unmaintained and has security issues References: <20131016072040.28005.15743.malonedeb@chaenomeles.canonical.com> Message-ID: <20131210175259.17290.18942.malone@chaenomeles.canonical.com> any thing useful here ? http://requests- oauthlib.readthedocs.org/en/latest/index.html -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1240382 Title: python-oauth2 dependency is unmaintained and has security issues Status in OpenStack Identity (Keystone): Confirmed Bug description: oauth2 is not maintained and have 2 CVE issues CVE-2013-4346 and CVE-2013-4347 and is not Python3 compatible can you remove this dependency (maybe switching to requests ? ) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240382/+subscriptions From 1254619 at bugs.launchpad.net Wed Dec 11 10:45:44 2013 From: 1254619 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Dec 2013 10:45:44 -0000 Subject: [Openstack-security] [Bug 1254619] Re: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" References: <20131125081604.9897.68214.malonedeb@gac.canonical.com> Message-ID: <20131211103759.17259.66586.launchpad@chaenomeles.canonical.com> ** Changed in: keystone Status: Triaged => In Progress ** Changed in: keystone Assignee: (unassigned) => Alvaro Lopez (aloga) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1254619 Title: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: In Progress Bug description: Hi there. Keystone allows the usage of external authentication. This external authentication makes possible for the deployers to integrate external euth methods in Keystone. When it is executed as a WSGI application (for example when executed behind apache using mod_wsgi) the authentication can be made by the web server and the user will be passed down using the REMOTE_USER environment variable. It is also possible to use external authn by creating a custom WSGI filter that will be pipelined. More details of this behaviour can be seen in [0]. [0] http://docs.openstack.org/developer/keystone/external-auth.html Since the Havana release, this code has been refactored and moved to a pluggable mechanism under keystone/auth/plugins/external.py. If I am not wrong, this was introduced in commit 88c319e6bce98082f9a90b8b27726793d5366326 [1]. This code is in stable/havana since that commit, and is currently in the trunk. [1] https://github.com/openstack/keystone/commit/88c319e6bce98082f9a90b8b27726793d5366326 During the review of [2] the ExternalDefault plugin I've realized that the way the plugin extracts the username can lead to impersonation. The excerpt of code that extracts the username is this one [3]:     names = remote_user.split('@')     username = names.pop(0)     domain_id = CONF.identity.default_domain_id     user_ref = auth_info.identity_api.get_user_by_name(username,                                                        domain_id) When Keystone is configured to use the defualt domain, the REMOTE_USER variable is splited by all the "@" and then only the leftfmost part is considered, while the leftovers are discarded. Since a username can contain "@" inside (for example when emails are used as usernames) "john" "john at example.org" and "john at foobar.net" will all get a token belonging to the "john" user. [2] https://review.openstack.org/#/c/50362 [3] https://github.com/openstack/keystone/blob/stable/havana/keystone/auth/plugins/external.py#L39 External authentication opens the door for any deployer to use any authentication mechanism. OpenStack does not ship any external authentication mechanism, but it is perfectly possible to use emails as the usernames (or usernames containing "@", as X509 certificate DNs). For example, a LDAP directory could be configured in Apache to let the users in, and set the REMOTE_USER as the username, instead of the user DN. It is possible to easily reproduce this using devstack as follows:     ubuntu at test-ks-vuln:~/devstack$ cat > localrc << EOF     > ENABLED_SERVICES=key,mysql     > APACHE_ENABLED_SERVICES+=keystone     > EOF     ubuntu at test-ks-vuln:~/devstack$ ./stack.sh     (...)     ubuntu at test-ks-vuln:~/devstack$ source openrc admin admin     ubuntu at test-ks-vuln:~/devstack$ keystone user-list     +----------------------------------+-------+---------+-------------------+     | id | name | enabled | email |     +----------------------------------+-------+---------+-------------------+     | dc90b499a1c0499997bd35ba19a2436c | admin | True | admin at example.com |     | 685cd73e645243c2ba81314cbc5ac89a | demo | True | demo at example.com |     +----------------------------------+-------+---------+-------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-list     +----------------------------------+--------------------+---------+     | id | name | enabled |     +----------------------------------+--------------------+---------+     | d5319bc5b7054e0589ad32048813ee1a | admin | True |     | badfa689e32a4d9fb7d102a7d92ad3b7 | demo | True |     | 110627ae8c534b548d70a5a159ff65ee | invisible_to_admin | True |     | 92484643deb246e680ee3d716a7dfeea | service | True |     +----------------------------------+--------------------+---------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-create --name external_users     +-------------+----------------------------------+     | Property | Value |     +-------------+----------------------------------+     | description | |     Listen 5000     | enabled | True |     Listen 5000     | id | 3ac4e3f06a3548378eb26e3be8dc3952 |     | name | external_users |     +-------------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john --tenant d5319bc5b7054e0589ad32048813ee1a --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     Listen 5000     | enabled | True |     | id | a8fe063e8a124f89ada9526d401aad98 |     | name | john |     | tenantId | d5319bc5b7054e0589ad32048813ee1a |     +----------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john at external_user.com --tenant 3ac4e3f06a3548378eb26e3be8dc3952 --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     | enabled | True |     | id | 6af78b4bdca646a68069d74cdf8e5334 |     | name | john at external_user.com |     | tenantId | 3ac4e3f06a3548378eb26e3be8dc3952 |     +----------+----------------------------------+ So far I've two different users. For the shake of simplicity I will use Apache's basic authentication, so it is needed to add the following excerpt to /etc/apache2/sites-enabled/keystone:     Listen 5001              WSGIDaemonProcess keystone-public2 processes=5 threads=1 user=ubuntu         WSGIProcessGroup keystone-public2         WSGIScriptAlias / /var/www/keystone/main         WSGIApplicationGroup %{GLOBAL}         ErrorLog /var/log/apache2/keystone         LogLevel debug         CustomLog /var/log/apache2/access.log combined                      AuthType Basic             AuthName "Restricted Files"             AuthBasicProvider file             AuthUserFile /opt/stack/htpasswd             Require valid-user               And then, create the external user, and authenticate with it:     ubuntu at test-ks-vuln:~/devstack$ sudo htpasswd -c /opt/stack/htpasswd john at external_user.com     New password:     Re-type new password:     Adding password for user john at external_user.com     ubuntu at test-ks-vuln:~/devstack$ sudo /etc/init.d/apache2 restart     * Restarting web server apache2     * ... waiting     ubuntu at test-ks-vuln:~/devstack$     ubuntu at test-ks-vuln:~$ curl --user john at external_user.com:secret -d '{"auth": {"identity":{ "methods": []}}}' -H "Content-type: application/json" http://172.16.0.63:5001/v3/auth/tokens |python -mjson.tool       % Total % Received % Xferd Average Speed Time Time Time Current                                      Dload Upload Total Spent Left Speed     100 1134 100 1095 100 39 2301 81 --:--:-- --:--:-- --:--:-- 2300     {         "token": {             "catalog": [                 {                     "endpoints": [                         {                             "id": "d0b2b692496a4d2c8a70e63543782aed",                             "interface": "internal",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         },                         {                             "id": "da7fe597a1b84529910e890807b47bdb",                             "interface": "admin",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:35357/v2.0"                         },                         {                             "id": "eeda9fbcffe94588ad15689d33f2c1e9",                             "interface": "public",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         }                     ],                     "id": "14a4bd4966b74503ab2fb47836101824",                     "type": "identity"                 }             ],             "expires_at": "2013-11-26T23:04:55.341085Z",             "extras": {},             "issued_at": "2013-11-25T23:04:55.341121Z",             "methods": [],             "project": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "d5319bc5b7054e0589ad32048813ee1a",                 "name": "admin"             },             "roles": [                 {                     "id": "9fe2ff9ee4384b1894a90878d3e92bab",                     "name": "_member_"                 }             ],             "user": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "a8fe063e8a124f89ada9526d401aad98",                 "name": "john"             }         }     } As you can see, I am getting the id for the user "john" (a8fe063e8a124f89ada9526d401aad98) instead of the user "john at example_user.com" (6af78b4bdca646a68069d74cdf8e5334). The patch in [2] should fix this issue (although it was initially unrelated) since it does not split the username when using the ExternalDefault plugin. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1254619/+subscriptions From 1174499 at bugs.launchpad.net Wed Dec 11 15:01:42 2013 From: 1174499 at bugs.launchpad.net (OpenStack Infra) Date: Wed, 11 Dec 2013 15:01:42 -0000 Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5 References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com> Message-ID: <20131211145320.17461.85492.malone@chaenomeles.canonical.com> Fix proposed to branch: master Review: https://review.openstack.org/61445 ** 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/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 1254619 at bugs.launchpad.net Wed Dec 11 20:08:13 2013 From: 1254619 at bugs.launchpad.net (Dolph Mathews) Date: Wed, 11 Dec 2013 20:08:13 -0000 Subject: [Openstack-security] [Bug 1254619] Re: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" References: <20131125081604.9897.68214.malonedeb@gac.canonical.com> Message-ID: <20131211195255.8887.61965.malone@gac.canonical.com> (replying mostly for posterity as I think this conversation took place in other venues) @Alvaro: agree completely. Adam Young has lifted his -2 to make exactly that happen. Regarding backwards compatibility, we should actually be restoring it vs grizzly, not breaking it in this bug fix. The bug fix itself will restore the behavior of master and stable/havana to be compatible with that of stable/grizzly... which should provide an easy migration path from stable/grizzly forward, eliminating the ops pain. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1254619 Title: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: In Progress Bug description: Hi there. Keystone allows the usage of external authentication. This external authentication makes possible for the deployers to integrate external euth methods in Keystone. When it is executed as a WSGI application (for example when executed behind apache using mod_wsgi) the authentication can be made by the web server and the user will be passed down using the REMOTE_USER environment variable. It is also possible to use external authn by creating a custom WSGI filter that will be pipelined. More details of this behaviour can be seen in [0]. [0] http://docs.openstack.org/developer/keystone/external-auth.html Since the Havana release, this code has been refactored and moved to a pluggable mechanism under keystone/auth/plugins/external.py. If I am not wrong, this was introduced in commit 88c319e6bce98082f9a90b8b27726793d5366326 [1]. This code is in stable/havana since that commit, and is currently in the trunk. [1] https://github.com/openstack/keystone/commit/88c319e6bce98082f9a90b8b27726793d5366326 During the review of [2] the ExternalDefault plugin I've realized that the way the plugin extracts the username can lead to impersonation. The excerpt of code that extracts the username is this one [3]:     names = remote_user.split('@')     username = names.pop(0)     domain_id = CONF.identity.default_domain_id     user_ref = auth_info.identity_api.get_user_by_name(username,                                                        domain_id) When Keystone is configured to use the defualt domain, the REMOTE_USER variable is splited by all the "@" and then only the leftfmost part is considered, while the leftovers are discarded. Since a username can contain "@" inside (for example when emails are used as usernames) "john" "john at example.org" and "john at foobar.net" will all get a token belonging to the "john" user. [2] https://review.openstack.org/#/c/50362 [3] https://github.com/openstack/keystone/blob/stable/havana/keystone/auth/plugins/external.py#L39 External authentication opens the door for any deployer to use any authentication mechanism. OpenStack does not ship any external authentication mechanism, but it is perfectly possible to use emails as the usernames (or usernames containing "@", as X509 certificate DNs). For example, a LDAP directory could be configured in Apache to let the users in, and set the REMOTE_USER as the username, instead of the user DN. It is possible to easily reproduce this using devstack as follows:     ubuntu at test-ks-vuln:~/devstack$ cat > localrc << EOF     > ENABLED_SERVICES=key,mysql     > APACHE_ENABLED_SERVICES+=keystone     > EOF     ubuntu at test-ks-vuln:~/devstack$ ./stack.sh     (...)     ubuntu at test-ks-vuln:~/devstack$ source openrc admin admin     ubuntu at test-ks-vuln:~/devstack$ keystone user-list     +----------------------------------+-------+---------+-------------------+     | id | name | enabled | email |     +----------------------------------+-------+---------+-------------------+     | dc90b499a1c0499997bd35ba19a2436c | admin | True | admin at example.com |     | 685cd73e645243c2ba81314cbc5ac89a | demo | True | demo at example.com |     +----------------------------------+-------+---------+-------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-list     +----------------------------------+--------------------+---------+     | id | name | enabled |     +----------------------------------+--------------------+---------+     | d5319bc5b7054e0589ad32048813ee1a | admin | True |     | badfa689e32a4d9fb7d102a7d92ad3b7 | demo | True |     | 110627ae8c534b548d70a5a159ff65ee | invisible_to_admin | True |     | 92484643deb246e680ee3d716a7dfeea | service | True |     +----------------------------------+--------------------+---------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-create --name external_users     +-------------+----------------------------------+     | Property | Value |     +-------------+----------------------------------+     | description | |     Listen 5000     | enabled | True |     Listen 5000     | id | 3ac4e3f06a3548378eb26e3be8dc3952 |     | name | external_users |     +-------------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john --tenant d5319bc5b7054e0589ad32048813ee1a --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     Listen 5000     | enabled | True |     | id | a8fe063e8a124f89ada9526d401aad98 |     | name | john |     | tenantId | d5319bc5b7054e0589ad32048813ee1a |     +----------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john at external_user.com --tenant 3ac4e3f06a3548378eb26e3be8dc3952 --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     | enabled | True |     | id | 6af78b4bdca646a68069d74cdf8e5334 |     | name | john at external_user.com |     | tenantId | 3ac4e3f06a3548378eb26e3be8dc3952 |     +----------+----------------------------------+ So far I've two different users. For the shake of simplicity I will use Apache's basic authentication, so it is needed to add the following excerpt to /etc/apache2/sites-enabled/keystone:     Listen 5001              WSGIDaemonProcess keystone-public2 processes=5 threads=1 user=ubuntu         WSGIProcessGroup keystone-public2         WSGIScriptAlias / /var/www/keystone/main         WSGIApplicationGroup %{GLOBAL}         ErrorLog /var/log/apache2/keystone         LogLevel debug         CustomLog /var/log/apache2/access.log combined                      AuthType Basic             AuthName "Restricted Files"             AuthBasicProvider file             AuthUserFile /opt/stack/htpasswd             Require valid-user               And then, create the external user, and authenticate with it:     ubuntu at test-ks-vuln:~/devstack$ sudo htpasswd -c /opt/stack/htpasswd john at external_user.com     New password:     Re-type new password:     Adding password for user john at external_user.com     ubuntu at test-ks-vuln:~/devstack$ sudo /etc/init.d/apache2 restart     * Restarting web server apache2     * ... waiting     ubuntu at test-ks-vuln:~/devstack$     ubuntu at test-ks-vuln:~$ curl --user john at external_user.com:secret -d '{"auth": {"identity":{ "methods": []}}}' -H "Content-type: application/json" http://172.16.0.63:5001/v3/auth/tokens |python -mjson.tool       % Total % Received % Xferd Average Speed Time Time Time Current                                      Dload Upload Total Spent Left Speed     100 1134 100 1095 100 39 2301 81 --:--:-- --:--:-- --:--:-- 2300     {         "token": {             "catalog": [                 {                     "endpoints": [                         {                             "id": "d0b2b692496a4d2c8a70e63543782aed",                             "interface": "internal",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         },                         {                             "id": "da7fe597a1b84529910e890807b47bdb",                             "interface": "admin",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:35357/v2.0"                         },                         {                             "id": "eeda9fbcffe94588ad15689d33f2c1e9",                             "interface": "public",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         }                     ],                     "id": "14a4bd4966b74503ab2fb47836101824",                     "type": "identity"                 }             ],             "expires_at": "2013-11-26T23:04:55.341085Z",             "extras": {},             "issued_at": "2013-11-25T23:04:55.341121Z",             "methods": [],             "project": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "d5319bc5b7054e0589ad32048813ee1a",                 "name": "admin"             },             "roles": [                 {                     "id": "9fe2ff9ee4384b1894a90878d3e92bab",                     "name": "_member_"                 }             ],             "user": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "a8fe063e8a124f89ada9526d401aad98",                 "name": "john"             }         }     } As you can see, I am getting the id for the user "john" (a8fe063e8a124f89ada9526d401aad98) instead of the user "john at example_user.com" (6af78b4bdca646a68069d74cdf8e5334). The patch in [2] should fix this issue (although it was initially unrelated) since it does not split the username when using the ExternalDefault plugin. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1254619/+subscriptions From 1254619 at bugs.launchpad.net Thu Dec 12 08:31:12 2013 From: 1254619 at bugs.launchpad.net (Alvaro Lopez) Date: Thu, 12 Dec 2013 08:31:12 -0000 Subject: [Openstack-security] [Bug 1254619] Re: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" References: <20131125081604.9897.68214.malonedeb@gac.canonical.com> Message-ID: <20131212082320.8498.41781.malone@gac.canonical.com> So I assume that I should remove the LegacyDomain and LegacyDefaultDomain from the patchest, don't 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/1254619 Title: external.Default authentication plugin only considers leftmost part of the REMOTE_USER split by "@" Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Security Advisories: Invalid Status in OpenStack Security Notes: In Progress Bug description: Hi there. Keystone allows the usage of external authentication. This external authentication makes possible for the deployers to integrate external euth methods in Keystone. When it is executed as a WSGI application (for example when executed behind apache using mod_wsgi) the authentication can be made by the web server and the user will be passed down using the REMOTE_USER environment variable. It is also possible to use external authn by creating a custom WSGI filter that will be pipelined. More details of this behaviour can be seen in [0]. [0] http://docs.openstack.org/developer/keystone/external-auth.html Since the Havana release, this code has been refactored and moved to a pluggable mechanism under keystone/auth/plugins/external.py. If I am not wrong, this was introduced in commit 88c319e6bce98082f9a90b8b27726793d5366326 [1]. This code is in stable/havana since that commit, and is currently in the trunk. [1] https://github.com/openstack/keystone/commit/88c319e6bce98082f9a90b8b27726793d5366326 During the review of [2] the ExternalDefault plugin I've realized that the way the plugin extracts the username can lead to impersonation. The excerpt of code that extracts the username is this one [3]:     names = remote_user.split('@')     username = names.pop(0)     domain_id = CONF.identity.default_domain_id     user_ref = auth_info.identity_api.get_user_by_name(username,                                                        domain_id) When Keystone is configured to use the defualt domain, the REMOTE_USER variable is splited by all the "@" and then only the leftfmost part is considered, while the leftovers are discarded. Since a username can contain "@" inside (for example when emails are used as usernames) "john" "john at example.org" and "john at foobar.net" will all get a token belonging to the "john" user. [2] https://review.openstack.org/#/c/50362 [3] https://github.com/openstack/keystone/blob/stable/havana/keystone/auth/plugins/external.py#L39 External authentication opens the door for any deployer to use any authentication mechanism. OpenStack does not ship any external authentication mechanism, but it is perfectly possible to use emails as the usernames (or usernames containing "@", as X509 certificate DNs). For example, a LDAP directory could be configured in Apache to let the users in, and set the REMOTE_USER as the username, instead of the user DN. It is possible to easily reproduce this using devstack as follows:     ubuntu at test-ks-vuln:~/devstack$ cat > localrc << EOF     > ENABLED_SERVICES=key,mysql     > APACHE_ENABLED_SERVICES+=keystone     > EOF     ubuntu at test-ks-vuln:~/devstack$ ./stack.sh     (...)     ubuntu at test-ks-vuln:~/devstack$ source openrc admin admin     ubuntu at test-ks-vuln:~/devstack$ keystone user-list     +----------------------------------+-------+---------+-------------------+     | id | name | enabled | email |     +----------------------------------+-------+---------+-------------------+     | dc90b499a1c0499997bd35ba19a2436c | admin | True | admin at example.com |     | 685cd73e645243c2ba81314cbc5ac89a | demo | True | demo at example.com |     +----------------------------------+-------+---------+-------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-list     +----------------------------------+--------------------+---------+     | id | name | enabled |     +----------------------------------+--------------------+---------+     | d5319bc5b7054e0589ad32048813ee1a | admin | True |     | badfa689e32a4d9fb7d102a7d92ad3b7 | demo | True |     | 110627ae8c534b548d70a5a159ff65ee | invisible_to_admin | True |     | 92484643deb246e680ee3d716a7dfeea | service | True |     +----------------------------------+--------------------+---------+     ubuntu at test-ks-vuln:~/devstack$ keystone tenant-create --name external_users     +-------------+----------------------------------+     | Property | Value |     +-------------+----------------------------------+     | description | |     Listen 5000     | enabled | True |     Listen 5000     | id | 3ac4e3f06a3548378eb26e3be8dc3952 |     | name | external_users |     +-------------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john --tenant d5319bc5b7054e0589ad32048813ee1a --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     Listen 5000     | enabled | True |     | id | a8fe063e8a124f89ada9526d401aad98 |     | name | john |     | tenantId | d5319bc5b7054e0589ad32048813ee1a |     +----------+----------------------------------+     ubuntu at test-ks-vuln:~/devstack$ keystone user-create --name john at external_user.com --tenant 3ac4e3f06a3548378eb26e3be8dc3952 --pass secret     +----------+----------------------------------+     | Property | Value |     +----------+----------------------------------+     | email | |     | enabled | True |     | id | 6af78b4bdca646a68069d74cdf8e5334 |     | name | john at external_user.com |     | tenantId | 3ac4e3f06a3548378eb26e3be8dc3952 |     +----------+----------------------------------+ So far I've two different users. For the shake of simplicity I will use Apache's basic authentication, so it is needed to add the following excerpt to /etc/apache2/sites-enabled/keystone:     Listen 5001              WSGIDaemonProcess keystone-public2 processes=5 threads=1 user=ubuntu         WSGIProcessGroup keystone-public2         WSGIScriptAlias / /var/www/keystone/main         WSGIApplicationGroup %{GLOBAL}         ErrorLog /var/log/apache2/keystone         LogLevel debug         CustomLog /var/log/apache2/access.log combined                      AuthType Basic             AuthName "Restricted Files"             AuthBasicProvider file             AuthUserFile /opt/stack/htpasswd             Require valid-user               And then, create the external user, and authenticate with it:     ubuntu at test-ks-vuln:~/devstack$ sudo htpasswd -c /opt/stack/htpasswd john at external_user.com     New password:     Re-type new password:     Adding password for user john at external_user.com     ubuntu at test-ks-vuln:~/devstack$ sudo /etc/init.d/apache2 restart     * Restarting web server apache2     * ... waiting     ubuntu at test-ks-vuln:~/devstack$     ubuntu at test-ks-vuln:~$ curl --user john at external_user.com:secret -d '{"auth": {"identity":{ "methods": []}}}' -H "Content-type: application/json" http://172.16.0.63:5001/v3/auth/tokens |python -mjson.tool       % Total % Received % Xferd Average Speed Time Time Time Current                                      Dload Upload Total Spent Left Speed     100 1134 100 1095 100 39 2301 81 --:--:-- --:--:-- --:--:-- 2300     {         "token": {             "catalog": [                 {                     "endpoints": [                         {                             "id": "d0b2b692496a4d2c8a70e63543782aed",                             "interface": "internal",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         },                         {                             "id": "da7fe597a1b84529910e890807b47bdb",                             "interface": "admin",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:35357/v2.0"                         },                         {                             "id": "eeda9fbcffe94588ad15689d33f2c1e9",                             "interface": "public",                             "legacy_endpoint_id": "59eddafa29194ef5a1d221aad17f2f2e",                             "region": "RegionOne",                             "url": "http://172.16.0.63:5000/v2.0"                         }                     ],                     "id": "14a4bd4966b74503ab2fb47836101824",                     "type": "identity"                 }             ],             "expires_at": "2013-11-26T23:04:55.341085Z",             "extras": {},             "issued_at": "2013-11-25T23:04:55.341121Z",             "methods": [],             "project": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "d5319bc5b7054e0589ad32048813ee1a",                 "name": "admin"             },             "roles": [                 {                     "id": "9fe2ff9ee4384b1894a90878d3e92bab",                     "name": "_member_"                 }             ],             "user": {                 "domain": {                     "id": "default",                     "name": "Default"                 },                 "id": "a8fe063e8a124f89ada9526d401aad98",                 "name": "john"             }         }     } As you can see, I am getting the id for the user "john" (a8fe063e8a124f89ada9526d401aad98) instead of the user "john at example_user.com" (6af78b4bdca646a68069d74cdf8e5334). The patch in [2] should fix this issue (although it was initially unrelated) since it does not split the username when using the ExternalDefault plugin. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1254619/+subscriptions From dcahill at midokura.com Mon Dec 16 02:56:03 2013 From: dcahill at midokura.com (Dave Cahill) Date: Mon, 16 Dec 2013 02:56:03 -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: <20131216024646.26202.97083.malone@wampee.canonical.com> Jeremy - sure, sounds good. Assuming the user can't contact us and wants to check directly, that would work. Alternatively, they could check that the method _sg_ip_addr_group_name() exists in neutron/plugins/midonet/plugin.py, since that was created as part of the patch. 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): New Status in OpenStack Security Advisories: Incomplete 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 1243534 at bugs.launchpad.net Fri Dec 20 02:08:43 2013 From: 1243534 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Fri, 20 Dec 2013 02:08:43 -0000 Subject: [Openstack-security] [Bug 1243534] [NEW] contradiction on default cryptography ciphers References: <20131023060123.12728.63393.malonedeb@gac.canonical.com> Message-ID: <20131220020842.6999.29451.launchpad@gac.canonical.com> Tom Fifield (fifieldt) has assigned this bug to you for openstack-manuals: Chapter 13: 'As this book does not intend to be a thorough reference on cryptography we do not wish to be prescriptive about what specific algorithms or cipher modes you should enable or disable in your OpenStack services.' Chapter 15: 'ciphers = "HIGH:!aNULL:!eNULL:!DES:!3DES"' ----------------------------------- Built: 2013-10-22T21:22:10 00:00 git SHA: 72ee6fa1cfcd6a1ae2d86d78a6ac3f8709f5aaf4 URL: http://docs.openstack.org/security-guide/content/ch017_threat-models-confidence-and-confidentiality.html source File: file:/home/jenkins/workspace/openstack-security-guide/doc/security-guide/ch017_threat-models-confidence-and-confidentiality.xml xml:id: ch017_threat-models-confidence-and-confidentiality ** Affects: openstack-manuals Importance: Low Assignee: OpenStack Security Group (openstack-ossg) Status: Confirmed ** Tags: sec-guide -- contradiction on default cryptography ciphers https://bugs.launchpad.net/bugs/1243534 You received this bug notification because you are a member of OpenStack Security Group, which is a bug assignee. From 1118194 at bugs.launchpad.net Fri Dec 20 07:36:14 2013 From: 1118194 at bugs.launchpad.net (Launchpad Bug Tracker) Date: Fri, 20 Dec 2013 07:36:14 -0000 Subject: [Openstack-security] [Bug 1118194] [NEW] Security Documentation for Horizon References: <20130207100009.11250.38496.malonedeb@chaenomeles.canonical.com> Message-ID: <20131220073613.6968.41249.launchpad@gac.canonical.com> Tom Fifield (fifieldt) has assigned this bug to you for openstack-manuals: Horizon's documentation doesn't contain much in terms of guidelines for securing a deployment. The following should be documented somewhere: When implementing Horizon for public usage, with the website served through HTTPS, the following recommendations apply. In the Apache global configuration ensure that the following directive is configured to prevent the server from sharing its name, version and any other information that could be used for an attack: ServerSignature Off In the Apache global configuration ensure that the following directive is configured to prevent cross-site tracing [1]: TraceEnable Off In the Apache virtual host configuration: 1) Ensure that the "Indexes" option is not included in the Options directive. 2) Protect the server from BEAST attacks [2] by implementing the following options:   SSLHonorCipherOrder on   SSLProtocol -ALL +SSLv3 +TLSv1   SSLCipherSuite RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH:!ADH:!AESGCM:!AES In local_settings.py, implement the following settings in order to help protect the cookies from cross-site scripting [3]: CSRF_COOKIE_SECURE = True SESSION_COOKIE_SECURE = True SESSION_COOKIE_HTTPONLY = True Note that the CSRF_COOKIE_SECURE option is only available from Django 1.4 and will therefore not work for most packaged Essex deployments. Also, since a recent patch [4], you can disable browser autocompletion [5] for the authentication form by changing the 'password_autocomplete' attribute to 'off' in horizon/conf/default.py. [1] http://www.kb.cert.org/vuls/id/867593 [2] http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack [3] https://www.owasp.org/index.php/HttpOnly [4] https://review.openstack.org/21349 [5] https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML ** Affects: horizon Importance: Undecided Assignee: Jesse Pretorius (jesse-pretorius) Status: Fix Released ** Affects: openstack-manuals Importance: Wishlist Assignee: OpenStack Security Group (openstack-ossg) Status: Confirmed ** Tags: sec-guide -- Security Documentation for Horizon https://bugs.launchpad.net/bugs/1118194 You received this bug notification because you are a member of OpenStack Security Group, which is a bug assignee. From thomas at goirand.fr Mon Dec 30 07:21:38 2013 From: thomas at goirand.fr (Thomas Goirand) Date: Mon, 30 Dec 2013 07:21:38 -0000 Subject: [Openstack-security] [Bug 1240382] Re: python-oauth2 dependency is unmaintained and has security issues References: <20131016072040.28005.15743.malonedeb@chaenomeles.canonical.com> Message-ID: <20131230072138.17036.14673.malone@gac.canonical.com> Hi, I'd like to point out that, because nobody took care of fixing this issue fast enough, python-oauth2 and Keystone were removed from Debian testing today. It'd be nice if this issue could be addressed. -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1240382 Title: python-oauth2 dependency is unmaintained and has security issues Status in OpenStack Identity (Keystone): Confirmed Bug description: oauth2 is not maintained and have 2 CVE issues CVE-2013-4346 and CVE-2013-4347 and is not Python3 compatible can you remove this dependency (maybe switching to requests ? ) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240382/+subscriptions From 1244025 at bugs.launchpad.net Tue Dec 31 07:57:19 2013 From: 1244025 at bugs.launchpad.net (OpenStack Infra) Date: Tue, 31 Dec 2013 07:57:19 -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: <20131231075722.26763.7851.launchpad@soybean.canonical.com> ** Changed in: neutron Status: New => In Progress ** Changed in: neutron Assignee: (unassigned) => Brandon Berg (bberg-s) -- You received this bug notification because you are a member of OpenStack Security Group, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1244025 Title: Remote security group criteria don't work in Midonet plugin Status in OpenStack Neutron (virtual network service): In Progress 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