From gerrit2 at review.openstack.org  Thu Jan  2 14:47:45 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 02 Jan 2014 14:47:45 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1VyjYn-0006UA-Iw@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 4e50dba9952ccfda8ea4200802cf3ad540d75aec
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present.
    
    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 fw at deneb.enyo.de  Thu Jan  2 17:36:18 2014
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 02 Jan 2014 18:36:18 +0100
Subject: [Openstack-security] instance-data sinkholing
Message-ID: <871u0q4771.fsf@mid.deneb.enyo.de>

It has been suggested that I bring up this matter here.

Some variants of the EC2 instance-data injection protocol use a DNS
lookup for the domain "instance-data".  If the instance data client is
not careful, the DNS stub resolver can add a search path to the
domain, resulting in a name like "instance-data.example.com".
(cloud-init was fixed in October 2012.)  However, if the search path
is misconfigured, results like "instance-data.com" are possible.

I've registered instance-data.com and instance-data.net, but I would
like to transfer them to someone doing proper sinkholing, or
de-register them altogether.  Occassionally, there is traffic
targeting these domains.  Ideally, someone would monitor them and
contact those who send HTTP requests which look like the instance-data
injection protocol.  Covering more TLDs might make sense as well.

Thoughts?



From bdpayne at acm.org  Thu Jan  2 17:39:33 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Thu, 2 Jan 2014 09:39:33 -0800
Subject: [Openstack-security] instance-data sinkholing
In-Reply-To: <871u0q4771.fsf@mid.deneb.enyo.de>
References: <871u0q4771.fsf@mid.deneb.enyo.de>
Message-ID: <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>

Interesting.  Sounds like a useful thing to continue.  We should find
someone that can pick up this effort.  Anyone out there able to help with
this?

Also, I think that this could be a useful topic for an OSSN (a security
note that will help guide people towards better configuration practices for
their cloud).  Rob et al... you agree?

Cheers,
-bryan


On Thu, Jan 2, 2014 at 9:36 AM, Florian Weimer <fw at deneb.enyo.de> wrote:

> It has been suggested that I bring up this matter here.
>
> Some variants of the EC2 instance-data injection protocol use a DNS
> lookup for the domain "instance-data".  If the instance data client is
> not careful, the DNS stub resolver can add a search path to the
> domain, resulting in a name like "instance-data.example.com".
> (cloud-init was fixed in October 2012.)  However, if the search path
> is misconfigured, results like "instance-data.com" are possible.
>
> I've registered instance-data.com and instance-data.net, but I would
> like to transfer them to someone doing proper sinkholing, or
> de-register them altogether.  Occassionally, there is traffic
> targeting these domains.  Ideally, someone would monitor them and
> contact those who send HTTP requests which look like the instance-data
> injection protocol.  Covering more TLDs might make sense as well.
>
> Thoughts?
>
> _______________________________________________
> 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: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140102/04344986/attachment.html>

From sriram at sriramhere.com  Thu Jan  2 20:25:28 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Thu, 2 Jan 2014 12:25:28 -0800
Subject: [Openstack-security] Request to review OSSN
In-Reply-To: <CAP6wb7JoqH2pEJcH4=FyBVqk8BHzArvyJxd=a-605E9FGHfcEg@mail.gmail.com>
References: <CAP6wb7KO-mfP6WKsB64PzGurVq3o5vXd3iJd73sRb+x-ojvOTg@mail.gmail.com>
 <CAM+Mi=u_7U77iUytt2z5EDXy4qWZiVGgsP5qkQh1aLz9TkUMSw@mail.gmail.com>
 <CAP6wb7JoqH2pEJcH4=FyBVqk8BHzArvyJxd=a-605E9FGHfcEg@mail.gmail.com>
Message-ID: <CAP6wb7JaWoRZ_-8rLVovwXCsqENwDvfaSBvUYJ9zMdw-6F+-9Q@mail.gmail.com>

Nathan,

Happy new year!

Please review the OSSN when you get time.

Thanks,
-Sriram


On Sat, Dec 21, 2013 at 10:03 AM, Sriram Subramanian
<sriram at sriramhere.com>wrote:

> 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" <sriram at sriramhere.com>
>> 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
>



-- 
Thanks,
-Sriram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140102/4eba3490/attachment.html>

From thierry at openstack.org  Fri Jan  3 13:59:30 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Fri, 03 Jan 2014 14:59:30 +0100
Subject: [Openstack-security] instance-data sinkholing
In-Reply-To: <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
References: <871u0q4771.fsf@mid.deneb.enyo.de>
 <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
Message-ID: <52C6C242.7020102@openstack.org>

Bryan D. Payne wrote:
> Interesting.  Sounds like a useful thing to continue.  We should find
> someone that can pick up this effort.  Anyone out there able to help
> with this?

If all else fails, I could probably ask the Foundation if they would be
OK to hold those domains -- although at this point they don't have (yet)
a resource to actively exploit data coming from it.

IIUC this is not OpenStack-specific but more EC2-metadata specific ?

-- 
Thierry Carrez (ttx)



From gerrit2 at review.openstack.org  Fri Jan  3 17:50:41 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 03 Jan 2014 17:50:41 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1Vz8tN-0005yG-EG@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 1baba09fefa020ee298c303cc27892799a0c254a
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present.
    
    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  Fri Jan  3 20:03:37 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Fri, 3 Jan 2014 12:03:37 -0800
Subject: [Openstack-security] instance-data sinkholing
In-Reply-To: <52C6C242.7020102@openstack.org>
References: <871u0q4771.fsf@mid.deneb.enyo.de>
 <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
 <52C6C242.7020102@openstack.org>
Message-ID: <CAP6wb7LbR8wJO9NFxopXXMKK34fmq6NnFkTE4LKWZ4-eArqWrg@mail.gmail.com>

I am sorry I didn't get it quite, What is the effort here?


On Fri, Jan 3, 2014 at 5:59 AM, Thierry Carrez <thierry at openstack.org>wrote:

> Bryan D. Payne wrote:
> > Interesting.  Sounds like a useful thing to continue.  We should find
> > someone that can pick up this effort.  Anyone out there able to help
> > with this?
>
> If all else fails, I could probably ask the Foundation if they would be
> OK to hold those domains -- although at this point they don't have (yet)
> a resource to actively exploit data coming from it.
>
> IIUC this is not OpenStack-specific but more EC2-metadata specific ?
>
> --
> 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: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140103/dc8d61a3/attachment.html>

From bdpayne at acm.org  Fri Jan  3 20:12:17 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Fri, 3 Jan 2014 12:12:17 -0800
Subject: [Openstack-security] instance-data sinkholing
In-Reply-To: <52C6C242.7020102@openstack.org>
References: <871u0q4771.fsf@mid.deneb.enyo.de>
 <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
 <52C6C242.7020102@openstack.org>
Message-ID: <CAFpPvXBkujgiHatBsssng=YYy1n0rVm3grT+Km1XtdqedJEOgg@mail.gmail.com>

>
> If all else fails, I could probably ask the Foundation if they would be
>  OK to hold those domains -- although at this point they don't have (yet)
> a resource to actively exploit data coming from it.
>

This sounds like a reasonable step.  At least we could actively prevent
someone else from doing bad things with this.  Notification to
misconfigured clouds would, of course, be nice... but just stopping the
exploit path is a big win.  Probably worthwhile to pick up a few other
related TLDs at the same time.

-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140103/e17b6955/attachment.html>

From pmakowski at espelida.com  Sat Jan  4 13:30:44 2014
From: pmakowski at espelida.com (Philippe Makowski)
Date: Sat, 04 Jan 2014 13:30:44 -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: <20140104133044.20877.50330.malone@wampee.canonical.com>

Hi Matthieu,

since in Mageia we also , as in Debian testing, removed  python-oauth2,
if you have any visible WIP, please tell me where I can look at. May be
I can help, even if my keystone knowledge is weak today. It could be an
opportunity to learn.

-- 
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 nkinder at redhat.com  Sat Jan  4 18:11:56 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Sat, 04 Jan 2014 18:11:56 -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: <20140104181157.6601.59370.malone@chaenomeles.canonical.com>

I would slightly reword the "Summary" section to be a bit more clear.
I'd suggest something like this:

-------------
There is currently no limitation on the number of VNC sessions that can be established for a single user's VNC token.  This enables one to cause a Denial of Service (DoS) style attack by establishing many VNC sessions against a single instance through a noVNC proxy.  This can cause timeouts for other users who are trying to access the same instance through VNC.
-------------

In the "Discussion" section, I don't think the first sentence is needed
("NoVNC Proxy is explained here").  There are also some areas where I
would suggest slight rewording:

-------------
Once a user gets a token to access an instance's VNC console, there is no restriction on the frequency that the user can attempt to connect to the instance's VNC console using that token.  There is also no restriction on the number of simultaneous VNC sessions that the user can establish against the instance using a single token.  If many connection requests are made, any subsequent connection requests made by other users may time out.  This could also impact other user's currently established VNC sessions to the instance.  The overall responsiveness of other Nova services running on the noVNC host.

By taking advantage of the lack of any VNC connection limiting, a single user could cause the noVNC proxy endpoint to be non-responsive or unreachable.  This results in a DoS attack.  It should be noted that there is no amplification effect.
-------------

I think the OSSN needs to mention Havana as well.  It currently only
indicates that Grizzly is affected in the "Affected Services" and
"Recommended Actions" sections.

You have a few spots that use "NoVNC" or "novnc".  These should be
"noVNC".

In the "Recommended Actions" section, you start to make a reference to
some best practices but there is no reference.  Were you intending to
refer to the Security Guide?

-- 
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 noloader at gmail.com  Sat Jan  4 19:34:44 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 4 Jan 2014 14:34:44 -0500
Subject: [Openstack-security] [Bug 1243534] [NEW] contradiction on
 default cryptography ciphers
In-Reply-To: <20131220020842.6999.29451.launchpad@gac.canonical.com>
References: <20131023060123.12728.63393.malonedeb@gac.canonical.com>
 <20131220020842.6999.29451.launchpad@gac.canonical.com>
Message-ID: <CAH8yC8kd4+QvBWBnm3NgNiPp8p5NEUz00+ur6tFDuVc3oXGaew@mail.gmail.com>

> Chapter 15: 'ciphers = "HIGH:!aNULL:!eNULL:!DES:!3DES"'
The simplest string to use would probably be:

    "HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM"

RC4 is not appropriate for use in TLS. See "On the Security of RC4 in
TLS and WPA", cr.yp.to/streamciphers/rc4biases-20130708.pdf‎.

MD5 is not appropriate for use in TLS if not used as a PRF. Its OK to
use it in the PRF, but it should not be used in MACs and Signatures.

2-key TDEA (TDEA) provides 80-bits of security (RSA 1024 equivalent)
and should no longer be used. 3-key TDEA (TDEA) provides 112-bits of
security (RSA 2048 equivalent) and is OK for use. SSL/TLS uses the
later and requires 24-bytes of key material (that's the 3-key
variant), so 3DES is OK. See RFC 2246 and friends.

If you want to ensure the ephemeral key exchanges are preferred over
RSA transport, then the following might be appropriate (ephemeral key
exchanges provide forward secrecy):

    "kEECDH:kEDH:kRSA:HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM"

Protocols are still an open question since they get enabled/disabled
through SSL_CTX_set_options. SSLv2 must be disabled, and SSLv3 should
be disabled.

Jeff

On Thu, Dec 19, 2013 at 9:08 PM, Launchpad Bug Tracker
<1243534 at bugs.launchpad.net> wrote:
> 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 noloader at gmail.com  Sat Jan  4 19:34:44 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 04 Jan 2014 19:34:44 -0000
Subject: [Openstack-security] [Bug 1243534] [NEW] contradiction on
	default	cryptography ciphers
References: <20131023060123.12728.63393.malonedeb@gac.canonical.com>
Message-ID: <CAH8yC8kd4+QvBWBnm3NgNiPp8p5NEUz00+ur6tFDuVc3oXGaew@mail.gmail.com>

> Chapter 15: 'ciphers = "HIGH:!aNULL:!eNULL:!DES:!3DES"'
The simplest string to use would probably be:

    "HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM"

RC4 is not appropriate for use in TLS. See "On the Security of RC4 in
TLS and WPA", cr.yp.to/streamciphers/rc4biases-20130708.pdf‎.

MD5 is not appropriate for use in TLS if not used as a PRF. Its OK to
use it in the PRF, but it should not be used in MACs and Signatures.

2-key TDEA (TDEA) provides 80-bits of security (RSA 1024 equivalent)
and should no longer be used. 3-key TDEA (TDEA) provides 112-bits of
security (RSA 2048 equivalent) and is OK for use. SSL/TLS uses the
later and requires 24-bytes of key material (that's the 3-key
variant), so 3DES is OK. See RFC 2246 and friends.

If you want to ensure the ephemeral key exchanges are preferred over
RSA transport, then the following might be appropriate (ephemeral key
exchanges provide forward secrecy):

    "kEECDH:kEDH:kRSA:HIGH:!RC4:!MD5:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM"

Protocols are still an open question since they get enabled/disabled
through SSL_CTX_set_options. SSLv2 must be disabled, and SSLv3 should
be disabled.

Jeff

On Thu, Dec 19, 2013 at 9:08 PM, Launchpad Bug Tracker
<1243534 at bugs.launchpad.net> wrote:
> 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.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is a bug assignee.
https://bugs.launchpad.net/bugs/1243534

Title:
  contradiction on default cryptography ciphers

Status in OpenStack Manuals:
  Confirmed

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-manuals/+bug/1243534/+subscriptions



From fw at deneb.enyo.de  Sun Jan  5 19:25:31 2014
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 05 Jan 2014 20:25:31 +0100
Subject: [Openstack-security] instance-data sinkholing
In-Reply-To: <52C6C242.7020102@openstack.org> (Thierry Carrez's message of
 "Fri, 03 Jan 2014 14:59:30 +0100")
References: <871u0q4771.fsf@mid.deneb.enyo.de>
 <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
 <52C6C242.7020102@openstack.org>
Message-ID: <87mwja44es.fsf@mid.deneb.enyo.de>

* Thierry Carrez:

> Bryan D. Payne wrote:
>> Interesting.  Sounds like a useful thing to continue.  We should find
>> someone that can pick up this effort.  Anyone out there able to help
>> with this?
>
> If all else fails, I could probably ask the Foundation if they would be
> OK to hold those domains -- although at this point they don't have (yet)
> a resource to actively exploit data coming from it.
>
> IIUC this is not OpenStack-specific but more EC2-metadata specific ?

It's a bit complicated.  I haven't tested if EC2 actually supports the
DNS-based approach, their documentation suggests to use the hard-coded
169.254.169.254 instead.  And you don't necessarily need code in the
hosting environment for that, you only need to configure a root zone
which has an A record a suitable delegation.



From thierry.carrez+lp at gmail.com  Mon Jan  6 13:36:58 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 06 Jan 2014 13:36: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: <20140106133658.13920.2748.malone@chaenomeles.canonical.com>

@Brandon: did you post a review about this ? If yes, could you post the
link here ?

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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



From thierry.carrez+lp at gmail.com  Mon Jan  6 14:20:43 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 06 Jan 2014 14:20: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: <20140106142043.925.17410.malone@gac.canonical.com>

Great, thx
My understanding is that we should have a stable/havana backport of that patch (once it lands in master), and Grizzly is unaffected ?

-- 
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



From shardy at redhat.com  Mon Jan  6 14:29:10 2014
From: shardy at redhat.com (Steven Hardy)
Date: Mon, 06 Jan 2014 14:29:10 -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: <20140106142913.25876.69795.launchpad@soybean.canonical.com>

** Changed in: heat
    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/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 stevemar at ca.ibm.com  Mon Jan  6 05:30:10 2014
From: stevemar at ca.ibm.com (Steve Martinelli)
Date: Mon, 06 Jan 2014 05:30:10 -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: <20140106053010.13404.85684.malone@chaenomeles.canonical.com>

Hi Philippe,

Here is the WIP patch: https://review.openstack.org/#/c/64427/

-- 
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  Mon Jan  6 13:27:16 2014
From: 1254619 at bugs.launchpad.net (Dolph Mathews)
Date: Mon, 06 Jan 2014 13:27:16 -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: <20140106132716.2013.92615.malone@gac.canonical.com>

Alvaro- refer to the code review

-- 
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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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 bberg at midokura.com  Mon Jan  6 13:51:51 2014
From: bberg at midokura.com (Brandon Berg)
Date: Mon, 06 Jan 2014 13:51:51 -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: <20140106135151.27260.71872.malone@soybean.canonical.com>

Here's the review: https://review.openstack.org/#/c/53052/
It's dependent on https://review.openstack.org/#/c/48574/

-- 
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



From bberg at midokura.com  Mon Jan  6 14:41:08 2014
From: bberg at midokura.com (Brandon Berg)
Date: Mon, 06 Jan 2014 14:41:08 -0000
Subject: [Openstack-security] [Bug 1244025] Re: Remote security group
	criteria don't work in	Midonet plugin
References: <20131024030525.12859.50542.malonedeb@gac.canonical.com>
Message-ID: <20140106144108.1319.95975.malone@gac.canonical.com>

Correct. It's going to Havana and later versions, but not to Grizzly.

-- 
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



From fungi at yuggoth.org  Mon Jan  6 17:28:57 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 06 Jan 2014 17:28:57 -0000
Subject: [Openstack-security] =?utf-8?q?=5BBug_1245350=5D_Re=3A_One_tenant?=
	=?utf-8?q?=27s_admin_user_can_modified_other_tenant=27s_user?=
	=?utf-8?b?4oCZcyBxdW90YSBpbmZv?=
References: <20131028063821.17025.34532.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140106172858.1381.94093.launchpad@gac.canonical.com>

*** This bug is a duplicate of bug 968696 ***
    https://bugs.launchpad.net/bugs/968696

** Changed in: cinder
       Status: Confirmed => Invalid

** Changed in: cinder
   Importance: High => Undecided

** Changed in: nova
   Importance: High => Undecided

** Changed in: ossa
       Status: Incomplete => Invalid

** Information type changed from Private Security to Public

** Tags added: security

** This bug has been marked a duplicate of bug 968696
   "admin"-ness not properly scoped

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1245350

Title:
  One tenant's admin user can modified other tenant's user’s quota info

Status in Cinder:
  Invalid
Status in OpenStack Compute (Nova):
  Invalid
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  1、Create tenant A and userA,and make userA as an admin
  2、Create tenant B and userA,and make userB as an admin
  3、userA login in openstack system,and create quota info “volumes:11111”
  4、userB login in openstack system ,and update userA’s quota info from “volumes:11111” to “volumes:111”
  5、detail test operation info see this link：http://paste.openstack.org/show/50020/

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1245350/+subscriptions



From sriram at sriramhere.com  Mon Jan  6 18:03:05 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Mon, 6 Jan 2014 10:03:05 -0800
Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on
 noVNC server can lead to service interruption or disruption
In-Reply-To: <20140104181157.6601.59370.malone@chaenomeles.canonical.com>
References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com>
 <20140104181157.6601.59370.malone@chaenomeles.canonical.com>
Message-ID: <CAP6wb7LsKcgjJTZOLwL4LXt-hr43H0E_8_NRrWy82LLLjFVZBw@mail.gmail.com>

Thanks for the comments Nathan.

I wanted to check if references to 3rd party tools are allowed in the
reference section.


On Sat, Jan 4, 2014 at 10:11 AM, Nathan Kinder <nkinder at redhat.com> wrote:

> I would slightly reword the "Summary" section to be a bit more clear.
> I'd suggest something like this:
>
> -------------
> There is currently no limitation on the number of VNC sessions that can be
> established for a single user's VNC token.  This enables one to cause a
> Denial of Service (DoS) style attack by establishing many VNC sessions
> against a single instance through a noVNC proxy.  This can cause timeouts
> for other users who are trying to access the same instance through VNC.
> -------------
>
> In the "Discussion" section, I don't think the first sentence is needed
> ("NoVNC Proxy is explained here").  There are also some areas where I
> would suggest slight rewording:
>
> -------------
> Once a user gets a token to access an instance's VNC console, there is no
> restriction on the frequency that the user can attempt to connect to the
> instance's VNC console using that token.  There is also no restriction on
> the number of simultaneous VNC sessions that the user can establish against
> the instance using a single token.  If many connection requests are made,
> any subsequent connection requests made by other users may time out.  This
> could also impact other user's currently established VNC sessions to the
> instance.  The overall responsiveness of other Nova services running on the
> noVNC host.
>
> By taking advantage of the lack of any VNC connection limiting, a single
> user could cause the noVNC proxy endpoint to be non-responsive or
> unreachable.  This results in a DoS attack.  It should be noted that there
> is no amplification effect.
> -------------
>
> I think the OSSN needs to mention Havana as well.  It currently only
> indicates that Grizzly is affected in the "Affected Services" and
> "Recommended Actions" sections.
>
> You have a few spots that use "NoVNC" or "novnc".  These should be
> "noVNC".
>
> In the "Recommended Actions" section, you start to make a reference to
> some best practices but there is no reference.  Were you intending to
> refer to the Security Guide?
>
> --
> You received this bug notification because you are a member of OpenStack
> Security Group, which is subscribed to OpenStack.
> https://bugs.launchpad.net/bugs/1227575
>
> Title:
>   DoS style attack on noVNC server can lead to service interruption or
>   disruption
>
> Status in OpenStack Compute (Nova):
>   In Progress
> Status in OpenStack Security Notes:
>   New
>
> Bug description:
>   There is no limiting on the number of VNC sessions that can be created
> for a single user's VNC token.
>   Any attempt to create multiple (say hundreds or thousands) of websocket
> connections to the VNC server
>   results in many connection timeouts. Due to these connection timeout
> error, other users trying to access their
>   VM's VNC console cannot do so.
>
>   A sample script that tries to create 100,000 connections to Nova noVNC
> proxy, shows timeout errors
>   Script: http://paste.openstack.org/show/47254/
>
>   Script output.... connections get timed out after a while
>   -------------------
>   ....
>   ..
>
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   timed out
>   Creating Connection
>   Receiving...
>   timed out
>   Creating Connection
>   Receiving...
>   timed out
>   Creating Connection
>   Receiving...
>   timed out
>   Creating Connection
>   Receiving...
>   timed out
>   --------------------
>
>   Impact:
>   1. Many of the sessions timeout. Any attempt to open other sessions also
> intermittently fail.
>   This can cause serious problems to users already having a running VNC
> session or trying to create new sessions.
>
>   2. The overall performance and response times of other nova services
> running on the novnc host, using tcp protocol
>   also gets affected after the connection timeout errors.
>
>   For example:
>   Before running the sumulate thousands of connections program:
>   $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc
>
> +-------+---------------------------------------------------------------------------------+
>   | Type  | Url
>                   |
>
> +-------+---------------------------------------------------------------------------------+
>   | novnc |
> http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212|
>
> +-------+---------------------------------------------------------------------------------+
>
>   real    0m0.751s
>   user    0m0.376s
>   sys     0m0.084s
>
>   rohit at precise-dev-102:~/tools/websocket-client-0.7.0$
>
>   After running the program, the response time is quite high:
>   $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc
>
>
> +-------+---------------------------------------------------------------------------------+
>   | Type  | Url
>                   |
>
> +-------+---------------------------------------------------------------------------------+
>   | novnc |
> http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9|
>
> +-------+---------------------------------------------------------------------------------+
>
>   real    3m9.231s
>   user    0m0.424s
>   sys     0m0.108s
>
>
>   Possible solutions:
>   1. Allow just 1 session per instance, and raise a new exception, say,
> VNCSessionAlreadyExists to reject multiple
>   connections for the same token, and return an error code to the user.
>   2. Make the number of sessions allowed per instance configurable,
> limited by some count of sessions.
>
>   However, both of these solutions may need to override and modify the
> do_proxy() method of websockify's WebSocketProxy class,
>   which can lead to maintenance issues.
>
>   Another possible solution would be to implement some kind of callback
> function in websockify, to which we can pass the token
>   for reconnection. This would first need contribution to the websockify
> project code, and then update Nova.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>



-- 
Thanks,
-Sriram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140106/edf4aaf4/attachment.html>

From sriram at sriramhere.com  Mon Jan  6 18:03:05 2014
From: sriram at sriramhere.com (SriramHere)
Date: Mon, 06 Jan 2014 18:03:05 -0000
Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on
	noVNC	server can lead to service interruption or disruption
References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com>
 <20140104181157.6601.59370.malone@chaenomeles.canonical.com>
Message-ID: <CAP6wb7LsKcgjJTZOLwL4LXt-hr43H0E_8_NRrWy82LLLjFVZBw@mail.gmail.com>

Thanks for the comments Nathan.

I wanted to check if references to 3rd party tools are allowed in the
reference section.


On Sat, Jan 4, 2014 at 10:11 AM, Nathan Kinder <nkinder at redhat.com> wrote:

> I would slightly reword the "Summary" section to be a bit more clear.
> I'd suggest something like this:
>
> -------------
> There is currently no limitation on the number of VNC sessions that can be
> established for a single user's VNC token.  This enables one to cause a
> Denial of Service (DoS) style attack by establishing many VNC sessions
> against a single instance through a noVNC proxy.  This can cause timeouts
> for other users who are trying to access the same instance through VNC.
> -------------
>
> In the "Discussion" section, I don't think the first sentence is needed
> ("NoVNC Proxy is explained here").  There are also some areas where I
> would suggest slight rewording:
>
> -------------
> Once a user gets a token to access an instance's VNC console, there is no
> restriction on the frequency that the user can attempt to connect to the
> instance's VNC console using that token.  There is also no restriction on
> the number of simultaneous VNC sessions that the user can establish against
> the instance using a single token.  If many connection requests are made,
> any subsequent connection requests made by other users may time out.  This
> could also impact other user's currently established VNC sessions to the
> instance.  The overall responsiveness of other Nova services running on the
> noVNC host.
>
> By taking advantage of the lack of any VNC connection limiting, a single
> user could cause the noVNC proxy endpoint to be non-responsive or
> unreachable.  This results in a DoS attack.  It should be noted that there
> is no amplification effect.
> -------------
>
> I think the OSSN needs to mention Havana as well.  It currently only
> indicates that Grizzly is affected in the "Affected Services" and
> "Recommended Actions" sections.
>
> You have a few spots that use "NoVNC" or "novnc".  These should be
> "noVNC".
>
> In the "Recommended Actions" section, you start to make a reference to
> some best practices but there is no reference.  Were you intending to
> refer to the Security Guide?
>
> --
> You received this bug notification because you are a member of OpenStack
> Security Group, which is subscribed to OpenStack.
> https://bugs.launchpad.net/bugs/1227575
>
> Title:
>   DoS style attack on noVNC server can lead to service interruption or
>   disruption
>
> Status in OpenStack Compute (Nova):
>   In Progress
> Status in OpenStack Security Notes:
>   New
>
> Bug description:
>   There is no limiting on the number of VNC sessions that can be created
> for a single user's VNC token.
>   Any attempt to create multiple (say hundreds or thousands) of websocket
> connections to the VNC server
>   results in many connection timeouts. Due to these connection timeout
> error, other users trying to access their
>   VM's VNC console cannot do so.
>
>   A sample script that tries to create 100,000 connections to Nova noVNC
> proxy, shows timeout errors
>   Script: http://paste.openstack.org/show/47254/
>
>   Script output.... connections get timed out after a while
>   -------------------
>   ....
>   ..
>
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   Received 'RFB 003.008
>   '
>   Creating Connection
>   Receiving...
>   timed out
>   Creating Connection
>   Receiving...
>   timed out
>   Creating Connection
>   Receiving...
>   timed out
>   Creating Connection
>   Receiving...
>   timed out
>   Creating Connection
>   Receiving...
>   timed out
>   --------------------
>
>   Impact:
>   1. Many of the sessions timeout. Any attempt to open other sessions also
> intermittently fail.
>   This can cause serious problems to users already having a running VNC
> session or trying to create new sessions.
>
>   2. The overall performance and response times of other nova services
> running on the novnc host, using tcp protocol
>   also gets affected after the connection timeout errors.
>
>   For example:
>   Before running the sumulate thousands of connections program:
>   $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc
>
> +-------+---------------------------------------------------------------------------------+
>   | Type  | Url
>                   |
>
> +-------+---------------------------------------------------------------------------------+
>   | novnc |
> http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212|
>
> +-------+---------------------------------------------------------------------------------+
>
>   real    0m0.751s
>   user    0m0.376s
>   sys     0m0.084s
>
>   rohit at precise-dev-102:~/tools/websocket-client-0.7.0$
>
>   After running the program, the response time is quite high:
>   $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc
>
>
> +-------+---------------------------------------------------------------------------------+
>   | Type  | Url
>                   |
>
> +-------+---------------------------------------------------------------------------------+
>   | novnc |
> http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9|
>
> +-------+---------------------------------------------------------------------------------+
>
>   real    3m9.231s
>   user    0m0.424s
>   sys     0m0.108s
>
>
>   Possible solutions:
>   1. Allow just 1 session per instance, and raise a new exception, say,
> VNCSessionAlreadyExists to reject multiple
>   connections for the same token, and return an error code to the user.
>   2. Make the number of sessions allowed per instance configurable,
> limited by some count of sessions.
>
>   However, both of these solutions may need to override and modify the
> do_proxy() method of websockify's WebSocketProxy class,
>   which can lead to maintenance issues.
>
>   Another possible solution would be to implement some kind of callback
> function in websockify, to which we can pass the token
>   for reconnection. This would first need contribution to the websockify
> project code, and then update Nova.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>


-- 
Thanks,
-Sriram

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1227575

Title:
  DoS style attack on noVNC server can lead to service interruption or
  disruption

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Notes:
  New

Bug description:
  There is no limiting on the number of VNC sessions that can be created for a single user's VNC token.
  Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server
  results in many connection timeouts. Due to these connection timeout error, other users trying to access their 
  VM's VNC console cannot do so.

  A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors
  Script: http://paste.openstack.org/show/47254/

  Script output.... connections get timed out after a while
  -------------------
  ....
  ..

  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  --------------------

  Impact:
  1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail.
  This can cause serious problems to users already having a running VNC session or trying to create new sessions.

  2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol
  also gets affected after the connection timeout errors.

  For example:
  Before running the sumulate thousands of connections program:
  $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc
  +-------+---------------------------------------------------------------------------------+
  | Type  | Url                                                                             |
  +-------+---------------------------------------------------------------------------------+
  | novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 |
  +-------+---------------------------------------------------------------------------------+

  real    0m0.751s
  user    0m0.376s
  sys     0m0.084s

  rohit at precise-dev-102:~/tools/websocket-client-0.7.0$

  After running the program, the response time is quite high:
  $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc

  +-------+---------------------------------------------------------------------------------+
  | Type  | Url                                                                             |
  +-------+---------------------------------------------------------------------------------+
  | novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 |
  +-------+---------------------------------------------------------------------------------+

  real    3m9.231s
  user    0m0.424s
  sys     0m0.108s

  
  Possible solutions:
  1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple
  connections for the same token, and return an error code to the user.
  2. Make the number of sessions allowed per instance configurable, limited by some count of sessions.

  However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class, 
  which can lead to maintenance issues.

  Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token
  for reconnection. This would first need contribution to the websockify project code, and then update Nova.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions



From abhishek.kekane at nttdata.com  Tue Jan  7 12:17:24 2014
From: abhishek.kekane at nttdata.com (Abhishek Kekane)
Date: Tue, 07 Jan 2014 12:17:24 -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: <20140107121725.25837.80097.malone@soybean.canonical.com>

Hi,

In spiceconsole when sending request to websocket server "payload" of
websocket is getting converted to javascript ArrayBuffer
(https://github.com/metacloud/spice-html5/blob/master/spiceconn.js#L126)
and then while converting "message" to arraybuffer connection_id is
getting converted to 32 bit integer (https://github.com/metacloud/spice-
html5/blob/master/spicemsg.js#L118). This connection_id then gets
encrypted (using anding and bit shifting of 32 bit integer)
(https://github.com/metacloud/spice-
html5/blob/master/spicedataview.js#L84).

At the servers side we get this "message" in recv_frames method of websocket(https://github.com/kanaka/websockify/blob/master/websockify/websocket.py#L337). This message is then decrypted and we get payload in hex format (https://github.com/kanaka/websockify/blob/master/websockify/websocket.py#L348). In this payload first four bytes is connection_id but it is in hex encrypted format.
As data received from client is in hex format, its difficult to retrive the connection_id in user readable format.

To overcome this issue, IMO the sessions need to be managed only in case of NoVncConsole and if the console is SpiceConsole then  there is no need to manage the sessions.
For this purpose one flag (is_vnc = true/false) will be passed from novncproxy to determine the console type while creating the server object(websocketproxy.NovaWebSocketProxy).

Please let me know if you found any workaround for the same.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1227575

Title:
  DoS style attack on noVNC server can lead to service interruption or
  disruption

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Notes:
  New

Bug description:
  There is no limiting on the number of VNC sessions that can be created for a single user's VNC token.
  Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server
  results in many connection timeouts. Due to these connection timeout error, other users trying to access their 
  VM's VNC console cannot do so.

  A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors
  Script: http://paste.openstack.org/show/47254/

  Script output.... connections get timed out after a while
  -------------------
  ....
  ..

  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  --------------------

  Impact:
  1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail.
  This can cause serious problems to users already having a running VNC session or trying to create new sessions.

  2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol
  also gets affected after the connection timeout errors.

  For example:
  Before running the sumulate thousands of connections program:
  $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc
  +-------+---------------------------------------------------------------------------------+
  | Type  | Url                                                                             |
  +-------+---------------------------------------------------------------------------------+
  | novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 |
  +-------+---------------------------------------------------------------------------------+

  real    0m0.751s
  user    0m0.376s
  sys     0m0.084s

  rohit at precise-dev-102:~/tools/websocket-client-0.7.0$

  After running the program, the response time is quite high:
  $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc

  +-------+---------------------------------------------------------------------------------+
  | Type  | Url                                                                             |
  +-------+---------------------------------------------------------------------------------+
  | novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 |
  +-------+---------------------------------------------------------------------------------+

  real    3m9.231s
  user    0m0.424s
  sys     0m0.108s

  
  Possible solutions:
  1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple
  connections for the same token, and return an error code to the user.
  2. Make the number of sessions allowed per instance configurable, limited by some count of sessions.

  However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class, 
  which can lead to maintenance issues.

  Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token
  for reconnection. This would first need contribution to the websockify project code, and then update Nova.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions



From gerrit2 at review.openstack.org  Tue Jan  7 15:24:05 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 07 Jan 2014 15:24:05 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W0YVh-00068h-8S@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 9dfd895ceac51d9c474f2049b9487c7058e28506
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present.
    
    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 Jan  7 16:22:51 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 07 Jan 2014 16:22:51 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W0ZQZ-00036g-P6@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit d78dd56862c3d94ca5b38725416e790c5e012e3e
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present.
    
    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 Jan  7 16:28:11 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 07 Jan 2014 16:28:11 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W0ZVj-0003aO-Sg@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 9f8e9882a1ca91665ea077460e8c046841908def
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present.
    
    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  Wed Jan  8 00:08:15 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 08 Jan 2014 00:08:15 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W0ggx-0001Ft-7A@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit 2d91ff0e0ba8b57f59d93c4cc2ca623f6e888ff9
Author: Jamie Lennox <jamielennox at redhat.com>
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 Jan  8 00:08:57 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 08 Jan 2014 00:08:57 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1W0ghd-0001Jb-RG@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59604

Log:
commit b47a174dee6154777fce4df6314c1baaa9186bc2
Author: Jamie Lennox <jamielennox at redhat.com>
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 robert.clark at hp.com  Wed Jan  8 11:37:27 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 8 Jan 2014 11:37:27 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
In-Reply-To: <CAH8yC8mOuOT-5fr=oRvNmxaKOoD_OjMkkMc6tK9+nUK3Z_BzVw@mail.gmail.com>
References: <E1W0ghd-0001Jb-RG@review.openstack.org>
 <CAH8yC8mOuOT-5fr=oRvNmxaKOoD_OjMkkMc6tK9+nUK3Z_BzVw@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A11019C34E@G4W3300.americas.hpqcorp.net>

I think Pecan is going to be used for API services in the future, moving 
away from eventlet I guess:
https://wiki.openstack.org/wiki/PecanStackForgeTransition

I'm looking into the crypto stuff now.

> -----Original Message-----
> From: Jeffrey Walton [mailto:noloader at gmail.com]
> Sent: 08 January 2014 00:38
> To: Clark, Robert Graham
> Subject: Fwd: [Openstack-security] [openstack/keystone]
> SecurityImpact review request change
> I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
>
> If there is a util.crypto (I think that's what its called), why is
> pecan.request.crypto.encrypt being used to encrypt and sign? Why is
> another crypto library being used? Has anyone reviewed
> pecan.request.crypto?
>
>
> ---------- Forwarded message ----------
> From:  <gerrit2 at review.openstack.org>
> Date: Tue, Jan 7, 2014 at 7:08 PM
> Subject: [Openstack-security] [openstack/keystone] SecurityImpact
> review request change
> I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
> 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/59604
>
> Log:
> commit b47a174dee6154777fce4df6314c1baaa9186bc2
> Author: Jamie Lennox <jamielennox at redhat.com>
> 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
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140108/58633566/attachment.bin>

From nkinder at redhat.com  Wed Jan  8 15:32:26 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Wed, 08 Jan 2014 15:32:26 -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: <20140108153226.31342.87526.malone@soybean.canonical.com>

There is precedent for having external references in an OSSN.  For
example, this OSSN refers to the Apache wiki:

    https://wiki.openstack.org/wiki/OSSN/1155566

I would suggest that you make it clear that the any third party tools
mentioned are possible solutions, not the only solution as there may be
other tools out there that can be used for limiting.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1227575

Title:
  DoS style attack on noVNC server can lead to service interruption or
  disruption

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Notes:
  New

Bug description:
  There is no limiting on the number of VNC sessions that can be created for a single user's VNC token.
  Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server
  results in many connection timeouts. Due to these connection timeout error, other users trying to access their 
  VM's VNC console cannot do so.

  A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors
  Script: http://paste.openstack.org/show/47254/

  Script output.... connections get timed out after a while
  -------------------
  ....
  ..

  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  --------------------

  Impact:
  1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail.
  This can cause serious problems to users already having a running VNC session or trying to create new sessions.

  2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol
  also gets affected after the connection timeout errors.

  For example:
  Before running the sumulate thousands of connections program:
  $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc
  +-------+---------------------------------------------------------------------------------+
  | Type  | Url                                                                             |
  +-------+---------------------------------------------------------------------------------+
  | novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 |
  +-------+---------------------------------------------------------------------------------+

  real    0m0.751s
  user    0m0.376s
  sys     0m0.084s

  rohit at precise-dev-102:~/tools/websocket-client-0.7.0$

  After running the program, the response time is quite high:
  $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc

  +-------+---------------------------------------------------------------------------------+
  | Type  | Url                                                                             |
  +-------+---------------------------------------------------------------------------------+
  | novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 |
  +-------+---------------------------------------------------------------------------------+

  real    3m9.231s
  user    0m0.424s
  sys     0m0.108s

  
  Possible solutions:
  1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple
  connections for the same token, and return an error code to the user.
  2. Make the number of sessions allowed per instance configurable, limited by some count of sessions.

  However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class, 
  which can lead to maintenance issues.

  Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token
  for reconnection. This would first need contribution to the websockify project code, and then update Nova.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions



From thierry.carrez+lp at gmail.com  Thu Jan  9 10:40:33 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 09 Jan 2014 10:40:33 -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: <20140109104033.31388.93551.launchpad@soybean.canonical.com>

** Also affects: neutron/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/1244025

Title:
  Remote security group criteria don't work in Midonet plugin

Status in OpenStack Neutron (virtual network service):
  In Progress
Status in neutron havana series:
  New
Status in OpenStack Security Advisories:
  Confirmed

Bug description:
  When creating a security rule that specifies a remote security group
  (rather than a CIDR range), the Midonet plugin does not enforce this
  criterion. With an egress rule, for example, one of the criteria for a
  particular rule may be that only traffic to security group A will be
  allowed out. This criterion is ignored, and traffic will be allowed
  out regardless of the destination security group, provided that it
  conforms to the rule's other criteria.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1244025/+subscriptions



From sriram at sriramhere.com  Thu Jan  9 17:26:01 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Thu, 9 Jan 2014 09:26:01 -0800
Subject: [Openstack-security] Today's meeting
Message-ID: <CAP6wb7JDfBNBQpe0d5nrNqGY9b5MbzaFk3sZt+2X3H+535gXjA@mail.gmail.com>

Team,

Happy New Year!

I won't be able to attend today's meeting.:(. Here 's my update

1) Working on the feedback on OSSN (1227575) provided by Nathan
2) Couldn't get hold of Ben during the holidays on OSSG edit work. Would
appreciate a gentle poke during the call :)

thanks,
-Sriram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140109/88c8485c/attachment.html>

From nkinder at redhat.com  Sat Jan 11 05:57:08 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Sat, 11 Jan 2014 05:57:08 -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: <20140111055708.26410.74526.malone@wampee.canonical.com>

I've finished a draft of the OSSN for this issue.  It's still unclear
exactly what the fix (if any) is going to be for a Havana update, so the
OSSN doesn't mention anything about potential future changes.  The OSSN
draft follows below.

-------------------------------------------------------------------------------------------------------------------------

Keystone can allow user impersonation when using REMOTE_USER for external authentication.
---

### Summary ###
When external authentication is used with Keystone using the "ExternalDefault" plug-in, external usernames containing "@" characters are truncated at the "@" character before being mapped to a local Keystone user.  This can result in separate external users mapping to the same local Keystone user, which could lead to user impersonation.

### Affected Services / Software ###
Keystone, Havana

### Discussion ###
When Keystone is run in Apache HTTP Server, the webserver can handle authentication and pass the authenticated username to Keystone using the REMOTE_USER environment variable.  External authentication behavior is handled by authentication plugins in Keystone.  In the Havana release of OpenStack, if the external username provided in the REMOTE_USER environment variable contains an "@" character Keystone will only use the portion preceding the "@" character as the username when using the "ExternalDefault" authentication plugin.  This results in the ability for multiple unique external usernames to map to the same single username in Keystone.  For example, the external usernames "jdoe at example1.com" and "jdoe at example2.com" would both map to the Keystone user "jdoe".  This behavior could potentially be abused to allow one to impersonate another similarly named external user.

Keystone in OpenStack releases prior to Havana uses the entire value
contained in the REMOTE_USER environment variable, so those versions are
not vulnerable to this impersonation issue.

### Recommended Actions ###
If the "ExternalDefault" plugin is being used for external authentication in the Havana release, you should ensure that external usernames do not contain "@" characters unless you want to collapse similarly named external users into a single user on the Keystone side.

If your external usernames do contain "@" characters and you do not want
to collapse similarly named external users into a single user on the
Keystone side, you might be able to use the "ExternalDomain" plug-in.
This plugin considers the portion of the external username that follows
an "@" character to be the domain that the user belongs to in Keystone.
This allows similarly named external users to map to separate Keystone
users if the portion of the external username that follows an "@"
character maps to a Keystone domain name.  To configure the
"ExternalDomain" authentication plugin, set the "external"  parameter in
the "[auth]" section of Keystone's keystone.conf as follows:

---- begin example keystone.conf snippet ----
[auth]
methods = external,password,token,oauth1
external = keystone.auth.plugins.external.ExternalDomain
---- end example keystone.conf snippet ----

If neither of the above recommendations work for your deployment, a
custom authentication plugin can be created that uses the external
username that contains an "@" character as-is.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1254619
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1254619
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/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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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 d.w.chadwick at kent.ac.uk  Sat Jan 11 10:24:32 2014
From: d.w.chadwick at kent.ac.uk (David Chadwick)
Date: Sat, 11 Jan 2014 10:24:32 +0000
Subject: [Openstack-security] [Bug 1254619] Re: external.Default
 authentication plugin only	considers leftmost part of the REMOTE_USER split
 by "@"
In-Reply-To: <20140111055708.26410.74526.malone@wampee.canonical.com>
References: <20131125081604.9897.68214.malonedeb@gac.canonical.com>
 <20140111055708.26410.74526.malone@wampee.canonical.com>
Message-ID: <52D11BE0.9060107@kent.ac.uk>

It seems to me that changing the action of ExternalDefault in the Havana
release was fundamentally wrong. Surely the default action should be to
take the external username that Apache provides and use it "as is",
which is what the previous releases of Keystone did. So why cant we
simply revert the Havana release to behave the same way as previous
releases.

regards

David

On 11/01/2014 05:57, Nathan Kinder wrote:
> I've finished a draft of the OSSN for this issue.  It's still
> unclear exactly what the fix (if any) is going to be for a Havana
> update, so the OSSN doesn't mention anything about potential future
> changes.  The OSSN draft follows below.
> 
> -------------------------------------------------------------------------------------------------------------------------
>
>  Keystone can allow user impersonation when using REMOTE_USER for
> external authentication. ---
> 
> ### Summary ### When external authentication is used with Keystone
> using the "ExternalDefault" plug-in, external usernames containing
> "@" characters are truncated at the "@" character before being mapped
> to a local Keystone user.  This can result in separate external users
> mapping to the same local Keystone user, which could lead to user
> impersonation.
> 
> ### Affected Services / Software ### Keystone, Havana
> 
> ### Discussion ### When Keystone is run in Apache HTTP Server, the
> webserver can handle authentication and pass the authenticated
> username to Keystone using the REMOTE_USER environment variable.
> External authentication behavior is handled by authentication plugins
> in Keystone.  In the Havana release of OpenStack, if the external
> username provided in the REMOTE_USER environment variable contains an
> "@" character Keystone will only use the portion preceding the "@"
> character as the username when using the "ExternalDefault"
> authentication plugin.  This results in the ability for multiple
> unique external usernames to map to the same single username in
> Keystone.  For example, the external usernames "jdoe at example1.com"
> and "jdoe at example2.com" would both map to the Keystone user "jdoe".
> This behavior could potentially be abused to allow one to impersonate
> another similarly named external user.
> 
> Keystone in OpenStack releases prior to Havana uses the entire value 
> contained in the REMOTE_USER environment variable, so those versions
> are not vulnerable to this impersonation issue.
> 
> ### Recommended Actions ### If the "ExternalDefault" plugin is being
> used for external authentication in the Havana release, you should
> ensure that external usernames do not contain "@" characters unless
> you want to collapse similarly named external users into a single
> user on the Keystone side.
> 
> If your external usernames do contain "@" characters and you do not
> want to collapse similarly named external users into a single user on
> the Keystone side, you might be able to use the "ExternalDomain"
> plug-in. This plugin considers the portion of the external username
> that follows an "@" character to be the domain that the user belongs
> to in Keystone. This allows similarly named external users to map to
> separate Keystone users if the portion of the external username that
> follows an "@" character maps to a Keystone domain name.  To
> configure the "ExternalDomain" authentication plugin, set the
> "external"  parameter in the "[auth]" section of Keystone's
> keystone.conf as follows:
> 
> ---- begin example keystone.conf snippet ---- [auth] methods =
> external,password,token,oauth1 external =
> keystone.auth.plugins.external.ExternalDomain ---- end example
> keystone.conf snippet ----
> 
> If neither of the above recommendations work for your deployment, a 
> custom authentication plugin can be created that uses the external 
> username that contains an "@" character as-is.
> 
> ### Contacts / References ### This OSSN :
> https://bugs.launchpad.net/ossn/+bug/1254619 Original LaunchPad Bug :
> https://bugs.launchpad.net/keystone/+bug/1254619 OpenStack Security
> ML : openstack-security at lists.openstack.org OpenStack Security Group
> : https://launchpad.net/~openstack-ossg
> 



From nkinder at redhat.com  Sat Jan 11 16:09:24 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Sat, 11 Jan 2014 08:09:24 -0800
Subject: [Openstack-security] [Bug 1254619] Re: external.Default
 authentication plugin only	considers leftmost part of the REMOTE_USER split
 by "@"
In-Reply-To: <52D11BE0.9060107@kent.ac.uk>
References: <20131125081604.9897.68214.malonedeb@gac.canonical.com>
 <20140111055708.26410.74526.malone@wampee.canonical.com>
 <52D11BE0.9060107@kent.ac.uk>
Message-ID: <52D16CB4.8@redhat.com>

On 01/11/2014 02:24 AM, David Chadwick wrote:
> It seems to me that changing the action of ExternalDefault in the Havana
> release was fundamentally wrong. Surely the default action should be to
> take the external username that Apache provides and use it "as is",
> which is what the previous releases of Keystone did. So why cant we
> simply revert the Havana release to behave the same way as previous
> releases.

I believe that this is what Dolph (Keystone PTL) plans to do based off
of my discussions with him yesterday.  The change hasn't been made yet,
so I don't want to have the OSSN say anything until we know the exact
course of action that is being taken in Havana.

Thanks,
-NGK

> 
> regards
> 
> David
> 
> On 11/01/2014 05:57, Nathan Kinder wrote:
>> I've finished a draft of the OSSN for this issue.  It's still
>> unclear exactly what the fix (if any) is going to be for a Havana
>> update, so the OSSN doesn't mention anything about potential future
>> changes.  The OSSN draft follows below.
>>
>> -------------------------------------------------------------------------------------------------------------------------
>>
>>  Keystone can allow user impersonation when using REMOTE_USER for
>> external authentication. ---
>>
>> ### Summary ### When external authentication is used with Keystone
>> using the "ExternalDefault" plug-in, external usernames containing
>> "@" characters are truncated at the "@" character before being mapped
>> to a local Keystone user.  This can result in separate external users
>> mapping to the same local Keystone user, which could lead to user
>> impersonation.
>>
>> ### Affected Services / Software ### Keystone, Havana
>>
>> ### Discussion ### When Keystone is run in Apache HTTP Server, the
>> webserver can handle authentication and pass the authenticated
>> username to Keystone using the REMOTE_USER environment variable.
>> External authentication behavior is handled by authentication plugins
>> in Keystone.  In the Havana release of OpenStack, if the external
>> username provided in the REMOTE_USER environment variable contains an
>> "@" character Keystone will only use the portion preceding the "@"
>> character as the username when using the "ExternalDefault"
>> authentication plugin.  This results in the ability for multiple
>> unique external usernames to map to the same single username in
>> Keystone.  For example, the external usernames "jdoe at example1.com"
>> and "jdoe at example2.com" would both map to the Keystone user "jdoe".
>> This behavior could potentially be abused to allow one to impersonate
>> another similarly named external user.
>>
>> Keystone in OpenStack releases prior to Havana uses the entire value 
>> contained in the REMOTE_USER environment variable, so those versions
>> are not vulnerable to this impersonation issue.
>>
>> ### Recommended Actions ### If the "ExternalDefault" plugin is being
>> used for external authentication in the Havana release, you should
>> ensure that external usernames do not contain "@" characters unless
>> you want to collapse similarly named external users into a single
>> user on the Keystone side.
>>
>> If your external usernames do contain "@" characters and you do not
>> want to collapse similarly named external users into a single user on
>> the Keystone side, you might be able to use the "ExternalDomain"
>> plug-in. This plugin considers the portion of the external username
>> that follows an "@" character to be the domain that the user belongs
>> to in Keystone. This allows similarly named external users to map to
>> separate Keystone users if the portion of the external username that
>> follows an "@" character maps to a Keystone domain name.  To
>> configure the "ExternalDomain" authentication plugin, set the
>> "external"  parameter in the "[auth]" section of Keystone's
>> keystone.conf as follows:
>>
>> ---- begin example keystone.conf snippet ---- [auth] methods =
>> external,password,token,oauth1 external =
>> keystone.auth.plugins.external.ExternalDomain ---- end example
>> keystone.conf snippet ----
>>
>> If neither of the above recommendations work for your deployment, a 
>> custom authentication plugin can be created that uses the external 
>> username that contains an "@" character as-is.
>>
>> ### Contacts / References ### This OSSN :
>> https://bugs.launchpad.net/ossn/+bug/1254619 Original LaunchPad Bug :
>> https://bugs.launchpad.net/keystone/+bug/1254619 OpenStack Security
>> ML : openstack-security at lists.openstack.org OpenStack Security Group
>> : https://launchpad.net/~openstack-ossg
>>
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 




From fungi at yuggoth.org  Sat Jan 11 20:25:16 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Sat, 11 Jan 2014 20:25:16 -0000
Subject: [Openstack-security] [Bug 1262759] Re: ICMPv6 RAs should only be
	permitted from known	routers
References: <20131219170628.26400.87374.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140111202517.25571.84808.launchpad@gac.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/1262759

Title:
  ICMPv6 RAs should only be permitted from known routers

Status in OpenStack Neutron (virtual network service):
  New
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  ICMPv6 is now allowed in from any host but other hosts can offer bogus
  routes.

  Change security group/port filtering to respect known routers:

  - tenant routers attached to subnets and passing v6
  - physical routers on provider networks provided on the network (as some sort of admin configurable list for that network).

  (Security issue: One VM sharing a neutron network can divert outgoing
  traffic from other VMs.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1262759/+subscriptions



From thierry.carrez+lp at gmail.com  Mon Jan 13 13:02:50 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 13 Jan 2014 13:02:50 -0000
Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString uses
	OS entropy source	directly
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
Message-ID: <20140113130251.18716.8331.malone@wampee.canonical.com>

Opened.

** Information type changed from Private Security to Public

** Tags added: security

** No longer affects: ossa

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1267912

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions



From jarret.raim at RACKSPACE.COM  Mon Jan 13 15:57:50 2014
From: jarret.raim at RACKSPACE.COM (Jarret Raim)
Date: Mon, 13 Jan 2014 15:57:50 +0000
Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString
 uses OS entropy source directly
In-Reply-To: <20140113130251.18716.8331.malone@wampee.canonical.com>
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140113130251.18716.8331.malone@wampee.canonical.com>
Message-ID: <CEF97213.12ECA%jarret.raim@rackspace.com>

All,


I¹d be concerned about making this change. Fundamentally, the os
/dev/urandom is cryptographically secure while creating a
cryptographically secure PRNG is actually quite difficult, especially one
built on PyCrypto which is a non-verified code base.

In the case of /dev/urandom, it seeds from the internal pool that also
supplies /dev/random. Once this seeding is complete, urandom can be relied
upon to supply random data without blocking or exhaustion problems. The
only time when there could be an issue is shortly after boot before the
kernel has generated enough entropy to sufficiently seed urandom.

This problem seems unlikely to appear in most OpenStack deployments and is
the same problem one would have to solve to adequately seed the PyCrypto
PRNG anyway.

Barbican has been thinking about exposing a /random resource that would
allow any user (no auth required) to pull a block of truly random data
from the HSMs for any case where someone would need it. We¹ve been on the
fence as the actual use cases seem nonexistent at the moment, but it is an
option for the future if we need it.

In short - we can probably leave the code the way it is.


Jarret



On 1/13/14, 7:02 AM, "Thierry Carrez" <thierry.carrez+lp at gmail.com> wrote:

>Opened.
>
>** Information type changed from Private Security to Public
>
>** Tags added: security
>
>** No longer affects: ossa
>
>-- 
>You received this bug notification because you are a member of OpenStack
>Security Group, which is subscribed to OpenStack.
>https://bugs.launchpad.net/bugs/1267912
>
>Title:
>  OS::Heat::RandomString uses OS entropy source directly
>
>Status in Orchestration API (Heat):
>  Confirmed
>
>Bug description:
>  The RandomString resource documentation[1] suggests that it's useful
>  for generating passwords and secrets. It doesn't mention the security
>  guarantees, however.
>
>  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
>  something like PyCrypto or better yet, have Oslo provide a
>  cryptographically secure random generator and use that.
>
>  On Linux, random.SystemRandom reads from /dev/urandom which if I
>  understand things correctly, can have its entropy depleted. So a Heat
>  user could use a template that asks for a huge amount of randomness
>  and empty the entropy pool of the entire system (not just Heat).
>
>  This would probably be difficult to exploit, but I think it'd be safer
>  use the entropy to seed a CSPRNG instead of using it directly. Which
>  is exactly what PyCrypto seems to do.
>
>  Regardless, the security guarantees and implications of
>  OS::Heat::RandomString should be documented.
>
>  [1]: 
>http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS:
>:Heat::RandomString
>  [2]: 
>https://github.com/openstack/heat/blob/master/heat/engine/resources/random
>_string.py#L81
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5551 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140113/e2848971/attachment.bin>

From nkinder at redhat.com  Mon Jan 13 16:24:41 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Mon, 13 Jan 2014 08:24:41 -0800
Subject: [Openstack-security] Security Note (OSSN) Process
Message-ID: <52D41349.6010202@redhat.com>

Hi,

I have started to put together a wiki page skeleton outlining the
process to follow when writing a new Security Note (OSSN).  I think it's
far enough along to share.  Any feedback and suggestions would be
appreciated!  The new page is available here:

    https://wiki.openstack.org/wiki/Security/Security_Note_Process

There are a few things that I think need to be added or clarified:

- Do we want to change the numbering scheme?  We've discussed using
something similar to the OSSA numbering scheme (YYYY-XX).  This would be
an improvement over what we currently use (Launchpad bug #).

- When is a CVE needed, and how is CVE filing handled?  Should we
consult with the VMT team and let them make the determination?

Thanks,
-NGK




From clint at fewbar.com  Mon Jan 13 16:34:38 2014
From: clint at fewbar.com (Clint Byrum)
Date: Mon, 13 Jan 2014 16:34:38 -0000
Subject: [Openstack-security] [Bug 1267912] Re:
	OS::Heat::RandomString	uses OS entropy source directly
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140113130251.18716.8331.malone@wampee.canonical.com>
 <CEF97213.12ECA%jarret.raim@rackspace.com>
Message-ID: <1389630466-sup-2174@clint-HP>

Excerpts from Jarret Raim's message of 2014-01-13 15:57:50 UTC:
> All,
> 
> 
> I¹d be concerned about making this change. Fundamentally, the os
> /dev/urandom is cryptographically secure while creating a
> cryptographically secure PRNG is actually quite difficult, especially one
> built on PyCrypto which is a non-verified code base.
> 
> In the case of /dev/urandom, it seeds from the internal pool that also
> supplies /dev/random. Once this seeding is complete, urandom can be relied
> upon to supply random data without blocking or exhaustion problems. The
> only time when there could be an issue is shortly after boot before the
> kernel has generated enough entropy to sufficiently seed urandom.
> 
> This problem seems unlikely to appear in most OpenStack deployments and is
> the same problem one would have to solve to adequately seed the PyCrypto
> PRNG anyway.
> 
> Barbican has been thinking about exposing a /random resource that would
> allow any user (no auth required) to pull a block of truly random data
> from the HSMs for any case where someone would need it. We¹ve been on the
> fence as the actual use cases seem nonexistent at the moment, but it is an
> option for the future if we need it.
> 
> In short - we can probably leave the code the way it is.

Agreed, this is not a code bug. The description contains a false
assumption:

"On Linux, random.SystemRandom reads from /dev/urandom which if I
understand things correctly, can have its entropy depleted."

This is not the case, and the u in urandom is presumed to mean
"unlimited". It is a PRNG, though constantly seeded by real entropy,
it may re-use entropy from /dev/random's pool.

The intention for the RandomString resource is for generating passwords
and shared secrets between servers.

So, I think we should document that this is not suitable for long term
encryption keys, and any such need should be satisfied in-instance where
nova-compute can manage access to /dev/random entropy via the hypervisor.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1267912

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions



From kseifried at redhat.com  Mon Jan 13 19:01:39 2014
From: kseifried at redhat.com (Kurt Seifried)
Date: Mon, 13 Jan 2014 12:01:39 -0700
Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString
 uses OS entropy source directly
In-Reply-To: <CEF97213.12ECA%jarret.raim@rackspace.com>
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140113130251.18716.8331.malone@wampee.canonical.com>
 <CEF97213.12ECA%jarret.raim@rackspace.com>
Message-ID: <52D43813.9010508@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2014 08:57 AM, Jarret Raim wrote:
> All,
> 
> 
> I¹d be concerned about making this change. Fundamentally, the os 
> /dev/urandom is cryptographically secure while creating a 
> cryptographically secure PRNG is actually quite difficult,
> especially one built on PyCrypto which is a non-verified code
> base.
> 
> In the case of /dev/urandom, it seeds from the internal pool that
> also supplies /dev/random. Once this seeding is complete, urandom
> can be relied upon to supply random data without blocking or
> exhaustion problems. The only time when there could be an issue is
> shortly after boot before the kernel has generated enough entropy
> to sufficiently seed urandom.
> 
> This problem seems unlikely to appear in most OpenStack deployments
> and is the same problem one would have to solve to adequately seed
> the PyCrypto PRNG anyway.
> 
> Barbican has been thinking about exposing a /random resource that
> would allow any user (no auth required) to pull a block of truly
> random data from the HSMs for any case where someone would need it.
> We¹ve been on the fence as the actual use cases seem nonexistent at
> the moment, but it is an option for the future if we need it.
> 
> In short - we can probably leave the code the way it is.
> 
> 
> Jarret

Just a heads up, you aren't the only people with this problem:

https://bugzilla.redhat.com/show_bug.cgi?id=786408
[RFE] Need ability to configure system entropy source for qemu

https://bugzilla.redhat.com/show_bug.cgi?id=786407
[RFE] Add ability to pull system entropy from host

So it's been solved to some degree, Steve Grubb sgrubb at redhat.com is
definitely the guy to talk to about this if you want some help. (CC'ed).


- -- 
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

iQIcBAEBAgAGBQJS1DgTAAoJEBYNRVNeJnmTwyQP/RaJVU/SxtJbZsSsGO0j2rVv
3no4m3QZGeQRTpJGsF/6OpoMqeI7WrADRdKAiqT019aLOhqcM+P7ZzD8oLGll4dH
e+Glk62T1KT9wL4bremiFI0MwIxnf0gDmYYSrBdhDhS+nm0JBZNG3zpNIU5TglNh
emeRtf4Q4DYF2y4ZJBASHafzU5hMH3Z8iNA1QlZVYhMxQjM3SJCz8HjjQbdUnry7
8UHS2y18s5odqO3ibVUpZjEvO6fr/A1yb4PveUN4Jsw2NBi10WlgHehA1HUl/Bc+
nxfGPwhjaGjyZH8xG7xbTdacQpwZzlqj/U1o6p3UFJ6jfzr75ON1FDdOgci+7glY
72DobZfbcqojRek5WdAbVPYECr8LrlIKl0v4YUHUQ8DlZQs3ecryLUm/F5ynf9Ht
Darg2XgPcr90KoYsLlg/NQSZeRFl+u2nyhvxVWCQLFG7K2meCeEKh+2oM6XcK6U/
51i2i0rT+iS7PiCgecBWN0B1fMgtmntFmYs2U8Hv1GNGwjSL/LI494BkIbEYjRWN
9r/sBa9QMEceV/UaGVuZ0BmPzAGzo2yhYfGqcXn1JH3q9f4u8tQhRvqPgVhB3AWQ
o91ipO8JJKEx68DxpJButarbyFjtkC7dTrdxpt9+Cs/wVjTrMQdRaA1p03Bcx6sy
qpuNu87aop6QY/kjZeHc
=qQ8M
-----END PGP SIGNATURE-----



From gerrit2 at review.openstack.org  Mon Jan 13 21:13:55 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 13 Jan 2014 21:13:55 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W2opX-0007TQ-SI@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit d2fbdbe3289c7b8c03c104b559a2b60e2c95f7b8
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gmurphy at redhat.com  Tue Jan 14 00:27:30 2014
From: gmurphy at redhat.com (Grant Murphy)
Date: Tue, 14 Jan 2014 10:27:30 +1000
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <52D41349.6010202@redhat.com>
References: <52D41349.6010202@redhat.com>
Message-ID: <1389659250.31175.8.camel@lappy>



On Mon, 2014-01-13 at 08:24 -0800, Nathan Kinder wrote:
> Hi,

Hi Nathan, 

> 
> I have started to put together a wiki page skeleton outlining the
> process to follow when writing a new Security Note (OSSN).  I think it's
> far enough along to share.  Any feedback and suggestions would be
> appreciated!  The new page is available here:
> 
>     https://wiki.openstack.org/wiki/Security/Security_Note_Process
> 
> There are a few things that I think need to be added or clarified:
> 
> - Do we want to change the numbering scheme?  We've discussed using
> something similar to the OSSA numbering scheme (YYYY-XX).  This would be
> an improvement over what we currently use (Launchpad bug #).
> 

I have no strong opinion about a numbering system. My only concern would
be if people get confused about the difference between an OSSA and a
OSSN. One thing I would like to start doing is to track OSSA & OSSN in a
more 'computer friendly' format. For example rubysec keeps advisories in
github in yaml format. This allows tooling to be built around ensuring
deployments are secure, and also allows us to see trends in what we are
getting wrong as developers.  



> - When is a CVE needed, and how is CVE filing handled?  Should we
> consult with the VMT team and let them make the determination?
> 

The VMT process is documented here:
 https://wiki.openstack.org/wiki/VulnerabilityManagement

Anything that is considered a vulnerability should be reported to the
VMT. If it is deemed that a CVE is not warranted a OSSN may be issued. 


HTH

- Grant.


> Thanks,
> -NGK
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security






From nkinder at redhat.com  Tue Jan 14 01:39:04 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Mon, 13 Jan 2014 17:39:04 -0800
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <1389659250.31175.8.camel@lappy>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
Message-ID: <52D49538.3080602@redhat.com>

On 01/13/2014 04:27 PM, Grant Murphy wrote:
> 
> 
> On Mon, 2014-01-13 at 08:24 -0800, Nathan Kinder wrote:
>> Hi,
> 
> Hi Nathan, 
> 
>>
>> I have started to put together a wiki page skeleton outlining the
>> process to follow when writing a new Security Note (OSSN).  I think it's
>> far enough along to share.  Any feedback and suggestions would be
>> appreciated!  The new page is available here:
>>
>>     https://wiki.openstack.org/wiki/Security/Security_Note_Process
>>
>> There are a few things that I think need to be added or clarified:
>>
>> - Do we want to change the numbering scheme?  We've discussed using
>> something similar to the OSSA numbering scheme (YYYY-XX).  This would be
>> an improvement over what we currently use (Launchpad bug #).
>>
> 
> I have no strong opinion about a numbering system. My only concern would
> be if people get confused about the difference between an OSSA and a
> OSSN. 

My problem with the current OSSN numbering scheme is that it gives no
indication of when the OSSN was published.  For example, a newer
Launchpad bug could result in a published OSSN before an older one.  It
would be nice to be able to compare two OSSN numbers and immediately
tell which is newer.

> One thing I would like to start doing is to track OSSA & OSSN in a
> more 'computer friendly' format. For example rubysec keeps advisories in
> github in yaml format. This allows tooling to be built around ensuring
> deployments are secure, and also allows us to see trends in what we are
> getting wrong as developers.  

This is a goal of mine as well.  I did some brief investigation a while
back into CVRF, which looks like a good potential option.  This is a
discussion I'd like to bring up with the VMT to get their thoughts.

> 
> 
> 
>> - When is a CVE needed, and how is CVE filing handled?  Should we
>> consult with the VMT team and let them make the determination?
>>
> 
> The VMT process is documented here:
>  https://wiki.openstack.org/wiki/VulnerabilityManagement
> 
> Anything that is considered a vulnerability should be reported to the
> VMT. If it is deemed that a CVE is not warranted a OSSN may be issued. 

We've published OSSNs that have a CVE associated with them.  I believe
that what happened in those cases is that the issue was looked at by the
VMT and a CVE was assigned while assessing the issue.  The issues were
low priority enough that it was determined that they should be handled
as OSSNs instead of OSSAs.

> 
> 
> HTH
> 
> - Grant.

Thanks for the feedback.  It's much appreciated!

-NGK
> 
> 
>> Thanks,
>> -NGK
>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
> 
> 




From kseifried at redhat.com  Tue Jan 14 02:13:54 2014
From: kseifried at redhat.com (Kurt Seifried)
Date: Mon, 13 Jan 2014 19:13:54 -0700
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <1389659250.31175.8.camel@lappy>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
Message-ID: <52D49D62.7060503@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2014 05:27 PM, Grant Murphy wrote:
> 
> 
> On Mon, 2014-01-13 at 08:24 -0800, Nathan Kinder wrote:
>> Hi,
> 
> Hi Nathan,
> 
>> 
>> I have started to put together a wiki page skeleton outlining
>> the process to follow when writing a new Security Note (OSSN).  I
>> think it's far enough along to share.  Any feedback and
>> suggestions would be appreciated!  The new page is available
>> here:
>> 
>> https://wiki.openstack.org/wiki/Security/Security_Note_Process
>> 
>> There are a few things that I think need to be added or
>> clarified:
>> 
>> - Do we want to change the numbering scheme?  We've discussed
>> using something similar to the OSSA numbering scheme (YYYY-XX).
>> This would be an improvement over what we currently use
>> (Launchpad bug #).

One note I would use the same number sequence, e.g.:

OSSA-2014-01
OSSA-2014-02
OSSN-2014-03

The reason for this: "OSSA-2014-01" vs "OSSN-2014-01" is kind of
messy, harder to search/etc. Also I would advice using more than 2
digits (3 should be safe).


- -- 
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

iQIcBAEBAgAGBQJS1J1iAAoJEBYNRVNeJnmTqmsP/0XQuAKdOvYOVvNmhX0PBfSA
wFrqU75DBsR5yH70tZzb6MZvZNdRETB5/fTRpXf5zi6wqPmWks+hWmRLlkA6+E9i
yFcwJHoC/BMl7k6UmHYMnWVnzFhfFFW6LUWE/wRw/q6VMzvloqIipT1eFmn6onZI
H6lSm332LPqoSmlEvxjx3rOyhoPuj59SKIfDKLoRx1J4U95BaAeQdUkqSpAyfhbQ
ESla5+TWWL29CxjTcPllCcxo15U6TN9H4skK2VPDB9A9wXdjuhSpaU7xoQBiCpQL
j8XBDtob9yfcpPGaAM6DDg0UnjfzaCsT6TRq4XN4KFD8Ri/tah4VZ680zh51+0C2
3blJC6HkseTAa8F3x4wB6CpAKjm1fnsdaEbstTrVFvAWqUEX3U90nOlhDxUdBEIQ
G+ZTqoYYJZvv4OndLqJRzSWD/Cr0QjVtow53vqIyYn9prRT8nO/USceOZX4gx44F
BRtBLhi/mEE9c4nFHEwAadkefoot1s9JD7WycVJWHzUKs1B9iurPv1UlmjePPyGh
yW+QekR6fCdjO02UFYzh8XXpqreSrHjnPCiQiUr4/03B76wN6ERgreq/76d4mkfY
S+mViSzEL2lG8in4KUbMO1Ql5OPTscUdH0WhsPOYbQkFaj5xPE9GfBcVZbDqvXoX
AT9mzC7goal1peHMz12z
=QQtF
-----END PGP SIGNATURE-----



From nkinder at redhat.com  Tue Jan 14 02:23:39 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Mon, 13 Jan 2014 18:23:39 -0800
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <52D49D62.7060503@redhat.com>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com>
Message-ID: <52D49FAB.2030405@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2014 06:13 PM, Kurt Seifried wrote:
> On 01/13/2014 05:27 PM, Grant Murphy wrote:
> 
> 
>> On Mon, 2014-01-13 at 08:24 -0800, Nathan Kinder wrote:
>>> Hi,
> 
>> Hi Nathan,
> 
>>> 
>>> I have started to put together a wiki page skeleton outlining 
>>> the process to follow when writing a new Security Note (OSSN).
>>> I think it's far enough along to share.  Any feedback and 
>>> suggestions would be appreciated!  The new page is available 
>>> here:
>>> 
>>> https://wiki.openstack.org/wiki/Security/Security_Note_Process
>>> 
>>> There are a few things that I think need to be added or 
>>> clarified:
>>> 
>>> - Do we want to change the numbering scheme?  We've discussed 
>>> using something similar to the OSSA numbering scheme
>>> (YYYY-XX). This would be an improvement over what we currently
>>> use (Launchpad bug #).
> 
> One note I would use the same number sequence, e.g.:
> 
> OSSA-2014-01 OSSA-2014-02 OSSN-2014-03
> 
> The reason for this: "OSSA-2014-01" vs "OSSN-2014-01" is kind of 
> messy, harder to search/etc. Also I would advice using more than 2 
> digits (3 should be safe).

I like it.  That prevents the OSSA/OSSN confusion problem and it also
has the benefit of allowing us to easily compare the publishing date
between an OSSA and OSSN.

> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS1J+gAAoJEJa+6E7Ri+EVA54H/1bmVEPdceEgb1XuVBY/P6dU
lqUE/6NfbRXzFWf4YXiY6REtzn3lHh+pkA44N9hU1LqTdK5p/KaO/9W0eBiCt+3L
xMJETZpCUteZ4U2xFhjlAob9CBuw9P2GoWHxyLNRVZFbSONGOaxz8SovIV+sl0SK
I9vvn5SCzmBhKkwnXsB76ka5gzG1esI+Pkzh7/j5aXfHYDmhYfJ/7ea3RoK7hr1r
hjRKOlvB/BgBDvnrU/PfLSlf60xK3hPzXqX0neG7dX9pZ5WP2EtstxRbNSSV89Af
vl4hZRapV3L7c1zyPk6quycRw03FEJZk2+T31l1MIg44/LMMEBk1K0f4O3v0nKQ=
=Ajh9
-----END PGP SIGNATURE-----



From thierry at openstack.org  Tue Jan 14 09:37:44 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 14 Jan 2014 10:37:44 +0100
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <52D49FAB.2030405@redhat.com>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com> <52D49FAB.2030405@redhat.com>
Message-ID: <52D50568.8050809@openstack.org>

Nathan Kinder wrote:
>> One note I would use the same number sequence, e.g.:
> 
>> OSSA-2014-01 OSSA-2014-02 OSSN-2014-03
> 
>> The reason for this: "OSSA-2014-01" vs "OSSN-2014-01" is kind of 
>> messy, harder to search/etc. Also I would advice using more than 2 
>> digits (3 should be safe).
> 
> I like it.  That prevents the OSSA/OSSN confusion problem and it also
> has the benefit of allowing us to easily compare the publishing date
> between an OSSA and OSSN.

I think it actually increases the confusion, and we'd need to build some
central numbering authority to make sure we don't reuse the same number...

OSSAs (and CVEs) are vulnerabilities, so they are serial events very
related to the time of their publication, hence the numbering. OSSNs are
more like security best practices: and those are permanent, eternal and
their order doesn't matter that much. What you need is a convenient way
to uniquely identify them, and then a mechanism to publish updated
version of them if need be.

For example you could use a single serial number with a date-based
edition version, like "OSSN 12 (2014-01-20 edition)". That would let you
revisit some topics as the software evolves over time.

(In summary, OSSAs are like a calendar with events, while OSSNs are like
a reference book with chapters. You would not number book chapters after
the date the chapter was originally written).

About CVEs: since anybody can request a CVE to be assigned about a
specific issue and everyone has a different opinion on what constitues a
"vulnerability", there have been a number of issues in the past that had
CVE assigned to them and did not trigger an OSSA. They tend to fall into
two categories though: CVE assigned by the VMT but not triggering an
OSSA, or CVE assigned by some other party (generally a distribution).
For that reason I don't think you need to be concerned too much about
CVE assignment. To handle the corner case where one is warranted but
nobody ever assigned one, you can always ask the VMT or this list for one.

-- 
Thierry Carrez (ttx)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140114/d8756767/attachment.sig>

From gerrit2 at review.openstack.org  Tue Jan 14 14:25:22 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 14 Jan 2014 14:25:22 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W34vi-0005UY-RY@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 245d542e7f0aab2b19c058ebee4045c35b1011f4
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From nkinder at redhat.com  Wed Jan 15 22:53:15 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Wed, 15 Jan 2014 22:53:15 -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: <20140115225315.426.61799.malone@gac.canonical.com>

> "When Keystone is run in Apache HTTP Server" isn't this normally
described as running Keystone "behind" apache?

Keystone is actually run as a child of the httpd process by using
mod_wsgi, so I think "in Apache HTTP Server" is appropriate here.

> We probably shouldn't use Oauthv1 in our configuration snippet as it's
not without it's own security considerations.

I can pull this out.  It was in the default config on my Havana RDO
install, so I was simply using the default config in the example.

-- 
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):
  Fix Committed
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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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 devoid at anl.gov  Thu Jan 16 00:09:43 2014
From: devoid at anl.gov (Scott Devoid)
Date: Thu, 16 Jan 2014 00:09:43 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Possible to get and update
	quotas for nonexistant	tenant
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140116000943.19628.67736.launchpad@chaenomeles.canonical.com>

** Tags added: security ux

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Possible to get and update quotas for nonexistant tenant

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From devoid at anl.gov  Thu Jan 16 00:08:29 2014
From: devoid at anl.gov (Scott Devoid)
Date: Thu, 16 Jan 2014 00:08:29 -0000
Subject: [Openstack-security] [Bug 1031139] Re: quota-show does not handle
	alternatives for	tenant_id as expected
References: <20120730234300.27634.40825.malonedeb@gac.canonical.com>
Message-ID: <20140116000829.25258.98582.malone@wampee.canonical.com>

I am able to replicate the bug using the Havana version of the tools:
http://paste.openstack.org/show/61321/

Marking as New for that reason.

@melwitt Please do not mark bugs as "Fix Committed" unless you can
supply the specific patch set that fixes the bug. Attempting to
replicate in Devstack is not sufficient to guarantee that the bug has
been fixed.

** Tags added: security ux

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1031139

Title:
  quota-show does not handle alternatives for tenant_id as expected

Status in Python client library for Nova:
  New

Bug description:
  quota-show does not handle alternatives for tenant_id as expected

  ENV: Devstack trunk (Folsom) / nova
  d56b5fc3ad6dbfc56e0729174925fb146cef87fa ,  Mon Jul 30 21:59:56 2012
  +0000

  I'd expect the following command to work as $ env | grep TENANT ->
  OS_TENANT_NAME=demo

  $ nova --debug --os_username=admin --os_password=password quota-show 
  usage: nova quota-show <tenant_id>
  error: too few arguments

  
  I'd also expect the following to work:
  $ nova --debug --os_username=admin --os_password=password quota-show --os_tenant_name=demo
  usage: nova quota-show <tenant_id>
  error: too few arguments

  
  What is more awesome, if in the event that I do provide the wrong tenant_id, it proceeds to use OS_TENANT_NAME returning those results:

  $nova --debug --os_username=admin --os_password=password quota-show
  gggggggggggggggggggggggggggggggggg

  REQ: curl -i
  http://10.1.11.219:8774/v2/04adebe40d214581b84118bcce264f0e/os-quota-
  sets/ggggggggggggggggggggggggggggggggggg -X GET -H "X-Auth-Project-Id:
  demo" -H "User-Agent: python-novaclient" -H "Accept: application/json"
  -H "X-Auth-Token: 10bd3f948df24039b2b88b98771b2b99"

  +-----------------------------+-------+
  | Property                    | Value |
  +-----------------------------+-------+
  | cores                       | 20    |
  | floating_ips                | 10    |
  | gigabytes                   | 1000  |
  | injected_file_content_bytes | 10240 |
  | injected_files              | 5     |
  | instances                   | 10    |
  | metadata_items              | 128   |
  | ram                         | 51200 |
  | volumes                     | 10    |
  +-----------------------------+-------+

  
  I also couldn't figure out how to get the quota-show to work as a member (non-admin) of a project.

  Let me know if you want any of these issues broken out in to
  additional bugs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-novaclient/+bug/1031139/+subscriptions



From gerrit2 at review.openstack.org  Thu Jan 16 06:58:10 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 06:58:10 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W3gu2-0000IN-4N@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit 1307b414597d35a9b4e94722b794e5a497f5ef95
Author: Jamie Lennox <jamielennox at redhat.com>
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  Thu Jan 16 07:00:30 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 07:00:30 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1W3gwI-0000Qk-2m@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59604

Log:
commit cffed221154a5bf9761cd7b9f391132956713e8a
Author: Jamie Lennox <jamielennox at redhat.com>
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  Thu Jan 16 07:44:24 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 07:44:24 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W3hcm-0003ey-Ct@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit a2134a25fc7cddffc7bb0a9544ac2756885958d2
Author: Jamie Lennox <jamielennox at redhat.com>
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  Thu Jan 16 07:46:17 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 07:46:17 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1W3heb-0003oC-5j@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59604

Log:
commit d682ba0c493ffe92b29499323facd1fe5c43867f
Author: Jamie Lennox <jamielennox at redhat.com>
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  Thu Jan 16 10:21:58 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 10:21:58 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I091b1620ab60184921cc12e038af5d717d4d476f
Message-ID: <E1W3k5G-0000aB-W1@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/65696

Log:
commit 43f9d33a842118639062fb22b190880fe8e2a610
Author: Sascha Peilicke <speilicke at suse.com>
Date:   Thu Jan 9 15:14:24 2014 +0100

    Support passing 'insecure' to neutronclient
    
    When using a self-signed certificate for the network service endpoint,
    the metadata agent has to pass the 'insecure' flag to neutronclient.
    Otherwise requests will fail due to the failed certificate validity
    check.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1269740
    Change-Id: I091b1620ab60184921cc12e038af5d717d4d476f




From ahmeda at cs.umu.se  Thu Jan 16 11:27:57 2014
From: ahmeda at cs.umu.se (Ahmed Aley)
Date: Thu, 16 Jan 2014 12:27:57 +0100
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <52D50568.8050809@openstack.org>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com> <52D49FAB.2030405@redhat.com>
 <52D50568.8050809@openstack.org>
Message-ID: <CAD5zmxhEzB=PO_OgMzYW0JKG2fkX7yo8DD6BFk_JuC2b4AgfJw@mail.gmail.com>

Hi,

How about having it like this:
OSSA-2014-01, OSSA-2014-02, OSSA-2014-03
OSSN-0114, OSSN-0214, OSSN-0314

This way you keep the relative ordering for both and it is easy to see when
was what issued with no confusion. I would also suggest adding categories
to OSSN, e.g, instead of OSSN-0114 have something like OSSN-NO-0114 where
the extra NO (or GL or something) in the middle indicates an acronym for
the project (Nova).

--Ahmed

On Tue, Jan 14, 2014 at 10:37 AM, Thierry Carrez <thierry at openstack.org>wrote:

> Nathan Kinder wrote:
> >> One note I would use the same number sequence, e.g.:
> >
> >> OSSA-2014-01 OSSA-2014-02 OSSN-2014-03
> >
> >> The reason for this: "OSSA-2014-01" vs "OSSN-2014-01" is kind of
> >> messy, harder to search/etc. Also I would advice using more than 2
> >> digits (3 should be safe).
> >
> > I like it.  That prevents the OSSA/OSSN confusion problem and it also
> > has the benefit of allowing us to easily compare the publishing date
> > between an OSSA and OSSN.
>
> I think it actually increases the confusion, and we'd need to build some
> central numbering authority to make sure we don't reuse the same number...
>
> OSSAs (and CVEs) are vulnerabilities, so they are serial events very
> related to the time of their publication, hence the numbering. OSSNs are
> more like security best practices: and those are permanent, eternal and
> their order doesn't matter that much. What you need is a convenient way
> to uniquely identify them, and then a mechanism to publish updated
> version of them if need be.
>
> For example you could use a single serial number with a date-based
> edition version, like "OSSN 12 (2014-01-20 edition)". That would let you
> revisit some topics as the software evolves over time.
>
> (In summary, OSSAs are like a calendar with events, while OSSNs are like
> a reference book with chapters. You would not number book chapters after
> the date the chapter was originally written).
>
> About CVEs: since anybody can request a CVE to be assigned about a
> specific issue and everyone has a different opinion on what constitues a
> "vulnerability", there have been a number of issues in the past that had
> CVE assigned to them and did not trigger an OSSA. They tend to fall into
> two categories though: CVE assigned by the VMT but not triggering an
> OSSA, or CVE assigned by some other party (generally a distribution).
> For that reason I don't think you need to be concerned too much about
> CVE assignment. To handle the corner case where one is warranted but
> nobody ever assigned one, you can always ask the VMT or this list for one.
>
> --
> Thierry Carrez (ttx)
>
>
> _______________________________________________
> 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: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140116/8a3981be/attachment.html>

From gerrit2 at review.openstack.org  Thu Jan 16 11:51:25 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 11:51:25 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I091b1620ab60184921cc12e038af5d717d4d476f
Message-ID: <E1W3lTp-0008LF-EW@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/65696

Log:
commit 9c8e84e3049e4598025532fbcf2a03102de31f68
Author: Sascha Peilicke <speilicke at suse.com>
Date:   Thu Jan 9 15:14:24 2014 +0100

    Support passing 'neutron_insecure' to neutronclient
    
    When using a self-signed certificate for the network service endpoint,
    the metadata agent has to pass the 'insecure' flag to neutronclient.
    Otherwise requests will fail due to the failed certificate validity
    check.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1269740
    Change-Id: I091b1620ab60184921cc12e038af5d717d4d476f




From gerrit2 at review.openstack.org  Thu Jan 16 14:38:56 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 14:38:56 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W3o5w-00061k-Mq@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 3c843aaede3214c8be5b729f35e92277d2381aa2
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From doug.hellmann at dreamhost.com  Tue Jan  7 17:42:51 2014
From: doug.hellmann at dreamhost.com (Doug Hellmann)
Date: Tue, 07 Jan 2014 17:42:51 -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: <20140107174251.14439.79518.malone@chaenomeles.canonical.com>

It looks like the change landed in oslo, so I marked this as committed
there.

** Changed in: oslo
       Status: In Progress => Fix Committed

** Changed in: oslo
    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:
  Fix Committed

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 1254619 at bugs.launchpad.net  Fri Jan 10 15:47:58 2014
From: 1254619 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Jan 2014 15:47:58 -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: <20140110154801.7694.60659.launchpad@soybean.canonical.com>

** Changed in: keystone
     Assignee: Alvaro Lopez (aloga) => Adam Young (ayoung)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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  Fri Jan 10 22:26:33 2014
From: 1254619 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 10 Jan 2014 22:26:33 -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: <20140110222636.26138.28881.launchpad@wampee.canonical.com>

** Changed in: keystone
     Assignee: Adam Young (ayoung) => Dolph Mathews (dolph)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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  Sun Jan 12 00:39:14 2014
From: 1254619 at bugs.launchpad.net (OpenStack Infra)
Date: Sun, 12 Jan 2014 00:39:14 -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: <20140112003914.24725.32199.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/50362
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=1889ff207561c57587384063d61ef0b6f78457c4
Submitter: Jenkins
Branch:    master

commit 1889ff207561c57587384063d61ef0b6f78457c4
Author: Alvaro Lopez Garcia <aloga at ifca.unican.es>
Date:   Tue Oct 8 11:08:42 2013 +0200

    Fix external auth (REMOTE_USER) plugin support
    
    According to the WSGI specification "REMOTE_USER should be the string
    username of the user, nothing more" [1], therefore no modifications
    should be made to the REMOTE_USER variable and it should be fully
    considered as the username. Otherwise the expected semantics of the
    REMOTE_USER variable change, and an site administrator could get
    undesirable side-effects.
    
    [1] http://wsgi.readthedocs.org/en/latest/specifications/simple_authentication.html#specification
    
    Moreover, it is important to have a consistent behaviour regarding
    external authentication in V2 (not domain aware), V3 with default
    domain and V3 with domain (see Bug #1253484) so that we produce similar
    results with the three methods.
    
    This change aims to solve this issues by removing the split of the
    REMOTE_USER variable by "@" at all:
    
    - In external.DefaultDomain, we cannot split REMOTE_USER by "@". This split
      will cause errors for remote users containing an "@" (not only
      emails, but also X.509 subjects, etc). The external.DefaultDomain plugin
      considers the REMOTE_USER variable as the username, and the configured
      default domain as the domain
    
    - In external.Domain we should not split also the REMOTE_USER by "@". A
      new environment variable (REMOTE_DOMAIN) is introduced, so that any
      external plugin can pass down the right domain for the user. The
      external.Domain plugin considers the REMOTE_USER as the username, the
      REMOTE_DOMAIN as the domain if it is present, otherwise it takes the
      configured default domain.
    
    - Two legacy plugins are also provided with the same behaviour as the
      Havana shipped ones. This plugins should not be used and are provided
      for compatibility reasons (see Bug #1254619)
    
    Closes-Bug: #1254619
    Closes-Bug: #1211233
    Closes-Bug: #1253484
    
    DocImpact: This change breaks backwards compatibility in favour of
    security (see bug #1254619), therefore an upgrade not is needed. It is
    needed to document the new plugins and state clearly the semantics of
    the REMOTE_USER and REMOTE_DOMAIN variable for the WSGI filters. The
    default external authentication plugin has been changed from
    exernal.ExternalDefault to external.Default.
    
    Change-Id: I1b2521a526fa976146dfe2fcf4d4c1851416d8ae


** Changed in: keystone
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1254619

Title:
  external.Default authentication plugin only considers leftmost part of
  the REMOTE_USER split by "@"

Status in OpenStack Identity (Keystone):
  Fix Committed
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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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 1267912 at bugs.launchpad.net  Mon Jan 13 15:57:50 2014
From: 1267912 at bugs.launchpad.net (Jarret Raim)
Date: Mon, 13 Jan 2014 15:57:50 -0000
Subject: [Openstack-security] [Bug 1267912] Re:
	OS::Heat::RandomString	uses OS entropy source directly
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140113130251.18716.8331.malone@wampee.canonical.com>
Message-ID: <CEF97213.12ECA%jarret.raim@rackspace.com>

All,


I¹d be concerned about making this change. Fundamentally, the os
/dev/urandom is cryptographically secure while creating a
cryptographically secure PRNG is actually quite difficult, especially one
built on PyCrypto which is a non-verified code base.

In the case of /dev/urandom, it seeds from the internal pool that also
supplies /dev/random. Once this seeding is complete, urandom can be relied
upon to supply random data without blocking or exhaustion problems. The
only time when there could be an issue is shortly after boot before the
kernel has generated enough entropy to sufficiently seed urandom.

This problem seems unlikely to appear in most OpenStack deployments and is
the same problem one would have to solve to adequately seed the PyCrypto
PRNG anyway.

Barbican has been thinking about exposing a /random resource that would
allow any user (no auth required) to pull a block of truly random data
from the HSMs for any case where someone would need it. We¹ve been on the
fence as the actual use cases seem nonexistent at the moment, but it is an
option for the future if we need it.

In short - we can probably leave the code the way it is.


Jarret


On 1/13/14, 7:02 AM, "Thierry Carrez" <thierry.carrez+lp at gmail.com>
wrote:

>Opened.
>
>** Information type changed from Private Security to Public
>
>** Tags added: security
>
>** No longer affects: ossa
>
>-- 
>You received this bug notification because you are a member of OpenStack
>Security Group, which is subscribed to OpenStack.
>https://bugs.launchpad.net/bugs/1267912
>
>Title:
>  OS::Heat::RandomString uses OS entropy source directly
>
>Status in Orchestration API (Heat):
>  Confirmed
>
>Bug description:
>  The RandomString resource documentation[1] suggests that it's useful
>  for generating passwords and secrets. It doesn't mention the security
>  guarantees, however.
>
>  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
>  something like PyCrypto or better yet, have Oslo provide a
>  cryptographically secure random generator and use that.
>
>  On Linux, random.SystemRandom reads from /dev/urandom which if I
>  understand things correctly, can have its entropy depleted. So a Heat
>  user could use a template that asks for a huge amount of randomness
>  and empty the entropy pool of the entire system (not just Heat).
>
>  This would probably be difficult to exploit, but I think it'd be safer
>  use the entropy to seed a CSPRNG instead of using it directly. Which
>  is exactly what PyCrypto seems to do.
>
>  Regardless, the security guarantees and implications of
>  OS::Heat::RandomString should be documented.
>
>  [1]: 
>http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS:
>:Heat::RandomString
>  [2]: 
>https://github.com/openstack/heat/blob/master/heat/engine/resources/random
>_string.py#L81
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions
>
>_______________________________________________
>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/1267912

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions



From tomas at sedovic.cz  Mon Jan 13 17:30:15 2014
From: tomas at sedovic.cz (Tomas Sedovic)
Date: Mon, 13 Jan 2014 17:30:15 -0000
Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString uses
	OS entropy source	directly
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
Message-ID: <20140113173015.7764.217.malone@soybean.canonical.com>

Jarret and Clint, thanks for the clarification, I completely
misunderstood urandom.

In that case, it makes sense to keep using SystemRandom. On a tangential
note, I assumed PyCrypto has been audited since it's powering
oslo.crypto. Has that not been the case?

Anyway, I agree with Clint's suggestion regarding the documentation.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1267912

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions



From 1254619 at bugs.launchpad.net  Tue Jan 14 18:15:29 2014
From: 1254619 at bugs.launchpad.net (Dolph Mathews)
Date: Tue, 14 Jan 2014 18:15:29 -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: <20140114181529.26146.10816.malone@gac.canonical.com>

+1 for OSSN in comment #24

-- 
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):
  Fix Committed
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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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  Wed Jan 15 19:12:58 2014
From: 1254619 at bugs.launchpad.net (Robert Clark)
Date: Wed, 15 Jan 2014 19:12:58 -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: <20140115191258.30737.5460.malone@soybean.canonical.com>

Two thoughts on the OSSN:

"When Keystone is run in Apache HTTP Server" isn't this normally
described as running Keystone "behind" apache?

We probably shouldn't use Oauthv1 in our configuration snippet as it's
not without it's own security considerations.

Otherwise looks good to me :)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1254619

Title:
  external.Default authentication plugin only considers leftmost part of
  the REMOTE_USER split by "@"

Status in OpenStack Identity (Keystone):
  Fix Committed
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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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 1240382 at bugs.launchpad.net  Thu Jan 16 16:12:51 2014
From: 1240382 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 16 Jan 2014 16:12:51 -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: <20140116161253.32441.21877.launchpad@gac.canonical.com>

** Changed in: keystone
       Status: Confirmed => In Progress

** Changed in: keystone
     Assignee: Matthieu Huin (mhu-s) => Dolph Mathews (dolph)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1240382

Title:
  python-oauth2 dependency is unmaintained and has security issues

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  oauth2 is not maintained and have 2 CVE issues CVE-2013-4346 and CVE-2013-4347 and is not Python3 compatible
  can you remove this dependency (maybe switching to requests ? )

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1240382/+subscriptions



From 1240382 at bugs.launchpad.net  Thu Jan 16 17:02:42 2014
From: 1240382 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 16 Jan 2014 17:02:42 -0000
Subject: [Openstack-security] [Bug 1240382] Re: python-oauth2 dependency is
	unmaintained and has	security issues
References: <20131016072040.28005.15743.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140116170244.32683.53208.launchpad@gac.canonical.com>

** Changed in: keystone
     Assignee: Dolph Mathews (dolph) => David Stanek (dstanek)

-- 
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):
  In Progress

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 jarret.raim at RACKSPACE.COM  Thu Jan 16 17:16:32 2014
From: jarret.raim at RACKSPACE.COM (Jarret Raim)
Date: Thu, 16 Jan 2014 17:16:32 +0000
Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString
 uses OS entropy source directly
In-Reply-To: <20140113173015.7764.217.malone@soybean.canonical.com>
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140113173015.7764.217.malone@soybean.canonical.com>
Message-ID: <CEFD7D87.134C0%jarret.raim@rackspace.com>

As far as I know, the C backend for PyCrypto has not been audited. There
really isn¹t a supported Python library suitable for crypto use (if you
want something audited, obviously PyCrypto is widely deployed).

My team is working with a bunch of other folks to remedy this situation.
We are unifying a lot of the python libs and pretty much all of them are
onboard. It¹s too new to move oslo.crypto onto it, but that is my plan for
later this year. 

We just had our first release that is being used as the new backed for
pyopenssl, but there is lots of work left to do. I¹ve CC¹d Paul Kehrer who
is one of the Barbican devs working on the project.

The code is here if anyone is interested:
https://github.com/pyca/cryptography



Jarret



On 1/13/14, 12:30 PM, "Tomas Sedovic" <tomas at sedovic.cz> wrote:

>Jarret and Clint, thanks for the clarification, I completely
>misunderstood urandom.
>
>In that case, it makes sense to keep using SystemRandom. On a tangential
>note, I assumed PyCrypto has been audited since it's powering
>oslo.crypto. Has that not been the case?
>
>Anyway, I agree with Clint's suggestion regarding the documentation.
>
>-- 
>You received this bug notification because you are a member of OpenStack
>Security Group, which is subscribed to OpenStack.
>https://bugs.launchpad.net/bugs/1267912
>
>Title:
>  OS::Heat::RandomString uses OS entropy source directly
>
>Status in Orchestration API (Heat):
>  Confirmed
>
>Bug description:
>  The RandomString resource documentation[1] suggests that it's useful
>  for generating passwords and secrets. It doesn't mention the security
>  guarantees, however.
>
>  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
>  something like PyCrypto or better yet, have Oslo provide a
>  cryptographically secure random generator and use that.
>
>  On Linux, random.SystemRandom reads from /dev/urandom which if I
>  understand things correctly, can have its entropy depleted. So a Heat
>  user could use a template that asks for a huge amount of randomness
>  and empty the entropy pool of the entire system (not just Heat).
>
>  This would probably be difficult to exploit, but I think it'd be safer
>  use the entropy to seed a CSPRNG instead of using it directly. Which
>  is exactly what PyCrypto seems to do.
>
>  Regardless, the security guarantees and implications of
>  OS::Heat::RandomString should be documented.
>
>  [1]: 
>http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS:
>:Heat::RandomString
>  [2]: 
>https://github.com/openstack/heat/blob/master/heat/engine/resources/random
>_string.py#L81
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5551 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140116/311c45bd/attachment.bin>

From gerrit2 at review.openstack.org  Thu Jan 16 17:22:25 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 17:22:25 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W3qe9-0005ZC-Ux@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit eff6e2498cf44347b4b69e89c3130179561e93e1
Author: Jamie Lennox <jamielennox at redhat.com>
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  Thu Jan 16 17:22:33 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 17:22:33 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1W3qeH-0005aG-H4@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59604

Log:
commit f7b295a245977e96775d32a79af78cdf59f619b9
Author: Jamie Lennox <jamielennox at redhat.com>
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 1267912 at bugs.launchpad.net  Thu Jan 16 17:16:32 2014
From: 1267912 at bugs.launchpad.net (Jarret Raim)
Date: Thu, 16 Jan 2014 17:16:32 -0000
Subject: [Openstack-security] [Bug 1267912] Re:
	OS::Heat::RandomString	uses OS entropy source directly
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140113173015.7764.217.malone@soybean.canonical.com>
Message-ID: <CEFD7D87.134C0%jarret.raim@rackspace.com>

As far as I know, the C backend for PyCrypto has not been audited. There
really isn¹t a supported Python library suitable for crypto use (if you
want something audited, obviously PyCrypto is widely deployed).

My team is working with a bunch of other folks to remedy this situation.
We are unifying a lot of the python libs and pretty much all of them are
onboard. It¹s too new to move oslo.crypto onto it, but that is my plan for
later this year. 

We just had our first release that is being used as the new backed for
pyopenssl, but there is lots of work left to do. I¹ve CC¹d Paul Kehrer who
is one of the Barbican devs working on the project.

The code is here if anyone is interested:
https://github.com/pyca/cryptography


Jarret


On 1/13/14, 12:30 PM, "Tomas Sedovic" <tomas at sedovic.cz> wrote:

>Jarret and Clint, thanks for the clarification, I completely
>misunderstood urandom.
>
>In that case, it makes sense to keep using SystemRandom. On a tangential
>note, I assumed PyCrypto has been audited since it's powering
>oslo.crypto. Has that not been the case?
>
>Anyway, I agree with Clint's suggestion regarding the documentation.
>
>-- 
>You received this bug notification because you are a member of OpenStack
>Security Group, which is subscribed to OpenStack.
>https://bugs.launchpad.net/bugs/1267912
>
>Title:
>  OS::Heat::RandomString uses OS entropy source directly
>
>Status in Orchestration API (Heat):
>  Confirmed
>
>Bug description:
>  The RandomString resource documentation[1] suggests that it's useful
>  for generating passwords and secrets. It doesn't mention the security
>  guarantees, however.
>
>  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
>  something like PyCrypto or better yet, have Oslo provide a
>  cryptographically secure random generator and use that.
>
>  On Linux, random.SystemRandom reads from /dev/urandom which if I
>  understand things correctly, can have its entropy depleted. So a Heat
>  user could use a template that asks for a huge amount of randomness
>  and empty the entropy pool of the entire system (not just Heat).
>
>  This would probably be difficult to exploit, but I think it'd be safer
>  use the entropy to seed a CSPRNG instead of using it directly. Which
>  is exactly what PyCrypto seems to do.
>
>  Regardless, the security guarantees and implications of
>  OS::Heat::RandomString should be documented.
>
>  [1]: 
>http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS:
>:Heat::RandomString
>  [2]: 
>https://github.com/openstack/heat/blob/master/heat/engine/resources/random
>_string.py#L81
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions
>
>_______________________________________________
>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/1267912

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions



From gerrit2 at review.openstack.org  Thu Jan 16 19:22:29 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 19:22:29 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W3sWL-0008NE-KJ@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit 30a0bbfbb9cea7fe5b5b3445ec3708e546f24a66
Author: Jamie Lennox <jamielennox at redhat.com>
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
    Implements: bp key-distribution-server
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From 1240382 at bugs.launchpad.net  Thu Jan 16 19:30:59 2014
From: 1240382 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 16 Jan 2014 19:30: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: <20140116193101.25558.86024.launchpad@wampee.canonical.com>

** Changed in: keystone
     Assignee: David Stanek (dstanek) => Dolph Mathews (dolph)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1240382

Title:
  python-oauth2 dependency is unmaintained and has security issues

Status in OpenStack Identity (Keystone):
  In Progress

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 Jan 16 22:11:38 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 22:11:38 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W3vA2-0005Z8-G5@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit 0563bfd8ee7c3dee72cf81c8fb1d684cbdc0357d
Author: Jamie Lennox <jamielennox at redhat.com>
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
    Implements: bp key-distribution-server
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Thu Jan 16 22:11:44 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 16 Jan 2014 22:11:44 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1W3vA8-0005Zh-Ke@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59604

Log:
commit eefdf228d10c55c41e45e8c221760bc2c2b2e2cc
Author: Jamie Lennox <jamielennox at redhat.com>
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 gmurphy at redhat.com  Thu Jan 16 23:34:55 2014
From: gmurphy at redhat.com (Grant Murphy)
Date: Thu, 16 Jan 2014 23:34:55 -0000
Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString uses
	OS entropy source	directly
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
Message-ID: <20140116233455.19628.37938.malone@chaenomeles.canonical.com>

FWIW Tomas I can see how you may have thought that.

This is from the manpage of urandom:

A  read  from the /dev/urandom device will not block waiting for more entropy.  As a result, if there is not
sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic 
attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current 
unclassified literature, but  it is theoretically possible that such an attack may exist.  If this is a concern in
your application, use /dev/random instead.


(off topic) 
I would like to see a more consistent usage of cryptographic operations across the board. I guess this is the intention of Oslo. If the usage of PyCryto is not advised at this point in time would it make more sense to use something like PyOpenSSL in Oslo instead?  It looks like it is a backend for Jarret's cryptography module so would be a suitable as a temporary dependency or would that just introduce too much busy work?   

So my question is now - Should we raise a bug against the use of
PyCrypto is it hasn't been audited ?

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1267912

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions



From gerrit2 at review.openstack.org  Fri Jan 17 07:21:27 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 17 Jan 2014 07:21:27 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W43k7-000340-3y@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit c621815261011bc096995c46e9fd4ac4b2cdab6f
Author: Jamie Lennox <jamielennox at redhat.com>
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
    Implements: bp key-distribution-server
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Fri Jan 17 07:41:56 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 17 Jan 2014 07:41:56 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1W443w-0004dp-SF@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59604

Log:
commit a174977076390da42355470024aff756fff14d50
Author: Jamie Lennox <jamielennox at redhat.com>
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  Fri Jan 17 07:43:15 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 17 Jan 2014 07:43:15 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1W445D-0004li-SY@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59604

Log:
commit 5cdbf19c7d92c93c39e7423845cf421c6bde8fc0
Author: Jamie Lennox <jamielennox at redhat.com>
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 noloader at gmail.com  Fri Jan 17 08:00:57 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 17 Jan 2014 03:00:57 -0500
Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString
 uses OS entropy source directly
In-Reply-To: <20140116233455.19628.37938.malone@chaenomeles.canonical.com>
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140116233455.19628.37938.malone@chaenomeles.canonical.com>
Message-ID: <CAH8yC8nwUdz45PEGM6+WqEgqyn7msrmR2U3tap-hUE_UL4FKmg@mail.gmail.com>

> As a result, if there is not sufficient entropy in the entropy
> pool, the returned values are theoretically vulnerable to a
> cryptographic attack on the algorithms used by the driver.
To avoid entropy depletion attacks, you keep the generator in good
working order.

To keep the generator in good working order, you should consider
practicing hedging. Hedging ensures there is sufficient entropy even
if the platform cannot. As long the prng's state is held secret from
the attacker, the system will be in good working order.

The two papers of interest on hedging that I am aware: [0, 1].

Hedging is not dependent upon lower level drivers, like virtio. Even
if the virtio driver is misconfigured or broken, its will still
produce a usable stream (assuming initial state was sufficient).


[0] When Virtual is Harder than Real: Resource Allocation Challenges
in Virtual Machine Based IT Environments,
http://static.usenix.org/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf

[1] When Good Randomness Goes Bad: Virtual Machine Reset
Vulnerabilities and Hedging Deployed Cryptography,
http://www.isoc.org/isoc/conferences/ndss/10/pdf/15.pdf



On Thu, Jan 16, 2014 at 6:34 PM, Grant Murphy <gmurphy at redhat.com> wrote:
> FWIW Tomas I can see how you may have thought that.
>
> This is from the manpage of urandom:
>
> A  read  from the /dev/urandom device will not block waiting for more entropy.  As a result, if there is not
> sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic
> attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current
> unclassified literature, but  it is theoretically possible that such an attack may exist.  If this is a concern in
> your application, use /dev/random instead.
>
>
> (off topic)
> I would like to see a more consistent usage of cryptographic operations across the board. I guess this is the intention of Oslo. If the usage of PyCryto is not advised at this point in time would it make more sense to use something like PyOpenSSL in Oslo instead?  It looks like it is a backend for Jarret's cryptography module so would be a suitable as a temporary dependency or would that just introduce too much busy work?
>
> So my question is now - Should we raise a bug against the use of
> PyCrypto is it hasn't been audited ?
>
> --
> You received this bug notification because you are a member of OpenStack
> Security Group, which is subscribed to OpenStack.
> https://bugs.launchpad.net/bugs/1267912
>
> Title:
>   OS::Heat::RandomString uses OS entropy source directly
>
> Status in Orchestration API (Heat):
>   Confirmed
>
> Bug description:
>   The RandomString resource documentation[1] suggests that it's useful
>   for generating passwords and secrets. It doesn't mention the security
>   guarantees, however.
>
>   Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
>   something like PyCrypto or better yet, have Oslo provide a
>   cryptographically secure random generator and use that.
>
>   On Linux, random.SystemRandom reads from /dev/urandom which if I
>   understand things correctly, can have its entropy depleted. So a Heat
>   user could use a template that asks for a huge amount of randomness
>   and empty the entropy pool of the entire system (not just Heat).
>
>   This would probably be difficult to exploit, but I think it'd be safer
>   use the entropy to seed a CSPRNG instead of using it directly. Which
>   is exactly what PyCrypto seems to do.
>
>   Regardless, the security guarantees and implications of
>   OS::Heat::RandomString should be documented.
>
>   [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
>   [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81



From noloader at gmail.com  Fri Jan 17 08:00:57 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 17 Jan 2014 08:00:57 -0000
Subject: [Openstack-security] [Bug 1267912] Re:
	OS::Heat::RandomString	uses OS entropy source directly
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140116233455.19628.37938.malone@chaenomeles.canonical.com>
Message-ID: <CAH8yC8nwUdz45PEGM6+WqEgqyn7msrmR2U3tap-hUE_UL4FKmg@mail.gmail.com>

> As a result, if there is not sufficient entropy in the entropy
> pool, the returned values are theoretically vulnerable to a
> cryptographic attack on the algorithms used by the driver.
To avoid entropy depletion attacks, you keep the generator in good
working order.

To keep the generator in good working order, you should consider
practicing hedging. Hedging ensures there is sufficient entropy even
if the platform cannot. As long the prng's state is held secret from
the attacker, the system will be in good working order.

The two papers of interest on hedging that I am aware: [0, 1].

Hedging is not dependent upon lower level drivers, like virtio. Even
if the virtio driver is misconfigured or broken, its will still
produce a usable stream (assuming initial state was sufficient).


[0] When Virtual is Harder than Real: Resource Allocation Challenges
in Virtual Machine Based IT Environments,
http://static.usenix.org/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf

[1] When Good Randomness Goes Bad: Virtual Machine Reset
Vulnerabilities and Hedging Deployed Cryptography,
http://www.isoc.org/isoc/conferences/ndss/10/pdf/15.pdf


On Thu, Jan 16, 2014 at 6:34 PM, Grant Murphy <gmurphy at redhat.com> wrote:
> FWIW Tomas I can see how you may have thought that.
>
> This is from the manpage of urandom:
>
> A  read  from the /dev/urandom device will not block waiting for more entropy.  As a result, if there is not
> sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic
> attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current
> unclassified literature, but  it is theoretically possible that such an attack may exist.  If this is a concern in
> your application, use /dev/random instead.
>
>
> (off topic)
> I would like to see a more consistent usage of cryptographic operations across the board. I guess this is the intention of Oslo. If the usage of PyCryto is not advised at this point in time would it make more sense to use something like PyOpenSSL in Oslo instead?  It looks like it is a backend for Jarret's cryptography module so would be a suitable as a temporary dependency or would that just introduce too much busy work?
>
> So my question is now - Should we raise a bug against the use of
> PyCrypto is it hasn't been audited ?
>
> --
> You received this bug notification because you are a member of OpenStack
> Security Group, which is subscribed to OpenStack.
> https://bugs.launchpad.net/bugs/1267912
>
> Title:
>   OS::Heat::RandomString uses OS entropy source directly
>
> Status in Orchestration API (Heat):
>   Confirmed
>
> Bug description:
>   The RandomString resource documentation[1] suggests that it's useful
>   for generating passwords and secrets. It doesn't mention the security
>   guarantees, however.
>
>   Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
>   something like PyCrypto or better yet, have Oslo provide a
>   cryptographically secure random generator and use that.
>
>   On Linux, random.SystemRandom reads from /dev/urandom which if I
>   understand things correctly, can have its entropy depleted. So a Heat
>   user could use a template that asks for a huge amount of randomness
>   and empty the entropy pool of the entire system (not just Heat).
>
>   This would probably be difficult to exploit, but I think it'd be safer
>   use the entropy to seed a CSPRNG instead of using it directly. Which
>   is exactly what PyCrypto seems to do.
>
>   Regardless, the security guarantees and implications of
>   OS::Heat::RandomString should be documented.
>
>   [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
>   [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1267912

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions



From thierry at openstack.org  Fri Jan 17 08:22:55 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Fri, 17 Jan 2014 09:22:55 +0100
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <52D41349.6010202@redhat.com>
References: <52D41349.6010202@redhat.com>
Message-ID: <52D8E85F.3020700@openstack.org>

Nathan Kinder wrote:
> I have started to put together a wiki page skeleton outlining the
> process to follow when writing a new Security Note (OSSN).  I think it's
> far enough along to share.  Any feedback and suggestions would be
> appreciated!  The new page is available here:
> 
>     https://wiki.openstack.org/wiki/Security/Security_Note_Process

As someone suggested during the meeting yesterday, OSSNs could live in a
git repository and in the future get autopublished under
www.openstack.org (the same way we plan to have the governance documents
autopublished).

An immediate benefit of using a repository is that you could use Gerrit
to comment, approve and iterate on OSSN drafts, which is so much better
that using emails and launchpad bugs. With OSSNs as "living knowledge
base documents" this also lets you propose new versions and corrections
easily.

FWIW even if OSSAs are one-time notifications, we plan to also use
repositories/Gerrit, purely to get decent draft review tooling. But we
need to support private reviews in Gerrit first...

Regards,

-- 
Thierry Carrez (ttx)



From robert.clark at hp.com  Fri Jan 17 12:22:00 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 17 Jan 2014 12:22:00 +0000
Subject: [Openstack-security] Security Note (OSSN) Process
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com> <52D49FAB.2030405@redhat.com>
 <52D50568.8050809@openstack.org>
 <CAD5zmxhEzB=PO_OgMzYW0JKG2fkX7yo8DD6BFk_JuC2b4AgfJw@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A1101ABB37@G4W3300.americas.hpqcorp.net>

On 16/01/2014 11:30, Ahmed Aley wrote:
> Hi,
>
> How about having it like this:
> OSSA-2014-01, OSSA-2014-02, OSSA-2014-03
> OSSN-0114, OSSN-0214, OSSN-0314
>
> This way you keep the relative ordering for both and it is easy to see
> when was what issued with no confusion. I would also suggest adding
> categories to OSSN, e.g, instead of OSSN-0114 have something like
> OSSN-NO-0114 where the extra NO (or GL or something) in the middle
> indicates an acronym for the project (Nova).
>
> --Ahmed
>
> On Tue, Jan 14, 2014 at 10:37 AM, Thierry Carrez <thierry at openstack.org
> <mailto:thierry at openstack.org>> wrote:
>
>     Nathan Kinder wrote:
>      >> One note I would use the same number sequence, e.g.:
>      >
>      >> OSSA-2014-01 OSSA-2014-02 OSSN-2014-03
>      >
>      >> The reason for this: "OSSA-2014-01" vs "OSSN-2014-01" is kind of
>      >> messy, harder to search/etc. Also I would advice using more than 2
>      >> digits (3 should be safe).
>      >
>      > I like it.  That prevents the OSSA/OSSN confusion problem and it also
>      > has the benefit of allowing us to easily compare the publishing date
>      > between an OSSA and OSSN.
>
>     I think it actually increases the confusion, and we'd need to build some
>     central numbering authority to make sure we don't reuse the same
>     number...
>
>     OSSAs (and CVEs) are vulnerabilities, so they are serial events very
>     related to the time of their publication, hence the numbering. OSSNs are
>     more like security best practices: and those are permanent, eternal and
>     their order doesn't matter that much. What you need is a convenient way
>     to uniquely identify them, and then a mechanism to publish updated
>     version of them if need be.
>
>     For example you could use a single serial number with a date-based
>     edition version, like "OSSN 12 (2014-01-20 edition)". That would let you
>     revisit some topics as the software evolves over time.
>
>     (In summary, OSSAs are like a calendar with events, while OSSNs are like
>     a reference book with chapters. You would not number book chapters after
>     the date the chapter was originally written).
>
>     About CVEs: since anybody can request a CVE to be assigned about a
>     specific issue and everyone has a different opinion on what constitues a
>     "vulnerability", there have been a number of issues in the past that had
>     CVE assigned to them and did not trigger an OSSA. They tend to fall into
>     two categories though: CVE assigned by the VMT but not triggering an
>     OSSA, or CVE assigned by some other party (generally a distribution).
>     For that reason I don't think you need to be concerned too much about
>     CVE assignment. To handle the corner case where one is warranted but
>     nobody ever assigned one, you can always ask the VMT or this list
>     for one.
>
>     --
>     Thierry Carrez (ttx)
>
>
>     _______________________________________________
>     Openstack-security mailing list
>     Openstack-security at lists.openstack.org
>     <mailto:Openstack-security at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>

I don't see OSSN's changing over time, they're not really written like 
that. A typical OSSN say's "This affects releases X,Y,Z" If a future 
release was affected I'd expect a new OSSN to be created and a link to 
the old one placed in the references section of the OSSN.

I'm not sure adding in an abbreviated service parameter 'OSSN-NO-0023'is 
worth doing, it makes the whole thing harder to read. We'll maintain a 
directory of OSSNs before long and we can easily have them sortable by 
service. There's also the possibility that in some cases an OSSN will 
cover more than one service, like a combined vulnerability with Nova and 
Glance for example.
-Rob



From ahmeda at cs.umu.se  Fri Jan 17 12:36:46 2014
From: ahmeda at cs.umu.se (Ahmed Aley)
Date: Fri, 17 Jan 2014 13:36:46 +0100
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <A0C170085C37664D93EE1604364858A1101ABB37@G4W3300.americas.hpqcorp.net>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com> <52D49FAB.2030405@redhat.com>
 <52D50568.8050809@openstack.org>
 <CAD5zmxhEzB=PO_OgMzYW0JKG2fkX7yo8DD6BFk_JuC2b4AgfJw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1101ABB37@G4W3300.americas.hpqcorp.net>
Message-ID: <CAD5zmxi6THHVg+N+T9-MoYxoqKxLyp5A9OfL7Zw5gEF92jHv_A@mail.gmail.com>

On Fri, Jan 17, 2014 at 1:22 PM, Clark, Robert Graham
<robert.clark at hp.com>wrote:

> On 16/01/2014 11:30, Ahmed Aley wrote:
> > Hi,
> >
> > How about having it like this:
> > OSSA-2014-01, OSSA-2014-02, OSSA-2014-03
> > OSSN-0114, OSSN-0214, OSSN-0314
> >
> > This way you keep the relative ordering for both and it is easy to see
> > when was what issued with no confusion. I would also suggest adding
> > categories to OSSN, e.g, instead of OSSN-0114 have something like
> > OSSN-NO-0114 where the extra NO (or GL or something) in the middle
> > indicates an acronym for the project (Nova).
> >
> > --Ahmed
> >
> > On Tue, Jan 14, 2014 at 10:37 AM, Thierry Carrez <thierry at openstack.org
> > <mailto:thierry at openstack.org>> wrote:
> >
> >     Nathan Kinder wrote:
> >      >> One note I would use the same number sequence, e.g.:
> >      >
> >      >> OSSA-2014-01 OSSA-2014-02 OSSN-2014-03
> >      >
> >      >> The reason for this: "OSSA-2014-01" vs "OSSN-2014-01" is kind of
> >      >> messy, harder to search/etc. Also I would advice using more than
> 2
> >      >> digits (3 should be safe).
> >      >
> >      > I like it.  That prevents the OSSA/OSSN confusion problem and it
> also
> >      > has the benefit of allowing us to easily compare the publishing
> date
> >      > between an OSSA and OSSN.
> >
> >     I think it actually increases the confusion, and we'd need to build
> some
> >     central numbering authority to make sure we don't reuse the same
> >     number...
> >
> >     OSSAs (and CVEs) are vulnerabilities, so they are serial events very
> >     related to the time of their publication, hence the numbering. OSSNs
> are
> >     more like security best practices: and those are permanent, eternal
> and
> >     their order doesn't matter that much. What you need is a convenient
> way
> >     to uniquely identify them, and then a mechanism to publish updated
> >     version of them if need be.
> >
> >     For example you could use a single serial number with a date-based
> >     edition version, like "OSSN 12 (2014-01-20 edition)". That would let
> you
> >     revisit some topics as the software evolves over time.
> >
> >     (In summary, OSSAs are like a calendar with events, while OSSNs are
> like
> >     a reference book with chapters. You would not number book chapters
> after
> >     the date the chapter was originally written).
> >
> >     About CVEs: since anybody can request a CVE to be assigned about a
> >     specific issue and everyone has a different opinion on what
> constitues a
> >     "vulnerability", there have been a number of issues in the past that
> had
> >     CVE assigned to them and did not trigger an OSSA. They tend to fall
> into
> >     two categories though: CVE assigned by the VMT but not triggering an
> >     OSSA, or CVE assigned by some other party (generally a distribution).
> >     For that reason I don't think you need to be concerned too much about
> >     CVE assignment. To handle the corner case where one is warranted but
> >     nobody ever assigned one, you can always ask the VMT or this list
> >     for one.
> >
> >     --
> >     Thierry Carrez (ttx)
> >
> >
> >     _______________________________________________
> >     Openstack-security mailing list
> >     Openstack-security at lists.openstack.org
> >     <mailto:Openstack-security at lists.openstack.org>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> >
> >
>
> I don't see OSSN's changing over time, they're not really written like
> that. A typical OSSN say's "This affects releases X,Y,Z" If a future
> release was affected I'd expect a new OSSN to be created and a link to
> the old one placed in the references section of the OSSN.
>
> I'm not sure adding in an abbreviated service parameter 'OSSN-NO-0023'is
> worth doing, it makes the whole thing harder to read. We'll maintain a
> directory of OSSNs before long and we can easily have them sortable by
> service. There's also the possibility that in some cases an OSSN will
> cover more than one service, like a combined vulnerability with Nova and
> Glance for example.
> -Rob
>

Makes sense.

--Ahmed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140117/ec11914e/attachment.html>

From gerrit2 at review.openstack.org  Fri Jan 17 13:02:28 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 17 Jan 2014 13:02:28 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I091b1620ab60184921cc12e038af5d717d4d476f
Message-ID: <E1W4948-0005BR-8X@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/65696

Log:
commit 993cff63da50e7bf24f29f62f5372384c0a994e1
Author: Sascha Peilicke <speilicke at suse.com>
Date:   Thu Jan 9 15:14:24 2014 +0100

    Support passing 'neutron_insecure' to neutronclient
    
    When using a self-signed certificate for the network service endpoint,
    the metadata agent has to pass the 'insecure' flag to neutronclient.
    Otherwise requests will fail due to the failed certificate validity
    check.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1269740
    Change-Id: I091b1620ab60184921cc12e038af5d717d4d476f




From gerrit2 at review.openstack.org  Fri Jan 17 13:22:54 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 17 Jan 2014 13:22:54 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W49Nu-00073v-HH@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit 75e7bd555de229ab49f849f28e113f8292758cd6
Author: Jamie Lennox <jamielennox at redhat.com>
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
    Implements: bp key-distribution-server
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Fri Jan 17 13:51:48 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 17 Jan 2014 13:51:48 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I091b1620ab60184921cc12e038af5d717d4d476f
Message-ID: <E1W49ps-00018e-Kx@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/67461

Log:
commit f4d297b7f6b43193ba649d0483c318c0610193ba
Author: Sascha Peilicke <speilicke at suse.com>
Date:   Thu Jan 9 15:14:24 2014 +0100

    Support passing 'neutron_insecure' to neutronclient
    
    When using a self-signed certificate for the network service endpoint,
    the metadata agent has to pass the 'insecure' flag to neutronclient.
    Otherwise requests will fail due to the failed certificate validity
    check.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1269740
    Change-Id: I091b1620ab60184921cc12e038af5d717d4d476f




From bdpayne at acm.org  Fri Jan 17 18:17:50 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Fri, 17 Jan 2014 10:17:50 -0800
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <CAD5zmxi6THHVg+N+T9-MoYxoqKxLyp5A9OfL7Zw5gEF92jHv_A@mail.gmail.com>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com> <52D49FAB.2030405@redhat.com>
 <52D50568.8050809@openstack.org>
 <CAD5zmxhEzB=PO_OgMzYW0JKG2fkX7yo8DD6BFk_JuC2b4AgfJw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1101ABB37@G4W3300.americas.hpqcorp.net>
 <CAD5zmxi6THHVg+N+T9-MoYxoqKxLyp5A9OfL7Zw5gEF92jHv_A@mail.gmail.com>
Message-ID: <CAFpPvXDDJ5=83tBdm1LQpOqXFZ7yqb3y5OzqzoD18bGJvHn0gg@mail.gmail.com>

A couple of thoughts...

* I like the idea of storing these in git.
* Perhaps including a date in the numbering of the OSSN is not needed?
 Could we just number them sequentially?

OSSN-0001
OSSN-0002
etc.

If we use git and number sequentially, then it would be easy to just grab
the next number when writing a new OSSN.  I also really like the idea of
doing the reviews in gerrit rather than launchpad / email.

-bryan



On Fri, Jan 17, 2014 at 4:36 AM, Ahmed Aley <ahmeda at cs.umu.se> wrote:

> On Fri, Jan 17, 2014 at 1:22 PM, Clark, Robert Graham <robert.clark at hp.com
> > wrote:
>
>> On 16/01/2014 11:30, Ahmed Aley wrote:
>> > Hi,
>> >
>> > How about having it like this:
>> > OSSA-2014-01, OSSA-2014-02, OSSA-2014-03
>> > OSSN-0114, OSSN-0214, OSSN-0314
>> >
>> > This way you keep the relative ordering for both and it is easy to see
>> > when was what issued with no confusion. I would also suggest adding
>> > categories to OSSN, e.g, instead of OSSN-0114 have something like
>> > OSSN-NO-0114 where the extra NO (or GL or something) in the middle
>> > indicates an acronym for the project (Nova).
>> >
>> > --Ahmed
>> >
>> > On Tue, Jan 14, 2014 at 10:37 AM, Thierry Carrez <thierry at openstack.org
>> > <mailto:thierry at openstack.org>> wrote:
>> >
>> >     Nathan Kinder wrote:
>> >      >> One note I would use the same number sequence, e.g.:
>> >      >
>> >      >> OSSA-2014-01 OSSA-2014-02 OSSN-2014-03
>> >      >
>> >      >> The reason for this: "OSSA-2014-01" vs "OSSN-2014-01" is kind of
>> >      >> messy, harder to search/etc. Also I would advice using more
>> than 2
>> >      >> digits (3 should be safe).
>> >      >
>> >      > I like it.  That prevents the OSSA/OSSN confusion problem and it
>> also
>> >      > has the benefit of allowing us to easily compare the publishing
>> date
>> >      > between an OSSA and OSSN.
>> >
>> >     I think it actually increases the confusion, and we'd need to build
>> some
>> >     central numbering authority to make sure we don't reuse the same
>> >     number...
>> >
>> >     OSSAs (and CVEs) are vulnerabilities, so they are serial events very
>> >     related to the time of their publication, hence the numbering.
>> OSSNs are
>> >     more like security best practices: and those are permanent, eternal
>> and
>> >     their order doesn't matter that much. What you need is a convenient
>> way
>> >     to uniquely identify them, and then a mechanism to publish updated
>> >     version of them if need be.
>> >
>> >     For example you could use a single serial number with a date-based
>> >     edition version, like "OSSN 12 (2014-01-20 edition)". That would
>> let you
>> >     revisit some topics as the software evolves over time.
>> >
>> >     (In summary, OSSAs are like a calendar with events, while OSSNs are
>> like
>> >     a reference book with chapters. You would not number book chapters
>> after
>> >     the date the chapter was originally written).
>> >
>> >     About CVEs: since anybody can request a CVE to be assigned about a
>> >     specific issue and everyone has a different opinion on what
>> constitues a
>> >     "vulnerability", there have been a number of issues in the past
>> that had
>> >     CVE assigned to them and did not trigger an OSSA. They tend to fall
>> into
>> >     two categories though: CVE assigned by the VMT but not triggering an
>> >     OSSA, or CVE assigned by some other party (generally a
>> distribution).
>> >     For that reason I don't think you need to be concerned too much
>> about
>> >     CVE assignment. To handle the corner case where one is warranted but
>> >     nobody ever assigned one, you can always ask the VMT or this list
>> >     for one.
>> >
>> >     --
>> >     Thierry Carrez (ttx)
>> >
>> >
>> >     _______________________________________________
>> >     Openstack-security mailing list
>> >     Openstack-security at lists.openstack.org
>> >     <mailto:Openstack-security at lists.openstack.org>
>> >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> >
>> >
>>
>> I don't see OSSN's changing over time, they're not really written like
>> that. A typical OSSN say's "This affects releases X,Y,Z" If a future
>> release was affected I'd expect a new OSSN to be created and a link to
>> the old one placed in the references section of the OSSN.
>>
>> I'm not sure adding in an abbreviated service parameter 'OSSN-NO-0023'is
>> worth doing, it makes the whole thing harder to read. We'll maintain a
>> directory of OSSNs before long and we can easily have them sortable by
>> service. There's also the possibility that in some cases an OSSN will
>> cover more than one service, like a combined vulnerability with Nova and
>> Glance for example.
>> -Rob
>>
>
> Makes sense.
>
> --Ahmed
>
> _______________________________________________
> 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: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140117/76b0add5/attachment.html>

From nkinder at redhat.com  Fri Jan 17 19:01:14 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Fri, 17 Jan 2014 19:01:14 -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: <20140117190114.19595.99053.malone@chaenomeles.canonical.com>

Published the following OSSN to the openstack and openstack-dev mailing
lists:

-----------------------------------------------------------------

Keystone can allow user impersonation when using REMOTE_USER for
external authentication
---

### Summary ###
When external authentication is used with Keystone using the
"ExternalDefault" plug-in, external usernames containing "@"
characters are truncated at the "@" character before being mapped to a
local Keystone user. This can result in separate external users
mapping to the same local Keystone user, which could lead to user
impersonation.

### Affected Services / Software ###
Keystone, Havana

### Discussion ###
When Keystone is run in the Apache HTTP Server, the webserver can
handle authentication and pass the authenticated username to Keystone
using the REMOTE_USER environment variable. External authentication
behavior is handled by authentication plugins in Keystone. In the
Havana release of OpenStack, if the external username provided in the
REMOTE_USER environment variable contains an "@" character Keystone
will only use the portion preceding the "@" character as the username
when using the "ExternalDefault" authentication plugin. This results
in the ability for multiple unique external usernames to map to the
same single username in Keystone. For example, the external usernames
"jdoe at example1.com" and "jdoe at example2.com" would both map to the
Keystone user "jdoe". This behavior could potentially be abused to
allow one to impersonate another similarly named external user.

Keystone in OpenStack releases prior to Havana uses the entire value
contained in the REMOTE_USER environment variable, so those versions
are not vulnerable to this impersonation issue.

### Recommended Actions ###
If the "ExternalDefault" plugin is being used for external
authentication in the Havana release, you should ensure that external
usernames do not contain "@" characters unless you want to collapse
similarly named external users into a single user on the Keystone side.

If your external usernames do contain "@" characters and you do not
want to collapse similarly named external users into a single user on
the Keystone side, you might be able to use the "ExternalDomain"
plug-in. This plugin considers the portion of the external username
that follows an "@" character to be the domain that the user belongs
to in Keystone. This allows similarly named external users to map to
separate Keystone users if the portion of the external username that
follows an "@" character maps to a Keystone domain name. To configure
the "ExternalDomain" authentication plugin, set the "external"
parameter in the "[auth]" section of Keystone's keystone.conf as follows:

---- begin example keystone.conf snippet ----
[auth]
methods = external,password,token
external = keystone.auth.plugins.external.ExternalDomain
---- end example keystone.conf snippet ----

If neither of the above recommendations work for your deployment, a
custom authentication plugin can be created that uses the external
username that contains an "@" character as-is.

### Contacts / References ###
This OSSN : https://bugs.launchpad.net/ossn/+bug/1254619
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1254619
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

** Changed in: ossn
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1254619

Title:
  external.Default authentication plugin only considers leftmost part of
  the REMOTE_USER split by "@"

Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack Security Advisories:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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 thierry at openstack.org  Sat Jan 18 13:46:30 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Sat, 18 Jan 2014 14:46:30 +0100
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <CAFpPvXDDJ5=83tBdm1LQpOqXFZ7yqb3y5OzqzoD18bGJvHn0gg@mail.gmail.com>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com> <52D49FAB.2030405@redhat.com>
 <52D50568.8050809@openstack.org>
 <CAD5zmxhEzB=PO_OgMzYW0JKG2fkX7yo8DD6BFk_JuC2b4AgfJw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1101ABB37@G4W3300.americas.hpqcorp.net>
 <CAD5zmxi6THHVg+N+T9-MoYxoqKxLyp5A9OfL7Zw5gEF92jHv_A@mail.gmail.com>
 <CAFpPvXDDJ5=83tBdm1LQpOqXFZ7yqb3y5OzqzoD18bGJvHn0gg@mail.gmail.com>
Message-ID: <52DA85B6.7060908@openstack.org>

Bryan D. Payne wrote:
> A couple of thoughts...
> 
> * I like the idea of storing these in git.
> * Perhaps including a date in the numbering of the OSSN is not needed?
>  Could we just number them sequentially?
> 
> OSSN-0001
> OSSN-0002
> etc.
> 
> If we use git and number sequentially, then it would be easy to just
> grab the next number when writing a new OSSN.  I also really like the
> idea of doing the reviews in gerrit rather than launchpad / email.

+1, nice and simple, and sufficiently different from OSSA numbering so
that they do not get confused.

-- 
Thierry Carrez (ttx)



From robert.clark at hp.com  Sat Jan 18 17:16:02 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Sat, 18 Jan 2014 17:16:02 +0000
Subject: [Openstack-security] Security Note (OSSN) Process
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com> <52D49FAB.2030405@redhat.com>
 <52D50568.8050809@openstack.org>
 <CAD5zmxhEzB=PO_OgMzYW0JKG2fkX7yo8DD6BFk_JuC2b4AgfJw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1101ABB37@G4W3300.americas.hpqcorp.net>
 <CAD5zmxi6THHVg+N+T9-MoYxoqKxLyp5A9OfL7Zw5gEF92jHv_A@mail.gmail.com>
 <CAFpPvXDDJ5=83tBdm1LQpOqXFZ7yqb3y5OzqzoD18bGJvHn0gg@mail.gmail.com>
 <52DA85B6.7060908@openstack.org>
Message-ID: <A0C170085C37664D93EE1604364858A1101AD658@G4W3300.americas.hpqcorp.net>

On Sat Jan 18 13:48:48 2014, Thierry Carrez wrote:
> Bryan D. Payne wrote:
>> A couple of thoughts...
>>
>> * I like the idea of storing these in git.
>> * Perhaps including a date in the numbering of the OSSN is not needed?
>>   Could we just number them sequentially?
>>
>> OSSN-0001
>> OSSN-0002
>> etc.
>>
>> If we use git and number sequentially, then it would be easy to just
>> grab the next number when writing a new OSSN.  I also really like the
>> idea of doing the reviews in gerrit rather than launchpad / email.
>
> +1, nice and simple, and sufficiently different from OSSA numbering so
> that they do not get confused.
>

+1 I'm happy with all of the above



From 1240382 at bugs.launchpad.net  Sat Jan 18 22:42:11 2014
From: 1240382 at bugs.launchpad.net (OpenStack Infra)
Date: Sat, 18 Jan 2014 22:42:11 -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: <20140118224211.30916.11540.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/64427
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=bed88a2e724f5f23a1c839b7872b1bc56f059df5
Submitter: Jenkins
Branch:    master

commit bed88a2e724f5f23a1c839b7872b1bc56f059df5
Author: Matthieu Huin <mhu at enovance.com>
Date:   Mon Dec 2 10:43:10 2013 +0100

    Replacing python-oauth2 by oauthlib
    
    This patch replaces the old, unmaintained python-oauth2 library
    by the better suited oauthlib in keystone oAuth modules.
    
    The library switch comes with two notable changes in terms of use:
    
    * the client must set the callback uri to 'oob' (out-of-band)
      explicitly when requesting a Request Token
    * the requested_project_id header is not included in the signature
      anymore, in compliance with the oAuth1 spec.
    
    Closes-Bug: 1240382
    Change-Id: Ie553830cc80075aa818e719604e6bc4c754d2ae3


** Changed in: keystone
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1240382

Title:
  python-oauth2 dependency is unmaintained and has security issues

Status in OpenStack Identity (Keystone):
  Fix Committed

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 nkinder at redhat.com  Sun Jan 19 03:38:24 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Sat, 18 Jan 2014 19:38:24 -0800
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <A0C170085C37664D93EE1604364858A1101AD658@G4W3300.americas.hpqcorp.net>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com> <52D49FAB.2030405@redhat.com>
 <52D50568.8050809@openstack.org>
 <CAD5zmxhEzB=PO_OgMzYW0JKG2fkX7yo8DD6BFk_JuC2b4AgfJw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1101ABB37@G4W3300.americas.hpqcorp.net>
 <CAD5zmxi6THHVg+N+T9-MoYxoqKxLyp5A9OfL7Zw5gEF92jHv_A@mail.gmail.com>
 <CAFpPvXDDJ5=83tBdm1LQpOqXFZ7yqb3y5OzqzoD18bGJvHn0gg@mail.gmail.com>
 <52DA85B6.7060908@openstack.org>
 <A0C170085C37664D93EE1604364858A1101AD658@G4W3300.americas.hpqcorp.net>
Message-ID: <52DB48B0.7080207@redhat.com>

On 01/18/2014 09:16 AM, Clark, Robert Graham wrote:
> On Sat Jan 18 13:48:48 2014, Thierry Carrez wrote:
>> Bryan D. Payne wrote:
>>> A couple of thoughts...
>>>
>>> * I like the idea of storing these in git.
>>> * Perhaps including a date in the numbering of the OSSN is not needed?
>>>   Could we just number them sequentially?
>>>
>>> OSSN-0001
>>> OSSN-0002
>>> etc.
>>>
>>> If we use git and number sequentially, then it would be easy to just
>>> grab the next number when writing a new OSSN.  I also really like the
>>> idea of doing the reviews in gerrit rather than launchpad / email.
>>
>> +1, nice and simple, and sufficiently different from OSSA numbering so
>> that they do not get confused.
>>
> 
> +1 I'm happy with all of the above

I'm happy with this approach as well.  I'll update the process wiki page
with the numbering approach.  Since we only have a handful of already
published OSSNs, I'm going to propose that we retroactively number the
existing OSSNs in the wiki publishing area based on the publishing date.

I will also look at moving to git/gerrit.

Thanks,
-NGK

> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 




From 1240382 at bugs.launchpad.net  Sun Jan 19 04:57:27 2014
From: 1240382 at bugs.launchpad.net (Dolph Mathews)
Date: Sun, 19 Jan 2014 04:57:27 -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: <20140119045728.19307.78029.launchpad@chaenomeles.canonical.com>

** Changed in: keystone
     Assignee: Dolph Mathews (dolph) => Matthieu Huin (mhu-s)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1240382

Title:
  python-oauth2 dependency is unmaintained and has security issues

Status in OpenStack Identity (Keystone):
  Fix Committed

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 fw at deneb.enyo.de  Sun Jan 19 19:23:50 2014
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 19 Jan 2014 20:23:50 +0100
Subject: [Openstack-security] instance-data sinkholing
In-Reply-To: <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
 (Bryan D. Payne's message of "Thu, 2 Jan 2014 09:39:33 -0800")
References: <871u0q4771.fsf@mid.deneb.enyo.de>
 <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
Message-ID: <87iotfzsft.fsf@mid.deneb.enyo.de>

* Bryan D. Payne:

> Interesting.  Sounds like a useful thing to continue.  We should find
> someone that can pick up this effort.  Anyone out there able to help with
> this?

Ping?

> Also, I think that this could be a useful topic for an OSSN (a security
> note that will help guide people towards better configuration practices for
> their cloud).  Rob et al... you agree?

A relevant cloud-init bug is here:

<https://bugs.launchpad.net/cloud-init/+bug/1040200>



From bdpayne at acm.org  Sun Jan 19 22:42:40 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Sun, 19 Jan 2014 14:42:40 -0800
Subject: [Openstack-security] instance-data sinkholing
In-Reply-To: <87iotfzsft.fsf@mid.deneb.enyo.de>
References: <871u0q4771.fsf@mid.deneb.enyo.de>
 <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
 <87iotfzsft.fsf@mid.deneb.enyo.de>
Message-ID: <CAFpPvXDWc0dnA0k7jyNvsD==LL=3iTCdzpXAa2g9SWs2oB0-wA@mail.gmail.com>

Thierry,


> > Interesting.  Sounds like a useful thing to continue.  We should find
> > someone that can pick up this effort.  Anyone out there able to help with
> > this?
>
> Ping?
>

Did the foundation decide to pick this up?

-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140119/34239840/attachment.html>

From gerrit2 at review.openstack.org  Mon Jan 20 01:08:19 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 20 Jan 2014 01:08:19 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W53Lf-0002KV-V9@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit de0b689eb784b2bc02d506cde37126f62f81c084
Author: Jamie Lennox <jamielennox at redhat.com>
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
    Implements: bp key-distribution-server
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Mon Jan 20 01:08:26 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 20 Jan 2014 01:08:26 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1W53Lm-0002LE-5p@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59604

Log:
commit 42cb93725d8b545622774158004f742fb835805a
Author: Jamie Lennox <jamielennox at redhat.com>
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 robert.clark at hp.com  Mon Jan 20 08:40:42 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 20 Jan 2014 08:40:42 +0000
Subject: [Openstack-security] instance-data sinkholing
References: <871u0q4771.fsf@mid.deneb.enyo.de>
 <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
 <87iotfzsft.fsf@mid.deneb.enyo.de>
 <CAFpPvXDWc0dnA0k7jyNvsD==LL=3iTCdzpXAa2g9SWs2oB0-wA@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A1101AF493@G4W3300.americas.hpqcorp.net>

On Sun Jan 19 22:44:52 2014, Bryan D. Payne wrote:
> Thierry,
>
>     > Interesting.  Sounds like a useful thing to continue.  We should
>     find
>     > someone that can pick up this effort.  Anyone out there able to
>     help with
>     > this?
>
>     Ping?
>
>
> Did the foundation decide to pick this up?
>
> -bryan
>

Only just found this thread. I too think this is interesting, probably 
worth an OSSN too.



From berrange at redhat.com  Mon Jan 20 10:53:29 2014
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 20 Jan 2014 10:53:29 +0000
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <CAFpPvXDDJ5=83tBdm1LQpOqXFZ7yqb3y5OzqzoD18bGJvHn0gg@mail.gmail.com>
References: <52D41349.6010202@redhat.com> <1389659250.31175.8.camel@lappy>
 <52D49D62.7060503@redhat.com> <52D49FAB.2030405@redhat.com>
 <52D50568.8050809@openstack.org>
 <CAD5zmxhEzB=PO_OgMzYW0JKG2fkX7yo8DD6BFk_JuC2b4AgfJw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1101ABB37@G4W3300.americas.hpqcorp.net>
 <CAD5zmxi6THHVg+N+T9-MoYxoqKxLyp5A9OfL7Zw5gEF92jHv_A@mail.gmail.com>
 <CAFpPvXDDJ5=83tBdm1LQpOqXFZ7yqb3y5OzqzoD18bGJvHn0gg@mail.gmail.com>
Message-ID: <20140120105329.GA6614@redhat.com>

On Fri, Jan 17, 2014 at 10:17:50AM -0800, Bryan D. Payne wrote:
> A couple of thoughts...
> 
> * I like the idea of storing these in git.
> * Perhaps including a date in the numbering of the OSSN is not needed?
>  Could we just number them sequentially?
> 
> OSSN-0001
> OSSN-0002
> etc.
> 
> If we use git and number sequentially, then it would be easy to just grab
> the next number when writing a new OSSN.  I also really like the idea of
> doing the reviews in gerrit rather than launchpad / email.

NB if the OSSN being created is for a non-public security issue then
you really don't want this going anywhere near a public gerrit review
or git repository. There's just too much risk of exposing sensitive
data that way.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



From berrange at redhat.com  Mon Jan 20 11:31:35 2014
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 20 Jan 2014 11:31:35 +0000
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <52D41349.6010202@redhat.com>
References: <52D41349.6010202@redhat.com>
Message-ID: <20140120113135.GB6614@redhat.com>

On Mon, Jan 13, 2014 at 08:24:41AM -0800, Nathan Kinder wrote:
> Hi,
> 
> I have started to put together a wiki page skeleton outlining the
> process to follow when writing a new Security Note (OSSN).  I think it's
> far enough along to share.  Any feedback and suggestions would be
> appreciated!  The new page is available here:
> 
>     https://wiki.openstack.org/wiki/Security/Security_Note_Process

I think it is good that you're taking steps to formalize the security
reporting process for OpenStack. Having just done the same for libvirt
I've got a few suggestions about the data format for recording this.

The wiki describes using the email text format as the master data
format for the OSSN, which I think is a mistake. For libvirt we
identified that we need to have ability to report in at least 4
different data formats - text, html, native libvirt xml and cvrf
xml, with potentially more in the future if the security industry
decides cvrf is no longer their best fit.

To make it easy to produce data in multiple formats we decided that
it was better to have a simple XML format as the master data format
for our vulnerability reports. It is was then a simple matter of
applying an XSL transform to generate the text / html / cvrf formats
from that.

An example of the master data format for a LSN is this:

  http://security.libvirt.org/2014/0002.xml

And corresponding auto-generated HTML + Text docs

  http://security.libvirt.org/2014/0002.txt
  http://security.libvirt.org/2014/0002.html

The use of XML also lets us generate an index page of all flaws

  http://security.libvirt.org/index.html
  http://security.libvirt.org/index.xml

Note that the website has clear, stable URLs for issues. We've
not actually done the CVRF conversion yet, but will do in the
not too distant future. In addition we're also planning to
add URL shortcuts for CVE numbers eg so you can visit a link
http://security.libvirt.org/CVE-2014-242.html and get redirected
the corresponding LSN URL. 

On the specifics of the data to be recorded, I think the template
in the wiki is missing a couple of pieces of important metadata.
You should record key dates about the issue including when it
was reported, when it was fixed and when it was made public. Note
that those dates can be in any order wrt each other - you don't
always get things in a tidy reported < fixed < public order. It
is also good to credit the person(s) who reported the flaw and
who fixed  the flaw to give recognition of their important
contribution to the project since they may be outsiders.

The affected services really should record detailed specifics of
where the flaw was introduced and fixed in GIT for each affected
GIT repository. You'd want this right down to the changesets and
release tags for both cases. We've found this is important data
to assist us in ensuring we identify what branches are vulnerable
and what should be backported. In writing up our historical list
of vulneribilities this highlighted a nbumber of mistakes made in
backporting fixes to older branches.

During initial handling of the vulnerability these docs are just
discussed over email. Only once the vulnerability is public do
they get added to a GIT repository, and announcements sent out
to public mailing list, etc. The website is auto-generated from
the GIT repository once an hour. I'd be wary of storing OSSNs in
the wiki since people who view the pages would have a pretty low
level of trust in the data, unless the pages were edit-restricted
to solely members of the security team. Having a website whose
content is auto-updated from GIT by a cron job gives you a high
level of trust in the data since you know any changes to the website
must have corresponding changes in the GIT repo, as no human manual
steps were involved.

FYI if OpenStack wants to re-use/adapt any of the scripts/templates
we use for libvirt, then Red Hat is fine relicensing them from GPLv2+
to the ASL-2.0 used by OpenStack projects. If the XML format described
is suitable then you'd mostly just need to change the CSS styling to
apply OpenStack branding to the HTML

  http://libvirt.org/git/?p=libvirt-security-notice.git;a=summary

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



From robert.clark at hp.com  Mon Jan 20 16:37:55 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 20 Jan 2014 16:37:55 +0000
Subject: [Openstack-security] Security Note (OSSN) Process
References: <52D41349.6010202@redhat.com> <20140120113135.GB6614@redhat.com>
Message-ID: <A0C170085C37664D93EE1604364858A1101AFBDF@G4W3300.americas.hpqcorp.net>

On Mon Jan 20 11:47:32 2014, Daniel P. Berrange wrote:
> On Mon, Jan 13, 2014 at 08:24:41AM -0800, Nathan Kinder wrote:
>> Hi,
>>
>> I have started to put together a wiki page skeleton outlining the
>> process to follow when writing a new Security Note (OSSN).  I think it's
>> far enough along to share.  Any feedback and suggestions would be
>> appreciated!  The new page is available here:
>>
>>      https://wiki.openstack.org/wiki/Security/Security_Note_Process
>
> I think it is good that you're taking steps to formalize the security
> reporting process for OpenStack. Having just done the same for libvirt
> I've got a few suggestions about the data format for recording this.
>
> The wiki describes using the email text format as the master data
> format for the OSSN, which I think is a mistake. For libvirt we
> identified that we need to have ability to report in at least 4
> different data formats - text, html, native libvirt xml and cvrf
> xml, with potentially more in the future if the security industry
> decides cvrf is no longer their best fit.
>
> To make it easy to produce data in multiple formats we decided that
> it was better to have a simple XML format as the master data format
> for our vulnerability reports. It is was then a simple matter of
> applying an XSL transform to generate the text / html / cvrf formats
> from that.
>
> An example of the master data format for a LSN is this:
>
>    http://security.libvirt.org/2014/0002.xml
>
> And corresponding auto-generated HTML + Text docs
>
>    http://security.libvirt.org/2014/0002.txt
>    http://security.libvirt.org/2014/0002.html
>
> The use of XML also lets us generate an index page of all flaws
>
>    http://security.libvirt.org/index.html
>    http://security.libvirt.org/index.xml
>
> Note that the website has clear, stable URLs for issues. We've
> not actually done the CVRF conversion yet, but will do in the
> not too distant future. In addition we're also planning to
> add URL shortcuts for CVE numbers eg so you can visit a link
> http://security.libvirt.org/CVE-2014-242.html and get redirected
> the corresponding LSN URL.
>
> On the specifics of the data to be recorded, I think the template
> in the wiki is missing a couple of pieces of important metadata.
> You should record key dates about the issue including when it
> was reported, when it was fixed and when it was made public. Note
> that those dates can be in any order wrt each other - you don't
> always get things in a tidy reported < fixed < public order. It
> is also good to credit the person(s) who reported the flaw and
> who fixed  the flaw to give recognition of their important
> contribution to the project since they may be outsiders.
>
> The affected services really should record detailed specifics of
> where the flaw was introduced and fixed in GIT for each affected
> GIT repository. You'd want this right down to the changesets and
> release tags for both cases. We've found this is important data
> to assist us in ensuring we identify what branches are vulnerable
> and what should be backported. In writing up our historical list
> of vulneribilities this highlighted a nbumber of mistakes made in
> backporting fixes to older branches.
>
> During initial handling of the vulnerability these docs are just
> discussed over email. Only once the vulnerability is public do
> they get added to a GIT repository, and announcements sent out
> to public mailing list, etc. The website is auto-generated from
> the GIT repository once an hour. I'd be wary of storing OSSNs in
> the wiki since people who view the pages would have a pretty low
> level of trust in the data, unless the pages were edit-restricted
> to solely members of the security team. Having a website whose
> content is auto-updated from GIT by a cron job gives you a high
> level of trust in the data since you know any changes to the website
> must have corresponding changes in the GIT repo, as no human manual
> steps were involved.
>
> FYI if OpenStack wants to re-use/adapt any of the scripts/templates
> we use for libvirt, then Red Hat is fine relicensing them from GPLv2+
> to the ASL-2.0 used by OpenStack projects. If the XML format described
> is suitable then you'd mostly just need to change the CSS styling to
> apply OpenStack branding to the HTML
>
>    http://libvirt.org/git/?p=libvirt-security-notice.git;a=summary
>
> Daniel

Thanks Daniel, I think you raise some good points but perhaps you are 
blurring the lines between security notes (OSSN) and security 
advisories (OSSA) a little too much.  It's worth keeping in mind that 
we are not talking about how OpenStack handles security advisories, we 
are talking about OpenStack Security Notes that provide guidance around 
configuration and software choices that have potential security impact 
to OpenStack deployments.

( fwiw I think that OSSAs probably should be published in CVRF 1.1 )

In many cases we wont have metadata such as  'reported date,' a 'fix 
commit', or even a 'broken in' date. Often we are not talking about 
specific defects but potential bad combinations of software, bad 
configurations (user end) etc. In fact we are almost never referring 
directly to a vulnerability in the OpenStack framework with an OSSN.

We don't have the same downstream consumers of OSSNs that libvirt LSNs 
or for that matter, that OpenStack OSSA's have. We don't necessarily 
need a format that's easily machine read - OSSNs are usually very 
subjective and require the reader to make an evaluation on the impact 
to their deployment. (I suppose I can see an opportunity for some 
future project that makes use of OSSNs as part of an automated 
checklist for an OpenStack deployment, but OSSNs are so broad that 
almost every one would be liable to generate false positives.) I'm not 
completely against having a machine readable format that can be parsed 
out into various languages but I think it might be a bit over-the-top 
for what our requirements are.

Your offer to relicense the scripts etc that are used by the libvirt 
project is greatly appreciated, having tooling available significantly 
lowers the bar in terms of adopting it, I think perhaps this is 
something that we should consider discussing at the weekly security 
meeting.

Cheers
-Rob



From berrange at redhat.com  Mon Jan 20 16:45:31 2014
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 20 Jan 2014 16:45:31 +0000
Subject: [Openstack-security] Security Note (OSSN) Process
In-Reply-To: <A0C170085C37664D93EE1604364858A1101AFBDF@G4W3300.americas.hpqcorp.net>
References: <52D41349.6010202@redhat.com> <20140120113135.GB6614@redhat.com>
 <A0C170085C37664D93EE1604364858A1101AFBDF@G4W3300.americas.hpqcorp.net>
Message-ID: <20140120164531.GJ6614@redhat.com>

On Mon, Jan 20, 2014 at 04:37:55PM +0000, Clark, Robert Graham wrote:
> 
> Thanks Daniel, I think you raise some good points but perhaps you are 
> blurring the lines between security notes (OSSN) and security 
> advisories (OSSA) a little too much.  It's worth keeping in mind that 
> we are not talking about how OpenStack handles security advisories, we 
> are talking about OpenStack Security Notes that provide guidance around 
> configuration and software choices that have potential security impact 
> to OpenStack deployments.
> 
> ( fwiw I think that OSSAs probably should be published in CVRF 1.1 )
> 
> In many cases we wont have metadata such as  'reported date,' a 'fix 
> commit', or even a 'broken in' date. Often we are not talking about 
> specific defects but potential bad combinations of software, bad 
> configurations (user end) etc. In fact we are almost never referring 
> directly to a vulnerability in the OpenStack framework with an OSSN.
> 
> We don't have the same downstream consumers of OSSNs that libvirt LSNs 
> or for that matter, that OpenStack OSSA's have. We don't necessarily 
> need a format that's easily machine read - OSSNs are usually very 
> subjective and require the reader to make an evaluation on the impact 
> to their deployment. (I suppose I can see an opportunity for some 
> future project that makes use of OSSNs as part of an automated 
> checklist for an OpenStack deployment, but OSSNs are so broad that 
> almost every one would be liable to generate false positives.) I'm not 
> completely against having a machine readable format that can be parsed 
> out into various languages but I think it might be a bit over-the-top 
> for what our requirements are.
> 
> Your offer to relicense the scripts etc that are used by the libvirt 
> project is greatly appreciated, having tooling available significantly 
> lowers the bar in terms of adopting it, I think perhaps this is 
> something that we should consider discussing at the weekly security 
> meeting.

Doh, I was in fact mixing up OSSNs and OSSAs. As you say, OSSNs obviously
don't require the same level of detail for metadata. I do wonder, however,
if there is some value is using related data formats for both ? eg perhaps
an OSSN could use the same core schema as OSSAs, but with a number of the
metadata pieces omitted, so similar tools could deal with both types of
document more easily ?

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



From robert.clark at hp.com  Mon Jan 20 17:18:47 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 20 Jan 2014 17:18:47 +0000
Subject: [Openstack-security] Security Note (OSSN) Process
References: <52D41349.6010202@redhat.com> <20140120113135.GB6614@redhat.com>
 <A0C170085C37664D93EE1604364858A1101AFBDF@G4W3300.americas.hpqcorp.net>
 <20140120164531.GJ6614@redhat.com>
Message-ID: <A0C170085C37664D93EE1604364858A1101AFC8E@G4W3300.americas.hpqcorp.net>

On Mon Jan 20 16:45:38 2014, Daniel P. Berrange wrote:
> On Mon, Jan 20, 2014 at 04:37:55PM +0000, Clark, Robert Graham wrote:
>>
>> Thanks Daniel, I think you raise some good points but perhaps you are
>> blurring the lines between security notes (OSSN) and security
>> advisories (OSSA) a little too much.  It's worth keeping in mind that
>> we are not talking about how OpenStack handles security advisories, we
>> are talking about OpenStack Security Notes that provide guidance around
>> configuration and software choices that have potential security impact
>> to OpenStack deployments.
>>
>> ( fwiw I think that OSSAs probably should be published in CVRF 1.1 )
>>
>> In many cases we wont have metadata such as  'reported date,' a 'fix
>> commit', or even a 'broken in' date. Often we are not talking about
>> specific defects but potential bad combinations of software, bad
>> configurations (user end) etc. In fact we are almost never referring
>> directly to a vulnerability in the OpenStack framework with an OSSN.
>>
>> We don't have the same downstream consumers of OSSNs that libvirt LSNs
>> or for that matter, that OpenStack OSSA's have. We don't necessarily
>> need a format that's easily machine read - OSSNs are usually very
>> subjective and require the reader to make an evaluation on the impact
>> to their deployment. (I suppose I can see an opportunity for some
>> future project that makes use of OSSNs as part of an automated
>> checklist for an OpenStack deployment, but OSSNs are so broad that
>> almost every one would be liable to generate false positives.) I'm not
>> completely against having a machine readable format that can be parsed
>> out into various languages but I think it might be a bit over-the-top
>> for what our requirements are.
>>
>> Your offer to relicense the scripts etc that are used by the libvirt
>> project is greatly appreciated, having tooling available significantly
>> lowers the bar in terms of adopting it, I think perhaps this is
>> something that we should consider discussing at the weekly security
>> meeting.
>
> Doh, I was in fact mixing up OSSNs and OSSAs. As you say, OSSNs obviously
> don't require the same level of detail for metadata. I do wonder, however,
> if there is some value is using related data formats for both ? eg perhaps
> an OSSN could use the same core schema as OSSAs, but with a number of the
> metadata pieces omitted, so similar tools could deal with both types of
> document more easily ?
>
> Daniel

I'd be open to that at some point in the future but as we currently 
don't have anything like this in place for OSSA's there's nothing for 
us to align with :-s

Definitely worth considering in the future.




From 1240382 at bugs.launchpad.net  Mon Jan 20 19:36:57 2014
From: 1240382 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Mon, 20 Jan 2014 19:36: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: <20140120193659.27817.26037.launchpad@ackee.canonical.com>

** Branch linked: lp:~ubuntu-server-dev/keystone/icehouse

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1240382

Title:
  python-oauth2 dependency is unmaintained and has security issues

Status in OpenStack Identity (Keystone):
  Fix Committed

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 jarret.raim at RACKSPACE.COM  Tue Jan 21 03:39:02 2014
From: jarret.raim at RACKSPACE.COM (Jarret Raim)
Date: Tue, 21 Jan 2014 03:39:02 +0000
Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString
 uses	OS entropy source	directly
In-Reply-To: <20140116233455.19628.37938.malone@chaenomeles.canonical.com>
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140116233455.19628.37938.malone@chaenomeles.canonical.com>
Message-ID: <6824C20A6CE7A44A939B31B7084E5596226224CA@ORD1EXD03.RACKSPACE.CORP>

> -----Original Message-----
> From: Grant Murphy [mailto:gmurphy at redhat.com]
> Sent: Thursday, January 16, 2014 5:35 PM
> To: openstack-security at lists.openstack.org
> Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString
> uses OS entropy source directly
>
> (off topic)
> I would like to see a more consistent usage of cryptographic operations
> across the board. I guess this is the intention of Oslo. If the usage of
PyCryto
> is not advised at this point in time would it make more sense to use
> something like PyOpenSSL in Oslo instead?  It looks like it is a backend
for
> Jarret's cryptography module so would be a suitable as a temporary
> dependency or would that just introduce too much busy work?

The PyOpenSSL author is working with the cryptography team and has a branch
of PyOpenSSL based on cryptography. It's an alpha, but it will be the way
forward. I would like to see cryptography added to OpenStack at some point,
but I think we still have some work to do before we get there. In the
meantime, I would just leave it alone until we have a suitable replacement
in cryptography.

Paul Kehrer and I will be talking about these issues in April at Pycon. It
might be worth seeing where we are at that point and talking through the
options at the Summit in May. Assuming the code is ready, we could start the
process of creating / updating oslo.crypto and starting the process of teams
moving to use cryptography. This would allow the deployed to choose which
codebase they wanted. We currently have backends for openssl, common-crypto
for mac and gcrypt. We are looking into NSS and pycrypto as well.

> So my question is now - Should we raise a bug against the use of PyCrypto
is
> it hasn't been audited ?

There wouldn't be much an open source tool could do to solve that one. An
audit would require a significant sponsor. Depending on the desired audit
regime (e.g. if you want FIPS or the like) you could be talking anywhere
from 50k to several hundred thousand.


Jarret


> You received this bug notification because you are a member of OpenStack
> Security Group, which is subscribed to OpenStack.
> https://bugs.launchpad.net/bugs/1267912
> 
> Title:
>   OS::Heat::RandomString uses OS entropy source directly
> 
> Status in Orchestration API (Heat):
>   Confirmed
> 
> Bug description:
>   The RandomString resource documentation[1] suggests that it's useful
>   for generating passwords and secrets. It doesn't mention the security
>   guarantees, however.
> 
>   Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
>   something like PyCrypto or better yet, have Oslo provide a
>   cryptographically secure random generator and use that.
> 
>   On Linux, random.SystemRandom reads from /dev/urandom which if I
>   understand things correctly, can have its entropy depleted. So a Heat
>   user could use a template that asks for a huge amount of randomness
>   and empty the entropy pool of the entire system (not just Heat).
> 
>   This would probably be difficult to exploit, but I think it'd be safer
>   use the entropy to seed a CSPRNG instead of using it directly. Which
>   is exactly what PyCrypto seems to do.
> 
>   Regardless, the security guarantees and implications of
>   OS::Heat::RandomString should be documented.
> 
>   [1]:
> http://docs.openstack.org/developer/heat/template_guide/openstack.html
> #OS::Heat::RandomString
>   [2]:
> https://github.com/openstack/heat/blob/master/heat/engine/resources/ra
> ndom_string.py#L81
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6087 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140121/880038b6/attachment.bin>

From 1267912 at bugs.launchpad.net  Tue Jan 21 03:39:02 2014
From: 1267912 at bugs.launchpad.net (Jarret Raim)
Date: Tue, 21 Jan 2014 03:39:02 -0000
Subject: [Openstack-security] [Bug 1267912] Re:
	OS::Heat::RandomString	uses	OS entropy source	directly
References: <20140110154958.26015.12359.malonedeb@gac.canonical.com>
 <20140116233455.19628.37938.malone@chaenomeles.canonical.com>
Message-ID: <6824C20A6CE7A44A939B31B7084E5596226224CA@ORD1EXD03.RACKSPACE.CORP>

> -----Original Message-----
> From: Grant Murphy [mailto:gmurphy at redhat.com]
> Sent: Thursday, January 16, 2014 5:35 PM
> To: openstack-security at lists.openstack.org
> Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString
> uses OS entropy source directly
>
> (off topic)
> I would like to see a more consistent usage of cryptographic operations
> across the board. I guess this is the intention of Oslo. If the usage of
PyCryto
> is not advised at this point in time would it make more sense to use
> something like PyOpenSSL in Oslo instead?  It looks like it is a backend
for
> Jarret's cryptography module so would be a suitable as a temporary
> dependency or would that just introduce too much busy work?

The PyOpenSSL author is working with the cryptography team and has a branch
of PyOpenSSL based on cryptography. It's an alpha, but it will be the way
forward. I would like to see cryptography added to OpenStack at some point,
but I think we still have some work to do before we get there. In the
meantime, I would just leave it alone until we have a suitable replacement
in cryptography.

Paul Kehrer and I will be talking about these issues in April at Pycon. It
might be worth seeing where we are at that point and talking through the
options at the Summit in May. Assuming the code is ready, we could start the
process of creating / updating oslo.crypto and starting the process of teams
moving to use cryptography. This would allow the deployed to choose which
codebase they wanted. We currently have backends for openssl, common-crypto
for mac and gcrypt. We are looking into NSS and pycrypto as well.

> So my question is now - Should we raise a bug against the use of PyCrypto
is
> it hasn't been audited ?

There wouldn't be much an open source tool could do to solve that one. An
audit would require a significant sponsor. Depending on the desired audit
regime (e.g. if you want FIPS or the like) you could be talking anywhere
from 50k to several hundred thousand.


Jarret


> You received this bug notification because you are a member of OpenStack
> Security Group, which is subscribed to OpenStack.
> https://bugs.launchpad.net/bugs/1267912
> 
> Title:
>   OS::Heat::RandomString uses OS entropy source directly
> 
> Status in Orchestration API (Heat):
>   Confirmed
> 
> Bug description:
>   The RandomString resource documentation[1] suggests that it's useful
>   for generating passwords and secrets. It doesn't mention the security
>   guarantees, however.
> 
>   Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
>   something like PyCrypto or better yet, have Oslo provide a
>   cryptographically secure random generator and use that.
> 
>   On Linux, random.SystemRandom reads from /dev/urandom which if I
>   understand things correctly, can have its entropy depleted. So a Heat
>   user could use a template that asks for a huge amount of randomness
>   and empty the entropy pool of the entire system (not just Heat).
> 
>   This would probably be difficult to exploit, but I think it'd be safer
>   use the entropy to seed a CSPRNG instead of using it directly. Which
>   is exactly what PyCrypto seems to do.
> 
>   Regardless, the security guarantees and implications of
>   OS::Heat::RandomString should be documented.
> 
>   [1]:
> http://docs.openstack.org/developer/heat/template_guide/openstack.html
> #OS::Heat::RandomString
>   [2]:
> https://github.com/openstack/heat/blob/master/heat/engine/resources/ra
> ndom_string.py#L81
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/heat/+bug/1267912/+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/1267912

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions



From gerrit2 at review.openstack.org  Tue Jan 21 05:46:35 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 21 Jan 2014 05:46:35 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W5UAV-0000oG-V2@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit 622e6d5f5625d5bc378aaf6b8a1e9f299b063ac9
Author: Jamie Lennox <jamielennox at redhat.com>
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
    Implements: bp key-distribution-server
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Tue Jan 21 05:46:46 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 21 Jan 2014 05:46:46 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1W5UAg-0000qI-Cj@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59604

Log:
commit 1f10c46823b39a03b38fc3b79628e6b736b91eab
Author: Jamie Lennox <jamielennox at redhat.com>
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  Tue Jan 21 08:36:40 2014
From: 1251647 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 21 Jan 2014 08:36:40 -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: <20140121083640.32503.61483.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/59685
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=e313efce5160ec48b0d7b292dbfea4b2311ebcd3
Submitter: Jenkins
Branch:    master

commit e313efce5160ec48b0d7b292dbfea4b2311ebcd3
Author: Angus Salkeld <angus.salkeld at rackspace.com>
Date:   Wed Jan 15 12:31:58 2014 +1000

    Use oslo crypto
    
    Use olso crypto as the new encryption solution.
    
    Change-Id: I80b76dc5acef5362c49c437bdefdf88f08983fc4
    Closes-bug: #1251647


** Changed in: heat
       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/1251647

Title:
  Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason

Status in Orchestration API (Heat):
  Fix Committed
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 thierry at openstack.org  Tue Jan 21 18:50:39 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Tue, 21 Jan 2014 11:50:39 -0700
Subject: [Openstack-security] instance-data sinkholing
In-Reply-To: <CAFpPvXDWc0dnA0k7jyNvsD==LL=3iTCdzpXAa2g9SWs2oB0-wA@mail.gmail.com>
References: <871u0q4771.fsf@mid.deneb.enyo.de>
 <CAFpPvXDTcA=ZUcV8CNKi4ELJFJEi7au0zfAYwvFVD_AsnmDkZA@mail.gmail.com>
 <87iotfzsft.fsf@mid.deneb.enyo.de>
 <CAFpPvXDWc0dnA0k7jyNvsD==LL=3iTCdzpXAa2g9SWs2oB0-wA@mail.gmail.com>
Message-ID: <52DEC17F.3050801@openstack.org>

Bryan D. Payne wrote:
> Did the foundation decide to pick this up?

I'd like the infra guys opinion on it but they have been a bit busy
those days. Will push that to them as soon as we are out of the critical
area.

-- 
Thierry Carrez (ttx)



From devoid at anl.gov  Wed Jan 22 01:18:16 2014
From: devoid at anl.gov (Scott Devoid)
Date: Wed, 22 Jan 2014 01:18:16 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Possible to get and update
	quotas for nonexistant	tenant
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140122011820.30807.80032.launchpad@soybean.canonical.com>

** Changed in: nova
       Status: Opinion => 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/1118066

Title:
  Possible to get and update quotas for nonexistant tenant

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From devoid at anl.gov  Wed Jan 22 01:25:17 2014
From: devoid at anl.gov (Scott Devoid)
Date: Wed, 22 Jan 2014 01:25:17 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Possible to get and update
	quotas for nonexistant	tenant
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140122012517.19307.53642.malone@chaenomeles.canonical.com>

"And as an admin (trusted user), we expect them to not break things."

Sorry, I am going to have to disagree with you on this. The interface
gives no indication that the request failed to produce the desired
effect. Add to that several facts:  many quota-exceeded errors are
masked by other quota exceeded error names and end users will report
quota exceeded errors as "my instance failed to start". These all add up
to a bad user experience.

"This is part of a bigger issue, which is nova doesn't have great RBAC
support. Say you want to create a tenant admin who can set quotas per
user."

I don't see how role-based access control is necessary when a simple
check "does this string correspond to a real project UUID (or name if
you want to support that)" would suffice.

Marking as open for these reasons.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Possible to get and update quotas for nonexistant tenant

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From gerrit2 at review.openstack.org  Wed Jan 22 02:39:16 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 22 Jan 2014 02:39:16 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W5nim-0003tT-Cw@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit c0d1934b7d29ccfe42bd86ff9ee20cf7691804eb
Author: Jamie Lennox <jamielennox at redhat.com>
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
    Implements: bp key-distribution-server
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Wed Jan 22 15:18:07 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 22 Jan 2014 15:18:07 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W5zZ9-0005jA-2O@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 7e28069eed82da10754a7f1e1fedf9c9d0eb88df
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From robert.clark at hp.com  Wed Jan 22 15:37:36 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 22 Jan 2014 15:37:36 +0000
Subject: [Openstack-security] FW: [openstack/nova] SecurityImpact review
 request change I871af4018f99ddfcc8408708bdaaf480088ac477
In-Reply-To: <E1W5zZ9-0005jA-2O@review.openstack.org>
References: <E1W5zZ9-0005jA-2O@review.openstack.org>
Message-ID: <A0C170085C37664D93EE1604364858A1101B3085@G4W3300.americas.hpqcorp.net>



> -----Original Message-----
> From: gerrit2 at review.openstack.org
> [mailto:gerrit2 at review.openstack.org]
> Sent: 22 January 2014 15:18
> To: openstack-security at lists.openstack.org
> Subject: [Openstack-security] [openstack/nova] SecurityImpact review
> request change I871af4018f99ddfcc8408708bdaaf480088ac477
> 
> 
> Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
> https://review.openstack.org/40467
> 
> Log:
> commit 7e28069eed82da10754a7f1e1fedf9c9d0eb88df
> Author: Dan Genin <daniel.genin at jhuapl.edu>
> Date:   Thu Jan 2 09:45:11 2014 -0500
> 
>     Adds ephemeral storage encryption for LVM back-end images
> 
>     This patch adds ephemeral storage encryption for LVM back-end
> instances.
>     Encryption is implemented by passing all data written to and read
> from
>     the logical volumes through a dm-crypt layer. Most instance
> operations
>     such as pause/continue, suspend/resume, reboot, etc. are
supported.
>     Snapshots are also supported but are not encrypted at present. VM
> rescue
>     and migration are not supported at present.
> 
>     The proposed code provides data-at-rest security for all ephemeral
>     storage disks, preventing access to data while an instance is
>     shut down, or in case the compute host is shut down while an
> instance is
>     running.
> 
>     Options controlling the encryption state, cipher and key size are
>     specified in the "ephemeral_storage_encryption" options group. The
> boolean
>     "enabled" option turns encryption on and off and the "cipher" and
> "key_size"
>     options specify the cipher and key size, respectively.
> 
>     Note: depends on cryptsetup being installed.
> 
>     Implements: blueprint encrypt-ephemeral-storage
>     Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
>     DocImpact
>     SecurityImpact
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

Please take a good look at this guys.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140122/b3ca10e8/attachment.bin>

From thierry.carrez+lp at gmail.com  Wed Jan 22 15:43:51 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 22 Jan 2014 15:43:51 -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: <20140122154354.25525.41373.launchpad@wampee.canonical.com>

** Changed in: keystone
       Status: Fix Committed => Fix Released

** Changed in: keystone
    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/1254619

Title:
  external.Default authentication plugin only considers leftmost part of
  the REMOTE_USER split by "@"

Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Security Advisories:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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
      <VirtualHost *: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
          <Location />
              AuthType Basic
              AuthName "Restricted Files"
              AuthBasicProvider file
              AuthUserFile /opt/stack/htpasswd
              Require valid-user
          </Location>
      </VirtualHost>

  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 thierry.carrez+lp at gmail.com  Wed Jan 22 15:42:27 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 22 Jan 2014 15:42:27 -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: <20140122154230.30598.31492.launchpad@soybean.canonical.com>

** Changed in: keystone
       Status: Fix Committed => Fix Released

** Changed in: keystone
    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/1240382

Title:
  python-oauth2 dependency is unmaintained and has security issues

Status in OpenStack Identity (Keystone):
  Fix Released

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 thierry.carrez+lp at gmail.com  Wed Jan 22 16:10:20 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 22 Jan 2014 16:10:20 -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: <20140122161022.19526.60639.launchpad@chaenomeles.canonical.com>

** Changed in: heat
       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/1251647

Title:
  Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason

Status in Orchestration API (Heat):
  Fix Released
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 thierry.carrez+lp at gmail.com  Wed Jan 22 16:11:25 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 22 Jan 2014 16:11:25 -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: <20140122161129.30536.17798.launchpad@soybean.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/1247217

Title:
  Sanitize passwords when logging payload in wsgi for API Extensions

Status in OpenStack Compute (Nova):
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Fix Committed

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 devoid at anl.gov  Wed Jan 22 20:10:49 2014
From: devoid at anl.gov (Scott Devoid)
Date: Wed, 22 Jan 2014 20:10:49 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Possible to get and update
	quotas for nonexistant	tenant
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140122201049.19495.7761.malone@chaenomeles.canonical.com>

> Yup, the UX is horrible for this one. can you expand on the error
masking point?

That was an error I saw in Essex where one type of quota exception would
be thrown when another type was exceeded. I'll check in our Havana setup
and see if it is still a problem. I'll file a separate report if it is.

> I am not sure how you want to change things. For this to be confirmed
I would like a more explicit explanation of what the issue is and what
the desired outcome should be.

I think the simple fix is to have the nova api check against Keystone to
validate the UUID before sending a response to the client. I'll update
the bug description to suggest this solution.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Possible to get and update quotas for nonexistant tenant

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From thierry.carrez+lp at gmail.com  Wed Jan 22 20:24:03 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 22 Jan 2014 20:24: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: <20140122202406.30567.93742.launchpad@soybean.canonical.com>

** Changed in: nova
    Milestone: icehouse-2 => icehouse-3

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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 devoid at anl.gov  Wed Jan 22 20:24:45 2014
From: devoid at anl.gov (Scott Devoid)
Date: Wed, 22 Jan 2014 20:24:45 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota
	requests against Keystone
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140122202446.650.15937.launchpad@gac.canonical.com>

** Summary changed:

- Possible to get and update quotas for nonexistant tenant
+ Nova should confirm quota requests against Keystone

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Nova should confirm quota requests against Keystone

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/
  against Keystone to ensure that :tenant does exist.

  POST requests to a non-existant tenant should fail with a 400 error
  code.

  GET requests to a non-existant tenant may fail with a 400 error code.
  Current behavior is to return 200 with the default quotas. A slightly
  incompatible change would be to return a 302 redirect to /v2/:tenant
  /os-quota-sets/defaults in this case.

  Edit (2014-01-22)

  Original Description
  --------------------
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From devoid at anl.gov  Wed Jan 22 20:32:23 2014
From: devoid at anl.gov (Scott Devoid)
Date: Wed, 22 Jan 2014 20:32:23 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota
	requests against Keystone
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140122203225.19464.99379.launchpad@chaenomeles.canonical.com>

** Description changed:

+ os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/
+ against Keystone to ensure that :tenant does exist.
+ 
+ POST requests to a non-existant tenant should fail with a 400 error
+ code.
+ 
+ GET requests to a non-existant tenant may fail with a 400 error code.
+ Current behavior is to return 200 with the default quotas. A slightly
+ incompatible change would be to return a 302 redirect to /v2/:tenant/os-
+ quota-sets/defaults in this case.
+ 
+ Edit (2014-01-22)
+ 
+ Original Description
+ --------------------
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.
  
  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!
  
  I'm not sure if this is a bug or not. I cannot find any documentation on
  this interface.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Nova should confirm quota requests against Keystone

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/
  against Keystone to ensure that :tenant does exist.

  POST requests to a non-existant tenant should fail with a 400 error
  code.

  GET requests to a non-existant tenant may fail with a 400 error code.
  Current behavior is to return 200 with the default quotas. A slightly
  incompatible change would be to return a 302 redirect to /v2/:tenant
  /os-quota-sets/defaults in this case.

  Edit (2014-01-22)

  Original Description
  --------------------
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From gerrit2 at review.openstack.org  Wed Jan 22 21:31:10 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 22 Jan 2014 21:31:10 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W65OA-0008S5-0Y@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 23e5927c812bcbd249040a90e06a9e8b939487eb
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From thierry.carrez+lp at gmail.com  Thu Jan 23 15:28:04 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 23 Jan 2014 15:28:04 -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: <20140123152808.25542.2920.launchpad@soybean.canonical.com>

** Changed in: oslo
       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/1247217

Title:
  Sanitize passwords when logging payload in wsgi for API Extensions

Status in OpenStack Compute (Nova):
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released

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  Thu Jan 23 22:08:23 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 23 Jan 2014 22:08:23 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W6SRj-0007p3-QL@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 6e511a9188ad6e4b81058cf93a2ae41c1f980d93
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Fri Jan 24 19:58:06 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 24 Jan 2014 19:58:06 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W6mtC-0001Ey-OO@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 4edaf1455f484497b02600fc0936d624d974d3a6
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Mon Jan 27 09:13:37 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 27 Jan 2014 09:13:37 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I091b1620ab60184921cc12e038af5d717d4d476f
Message-ID: <E1W7iG9-0007yX-GY@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/65696

Log:
commit 5809bf49ed9c524c3eae82cec1aab403d579acb4
Author: Sascha Peilicke <speilicke at suse.com>
Date:   Thu Jan 9 15:14:24 2014 +0100

    Support passing 'neutron_insecure' to neutronclient
    
    When using a self-signed certificate for the network service endpoint,
    the metadata agent has to pass the 'insecure' flag to neutronclient.
    Otherwise requests will fail due to the failed certificate validity
    check.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1269740
    Change-Id: I091b1620ab60184921cc12e038af5d717d4d476f




From gerrit2 at review.openstack.org  Tue Jan 28 14:46:43 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 28 Jan 2014 14:46:43 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W89w3-0002a5-Ck@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 864d95295521582120159b23b2e4fcc81537d121
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Tue Jan 28 17:22:26 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 28 Jan 2014 17:22:26 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W8CMk-000877-Ck@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit e417a810c7534f5011fd71e95600b0633489edf1
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Tue Jan 28 17:37:22 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 28 Jan 2014 17:37:22 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W8CbC-00010i-Jv@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 8ad72ce29e02597f0237bc3df6dd7f111f23916c
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Thu Jan 30 04:28:39 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Jan 2014 04:28:39 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1W8jF1-0005rW-VY@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/59603

Log:
commit fdfb0f24c4ba5e64b56a3e9e2fafdb31f84f972a
Author: Jamie Lennox <jamielennox at redhat.com>
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
    Implements: bp key-distribution-server
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Thu Jan 30 15:00:07 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Jan 2014 15:00:07 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W8t67-0004tN-12@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 0343bc5d861cbd7c024dc7dff02baca905cb6b84
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Thu Jan 30 16:57:02 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Jan 2014 16:57:02 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1W8uvG-0007J0-3F@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/40467

Log:
commit 3c9ab57d3ac08c3a090ee350b52219ee5ce727a3
Author: Dan Genin <daniel.genin at jhuapl.edu>
Date:   Thu Jan 2 09:45:11 2014 -0500

    Adds ephemeral storage encryption for LVM back-end images
    
    This patch adds ephemeral storage encryption for LVM back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Implements: blueprint encrypt-ephemeral-storage
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From hailybrown at hushmail.com  Thu Jan 30 21:59:00 2014
From: hailybrown at hushmail.com (hailybrown at hushmail.com)
Date: Thu, 30 Jan 2014 16:59:00 -0500
Subject: [Openstack-security] Fake Conferences CSCI and WORLDCOMP of Hamid
	Arabnia
Message-ID: <20140130215901.04F456018A@smtp.hushmail.com>

Fake Conferences CSCI and WORLDCOMP of Hamid Arabnia

If you have any thought of attending the world’s biggest 
fake conference in computer science, WORLDCOMP  
http://www.world-academy-of-science.org you must visit any 
websites below

https://sites.google.com/site/worlddump1 
or
https://sites.google.com/site/dumpconf 
https://sites.google.com/site/moneycomp1
https://sites.google.com/site/worlddump4

The organizer of this conference is Hamid Arabnia  
http://www.cs.uga.edu/~hra a professor from University 
of Georgia, Athens, US.  The primary goal of this 
conference is to collect registration fee by accepting 
all submitted papers. Several fake papers were published 
in the conference proceedings. He already earned millions 
of dollars from the registration fee and is using part 
of the money for anti-Christmas greetings campaign.   
http://worldcomp-fake-bogus.blogspot.com   has 
additional information on this campaign. He recently 
started another new conference CSCI due to his hunger 
for money  http://www.americancse.org

Hamid Arabnia failed to reveal the reviews and reviewers' 
information for all the papers he received, despite 
repeated requests and challenges. The reason for his 
failure is there were no reviews and reviewers and he 
just cheated the research community for more than a 
decade by announcing that each draft paper is reviewed 
by two experts. We challenge him to publish these details 
at the conference website. Where are these experts? 
Where are these reviews? 

Soon he comes up with a story that he lost all the reviews 
and reviewers’ information because of computer crash or 
theft.

DBLP stopped indexing these conferences since 2011 
and displayed an explicit message; 
The DBLP Advisory Board decided to discontinue indexing of 
this conference series. Visit 
http://www.informatik.uni-trier.de/~ley/db/conf/biocomp/index.html 
as a sample.

He was forced to remove his name, the university of 
Georgia name, and university of Georgia email address from 
the conference’s contact page because the University has 
banned him from doing that. Do not spoil your resume by 
publishing in this bogus conference.

Wikipedia’s comments on Hamid Arabnia are at     
http://en.wikipedia.org/w/index.php?title=Talk:Hamid_Arabnia&oldid  

Additional information on this conference bogus conference is 
available by searching internet using the keywords   
worldcomp fake   or Hamid Arabnia fake

Apologies for posting to multiple mailing lists. Spreading the 
news is the only way to stop this conference from harming 
innocent researchers.

Respectfully,
Many researchers cheated by Hamid Arabnia’s fake conferences




From gerrit2 at review.openstack.org  Thu Jan 30 22:09:33 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 30 Jan 2014 22:09:33 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71
Message-ID: <E1W8znh-0007xk-97@review.openstack.org>


Hi, I'd like you to take a look at this patch for potential
SecurityImpact.
https://review.openstack.org/70228

Log:
commit 34fc2bc095905e09d388266e8abc6608d6719d85
Author: Kaitlin Farr <kaitlin.farr at jhuapl.edu>
Date:   Thu Jan 30 16:58:26 2014 -0500

    Adds ephemeral storage encryption for Raw back-end images
    
    This patch adds ephemeral storage encryption for Raw back-end instances.
    Encryption is implemented by passing all data written to and read from
    the logical volumes through a dm-crypt layer. Most instance operations
    such as pause/continue, suspend/resume, reboot, etc. are supported.
    Snapshots are also supported but are not encrypted at present. VM rescue
    and migration are not supported at present.
    
    The proposed code provides data-at-rest security for all ephemeral
    storage disks, preventing access to data while an instance is
    shut down, or in case the compute host is shut down while an instance is
    running.
    
    Options controlling the encryption state, cipher and key size are
    specified in the "ephemeral_storage_encryption" options group. The boolean
    "enabled" option turns encryption on and off and the "cipher" and "key_size"
    options specify the cipher and key size, respectively.
    
    Note: depends on cryptsetup being installed.
    
    Change-Id: I0dfc3ba8fa8317d9832b3b8fb62f348dc0567e71
    Implements: blueprint encrypt-ephemeral-storage
    DocImpact
    SecurityImpact




From gmurphy at redhat.com  Fri Jan 31 00:57:09 2014
From: gmurphy at redhat.com (Grant Murphy)
Date: Fri, 31 Jan 2014 10:57:09 +1000
Subject: [Openstack-security] OSSN required?
Message-ID: <1391129829.2549.9.camel@lappy>

Red Hat security response team have recently issued an errata for a
problem we have fixed publicly upstream. As a CVE has been assigned for
this problem I believe it is worth issuing a OSSN.

The details of the errata are available here: 
	https://rhn.redhat.com/errata/RHSA-2014-0112.html

The relevant launchpad bug is: 
	https://bugs.launchpad.net/oslo/+bug/1158807


- Grant. 

 




From bdpayne at acm.org  Fri Jan 31 01:17:53 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Thu, 30 Jan 2014 17:17:53 -0800
Subject: [Openstack-security] OSSN required?
In-Reply-To: <1391129829.2549.9.camel@lappy>
References: <1391129829.2549.9.camel@lappy>
Message-ID: <CAFpPvXAHz7X9N=oP1cSuxxnR8ADekhee1k=7Jz8DQHG5bQUXOQ@mail.gmail.com>

Are you thinking an OSSN or an OSSA?  The advisory (OSSA) is often what is
used for security issues that have been fixed and we want to tell people to
upgrade.  The note (OSSN) is often what is used for guidance on configuring
one's system securely.

-bryan



On Thu, Jan 30, 2014 at 4:57 PM, Grant Murphy <gmurphy at redhat.com> wrote:

> Red Hat security response team have recently issued an errata for a
> problem we have fixed publicly upstream. As a CVE has been assigned for
> this problem I believe it is worth issuing a OSSN.
>
> The details of the errata are available here:
>         https://rhn.redhat.com/errata/RHSA-2014-0112.html
>
> The relevant launchpad bug is:
>         https://bugs.launchpad.net/oslo/+bug/1158807
>
>
> - Grant.
>
>
>
>
> _______________________________________________
> 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: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140130/8b7c06bc/attachment.html>

From fungi at yuggoth.org  Fri Jan 31 01:32:44 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 31 Jan 2014 01:32:44 +0000
Subject: [Openstack-security] OSSN required?
In-Reply-To: <CAFpPvXAHz7X9N=oP1cSuxxnR8ADekhee1k=7Jz8DQHG5bQUXOQ@mail.gmail.com>
References: <1391129829.2549.9.camel@lappy>
 <CAFpPvXAHz7X9N=oP1cSuxxnR8ADekhee1k=7Jz8DQHG5bQUXOQ@mail.gmail.com>
Message-ID: <20140131013242.GX2347@yuggoth.org>

On 2014-01-30 17:17:53 -0800 (-0800), Bryan D. Payne wrote:
> Are you thinking an OSSN or an OSSA? The advisory (OSSA) is
> often what is used for security issues that have been fixed and
> we want to tell people to upgrade. The note (OSSN) is often what
> is used for guidance on configuring one's system securely.

Good point. It looks like this was fixed early in the Havana
development cycle, but not dealt with as a security vulnerability
nor brought to the VMT's attention at the time. Since QPid support
seems to have been in place around the Essex release we could in
theory issue a retroactive OSSA affecting Grizzly (but its end of
support is only about a month away now). Thoughts?
-- 
Jeremy Stanley



From bdpayne at acm.org  Fri Jan 31 01:37:11 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Thu, 30 Jan 2014 17:37:11 -0800
Subject: [Openstack-security] OSSN required?
In-Reply-To: <20140131013242.GX2347@yuggoth.org>
References: <1391129829.2549.9.camel@lappy>
 <CAFpPvXAHz7X9N=oP1cSuxxnR8ADekhee1k=7Jz8DQHG5bQUXOQ@mail.gmail.com>
 <20140131013242.GX2347@yuggoth.org>
Message-ID: <CAFpPvXBJwCAZn=-cEtcDGythN=vqoK72imQvWqJsVgHDeqR4xw@mail.gmail.com>

For me, if it is still supported today then we should issue the OSSA.
-bryan


On Thu, Jan 30, 2014 at 5:32 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2014-01-30 17:17:53 -0800 (-0800), Bryan D. Payne wrote:
> > Are you thinking an OSSN or an OSSA? The advisory (OSSA) is
> > often what is used for security issues that have been fixed and
> > we want to tell people to upgrade. The note (OSSN) is often what
> > is used for guidance on configuring one's system securely.
>
> Good point. It looks like this was fixed early in the Havana
> development cycle, but not dealt with as a security vulnerability
> nor brought to the VMT's attention at the time. Since QPid support
> seems to have been in place around the Essex release we could in
> theory issue a retroactive OSSA affecting Grizzly (but its end of
> support is only about a month away now). Thoughts?
> --
> Jeremy Stanley
>
> _______________________________________________
> 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: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140130/1317516e/attachment.html>

From kseifried at redhat.com  Fri Jan 31 03:34:46 2014
From: kseifried at redhat.com (Kurt Seifried)
Date: Thu, 30 Jan 2014 20:34:46 -0700
Subject: [Openstack-security] OSSN required?
In-Reply-To: <CAFpPvXBJwCAZn=-cEtcDGythN=vqoK72imQvWqJsVgHDeqR4xw@mail.gmail.com>
References: <1391129829.2549.9.camel@lappy>
 <CAFpPvXAHz7X9N=oP1cSuxxnR8ADekhee1k=7Jz8DQHG5bQUXOQ@mail.gmail.com>
 <20140131013242.GX2347@yuggoth.org>
 <CAFpPvXBJwCAZn=-cEtcDGythN=vqoK72imQvWqJsVgHDeqR4xw@mail.gmail.com>
Message-ID: <52EB19D6.7060405@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/30/2014 06:37 PM, Bryan D. Payne wrote:
> For me, if it is still supported today then we should issue the
> OSSA. -bryan
> 

My understanding is that it requires a code change to fix so to me
that sounds like an OSSN.

In my mind at least OSSN=code change, OSSA=config/docs change. Is that
correct?


- -- 
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

iQIcBAEBAgAGBQJS6xnVAAoJEBYNRVNeJnmTZasP/iubHgdDkjdpiWN6kODKOKHc
XE+wMBt+ZiMYBmG1MSxMyEx3W8suq67K2Yy2WLvYzr4eBzgSe22ztkrjPLWZCQTH
8m8JrAn8XKcPE8CRFWGmbV0069eRXcsxBxIrf+xdLKqXteJBLfJ9MEO5EGmknd6H
ZOHxIsdS7bB9pVxbqlSgUORmvX//bHDF9LxGvHdHaiudj8XEOBLbSms1QIDOPw7b
NI5mHPOp1GY2uGvt3lbr319xHnmliHgSvuUHI41+3GmU+l/9imdWl78nxr2CKyAg
bh4WqOWTED+zFMAUyOs01JJBHpR7nTxd7nQTaE3W2hEhvO6DiHsA/hlXnOUR+nk2
2fWRwm1L8OnfxeChoEdUzJm3jkVcnsd6fG1IzOyWw7WUT13NUkbQzuB6JV3zeY5A
gv65/zGqYTPxq7i8+wcfmrJjz7h1KfCeaFSDzP4AMFNDCHCrHLDql5Wgbe2hhxbg
sghErHvz7keKJ5mMp8aZ4+vm4ERIpyOsP/LCtsyj6G+Zt5I8xkfrIJXJrXP8605w
WIn0tyjYQBySFV8j+o9Pv9CIpPSkBC1xPmne1lkBL6gVKK7iB3u1c6eCOfa4iL0E
z/wguXXvotyFKi5EppjbyZuRewnNrMaFk5xEIOumXK5fC1Vx3SF1utnYFRAJM7h+
1JP+GKjbte0nDLfLRR5l
=l6fA
-----END PGP SIGNATURE-----



From nkinder at redhat.com  Fri Jan 31 03:44:16 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Thu, 30 Jan 2014 19:44:16 -0800
Subject: [Openstack-security] OSSN required?
In-Reply-To: <52EB19D6.7060405@redhat.com>
References: <1391129829.2549.9.camel@lappy>
 <CAFpPvXAHz7X9N=oP1cSuxxnR8ADekhee1k=7Jz8DQHG5bQUXOQ@mail.gmail.com>
 <20140131013242.GX2347@yuggoth.org>
 <CAFpPvXBJwCAZn=-cEtcDGythN=vqoK72imQvWqJsVgHDeqR4xw@mail.gmail.com>
 <52EB19D6.7060405@redhat.com>
Message-ID: <52EB1C10.20207@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/30/2014 07:34 PM, Kurt Seifried wrote:
> On 01/30/2014 06:37 PM, Bryan D. Payne wrote:
>> For me, if it is still supported today then we should issue the 
>> OSSA. -bryan
> 
> 
> My understanding is that it requires a code change to fix so to me 
> that sounds like an OSSN.
> 
> In my mind at least OSSN=code change, OSSA=config/docs change. Is
> that correct?

You have it reversed.  That said, an issue described in an OSSN might
still trigger a code change, though there is usually a workaround that
the OSSN recommends.

> 
> 
> 
> _______________________________________________ Openstack-security
> mailing list Openstack-security at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS6xwIAAoJEJa+6E7Ri+EVfN4H/i9mxYM5bB+dycJYUEo3KPtV
Ah3feaZoLCWIZm0LAW7/Pv5TY2dkIG4NgBWYAypO7YKhupzFZBXux5FQxrnBEEFc
i0xChTG9whDDmERkZn26O6kms4owSqpygH8GBU8WR1mydsPozrrW5G1Yhs2mnIp8
HYcpJ8DHCN+RcaWlOevI5HO5nCa2AZGfT6yp0Vdg3AmB4up+aJ3gpNeBWpPIYhkP
QZkWMekU7q5NYVgWHp1taTHk3okS1JKg7Jvi8VFj6g+jvnlKkMEuAo3TpDTchC/b
62j/smcyCYuHRiLGKQlvY6bwZ8ylrxPLK75xjUufLr+3LtIRLhq35ijpWSdu3lE=
=XYqR
-----END PGP SIGNATURE-----



From kseifried at redhat.com  Fri Jan 31 05:34:50 2014
From: kseifried at redhat.com (Kurt Seifried)
Date: Thu, 30 Jan 2014 22:34:50 -0700
Subject: [Openstack-security] OSSN required?
In-Reply-To: <52EB1C10.20207@redhat.com>
References: <1391129829.2549.9.camel@lappy>
 <CAFpPvXAHz7X9N=oP1cSuxxnR8ADekhee1k=7Jz8DQHG5bQUXOQ@mail.gmail.com>
 <20140131013242.GX2347@yuggoth.org>
 <CAFpPvXBJwCAZn=-cEtcDGythN=vqoK72imQvWqJsVgHDeqR4xw@mail.gmail.com>
 <52EB19D6.7060405@redhat.com> <52EB1C10.20207@redhat.com>
Message-ID: <52EB35FA.4020103@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/30/2014 08:44 PM, Nathan Kinder wrote:
> On 01/30/2014 07:34 PM, Kurt Seifried wrote:
>> On 01/30/2014 06:37 PM, Bryan D. Payne wrote:
>>> For me, if it is still supported today then we should issue the
>>>  OSSA. -bryan
> 
> 
>> My understanding is that it requires a code change to fix so to
>> me that sounds like an OSSN.
> 
>> In my mind at least OSSN=code change, OSSA=config/docs change.
>> Is that correct?
> 
> You have it reversed.  That said, an issue described in an OSSN
> might still trigger a code change, though there is usually a
> workaround that the OSSN recommends.

Sorry yeah, OSSA/OSSN mental swap. Derp!


- -- 
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

iQIcBAEBAgAGBQJS6zX6AAoJEBYNRVNeJnmThpEP/1r1ZghhSqe3oFYpBjALs+Bo
31/wxM6a7EwVE4wi3ijvJFQTL4oj3hf5A1A8ixexYGTaa+wvgH7qP/jD2YXO7I8h
K2H5sJGEBWKisnq0hMf6EpTBkoW1bGI1rcdIC0ZZD6b0FrcYBN2nl37wX+t3+a6z
V3KJNvPrlE6RSDmyFw2/EVErF/NQbBWvgrL27VLgXLSEJVeST4iQBUgwNGzmZCIC
oDGRoYts967cLZb+oU6b6exkDkwfciJB1J5zmBFFsoLG81xfo6w1iiwJoVynzC3g
4hCbtnnL0tBgSpZ6EwXPhXt2O+BRYGu2HV1XzPtpkcj7urZ75XUh5sy6Cq5VpmjZ
mxjrWrQYaIE2Mj4sLIjL6i3nzjAsA4CSVkP0NO5hnvlaxNBNuTCn76ZytKZLZRq9
WBndn0jP/NKO/trputgKU5Kr14HDzOAs4xSu2ecYqMRs6RxjOQRx7wIhE6VVvwXi
Dt6Or9x1em4ZMxVTGr5/jpicQ03jEHDQA6PT8g0e/kedvHISz7o9LEhhH8WNXjAK
Jr1mgeD8qSi88qyWzavJzqU99Bc93OK3ZNjq0y0ox3R2b76eCAzuLLTuC8dl2Eyn
PTslezFuMCDZbk/On3B+AI976LlAT0pYqH2gOBKeIHX2kKxF2NKAVdxbt8XLcils
/78hQuenv0Wbt5eqtngU
=4JJG
-----END PGP SIGNATURE-----



From thierry at openstack.org  Fri Jan 31 09:27:51 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Fri, 31 Jan 2014 10:27:51 +0100
Subject: [Openstack-security] OSSN required?
In-Reply-To: <CAFpPvXBJwCAZn=-cEtcDGythN=vqoK72imQvWqJsVgHDeqR4xw@mail.gmail.com>
References: <1391129829.2549.9.camel@lappy>
 <CAFpPvXAHz7X9N=oP1cSuxxnR8ADekhee1k=7Jz8DQHG5bQUXOQ@mail.gmail.com>
 <20140131013242.GX2347@yuggoth.org>
 <CAFpPvXBJwCAZn=-cEtcDGythN=vqoK72imQvWqJsVgHDeqR4xw@mail.gmail.com>
Message-ID: <52EB6C97.6020101@openstack.org>

Bryan D. Payne wrote:
> For me, if it is still supported today then we should issue the OSSA.

+1

-- 
Thierry Carrez (ttx)



From fungi at yuggoth.org  Fri Jan 31 15:49:13 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 31 Jan 2014 15:49:13 +0000
Subject: [Openstack-security] OSSN required?
In-Reply-To: <52EB19D6.7060405@redhat.com>
References: <1391129829.2549.9.camel@lappy>
 <CAFpPvXAHz7X9N=oP1cSuxxnR8ADekhee1k=7Jz8DQHG5bQUXOQ@mail.gmail.com>
 <20140131013242.GX2347@yuggoth.org>
 <CAFpPvXBJwCAZn=-cEtcDGythN=vqoK72imQvWqJsVgHDeqR4xw@mail.gmail.com>
 <52EB19D6.7060405@redhat.com>
Message-ID: <20140131154911.GY2347@yuggoth.org>

On 2014-01-30 20:34:46 -0700 (-0700), Kurt Seifried wrote:
[...]
> In my mind at least OSSN=code change, OSSA=config/docs change. Is
> that correct?

A->advisory, N->note. The VMT should issue advisories when the
OpenStack project fixes security vulnerabilities in its software and
then distributes patches or releases new versions incorporating
those fixes. The OSSG may issue notes when there are new
recommendations for configuration or potential pitfalls of which
users should be made aware.
-- 
Jeremy Stanley



From thomas at goirand.fr  Sun Jan 19 05:50:43 2014
From: thomas at goirand.fr (Thomas Goirand)
Date: Sun, 19 Jan 2014 05:50:43 -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: <20140119054537.19661.33378.malone@chaenomeles.canonical.com>

Hi,

Is there someone working on the backport to Havana? FYI, keystone is
currently blocked from migrating from Debian Sid to Debian testing
because of this problem (eg: oauth2 has been removed from testing
because unmaintained).

Cheers,

Thomas

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1240382

Title:
  python-oauth2 dependency is unmaintained and has security issues

Status in OpenStack Identity (Keystone):
  Fix Committed

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 1118066 at bugs.launchpad.net  Tue Jan 21 11:46:00 2014
From: 1118066 at bugs.launchpad.net (Dmitry)
Date: Tue, 21 Jan 2014 11:46:00 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Possible to get and update
	quotas for nonexistant	tenant
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140121113734.19694.92246.launchpad@chaenomeles.canonical.com>

** Changed in: nova
     Assignee: Dmitry (hovyakov) => (unassigned)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Possible to get and update quotas for nonexistant tenant

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From 1118066 at bugs.launchpad.net  Wed Jan 22 01:16:04 2014
From: 1118066 at bugs.launchpad.net (Joe Gordon)
Date: Wed, 22 Jan 2014 01:16:04 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Possible to get and update
	quotas for nonexistant	tenant
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140122010820.689.73520.malone@gac.canonical.com>

So this is a known issue, nova doesn't do any tenant validation for
quotas.   Right now the assumption is that only global admins (think
cloud operator) should have access to the last three methods in:

http://docs.openstack.org/api/openstack-compute/2/content/os-quota-
sets.html

GET	v2{/tenant_id}/os-quota-sets{/tenant_id}{/user_id}	
Enables an admin user to show quotas for a specified tenant and user.

POST	v2{/tenant_id}/os-quota-sets{/tenant_id}{/user_id}	
Updates quotas for a specified tenant/project and user.

GET	v2{/tenant_id}/os-quota-sets{/tenant_id}/detail{/user_id}	
Shows details for quotas for a specified tenant and user.

And as an admin (trusted user), we expect them to not break things.

This is part of a bigger issue, which is nova doesn't have great RBAC
support. Say you want to create a tenant admin who can set quotas per
user.

** Changed in: nova
       Status: Confirmed => Opinion

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Possible to get and update quotas for nonexistant tenant

Status in OpenStack Compute (Nova):
  Opinion

Bug description:
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From 1118066 at bugs.launchpad.net  Wed Jan 22 02:45:49 2014
From: 1118066 at bugs.launchpad.net (Joe Gordon)
Date: Wed, 22 Jan 2014 02:45:49 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Possible to get and update
	quotas for nonexistant	tenant
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140122024013.30737.44442.malone@soybean.canonical.com>

>"And as an admin (trusted user), we expect them to not break things."
>
>Sorry, I am going to have to disagree with you on this. The interface gives no indication that the request failed to produce the >desired effect. Add to that several facts: many quota-exceeded errors are masked by other quota exceeded error names and end >users will report quota exceeded errors as "my instance failed to start". These all add up to a bad user experience."

Yup, the UX is horrible for this one. can you expand on the error
masking point?

>"This is part of a bigger issue, which is nova doesn't have great RBAC support. Say you want to create a tenant admin who can set >quotas per user."
>
>I don't see how role-based access control is necessary when a simple check "does this string correspond to a real project UUID (or >name if you want to support that)" would suffice.

So nova doesn't keep track of project UUIDs, so this would have to be
implemented as a call out to keystone. So I am not very familiar with
the keystone API but I think you would need to call
v2.0/tenants{/tenantId}  (http://docs.openstack.org/api/openstack-
identity-service/2.0/content/Tenant_Operations.html) to make sure the
tenant is valid or not.


>
>Marking as open for these reasons.

Perhaps opinion was the wrong status, while I agree that there is
something to fix here, I am not sure how you want to change things.  For
this to be confirmed I would like a more explicit explanation of what
the issue is and what the desired outcome should be.  Do you just want
to make sure the tenant is valid? If so I can get behind that, but the
bug description needs some updating.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Possible to get and update quotas for nonexistant tenant

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From 1118066 at bugs.launchpad.net  Wed Jan 22 09:16:50 2014
From: 1118066 at bugs.launchpad.net (Phil Day)
Date: Wed, 22 Jan 2014 09:16:50 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Possible to get and update
	quotas for nonexistant	tenant
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140122090733.10349.46873.malone@wampee.canonical.com>

Goes beyond the scope of the specific bug here, but IMO the real fix for
this kind of issue is that quota limits should be managed in Keystone
(and passed to Nova and other services as part of the context) , and
enforced in the service.

Project and User IDs are really just foreign keys to Nova, it shouldn't
be managing properties of them.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066

Title:
  Possible to get and update quotas for nonexistant tenant

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  returns 200 with the default quotas.

  Moreover
  POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
  with updated quotas succeeds and that metadata is saved!

  I'm not sure if this is a bug or not. I cannot find any documentation
  on this interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions



From pengxuhan at gmail.com  Wed Jan 22 15:32:25 2014
From: pengxuhan at gmail.com (Xu Han Peng)
Date: Wed, 22 Jan 2014 15:32:25 -0000
Subject: [Openstack-security] [Bug 1262759] Re: ICMPv6 RAs should only be
	permitted from known	routers
References: <20131219170628.26400.87374.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140122152514.16952.4734.malone@chaenomeles.canonical.com>

As we talked in yesterday's IPv6 sub-team meeting, current we have this
patch allowing all the RA by default so VM can do SLAAC without any
security group configuration:

https://review.openstack.org/#/c/53028

But what we need soon is to only allow RA from the internal and external
routers instead of all the RA.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1262759

Title:
  ICMPv6 RAs should only be permitted from known routers

Status in OpenStack Neutron (virtual network service):
  New
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  ICMPv6 is now allowed in from any host but other hosts can offer bogus
  routes.

  Change security group/port filtering to respect known routers:

  - tenant routers attached to subnets and passing v6
  - physical routers on provider networks provided on the network (as some sort of admin configurable list for that network).

  (Security issue: One VM sharing a neutron network can divert outgoing
  traffic from other VMs.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1262759/+subscriptions



From bdobrelia at mirantis.com  Tue Jan 28 10:15:56 2014
From: bdobrelia at mirantis.com (Bogdan Dobrelya)
Date: Tue, 28 Jan 2014 10:15:56 -0000
Subject: [Openstack-security] [Bug 1272349] Re: We shouldn't assign public
	addresses for computes, ceph-osd and cinder-lvm roles
References: <20140124141418.15657.35524.malonedeb@gac.canonical.com>
Message-ID: <20140128100658.30333.26622.launchpad@gac.canonical.com>

** Tags added: security

** Changed in: fuel
       Status: New => Triaged

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1272349

Title:
  We shouldn't assign public addresses for computes, ceph-osd and
  cinder-lvm roles

Status in Fuel: OpenStack installer that works:
  Triaged

Bug description:
  Fuel assigns public network to all nodes in the cloud.

  But, in fact, only controller nodes should have a public network.

  We should remove public network for roles:
  - computes
  - ceph-osd
  - cinder-lvm

  Exception: in case nova-network (multi host) computes required public
  network.

To manage notifications about this bug go to:
https://bugs.launchpad.net/fuel/+bug/1272349/+subscriptions



From pengxuhan at gmail.com  Tue Jan 28 15:11:16 2014
From: pengxuhan at gmail.com (Xu Han Peng)
Date: Tue, 28 Jan 2014 15:11:16 -0000
Subject: [Openstack-security] [Bug 1262759] Re: ICMPv6 RAs should only be
	permitted from known	routers
References: <20131219170628.26400.87374.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140128150408.23636.85761.launchpad@soybean.canonical.com>

** Changed in: neutron
     Assignee: (unassigned) => Xu Han Peng (xuhanp)

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1262759

Title:
  ICMPv6 RAs should only be permitted from known routers

Status in OpenStack Neutron (virtual network service):
  New
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  ICMPv6 is now allowed in from any host but other hosts can offer bogus
  routes.

  Change security group/port filtering to respect known routers:

  - tenant routers attached to subnets and passing v6
  - physical routers on provider networks provided on the network (as some sort of admin configurable list for that network).

  (Security issue: One VM sharing a neutron network can divert outgoing
  traffic from other VMs.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1262759/+subscriptions



From abhishek.kekane at nttdata.com  Wed Jan 29 10:41:11 2014
From: abhishek.kekane at nttdata.com (Abhishek Kekane)
Date: Wed, 29 Jan 2014 10:41:11 -0000
Subject: [Openstack-security] [Bug 1227575] Re: DoS style attack on noVNC
 server can lead to service interruption or disruption
References: <20130919104202.7636.21762.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140129103046.12260.11596.malone@soybean.canonical.com>

Hi,

To bypass the session management for spice console, we can use template-method design pattern in NovaWebSocketProxy class.
Implement "new_client" as a template method in the NovaWebSocketProxy class.
>From this method, invoke create_console/remove_console method to manage sessions.
We can now create two new classes one for NoVncConsole and another for SpiceConsole in websocketproxy.py; extending NovaWebSocketProxy class and implements create_console/remove_console methods as per our need.

The advantage of using template method design pattern is new_client
method will be common for NoVncConsole and SpiceConsole.

Please let me know if you have any suggestions for the same.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1227575

Title:
  DoS style attack on noVNC server can lead to service interruption or
  disruption

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Notes:
  New

Bug description:
  There is no limiting on the number of VNC sessions that can be created for a single user's VNC token.
  Any attempt to create multiple (say hundreds or thousands) of websocket connections to the VNC server
  results in many connection timeouts. Due to these connection timeout error, other users trying to access their 
  VM's VNC console cannot do so.

  A sample script that tries to create 100,000 connections to Nova noVNC proxy, shows timeout errors
  Script: http://paste.openstack.org/show/47254/

  Script output.... connections get timed out after a while
  -------------------
  ....
  ..

  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  Received 'RFB 003.008
  '
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  Creating Connection
  Receiving...
  timed out
  --------------------

  Impact:
  1. Many of the sessions timeout. Any attempt to open other sessions also intermittently fail.
  This can cause serious problems to users already having a running VNC session or trying to create new sessions.

  2. The overall performance and response times of other nova services running on the novnc host, using tcp protocol
  also gets affected after the connection timeout errors.

  For example:
  Before running the sumulate thousands of connections program:
  $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc
  +-------+---------------------------------------------------------------------------------+
  | Type  | Url                                                                             |
  +-------+---------------------------------------------------------------------------------+
  | novnc | http://10.2.3.102:6080/vnc_auto.html?token=e776dd33-422f-4b56-9f98-e317410d0212 |
  +-------+---------------------------------------------------------------------------------+

  real    0m0.751s
  user    0m0.376s
  sys     0m0.084s

  rohit at precise-dev-102:~/tools/websocket-client-0.7.0$

  After running the program, the response time is quite high:
  $ time nova get-vnc-console c1b093a3-f53b-4282-b89c-e68f0fa1b6e5  novnc

  +-------+---------------------------------------------------------------------------------+
  | Type  | Url                                                                             |
  +-------+---------------------------------------------------------------------------------+
  | novnc | http://10.2.3.102:6080/vnc_auto.html?token=6865d675-d852-478b-b1ee-457b092f11b9 |
  +-------+---------------------------------------------------------------------------------+

  real    3m9.231s
  user    0m0.424s
  sys     0m0.108s

  
  Possible solutions:
  1. Allow just 1 session per instance, and raise a new exception, say, VNCSessionAlreadyExists to reject multiple
  connections for the same token, and return an error code to the user.
  2. Make the number of sessions allowed per instance configurable, limited by some count of sessions.

  However, both of these solutions may need to override and modify the do_proxy() method of websockify's WebSocketProxy class, 
  which can lead to maintenance issues.

  Another possible solution would be to implement some kind of callback function in websockify, to which we can pass the token
  for reconnection. This would first need contribution to the websockify project code, and then update Nova.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1227575/+subscriptions