From tom at openstack.org  Tue Apr  1 02:21:37 2014
From: tom at openstack.org (Tom Fifield)
Date: Tue, 01 Apr 2014 10:21:37 +0800
Subject: [Openstack-security] Seeking a moderator for ops security summit
	session
Message-ID: <533A22B1.4010306@openstack.org>

Hi,

backstory @ 
http://lists.openstack.org/pipermail/openstack-operators/2014-March/004180.html 


etherpad @ https://etherpad.openstack.org/p/ATL-ops-unconference-RFC

The short version is: we've got some space for talking ops in 
design-summit style at the Atlanta summit.

In this, there's a slot to chat security which needs a moderator/session 
leader. Anyone keen? Please sign up on the etherpad :)


Ideas that came up during brainstorming are:

Security (MODERATOR NEEDED)

     What should any cloud be doing (and can we make this default) ?

     How does an operator address an auditor ?

     Inspection/Surveillance of user VMs ?

     Answers to common concerns (hypervisor breakout, openrc variables 
in environment,

     What tools can we recommend ?

     and include into the gate to ensure impact is low in future

     Inspection/Surveillance of user VMs ?


Regards,


Tom



From sriram at sriramhere.com  Tue Apr  1 03:20:42 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Mon, 31 Mar 2014 20:20:42 -0700
Subject: [Openstack-security] Seeking a moderator for ops security
	summit session
In-Reply-To: <533A22B1.4010306@openstack.org>
References: <533A22B1.4010306@openstack.org>
Message-ID: <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>

Tom, I would love to. Signingup


On Mon, Mar 31, 2014 at 7:21 PM, Tom Fifield <tom at openstack.org> wrote:

> Hi,
>
> backstory @ http://lists.openstack.org/pipermail/openstack-operators/
> 2014-March/004180.html
>
> etherpad @ https://etherpad.openstack.org/p/ATL-ops-unconference-RFC
>
> The short version is: we've got some space for talking ops in
> design-summit style at the Atlanta summit.
>
> In this, there's a slot to chat security which needs a moderator/session
> leader. Anyone keen? Please sign up on the etherpad :)
>
>
> Ideas that came up during brainstorming are:
>
> Security (MODERATOR NEEDED)
>
>     What should any cloud be doing (and can we make this default) ?
>
>     How does an operator address an auditor ?
>
>     Inspection/Surveillance of user VMs ?
>
>     Answers to common concerns (hypervisor breakout, openrc variables in
> environment,
>
>     What tools can we recommend ?
>
>     and include into the gate to ensure impact is low in future
>
>     Inspection/Surveillance of user VMs ?
>
>
> Regards,
>
>
> Tom
>
> _______________________________________________
> 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/20140331/d33aeafc/attachment.html>

From sriram at sriramhere.com  Tue Apr  1 03:24:05 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Mon, 31 Mar 2014 20:24:05 -0700
Subject: [Openstack-security] Seeking a moderator for ops security
	summit session
In-Reply-To: <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
References: <533A22B1.4010306@openstack.org>
 <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
Message-ID: <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>

Looks like Bryan is already signed up from OSSG.

Tom - do you want a team to chat, or one person to moderate. Sorry it
wasn't clear.


On Mon, Mar 31, 2014 at 8:20 PM, Sriram Subramanian
<sriram at sriramhere.com>wrote:

> Tom, I would love to. Signingup
>
>
> On Mon, Mar 31, 2014 at 7:21 PM, Tom Fifield <tom at openstack.org> wrote:
>
>> Hi,
>>
>> backstory @ http://lists.openstack.org/pipermail/openstack-operators/
>> 2014-March/004180.html
>>
>> etherpad @ https://etherpad.openstack.org/p/ATL-ops-unconference-RFC
>>
>> The short version is: we've got some space for talking ops in
>> design-summit style at the Atlanta summit.
>>
>> In this, there's a slot to chat security which needs a moderator/session
>> leader. Anyone keen? Please sign up on the etherpad :)
>>
>>
>> Ideas that came up during brainstorming are:
>>
>> Security (MODERATOR NEEDED)
>>
>>     What should any cloud be doing (and can we make this default) ?
>>
>>     How does an operator address an auditor ?
>>
>>     Inspection/Surveillance of user VMs ?
>>
>>     Answers to common concerns (hypervisor breakout, openrc variables in
>> environment,
>>
>>     What tools can we recommend ?
>>
>>     and include into the gate to ensure impact is low in future
>>
>>     Inspection/Surveillance of user VMs ?
>>
>>
>> Regards,
>>
>>
>> Tom
>>
>> _______________________________________________
>> 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/20140331/5fe14c40/attachment.html>

From lilinguo8212 at gmail.com  Tue Apr  1 03:18:58 2014
From: lilinguo8212 at gmail.com (Lee Li)
Date: Tue, 01 Apr 2014 03:18:58 -0000
Subject: [Openstack-security] [Bug 1289195] Re: Duplicate security group
 name cause fail to start instance
References: <20140307080022.26596.61856.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140401031859.9919.92102.launchpad@soybean.canonical.com>

** No longer affects: neutron

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

Title:
  Duplicate security group name cause fail to start instance

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  When create a security group, the duplicate name is allowed.
  In create a instance, duplicate sg name will cause exception and the instance will be started fail. So the duplicate name of sg should be not allowed.

  In nova.network.neutronv2.API:allocate_for_instance
  for security_group in security_groups:
      name_match = None
      uuid_match = None
      for user_security_group in user_security_groups:
          if user_security_group['name'] == security_group:         # if have duplicate sg name, the name_match will not be None for the second matching.
              if name_match:
                  raise exception.NoUniqueMatch(
                      _("Multiple security groups found matching"
                         " '%s'. Use an ID to be more specific.") %
                      security_group)

              name_match = user_security_group['id']
          if user_security_group['id'] == security_group:
              uuid_match = user_security_group['id']

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



From tom at openstack.org  Tue Apr  1 03:37:59 2014
From: tom at openstack.org (Tom Fifield)
Date: Tue, 01 Apr 2014 11:37:59 +0800
Subject: [Openstack-security] Seeking a moderator for ops security
 summit session
In-Reply-To: <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>
References: <533A22B1.4010306@openstack.org>	<CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
 <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>
Message-ID: <533A3497.9080706@openstack.org>

Hi,

Going quickly back to the overall aims:

Aims:

1   Gather feedback on the issues that come up in running OpenStack and 
work to communicate this throughout the community

2   Create a forum in which to share best practices and architectures 
between interested parties

3    Increase constructive, proactive involvement from those running 
clouds in the design summit (as opposed to just checking email while 
watching presentations ^_^), and afterward


In terms of the 'moderator', we need someone who is able to make those 
aims  happen, in this session, for security. Someone who can extract 
from people in the room those security niggles that they've been having 
in neutron but haven't reported, or convincing someone to share that 
awesome openstack snort setup that they have going for nova vms, or 
encouraging everyone to join OSSG :)

Does that make more sense?

Regards,


Tom

On 01/04/14 11:24, Sriram Subramanian wrote:
> Looks like Bryan is already signed up from OSSG.
>
> Tom - do you want a team to chat, or one person to moderate. Sorry it
> wasn't clear.
>
>
> On Mon, Mar 31, 2014 at 8:20 PM, Sriram Subramanian
> <sriram at sriramhere.com <mailto:sriram at sriramhere.com>> wrote:
>
>     Tom, I would love to. Signingup
>
>
>     On Mon, Mar 31, 2014 at 7:21 PM, Tom Fifield <tom at openstack.org
>     <mailto:tom at openstack.org>> wrote:
>
>         Hi,
>
>         backstory @
>         http://lists.openstack.org/__pipermail/openstack-operators/__2014-March/004180.html
>         <http://lists.openstack.org/pipermail/openstack-operators/2014-March/004180.html>
>
>
>         etherpad @
>         https://etherpad.openstack.__org/p/ATL-ops-unconference-RFC
>         <https://etherpad.openstack.org/p/ATL-ops-unconference-RFC>
>
>         The short version is: we've got some space for talking ops in
>         design-summit style at the Atlanta summit.
>
>         In this, there's a slot to chat security which needs a
>         moderator/session leader. Anyone keen? Please sign up on the
>         etherpad :)
>
>
>         Ideas that came up during brainstorming are:
>
>         Security (MODERATOR NEEDED)
>
>              What should any cloud be doing (and can we make this default) ?
>
>              How does an operator address an auditor ?
>
>              Inspection/Surveillance of user VMs ?
>
>              Answers to common concerns (hypervisor breakout, openrc
>         variables in environment,
>
>              What tools can we recommend ?
>
>              and include into the gate to ensure impact is low in future
>
>              Inspection/Surveillance of user VMs ?
>
>
>         Regards,
>
>
>         Tom
>
>         _________________________________________________
>         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
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security>
>
>
>
>
>     --
>     Thanks,
>     -Sriram
>
>
>
>
> --
> Thanks,
> -Sriram




From hui.xiang at canonical.com  Tue Apr  1 03:40:19 2014
From: hui.xiang at canonical.com (Hui Xiang)
Date: Tue, 1 Apr 2014 11:40:19 +0800
Subject: [Openstack-security] OSSN repository is live!
In-Reply-To: <854D4FA8-0523-40A1-8D6E-4C20D1CD50AF@ericsson.com>
References: <53360D49.8050102@redhat.com>
 <CAFpPvXAnscOMP1w=VCaudO8sznODVgFkvjJou9MN-EQx_ppUWw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A112245925@G4W3229.americas.hpqcorp.net>
 <854D4FA8-0523-40A1-8D6E-4C20D1CD50AF@ericsson.com>
Message-ID: <CAHcZBTO_ZOrgV1PBWmzxKFz1E8WJoi++J1z1MHTsgN2AT62_XQ@mail.gmail.com>

+1, Thanks Nathan.


On Mon, Mar 31, 2014 at 4:00 PM, Abu Shohel Ahmed <ahmed.shohel at ericsson.com
> wrote:

> Hi Nathan,
>
> Great news!
>
> By the way, we are also planning to use GIT/GERRIT work flow for Threat
> modelling work. This will provide us clear process and
> visibility of the work chain. Could you please share, what is the process
> to achieve this. I mean, i can see a bug report related to this:
>
> https://bugs.launchpad.net/openstack-ci/+bug/1279074
>
> Thanks,
> Shohel
>
>
>
> On 30 Mar 2014, at 13:00, Clark, Robert Graham <robert.clark at hp.com>
> wrote:
>
> +1
>
> Lots of work has gone into this, thank you Nathan this is a big step
> forward for OSSNs
>
> *From:* Bryan D. Payne [mailto:bdpayne at acm.org <bdpayne at acm.org>]
> *Sent:* 29 March 2014 02:34
> *To:* Nathan Kinder
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] OSSN repository is live!
>
> Great news, thanks for setting this up!
> -bryan
>
>
> On Fri, Mar 28, 2014 at 5:01 PM, Nathan Kinder <nkinder at redhat.com> wrote:
>
> Hi,
>
> I'm happy to announce that our new OSSN git repository is live!  I have
> pre-populated it with all of the previously published Security Notes as
> well as templates to aid in the creation of new Security Notes.  The
> repository is located here:
>
>     http://git.openstack.org/cgit/openstack/openstack-security-notes/
>
> Now that we have this repository, we will use the normal Gerrit workflow
> [1] for reviewing OSSNs.  Bryan Payne, Rob Clark, and myself have +2
> review permission to start with.  We can certainly discuss making
> changes to this, but it should be fine for now.  It might be a good item
> for us to discuss in Atlanta at the Summit.
>
> Publishing of OSSNs is still a manual process.  I would like to add
> automatic publishing jobs, which is something that I will be looking
> into.  We can also potentially add check and gate jobs for things such
> as formatting if desired.
>
> I have updated the OSSN process wiki page [2] with details of the new
> review procedures.
>
> Thanks,
> -NGK
>
> [1] https://wiki.openstack.org/wiki/Gerrit_Workflow
> [2] https://wiki.openstack.org/wiki/Security/Security_Note_Process
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
> _______________________________________________
> 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/20140401/e94d0471/attachment.html>

From bdpayne at acm.org  Tue Apr  1 06:13:20 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Mon, 31 Mar 2014 23:13:20 -0700
Subject: [Openstack-security] Seeking a moderator for ops security
	summit session
In-Reply-To: <533A3497.9080706@openstack.org>
References: <533A22B1.4010306@openstack.org>
 <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
 <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>
 <533A3497.9080706@openstack.org>
Message-ID: <CAFpPvXAt-6_X3=GiwxA3waHqY65Gq3wJbQko4f-hdBswG5d54w@mail.gmail.com>

>
> Does that make more sense?
>

It does to me.

I think this sounds like a great idea and moderating it would be right up
my ally.  However, I'm happy to defer to Tom or a coin toss or whatever if
there are other people interested in moderating as well.

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

From tom at openstack.org  Tue Apr  1 06:52:15 2014
From: tom at openstack.org (Tom Fifield)
Date: Tue, 01 Apr 2014 14:52:15 +0800
Subject: [Openstack-security] Seeking a moderator for ops security
 summit session
In-Reply-To: <CAFpPvXAt-6_X3=GiwxA3waHqY65Gq3wJbQko4f-hdBswG5d54w@mail.gmail.com>
References: <533A22B1.4010306@openstack.org>
 <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
 <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>
 <533A3497.9080706@openstack.org>
 <CAFpPvXAt-6_X3=GiwxA3waHqY65Gq3wJbQko4f-hdBswG5d54w@mail.gmail.com>
Message-ID: <533A621F.6070605@openstack.org>

On 01/04/14 14:13, Bryan D. Payne wrote:
>     Does that make more sense?
>
>
> It does to me.
>
> I think this sounds like a great idea and moderating it would be right
> up my ally.  However, I'm happy to defer to Tom or a coin toss or
> whatever if there are other people interested in moderating as well.

Do you guys feel like co-moderating with each other?

Regards,

Tom




From gerrit2 at review.openstack.org  Tue Apr  1 07:23:27 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 01 Apr 2014 07:23:27 +0000
Subject: [Openstack-security] [stackforge/kite] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1WUt2d-0002I5-6T@review.openstack.org>


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

Log:
commit 333e81dbb4a8cbfa5ce90cc3085e6fd494d133e6
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.
    
    Add some routes to allow setting a key through the storage interface.
    
    SecurityImpact
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Tue Apr  1 07:24:40 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 01 Apr 2014 07:24:40 +0000
Subject: [Openstack-security] [stackforge/kite] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1WUt3o-0002RH-J6@review.openstack.org>


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

Log:
commit 6d742295a5f87e0e31ce3806a30bbeb8d69f12bc
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
    Change-Id: I4dbd23adb0bdd9011eb9a0b45e30dd862d390473




From florent.flament-ext at cloudwatt.com  Tue Apr  1 12:25:49 2014
From: florent.flament-ext at cloudwatt.com (Florent Flament)
Date: Tue, 01 Apr 2014 12:25:49 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140401122551.9681.54228.launchpad@soybean.canonical.com>

** Changed in: keystone
     Assignee: (unassigned) => Florent Flament (florent-flament-ext)

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From 1300274 at bugs.launchpad.net  Tue Apr  1 12:56:30 2014
From: 1300274 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 01 Apr 2014 12:56:30 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140401125631.5958.13654.malone@chaenomeles.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/84425

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

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From robert.clark at hp.com  Tue Apr  1 14:23:10 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 1 Apr 2014 14:23:10 +0000
Subject: [Openstack-security] OSSG Work Topics
Message-ID: <A0C170085C37664D93EE1604364858A112259713@G4W3229.americas.hpqcorp.net>

Hi All,

As we didn't have a meeting last week I wanted to take a few moments to share a few things from the last meeting that people on-list will probably care about.

Adding Security Tests to OpenStack Infrastructure:
There was discussion around the possibility of introducing security checks into the CI/CD system for OpenStack.  Once we can work out where the appropriate hooks are there's lots of opportunity to add security value into the process. I imagine an early version of this would introduce basic credential checking, regression checking and perhaps some specific pylint profiling. Later versions would probably look to include static analysis technologies. Hooks can be placed at later stages i.e Tempest to perform automated testing of API endpoints and Horizon.

Security Guidelines:
An area we need to get agreement on is the basic security guidelines that we can publish, get buy-in from PTLs and drive as basic security principles within the community. In some cases these can be codified and tied into the security testing work that I mention above. Some actions were taken to work on this at the last meeting and I'll follow-up on that during the next few days.

Security Review:
There is at the moment some great security review work that is taking place in the community, I think in the whole the OSSG should look to embrace this further. We have many large players in OpenStack participating in the OSSG, with organisations such as Intel, IBM, HP, Nebula - each are doing their own security reviews internally and slapping a proprietary 'Do not share' sticker on the results. I'd like to find a way to change that. For starters we are all repeating each other's work and we are all missing things that others have caught. In an ideal world I'd like to see us all working together on centralized security reviews, that are conducted in the open and interact with the community. I'm sure we will all still have internal reviews to do for value-add and extensions but at least these would be delta reviews, starting from a common base - probably crazy talk but I think it's worth discussing further.

Blueprints?
We need a way to record all the smart, interesting or crazy ideas that come up in the OSSG be them technical or otherwise. I think perhaps either coming up with a 'future project' page on the wiki or looking at the way blueprints are currently used for other projects might make sense.

Hopefully this email is useful for starting discussion or just keeping you informed on some of what's been going on and the direction we are likely to go in.

-Rob

IRC Minutes: http://eavesdrop.openstack.org/meetings/openstack_security_group/2014/openstack_security_group.2014-03-20-18.01.log.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140401/07686c86/attachment.html>

From sriram at sriramhere.com  Tue Apr  1 18:07:50 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Tue, 1 Apr 2014 11:07:50 -0700
Subject: [Openstack-security] Seeking a moderator for ops security
	summit session
In-Reply-To: <533A621F.6070605@openstack.org>
References: <533A22B1.4010306@openstack.org>
 <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
 <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>
 <533A3497.9080706@openstack.org>
 <CAFpPvXAt-6_X3=GiwxA3waHqY65Gq3wJbQko4f-hdBswG5d54w@mail.gmail.com>
 <533A621F.6070605@openstack.org>
Message-ID: <CAP6wb7KF7ijaDB_jOG+jLKOPA2yBszpuGMkJvGSvwvpkjHRF+g@mail.gmail.com>

Bryan can be the moderator. I can be of any assistance if needed.


On Mon, Mar 31, 2014 at 11:52 PM, Tom Fifield <tom at openstack.org> wrote:

> On 01/04/14 14:13, Bryan D. Payne wrote:
>
>>     Does that make more sense?
>>
>>
>> It does to me.
>>
>> I think this sounds like a great idea and moderating it would be right
>> up my ally.  However, I'm happy to defer to Tom or a coin toss or
>> whatever if there are other people interested in moderating as well.
>>
>
> Do you guys feel like co-moderating with each other?
>
> Regards,
>
> Tom
>
>


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

From fungi at yuggoth.org  Tue Apr  1 18:51:12 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 1 Apr 2014 18:51:12 +0000
Subject: [Openstack-security] Seeking a moderator for ops security
 summit session
In-Reply-To: <533A3497.9080706@openstack.org>
References: <533A22B1.4010306@openstack.org>
 <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
 <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>
 <533A3497.9080706@openstack.org>
Message-ID: <20140401185111.GL17131@yuggoth.org>

On 2014-04-01 11:37:59 +0800 (+0800), Tom Fifield wrote:
[...]
> 3    Increase constructive, proactive involvement from those running
> clouds in the design summit (as opposed to just checking email while
> watching presentations ^_^), and afterward
> 
> In terms of the 'moderator', we need someone who is able to make
> those aims  happen, in this session, for security.
[...]

Those bits make me think you might also need a representative from
the VMT on the moderator panel, depending on whether the topic
starts to dive into vulnerability management and security fixes. If
so (you likely have a better feel for where this audience is prone
to focus than I do), I or one of the other VMT members can probably
arrange to participate as well.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140401/7cc8b062/attachment.sig>

From 1300274 at bugs.launchpad.net  Tue Apr  1 19:55:03 2014
From: 1300274 at bugs.launchpad.net (Dolph Mathews)
Date: Tue, 01 Apr 2014 19:55:03 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140401195504.9505.18870.launchpad@soybean.canonical.com>

** Tags removed: icehouse-backport-potential
** Tags added: icehouse-rc-potential

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From 1299039 at bugs.launchpad.net  Tue Apr  1 21:20:52 2014
From: 1299039 at bugs.launchpad.net (Adam Young)
Date: Tue, 01 Apr 2014 21:20:52 -0000
Subject: [Openstack-security] [Bug 1299039] Re: Token Scoping
References: <20140328144343.5612.44045.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140401212052.9681.616.malone@soybean.canonical.com>

It would break Horizon.

On initial login, Horizon passes user id and password to the V2 API.  If
no tenant is specified, it gets s token scoped to the default tenant.

Even if it didn't, however, Horizon only holds on to the last token ,
and revokes all eralier, so you would break the ability to go from
project to project.

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

Title:
  Token Scoping

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  In Havana Stable release for both V2.0 an V3,

  A scoped token can be used to get another scoped or un-scopped token.
  This can be exploited by anyone who has gained access to  a scoped
  token.

  For example,

  1. userA is related to two projects: Project1, Project2
  2. userA creates  tokenA scoped by Project1
  3.  userA  shares the tokenA to a third party (malicious).  
  4. Third party can now make a token creation call to create a new tokenB scoped under projectB using tokenA.

  Although, we know that bearer token has all or nothing property, scoping the token can limit the exposure. 
  A scoped token should not be allowed to create another scoped token.

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



From tom at openstack.org  Wed Apr  2 02:07:14 2014
From: tom at openstack.org (Tom Fifield)
Date: Wed, 02 Apr 2014 10:07:14 +0800
Subject: [Openstack-security] Seeking a moderator for ops security
 summit session
In-Reply-To: <20140401185111.GL17131@yuggoth.org>
References: <533A22B1.4010306@openstack.org>
 <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
 <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>
 <533A3497.9080706@openstack.org> <20140401185111.GL17131@yuggoth.org>
Message-ID: <533B70D2.9010303@openstack.org>

On 02/04/14 02:51, Jeremy Stanley wrote:
> On 2014-04-01 11:37:59 +0800 (+0800), Tom Fifield wrote:
> [...]
>> 3    Increase constructive, proactive involvement from those running
>> clouds in the design summit (as opposed to just checking email while
>> watching presentations ^_^), and afterward
>>
>> In terms of the 'moderator', we need someone who is able to make
>> those aims  happen, in this session, for security.
> [...]
>
> Those bits make me think you might also need a representative from
> the VMT on the moderator panel, depending on whether the topic
> starts to dive into vulnerability management and security fixes. If
> so (you likely have a better feel for where this audience is prone
> to focus than I do), I or one of the other VMT members can probably
> arrange to participate as well.

I definitely hope the excellent work of the VMT comes up and is 
discussed, so that sounds wonderful :)




From gmurphy at redhat.com  Wed Apr  2 02:23:11 2014
From: gmurphy at redhat.com (Grant Murphy)
Date: Wed, 02 Apr 2014 02:23:11 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140402022312.30752.99244.launchpad@gac.canonical.com>

** Also affects: ossa
   Importance: Undecided
       Status: New

** Information type changed from Public to Public Security

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  New

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From gerrit2 at review.openstack.org  Wed Apr  2 08:47:50 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 02 Apr 2014 08:47:50 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b
Message-ID: <E1WVGpq-0001YV-0C@review.openstack.org>


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

Log:
commit 6c3f602599944fca414a073c0e609485b413e9e5
Author: Daniel Gollub <d.gollub at telekom.de>
Date:   Sat Feb 22 21:37:59 2014 +0100

    Replace HTTPSConnection in zadara with Requests
    
    SSL Verification is from now on enabled by default.
    
    This changes the default behaviour and is the primary intention of this
    change: verify SSL certificates.
    
    This might break existing configuration/setups where the SSL certificate
    used by the SAN would not pass the verification.
    
    Old behaviour can be forced by using `san_ssl_insecure=True`.
    
    SecurityImpact
    DocImpact
    Partial-Bug: 1188189
    
    Change-Id: I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b




From thierry.carrez+lp at gmail.com  Wed Apr  2 10:21:49 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 02 Apr 2014 10:21:49 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140402102150.9863.71946.malone@wampee.canonical.com>

Not totally convinced this is different from placing normal activity on
the server...

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

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From florent.flament-ext at cloudwatt.com  Wed Apr  2 13:24:26 2014
From: florent.flament-ext at cloudwatt.com (Florent Flament)
Date: Wed, 02 Apr 2014 13:24:26 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140402132426.12181.22484.malone@wampee.canonical.com>

@Thierry, the difference that I see between many authentication requests
versus one request with many authentication methods, is that in the
first case an operator may limit the rate at which requests are
processed, but it's more difficult to protect Keystone against few
requests triggering many authentication trials.

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From thierry.carrez+lp at gmail.com  Wed Apr  2 13:53:17 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 02 Apr 2014 13:53:17 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140402135320.5705.79403.launchpad@chaenomeles.canonical.com>

** Changed in: keystone
    Milestone: None => icehouse-rc2

** Tags removed: icehouse-rc-potential

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From 1300274 at bugs.launchpad.net  Wed Apr  2 14:37:58 2014
From: 1300274 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 02 Apr 2014 14:37:58 -0000
Subject: [Openstack-security] [Bug 1300274] Fix proposed to keystone
	(milestone-proposed)
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140402143758.22276.66.malone@wampee.canonical.com>

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/84735

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From houckrj at gmail.com  Wed Apr  2 15:49:02 2014
From: houckrj at gmail.com (Robert Houck)
Date: Wed, 2 Apr 2014 10:49:02 -0500
Subject: [Openstack-security] If a service is compromised,
	how compromised is the system?
Message-ID: <CAFbnOrUT_60M=yYwBY_w3HCqL+unqiV7qpJY4acD3eg=ME-16g@mail.gmail.com>

*BLUF* Since OpenStack is a distributed system, how compromised does the
system become when a single service is compromised?

*Details* I am looking at this from an insider threat, not an external
threat. Obviously, Keystone would be a 100% compromise as the thread can
create what ever token they want. In Havana, it would appear that
Ceilometer would have close to 0% on the actual operations. While billing
make be affected and usage information gathered, the system would still
operate properly.

While I have been reading up on OpenStack, I have not seen anything
detailed like this. Different policies could be implemented for each
service depending on their capabilities.

Additionally, I am looking for "flow of control" between services. I have
not found this in the documentation and would like to see what steps the
system goes through when answering a request.

While I have attempted to search the forum for similar topics, I did not
see any. I have a limited knowledge of OpenStack and may not have been
using the proper terms.

I have been looking through the Security Guide for a baseline and while
certain services are more important (messaging and keystone) or vulnerable
(nova) there isn't really a quantitative answer.

Another issue is defining how a compromise is seen. If one states a cloud
should provided Computing, Networking, and Storage (for runtime computing)
then the compromise of Swift, Neutron or Nova would mean a 100% compromise
as a removing any one of the three would prevent operations.

But one could also look at it as 33.333% for each part and one being
compromised/removed only affects 1/3 of the overall system.

I would like some professional feedback on these thoughts.


Thank you,
Robert Houck
Student, UTSA
(210) 587-9592
houckrj at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140402/1c7af31a/attachment.html>

From 1188189 at bugs.launchpad.net  Wed Apr  2 15:57:18 2014
From: 1188189 at bugs.launchpad.net (Mark McClain)
Date: Wed, 02 Apr 2014 15:57:18 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
 communication fails to check certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20140402155721.22113.69372.launchpad@wampee.canonical.com>

** Tags added: icehouse-backport-potential

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

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Python client library for Keystone:
  Fix Released
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

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



From 1300274 at bugs.launchpad.net  Wed Apr  2 16:31:00 2014
From: 1300274 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 02 Apr 2014 16:31:00 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140402163100.5581.42354.malone@chaenomeles.canonical.com>

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

commit ef868ad92c00e23a4a5e9eb71e3e0bf5ae2fff0c
Author: Florent Flament <florent.flament-ext at cloudwatt.com>
Date:   Tue Apr 1 12:48:22 2014 +0000

    Sanitizes authentication methods received in requests.
    
    When a user authenticates against Identity V3 API, he can specify
    multiple authentication methods. This patch removes duplicates, which
    could have been used to achieve DoS attacks.
    
    Change-Id: Iec9a1875a4ff6e2fac0fb2c3db6f3ce34a5dfd1d
    Closes-Bug: 1300274


** 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/1300274

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From bdpayne at acm.org  Wed Apr  2 20:08:28 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 2 Apr 2014 13:08:28 -0700
Subject: [Openstack-security] Seeking a moderator for ops security
	summit session
In-Reply-To: <533A621F.6070605@openstack.org>
References: <533A22B1.4010306@openstack.org>
 <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
 <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>
 <533A3497.9080706@openstack.org>
 <CAFpPvXAt-6_X3=GiwxA3waHqY65Gq3wJbQko4f-hdBswG5d54w@mail.gmail.com>
 <533A621F.6070605@openstack.org>
Message-ID: <CAFpPvXBXkV23G=VLYKnUeSAC9uOAHu4m6iCjveyDZ67wY+rwqQ@mail.gmail.com>

Tom,

I'm comfortable with what ever you think is best.  My input would be that
it all depends on what format you're looking for.  If there's already a
panel, then one moderator feels sufficient.  If you are building a panel of
moderators (?) then perhaps multiple people, and including the VMT as well,
makes sense.

I'm happy to let you craft the vision for this session to the point where
you are happy to hand it off.  And then I could take it from there.

My two cents,
-bryan




On Mon, Mar 31, 2014 at 11:52 PM, Tom Fifield <tom at openstack.org> wrote:

> On 01/04/14 14:13, Bryan D. Payne wrote:
>
>>     Does that make more sense?
>>
>>
>> It does to me.
>>
>> I think this sounds like a great idea and moderating it would be right
>> up my ally.  However, I'm happy to defer to Tom or a coin toss or
>> whatever if there are other people interested in moderating as well.
>>
>
> Do you guys feel like co-moderating with each other?
>
> Regards,
>
> Tom
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140402/9fcf9be5/attachment.html>

From tom at openstack.org  Thu Apr  3 01:48:17 2014
From: tom at openstack.org (Tom Fifield)
Date: Thu, 03 Apr 2014 09:48:17 +0800
Subject: [Openstack-security] Seeking a moderator for ops security
 summit session
In-Reply-To: <CAFpPvXBXkV23G=VLYKnUeSAC9uOAHu4m6iCjveyDZ67wY+rwqQ@mail.gmail.com>
References: <533A22B1.4010306@openstack.org>
 <CAP6wb7K4u-yHywwAANxL3YVWkR6_aq4_Dy_osxz5asD=h88_RA@mail.gmail.com>
 <CAP6wb7Kcjq=5THVRcR-ntDVcYgBQx2an0vQDpx74e4WSQsxNVg@mail.gmail.com>
 <533A3497.9080706@openstack.org>
 <CAFpPvXAt-6_X3=GiwxA3waHqY65Gq3wJbQko4f-hdBswG5d54w@mail.gmail.com>
 <533A621F.6070605@openstack.org>
 <CAFpPvXBXkV23G=VLYKnUeSAC9uOAHu4m6iCjveyDZ67wY+rwqQ@mail.gmail.com>
Message-ID: <533CBDE1.1090200@openstack.org>

On 03/04/14 04:08, Bryan D. Payne wrote:
> Tom,
>
> I'm comfortable with what ever you think is best.  My input would be
> that it all depends on what format you're looking for.  If there's
> already a panel, then one moderator feels sufficient.  If you are
> building a panel of moderators (?) then perhaps multiple people, and
> including the VMT as well, makes sense.
>
> I'm happy to let you craft the vision for this session to the point
> where you are happy to hand it off.  And then I could take it from there.

Hi Bryan,

Sorry for the confusion.

To clarify, this is not a panel session. It's a whole-room discussion 
session, like a regular design summit session.

I think I'll followup in off-list email with the appropriate parties 
(moderator-volunteers from all of the sessions in this section of the 
conference), to avoid annoying others on this list :)


Regards,


Tom




From thierry.carrez+lp at gmail.com  Thu Apr  3 08:58:07 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 03 Apr 2014 08:58:07 -0000
Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method
	chaining
References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140403085809.9182.6313.launchpad@gac.canonical.com>

** Changed in: keystone
   Importance: Undecided => Medium

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

Title:
  V3 api authentication method chaining

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  When using authentication method chaining for token creation (POST)
  in Keystone V3 api , it is possible to use authentication credentials
  for two different users . For example, if i have an existing token for
  a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier
  for demo tenant) and i have a user say 'test131' in admin tenant

  Now i can make an authentication call using auth method chaining

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "token" 
           ],
          "token":{
              "id":"6bb934a0120f097a32b5d3cc71f83beb"
           },
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"test131",
                 "password":"test131"
              }
           }
        }
     }
  }

  The call will succeed even though two different users authentication
  credentials are used.  The generated token will get properties of
  test131 user although the expirary date is set by demo user token.  If
  we change the methods sequence, the generated token will get all
  properties from demo users token.

  
  This is an undesired security behaviour - token should not  be allowed to generate using credentials from two different users.

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



From 1300274 at bugs.launchpad.net  Thu Apr  3 09:55:02 2014
From: 1300274 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 03 Apr 2014 09:55:02 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140403095502.17589.31818.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/84735
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=ce6cedb30c5c4b4cf4db9380f09443de22414b39
Submitter: Jenkins
Branch:    milestone-proposed

commit ce6cedb30c5c4b4cf4db9380f09443de22414b39
Author: Florent Flament <florent.flament-ext at cloudwatt.com>
Date:   Tue Apr 1 12:48:22 2014 +0000

    Sanitizes authentication methods received in requests.
    
    When a user authenticates against Identity V3 API, he can specify
    multiple authentication methods. This patch removes duplicates, which
    could have been used to achieve DoS attacks.
    
    Change-Id: Iec9a1875a4ff6e2fac0fb2c3db6f3ce34a5dfd1d
    Closes-Bug: 1300274


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

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

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

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From gerrit2 at review.openstack.org  Thu Apr  3 14:28:15 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 03 Apr 2014 14:28:15 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337
Message-ID: <E1WVicp-0002sc-J7@review.openstack.org>


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

Log:
commit 264b4a2523c165640f17aa4837f87ddfd0b49640
Author: Daniel Gollub <d.gollub at telekom.de>
Date:   Sun Mar 2 09:33:38 2014 +0100

    Replace HTTPSConnection in NEC plugin
    
    Replace HTTPSConnection in NEC plugin PFC driver with Requests.
    
    SSL Verification is from now on enabled by default.
    
    This changes the default behaviour and is the primary intention of this
    change: verify SSL certificates.
    
    This might break existing configuration/setups where the SSL certificate
    used by the NEC PFC driver would not pass the verification.
    
    SecurityImpact
    DocImpact
    Partial-Bug: 1188189
    
    Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337




From 1188189 at bugs.launchpad.net  Thu Apr  3 14:28:09 2014
From: 1188189 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 03 Apr 2014 14:28:09 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
 communication fails to check certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20140403142812.17655.71075.launchpad@chaenomeles.canonical.com>

** Changed in: neutron
     Assignee: Daniel Gollub (d-gollub) => Akihiro Motoki (amotoki)

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

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Python client library for Keystone:
  Fix Released
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

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



From 1188189 at bugs.launchpad.net  Thu Apr  3 14:29:06 2014
From: 1188189 at bugs.launchpad.net (Akihiro Motoki)
Date: Thu, 03 Apr 2014 14:29:06 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
 communication fails to check certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20140403142910.17349.4494.launchpad@chaenomeles.canonical.com>

** Changed in: neutron
     Assignee: Akihiro Motoki (amotoki) => Daniel Gollub (d-gollub)

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

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Python client library for Keystone:
  Fix Released
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

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



From 1299012 at bugs.launchpad.net  Wed Apr  2 12:14:39 2014
From: 1299012 at bugs.launchpad.net (Abu Shohel Ahmed)
Date: Wed, 02 Apr 2014 12:14:39 -0000
Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method
	chaining
References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140402121441.9863.83477.launchpad@wampee.canonical.com>

** Tags added: security

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

Title:
  V3 api authentication method chaining

Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  When using authentication method chaining for token creation (POST)
  in Keystone V3 api , it is possible to use authentication credentials
  for two different users . For example, if i have an existing token for
  a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier
  for demo tenant) and i have a user say 'test131' in admin tenant

  Now i can make an authentication call using auth method chaining

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "token" 
           ],
          "token":{
              "id":"6bb934a0120f097a32b5d3cc71f83beb"
           },
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"test131",
                 "password":"test131"
              }
           }
        }
     }
  }

  The call will succeed even though two different users authentication
  credentials are used.  The generated token will get properties of
  test131 user although the expirary date is set by demo user token.  If
  we change the methods sequence, the generated token will get all
  properties from demo users token.

  
  This is an undesired security behaviour - token should not  be allowed to generate using credentials from two different users.

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



From 1299012 at bugs.launchpad.net  Wed Apr  2 23:48:24 2014
From: 1299012 at bugs.launchpad.net (Dolph Mathews)
Date: Wed, 02 Apr 2014 23:48:24 -0000
Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method
	chaining
References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140402234824.9757.52194.malone@soybean.canonical.com>

Guang: can you propose your patch against master via gerrit now?

** Changed in: keystone
    Milestone: None => icehouse-rc2

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

Title:
  V3 api authentication method chaining

Status in OpenStack Identity (Keystone):
  New
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  When using authentication method chaining for token creation (POST)
  in Keystone V3 api , it is possible to use authentication credentials
  for two different users . For example, if i have an existing token for
  a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier
  for demo tenant) and i have a user say 'test131' in admin tenant

  Now i can make an authentication call using auth method chaining

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "token" 
           ],
          "token":{
              "id":"6bb934a0120f097a32b5d3cc71f83beb"
           },
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"test131",
                 "password":"test131"
              }
           }
        }
     }
  }

  The call will succeed even though two different users authentication
  credentials are used.  The generated token will get properties of
  test131 user although the expirary date is set by demo user token.  If
  we change the methods sequence, the generated token will get all
  properties from demo users token.

  
  This is an undesired security behaviour - token should not  be allowed to generate using credentials from two different users.

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



From 1299012 at bugs.launchpad.net  Thu Apr  3 05:22:29 2014
From: 1299012 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 03 Apr 2014 05:22:29 -0000
Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method
	chaining
References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140403052230.8734.55979.malone@gac.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/84945

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

** Changed in: keystone
     Assignee: (unassigned) => Guang Yee (guang-yee)

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

Title:
  V3 api authentication method chaining

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  When using authentication method chaining for token creation (POST)
  in Keystone V3 api , it is possible to use authentication credentials
  for two different users . For example, if i have an existing token for
  a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier
  for demo tenant) and i have a user say 'test131' in admin tenant

  Now i can make an authentication call using auth method chaining

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "token" 
           ],
          "token":{
              "id":"6bb934a0120f097a32b5d3cc71f83beb"
           },
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"test131",
                 "password":"test131"
              }
           }
        }
     }
  }

  The call will succeed even though two different users authentication
  credentials are used.  The generated token will get properties of
  test131 user although the expirary date is set by demo user token.  If
  we change the methods sequence, the generated token will get all
  properties from demo users token.

  
  This is an undesired security behaviour - token should not  be allowed to generate using credentials from two different users.

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



From gerrit2 at review.openstack.org  Thu Apr  3 19:33:14 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 03 Apr 2014 19:33:14 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WVnNy-0004X6-Fs@review.openstack.org>


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

Log:
commit dde7670369cc8cbc3fe1633935eeab218b93ea17
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Mar 13 15:38:34 2014 -0500

    Allow hash tokens with sha256
    
    Tokens were always hashed with md5. This change allows tokens to
    be hashed with sha256 or any other algorithm supported by hashlib.
    This is for security hardening.
    
    If the new 'hash_algorithm' configuration option is set to 'sha256'
    then the auth_token middleware will hash tokens using 'sha256' when
    
    a) Tokens are stored to the cache.
    b) Tokens are hashed to compare against the revocation list.
    
    Using this will require that the Keystone server is also configured
    to use the same algorithm for tokens, otherwise the revocation list
    comparison isn't going to work. The 'hash_algorithm' option defaults
    to 'md5' for backwards compatibility.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From nkinder at redhat.com  Thu Apr  3 20:49:31 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Thu, 03 Apr 2014 13:49:31 -0700
Subject: [Openstack-security] SSL proxies vs. native SSL support
In-Reply-To: <5339BE02.4010606@redhat.com>
References: <5331F532.4010306@redhat.com>
 <CAFpPvXBcOoLFsBFEnnjQz-kcsc_Js56d5JbY=gyniO466aG2cg@mail.gmail.com>
 <5339BE02.4010606@redhat.com>
Message-ID: <533DC95B.2040202@redhat.com>

On 03/31/2014 12:12 PM, Nathan Kinder wrote:
> On 03/25/2014 02:50 PM, Bryan D. Payne wrote:
>> A few thoughts come to mind:
>>
>> * For any production system, I suspect that you will be running a front
>> end server in front of the actual endpoint.  So, at a minimum, that
>> server is where the TLS termination would happen.  Depending on your
>> setup, it may make more sense to terminate directly at that server
>> (e.g., Apache or Nginx), or using a dedicated / purpose built TLS
>> termination shim (e.g., Stud or Pound).
>>
>> * In many deployments, the control plane uses a different trust model
>> than the external networks.  Services on the control plane may not trust
>> the same set of root certs that clients on the external network choose
>> to trust.  As such, the TLS setup would need to be different.
>>  Re-encrypting the connection at a proxy that sits on the boundary of
>> the external network and the control plane serves to handle this use
>> somewhat common use case.
>>
>> * In some cases it may be useful for purposes of load balancing, and
>> auditing to be able to inspect the traffic at a proxy sitting between
>> the external network and the control plane.
>>
>> * If there is no use case to inspect the traffic, and there is a common
>> set of trusted root certs on both networks, then I see no problem just
>> taking the TLS all the way back to the front-end server handling the
>> endpoint (these would likely be deployed on the same machine... and
>> could then just communicate the clear-text information over a unix
>> socket or similar setup).
> 
> A unix socket would definitely be ideal.  As you say, if inspection of
> the encrypted traffic is not needed for something like load balancing,
> this sort of deployment would meet the goal of keeping clear-text
> traffic off of the network.  It would also add some privilege separation
> by keeping access to the private key limited to the SSL terminator (vs.
> allowing the API endpoint process to access it).
> 
>>
>> If others agree, perhaps there is room to improve the wording in the
>> book around this point?  I do suspect that the setup described in the
>> book is most common for real world deployments, but I don't see anything
>> wrong with the other setup from a security standpoint.
> 
> I do think that some re-wording and more detail would add clarity in
> this area.  I think that each deployment will have different security
> requirements and concerns.  The Security Guide should spell out the
> options, with limitations and concerns mentioned for each.  This would
> allow the reader to make their own decision about what type of
> deployment would meet their requirements.
> 
> I'm working on writing up some details in this area, so I'd be happy to
> submit some patches for this chapter of the Security Guide.

I've published a blog post based on my research of this topic:

  https://blog-nkinder.rhcloud.com/?p=7

I'd like to use this as a basis for improving the Security Guide, but
I'd love to get some feedback from others first.  Any comments would be
much appreciated!

Thanks,
-NGK

> 
> -NGK
> 
>>
>> My two cents,
>> -bryan
>>
>>
>>
>> On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder <nkinder at redhat.com
>> <mailto:nkinder at redhat.com>> wrote:
>>
>>     Hi,
>>
>>     The Security Guide currently recommends that SSL/TLS be used to protect
>>     the API endpoints (as it should).  We specifically mention that SSL
>>     proxies should be used for this, as opposed to configuring SSL natively
>>     in the services themselves:
>>
>>
>>     http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html
>>
>>     Is there any particular reason why we don't recommend configuring
>>     SSL/TLS natively in the services?  It seems like that would be an ideal
>>     approach, as it eliminates the need for running proxies.  It also keeps
>>     access to the unencrypted traffic closer to the actual services that
>>     need to access it, which is better from a security standpoint.
>>
>>     I'm not sure that all of the integrated projects actually have working
>>     native SSL/TLS support, but I know that a number of them claim to have
>>     support.  Shouldn't native support be the preferred recommendation from
>>     a security standpoint?
>>
>>     Thanks,
>>     -NGK
>>
>>     _______________________________________________
>>     Openstack-security mailing list
>>     Openstack-security at lists.openstack.org
>>     <mailto:Openstack-security at lists.openstack.org>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 




From bdpayne at acm.org  Thu Apr  3 21:04:43 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Thu, 3 Apr 2014 14:04:43 -0700
Subject: [Openstack-security] SSL proxies vs. native SSL support
In-Reply-To: <533DC95B.2040202@redhat.com>
References: <5331F532.4010306@redhat.com>
 <CAFpPvXBcOoLFsBFEnnjQz-kcsc_Js56d5JbY=gyniO466aG2cg@mail.gmail.com>
 <5339BE02.4010606@redhat.com> <533DC95B.2040202@redhat.com>
Message-ID: <CAFpPvXBxcVhKVYe6zOFkRqeKTMftYcQjHOG1ZdTSOyekUHHN4g@mail.gmail.com>

I just read the blog post and it is a nice summary of the discussion we've
had in this thread.  Thanks for putting that together.  I'd be happy to
work with you to help make these improvements to the book.

-bryan


On Thu, Apr 3, 2014 at 1:49 PM, Nathan Kinder <nkinder at redhat.com> wrote:

> On 03/31/2014 12:12 PM, Nathan Kinder wrote:
> > On 03/25/2014 02:50 PM, Bryan D. Payne wrote:
> >> A few thoughts come to mind:
> >>
> >> * For any production system, I suspect that you will be running a front
> >> end server in front of the actual endpoint.  So, at a minimum, that
> >> server is where the TLS termination would happen.  Depending on your
> >> setup, it may make more sense to terminate directly at that server
> >> (e.g., Apache or Nginx), or using a dedicated / purpose built TLS
> >> termination shim (e.g., Stud or Pound).
> >>
> >> * In many deployments, the control plane uses a different trust model
> >> than the external networks.  Services on the control plane may not trust
> >> the same set of root certs that clients on the external network choose
> >> to trust.  As such, the TLS setup would need to be different.
> >>  Re-encrypting the connection at a proxy that sits on the boundary of
> >> the external network and the control plane serves to handle this use
> >> somewhat common use case.
> >>
> >> * In some cases it may be useful for purposes of load balancing, and
> >> auditing to be able to inspect the traffic at a proxy sitting between
> >> the external network and the control plane.
> >>
> >> * If there is no use case to inspect the traffic, and there is a common
> >> set of trusted root certs on both networks, then I see no problem just
> >> taking the TLS all the way back to the front-end server handling the
> >> endpoint (these would likely be deployed on the same machine... and
> >> could then just communicate the clear-text information over a unix
> >> socket or similar setup).
> >
> > A unix socket would definitely be ideal.  As you say, if inspection of
> > the encrypted traffic is not needed for something like load balancing,
> > this sort of deployment would meet the goal of keeping clear-text
> > traffic off of the network.  It would also add some privilege separation
> > by keeping access to the private key limited to the SSL terminator (vs.
> > allowing the API endpoint process to access it).
> >
> >>
> >> If others agree, perhaps there is room to improve the wording in the
> >> book around this point?  I do suspect that the setup described in the
> >> book is most common for real world deployments, but I don't see anything
> >> wrong with the other setup from a security standpoint.
> >
> > I do think that some re-wording and more detail would add clarity in
> > this area.  I think that each deployment will have different security
> > requirements and concerns.  The Security Guide should spell out the
> > options, with limitations and concerns mentioned for each.  This would
> > allow the reader to make their own decision about what type of
> > deployment would meet their requirements.
> >
> > I'm working on writing up some details in this area, so I'd be happy to
> > submit some patches for this chapter of the Security Guide.
>
> I've published a blog post based on my research of this topic:
>
>   https://blog-nkinder.rhcloud.com/?p=7
>
> I'd like to use this as a basis for improving the Security Guide, but
> I'd love to get some feedback from others first.  Any comments would be
> much appreciated!
>
> Thanks,
> -NGK
>
> >
> > -NGK
> >
> >>
> >> My two cents,
> >> -bryan
> >>
> >>
> >>
> >> On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder <nkinder at redhat.com
> >> <mailto:nkinder at redhat.com>> wrote:
> >>
> >>     Hi,
> >>
> >>     The Security Guide currently recommends that SSL/TLS be used to
> protect
> >>     the API endpoints (as it should).  We specifically mention that SSL
> >>     proxies should be used for this, as opposed to configuring SSL
> natively
> >>     in the services themselves:
> >>
> >>
> >>
> http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html
> >>
> >>     Is there any particular reason why we don't recommend configuring
> >>     SSL/TLS natively in the services?  It seems like that would be an
> ideal
> >>     approach, as it eliminates the need for running proxies.  It also
> keeps
> >>     access to the unencrypted traffic closer to the actual services that
> >>     need to access it, which is better from a security standpoint.
> >>
> >>     I'm not sure that all of the integrated projects actually have
> working
> >>     native SSL/TLS support, but I know that a number of them claim to
> have
> >>     support.  Shouldn't native support be the preferred recommendation
> from
> >>     a security standpoint?
> >>
> >>     Thanks,
> >>     -NGK
> >>
> >>     _______________________________________________
> >>     Openstack-security mailing list
> >>     Openstack-security at lists.openstack.org
> >>     <mailto:Openstack-security at lists.openstack.org>
> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> >>
> >>
> >
> >
> > _______________________________________________
> > Openstack-security mailing list
> > Openstack-security at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140403/741531b7/attachment.html>

From gerrit2 at review.openstack.org  Thu Apr  3 21:38:10 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 03 Apr 2014 21:38:10 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WVpKs-00011b-9q@review.openstack.org>


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

Log:
commit e2156a1ade245f947ba4a418962b8c3ca87ff389
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Mar 13 15:38:34 2014 -0500

    Allow hash tokens with sha256
    
    PKI Tokens were always hashed with MD5. This change allows
    tokens to be hashed with SHA256 or any other algorithm
    supported by hashlib. This is for security hardening.
    
    If the new 'hash_algorithm' configuration option is set to
    'sha256' then the auth_token middleware will hash tokens using
    SHA256 when tokens are stored in the cache. The
    'hash_algorithm' option defaults to 'md5' for backwards
    compatiblity.
    
    The auth_token middleware will also accept a new format for
    the revocation list. If the revocation list has the
    'hash_algorithm' field set then that algorithm will be used to
    hash the PKI token to compare against the IDs in the
    revocation list. If the revocation list doesn't have the
    'hash_algorithm' field set then MD5 will be used for backwards
    compatibility.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Thu Apr  3 22:28:27 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 03 Apr 2014 22:28:27 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Iafe3c975d59818c8f362647f7ea5149a03deee47
Message-ID: <E1WVq7X-00065E-Us@review.openstack.org>


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

Log:
commit 41a448f8b2ca0052b528186253310d5cefb2c7f7
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Mar 27 19:10:10 2014 -0500

    Configurable token hash algorithm
    
    Tokens were always hashed with MD5. This change allows tokens to
    be hashed with SHA256 (or any other algorithm supported by the
    keystoneclient token hash function). This is for security
    hardening.
    
    There's a new configuration option 'hash_algorithm' in the [token]
    section. This is the algorithm to use for hashing tokens for the
    revocation list. If this is not set then MD5 is used. If it's set to
    a hash algorithm (such as 'sha256'), then PKI tokens will be hashed
    using that algorithm. Also, the configured hash algorithm is now
    set on the revocation list object for use by the auth_token
    middleware.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47




From gerrit2 at review.openstack.org  Thu Apr  3 22:37:50 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 03 Apr 2014 22:37:50 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Iafe3c975d59818c8f362647f7ea5149a03deee47
Message-ID: <E1WVqGc-00071l-6g@review.openstack.org>


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

Log:
commit 423ba8b9d8788041877c5d8fd089090646760c7c
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Mar 27 19:10:10 2014 -0500

    Configurable token hash algorithm
    
    Tokens were always hashed with MD5. This change allows tokens to
    be hashed with SHA256 (or any other algorithm supported by the
    keystoneclient token hash function). This is for security
    hardening.
    
    There's a new configuration option 'hash_algorithm' in the [token]
    section. This is the algorithm to use for hashing PKI tokens, so is
    used
    
     a) when storing the token in the db
     b) as the hash in the revocation list
    
    hash_algorithm defaults to 'md5' for backwards compatibility, and
    can be set to any hash algorithm that keystoneclient supports
    (such as 'sha256').
    
    The hash algorithm is set on the revocation list object for use
    by the auth_token middleware.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47




From 1188189 at bugs.launchpad.net  Thu Apr  3 22:33:38 2014
From: 1188189 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 03 Apr 2014 22:33:38 -0000
Subject: [Openstack-security] [Bug 1188189] Fix merged to neutron (master)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20140403223338.25889.89386.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/77414
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=264b4a2523c165640f17aa4837f87ddfd0b49640
Submitter: Jenkins
Branch:    master

commit 264b4a2523c165640f17aa4837f87ddfd0b49640
Author: Daniel Gollub <d.gollub at telekom.de>
Date:   Sun Mar 2 09:33:38 2014 +0100

    Replace HTTPSConnection in NEC plugin
    
    Replace HTTPSConnection in NEC plugin PFC driver with Requests.
    
    SSL Verification is from now on enabled by default.
    
    This changes the default behaviour and is the primary intention of this
    change: verify SSL certificates.
    
    This might break existing configuration/setups where the SSL certificate
    used by the NEC PFC driver would not pass the verification.
    
    SecurityImpact
    DocImpact
    Partial-Bug: 1188189
    
    Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337

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

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Python client library for Keystone:
  Fix Released
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

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



From gerrit2 at review.openstack.org  Fri Apr  4 00:07:04 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 04 Apr 2014 00:07:04 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Iafe3c975d59818c8f362647f7ea5149a03deee47
Message-ID: <E1WVrey-0006AI-8S@review.openstack.org>


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

Log:
commit 893e048b2eb9cddea9a64396bf2c80cb56711845
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Mar 27 19:10:10 2014 -0500

    Configurable token hash algorithm
    
    Tokens were always hashed with MD5. This change allows tokens to
    be hashed with SHA256 (or any other algorithm supported by the
    keystoneclient token hash function). This is for security
    hardening.
    
    There's a new configuration option 'hash_algorithm' in the [token]
    section. This is the algorithm to use for hashing PKI tokens, so is
    used
    
     a) when storing the token in the db
     b) as the hash in the revocation list
    
    hash_algorithm defaults to 'md5' for backwards compatibility, and
    can be set to any hash algorithm that keystoneclient supports
    (such as 'sha256').
    
    The hash algorithm is set on the revocation list object for use
    by the auth_token middleware.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47




From 1262759 at bugs.launchpad.net  Fri Apr  4 00:11:48 2014
From: 1262759 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 04 Apr 2014 00:11:48 -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: <20140404001148.17721.54773.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/72252
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=b7b0c7dbcd3e6754bc09b2fd75d888c41ae4aadb
Submitter: Jenkins
Branch:    master

commit b7b0c7dbcd3e6754bc09b2fd75d888c41ae4aadb
Author: Xuhan Peng <xuhanp at cn.ibm.com>
Date:   Sun Feb 9 22:02:33 2014 -0500

    Permit ICMPv6 RAs only from known routers
    
    Currently ingress ICMPv6 RAs are permitted from any IPs by
    default to allow VMs to accept ICMPv6 RA from provider network.
    In this way, VM can accept RAs from attacker VM and configure
    a network prefix specified by the attacher VM.
    
    Remove permitting ICMPv6 RAs from any IPs and add security rule
    to only permit ICMPv6 RA from:
    
    1. If the port's subnet is configured with ipv6_ra_mode value
    (i.e.value is slaac, dhcpv6-stateful, or dhcpv6-stateless), RA
    is sending from dnsmasq controlled by OpenStack. In this case,
    allow RA from the link local address of gateway port (if the
    gateway port is created).
    
    2. If the subnet's gateway port is not managed by OpenStack, allow
    the ICMPv6 RA sent from the subnet gateway IP if it's a link local
    address. The administrator needs to configure the gateway IP as
    link local address in this case to make the RA rule work.
    
    Change-Id: I1d5c7aaa8e4cf057204eb746c0faab2c70409a94
    Closes-Bug: 1262759


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

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

Title:
  ICMPv6 RAs should only be permitted from known routers

Status in OpenStack Neutron (virtual network service):
  Fix Committed
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 gerrit2 at review.openstack.org  Fri Apr  4 01:19:59 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 04 Apr 2014 01:19:59 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WVsnX-000406-L0@review.openstack.org>


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

Log:
commit a3db0516c136767e493e1125e3980f057165a585
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Mar 13 15:38:34 2014 -0500

    Allow hash tokens with sha256
    
    PKI Tokens were always hashed with MD5. This change allows
    tokens to be hashed with SHA256 or any other algorithm
    supported by hashlib. This is for security hardening.
    
    If the new 'hash_algorithm' configuration option is set to
    'sha256' then the auth_token middleware will hash tokens using
    SHA256 when tokens are stored in the cache. The
    'hash_algorithm' option defaults to 'md5' for backwards
    compatiblity.
    
    The auth_token middleware will also accept a new format for
    the revocation list. If the revocation list has the
    'hash_algorithm' field set then that algorithm will be used to
    hash the PKI token to compare against the IDs in the
    revocation list. If the revocation list doesn't have the
    'hash_algorithm' field set then MD5 will be used for backwards
    compatibility.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From thierry.carrez+lp at gmail.com  Fri Apr  4 12:52:57 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Fri, 04 Apr 2014 12:52:57 -0000
Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails
 to prevent ip netns exec
References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com>
Message-ID: <20140404125300.8703.15566.launchpad@gac.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/1081795

Title:
  oslo.rootwrap IpFilter fails to prevent ip netns exec

Status in Oslo - a Library of Common OpenStack Code:
  Fix Released

Bug description:
  This is an oslo.rootwrap bug.

  IpFilter is designed to allow any ip command, unless the second
  parameter is "netns" (in which case you only allow ip netns
  {list,add,delete}.

  The trick is it's trivial to work around this (just run 'ip -s netns
  exec').

  Once that's fixed, Nova should update from using a CommandFilter to
  using the IpFilter for calling 'ip'.

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



From gerrit2 at review.openstack.org  Fri Apr  4 19:52:43 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 04 Apr 2014 19:52:43 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1WWAAN-0002V1-01@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 b81dbdf77b915ee9bdeb610dad1c4f94c1161953
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 Apr  4 19:58:39 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 04 Apr 2014 19:58:39 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1WWAG7-0003VT-D4@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 8eca5128b9dcd7786a3a10780e66cd68b323ae5f
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 priti_desai at symantec.com  Fri Apr  4 19:18:09 2014
From: priti_desai at symantec.com (Priti Desai)
Date: Fri, 04 Apr 2014 19:18:09 -0000
Subject: [Openstack-security] [Bug 1299039] Re: Token Scoping
References: <20140328144343.5612.44045.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140404191811.17829.22307.launchpad@chaenomeles.canonical.com>

** Changed in: keystone
     Assignee: (unassigned) => Priti Desai (priti-desai)

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

Title:
  Token Scoping

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  In Havana Stable release for both V2.0 an V3,

  A scoped token can be used to get another scoped or un-scopped token.
  This can be exploited by anyone who has gained access to  a scoped
  token.

  For example,

  1. userA is related to two projects: Project1, Project2
  2. userA creates  tokenA scoped by Project1
  3.  userA  shares the tokenA to a third party (malicious).  
  4. Third party can now make a token creation call to create a new tokenB scoped under projectB using tokenA.

  Although, we know that bearer token has all or nothing property, scoping the token can limit the exposure. 
  A scoped token should not be allowed to create another scoped token.

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



From gerrit2 at review.openstack.org  Fri Apr  4 20:09:47 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 04 Apr 2014 20:09:47 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337
Message-ID: <E1WWAQt-00052J-9e@review.openstack.org>


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

Log:
commit 8fd51240983f4c2ff2a73d907ccb1c597bd5d835
Author: Daniel Gollub <d.gollub at telekom.de>
Date:   Sun Mar 2 09:33:38 2014 +0100

    Replace HTTPSConnection in NEC plugin
    
    Replace HTTPSConnection in NEC plugin PFC driver with Requests.
    
    SSL Verification is from now on enabled by default.
    
    This changes the default behaviour and is the primary intention of this
    change: verify SSL certificates.
    
    This might break existing configuration/setups where the SSL certificate
    used by the NEC PFC driver would not pass the verification.
    
    SecurityImpact
    DocImpact
    Partial-Bug: 1188189
    
    Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337
    (cherry picked from commit 264b4a2523c165640f17aa4837f87ddfd0b49640)




From 1188189 at bugs.launchpad.net  Fri Apr  4 20:09:41 2014
From: 1188189 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 04 Apr 2014 20:09:41 -0000
Subject: [Openstack-security] [Bug 1188189] Fix proposed to neutron
	(milestone-proposed)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20140404200941.17279.86544.malone@chaenomeles.canonical.com>

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/85470

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

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Python client library for Keystone:
  Fix Released
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

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



From 1262759 at bugs.launchpad.net  Fri Apr  4 22:17:43 2014
From: 1262759 at bugs.launchpad.net (Mark McClain)
Date: Fri, 04 Apr 2014 22:17:43 -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: <20140404221746.8807.69160.launchpad@gac.canonical.com>

** Changed in: neutron
    Milestone: None => juno-1

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

Title:
  ICMPv6 RAs should only be permitted from known routers

Status in OpenStack Neutron (virtual network service):
  Fix Committed
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 1188189 at bugs.launchpad.net  Fri Apr  4 22:45:38 2014
From: 1188189 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 04 Apr 2014 22:45:38 -0000
Subject: [Openstack-security] [Bug 1188189] Fix merged to neutron
	(milestone-proposed)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20140404224538.8540.77871.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/85470
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8fd51240983f4c2ff2a73d907ccb1c597bd5d835
Submitter: Jenkins
Branch:    milestone-proposed

commit 8fd51240983f4c2ff2a73d907ccb1c597bd5d835
Author: Daniel Gollub <d.gollub at telekom.de>
Date:   Sun Mar 2 09:33:38 2014 +0100

    Replace HTTPSConnection in NEC plugin
    
    Replace HTTPSConnection in NEC plugin PFC driver with Requests.
    
    SSL Verification is from now on enabled by default.
    
    This changes the default behaviour and is the primary intention of this
    change: verify SSL certificates.
    
    This might break existing configuration/setups where the SSL certificate
    used by the NEC PFC driver would not pass the verification.
    
    SecurityImpact
    DocImpact
    Partial-Bug: 1188189
    
    Change-Id: I1e5fdc9c2ed5b812aa6509d1639bd499acc5c337
    (cherry picked from commit 264b4a2523c165640f17aa4837f87ddfd0b49640)

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

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Python client library for Keystone:
  Fix Released
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

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



From malini.k.bhandaru at intel.com  Sat Apr  5 01:11:26 2014
From: malini.k.bhandaru at intel.com (Malini Bhandaru)
Date: Sat, 05 Apr 2014 01:11:26 -0000
Subject: [Openstack-security] [Bug 1299039] Re: Token Scoping
References: <20140328144343.5612.44045.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140405011127.7042.31903.malone@wampee.canonical.com>

Seems like horizon login page should take as input a "scope",  domain (and even project possibly) to avoid such an issue.
Users are supposed to be unique per domain.

Then we could enforce any subsequent token creation to the domain and
project of the current token. So no more or less harm than the token
already leaked.

Further, we could limit horizon admin uses to only "read-only" on other
domains/projects.

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

Title:
  Token Scoping

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  In Havana Stable release for both V2.0 an V3,

  A scoped token can be used to get another scoped or un-scopped token.
  This can be exploited by anyone who has gained access to  a scoped
  token.

  For example,

  1. userA is related to two projects: Project1, Project2
  2. userA creates  tokenA scoped by Project1
  3.  userA  shares the tokenA to a third party (malicious).  
  4. Third party can now make a token creation call to create a new tokenB scoped under projectB using tokenA.

  Although, we know that bearer token has all or nothing property, scoping the token can limit the exposure. 
  A scoped token should not be allowed to create another scoped token.

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



From d.w.chadwick at kent.ac.uk  Sat Apr  5 06:00:48 2014
From: d.w.chadwick at kent.ac.uk (David Chadwick)
Date: Sat, 05 Apr 2014 07:00:48 +0100
Subject: [Openstack-security] [Bug 1299039] Re: Token Scoping
In-Reply-To: <20140405011127.7042.31903.malone@wampee.canonical.com>
References: <20140328144343.5612.44045.malonedeb@chaenomeles.canonical.com>
 <20140405011127.7042.31903.malone@wampee.canonical.com>
Message-ID: <533F9C10.2080402@kent.ac.uk>

I dont think this is anything to do with a user interface issue. I think
it is a design bug in Keystone. I think the flow in Keystone should be
more like this:

1. User logs in, gets an unscoped token
2. User switches unscoped token for any scoped token of his choice. This
is a downgrading of privileges.
3. User switches from a scoped token to an unscoped token. This is an
escalation of privileges, so should require re-authentication
4. User can now switch his/her unscoped token to any scoped token

regards

David

On 05/04/2014 02:11, Malini Bhandaru wrote:
> Seems like horizon login page should take as input a "scope",  domain (and even project possibly) to avoid such an issue.
> Users are supposed to be unique per domain.
> 
> Then we could enforce any subsequent token creation to the domain and
> project of the current token. So no more or less harm than the token
> already leaked.
> 
> Further, we could limit horizon admin uses to only "read-only" on other
> domains/projects.
> 



From gerrit2 at review.openstack.org  Mon Apr  7 00:04:29 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 07 Apr 2014 00:04:29 +0000
Subject: [Openstack-security] [stackforge/kite] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1WWx37-0005K3-La@review.openstack.org>


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

Log:
commit d014152422993bb6d88458e05a2de1a80fc21bce
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.
    
    Add some routes to allow setting a key through the storage interface.
    
    SecurityImpact
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Mon Apr  7 00:04:39 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 07 Apr 2014 00:04:39 +0000
Subject: [Openstack-security] [stackforge/kite] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1WWx3H-0005Mq-HG@review.openstack.org>


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

Log:
commit 77b042f2243ebce8b70e361bd39b6082f51d96d3
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
    Change-Id: I4dbd23adb0bdd9011eb9a0b45e30dd862d390473




From gerrit2 at review.openstack.org  Mon Apr  7 06:01:00 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 07 Apr 2014 06:01:00 +0000
Subject: [Openstack-security] [stackforge/kite] SecurityImpact review
 request change Id8acb8fae0f0908a2bade4f227cd1a181b0075de
Message-ID: <E1WX2c8-0003aK-PT@review.openstack.org>


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

Log:
commit b4cd17b7a908c15c2eb7dd810261c330465a6a19
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.
    
    Add some routes to allow setting a key through the storage interface.
    
    SecurityImpact
    Change-Id: Id8acb8fae0f0908a2bade4f227cd1a181b0075de




From gerrit2 at review.openstack.org  Mon Apr  7 06:05:54 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 07 Apr 2014 06:05:54 +0000
Subject: [Openstack-security] [stackforge/kite] SecurityImpact review
 request change I4dbd23adb0bdd9011eb9a0b45e30dd862d390473
Message-ID: <E1WX2gs-0004HI-5L@review.openstack.org>


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

Log:
commit 361781c75c333e685c5b8ea813bed19c7a430d28
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
    Change-Id: I4dbd23adb0bdd9011eb9a0b45e30dd862d390473




From thierry.carrez+lp at gmail.com  Mon Apr  7 14:34:13 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 07 Apr 2014 14:34:13 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140407143415.8839.38894.launchpad@gac.canonical.com>

** Changed in: ossa
   Importance: Undecided => Medium

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

** Also affects: keystone/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/1300274

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  New
Status in OpenStack Security Advisories:
  Confirmed

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From thierry.carrez+lp at gmail.com  Mon Apr  7 15:23:15 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 07 Apr 2014 15:23:15 -0000
Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method
	chaining
References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140407152317.26101.8448.launchpad@soybean.canonical.com>

** Changed in: keystone
    Milestone: icehouse-rc2 => None

** Tags added: icehouse-rc-potential

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

Title:
  V3 api authentication method chaining

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  When using authentication method chaining for token creation (POST)
  in Keystone V3 api , it is possible to use authentication credentials
  for two different users . For example, if i have an existing token for
  a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier
  for demo tenant) and i have a user say 'test131' in admin tenant

  Now i can make an authentication call using auth method chaining

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "token" 
           ],
          "token":{
              "id":"6bb934a0120f097a32b5d3cc71f83beb"
           },
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"test131",
                 "password":"test131"
              }
           }
        }
     }
  }

  The call will succeed even though two different users authentication
  credentials are used.  The generated token will get properties of
  test131 user although the expirary date is set by demo user token.  If
  we change the methods sequence, the generated token will get all
  properties from demo users token.

  
  This is an undesired security behaviour - token should not  be allowed to generate using credentials from two different users.

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



From tristan.cacqueray at enovance.com  Mon Apr  7 16:03:39 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Mon, 07 Apr 2014 16:03:39 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140407160339.7202.14240.malone@wampee.canonical.com>

Impact description draft #1:

Title: Keystone DoS through V3 API authentication chaining
Reporter: Abu Shohel Ahmed (Ericsson)
Products: Keystone
Versions: 2013.2 versions up to 2013.2.3

Description:
Abu Shohel Ahmed from Ericsson reported a vulnerability in Keystone V3 API authentication. By sending a single request with the same authentication method multiple times, a remote attacker may generate unwanted load on the Keystone host, potentially resulting in a Denial of Service against a Keystone service. Only Keystone setups enabling V3 API are affected.

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  New
Status in OpenStack Security Advisories:
  Confirmed

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From 1300274 at bugs.launchpad.net  Mon Apr  7 23:03:26 2014
From: 1300274 at bugs.launchpad.net (Dolph Mathews)
Date: Mon, 07 Apr 2014 23:03:26 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140407230326.17444.99234.malone@chaenomeles.canonical.com>

I could be mistaken, but I believe 2013.1 would be affected as well.
(please correct me if that's not true!)

+1 for the description itself

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  New
Status in OpenStack Security Advisories:
  Confirmed

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From thierry.carrez+lp at gmail.com  Tue Apr  8 10:18:17 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Tue, 08 Apr 2014 10:18:17 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140408101817.8932.18404.malone@gac.canonical.com>

Description: +1 -- please doublecheck affected versions as Dolph said

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  New
Status in OpenStack Security Advisories:
  Confirmed

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From florent.flament-ext at cloudwatt.com  Tue Apr  8 11:40:17 2014
From: florent.flament-ext at cloudwatt.com (Florent Flament)
Date: Tue, 08 Apr 2014 11:40:17 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140408114020.7009.91053.launchpad@wampee.canonical.com>

** Changed in: keystone/havana
     Assignee: (unassigned) => Florent Flament (florent-flament-ext)

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  New
Status in OpenStack Security Advisories:
  Confirmed

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From 1300274 at bugs.launchpad.net  Tue Apr  8 13:00:33 2014
From: 1300274 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 08 Apr 2014 13:00:33 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140408130034.8482.58807.malone@gac.canonical.com>

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/86024

** Changed in: keystone/havana
       Status: New => In Progress

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  In Progress
Status in OpenStack Security Advisories:
  Confirmed

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From tristan.cacqueray at enovance.com  Tue Apr  8 13:38:29 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Tue, 08 Apr 2014 13:38:29 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140408133830.17093.11657.malone@chaenomeles.canonical.com>

@Dolph yes you are right, my bad I forget to include it in the affected
version line.

I think 9f812939 introduced this bug and "git tag --contains" says it
get merged for 2013.1.

Update impact description draft #2:

Title: Keystone DoS through V3 API authentication chaining
Reporter: Abu Shohel Ahmed (Ericsson)
Products: Keystone
Versions: 2013.1 versions up to 2013.2.3

Description:
Abu Shohel Ahmed from Ericsson reported a vulnerability in Keystone V3 API authentication. By sending a single request with the same authentication method multiple times, a remote attacker may generate unwanted load on the Keystone host, potentially resulting in a Denial of Service against a Keystone service. Only Keystone setups enabling V3 API are affected.

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  In Progress
Status in OpenStack Security Advisories:
  Confirmed

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From tristan.cacqueray at enovance.com  Tue Apr  8 15:08:49 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Tue, 08 Apr 2014 15:08:49 -0000
Subject: [Openstack-security] [Bug 1289033] Re: XSS in Horizon-Orchestration
	(CVE-2014-0157)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140408150850.9284.54120.launchpad@gac.canonical.com>

** Information type changed from Private Security to Public 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/1289033

Title:
  XSS in Horizon-Orchestration (CVE-2014-0157)

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Dashboard (Horizon) havana series:
  In Progress
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From 1289033 at bugs.launchpad.net  Tue Apr  8 15:14:05 2014
From: 1289033 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 08 Apr 2014 15:14:05 -0000
Subject: [Openstack-security] [Bug 1289033] Re: XSS in Horizon-Orchestration
	(CVE-2014-0157)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140408151405.8839.7816.malone@gac.canonical.com>

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/86056

** Changed in: horizon/havana
       Status: New => In Progress

** Changed in: horizon/havana
     Assignee: (unassigned) => Akihiro Motoki (amotoki)

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

Title:
  XSS in Horizon-Orchestration (CVE-2014-0157)

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Dashboard (Horizon) havana series:
  In Progress
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From 1174499 at bugs.launchpad.net  Tue Apr  8 15:23:59 2014
From: 1174499 at bugs.launchpad.net (Dolph Mathews)
Date: Tue, 08 Apr 2014 15:23:59 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140408152400.17758.67098.launchpad@chaenomeles.canonical.com>

** Also affects: openstack-api-site
   Importance: Undecided
       Status: New

** Changed in: openstack-api-site
       Status: New => Confirmed

** Tags added: identity-api

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

Title:
  Keystone token hashing is MD5

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

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



From tristan.cacqueray at enovance.com  Tue Apr  8 15:54:17 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Tue, 08 Apr 2014 15:54:17 -0000
Subject: [Openstack-security] [Bug 1289033] Re: [OSSA-2014-010] XSS in
 Horizon-Orchestration (CVE-2014-0157)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140408155418.25738.58355.launchpad@soybean.canonical.com>

** Summary changed:

- XSS in Horizon-Orchestration (CVE-2014-0157)
+ [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157)

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

Title:
  [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157)

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Dashboard (Horizon) havana series:
  In Progress
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From david.lyle at hp.com  Tue Apr  8 16:02:05 2014
From: david.lyle at hp.com (David Lyle)
Date: Tue, 08 Apr 2014 16:02:05 -0000
Subject: [Openstack-security] [Bug 1289033] Re: [OSSA-2014-010] XSS in
 Horizon-Orchestration (CVE-2014-0157)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140408160208.6871.52367.launchpad@wampee.canonical.com>

** Changed in: horizon/havana
   Importance: Undecided => High

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

Title:
  [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157)

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Dashboard (Horizon) havana series:
  In Progress
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From fungi at yuggoth.org  Tue Apr  8 16:49:40 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 08 Apr 2014 16:49:40 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140408164940.17758.96208.malone@chaenomeles.canonical.com>

Following our current template in the wiki this would more properly be
expressed as...

Versions: from 2013.1 to 2013.2.3

Otherwise Tristan's latest impact description looks great.

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  In Progress
Status in OpenStack Security Advisories:
  Confirmed

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From 1289033 at bugs.launchpad.net  Tue Apr  8 18:52:11 2014
From: 1289033 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 08 Apr 2014 18:52:11 -0000
Subject: [Openstack-security] [Bug 1289033] Re: [OSSA-2014-010] XSS in
 Horizon-Orchestration (CVE-2014-0157)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140408185211.8703.14718.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/86059
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=198dba6a2d92b8157b86285f5b0cb000e64ae7ac
Submitter: Jenkins
Branch:    master

commit 198dba6a2d92b8157b86285f5b0cb000e64ae7ac
Author: CristianFiorentino <cristian.fiorentino at intel.com>
Date:   Mon Mar 10 17:36:31 2014 -0300

    Introduces escaping in Horizon/Orchestration
    
    1) Escape help_text a second time to avoid bootstrap tooltip XSS issue
    
    The "Description" parameter in a Heat template is used to populate
    a help_text tooltip in the dynamically generated Heat form. Bootstrap
    inserts this tooltip into the DOM using .html() which undoes any
    escaping we do in Django (it should be using .text()).
    
    This was fixed by forcing the help_text content to be escaped a second
    time. The issue itself is mitigated in bootstrap.js release 2.0.3
    (ours is currently 2.0.1).
    
    2) Properly escape untrusted Heat template 'outputs'
    
    The 'outputs' parameter in a Heat template was included in a Django
    template with HTML autoescaping turned off. Malicious HTML content
    could be included in a Heat template and would be rendered by Horizon
    when details about a created stack were displayed.
    
    This was fixed by not disabling autoescaping and explicitly escaping
    untrusted values in any strings that are later marked "safe" to render
    without further escaping.
    
    Change-Id: Icd9f9d9ca77068b12227d77469773a325c840001
    Closes-Bug: #1289033
    Co-Authored-By: Kieran Spear <kispear at gmail.com>


** Changed in: horizon
       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/1289033

Title:
  [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157)

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Dashboard (Horizon) havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From 1289033 at bugs.launchpad.net  Tue Apr  8 18:57:19 2014
From: 1289033 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 08 Apr 2014 18:57:19 -0000
Subject: [Openstack-security] [Bug 1289033] Re: [OSSA-2014-010] XSS in
 Horizon-Orchestration (CVE-2014-0157)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140408185719.7042.54847.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/86054
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=1b0106e2804a45e641433c4bd459e6bed85521c3
Submitter: Jenkins
Branch:    milestone-proposed

commit 1b0106e2804a45e641433c4bd459e6bed85521c3
Author: CristianFiorentino <cristian.fiorentino at intel.com>
Date:   Mon Mar 10 17:36:31 2014 -0300

    Introduces escaping in Horizon/Orchestration
    
    1) Escape help_text a second time to avoid bootstrap tooltip XSS issue
    
    The "Description" parameter in a Heat template is used to populate
    a help_text tooltip in the dynamically generated Heat form. Bootstrap
    inserts this tooltip into the DOM using .html() which undoes any
    escaping we do in Django (it should be using .text()).
    
    This was fixed by forcing the help_text content to be escaped a second
    time. The issue itself is mitigated in bootstrap.js release 2.0.3
    (ours is currently 2.0.1).
    
    2) Properly escape untrusted Heat template 'outputs'
    
    The 'outputs' parameter in a Heat template was included in a Django
    template with HTML autoescaping turned off. Malicious HTML content
    could be included in a Heat template and would be rendered by Horizon
    when details about a created stack were displayed.
    
    This was fixed by not disabling autoescaping and explicitly escaping
    untrusted values in any strings that are later marked "safe" to render
    without further escaping.
    
    Change-Id: Icd9f9d9ca77068b12227d77469773a325c840001
    Closes-Bug: #1289033
    Co-Authored-By: Kieran Spear <kispear at gmail.com>


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

** Changed in: horizon/havana
       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/1289033

Title:
  [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157)

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Dashboard (Horizon) havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From 1289033 at bugs.launchpad.net  Tue Apr  8 18:57:28 2014
From: 1289033 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 08 Apr 2014 18:57:28 -0000
Subject: [Openstack-security] [Bug 1289033] Fix merged to horizon
	(stable/havana)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140408185728.7073.63691.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/86056
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=54ec015f720a4379e8ffc34345b3a7bf36b6f15b
Submitter: Jenkins
Branch:    stable/havana

commit 54ec015f720a4379e8ffc34345b3a7bf36b6f15b
Author: CristianFiorentino <cristian.fiorentino at intel.com>
Date:   Mon Mar 10 17:36:31 2014 -0300

    Introduces escaping in Horizon/Orchestration
    
    1) Escape help_text a second time to avoid bootstrap tooltip XSS issue
    
    The "Description" parameter in a Heat template is used to populate
    a help_text tooltip in the dynamically generated Heat form. Bootstrap
    inserts this tooltip into the DOM using .html() which undoes any
    escaping we do in Django (it should be using .text()).
    
    This was fixed by forcing the help_text content to be escaped a second
    time. The issue itself is mitigated in bootstrap.js release 2.0.3
    (ours is currently 2.0.1).
    
    2) Properly escape untrusted Heat template 'outputs'
    
    The 'outputs' parameter in a Heat template was included in a Django
    template with HTML autoescaping turned off. Malicious HTML content
    could be included in a Heat template and would be rendered by Horizon
    when details about a created stack were displayed.
    
    This was fixed by not disabling autoescaping and explicitly escaping
    untrusted values in any strings that are later marked "safe" to render
    without further escaping.
    
    Conflicts:
    	openstack_dashboard/dashboards/project/stacks/mappings.py
    
    Change-Id: Icd9f9d9ca77068b12227d77469773a325c840001
    Closes-Bug: #1289033
    Co-Authored-By: Kieran Spear <kispear at gmail.com>

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

Title:
  [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157)

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Dashboard (Horizon) havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From malini.k.bhandaru at intel.com  Tue Apr  8 17:01:24 2014
From: malini.k.bhandaru at intel.com (Bhandaru, Malini K)
Date: Tue, 8 Apr 2014 17:01:24 +0000
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
Message-ID: <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>



From: Ryan Ware [mailto:ryan.r.ware at intel.com]
Sent: Tuesday, April 08, 2014 7:11 AM
To: OTC ALL
Subject: OpenSSL Heartblead (CVE-2014-0160)

I wanted to take a moment and make sure everyone knows about this critical security vulnerability.  While system administrators in OTC (and outside) already know about this, I also know that people have many side projects and personal infrastructure as well.

The comment with the OpenSSL patch that fixes this issue can be found here (https://www.openssl.org/news/secadv_20140407.txt) but since it's short I'll reproduce it as well:


OpenSSL Security Advisory [07 Apr 2014]

========================================



TLS heartbeat read overrun (CVE-2014-0160)

==========================================



A missing bounds check in the handling of the TLS heartbeat extension can be

used to reveal up to 64k of memory to a connected client or server.



Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including

1.0.1f and 1.0.2-beta1.



Thanks for Neel Mehta of Google Security for discovering this bug and to

Adam Langley <agl at chromium.org<mailto:agl at chromium.org>> and Bodo Moeller <bmoeller at acm.org<mailto:bmoeller at acm.org>> for

preparing the fix.



Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately

upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.



1.0.2 will be fixed in 1.0.2-beta2.

Note that it is remotely exploitable and you will not find anything in your logs indicating you were attacked.  If you were previously attacked, it is very possible that private keys, passwords or anything else in the server process' memory space could have been leaked so you probably have more remediation to do (generate new keys, passwords, etc.) than just patch.

There is a decent article here (http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens-two-thirds-of-the-web-to-eavesdropping/) with more info.  There is also known exploit code in the wild such as here (http://s3.jspenguin.org/ssltest.py).  There is also more information here (http://heartbleed.com/).

Please take this vulnerability seriously.  This is the most significant CVE I've seen in a long time.

Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140408/4e8b6754/attachment.html>

From robert.clark at hp.com  Tue Apr  8 19:32:33 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 8 Apr 2014 19:32:33 +0000
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
Message-ID: <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>

Thanks Malini, excellent summary.

It’s worth re-iterating this point from the email below: Any secrets that you have previously communicated, API keys, passwords, credentials should be considered compromised.

A second important point that isn’t being that widely discussed is the possibility that certificates and keys have been stolen and can be used to impersonate TLS servers. Now these certificates can be revoked, but that doesn’t buy you much outside of the browser, support for CRL’s is spotty in system crypto APIs (and you almost certainly haven’t downloaded them) and OCSP is basically non-existent for most client libraries.

--
Robert Clark
Lead Security Architect
HP Converged Cloud


On 8 April 2014 at 12:17:37, Bhandaru, Malini K (malini.k.bhandaru at intel.com<mailto:malini.k.bhandaru at intel.com>) wrote:


From: Ryan Ware [mailto:ryan.r.ware at intel.com]
Sent: Tuesday, April 08, 2014 7:11 AM
To: OTC ALL
Subject: OpenSSL Heartblead (CVE-2014-0160)

I wanted to take a moment and make sure everyone knows about this critical security vulnerability.  While system administrators in OTC (and outside) already know about this, I also know that people have many side projects and personal infrastructure as well.

The comment with the OpenSSL patch that fixes this issue can be found here (https://www.openssl.org/news/secadv_20140407.txt) but since it's short I'll reproduce it as well:


OpenSSL Security Advisory [07 Apr 2014]


========================================





TLS heartbeat read overrun (CVE-2014-0160)


==========================================





A missing bounds check in the handling of the TLS heartbeat extension can be


used to reveal up to 64k of memory to a connected client or server.





Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including


1.0.1f and 1.0.2-beta1.





Thanks for Neel Mehta of Google Security for discovering this bug and to


Adam Langley <agl at chromium.org<mailto:agl at chromium.org>> and Bodo Moeller <bmoeller at acm.org<mailto:bmoeller at acm.org>> for


preparing the fix.





Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately


upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.





1.0.2 will be fixed in 1.0.2-beta2.


Note that it is remotely exploitable and you will not find anything in your logs indicating you were attacked.  If you were previously attacked, it is very possible that private keys, passwords or anything else in the server process' memory space could have been leaked so you probably have more remediation to do (generate new keys, passwords, etc.) than just patch.

There is a decent article here (http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens-two-thirds-of-the-web-to-eavesdropping/) with more info.  There is also known exploit code in the wild such as here (http://s3.jspenguin.org/ssltest.py).  There is also more information here (http://heartbleed.com/).

Please take this vulnerability seriously.  This is the most significant CVE I've seen in a long time.

Ryan

From noloader at gmail.com  Tue Apr  8 20:07:19 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 8 Apr 2014 16:07:19 -0400
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
 <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>
Message-ID: <CAH8yC8kMxkZc1gDbFPz94in-5ashYfDzFmduE8B7ebpCqXSodQ@mail.gmail.com>

On Tue, Apr 8, 2014 at 3:32 PM, Clark, Robert Graham
<robert.clark at hp.com> wrote:
> Thanks Malini, excellent summary.
>
> It’s worth re-iterating this point from the email below: Any secrets that you have previously communicated, API keys, passwords, credentials should be considered compromised.
>
> A second important point that isn’t being that widely discussed is the possibility that certificates and keys have been stolen and can be used to impersonate TLS servers. Now these certificates can be revoked, but that doesn’t buy you much outside of the browser, support for CRL’s is spotty in system crypto APIs (and you almost certainly haven’t downloaded them) and OCSP is basically non-existent for most client libraries.
>
+1

Companies like Google will be OK in the short term because they use
those 30-day certs in many places (while re-certifying the same public
key). Others, not so sure....

Jeff



From 1274034 at bugs.launchpad.net  Tue Apr  8 20:06:50 2014
From: 1274034 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 08 Apr 2014 20:06:50 -0000
Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall
 anti-spoofing does not prevent ARP poisoning
References: <20140129101504.12361.90017.malonedeb@gac.canonical.com>
Message-ID: <20140408200653.17248.50462.launchpad@chaenomeles.canonical.com>

** Changed in: neutron
       Status: Triaged => In Progress

** Changed in: neutron
     Assignee: (unassigned) => Kevin Bringard (kbringard)

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

Title:
  Neutron firewall anti-spoofing does not prevent ARP poisoning

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

Bug description:
  The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning.
  When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature:
  - no-mac-spoofing
  - no-ip-spoofing
  - no-arp-spoofing
  - nova-no-nd-reflection
  - allow-dhcp-server

  Actually, the neutron firewall driver 'iptabes_firawall' handles only
  MAC and IP anti-spoofing rules.

  This is a security vulnerability, especially on shared networks.

  Reproduce an ARP cache poisoning and man in the middle:
  - Create a private network/subnet 10.0.0.0/24
  - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4)
  - Log on VM1 and install ettercap [1]
  - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:'
  - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok
  - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2]
  - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1

  [1] http://ettercap.github.io/ettercap/
  [2] http://paste.openstack.org/show/62112/

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



From gerrit2 at review.openstack.org  Tue Apr  8 23:40:42 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 08 Apr 2014 23:40:42 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WXfdC-0005f7-Kl@review.openstack.org>


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

Log:
commit 7287a25d38933fb57f9d3647f6ffb6ee1ee492a8
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Mar 13 15:38:34 2014 -0500

    Support token hash algorithm
    
    PKI Tokens were always hashed with MD5. This change allows
    tokens to be hashed with SHA256 or any other algorithm
    supported by hashlib. This is for security hardening.
    
    If the token metadata contains 'hash_algorithm' then that
    will be used as the hash algorithm. For backwards
    compatibility if the token metadata doesn't contain a
    hash algorithm then MD5 is used.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Tue Apr  8 23:50:42 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 08 Apr 2014 23:50:42 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Iafe3c975d59818c8f362647f7ea5149a03deee47
Message-ID: <E1WXfms-000700-Ar@review.openstack.org>


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

Log:
commit ae4bbf5f5c210463d597c60259216a96a72b98ac
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Mar 27 19:10:10 2014 -0500

    Configurable token hash algorithm
    
    Tokens were always hashed with MD5. This change allows tokens to
    be hashed with SHA256 (or any other algorithm supported by the
    keystoneclient token hash function). This is for security
    hardening.
    
    There's a new configuration option 'hash_algorithm' in the [token]
    section. This is the algorithm to use for hashing PKI tokens, so is
    used
    
     a) when storing the token in the db
     b) as the hash in the revocation list
    
    hash_algorithm defaults to 'md5' for backwards compatibility, and
    can be set to any hash algorithm that keystoneclient supports
    (such as 'sha256').
    
    The hash algorithm is set on the tokens, in the metadata. This is
    so clients can hash the token correctly.
    
    The hash algorithm is also set on the revocation list object for
    use by the auth_token middleware.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47




From gerrit2 at review.openstack.org  Wed Apr  9 00:55:42 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 00:55:42 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ia08c2d6252bb034087a244b47d5bcbea7dcfa70b
Message-ID: <E1WXgnm-0007nr-9t@review.openstack.org>


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

Log:
commit e69d91a946268eeeb0db5ebaa7ce06b86d7e307a
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 19:50:09 2014 -0500

    Hash functions support different hash algorithms
    
    The token hash functions always used MD5. With this change, the
    hash function can be passed in to the hash functions.
    
    SecurityImpact
    Related-Bug: #1174499
    
    Change-Id: Ia08c2d6252bb034087a244b47d5bcbea7dcfa70b




From gerrit2 at review.openstack.org  Wed Apr  9 00:55:48 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 00:55:48 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WXgns-0007p5-R2@review.openstack.org>


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

Log:
commit 5a030ef5b8515b2ea1e64a5d56c8c53dfd3ec64a
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 19:51:49 2014 -0500

    Support token hash algorithm
    
    PKI Tokens were always hashed with MD5. This change allows
    tokens to be hashed with SHA256 or any other algorithm
    supported by hashlib. This is for security hardening.
    
    If the token metadata contains 'hash_algorithm' then that
    will be used as the hash algorithm. For backwards
    compatibility if the token metadata doesn't contain a
    hash algorithm then MD5 is used.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From 1174499 at bugs.launchpad.net  Wed Apr  9 00:55:39 2014
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 09 Apr 2014 00:55:39 -0000
Subject: [Openstack-security] [Bug 1174499] Related fix proposed to
	python-keystoneclient (master)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140409005539.8602.16982.malone@gac.canonical.com>

Related fix proposed to branch: master
Review: https://review.openstack.org/86202

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

Title:
  Keystone token hashing is MD5

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

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



From gerrit2 at review.openstack.org  Wed Apr  9 01:59:56 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 01:59:56 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 I9fe61354103b59dfd292740fbec35e9c6f5ef765
Message-ID: <E1WXhnw-0007S4-1F@review.openstack.org>


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

Log:
commit 77a6ddc665e1dfc629a4034b6bb8094e6188ab98
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with sha256
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256. This
    is for security hardening.
    
    Both SHA256 and MD5 will be tried when checking against the
    revocation list. This will support identity servers that are not
    configured for SHA256.
    
    When storing the PKI token in the local cache, the sha256 hash will
    always be used.
    
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: I9fe61354103b59dfd292740fbec35e9c6f5ef765




From gerrit2 at review.openstack.org  Wed Apr  9 02:00:42 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 02:00:42 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WXhog-0007Z3-SS@review.openstack.org>


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

Log:
commit 99f9effcb51c3a398db0e0631a80ee91b620a4d5
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with sha256
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256. This
    is for security hardening.
    
    Both SHA256 and MD5 will be tried when checking against the
    revocation list. This will support identity servers that are not
    configured for SHA256.
    
    When storing the PKI token in the local cache, the sha256 hash will
    always be used.
    
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From 1174499 at bugs.launchpad.net  Wed Apr  9 01:59:52 2014
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 09 Apr 2014 01:59:52 -0000
Subject: [Openstack-security] [Bug 1174499] Fix proposed to
	python-keystoneclient (master)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140409015952.26378.98141.malone@soybean.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/86206

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

Title:
  Keystone token hashing is MD5

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

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



From masoom.alam at gmail.com  Wed Apr  9 02:14:28 2014
From: masoom.alam at gmail.com (masoom alam)
Date: Wed, 9 Apr 2014 07:14:28 +0500
Subject: [Openstack-security] My Bio for
	https://launchpad.net/~openstack-ossg
Message-ID: <CAPihp9nL2nYiu=XpS1=kYBaXYq0TNaNPzFPW0e0n1K5+iF9Uaw@mail.gmail.com>

Hi Every one,

My name is Masoom Alam and I am the joint director for the Applied Security
Engineering Research Group  (http://aserg.comsats.edu.pk/ or
http://aserg.com.pk/ ) and working as Associate Professor in a university.

Just got a look at video from Robert Clark and Brayn on Openstack security
group delivered at Openstack Summit.

I am a newbie to OpenStack, but have got my hands dirty already with
security stuff especially Security Monitoring through SIEM -- I have been
involved in the development of an Managed Security Service provider, access
control policies specification through XACML and formal verification - this
is my favorite area - see our SACMAT publications ([1] and [2]*)*

Kindly approve my membership at Openstack-OSSG.

Thanks.


*[1]* xDAuth: A Scalable and Lightweight Framework for Cross Domain Access
Control and Delegation* Masoom Alam*, and Zhang, X. and Khan, K.H. and Ali,
G. http://profsandhu.com/zhang/pub/sacmat11-xdauth.pdf

*[2 ] **"** Model based behavior attestation"*   *Masoom Alam*, Xinwen
Zhang, Mohammed Nauman, Tamleek, Jean-Peirrre Seifert*, *at SACMAT 08
*http://portal.acm.org/citation.cfm?id=1377836.1377864&coll=Portal&dl=ACM&type=series&idx=SERIES10694&part=series&WantType=Proceedings&title=SACMAT
<http://portal.acm.org/citation.cfm?id=1377836.1377864&coll=Portal&dl=ACM&type=series&idx=SERIES10694&part=series&WantType=Proceedings&title=SACMAT>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140409/603cdc6b/attachment.html>

From gerrit2 at review.openstack.org  Wed Apr  9 05:37:18 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 05:37:18 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b
Message-ID: <E1WXlCI-0000Hn-4e@review.openstack.org>


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

Log:
commit 6c5ae7bcce79e0c899ab41d196b24a10c30b9ab4
Author: Daniel Gollub <d.gollub at telekom.de>
Date:   Sat Feb 22 21:37:59 2014 +0100

    Replace HTTPSConnection in zadara with Requests
    
    SSL Verification is from now on enabled by default.
    
    This changes the default behaviour and is the primary intention of this
    change: verify SSL certificates.
    
    This might break existing configuration/setups where the SSL certificate
    used by the SAN would not pass the verification.
    
    Old behaviour can be forced by using `san_ssl_insecure=True`.
    
    SecurityImpact
    DocImpact
    Partial-Bug: 1188189
    
    Change-Id: I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b




From gerrit2 at review.openstack.org  Wed Apr  9 06:49:45 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 06:49:45 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b
Message-ID: <E1WXmKP-0002cI-5K@review.openstack.org>


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

Log:
commit eba1dab2450144edfeb8408e0c6d9984322ebf3f
Author: Daniel Gollub <d.gollub at telekom.de>
Date:   Sat Feb 22 21:37:59 2014 +0100

    Replace HTTPSConnection in zadara with Requests
    
    SSL Verification is from now on enabled by default.
    
    This changes the default behaviour and is the primary intention of this
    change: verify SSL certificates.
    
    This might break existing configuration/setups where the SSL certificate
    used by the SAN would not pass the verification.
    
    Old behaviour can be forced by using `san_ssl_insecure=True`.
    
    SecurityImpact
    DocImpact
    Partial-Bug: 1188189
    
    Change-Id: I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b




From tristan.cacqueray at enovance.com  Wed Apr  9 08:22:22 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Wed, 09 Apr 2014 08:22:22 -0000
Subject: [Openstack-security] [Bug 1289033] Re: [OSSA-2014-010] XSS in
 Horizon-Orchestration (CVE-2014-0157)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140409082225.8932.53210.launchpad@gac.canonical.com>

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

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

Title:
  [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157)

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Dashboard (Horizon) havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From thierry at openstack.org  Wed Apr  9 10:38:55 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 09 Apr 2014 12:38:55 +0200
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <CAH8yC8kMxkZc1gDbFPz94in-5ashYfDzFmduE8B7ebpCqXSodQ@mail.gmail.com>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
 <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>
 <CAH8yC8kMxkZc1gDbFPz94in-5ashYfDzFmduE8B7ebpCqXSodQ@mail.gmail.com>
Message-ID: <5345233F.7060007@openstack.org>

Jeffrey Walton wrote:
> On Tue, Apr 8, 2014 at 3:32 PM, Clark, Robert Graham
> <robert.clark at hp.com> wrote:
>> Thanks Malini, excellent summary.
>>
>> It’s worth re-iterating this point from the email below: Any secrets that you have previously communicated, API keys, passwords, credentials should be considered compromised.
>>
>> A second important point that isn’t being that widely discussed is the possibility that certificates and keys have been stolen and can be used to impersonate TLS servers. Now these certificates can be revoked, but that doesn’t buy you much outside of the browser, support for CRL’s is spotty in system crypto APIs (and you almost certainly haven’t downloaded them) and OCSP is basically non-existent for most client libraries.
>>
> +1
> 
> Companies like Google will be OK in the short term because they use
> those 30-day certs in many places (while re-certifying the same public
> key). Others, not so sure....

Should we consider issuing an OSSN describing steps for heartbleed
mitigation in OpenStack deployments ? I know it's not very different
from other affected SSL services, but I've already answered that
question twice on MLs and people are apparently very confused about it
so it looks like something that could use a reference official answer :)

-- 
Thierry Carrez (ttx)



From 1240382 at bugs.launchpad.net  Wed Apr  9 11:37:05 2014
From: 1240382 at bugs.launchpad.net (Alan Pevec)
Date: Wed, 09 Apr 2014 11:37:05 -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: <20140409113705.6739.26986.malone@wampee.canonical.com>

As discussed on the stable-maint list[1] such change isn't appropriate for the stable branch.
Distros can carry the proposed patch[2] or drop oauth support in their Havana packages, to address security concerns with oauth2.

[1] http://lists.openstack.org/pipermail/openstack-stable-maint/2014-March/002242.html
[2] https://review.openstack.org/70750

** Also affects: keystone/havana
   Importance: Undecided
       Status: New

** Changed in: keystone/havana
       Status: New => Won't Fix

** Changed in: keystone/havana
   Importance: Undecided => High

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

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

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  Won't Fix

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 Apr  9 12:23:54 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 09 Apr 2014 12:23:54 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140409122356.6871.10812.launchpad@wampee.canonical.com>

** Changed in: ossa
       Status: Confirmed => Triaged

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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  In Progress
Status in OpenStack Security Advisories:
  Triaged

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From 1300274 at bugs.launchpad.net  Wed Apr  9 13:13:16 2014
From: 1300274 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 09 Apr 2014 13:13:16 -0000
Subject: [Openstack-security] [Bug 1300274] Re: V3 Authentication Chaining -
 uniqueness of auth method names
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140409131316.8703.17318.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/86024
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=e364ba5b12de8e4c11bd80bcca903f9615dcfc2e
Submitter: Jenkins
Branch:    stable/havana

commit e364ba5b12de8e4c11bd80bcca903f9615dcfc2e
Author: Florent Flament <florent.flament-ext at cloudwatt.com>
Date:   Tue Apr 1 12:48:22 2014 +0000

    Sanitizes authentication methods received in requests.
    
    When a user authenticates against Identity V3 API, he can specify
    multiple authentication methods. This patch removes duplicates, which
    could have been used to achieve DoS attacks.
    
    Closes-Bug: 1300274
    (cherry picked from commit ef868ad92c00e23a4a5e9eb71e3e0bf5ae2fff0c)
    Cherry-pick from https://review.openstack.org/#/c/84425/
    
    Change-Id: I6e60324309baa094a5e54b012fb0fc528fea72ab


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

Title:
  V3 Authentication Chaining - uniqueness of auth method names

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Triaged

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From tristan.cacqueray at enovance.com  Wed Apr  9 15:01:16 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Wed, 09 Apr 2014 15:01:16 -0000
Subject: [Openstack-security] [Bug 1290537] Re: RBAC policy not enforced
 when adding a security group rule using EC2 API (CVE-2014-0167)
References: <20140310202059.13934.40594.malonedeb@gac.canonical.com>
Message-ID: <20140409150117.17721.91974.launchpad@chaenomeles.canonical.com>

** Information type changed from Private Security to Public 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/1290537

Title:
  RBAC policy not enforced when adding a security group rule using EC2
  API (CVE-2014-0167)

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) havana series:
  New
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  
  It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons.

  The Nova API security group implementation does enforce RBAC on these
  functions.

  In addition, the add_to_instance and remove_from _instance functions
  which are wrapped in RBAC verification use the
  "compute:security_groups" action which is not even listed in the
  default /etc/nova/policy.json. The latter is confusing to users.

  This is the case on Grizlly and at first glance, it doesn't look like
  this has changed in Havana.

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



From tristan.cacqueray at enovance.com  Wed Apr  9 15:03:24 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Wed, 09 Apr 2014 15:03:24 -0000
Subject: [Openstack-security] [Bug 1290537] Re: RBAC policy not enforced
 when adding a security group rule using EC2 API (CVE-2014-0167)
References: <20140310202059.13934.40594.malonedeb@gac.canonical.com>
Message-ID: <20140409150324.8839.27655.malone@gac.canonical.com>

Master review: https://review.openstack.org/#/c/86353/

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

Title:
  RBAC policy not enforced when adding a security group rule using EC2
  API (CVE-2014-0167)

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) havana series:
  New
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  
  It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons.

  The Nova API security group implementation does enforce RBAC on these
  functions.

  In addition, the add_to_instance and remove_from _instance functions
  which are wrapped in RBAC verification use the
  "compute:security_groups" action which is not even listed in the
  default /etc/nova/policy.json. The latter is confusing to users.

  This is the case on Grizlly and at first glance, it doesn't look like
  this has changed in Havana.

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



From bdpayne at acm.org  Wed Apr  9 16:33:18 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 9 Apr 2014 09:33:18 -0700
Subject: [Openstack-security] My Bio for
	https://launchpad.net/~openstack-ossg
In-Reply-To: <CAPihp9nL2nYiu=XpS1=kYBaXYq0TNaNPzFPW0e0n1K5+iF9Uaw@mail.gmail.com>
References: <CAPihp9nL2nYiu=XpS1=kYBaXYq0TNaNPzFPW0e0n1K5+iF9Uaw@mail.gmail.com>
Message-ID: <CAFpPvXDi0D-jj_XaqnsiD_Bdw9GM4OkFjC1qpvUQzth-8x9Y9Q@mail.gmail.com>

Welcome to the group.  The best way to get involved is to attend one of the
IRC meetings on Thursdays at 1800 UTC.

https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity

Cheers,
-bryan


On Tue, Apr 8, 2014 at 7:14 PM, masoom alam <masoom.alam at gmail.com> wrote:

> Hi Every one,
>
> My name is Masoom Alam and I am the joint director for the Applied
> Security Engineering Research Group  (http://aserg.comsats.edu.pk/ or
> http://aserg.com.pk/ ) and working as Associate Professor in a
> university.
>
> Just got a look at video from Robert Clark and Brayn on Openstack security
> group delivered at Openstack Summit.
>
> I am a newbie to OpenStack, but have got my hands dirty already with
> security stuff especially Security Monitoring through SIEM -- I have been
> involved in the development of an Managed Security Service provider, access
> control policies specification through XACML and formal verification - this
> is my favorite area - see our SACMAT publications ([1] and [2]*)*
>
> Kindly approve my membership at Openstack-OSSG.
>
> Thanks.
>
>
> *[1]* xDAuth: A Scalable and Lightweight Framework for Cross Domain
> Access Control and Delegation* Masoom Alam*, and Zhang, X. and Khan, K.H.
> and Ali, G. http://profsandhu.com/zhang/pub/sacmat11-xdauth.pdf
>
> *[2 ] **"** Model based behavior attestation"*   *Masoom Alam*, Xinwen
> Zhang, Mohammed Nauman, Tamleek, Jean-Peirrre Seifert*, *at SACMAT 08 *http://portal.acm.org/citation.cfm?id=1377836.1377864&coll=Portal&dl=ACM&type=series&idx=SERIES10694&part=series&WantType=Proceedings&title=SACMAT
> <http://portal.acm.org/citation.cfm?id=1377836.1377864&coll=Portal&dl=ACM&type=series&idx=SERIES10694&part=series&WantType=Proceedings&title=SACMAT>*
>
> _______________________________________________
> 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/20140409/0bd6ccc7/attachment.html>

From bdpayne at acm.org  Wed Apr  9 16:35:14 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 9 Apr 2014 09:35:14 -0700
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <5345233F.7060007@openstack.org>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
 <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>
 <CAH8yC8kMxkZc1gDbFPz94in-5ashYfDzFmduE8B7ebpCqXSodQ@mail.gmail.com>
 <5345233F.7060007@openstack.org>
Message-ID: <CAFpPvXCdPhHNwsZgXwC50ePd3aC2na61diP_Y+-CTj6c8kjrSw@mail.gmail.com>

>
> Should we consider issuing an OSSN describing steps for heartbleed
> mitigation in OpenStack deployments ? I know it's not very different
> from other affected SSL services, but I've already answered that
> question twice on MLs and people are apparently very confused about it
> so it looks like something that could use a reference official answer :)
>

Unless we have something specifically related to OpenStack to add, I'd
suggest just pointing people to http://heartbleed.com/.

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

From thierry.carrez+lp at gmail.com  Wed Apr  9 18:50:34 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 09 Apr 2014 18:50:34 -0000
Subject: [Openstack-security] [Bug 1290537] Re: RBAC policy not enforced
 when adding a security group rule using EC2 API (CVE-2014-0167)
References: <20140310202059.13934.40594.malonedeb@gac.canonical.com>
Message-ID: <20140409185037.6739.41139.launchpad@wampee.canonical.com>

** Changed in: nova/havana
       Status: New => In Progress

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

Title:
  RBAC policy not enforced when adding a security group rule using EC2
  API (CVE-2014-0167)

Status in OpenStack Compute (Nova):
  Fix Committed
Status in OpenStack Compute (nova) havana series:
  In Progress
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  
  It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons.

  The Nova API security group implementation does enforce RBAC on these
  functions.

  In addition, the add_to_instance and remove_from _instance functions
  which are wrapped in RBAC verification use the
  "compute:security_groups" action which is not even listed in the
  default /etc/nova/policy.json. The latter is confusing to users.

  This is the case on Grizlly and at first glance, it doesn't look like
  this has changed in Havana.

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



From gerrit2 at review.openstack.org  Wed Apr  9 19:12:21 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 19:12:21 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ia08c2d6252bb034087a244b47d5bcbea7dcfa70b
Message-ID: <E1WXxv3-0002Bz-Kf@review.openstack.org>


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

Log:
commit 82359492dc14e679d48e6801da304027e508533c
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 19:50:09 2014 -0500

    Hash functions support different hash algorithms
    
    The token hash functions always used MD5. With this change, the
    hash function can be passed in to the hash functions.
    
    SecurityImpact
    Related-Bug: #1174499
    
    Change-Id: Ia08c2d6252bb034087a244b47d5bcbea7dcfa70b




From gerrit2 at review.openstack.org  Wed Apr  9 19:12:29 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 19:12:29 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WXxvB-0002D6-0T@review.openstack.org>


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

Log:
commit edcec85f9ffdf5fbead8e38291c726be2f29baee
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with sha256
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256. This
    is for security hardening.
    
    Both SHA256 and MD5 will be tried when checking against the
    revocation list. This will support identity servers that are not
    configured for SHA256.
    
    When storing the PKI token in the local cache, the sha256 hash will
    always be used.
    
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Wed Apr  9 19:58:37 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 19:58:37 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WXydp-00008M-8L@review.openstack.org>


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

Log:
commit e2392ab93c238c0085da4d3fc5275cb4d38ac54d
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to 'sha256','md5'.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From robert.clark at hp.com  Wed Apr  9 20:24:06 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 9 Apr 2014 20:24:06 +0000
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <CAFpPvXCdPhHNwsZgXwC50ePd3aC2na61diP_Y+-CTj6c8kjrSw@mail.gmail.com>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
 <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>
 <CAH8yC8kMxkZc1gDbFPz94in-5ashYfDzFmduE8B7ebpCqXSodQ@mail.gmail.com>
 <5345233F.7060007@openstack.org>
 <CAFpPvXCdPhHNwsZgXwC50ePd3aC2na61diP_Y+-CTj6c8kjrSw@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A1122A1047@G4W3300.americas.hpqcorp.net>

I think there may be some value in us creating an OSSN that runs through the issue, it's coming up a lot on the ML and while I agree with Bryan in principle that it's not completely within the realm of the OSSN process, there's value in having one well written summary that people can refer to on the ML and elsewhere rather than having lots of add hock conversations.

Thoughts?

From: Bryan D. Payne [mailto:bdpayne at acm.org]
Sent: 09 April 2014 09:35
To: Thierry Carrez
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)

Should we consider issuing an OSSN describing steps for heartbleed
mitigation in OpenStack deployments ? I know it's not very different
from other affected SSL services, but I've already answered that
question twice on MLs and people are apparently very confused about it
so it looks like something that could use a reference official answer :)

Unless we have something specifically related to OpenStack to add, I'd suggest just pointing people to http://heartbleed.com/.

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

From gerrit2 at review.openstack.org  Wed Apr  9 20:25:37 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 20:25:37 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WXz3x-0003fU-8a@review.openstack.org>


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

Log:
commit a2bb1a1874c5116d67318b0eb1f412166d27bbd0
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to 'sha256','md5'.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From cody.bunch at rackspace.com  Wed Apr  9 20:28:11 2014
From: cody.bunch at rackspace.com (Cody Bunch)
Date: Wed, 9 Apr 2014 20:28:11 +0000
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <A0C170085C37664D93EE1604364858A1122A1047@G4W3300.americas.hpqcorp.net>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
 <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>
 <CAH8yC8kMxkZc1gDbFPz94in-5ashYfDzFmduE8B7ebpCqXSodQ@mail.gmail.com>
 <5345233F.7060007@openstack.org>
 <CAFpPvXCdPhHNwsZgXwC50ePd3aC2na61diP_Y+-CTj6c8kjrSw@mail.gmail.com>,
 <A0C170085C37664D93EE1604364858A1122A1047@G4W3300.americas.hpqcorp.net>
Message-ID: <327FAB32C28C564DAA23CE6D03789DBCB0F2E0E9@ORD1EXD01.RACKSPACE.CORP>

If not an OSSN a small faq of sorts as it pertains to OpenStack.

-C

________________________________
From: Clark, Robert Graham [robert.clark at hp.com]
Sent: Wednesday, April 09, 2014 3:24 PM
To: Bryan D. Payne; Thierry Carrez; Nathan Kinder
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)

I think there may be some value in us creating an OSSN that runs through the issue, it’s coming up a lot on the ML and while I agree with Bryan in principle that it’s not completely within the realm of the OSSN process, there’s value in having one well written summary that people can refer to on the ML and elsewhere rather than having lots of add hock conversations.

Thoughts?

From: Bryan D. Payne [mailto:bdpayne at acm.org]
Sent: 09 April 2014 09:35
To: Thierry Carrez
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)

Should we consider issuing an OSSN describing steps for heartbleed
mitigation in OpenStack deployments ? I know it's not very different
from other affected SSL services, but I've already answered that
question twice on MLs and people are apparently very confused about it
so it looks like something that could use a reference official answer :)

Unless we have something specifically related to OpenStack to add, I'd suggest just pointing people to http://heartbleed.com/.

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

From gerrit2 at review.openstack.org  Wed Apr  9 20:33:19 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 20:33:19 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WXzBP-0004dh-ON@review.openstack.org>


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

Log:
commit 6f0d61b0fc4a8671cf12bb516514c9f209cf1180
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to 'sha256','md5'.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Wed Apr  9 20:44:55 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 20:44:55 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WXzMd-0006Py-8n@review.openstack.org>


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

Log:
commit fb8ecac52b9a131f83b82f448325b160040fc933
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance.
    
    SecurityImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From lhdx at dv.com  Wed Apr  9 13:52:58 2014
From: lhdx at dv.com (=?utf-8?B?6b6Z5L+h6Im6?=)
Date: Wed, 9 Apr 2014 21:52:58 +0800
Subject: [Openstack-security] =?utf-8?b?5aaC5LuK6YeH6LSt55qE5Y+R5bGV6LaL?=
	=?utf-8?b?5Yq/?=
Message-ID: <DD145A6115365CD72E0A815BDCA5F8FE@dv.com>


龙信艺lhdx at dv.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140409/d514f854/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3.30精益采购.gif
Type: image/gif
Size: 85204 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140409/d514f854/attachment.gif>

From 1290537 at bugs.launchpad.net  Wed Apr  9 15:02:41 2014
From: 1290537 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 09 Apr 2014 15:02:41 -0000
Subject: [Openstack-security] [Bug 1290537] Fix proposed to nova
	(milestone-proposed)
References: <20140310202059.13934.40594.malonedeb@gac.canonical.com>
Message-ID: <20140409150241.8571.31540.malone@gac.canonical.com>

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/86360

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

Title:
  RBAC policy not enforced when adding a security group rule using EC2
  API (CVE-2014-0167)

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Compute (nova) havana series:
  New
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  
  It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons.

  The Nova API security group implementation does enforce RBAC on these
  functions.

  In addition, the add_to_instance and remove_from _instance functions
  which are wrapped in RBAC verification use the
  "compute:security_groups" action which is not even listed in the
  default /etc/nova/policy.json. The latter is confusing to users.

  This is the case on Grizlly and at first glance, it doesn't look like
  this has changed in Havana.

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



From vp73nk8020.ptm at 1012wellness.com  Wed Apr  9 16:29:16 2014
From: vp73nk8020.ptm at 1012wellness.com (=?GB2312?B?varNrs7E?=)
Date: Wed, 09 Apr 2014 16:29:16 -0000
Subject: [Openstack-security] 173676openstack-security
Message-ID: <mailman.0.1560799084.28383.openstack-security@lists.openstack.org>

openstack-security
-----------------------------------------------------------------------------------------

                      173676《微.信.营.销.从.入.门.到.实.战》00:36:57

                             【主.讲：马.佳.彬】00:36:57

【时$间】4月18上$海、4月19北$京、4月26深$圳、5月17广$州、6月2ｏ上$海、6月21北$京、6月28深$圳

          赠.送：173676

           价.值18ｏｏ元的微.网.站，限前3ｏ名报名学.员。173676

           微.信营.销系.统4ｏ多款公众平台接口，含大转盘、刮刮卡、优惠券等实用营.销功能。173676

【会.务.负.责.人】１３６９１４７２８１６ ＱＱ：１３２１２５９１２４（叶.霞）

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

课$程$大$纲173676

一、微.信.营.销.概.念.篇173676

二、微.信.营.销.入.门.篇173676

三、微.信.营.销.进.阶.篇173676

四、微.信.营.销.落.地.篇173676

-----------------------------------------------------------------------------------------
00:36:57



From 1290537 at bugs.launchpad.net  Wed Apr  9 17:36:32 2014
From: 1290537 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 09 Apr 2014 17:36:32 -0000
Subject: [Openstack-security] [Bug 1290537] Re: RBAC policy not enforced
 when adding a security group rule using EC2 API (CVE-2014-0167)
References: <20140310202059.13934.40594.malonedeb@gac.canonical.com>
Message-ID: <20140409173632.8998.55991.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/86358
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=d4056f8723cc6cefb28ff6e5a7c0df5ea77f82ef
Submitter: Jenkins
Branch:    master

commit d4056f8723cc6cefb28ff6e5a7c0df5ea77f82ef
Author: Andrew Laski <andrew.laski at rackspace.com>
Date:   Thu Mar 20 19:04:09 2014 -0400

    Add RBAC policy for ec2 API security groups calls
    
    The revoke_security_group_ingress, revoke_security_group_ingress, and
    delete_security_group calls in the ec2 API were not restricted by policy
    checks.  This prevented a deployer from restricting their usage via
    roles or other checks.  Checks have been added for these calls.
    
    Closes-Bug: #1290537
    Change-Id: I4bf681bedd68ed2216b429d34db735823e0a6189


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

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

Title:
  RBAC policy not enforced when adding a security group rule using EC2
  API (CVE-2014-0167)

Status in OpenStack Compute (Nova):
  Fix Committed
Status in OpenStack Compute (nova) havana series:
  New
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  
  It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons.

  The Nova API security group implementation does enforce RBAC on these
  functions.

  In addition, the add_to_instance and remove_from _instance functions
  which are wrapped in RBAC verification use the
  "compute:security_groups" action which is not even listed in the
  default /etc/nova/policy.json. The latter is confusing to users.

  This is the case on Grizlly and at first glance, it doesn't look like
  this has changed in Havana.

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



From 1290537 at bugs.launchpad.net  Wed Apr  9 20:54:11 2014
From: 1290537 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 09 Apr 2014 20:54:11 -0000
Subject: [Openstack-security] [Bug 1290537] Re: RBAC policy not enforced
 when adding a security group rule using EC2 API (CVE-2014-0167)
References: <20140310202059.13934.40594.malonedeb@gac.canonical.com>
Message-ID: <20140409205411.26245.13211.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/86360
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=87f57c0a2cc00a70edc87c5dc10bdefb6c01587b
Submitter: Jenkins
Branch:    milestone-proposed

commit 87f57c0a2cc00a70edc87c5dc10bdefb6c01587b
Author: Andrew Laski <andrew.laski at rackspace.com>
Date:   Thu Mar 20 19:04:09 2014 -0400

    Add RBAC policy for ec2 API security groups calls
    
    The revoke_security_group_ingress, revoke_security_group_ingress, and
    delete_security_group calls in the ec2 API were not restricted by policy
    checks.  This prevented a deployer from restricting their usage via
    roles or other checks.  Checks have been added for these calls.
    
    Closes-Bug: #1290537
    Change-Id: I4bf681bedd68ed2216b429d34db735823e0a6189
    (cherry picked from commit d4056f8723cc6cefb28ff6e5a7c0df5ea77f82ef)


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

** Changed in: nova/havana
       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/1290537

Title:
  RBAC policy not enforced when adding a security group rule using EC2
  API (CVE-2014-0167)

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  
  It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons.

  The Nova API security group implementation does enforce RBAC on these
  functions.

  In addition, the add_to_instance and remove_from _instance functions
  which are wrapped in RBAC verification use the
  "compute:security_groups" action which is not even listed in the
  default /etc/nova/policy.json. The latter is confusing to users.

  This is the case on Grizlly and at first glance, it doesn't look like
  this has changed in Havana.

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



From 1290537 at bugs.launchpad.net  Wed Apr  9 20:55:32 2014
From: 1290537 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 09 Apr 2014 20:55:32 -0000
Subject: [Openstack-security] [Bug 1290537] Fix merged to nova
	(stable/havana)
References: <20140310202059.13934.40594.malonedeb@gac.canonical.com>
Message-ID: <20140409205532.8734.52156.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/86361
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=dbb7dd03fea68120ef5ac9bbb1b3f184e3f2eacc
Submitter: Jenkins
Branch:    stable/havana

commit dbb7dd03fea68120ef5ac9bbb1b3f184e3f2eacc
Author: Andrew Laski <andrew.laski at rackspace.com>
Date:   Wed Apr 9 09:27:44 2014 -0400

    Add RBAC policy for ec2 API security groups calls
    
    The revoke_security_group_ingress, revoke_security_group_ingress, and
    delete_security_group calls in the ec2 API were not restricted by policy
    checks.  This prevented a deployer from restricting their usage via
    roles or other checks.  Checks have been added for these calls.
    
    Based on commit d4056f8723cc6cefb28ff6e5a7c0df5ea77f82ef but modified
    for the backport.
    
    Closes-Bug: #1290537
    Change-Id: I4bf681bedd68ed2216b429d34db735823e0a6189

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

Title:
  RBAC policy not enforced when adding a security group rule using EC2
  API (CVE-2014-0167)

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Committed

Bug description:
  
  It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons.

  The Nova API security group implementation does enforce RBAC on these
  functions.

  In addition, the add_to_instance and remove_from _instance functions
  which are wrapped in RBAC verification use the
  "compute:security_groups" action which is not even listed in the
  default /etc/nova/policy.json. The latter is confusing to users.

  This is the case on Grizlly and at first glance, it doesn't look like
  this has changed in Havana.

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



From bdpayne at acm.org  Wed Apr  9 21:43:21 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 9 Apr 2014 14:43:21 -0700
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <327FAB32C28C564DAA23CE6D03789DBCB0F2E0E9@ORD1EXD01.RACKSPACE.CORP>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
 <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>
 <CAH8yC8kMxkZc1gDbFPz94in-5ashYfDzFmduE8B7ebpCqXSodQ@mail.gmail.com>
 <5345233F.7060007@openstack.org>
 <CAFpPvXCdPhHNwsZgXwC50ePd3aC2na61diP_Y+-CTj6c8kjrSw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122A1047@G4W3300.americas.hpqcorp.net>
 <327FAB32C28C564DAA23CE6D03789DBCB0F2E0E9@ORD1EXD01.RACKSPACE.CORP>
Message-ID: <CAFpPvXD97P2qRh2MzmCUuhOyrLLbnzYViEfNeox7=DRzmMC4DQ@mail.gmail.com>

If we are going to do something, let's do an OSSN.  Given the discussion
here, I'm going to flip my opinion and suggest that we cut an OSSN in short
order.  Who would like to write it up?  I'm traveling today, so I'm out.

-bryan


On Wed, Apr 9, 2014 at 1:28 PM, Cody Bunch <cody.bunch at rackspace.com> wrote:

>  If not an OSSN a small faq of sorts as it pertains to OpenStack.
>
> -C
>
>  ------------------------------
> *From:* Clark, Robert Graham [robert.clark at hp.com]
> *Sent:* Wednesday, April 09, 2014 3:24 PM
> *To:* Bryan D. Payne; Thierry Carrez; Nathan Kinder
>
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
>
>   I think there may be some value in us creating an OSSN that runs
> through the issue, it's coming up a lot on the ML and while I agree with
> Bryan in principle that it's not completely within the realm of the OSSN
> process, there's value in having one well written summary that people can
> refer to on the ML and elsewhere rather than having lots of add hock
> conversations.
>
>
>
> Thoughts?
>
>
>
> *From:* Bryan D. Payne [mailto:bdpayne at acm.org]
> *Sent:* 09 April 2014 09:35
> *To:* Thierry Carrez
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
>
>
>
>  Should we consider issuing an OSSN describing steps for heartbleed
>
> mitigation in OpenStack deployments ? I know it's not very different
> from other affected SSL services, but I've already answered that
> question twice on MLs and people are apparently very confused about it
> so it looks like something that could use a reference official answer :)
>
>
>
> Unless we have something specifically related to OpenStack to add, I'd
> suggest just pointing people to http://heartbleed.com/.
>
>
>
> -bryan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140409/733ac046/attachment.html>

From gerrit2 at review.openstack.org  Wed Apr  9 22:58:40 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 09 Apr 2014 22:58:40 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WY1S4-0008Qy-Rn@review.openstack.org>


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

Log:
commit 316b3eeb2e629f36e24ace5c1e5e362dd0c4cad6
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From nkinder at redhat.com  Wed Apr  9 22:59:09 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Wed, 09 Apr 2014 15:59:09 -0700
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <CAFpPvXD97P2qRh2MzmCUuhOyrLLbnzYViEfNeox7=DRzmMC4DQ@mail.gmail.com>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
 <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>
 <CAH8yC8kMxkZc1gDbFPz94in-5ashYfDzFmduE8B7ebpCqXSodQ@mail.gmail.com>
 <5345233F.7060007@openstack.org>
 <CAFpPvXCdPhHNwsZgXwC50ePd3aC2na61diP_Y+-CTj6c8kjrSw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122A1047@G4W3300.americas.hpqcorp.net>
 <327FAB32C28C564DAA23CE6D03789DBCB0F2E0E9@ORD1EXD01.RACKSPACE.CORP>
 <CAFpPvXD97P2qRh2MzmCUuhOyrLLbnzYViEfNeox7=DRzmMC4DQ@mail.gmail.com>
Message-ID: <5345D0BD.20306@redhat.com>

On 04/09/2014 02:43 PM, Bryan D. Payne wrote:
> If we are going to do something, let's do an OSSN.  Given the discussion
> here, I'm going to flip my opinion and suggest that we cut an OSSN in
> short order.  Who would like to write it up?  I'm traveling today, so
> I'm out.

https://review.openstack.org/#/c/86466/

> 
> -bryan
> 
> 
> On Wed, Apr 9, 2014 at 1:28 PM, Cody Bunch <cody.bunch at rackspace.com
> <mailto:cody.bunch at rackspace.com>> wrote:
> 
>     If not an OSSN a small faq of sorts as it pertains to OpenStack.
> 
>     -C
> 
>     ------------------------------------------------------------------------
>     *From:* Clark, Robert Graham [robert.clark at hp.com
>     <mailto:robert.clark at hp.com>]
>     *Sent:* Wednesday, April 09, 2014 3:24 PM
>     *To:* Bryan D. Payne; Thierry Carrez; Nathan Kinder
> 
>     *Cc:* openstack-security at lists.openstack.org
>     <mailto:openstack-security at lists.openstack.org>
>     *Subject:* Re: [Openstack-security] FW: OpenSSL Heartblead
>     (CVE-2014-0160)
> 
>     I think there may be some value in us creating an OSSN that runs
>     through the issue, it’s coming up a lot on the ML and while I agree
>     with Bryan in principle that it’s not completely within the realm of
>     the OSSN process, there’s value in having one well written summary
>     that people can refer to on the ML and elsewhere rather than having
>     lots of add hock conversations.
> 
>      
> 
>     Thoughts?
> 
>      
> 
>     *From:*Bryan D. Payne [mailto:bdpayne at acm.org <mailto:bdpayne at acm.org>]
>     *Sent:* 09 April 2014 09:35
>     *To:* Thierry Carrez
>     *Cc:* openstack-security at lists.openstack.org
>     <mailto:openstack-security at lists.openstack.org>
>     *Subject:* Re: [Openstack-security] FW: OpenSSL Heartblead
>     (CVE-2014-0160)
> 
>      
> 
>         Should we consider issuing an OSSN describing steps for heartbleed
> 
>         mitigation in OpenStack deployments ? I know it's not very different
>         from other affected SSL services, but I've already answered that
>         question twice on MLs and people are apparently very confused
>         about it
>         so it looks like something that could use a reference official
>         answer :)
> 
>      
> 
>     Unless we have something specifically related to OpenStack to add,
>     I'd suggest just pointing people to http://heartbleed.com/.
> 
>      
> 
>     -bryan
> 
> 




From 1174499 at bugs.launchpad.net  Wed Apr  9 23:02:13 2014
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 09 Apr 2014 23:02:13 -0000
Subject: [Openstack-security] [Bug 1174499] Related fix merged to
	python-keystoneclient (master)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140409230214.17758.83603.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/86202
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=82359492dc14e679d48e6801da304027e508533c
Submitter: Jenkins
Branch:    master

commit 82359492dc14e679d48e6801da304027e508533c
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 19:50:09 2014 -0500

    Hash functions support different hash algorithms
    
    The token hash functions always used MD5. With this change, the
    hash function can be passed in to the hash functions.
    
    SecurityImpact
    Related-Bug: #1174499
    
    Change-Id: Ia08c2d6252bb034087a244b47d5bcbea7dcfa70b

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

Title:
  Keystone token hashing is MD5

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

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



From todd at privatecore.com  Wed Apr  9 23:55:18 2014
From: todd at privatecore.com (Todd Thiemann)
Date: Wed, 9 Apr 2014 16:55:18 -0700
Subject: [Openstack-security] OpenStack Security Meetup in Silicon Valley (1
 May 2014) Call for Papers (CFP)
Message-ID: <CANRJSuTgLsnp6MW6=GRAjrqea+kDCB=+hNerNYG1JG3YQaqSWQ@mail.gmail.com>

Dear Stackers and Security Types,

We are holding a Meetup on the evening of 1 May in Redwood City (Silicon
Valley) to have a few short talks in the run-up to OpenStack Summit
Atlanta.  If you are in the area, please feel free to register and attend.
We now have 74 people signed up to attend the "OpenStack Security Conclave"
Meetup with a fantastic kickoff presentation from Bryan Payne of Nebula
fame. (check out http://www.meetup.com/openstack/events/173686002/ )

We have presentation/demo slots available for those with OpenStack security
insights.  These slots provide a platform to briefly (25 minutes) cover a
topic of interest to the OpenStack security community.  These are intended
to be technical presentations that educate on a given topic (no sales
pitches). We may also have the time for brief demos or breakout
discussions.

If you have an interest in presenting or demo-ing, please send me an email (
todd at privatecore.com) with a summary of the topic and 2-3 bullet points
that the audience will take away.

Also, if your company/organization is interested in sponsoring the event
(venues and beverages have a cost), please contact me.

I look forward to seeing you at the OpenStack Security Conclave in Redwood
City on 1 May!

Cheers,

Todd

-- 

Todd Thiemann

todd at privatecore.com | www.privatecore.com

Visit our blog at http://privatecore.com/blogs/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140409/de742ff6/attachment.html>

From gerrit2 at review.openstack.org  Thu Apr 10 00:20:07 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 10 Apr 2014 00:20:07 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Iafe3c975d59818c8f362647f7ea5149a03deee47
Message-ID: <E1WY2it-0000rl-ED@review.openstack.org>


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

Log:
commit e8653f02b4f8b1b85051b4fea8437d6aa00a5013
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Apr 9 19:13:09 2014 -0500

    Configurable token hash algorithm
    
    Tokens were always hashed with MD5. This change allows tokens to
    be hashed with SHA256 (or any other algorithm supported by the
    keystoneclient token hash function). This is for security
    hardening.
    
    There's a new configuration option 'hash_algorithm' in the [token]
    section. This is the algorithm to use for hashing PKI tokens, so is
    used
    
    a) when storing the token in the db
    b) as the hash in the revocation list
    
    hash_algorithm defaults to 'md5' for backwards compatibility.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47




From gerrit2 at review.openstack.org  Thu Apr 10 00:28:00 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 10 Apr 2014 00:28:00 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Iafe3c975d59818c8f362647f7ea5149a03deee47
Message-ID: <E1WY2qW-0001TM-5H@review.openstack.org>


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

Log:
commit bf4ff96472991675f76c95dde8c027417d0deafd
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Apr 9 19:13:09 2014 -0500

    Configurable token hash algorithm
    
    Tokens were always hashed with MD5. This change allows tokens to
    be hashed with SHA256 (or any other algorithm supported by the
    keystoneclient token hash function). This is for security
    hardening.
    
    There's a new configuration option 'hash_algorithm' in the [token]
    section. This is the algorithm to use for hashing PKI tokens, so is
    used
    
    a) when storing the token in the db
    b) as the hash in the revocation list
    
    hash_algorithm defaults to 'md5' for backwards compatibility.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47




From thierry at openstack.org  Thu Apr 10 07:59:52 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Thu, 10 Apr 2014 09:59:52 +0200
Subject: [Openstack-security] FW: OpenSSL Heartblead (CVE-2014-0160)
In-Reply-To: <5345D0BD.20306@redhat.com>
References: <CAGGTEhMesAuesyjabBWkgom4-a4GGtazcBTsK5++sawyVnm-9w@mail.gmail.com>
 <EE6FFF4F6C34C84C8C98DD2414EEA47E71940323@FMSMSX102.amr.corp.intel.com>
 <etPan.53444ed2.1190cde7.14bd@Roberts-MacBook-Air.local>
 <CAH8yC8kMxkZc1gDbFPz94in-5ashYfDzFmduE8B7ebpCqXSodQ@mail.gmail.com>
 <5345233F.7060007@openstack.org>
 <CAFpPvXCdPhHNwsZgXwC50ePd3aC2na61diP_Y+-CTj6c8kjrSw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122A1047@G4W3300.americas.hpqcorp.net>
 <327FAB32C28C564DAA23CE6D03789DBCB0F2E0E9@ORD1EXD01.RACKSPACE.CORP>
 <CAFpPvXD97P2qRh2MzmCUuhOyrLLbnzYViEfNeox7=DRzmMC4DQ@mail.gmail.com>
 <5345D0BD.20306@redhat.com>
Message-ID: <53464F78.60309@openstack.org>

Nathan Kinder wrote:
> On 04/09/2014 02:43 PM, Bryan D. Payne wrote:
>> If we are going to do something, let's do an OSSN.  Given the discussion
>> here, I'm going to flip my opinion and suggest that we cut an OSSN in
>> short order.  Who would like to write it up?  I'm traveling today, so
>> I'm out.
> 
> https://review.openstack.org/#/c/86466/

Nice work!

-- 
Thierry Carrez (ttx)



From tristan.cacqueray at enovance.com  Thu Apr 10 08:47:49 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Thu, 10 Apr 2014 08:47:49 -0000
Subject: [Openstack-security] [Bug 1290537] Re: [0SSA 2014-011] RBAC policy
 not enforced when adding a security group rule using EC2 API
 (CVE-2014-0167)
References: <20140310202059.13934.40594.malonedeb@gac.canonical.com>
Message-ID: <20140410084751.6907.12140.launchpad@wampee.canonical.com>

** Summary changed:

- RBAC policy not enforced when adding a security group rule using EC2 API (CVE-2014-0167)
+ [0SSA 2014-011] RBAC policy not enforced when adding a security group rule using EC2 API (CVE-2014-0167)

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

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

Title:
  [0SSA 2014-011] RBAC policy not enforced when adding a security group
  rule using EC2 API (CVE-2014-0167)

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released

Bug description:
  
  It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons.

  The Nova API security group implementation does enforce RBAC on these
  functions.

  In addition, the add_to_instance and remove_from _instance functions
  which are wrapped in RBAC verification use the
  "compute:security_groups" action which is not even listed in the
  default /etc/nova/policy.json. The latter is confusing to users.

  This is the case on Grizlly and at first glance, it doesn't look like
  this has changed in Havana.

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



From tristan.cacqueray at enovance.com  Thu Apr 10 20:21:33 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Thu, 10 Apr 2014 20:21:33 -0000
Subject: [Openstack-security] [Bug 1300274] Re: [0SSA 2014-013] V3
 Authentication Chaining - uniqueness of auth method names (CVE-2014-2828)
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140410202134.8807.18819.launchpad@gac.canonical.com>

** Summary changed:

- V3 Authentication Chaining - uniqueness of auth method names 
+ [0SSA 2014-013] V3 Authentication Chaining - uniqueness of auth method names (CVE-2014-2828)

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

Title:
  [0SSA 2014-013] V3 Authentication Chaining - uniqueness of auth method
  names (CVE-2014-2828)

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Triaged

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From tristan.cacqueray at enovance.com  Thu Apr 10 20:42:01 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Thu, 10 Apr 2014 20:42:01 -0000
Subject: [Openstack-security] [Bug 1300274] Re: [0SSA 2014-013] V3
 Authentication Chaining - uniqueness of auth method names (CVE-2014-2828)
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140410204203.8807.76432.launchpad@gac.canonical.com>

** Changed in: ossa
       Status: Triaged => Fix Released

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

Title:
  [0SSA 2014-013] V3 Authentication Chaining - uniqueness of auth method
  names (CVE-2014-2828)

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From 1305566 at bugs.launchpad.net  Thu Apr 10 14:05:58 2014
From: 1305566 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 10 Apr 2014 14:05:58 -0000
Subject: [Openstack-security] [Bug 1305566] Re: the token still can be used
 if the credential has been deleted
References: <20140410083249.25765.8738.malonedeb@soybean.canonical.com>
Message-ID: <20140410140559.8734.6124.malone@gac.canonical.com>

This would be a great place to emit revocation events in Juno.

** Changed in: keystone
   Importance: Undecided => Medium

** Changed in: keystone
       Status: New => Triaged

** Tags added: security

** Summary changed:

- the token still can be used if the credential has been deleted
+ the token still can be used if the EC2 credential has been deleted

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

Title:
  the token still can be used if the EC2 credential has been deleted

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  Currently, the associated tokens are not deleted when deleting ec2
  credential. So, the token got before can still be used.

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



From gerrit2 at review.openstack.org  Thu Apr 10 22:55:37 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 10 Apr 2014 22:55:37 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WYNsf-00040o-Vu@review.openstack.org>


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

Log:
commit 8ef39afc712909b4b0802efca6f892bf0640fab7
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance.
    
    SecurityImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From w.wanghong at huawei.com  Fri Apr 11 04:07:57 2014
From: w.wanghong at huawei.com (wanghong)
Date: Fri, 11 Apr 2014 04:07:57 -0000
Subject: [Openstack-security] [Bug 1305566] Re: the token still can be used
 if the EC2 credential has been deleted
References: <20140410083249.25765.8738.malonedeb@soybean.canonical.com>
Message-ID: <20140411040759.8901.91611.launchpad@gac.canonical.com>

** Changed in: keystone
     Assignee: (unassigned) => wanghong (w-wanghong)

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

Title:
  the token still can be used if the EC2 credential has been deleted

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  Currently, the associated tokens are not deleted when deleting ec2
  credential. So, the token got before can still be used.

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



From ahmed.shohel at ericsson.com  Fri Apr 11 08:13:16 2014
From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed)
Date: Fri, 11 Apr 2014 11:13:16 +0300
Subject: [Openstack-security] Openstack Threat modelling - Common Repository
Message-ID: <B8949B67-B3D4-4D74-9035-14BD8A46E820@ericsson.com>

Hi,

Yesterday’s OSSG meeting, we are discussing about Threat Modelling process and more specifically gating and publishing process.
Currently, the work is hosted in the Security Wiki page:

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

and  some of the contents are in  
https://github.com/shohel02/OpenStack_Threat_Modelling.git

Now, that more people are getting interested and there is a need to have engagement and dissemination strategy.
We are thinking of  some common GIT repo with Gerit control, similar to OSSN currently has.  Another aspect is, 
can it be part of the documentation project? We think it is well fitted in that category. What do you guys think ?

Thanks,
Shohel
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140411/d0d489d8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4163 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140411/d0d489d8/attachment.bin>

From 1300274 at bugs.launchpad.net  Fri Apr 11 14:04:48 2014
From: 1300274 at bugs.launchpad.net (Alan Pevec)
Date: Fri, 11 Apr 2014 14:04:48 -0000
Subject: [Openstack-security] [Bug 1300274] Re: [0SSA 2014-013] V3
 Authentication Chaining - uniqueness of auth method names (CVE-2014-2828)
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140411140450.8540.9193.launchpad@gac.canonical.com>

** Changed in: keystone/havana
   Importance: Undecided => High

** Tags removed: havana-backport-potential

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

Title:
  [0SSA 2014-013] V3 Authentication Chaining - uniqueness of auth method
  names (CVE-2014-2828)

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From 1274034 at bugs.launchpad.net  Fri Apr 11 14:28:08 2014
From: 1274034 at bugs.launchpad.net (Akihiro Motoki)
Date: Fri, 11 Apr 2014 14:28:08 -0000
Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall
 anti-spoofing does not prevent ARP poisoning
References: <20140129101504.12361.90017.malonedeb@gac.canonical.com>
Message-ID: <20140411142809.17562.31858.launchpad@chaenomeles.canonical.com>

** Tags added: icehouse-backport-potential

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

Title:
  Neutron firewall anti-spoofing does not prevent ARP poisoning

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

Bug description:
  The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning.
  When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature:
  - no-mac-spoofing
  - no-ip-spoofing
  - no-arp-spoofing
  - nova-no-nd-reflection
  - allow-dhcp-server

  Actually, the neutron firewall driver 'iptabes_firawall' handles only
  MAC and IP anti-spoofing rules.

  This is a security vulnerability, especially on shared networks.

  Reproduce an ARP cache poisoning and man in the middle:
  - Create a private network/subnet 10.0.0.0/24
  - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4)
  - Log on VM1 and install ettercap [1]
  - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:'
  - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok
  - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2]
  - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1

  [1] http://ettercap.github.io/ettercap/
  [2] http://paste.openstack.org/show/62112/

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



From gerrit2 at review.openstack.org  Fri Apr 11 14:36:21 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 11 Apr 2014 14:36:21 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WYcZ3-0004AS-3p@review.openstack.org>


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

Log:
commit 370f452617a7857ec7e7a6b3bb1dc3e3222bfd71
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From bdpayne at acm.org  Fri Apr 11 16:06:06 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Fri, 11 Apr 2014 09:06:06 -0700
Subject: [Openstack-security] Openstack Threat modelling - Common
	Repository
In-Reply-To: <B8949B67-B3D4-4D74-9035-14BD8A46E820@ericsson.com>
References: <B8949B67-B3D4-4D74-9035-14BD8A46E820@ericsson.com>
Message-ID: <CAFpPvXDmXdcFbQNFetuzM_=5PwgA-Xmhy7WGb2Zt86rhYiGVbA@mail.gmail.com>

This doesn't strike me as being as good of a fit for the documentation
project.  I say this because the output isn't a long lived document that
people will reference.  The findings seem to me to be of high value
initially, and then (hopefully) things get fixed and then I don't see
people referencing the findings much any more.  Please correct me if I'm
thinking of this in the wrong light.

Could you describe a bit more about how you would make of use gerrit here?
 Is this just to get some peer review on the findings before presenting
them to the projects as bug reports?

-bryan




On Fri, Apr 11, 2014 at 1:13 AM, Abu Shohel Ahmed <ahmed.shohel at ericsson.com
> wrote:

> Hi,
>
> Yesterday's OSSG meeting, we are discussing about Threat Modelling process
> and more specifically gating and publishing process.
> Currently, the work is hosted in the Security Wiki page:
>
> https://wiki.openstack.org/wiki/Security/Threat_Analysis
>
> and  some of the contents are in
> https://github.com/shohel02/OpenStack_Threat_Modelling.git
>
> Now, that more people are getting interested and there is a need to have
> engagement and dissemination strategy.
> We are thinking of  some common GIT repo with Gerit control, similar to
> OSSN currently has.  Another aspect is,
> can it be part of the documentation project? We think it is well fitted in
> that category. What do you guys think ?
>
> Thanks,
> Shohel
>
>
> _______________________________________________
> 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/20140411/568055f9/attachment.html>

From nkinder at redhat.com  Fri Apr 11 16:23:41 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Fri, 11 Apr 2014 09:23:41 -0700
Subject: [Openstack-security] Openstack Threat modelling - Common
	Repository
In-Reply-To: <B8949B67-B3D4-4D74-9035-14BD8A46E820@ericsson.com>
References: <B8949B67-B3D4-4D74-9035-14BD8A46E820@ericsson.com>
Message-ID: <5348170D.8040800@redhat.com>

On 04/11/2014 01:13 AM, Abu Shohel Ahmed wrote:
> Hi,
> 
> Yesterday’s OSSG meeting, we are discussing about Threat Modelling
> process and more specifically gating and publishing process.
> Currently, the work is hosted in the Security Wiki page:
> 
> https://wiki.openstack.org/wiki/Security/Threat_Analysis
> 
> and  some of the contents are in  
> https://github.com/shohel02/OpenStack_Threat_Modelling.git
> 
> Now, that more people are getting interested and there is a need to have
> engagement and dissemination strategy.
> We are thinking of  some common GIT repo with Gerit control, similar to
> OSSN currently has.  Another aspect is, 
> can it be part of the documentation project? We think it is well fitted
> in that category. What do you guys think ?

Hi Shohel,

I brought some of this up on our IRC meeting yesterday, but I'll repeat
it here for a wider audience.

We need to determine how the threat modeling documents will be
disseminated.  It's clearly documentation, so it would fall under the
Documentation program IMHO.  What is the ultimate form that these
documents will take?  Would it be a "Threat Modeling" manual, or perhaps
a series of white papers (one per project)?

The files in the existing repo are really built documents, not source.
For example, you can't easily review a diff of changes to the pdf that
is checked into the existing repo.  If we want these to be published
along with the rest of the OpenStack documentation, we need to follow
the conventions already used.  This means using Docbook (or possibly
RST) for the documentation source.  We should move away from pdf and xls
files in the repo.  The normal documentation build tools can produce
html and pdfs.

I think the format conversion needs to take place as a pre-requisite to
creating an official repo.

Thanks,
-NGK

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




From 1274034 at bugs.launchpad.net  Fri Apr 11 16:20:33 2014
From: 1274034 at bugs.launchpad.net (Kevin Bringard)
Date: Fri, 11 Apr 2014 16:20:33 -0000
Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall
 anti-spoofing does not prevent ARP poisoning
References: <20140129101504.12361.90017.malonedeb@gac.canonical.com>
Message-ID: <20140411162034.8901.39999.malone@gac.canonical.com>

Review https://review.openstack.org/#/c/83845/ is in progress to add L3
destination filtering to the spoof chain. Once that gets accepted we can
work on porting that back to icehouse and havana.

If anyone wants to go take a look at it and get it pushed through that'd
be useful :-D

We'll still need to keep this bug open as triaged, because we need to
implement true L2 filtering along the lines of what Édouard outlined in
the initial report.

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

Title:
  Neutron firewall anti-spoofing does not prevent ARP poisoning

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

Bug description:
  The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning.
  When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature:
  - no-mac-spoofing
  - no-ip-spoofing
  - no-arp-spoofing
  - nova-no-nd-reflection
  - allow-dhcp-server

  Actually, the neutron firewall driver 'iptabes_firawall' handles only
  MAC and IP anti-spoofing rules.

  This is a security vulnerability, especially on shared networks.

  Reproduce an ARP cache poisoning and man in the middle:
  - Create a private network/subnet 10.0.0.0/24
  - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4)
  - Log on VM1 and install ettercap [1]
  - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:'
  - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok
  - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2]
  - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1

  [1] http://ettercap.github.io/ettercap/
  [2] http://paste.openstack.org/show/62112/

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



From malini.k.bhandaru at intel.com  Fri Apr 11 23:57:26 2014
From: malini.k.bhandaru at intel.com (Bhandaru, Malini K)
Date: Fri, 11 Apr 2014 23:57:26 +0000
Subject: [Openstack-security] Openstack Threat modelling -
	Common	Repository
In-Reply-To: <CAFpPvXDmXdcFbQNFetuzM_=5PwgA-Xmhy7WGb2Zt86rhYiGVbA@mail.gmail.com>
References: <B8949B67-B3D4-4D74-9035-14BD8A46E820@ericsson.com>
 <CAFpPvXDmXdcFbQNFetuzM_=5PwgA-Xmhy7WGb2Zt86rhYiGVbA@mail.gmail.com>
Message-ID: <EE6FFF4F6C34C84C8C98DD2414EEA47E71945728@FMSMSX102.amr.corp.intel.com>

Bryan brings up a good point ..  this then takes the flavor of a blueprint with patches to address and/or write OSSNs and cover in the OpenStack security guide.

Regards
Malini

From: Bryan D. Payne [mailto:bdpayne at acm.org]
Sent: Friday, April 11, 2014 9:06 AM
To: Abu Shohel Ahmed
Cc: Openstack-security at lists.openstack.org , ; Anne Gentle
Subject: Re: [Openstack-security] Openstack Threat modelling - Common Repository

This doesn't strike me as being as good of a fit for the documentation project.  I say this because the output isn't a long lived document that people will reference.  The findings seem to me to be of high value initially, and then (hopefully) things get fixed and then I don't see people referencing the findings much any more.  Please correct me if I'm thinking of this in the wrong light.

Could you describe a bit more about how you would make of use gerrit here?  Is this just to get some peer review on the findings before presenting them to the projects as bug reports?

-bryan



On Fri, Apr 11, 2014 at 1:13 AM, Abu Shohel Ahmed <ahmed.shohel at ericsson.com<mailto:ahmed.shohel at ericsson.com>> wrote:
Hi,

Yesterday's OSSG meeting, we are discussing about Threat Modelling process and more specifically gating and publishing process.
Currently, the work is hosted in the Security Wiki page:

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

and  some of the contents are in
https://github.com/shohel02/OpenStack_Threat_Modelling.git

Now, that more people are getting interested and there is a need to have engagement and dissemination strategy.
We are thinking of  some common GIT repo with Gerit control, similar to OSSN currently has.  Another aspect is,
can it be part of the documentation project? We think it is well fitted in that category. What do you guys think ?

Thanks,
Shohel


_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140411/6ee865ee/attachment.html>

From dev29aug at gmail.com  Sun Apr 13 11:52:00 2014
From: dev29aug at gmail.com (Devendra Gupta)
Date: Sun, 13 Apr 2014 17:22:00 +0530
Subject: [Openstack-security] Glance Image list not working after Keystone
	SSL setup
Message-ID: <CAEb49LgDdfDhfeCqve7s-XNTZ1dCdp1FS6moBOu9_+ABLoTNtQ@mail.gmail.com>

Hi,

I have configured keystone to SSL and also update the endpoint in
service catalog. Keystone operations like endpoint/tenant list working
fine. I also update glance-api.conf and glance-registry.conf files
with ssl enabled keystone details but still glance is unable to find
images. It fails with following:

[root at openstack-centos65 glance(keystone_admin)]# glance --insecure image-list
Request returned failure status.
Invalid OpenStack Identity credentials.

Please see attached keystone.conf, glance-api.conf and
glance-registry.conf and debug output of glance image-list and
endpoint list.

Regards,
Devendra
-------------- next part --------------
+----------------------------------+-----------+---------------------------------------------------------+---------------------------------------------------------+--------------------------------------------------------+----------------------------------+
|                id                |   region  |                        publicurl                        |                       internalurl                       |                        adminurl                        |            service_id            |
+----------------------------------+-----------+---------------------------------------------------------+---------------------------------------------------------+--------------------------------------------------------+----------------------------------+
| 2ba1fc5b5fa040cba1fa99f3a0f16b31 | RegionOne |         http://openstack-centos65:8773/services/Cloud        |         http://openstack-centos65:8773/services/Cloud        |        http://openstack-centos65:8773/services/Admin        | 07acc02f8da44aabb6d74f8bfeb73110 |
| 34c308699eed49498dbb572624a89d78 | RegionOne |        http://openstack-centos65:8776/v1/%(tenant_id)s       |        http://openstack-centos65:8776/v1/%(tenant_id)s       |       http://openstack-centos65:8776/v1/%(tenant_id)s       | 58ddbeb7bfa241b8abf5d4b00fa60796 |
| 35383c51b83146cd9d5920e3b598812c | RegionOne |        http://openstack-centos65:8774/v2/%(tenant_id)s       |        http://openstack-centos65:8774/v2/%(tenant_id)s       |       http://openstack-centos65:8774/v2/%(tenant_id)s       | 5e3c505c2b684b80afe1d1f62963f48b |
| 4364a747f16549bb90f0820288ca62ea | RegionOne |        http://openstack-centos65:8776/v2/%(tenant_id)s       |        http://openstack-centos65:8776/v2/%(tenant_id)s       |       http://openstack-centos65:8776/v2/%(tenant_id)s       | ca4e340f3ac84871b47a7bf32f88ec47 |
| 7beb09e4b38a4a0cb115e2b28cff20d7 | RegionOne |                http://openstack-centos65:9292                |                http://openstack-centos65:9292                |               http://openstack-centos65:9292                | 8046b0a30eb5478b82d9f34560ab2848 |
| 8b3680803d034ccc9bd8994c214e5652 | RegionOne |                http://openstack-centos65:8777                |                http://openstack-centos65:8777                |               http://openstack-centos65:8777                | 2861404c9ff4467cadf617f3fa281256 |
| b0013f4bf78b4c31a078c48edc847025 | RegionOne |     http://openstack-centos65:8080/v1/AUTH_%(tenant_id)s     |     http://openstack-centos65:8080/v1/AUTH_%(tenant_id)s     |               http://openstack-centos65:8080/               | 4f9d0f3af6e64e1d9f7d6e18cc9d843c |
| c17ff619f0dd49eda15704dd137dce57 | RegionOne |                http://openstack-centos65:9696/               |                http://openstack-centos65:9696/               |               http://openstack-centos65:9696/               | 0a6a913e64364ea0888380d4011dace7 |
| d15b58c95b344d01bbaa4537618571f2 | RegionOne | https://openstack-centos65:$(public_port)s/v2.0 | https://openstack-centos65:$(public_port)s/v2.0 | https://openstack-centos65:$(admin_port)s/v2.0 | 9ab7d84f23094cb58a1614f2c99b38f2 |
| de343660051145b8996459691eabe64e | RegionOne |                http://openstack-centos65:8080                |                http://openstack-centos65:8080                |               http://openstack-centos65:8080                | c71f1a7cb5264938be8e2631622f7168 |
+----------------------------------+-----------+---------------------------------------------------------+---------------------------------------------------------+--------------------------------------------------------+----------------------------------+
-------------- next part --------------
[root at openstack-centos65 glance(keystone_admin)]# glance --insecure --debug image-list
curl -i -X GET -H 'X-Auth-Token: MIIPwQYJKoZIhvcNAQcCoIIPsjCCD64CAQExCTAHBgUrDgMCGjCCDo0GCSqGSIb3DQEHAaCCDn4Egg56eyJhY2Nlc3MiOiB7InRva2VuIjogeyJpc3N1ZWRfYXQiOiAiMjAxNC0wNC0xM1QxODo1MTozNi41NjMyNTkiLCAiZXhwaXJlcyI6ICIyMDE0LTA0LTE0VDE4OjUxOjM2WiIsICJpZCI6ICJwbGFjZWhvbGRlciIsICJ0ZW5hbnQiOiB7ImRlc2NyaXB0aW9uIjogImFkbWluIHRlbmFudCIsICJlbmFibGVkIjogdHJ1ZSwgImlkIjogImIzMjczMTNlYmU1ZDRiYTI5YTI2YmU0NjNlMTNhNGVjIiwgIm5hbWUiOiAiYWRtaW4ifX0sICJzZXJ2aWNlQ2F0YWxvZyI6IFt7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4xMjkuNTYuMjMwOjg3NzQvdjIvYjMyNzMxM2ViZTVkNGJhMjlhMjZiZTQ2M2UxM2E0ZWMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4Nzc0L3YyL2IzMjczMTNlYmU1ZDRiYTI5YTI2YmU0NjNlMTNhNGVjIiwgImlkIjogIjY3YjJhZWIxY2FiMjQ5Yjg5YzM2ZThkNjhjN2JhYTY3IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4Nzc0L3YyL2IzMjczMTNlYmU1ZDRiYTI5YTI2YmU0NjNlMTNhNGVjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImNvbXB1dGUiLCAibmFtZSI6ICJub3ZhIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEwLjEyOS41Ni4yMzA6OTY5Ni8iLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo5Njk2LyIsICJpZCI6ICIwNWE2MWM2NDM2NGM0MmNmODhhYjJkYjJkYmIxY2RlNSIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEwLjEyOS41Ni4yMzA6OTY5Ni8ifV0sICJlbmRwb2ludHNfbGlua3MiOiBbXSwgInR5cGUiOiAibmV0d29yayIsICJuYW1lIjogIm5ldXRyb24ifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4Nzc2L3YyL2IzMjczMTNlYmU1ZDRiYTI5YTI2YmU0NjNlMTNhNGVjIiwgInJlZ2lvbiI6ICJSZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEwLjEyOS41Ni4yMzA6ODc3Ni92Mi9iMzI3MzEzZWJlNWQ0YmEyOWEyNmJlNDYzZTEzYTRlYyIsICJpZCI6ICI3Y2FkYzE1ZjlhMGQ0YjYyYWQyMDRiNmIwNTE3ZjMyMCIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEwLjEyOS41Ni4yMzA6ODc3Ni92Mi9iMzI3MzEzZWJlNWQ0YmEyOWEyNmJlNDYzZTEzYTRlYyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJ2b2x1bWV2MiIsICJuYW1lIjogImNpbmRlcl92MiJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4xMjkuNTYuMjMwOjgwODAiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4MDgwIiwgImlkIjogIjExOGJiYWQ3MTlhYjQyYWE4ZTYwZDg0NTMyYWFjZTA2IiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4MDgwIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInMzIiwgIm5hbWUiOiAic3dpZnRfczMifSwgeyJlbmRwb2ludHMiOiBbeyJhZG1pblVSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo5MjkyIiwgInJlZ2lvbiI6ICJSZWdpb25PbmUiLCAiaW50ZXJuYWxVUkwiOiAiaHR0cDovLzEwLjEyOS41Ni4yMzA6OTI5MiIsICJpZCI6ICI0MTUzZDZlOGQ0NDE0MzM5YjU2Njk3MGRkN2U2YzI0YyIsICJwdWJsaWNVUkwiOiAiaHR0cDovLzEwLjEyOS41Ni4yMzA6OTI5MiJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpbWFnZSIsICJuYW1lIjogImdsYW5jZSJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4xMjkuNTYuMjMwOjg3NzciLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4Nzc3IiwgImlkIjogIjRlNGJjZGJmNzZiOTQ1ZWY4MGRmMjIzMmZjZGFmNzFlIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4Nzc3In1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogIm1ldGVyaW5nIiwgIm5hbWUiOiAiY2VpbG9tZXRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4xMjkuNTYuMjMwOjg3NzYvdjEvYjMyNzMxM2ViZTVkNGJhMjlhMjZiZTQ2M2UxM2E0ZWMiLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4Nzc2L3YxL2IzMjczMTNlYmU1ZDRiYTI5YTI2YmU0NjNlMTNhNGVjIiwgImlkIjogIjRhZGQzMWIzM2M2MzRhMWU4ZDIwYTA3MzhjNmQ1ZjExIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4Nzc2L3YxL2IzMjczMTNlYmU1ZDRiYTI5YTI2YmU0NjNlMTNhNGVjIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogInZvbHVtZSIsICJuYW1lIjogImNpbmRlciJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHA6Ly8xMC4xMjkuNTYuMjMwOjg3NzMvc2VydmljZXMvQWRtaW4iLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4NzczL3NlcnZpY2VzL0Nsb3VkIiwgImlkIjogIjc3YWE0NWM5MWY3MDQzYmNhOWFiYWE0NmM4MzYzODJjIiwgInB1YmxpY1VSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4NzczL3NlcnZpY2VzL0Nsb3VkIn1dLCAiZW5kcG9pbnRzX2xpbmtzIjogW10sICJ0eXBlIjogImVjMiIsICJuYW1lIjogIm5vdmFfZWMyIn0sIHsiZW5kcG9pbnRzIjogW3siYWRtaW5VUkwiOiAiaHR0cDovLzEwLjEyOS41Ni4yMzA6ODA4MC8iLCAicmVnaW9uIjogIlJlZ2lvbk9uZSIsICJpbnRlcm5hbFVSTCI6ICJodHRwOi8vMTAuMTI5LjU2LjIzMDo4MDgwL3YxL0FVVEhfYjMyNzMxM2ViZTVkNGJhMjlhMjZiZTQ2M2UxM2E0ZWMiLCAiaWQiOiAiMjc5NWNjMTQzMTFjNGZmZThhZjE3OTI1OTY1Nzk1ZDYiLCAicHVibGljVVJMIjogImh0dHA6Ly8xMC4xMjkuNTYuMjMwOjgwODAvdjEvQVVUSF9iMzI3MzEzZWJlNWQ0YmEyOWEyNmJlNDYzZTEzYTRlYyJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJvYmplY3Qtc3RvcmUiLCAibmFtZSI6ICJzd2lmdCJ9LCB7ImVuZHBvaW50cyI6IFt7ImFkbWluVVJMIjogImh0dHBzOi8vb3BlbnN0YWNrLWNlbnRvczY1LmJtYy5jb206MzUzNTcvdjIuMCIsICJyZWdpb24iOiAiUmVnaW9uT25lIiwgImludGVybmFsVVJMIjogImh0dHBzOi8vb3BlbnN0YWNrLWNlbnRvczY1LmJtYy5jb206NTAwMC92Mi4wIiwgImlkIjogIjU0YmMzYjRjNzM2ODQ3NDk4M2IxZTcyYTc0ZDIwYWIzIiwgInB1YmxpY1VSTCI6ICJodHRwczovL29wZW5zdGFjay1jZW50b3M2NS5ibWMuY29tOjUwMDAvdjIuMCJ9XSwgImVuZHBvaW50c19saW5rcyI6IFtdLCAidHlwZSI6ICJpZGVudGl0eSIsICJuYW1lIjogImtleXN0b25lIn1dLCAidXNlciI6IHsidXNlcm5hbWUiOiAiYWRtaW4iLCAicm9sZXNfbGlua3MiOiBbXSwgImlkIjogIjVlZGYyNWY1YTI5YTQ3NGViZTE2ODBiMmFiOGY4MTk1IiwgInJvbGVzIjogW3sibmFtZSI6ICJhZG1pbiJ9XSwgIm5hbWUiOiAiYWRtaW4ifSwgIm1ldGFkYXRhIjogeyJpc19hZG1pbiI6IDAsICJyb2xlcyI6IFsiYzM4ZWE0NDdlMmM4NDFiMmEzZDk4ZjI5NDU5YzQ5NzYiXX19fTGCAQswggEHAgEBMGcwYjELMAkGA1UEBhMCVVMxDjAMBgNVBAgMBVVuc2V0MQ4wDAYDVQQHDAVVbnNldDEOMAwGA1UECgwFVW5zZXQxIzAhBgNVBAMMGm9wZW5zdGFjay1jZW50b3M2NS5ibWMuY29tAgEBMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIGAf62TPWxtBj3BDkliPtWmz-r+Z7TPDKSbT9GUAFO27xwa68WxtgbQbVC8xpNcvOg8gNQhWvgV20L-oDDEUHhxcHCP-qqO8LdD+5YbzOwn8rlS0CAaUFoElA-ZDW1EVMpaXWII7YFFm+6VlSMKmVh0rEr7RT70EVHUeoAD+aVwtrA=' -H 'Content-Type: application/json' -H 'User-Agent: python-glanceclient' http://openstack-centos65:9292/v1/images/detail?sort_key=name&sort_dir=asc&limit=20

HTTP/1.1 401 Unauthorized
date: Sun, 13 Apr 2014 18:51:40 GMT
content-length: 253
content-type: text/plain; charset=UTF-8

401 Unauthorized

This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.



Request returned failure status.
Invalid OpenStack Identity credentials.
[root at openstack-centos65 glance(keystone_admin)]# glance --insecure image-list
Request returned failure status.
Invalid OpenStack Identity credentials.
-------------- next part --------------
[DEFAULT]
# Show more verbose log output (sets INFO log level output)
#verbose=True
verbose=True

# Show debugging output in logs (sets DEBUG log level output)
#debug=False
debug=False

# Which backend scheme should Glance use by default is not specified
# in a request to add a new image to Glance? Known schemes are determined
# by the known_stores option below.
# Default: 'file'
default_store = file

# List of which store classes and store class locations are
# currently known to glance at startup.
#known_stores = glance.store.filesystem.Store,
#               glance.store.http.Store,
#               glance.store.rbd.Store,
#               glance.store.s3.Store,
#               glance.store.swift.Store,
#               glance.store.sheepdog.Store,
#               glance.store.cinder.Store,


# Maximum image size (in bytes) that may be uploaded through the
# Glance API server. Defaults to 1 TB.
# WARNING: this value should only be increased after careful consideration
# and must be set to a value under 8 EB (9223372036854775808).
#image_size_cap = 1099511627776

# Address to bind the API server
bind_host = 0.0.0.0

# Port the bind the API server to
bind_port = 9292

# Log to this file. Make sure you do not set the same log
# file for both the API and registry servers!
#log_file=/var/log/glance/api.log
log_file=/var/log/glance/api.log

# Backlog requests when creating socket
backlog = 4096

# TCP_KEEPIDLE value in seconds when creating socket.
# Not supported on OS X.
#tcp_keepidle = 600

# API to use for accessing data. Default value points to sqlalchemy
# package, it is also possible to use: glance.db.registry.api
# data_api = glance.db.sqlalchemy.api

# SQLAlchemy connection string for the reference implementation
# registry server. Any valid SQLAlchemy connection string is fine.
# See: http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/connections.html#sqlalchemy.create_engine
#sql_connection=mysql://glance:glance at localhost/glance
sql_connection=mysql://glance:5266553a114e4208 at openstack-centos65/glance

# Period in seconds after which SQLAlchemy should reestablish its connection
# to the database.
#
# MySQL uses a default `wait_timeout` of 8 hours, after which it will drop
# idle connections. This can result in 'MySQL Gone Away' exceptions. If you
# notice this, you can lower this value to ensure that SQLAlchemy reconnects
# before MySQL can drop the connection.
sql_idle_timeout = 3600

# Number of Glance API worker processes to start.
# On machines with more than one CPU increasing this value
# may improve performance (especially if using SSL with
# compression turned on). It is typically recommended to set
# this value to the number of CPUs present on your machine.
workers = 4

# Role used to identify an authenticated user as administrator
#admin_role = admin

# Allow unauthenticated users to access the API with read-only
# privileges. This only applies when using ContextMiddleware.
#allow_anonymous_access = False

# Allow access to version 1 of glance api
#enable_v1_api = True

# Allow access to version 2 of glance api
#enable_v2_api = True

# Return the URL that references where the data is stored on
# the backend storage system.  For example, if using the
# file system store a URL of 'file:///path/to/image' will
# be returned to the user in the 'direct_url' meta-data field.
# The default value is false.
#show_image_direct_url = False

# Send headers containing user and tenant information when making requests to
# the v1 glance registry. This allows the registry to function as if a user is
# authenticated without the need to authenticate a user itself using the
# auth_token middleware.
# The default value is false.
#send_identity_headers = False

# Supported values for the 'container_format' image attribute
#container_formats=ami,ari,aki,bare,ovf

# Supported values for the 'disk_format' image attribute
#disk_formats=ami,ari,aki,vhd,vmdk,raw,qcow2,vdi,iso

# Directory to use for lock files. Default to a temp directory
# (string value). This setting needs to be the same for both
# glance-scrubber and glance-api.
#lock_path=<None>
#
# Property Protections config file
# This file contains the rules for property protections and the roles
# associated with it.
# If this config value is not specified, by default, property protections
# won't be enforced.
# If a value is specified and the file is not found, then an
# HTTPInternalServerError will be thrown.
#property_protection_file =

# Set a system wide quota for every user.  This value is the total number
# of bytes that a user can use across all storage systems.  A value of
# 0 means unlimited.
#user_storage_quota = 0

# ================= Syslog Options ============================

# Send logs to syslog (/dev/log) instead of to file specified
# by `log_file`
#use_syslog = False
use_syslog = False

# Facility to use. If unset defaults to LOG_USER.
#syslog_log_facility = LOG_LOCAL0

# ================= SSL Options ===============================

# Certificate file to use when starting API server securely
#cert_file = /path/to/certfile

# Private key file to use when starting API server securely
#key_file = /path/to/keyfile

# CA certificate file to use to verify connecting clients
#ca_file = /path/to/cafile

# ================= Security Options ==========================

# AES key for encrypting store 'location' metadata, including
# -- if used -- Swift or S3 credentials
# Should be set to a random string of length 16, 24 or 32 bytes
#metadata_encryption_key = <16, 24 or 32 char registry metadata key>

# ============ Registry Options ===============================

# Address to find the registry server
registry_host = 0.0.0.0

# Port the registry server is listening on
registry_port = 9191

# What protocol to use when connecting to the registry server?
# Set to https for secure HTTP communication
registry_client_protocol = http

# The path to the key file to use in SSL connections to the
# registry server, if any. Alternately, you may set the
# GLANCE_CLIENT_KEY_FILE environ variable to a filepath of the key file
#registry_client_key_file = /path/to/key/file

# The path to the cert file to use in SSL connections to the
# registry server, if any. Alternately, you may set the
# GLANCE_CLIENT_CERT_FILE environ variable to a filepath of the cert file
#registry_client_cert_file = /path/to/cert/file

# The path to the certifying authority cert file to use in SSL connections
# to the registry server, if any. Alternately, you may set the
# GLANCE_CLIENT_CA_FILE environ variable to a filepath of the CA cert file
#registry_client_ca_file = /path/to/ca/file

# When using SSL in connections to the registry server, do not require
# validation via a certifying authority. This is the registry's equivalent of
# specifying --insecure on the command line using glanceclient for the API
# Default: False
#registry_client_insecure = False

# The period of time, in seconds, that the API server will wait for a registry
# request to complete. A value of '0' implies no timeout.
# Default: 600
#registry_client_timeout = 600

# Whether to automatically create the database tables.
# Default: False
#db_auto_create = False

# Enable DEBUG log messages from sqlalchemy which prints every database
# query and response.
# Default: False
#sqlalchemy_debug = True

# ============ Notification System Options =====================

# Notifications can be sent when images are create, updated or deleted.
# There are three methods of sending notifications, logging (via the
# log_file directive), rabbit (via a rabbitmq queue), qpid (via a Qpid
# message queue), or noop (no notifications sent, the default)
#notifier_strategy=qpid
notifier_strategy=qpid

# Configuration options if sending notifications via rabbitmq (these are
# the defaults)
rabbit_host = localhost
rabbit_port = 5672
rabbit_use_ssl = false
rabbit_userid = guest
rabbit_password = guest
rabbit_virtual_host = /
rabbit_notification_exchange = glance
rabbit_notification_topic = notifications
rabbit_durable_queues = False

# Configuration options if sending notifications via Qpid (these are
# the defaults)
qpid_notification_exchange = glance
qpid_notification_topic = notifications
qpid_hostname = openstack-centos65
qpid_port = 5672
qpid_username =guest
qpid_password =guest
qpid_sasl_mechanisms =
qpid_reconnect_timeout = 0
qpid_reconnect_limit = 0
qpid_reconnect_interval_min = 0
qpid_reconnect_interval_max = 0
qpid_reconnect_interval = 0
#qpid_heartbeat=60
# Set to 'ssl' to enable SSL
qpid_protocol = tcp
qpid_tcp_nodelay = True

# ============ Filesystem Store Options ========================

# Directory that the Filesystem backend store
# writes image data to
#filesystem_store_datadir=/var/lib/glance/images/
filesystem_store_datadir=/var/lib/glance/images/

# A path to a JSON file that contains metadata describing the storage
# system.  When show_multiple_locations is True the information in this
# file will be returned with any location that is contained in this
# store.
#filesystem_store_metadata_file = None

# ============ Swift Store Options =============================

# Version of the authentication service to use
# Valid versions are '2' for keystone and '1' for swauth and rackspace
swift_store_auth_version = 2

# Address where the Swift authentication service lives
# Valid schemes are 'http://' and 'https://'
# If no scheme specified,  default to 'https://'
# For swauth, use something like '127.0.0.1:8080/v1.0/'
swift_store_auth_address = 127.0.0.1:5000/v2.0/

# User to authenticate against the Swift authentication service
# If you use Swift authentication service, set it to 'account':'user'
# where 'account' is a Swift storage account and 'user'
# is a user in that account
swift_store_user = jdoe:jdoe

# Auth key for the user authenticating against the
# Swift authentication service
swift_store_key = a86850deb2742ec3cb41518e26aa2d89

# Container within the account that the account should use
# for storing images in Swift
swift_store_container = glance

# Do we create the container if it does not exist?
swift_store_create_container_on_put = False

# What size, in MB, should Glance start chunking image files
# and do a large object manifest in Swift? By default, this is
# the maximum object size in Swift, which is 5GB
swift_store_large_object_size = 5120

# When doing a large object manifest, what size, in MB, should
# Glance write chunks to Swift? This amount of data is written
# to a temporary disk buffer during the process of chunking
# the image file, and the default is 200MB
swift_store_large_object_chunk_size = 200

# Whether to use ServiceNET to communicate with the Swift storage servers.
# (If you aren't RACKSPACE, leave this False!)
#
# To use ServiceNET for authentication, prefix hostname of
# `swift_store_auth_address` with 'snet-'.
# Ex. https://example.com/v1.0/ -> https://snet-example.com/v1.0/
swift_enable_snet = False

# If set to True enables multi-tenant storage mode which causes Glance images
# to be stored in tenant specific Swift accounts.
#swift_store_multi_tenant = False

# A list of swift ACL strings that will be applied as both read and
# write ACLs to the containers created by Glance in multi-tenant
# mode. This grants the specified tenants/users read and write access
# to all newly created image objects. The standard swift ACL string
# formats are allowed, including:
# <tenant_id>:<username>
# <tenant_name>:<username>
# *:<username>
# Multiple ACLs can be combined using a comma separated list, for
# example: swift_store_admin_tenants = service:glance,*:admin
#swift_store_admin_tenants =

# The region of the swift endpoint to be used for single tenant. This setting
# is only necessary if the tenant has multiple swift endpoints.
#swift_store_region =

# If set to False, disables SSL layer compression of https swift requests.
# Setting to 'False' may improve performance for images which are already
# in a compressed format, eg qcow2. If set to True, enables SSL layer
# compression (provided it is supported by the target swift proxy).
#swift_store_ssl_compression = True

# ============ S3 Store Options =============================

# Address where the S3 authentication service lives
# Valid schemes are 'http://' and 'https://'
# If no scheme specified,  default to 'http://'
s3_store_host = 127.0.0.1:8080/v1.0/

# User to authenticate against the S3 authentication service
s3_store_access_key = <20-char AWS access key>

# Auth key for the user authenticating against the
# S3 authentication service
s3_store_secret_key = <40-char AWS secret key>

# Container within the account that the account should use
# for storing images in S3. Note that S3 has a flat namespace,
# so you need a unique bucket name for your glance images. An
# easy way to do this is append your AWS access key to "glance".
# S3 buckets in AWS *must* be lowercased, so remember to lowercase
# your AWS access key if you use it in your bucket name below!
s3_store_bucket = <lowercased 20-char aws access key>glance

# Do we create the bucket if it does not exist?
s3_store_create_bucket_on_put = False

# When sending images to S3, the data will first be written to a
# temporary buffer on disk. By default the platform's temporary directory
# will be used. If required, an alternative directory can be specified here.
#s3_store_object_buffer_dir = /path/to/dir

# When forming a bucket url, boto will either set the bucket name as the
# subdomain or as the first token of the path. Amazon's S3 service will
# accept it as the subdomain, but Swift's S3 middleware requires it be
# in the path. Set this to 'path' or 'subdomain' - defaults to 'subdomain'.
#s3_store_bucket_url_format = subdomain

# ============ RBD Store Options =============================

# Ceph configuration file path
# If using cephx authentication, this file should
# include a reference to the right keyring
# in a client.<USER> section
rbd_store_ceph_conf = /etc/ceph/ceph.conf

# RADOS user to authenticate as (only applicable if using cephx)
rbd_store_user = glance

# RADOS pool in which images are stored
rbd_store_pool = images

# Images will be chunked into objects of this size (in megabytes).
# For best performance, this should be a power of two
rbd_store_chunk_size = 8

# ============ Sheepdog Store Options =============================

sheepdog_store_address = localhost

sheepdog_store_port = 7000

# Images will be chunked into objects of this size (in megabytes).
# For best performance, this should be a power of two
sheepdog_store_chunk_size = 64

# ============ Cinder Store Options ===============================

# Info to match when looking for cinder in the service catalog
# Format is : separated values of the form:
# <service_type>:<service_name>:<endpoint_type> (string value)
#cinder_catalog_info = volume:cinder:publicURL

# Override service catalog lookup with template for cinder endpoint
# e.g. http://localhost:8776/v1/%(project_id)s (string value)
#cinder_endpoint_template = <None>

# Region name of this node (string value)
#os_region_name = <None>

# Location of ca certicates file to use for cinder client requests
# (string value)
#cinder_ca_certificates_file = <None>

# Number of cinderclient retries on failed http calls (integer value)
#cinder_http_retries = 3

# Allow to perform insecure SSL requests to cinder (boolean value)
#cinder_api_insecure = False

# ============ Delayed Delete Options =============================

# Turn on/off delayed delete
delayed_delete = False

# Delayed delete time in seconds
scrub_time = 43200

# Directory that the scrubber will use to remind itself of what to delete
# Make sure this is also set in glance-scrubber.conf
#scrubber_datadir=/var/lib/glance/scrubber

# =============== Image Cache Options =============================

# Base directory that the Image Cache uses
#image_cache_dir=/var/lib/glance/image-cache/

[keystone_authtoken]
#auth_host=127.0.0.1
#auth_host=openstack-centos65
auth_host=openstack-centos65
#auth_port=35357
auth_port=35357
#auth_protocol=http
auth_protocol=https
#admin_tenant_name=%SERVICE_TENANT_NAME%
admin_tenant_name=services
#admin_user=%SERVICE_USER%
admin_user=glance
#admin_password=%SERVICE_PASSWORD%
admin_password=9910fdcb05c4439a
#auth_uri=http://openstack-centos65:5000/
auth_uri=https://openstack-centos65:5000/

[paste_deploy]
# Name of the paste configuration file that defines the available pipelines
#config_file=/usr/share/glance/glance-api-dist-paste.ini

# Partial name of a pipeline in your paste configuration file with the
# service name removed. For example, if your paste section name is
# [pipeline:glance-api-keystone], you would configure the flavor below
# as 'keystone'.
#flavor=
flavor=keystone
-------------- next part --------------
[DEFAULT]
# Show more verbose log output (sets INFO log level output)
#verbose=True
verbose=True

# Show debugging output in logs (sets DEBUG log level output)
#debug=False
debug=False

# Address to bind the registry server
bind_host = 0.0.0.0

# Port the bind the registry server to
bind_port = 9191

# Log to this file. Make sure you do not set the same log
# file for both the API and registry servers!
#log_file=/var/log/glance/registry.log

# Backlog requests when creating socket
backlog = 4096

# TCP_KEEPIDLE value in seconds when creating socket.
# Not supported on OS X.
#tcp_keepidle = 600

# API to use for accessing data. Default value points to sqlalchemy
# package.
# data_api = glance.db.sqlalchemy.api

# SQLAlchemy connection string for the reference implementation
# registry server. Any valid SQLAlchemy connection string is fine.
# See: http://www.sqlalchemy.org/docs/05/reference/sqlalchemy/connections.html#sqlalchemy.create_engine
#sql_connection=mysql://glance:glance at localhost/glance
sql_connection=mysql://glance:5266553a114e4208 at openstack-centos65/glance

# Period in seconds after which SQLAlchemy should reestablish its connection
# to the database.
#
# MySQL uses a default `wait_timeout` of 8 hours, after which it will drop
# idle connections. This can result in 'MySQL Gone Away' exceptions. If you
# notice this, you can lower this value to ensure that SQLAlchemy reconnects
# before MySQL can drop the connection.
sql_idle_timeout = 3600

# Limit the api to return `param_limit_max` items in a call to a container. If
# a larger `limit` query param is provided, it will be reduced to this value.
api_limit_max = 1000

# If a `limit` query param is not provided in an api request, it will
# default to `limit_param_default`
limit_param_default = 25

# Role used to identify an authenticated user as administrator
#admin_role = admin

# Whether to automatically create the database tables.
# Default: False
#db_auto_create = False

# Enable DEBUG log messages from sqlalchemy which prints every database
# query and response.
# Default: False
#sqlalchemy_debug = True

# ================= Syslog Options ============================

# Send logs to syslog (/dev/log) instead of to file specified
# by `log_file`
#use_syslog = False
use_syslog = False

# Facility to use. If unset defaults to LOG_USER.
#syslog_log_facility = LOG_LOCAL1

# ================= SSL Options ===============================

# Certificate file to use when starting registry server securely
#cert_file = /path/to/certfile

# Private key file to use when starting registry server securely
#key_file = /path/to/keyfile

# CA certificate file to use to verify connecting clients
#ca_file = /path/to/cafile

[keystone_authtoken]
#auth_host=127.0.0.1
auth_host=openstack-centos65
#auth_port=35357
auth_port=35357
#auth_protocol=http
auth_protocol=https
#admin_tenant_name=%SERVICE_TENANT_NAME%
admin_tenant_name=services
#admin_user=%SERVICE_USER%
admin_user=glance
#admin_password=%SERVICE_PASSWORD%
admin_password=9910fdcb05c4439a
auth_uri=https://openstack-centos65:5000/

[paste_deploy]
# Name of the paste configuration file that defines the available pipelines
#config_file=/usr/share/glance/glance-registry-dist-paste.ini

# Partial name of a pipeline in your paste configuration file with the
# service name removed. For example, if your paste section name is
# [pipeline:glance-registry-keystone], you would configure the flavor below
# as 'keystone'.
#flavor=
flavor=keystone
-------------- next part --------------
f[DEFAULT]
# A "shared secret" between keystone and other openstack services
# admin_token = ADMIN
admin_token = 768b64d7641f49b3b3f98fb0d60dc1bc

# The IP address of the network interface to listen on
# bind_host = 0.0.0.0
bind_host = 0.0.0.0

# The port number which the public service listens on
# public_port = 5000
public_port = 5000

# The port number which the public admin listens on
# admin_port = 35357
admin_port = 35357

# The base endpoint URLs for keystone that are advertised to clients
# (NOTE: this does NOT affect how keystone listens for connections)
# public_endpoint = http://localhost:%(public_port)s/
# admin_endpoint = http://localhost:%(admin_port)s/

# The port number which the OpenStack Compute service listens on
# compute_port = 8774
compute_port = 8774

# Path to your policy definition containing identity actions
# policy_file = policy.json

# Rule to check if no matching policy definition is found
# FIXME(dolph): This should really be defined as [policy] default_rule
# policy_default_rule = admin_required

# Role for migrating membership relationships
# During a SQL upgrade, the following values will be used to create a new role
# that will replace records in the user_tenant_membership table with explicit
# role grants.  After migration, the member_role_id will be used in the API
# add_user_to_project, and member_role_name will be ignored.
# member_role_id = 9fe2ff9ee4384b1894a90878d3e92bab
# member_role_name = _member_

# enforced by optional sizelimit middleware (keystone.middleware:RequestBodySizeLimiter)
# max_request_body_size = 114688

# limit the sizes of user & tenant ID/names
# max_param_size = 64

# similar to max_param_size, but provides an exception for token values
# max_token_size = 8192

# === Logging Options ===
# Print debugging output
# (includes plaintext request logging, potentially including passwords)
# debug = False
debug = False

# Print more verbose output
# verbose = False
verbose = True

# Name of log file to output to. If not set, logging will go to stdout.
# log_file = /var/log/keystone/keystone.log

# The directory to keep log files in (will be prepended to --logfile)
# log_dir = /var/log/keystone
log_dir = /var/log/keystone

# Use syslog for logging.
# use_syslog = False
use_syslog = False

# syslog facility to receive log lines
# syslog_log_facility = LOG_USER

# If this option is specified, the logging configuration file specified is
# used and overrides any other logging options specified. Please see the
# Python logging module documentation for details on logging configuration
# files.
# log_config = logging.conf

# A logging.Formatter log message format string which may use any of the
# available logging.LogRecord attributes.
# log_format = %(asctime)s %(levelname)8s [%(name)s] %(message)s

# Format string for %(asctime)s in log records.
# log_date_format = %Y-%m-%d %H:%M:%S

# onready allows you to send a notification when the process is ready to serve
# For example, to have it notify using systemd, one could set shell command:
# onready = systemd-notify --ready
# or a module with notify() method:
# onready = keystone.common.systemd

# === Notification Options ===

# Notifications can be sent when users or projects are created, updated or
# deleted. There are three methods of sending notifications: logging (via the
# log_file directive), rpc (via a message queue) and no_op (no notifications
# sent, the default)

# notification_driver can be defined multiple times
# Do nothing driver (the default)
# notification_driver = keystone.openstack.common.notifier.no_op_notifier
# Logging driver example (not enabled by default)
# notification_driver = keystone.openstack.common.notifier.log_notifier
# RPC driver example (not enabled by default)
# notification_driver = keystone.openstack.common.notifier.rpc_notifier

# Default notification level for outgoing notifications
# default_notification_level = INFO

# Default publisher_id for outgoing notifications; included in the payload.
# default_publisher_id =

# AMQP topics to publish to when using the RPC notification driver.
# Multiple values can be specified by separating with commas.
# The actual topic names will be %s.%(default_notification_level)s
# notification_topics = notifications

# === RPC Options ===

# For Keystone, these options apply only when the RPC notification driver is
# used.

# The messaging module to use, defaults to kombu.
# rpc_backend = keystone.openstack.common.rpc.impl_kombu

# Size of RPC thread pool
# rpc_thread_pool_size = 64

# Size of RPC connection pool
# rpc_conn_pool_size = 30

# Seconds to wait for a response from call or multicall
# rpc_response_timeout = 60

# Seconds to wait before a cast expires (TTL). Only supported by impl_zmq.
# rpc_cast_timeout = 30

# Modules of exceptions that are permitted to be recreated upon receiving
# exception data from an rpc call.
# allowed_rpc_exception_modules = keystone.openstack.common.exception,nova.exception,cinder.exception,exceptions

# If True, use a fake RabbitMQ provider
# fake_rabbit = False

# AMQP exchange to connect to if using RabbitMQ or Qpid
# control_exchange = openstack

[sql]
# The SQLAlchemy connection string used to connect to the database
# connection = mysql://keystone:keystone at localhost/keystone
connection = mysql://keystone_admin:1817719f79c54395 at openstack-centos65/keystone

# the timeout before idle sql connections are reaped
# idle_timeout = 200
idle_timeout = 200

[identity]
# driver = keystone.identity.backends.sql.Identity

# This references the domain to use for all Identity API v2 requests (which are
# not aware of domains). A domain with this ID will be created for you by
# keystone-manage db_sync in migration 008.  The domain referenced by this ID
# cannot be deleted on the v3 API, to prevent accidentally breaking the v2 API.
# There is nothing special about this domain, other than the fact that it must
# exist to order to maintain support for your v2 clients.
# default_domain_id = default
#
# A subset (or all) of domains can have their own identity driver, each with
# their own partial configuration file in a domain configuration directory.
# Only values specific to the domain need to be placed in the domain specific
# configuration file. This feature is disabled by default; set
# domain_specific_drivers_enabled to True to enable.
# domain_specific_drivers_enabled = False
# domain_config_dir = /etc/keystone/domains

# Maximum supported length for user passwords; decrease to improve performance.
# max_password_length = 4096

[credential]
# driver = keystone.credential.backends.sql.Credential

[trust]
# driver = keystone.trust.backends.sql.Trust

# delegation and impersonation features can be optionally disabled
# enabled = True

[os_inherit]
# role-assignment inheritance to projects from owning domain can be
# optionally enabled
# enabled = False

[catalog]
# dynamic, sql-based backend (supports API/CLI-based management commands)
# driver = keystone.catalog.backends.sql.Catalog
driver = keystone.catalog.backends.sql.Catalog

# static, file-based backend (does *NOT* support any management commands)
# driver = keystone.catalog.backends.templated.TemplatedCatalog

# template_file = /etc/keystone/default_catalog.templates

[endpoint_filter]
# extension for creating associations between project and endpoints in order to
# provide a tailored catalog for project-scoped token requests.
# driver = keystone.contrib.endpoint_filter.backends.sql.EndpointFilter
# return_all_endpoints_if_no_filter = True

[token]
# Provides token persistence.
# driver = keystone.token.backends.sql.Token
driver = keystone.token.backends.sql.Token

# Controls the token construction, validation, and revocation operations.
# Core providers are keystone.token.providers.[pki|uuid].Provider
# provider =
provider =keystone.token.providers.pki.Provider

# Amount of time a token should remain valid (in seconds)
# expiration = 86400
expiration = 86400

# External auth mechanisms that should add bind information to token.
# eg kerberos, x509
# bind =

# Enforcement policy on tokens presented to keystone with bind information.
# One of disabled, permissive, strict, required or a specifically required bind
# mode e.g. kerberos or x509 to require binding to that authentication.
# enforce_token_bind = permissive

# Token specific caching toggle. This has no effect unless the global caching
# option is set to True
# caching = True

# Token specific cache time-to-live (TTL) in seconds.
# cache_time =

# Revocation-List specific cache time-to-live (TTL) in seconds.
# revocation_cache_time = 3600

[cache]
# Global cache functionality toggle.
# enabled = False

# Prefix for building the configuration dictionary for the cache region. This
# should not need to be changed unless there is another dogpile.cache region
# with the same configuration name
# config_prefix = cache.keystone

# Default TTL, in seconds, for any cached item in the dogpile.cache region.
# This applies to any cached method that doesn't have an explicit cache
# expiration time defined for it.
# expiration_time = 600

# Dogpile.cache backend module. It is recommended that Memcache
# (dogpile.cache.memcache) or Redis (dogpile.cache.redis) be used in production
# deployments.  Small workloads (single process) like devstack can use the
# dogpile.cache.memory backend.
# backend = keystone.common.cache.noop

# Arguments supplied to the backend module. Specify this option once per
# argument to be passed to the dogpile.cache backend.
# Example format: <argname>:<value>
# backend_argument =

# Proxy Classes to import that will affect the way the dogpile.cache backend
# functions.  See the dogpile.cache documentation on changing-backend-behavior.
# Comma delimited list e.g. my.dogpile.proxy.Class, my.dogpile.proxyClass2
# proxies =

# Use a key-mangling function (sha1) to ensure fixed length cache-keys. This
# is toggle-able for debugging purposes, it is highly recommended to always
# leave this set to True.
# use_key_mangler = True

# Extra debugging from the cache backend (cache keys, get/set/delete/etc calls)
# This is only really useful if you need to see the specific cache-backend
# get/set/delete calls with the keys/values.  Typically this should be left
# set to False.
# debug_cache_backend = False

[policy]
# driver = keystone.policy.backends.sql.Policy

[ec2]
# driver = keystone.contrib.ec2.backends.sql.Ec2

[assignment]
# driver =

# Assignment specific caching toggle. This has no effect unless the global
# caching option is set to True
# caching = True

# Assignment specific cache time-to-live (TTL) in seconds.
# cache_time =

[oauth1]
# driver = keystone.contrib.oauth1.backends.sql.OAuth1

# The Identity service may include expire attributes.
# If no such attribute is included, then the token lasts indefinitely.
# Specify how quickly the request token will expire (in seconds)
# request_token_duration = 28800
# Specify how quickly the access token will expire (in seconds)
# access_token_duration = 86400

[ssl]
enable = True
certfile = /etc/keystone/ssl/certs/signing_cert.pem
keyfile = /etc/keystone/ssl/private/signing_key.pem
ca_certs = /etc/keystone/ssl/certs/ca.pem
ca_key = /etc/keystone/ssl/certs/cakey.pem
key_size = 1024
valid_days = 3650
cert_required = False
cert_subject = /C=US/ST=Unset/L=Unset/O=Unset/CN=openstack-centos65

[signing]
# Deprecated in favor of provider in the [token] section
# Allowed values are PKI or UUID
#token_format = PKI

#certfile = /etc/keystone/pki/certs/signing_cert.pem
#keyfile = /etc/keystone/pki/private/signing_key.pem
#ca_certs = /etc/keystone/pki/certs/cacert.pem
#ca_key = /etc/keystone/pki/private/cakey.pem
#key_size = 2048
#valid_days = 3650
#cert_subject = /C=US/ST=Unset/L=Unset/O=Unset/CN=www.example.com

[ldap]
# url = ldap://localhost
# user = dc=Manager,dc=example,dc=com
# password = None
# suffix = cn=example,cn=com
# use_dumb_member = False
# allow_subtree_delete = False
# dumb_member = cn=dumb,dc=example,dc=com

# Maximum results per page; a value of zero ('0') disables paging (default)
# page_size = 0

# The LDAP dereferencing option for queries. This can be either 'never',
# 'searching', 'always', 'finding' or 'default'. The 'default' option falls
# back to using default dereferencing configured by your ldap.conf.
# alias_dereferencing = default

# The LDAP scope for queries, this can be either 'one'
# (onelevel/singleLevel) or 'sub' (subtree/wholeSubtree)
# query_scope = one

# user_tree_dn = ou=Users,dc=example,dc=com
# user_filter =
# user_objectclass = inetOrgPerson
# user_id_attribute = cn
# user_name_attribute = sn
# user_mail_attribute = email
# user_pass_attribute = userPassword
# user_enabled_attribute = enabled
# user_enabled_mask = 0
# user_enabled_default = True
# user_attribute_ignore = default_project_id,tenants
# user_default_project_id_attribute =
# user_allow_create = True
# user_allow_update = True
# user_allow_delete = True
# user_enabled_emulation = False
# user_enabled_emulation_dn =

# tenant_tree_dn = ou=Projects,dc=example,dc=com
# tenant_filter =
# tenant_objectclass = groupOfNames
# tenant_domain_id_attribute = businessCategory
# tenant_id_attribute = cn
# tenant_member_attribute = member
# tenant_name_attribute = ou
# tenant_desc_attribute = desc
# tenant_enabled_attribute = enabled
# tenant_attribute_ignore =
# tenant_allow_create = True
# tenant_allow_update = True
# tenant_allow_delete = True
# tenant_enabled_emulation = False
# tenant_enabled_emulation_dn =

# role_tree_dn = ou=Roles,dc=example,dc=com
# role_filter =
# role_objectclass = organizationalRole
# role_id_attribute = cn
# role_name_attribute = ou
# role_member_attribute = roleOccupant
# role_attribute_ignore =
# role_allow_create = True
# role_allow_update = True
# role_allow_delete = True

# group_tree_dn =
# group_filter =
# group_objectclass = groupOfNames
# group_id_attribute = cn
# group_name_attribute = ou
# group_member_attribute = member
# group_desc_attribute = desc
# group_attribute_ignore =
# group_allow_create = True
# group_allow_update = True
# group_allow_delete = True

# ldap TLS options
# if both tls_cacertfile and tls_cacertdir are set then
# tls_cacertfile will be used and tls_cacertdir is ignored
# valid options for tls_req_cert are demand, never, and allow
# use_tls = False
# tls_cacertfile =
# tls_cacertdir =
# tls_req_cert = demand

# Additional attribute mappings can be used to map ldap attributes to internal
# keystone attributes. This allows keystone to fulfill ldap objectclass
# requirements. An example to map the description and gecos attributes to a
# user's name would be:
# user_additional_attribute_mapping = description:name, gecos:name
#
# domain_additional_attribute_mapping =
# group_additional_attribute_mapping =
# role_additional_attribute_mapping =
# project_additional_attribute_mapping =
# user_additional_attribute_mapping =

[auth]
methods = external,password,token,oauth1
#external = keystone.auth.plugins.external.ExternalDefault
password = keystone.auth.plugins.password.Password
token = keystone.auth.plugins.token.Token
oauth1 = keystone.auth.plugins.oauth1.OAuth

[paste_deploy]
# Name of the paste configuration file that defines the available pipelines
# config_file = /usr/share/keystone/keystone-dist-paste.ini

From =?utf-8?B?576K5YWI55Sf?=  Sun Apr 13 19:31:51 2014
From: =?utf-8?B?576K5YWI55Sf?= (=?utf-8?B?576K5YWI55Sf?=)
Date: Sun, 13 Apr 2014 19:31:51 -0000
Subject: [Openstack-security] k4bs
Message-ID: <6E686E4B11E5A9F65845BFE90FF1DAEE@ti.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140413/6c650071/attachment.html>

From vp73nk524975266 at qq.co  Mon Apr 14 01:47:52 2014
From: vp73nk524975266 at qq.co (=?GB2312?B?vaqzybOv?=)
Date: Mon, 14 Apr 2014 01:47:52 -0000
Subject: [Openstack-security] 466555
Message-ID: <mailman.1.1560799085.28383.openstack-security@lists.openstack.org>

openstack-security
---------------------------------------------------------------------------------
466555《全 能 型 车 间 主 任 实 战 技 能 训 练》466555

【时 间】2014年4月19-20深.圳、4月26-27上.海、6月21-22深.圳、6月28-29上.海

【对 象】企业厂长、制造业生产总监、生产经理、车间主任及生产制造主管及一线干部

【会务负责人】１３６ ９１４ ７２８１６   ＱＱ：１３２ １２５ ９１２４（叶　霞）

---------------------------------------------------------------------------------
466555



From ahmed.shohel at ericsson.com  Mon Apr 14 08:18:53 2014
From: ahmed.shohel at ericsson.com (Abu Shohel Ahmed)
Date: Mon, 14 Apr 2014 11:18:53 +0300
Subject: [Openstack-security] Openstack Threat modelling - Common
	Repository
In-Reply-To: <CAFpPvXDmXdcFbQNFetuzM_=5PwgA-Xmhy7WGb2Zt86rhYiGVbA@mail.gmail.com>
References: <B8949B67-B3D4-4D74-9035-14BD8A46E820@ericsson.com>
 <CAFpPvXDmXdcFbQNFetuzM_=5PwgA-Xmhy7WGb2Zt86rhYiGVbA@mail.gmail.com>
Message-ID: <4E1329CC-B41E-4E0D-96D4-835F1E4F4714@ericsson.com>

Hi,

The main purpose of threat modelling is systematically finding the security weakness / threats in the system. In the process, there will be some bug reports related to the implementation,
however IMHO the main contribution should be around design and deployment weakness, which by way the takes longer time to fix or has trade offs related with it ( e.g., the bearer token
issue, adminess issues). Now, some of these are already documented as part of the OSSN, and in the threat modelling we are proactively trying to find new ones in a broader scale. 
The other objective is to document the systematic view and all possible threats per project in a single document / place. IMHO, it should a good fit in the documentation project or 
security guide / Annex of the security guide.  And the issue about format changing (from .doc, .xls), that is something we will gradually perform - should be small amount of manual job -
 if we agreed on the dissemination platform.

The plan to use Gerrit is to add flow to the process and  add peer review obviously.  From another angle, i was thinking, is it a good idea to merge the  work with Security Guides work.
In that case, we can follow the same process ?

Thanks,
Shohel


On 11 Apr 2014, at 19:06, Bryan D. Payne <bdpayne at acm.org> wrote:

> This doesn't strike me as being as good of a fit for the documentation project.  I say this because the output isn't a long lived document that people will reference.  The findings seem to me to be of high value initially, and then (hopefully) things get fixed and then I don't see people referencing the findings much any more.  Please correct me if I'm thinking of this in the wrong light.
> 
> Could you describe a bit more about how you would make of use gerrit here?  Is this just to get some peer review on the findings before presenting them to the projects as bug reports?
> 
> -bryan
> 
> 
> 
> 
> On Fri, Apr 11, 2014 at 1:13 AM, Abu Shohel Ahmed <ahmed.shohel at ericsson.com> wrote:
> Hi,
> 
> Yesterday’s OSSG meeting, we are discussing about Threat Modelling process and more specifically gating and publishing process.
> Currently, the work is hosted in the Security Wiki page:
> 
> https://wiki.openstack.org/wiki/Security/Threat_Analysis
> 
> and  some of the contents are in  
> https://github.com/shohel02/OpenStack_Threat_Modelling.git
> 
> Now, that more people are getting interested and there is a need to have engagement and dissemination strategy.
> We are thinking of  some common GIT repo with Gerit control, similar to OSSN currently has.  Another aspect is, 
> can it be part of the documentation project? We think it is well fitted in that category. What do you guys think ?
> 
> Thanks,
> Shohel
>  
> 
> _______________________________________________
> 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/20140414/96aa6bfc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4163 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140414/96aa6bfc/attachment.bin>

From robert.clark at hp.com  Mon Apr 14 09:02:36 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 14 Apr 2014 09:02:36 +0000
Subject: [Openstack-security] Openstack Threat modelling - Common
 Repository
In-Reply-To: <4E1329CC-B41E-4E0D-96D4-835F1E4F4714@ericsson.com>
Message-ID: <CF715AE4.8E0A%robert.clark@hp.com>

Hi Shohel,

First off, I think you guys are doing great work, it’s something I hope to be more involved with moving forward.

You mention below OSSNs and the Security Guide, I think both have a natural fit with the threat modelling you’re working on. There’s potential to have a chapter on threat modelling but I imagine adding a section to each service’s chapter covering the threat analysis etc would work well. Findings from the threat modelling process will probably result in deployment recommendations in the form of OSSNs or in some cases will identify vulnerabilities, in which case OSSAs or OSSNs depending on the root cause, severity etc.

-Rob


From: Abu Shohel Ahmed <ahmed.shohel at ericsson.com<mailto:ahmed.shohel at ericsson.com>>
Date: Mon, 14 Apr 2014 11:18:53 +0300
To: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>, "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
Cc: Anne Gentle <anne at openstack.org<mailto:anne at openstack.org>>
Subject: Re: [Openstack-security] Openstack Threat modelling - Common Repository

Hi,

The main purpose of threat modelling is systematically finding the security weakness / threats in the system. In the process, there will be some bug reports related to the implementation,
however IMHO the main contribution should be around design and deployment weakness, which by way the takes longer time to fix or has trade offs related with it ( e.g., the bearer token
issue, adminess issues). Now, some of these are already documented as part of the OSSN, and in the threat modelling we are proactively trying to find new ones in a broader scale.
The other objective is to document the systematic view and all possible threats per project in a single document / place. IMHO, it should a good fit in the documentation project or
security guide / Annex of the security guide.  And the issue about format changing (from .doc, .xls), that is something we will gradually perform - should be small amount of manual job -
 if we agreed on the dissemination platform.

The plan to use Gerrit is to add flow to the process and  add peer review obviously.  From another angle, i was thinking, is it a good idea to merge the  work with Security Guides work.
In that case, we can follow the same process ?

Thanks,
Shohel


On 11 Apr 2014, at 19:06, Bryan D. Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:

This doesn't strike me as being as good of a fit for the documentation project.  I say this because the output isn't a long lived document that people will reference.  The findings seem to me to be of high value initially, and then (hopefully) things get fixed and then I don't see people referencing the findings much any more.  Please correct me if I'm thinking of this in the wrong light.

Could you describe a bit more about how you would make of use gerrit here?  Is this just to get some peer review on the findings before presenting them to the projects as bug reports?

-bryan




On Fri, Apr 11, 2014 at 1:13 AM, Abu Shohel Ahmed <ahmed.shohel at ericsson.com<mailto:ahmed.shohel at ericsson.com>> wrote:
Hi,

Yesterday’s OSSG meeting, we are discussing about Threat Modelling process and more specifically gating and publishing process.
Currently, the work is hosted in the Security Wiki page:

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

and  some of the contents are in
https://github.com/shohel02/OpenStack_Threat_Modelling.git

Now, that more people are getting interested and there is a need to have engagement and dissemination strategy.
We are thinking of  some common GIT repo with Gerit control, similar to OSSN currently has.  Another aspect is,
can it be part of the documentation project? We think it is well fitted in that category. What do you guys think ?

Thanks,
Shohel


_______________________________________________
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



_______________________________________________ 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



From anne at openstack.org  Mon Apr 14 13:20:52 2014
From: anne at openstack.org (Anne Gentle)
Date: Mon, 14 Apr 2014 08:20:52 -0500
Subject: [Openstack-security] Openstack Threat modelling - Common
	Repository
In-Reply-To: <B8949B67-B3D4-4D74-9035-14BD8A46E820@ericsson.com>
References: <B8949B67-B3D4-4D74-9035-14BD8A46E820@ericsson.com>
Message-ID: <CAD0KtVFhJyPi0UNwGpVYUk6ymemSdU5KP1pXC89Yark7e=g_Uw@mail.gmail.com>

On Fri, Apr 11, 2014 at 3:13 AM, Abu Shohel Ahmed <ahmed.shohel at ericsson.com
> wrote:

> Hi,
>
> Yesterday's OSSG meeting, we are discussing about Threat Modelling process
> and more specifically gating and publishing process.
> Currently, the work is hosted in the Security Wiki page:
>
> https://wiki.openstack.org/wiki/Security/Threat_Analysis
>
> and  some of the contents are in
> https://github.com/shohel02/OpenStack_Threat_Modelling.git
>
> Now, that more people are getting interested and there is a need to have
> engagement and dissemination strategy.
> We are thinking of  some common GIT repo with Gerit control, similar to
> OSSN currently has.  Another aspect is,
> can it be part of the documentation project? We think it is well fitted in
> that category. What do you guys think ?
>

I'd like to see a thread modeling chapter added to the Security Guide.

I think this fits in nicely with the Documentation Program.

Thanks,
Anne


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

From gerrit2 at review.openstack.org  Mon Apr 14 17:09:11 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 14 Apr 2014 17:09:11 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WZkNb-0007a4-Kl@review.openstack.org>


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

Log:
commit 77f276e178054f72ef7880a0432389746d3656c1
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance.
    
    SecurityImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From bknudson at us.ibm.com  Mon Apr 14 22:28:32 2014
From: bknudson at us.ibm.com (Brant Knudson)
Date: Mon, 14 Apr 2014 22:28:32 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140414222833.8672.21859.launchpad@gac.canonical.com>

** Also affects: horizon
   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/1174499

Title:
  Keystone token hashing is MD5

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

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



From 1305566 at bugs.launchpad.net  Tue Apr 15 06:31:03 2014
From: 1305566 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 15 Apr 2014 06:31:03 -0000
Subject: [Openstack-security] [Bug 1305566] Re: the token still can be used
 if the EC2 credential has been deleted
References: <20140410083249.25765.8738.malonedeb@soybean.canonical.com>
Message-ID: <20140415063103.8839.50892.malone@gac.canonical.com>

Fix proposed to branch: master
Review: https://review.openstack.org/87450

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

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

Title:
  the token still can be used if the EC2 credential has been deleted

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  Currently, the associated tokens are not deleted when deleting ec2
  credential. So, the token got before can still be used.

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



From gerrit2 at review.openstack.org  Tue Apr 15 07:29:49 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 15 Apr 2014 07:29:49 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change Ic17c330eff701ff63701c0029b26db7093a1d73d
Message-ID: <E1WZxoT-0002Pw-Lg@review.openstack.org>


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

Log:
commit bebe906ee7ddcc8785c927b559c930d62e972cbb
Author: Brian Cline <bcline at softlayer.com>
Date:   Tue Apr 15 02:10:28 2014 -0500

    Uses None instead of mutables for function param defaults
    
    Addressing bug 1307878, changes use of mutable lists and dicts as
    default arguments and defaults them within the function. Otherwise,
    those defaults can be unexpectedly persisted with the function between
    invocations and erupt into mass hysteria on the streets.
    
    To my knowledge there aren't known cases of the current use causing
    specific issues, but needs addressing (even stylistically) to avoid
    problems in the future -- ones that may crop up as extremely subtle or
    intermittent bugs...or worse, security vulnerabilities.
    
    In Glance's case there are ACL-related methods using this, so
    although I haven't confirmed one way or the other yet, I've marked it
    with SecurityImpact so that a more knowledgeable set of eyes can
    review it in this context as well.
    
    Closes-Bug: #1307878
    SecurityImpact
    
    Change-Id: Ic17c330eff701ff63701c0029b26db7093a1d73d




From robert.clark at hp.com  Tue Apr 15 08:38:16 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 15 Apr 2014 08:38:16 +0000
Subject: [Openstack-security] Cryptographic Export Controls and OpenStack
Message-ID: <CF72AE8A.9208%robert.clark@hp.com>

Does anyone have a documented run-down of changes that must be made to OpenStack configurations to allow them to comply with EAR requirements? http://www.bis.doc.gov/index.php/policy-guidance/encryption

It seems like something we should consider putting into the security guide. I realise that most of the time it’s just “don’t use your own libraries, call to others, make algorithms configurable” etc but it’s a question I’m seeing more and more, the security guide’s compliance section looks like a great place to have something about EAR.

-Rob



From pengxuhan at gmail.com  Tue Apr 15 09:09:17 2014
From: pengxuhan at gmail.com (Xu Han Peng)
Date: Tue, 15 Apr 2014 09:09:17 -0000
Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall
 anti-spoofing does not prevent ARP poisoning
References: <20140129101504.12361.90017.malonedeb@gac.canonical.com>
Message-ID: <20140415090917.25957.13614.malone@soybean.canonical.com>

For your information, I registered blueprint [1] for RA guard and IPv6
snooping after discussing with IPv6 sub team.

[1] https://blueprints.launchpad.net/neutron/+spec/security-group-ipv6
-ra-guard

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

Title:
  Neutron firewall anti-spoofing does not prevent ARP poisoning

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

Bug description:
  The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning.
  When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature:
  - no-mac-spoofing
  - no-ip-spoofing
  - no-arp-spoofing
  - nova-no-nd-reflection
  - allow-dhcp-server

  Actually, the neutron firewall driver 'iptabes_firawall' handles only
  MAC and IP anti-spoofing rules.

  This is a security vulnerability, especially on shared networks.

  Reproduce an ARP cache poisoning and man in the middle:
  - Create a private network/subnet 10.0.0.0/24
  - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4)
  - Log on VM1 and install ettercap [1]
  - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:'
  - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok
  - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2]
  - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1

  [1] http://ettercap.github.io/ettercap/
  [2] http://paste.openstack.org/show/62112/

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



From edouard.thuleau at cloudwatt.com  Tue Apr 15 09:44:39 2014
From: edouard.thuleau at cloudwatt.com (=?utf-8?q?=C3=89douard_Thuleau?=)
Date: Tue, 15 Apr 2014 09:44:39 -0000
Subject: [Openstack-security] [Bug 1274034] Re: Neutron firewall
 anti-spoofing does not prevent ARP poisoning
References: <20140129101504.12361.90017.malonedeb@gac.canonical.com>
Message-ID: <20140415094439.9052.49833.malone@gac.canonical.com>

@Kevin: Thanks for your backportable patch. I still need to rebase and
proposed my patch (some UT need to be coded)

@Xu Han Peng: Thanks to create that patch to prevent RA and FHS IPv6
directly to the egress traffic port.

When I writing my patch, I though it could be better to separate first hop security port (spoofing, ARP, DHCP, RA, ND...) to the security group. I think it's two different things. For example, actually, to protect DHCP spoofing, we add provider security group to the security group of a port. But that security group is not visible by the user.
To separate FHS to SG, we need to implement specific RPC calls between API servers and agents. It's a huge work.
Any thoughts ?

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

Title:
  Neutron firewall anti-spoofing does not prevent ARP poisoning

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

Bug description:
  The neutron firewall driver 'iptabes_firawall' does not prevent ARP cache poisoning.
  When anti-spoofing rules are handled by Nova, a list of rules was added through the libvirt network filter feature:
  - no-mac-spoofing
  - no-ip-spoofing
  - no-arp-spoofing
  - nova-no-nd-reflection
  - allow-dhcp-server

  Actually, the neutron firewall driver 'iptabes_firawall' handles only
  MAC and IP anti-spoofing rules.

  This is a security vulnerability, especially on shared networks.

  Reproduce an ARP cache poisoning and man in the middle:
  - Create a private network/subnet 10.0.0.0/24
  - Start 2 VM attached to that private network (VM1: IP 10.0.0.3, VM2: 10.0.0.4)
  - Log on VM1 and install ettercap [1]
  - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output:'
  - Log on too on VM2 (with VNC/spice console) and ping google.fr => ping is ok
  - Go back on VM1, and see the VM2's ping to google.fr going to the VM1 instead to be send directly to the network gateway and forwarded by the VM1 to the gw. The ICMP capture looks something like that [2]
  - Go back to VM2 and check the ARP table => the MAC address associated to the GW is the MAC address of VM1

  [1] http://ettercap.github.io/ettercap/
  [2] http://paste.openstack.org/show/62112/

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



From gerrit2 at review.openstack.org  Tue Apr 15 20:48:34 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 15 Apr 2014 20:48:34 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WaAHS-0001mI-Ch@review.openstack.org>


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

Log:
commit a11fe896311898bd993f1c5bf78e1e1edc2f1d0f
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance.
    
    SecurityImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From gerrit2 at review.openstack.org  Tue Apr 15 21:36:30 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 15 Apr 2014 21:36:30 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WaB1q-0006sJ-8d@review.openstack.org>


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

Log:
commit e2737f13d553931deae83f843d9a62dbd7fe5063
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From m.koderer at telekom.de  Wed Apr 16 13:09:00 2014
From: m.koderer at telekom.de (Koderer, Marc)
Date: Wed, 16 Apr 2014 15:09:00 +0200
Subject: [Openstack-security] Fuzzy test framework Dev Session in Atlanta
Message-ID: <FD9023AAE9C10145BD4DDD6CB11F8D580D49F2588D@QEO40075.de.t-online.corp>

Hi folks,

I just want to let you know that I registered a dev session about the fuzzy testing framework:

http://summit.openstack.org/cfp/details/323

Since I hadn't too much time to work on the BP I think it's worth to have a detailed dev talk about it.
Are you planning other session in Atlanta? I am open to move the topic from QA to OSSG if needed.

Regards
Marc


DEUTSCHE TELEKOM AG
Digital Business Unit, Cloud Services (P&I)
Marc Koderer
Cloud Technology Software Developer
T-Online-Allee 1, 64211 Darmstadt
E-Mail: m.koderer at telekom.de
www.telekom.com   

LIFE IS FOR SHARING. 

DEUTSCHE TELEKOM AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: René Obermann (Chairman),
Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges,
Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick
Commercial register: Amtsgericht Bonn HRB 6794
Registered office: Bonn

BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL.



From bdpayne at acm.org  Wed Apr 16 16:11:35 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 16 Apr 2014 09:11:35 -0700
Subject: [Openstack-security] Fuzzy test framework Dev Session in Atlanta
In-Reply-To: <FD9023AAE9C10145BD4DDD6CB11F8D580D49F2588D@QEO40075.de.t-online.corp>
References: <FD9023AAE9C10145BD4DDD6CB11F8D580D49F2588D@QEO40075.de.t-online.corp>
Message-ID: <CAFpPvXAcHVxSJA8_wFViFdm3Z0th_T+HWUhBMwxEdF+gi+KRjA@mail.gmail.com>

QA actually sounds like a good place for this as it will need lots of input
from that community.  I'll watch for it in the schedule and plan on
attending.  Thanks for the heads up!

-bryan


On Wed, Apr 16, 2014 at 6:09 AM, Koderer, Marc <m.koderer at telekom.de> wrote:

> Hi folks,
>
> I just want to let you know that I registered a dev session about the
> fuzzy testing framework:
>
> http://summit.openstack.org/cfp/details/323
>
> Since I hadn't too much time to work on the BP I think it's worth to have
> a detailed dev talk about it.
> Are you planning other session in Atlanta? I am open to move the topic
> from QA to OSSG if needed.
>
> Regards
> Marc
>
>
> DEUTSCHE TELEKOM AG
> Digital Business Unit, Cloud Services (P&I)
> Marc Koderer
> Cloud Technology Software Developer
> T-Online-Allee 1, 64211 Darmstadt
> E-Mail: m.koderer at telekom.de
> www.telekom.com
>
> LIFE IS FOR SHARING.
>
> DEUTSCHE TELEKOM AG
> Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
> Board of Management: René Obermann (Chairman),
> Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges,
> Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick
> Commercial register: Amtsgericht Bonn HRB 6794
> Registered office: Bonn
>
> BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL.
>
> _______________________________________________
> 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/20140416/abdc62b1/attachment.html>

From gerrit2 at review.openstack.org  Wed Apr 16 17:10:18 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 16 Apr 2014 17:10:18 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WaTLm-0002MX-0e@review.openstack.org>


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

Log:
commit bd4dc2232e2ebffe484618622ea139adf53ce9b8
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance.
    
    SecurityImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From bdpayne at acm.org  Wed Apr 16 17:28:15 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 16 Apr 2014 10:28:15 -0700
Subject: [Openstack-security] Cryptographic Export Controls and OpenStack
In-Reply-To: <CF72AE8A.9208%robert.clark@hp.com>
References: <CF72AE8A.9208%robert.clark@hp.com>
Message-ID: <CAFpPvXBGzQiJc9AH2Tqh5e89L2YoOu21cKhrLYOdxFJeGRbhyQ@mail.gmail.com>

I'm not aware of a list of the specific changes, but this seems quite
related to the work that Nathan has started played with... discussed on his
blog here:

https://blog-nkinder.rhcloud.com/?p=51

Cheers,
-bryan



On Tue, Apr 15, 2014 at 1:38 AM, Clark, Robert Graham
<robert.clark at hp.com>wrote:

> Does anyone have a documented run-down of changes that must be made to
> OpenStack configurations to allow them to comply with EAR requirements?
> http://www.bis.doc.gov/index.php/policy-guidance/encryption
>
> It seems like something we should consider putting into the security
> guide. I realise that most of the time it’s just “don’t use your own
> libraries, call to others, make algorithms configurable” etc but it’s a
> question I’m seeing more and more, the security guide’s compliance section
> looks like a great place to have something about EAR.
>
> -Rob
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140416/6bbb85e8/attachment.html>

From 1262759 at bugs.launchpad.net  Wed Apr 16 17:39:46 2014
From: 1262759 at bugs.launchpad.net (Openstack Gerrit)
Date: Wed, 16 Apr 2014 17:39:46 -0000
Subject: [Openstack-security] [Bug 1262759] Fix proposed to neutron
	(milestone-proposed)
References: <20131219170628.26400.87374.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140416173946.18921.59574.malone@chaenomeles.canonical.com>

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/88034

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

Title:
  ICMPv6 RAs should only be permitted from known routers

Status in OpenStack Neutron (virtual network service):
  Fix Committed
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 1174499 at bugs.launchpad.net  Thu Apr 17 02:59:54 2014
From: 1174499 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 17 Apr 2014 02:59:54 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140417025956.24203.93583.launchpad@wampee.canonical.com>

** Changed in: python-keystoneclient
    Milestone: 0.8.0 => None

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

Title:
  Keystone token hashing is MD5

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

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



From robert.clark at hp.com  Thu Apr 17 07:19:43 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Thu, 17 Apr 2014 07:19:43 +0000
Subject: [Openstack-security] Fuzzy test framework Dev Session in Atlanta
In-Reply-To: <CAFpPvXAcHVxSJA8_wFViFdm3Z0th_T+HWUhBMwxEdF+gi+KRjA@mail.gmail.com>
Message-ID: <CF753EE4.97D7%robert.clark@hp.com>

Agreed, looks exciting.

Bryan – should we look to make a schedule that highlights all the interesting talks/sessions for the summit ?

From: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>
Date: Wed, 16 Apr 2014 09:11:35 -0700
To: "Koderer, Marc" <m.koderer at telekom.de<mailto:m.koderer at telekom.de>>
Cc: "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
Subject: Re: [Openstack-security] Fuzzy test framework Dev Session in Atlanta

QA actually sounds like a good place for this as it will need lots of input from that community.  I'll watch for it in the schedule and plan on attending.  Thanks for the heads up!

-bryan


On Wed, Apr 16, 2014 at 6:09 AM, Koderer, Marc <m.koderer at telekom.de<mailto:m.koderer at telekom.de>> wrote:
Hi folks,

I just want to let you know that I registered a dev session about the fuzzy testing framework:

http://summit.openstack.org/cfp/details/323

Since I hadn't too much time to work on the BP I think it's worth to have a detailed dev talk about it.
Are you planning other session in Atlanta? I am open to move the topic from QA to OSSG if needed.

Regards
Marc


DEUTSCHE TELEKOM AG
Digital Business Unit, Cloud Services (P&I)
Marc Koderer
Cloud Technology Software Developer
T-Online-Allee 1, 64211 Darmstadt
E-Mail: m.koderer at telekom.de<mailto:m.koderer at telekom.de>
www.telekom.com<http://www.telekom.com>

LIFE IS FOR SHARING.

DEUTSCHE TELEKOM AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: René Obermann (Chairman),
Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges,
Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick
Commercial register: Amtsgericht Bonn HRB 6794
Registered office: Bonn

BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL.

_______________________________________________
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

_______________________________________________ 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



From thierry.carrez+lp at gmail.com  Thu Apr 17 07:25:27 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 07:25:27 -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: <20140417072530.18502.11721.launchpad@chaenomeles.canonical.com>

** Changed in: oslo
    Milestone: icehouse-2 => 2014.1

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

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

Status in OpenStack Compute (Nova):
  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 thierry.carrez+lp at gmail.com  Thu Apr 17 07:38:03 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 07:38:03 -0000
Subject: [Openstack-security] [Bug 1081795] Re: oslo.rootwrap IpFilter fails
 to prevent ip netns exec
References: <20121121214352.19413.92008.malonedeb@wampee.canonical.com>
Message-ID: <20140417073805.24956.76591.launchpad@wampee.canonical.com>

** Changed in: oslo
    Milestone: icehouse-rc1 => 2014.1

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

Title:
  oslo.rootwrap IpFilter fails to prevent ip netns exec

Status in Oslo - a Library of Common OpenStack Code:
  Fix Released

Bug description:
  This is an oslo.rootwrap bug.

  IpFilter is designed to allow any ip command, unless the second
  parameter is "netns" (in which case you only allow ip netns
  {list,add,delete}.

  The trick is it's trivial to work around this (just run 'ip -s netns
  exec').

  Once that's fixed, Nova should update from using a CommandFilter to
  using the IpFilter for calling 'ip'.

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



From thierry.carrez+lp at gmail.com  Thu Apr 17 08:00:18 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 08:00:18 -0000
Subject: [Openstack-security] [Bug 1279849] Re: keystone password creation
	and verification mismatch
References: <20140213153829.1383.20321.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140417080019.26997.94393.launchpad@gac.canonical.com>

** Changed in: keystone
    Milestone: icehouse-3 => 2014.1

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

Title:
  keystone password creation and verification mismatch

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  In keystone stable/Havana release,  password for a user can be set
  during user creation process. Now if a user initially do a sha512 hash
  of his password and sent it to the keystone server over the wire, then
  hash_password method of  keystone/common/utils.py

  
  def hash_password(password):
     ~                          |    """Hash a password. Hard."""
     ~                          |    password_utf8 = trunc_password(password).encode('utf-8')
     ~                          |    if passlib.hash.sha512_crypt.identify(password_utf8):
     ~                          |        return password_utf8
     ~                          |    h = passlib.hash.sha512_crypt.encrypt(password_utf8,
     ~                          |                                          rounds=CONF.crypt_strength)
     ~                          |    return h

  will not do any hashing, or it directly store the password in DB.

  However, during authentication, the user needs to provide the clear
  text password for authentication because during authentication it
  always does sha512 over the password field (it does not check the
  password is already hashed)

  def check_password(password, hashed):
    ""Check that a plaintext password matches hashed.
      hashpw returns the salt value concatenated with the actual hash value.
     It extracts the actual salt if this value is then passed as the salt.

     """
           if password is None or hashed is None:
                    return False
           password_utf8 = trunc_password(password).encode('utf-8')
           return passlib.hash.sha512_crypt.verify(password_utf8, hashed)


  Now in this case,
  1)  user chooses a password which is similar to a sha512 output, now keystone thinks it is already hashed, so it will store it as it is. User provides the sha512 during authentication but he cannot login this time cause now the password is hashed before matching.

  There should be consistency for both password creation and
  verification process.

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



From thierry.carrez+lp at gmail.com  Thu Apr 17 07:58:28 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 07:58:28 -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: <20140417075829.26949.10905.launchpad@gac.canonical.com>

** Changed in: keystone
    Milestone: icehouse-2 => 2014.1

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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  Thu Apr 17 07:58:18 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 07:58:18 -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: <20140417075820.24335.32153.launchpad@wampee.canonical.com>

** Changed in: keystone
    Milestone: icehouse-2 => 2014.1

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

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

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  Won't Fix

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  Thu Apr 17 08:07:56 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 08:07:56 -0000
Subject: [Openstack-security] [Bug 1300274] Re: [0SSA 2014-013] V3
 Authentication Chaining - uniqueness of auth method names (CVE-2014-2828)
References: <20140331151221.30715.87577.malonedeb@gac.canonical.com>
Message-ID: <20140417080758.19100.77452.launchpad@chaenomeles.canonical.com>

** Changed in: keystone
    Milestone: icehouse-rc2 => 2014.1

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

Title:
  [0SSA 2014-013] V3 Authentication Chaining - uniqueness of auth method
  names (CVE-2014-2828)

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released

Bug description:
  In V3.0 API,  we can chain authentication methods. An attacker can
  place the same authentication method multiple times in the methods
  filed. This will result in the same authentication method checking
  over and over (for loop in code).  Using this, an attacker can achieve
  some sorts of Denial of Service.   The methods field is not properly
  sanitized.

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "password",
               "password",
               "password",
               "password" 
           ],
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"demo",
                 "password":"stack"
              }
           }
        }
     }
  }

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



From thierry.carrez+lp at gmail.com  Thu Apr 17 08:05:28 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 08:05:28 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
 communication fails to check certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20140417080532.19100.76775.launchpad@chaenomeles.canonical.com>

** Changed in: keystone
    Milestone: icehouse-rc1 => 2014.1

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

Title:
  Some server-side 'SSL' communication fails to check certificates (use
  of HTTPSConnection)

Status in Cinder:
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Neutron (virtual network service):
  In Progress
Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released
Status in Python client library for Keystone:
  Fix Released
Status in OpenStack Object Storage (Swift):
  Invalid

Bug description:
  Grant Murphy from Red Hat reported usage of httplib.HTTPSConnection
  objects. In Python 2.x those do not perform CA checks so client
  connections are vulnerable to MiM attacks.

  """
  The following files use httplib.HTTPSConnection :
  keystone/middleware/s3_token.py
  keystone/middleware/ec2_token.py
  keystone/common/bufferedhttp.py
  vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

  AFAICT HTTPSConnection does not validate server certificates and
  should be avoided. This is fixed in Python 3, however in 2.X no
  validation occurs. I suspect this is also applicable to most OpenStack
  modules that make HTTPS client calls.

  Similar problems were found in ovirt:
  https://bugzilla.redhat.com/show_bug.cgi?id=851672 (CVE-2012-3533)

  With solutions for ovirt:
  http://gerrit.ovirt.org/#/c/7209/
  http://gerrit.ovirt.org/#/c/7249/
  """

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



From thierry.carrez+lp at gmail.com  Thu Apr 17 08:49:49 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 08:49:49 -0000
Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been
 print in log by some API call
References: <20130926055439.7490.27811.malonedeb@gac.canonical.com>
Message-ID: <20140417084951.24773.58406.launchpad@wampee.canonical.com>

** Changed in: nova
    Milestone: icehouse-1 => 2014.1

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

Title:
  Clear text password has been print in log by some API call

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) havana series:
  Fix Released

Bug description:
  In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova.
  i.e:

  2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': <nova.api.openstack.wsgi.Resource object at 0x46d09d0>, 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f
  f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103
  2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926

  This is not secue which the password should be replaced by ***

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



From thierry.carrez+lp at gmail.com  Thu Apr 17 08:57:50 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 08:57:50 -0000
Subject: [Openstack-security] [Bug 1247217] Re: Sanitize passwords when
 logging payload in wsgi for API Extensions
References: <20131101180555.24208.66851.malonedeb@gac.canonical.com>
Message-ID: <20140417085752.27069.98871.launchpad@gac.canonical.com>

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

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

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

Status in OpenStack Compute (Nova):
  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 thierry.carrez+lp at gmail.com  Thu Apr 17 09:19:00 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 09:19:00 -0000
Subject: [Openstack-security] [Bug 1290537] Re: [0SSA 2014-011] RBAC policy
 not enforced when adding a security group rule using EC2 API
 (CVE-2014-0167)
References: <20140310202059.13934.40594.malonedeb@gac.canonical.com>
Message-ID: <20140417091903.18791.46696.launchpad@chaenomeles.canonical.com>

** Changed in: nova
    Milestone: icehouse-rc2 => 2014.1

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

Title:
  [0SSA 2014-011] RBAC policy not enforced when adding a security group
  rule using EC2 API (CVE-2014-0167)

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released

Bug description:
  
  It seems that when using the EC2 API, the security group implementation does not enforce RBAC policy for the add_rules, remove_rules, destroy and other functions (in compute/api.py). Only the add_to_instance and remove_from_instance functions enforce RBAC. This seems like an oversight for obvious reasons.

  The Nova API security group implementation does enforce RBAC on these
  functions.

  In addition, the add_to_instance and remove_from _instance functions
  which are wrapped in RBAC verification use the
  "compute:security_groups" action which is not even listed in the
  default /etc/nova/policy.json. The latter is confusing to users.

  This is the case on Grizlly and at first glance, it doesn't look like
  this has changed in Havana.

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



From thierry.carrez+lp at gmail.com  Thu Apr 17 09:32:43 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 09:32:43 -0000
Subject: [Openstack-security] [Bug 1250101] Re: Cinder's rootwrap filters
 allow to run find as root, which allows arbitrary commands
References: <20131111144450.24249.16674.malonedeb@gac.canonical.com>
Message-ID: <20140417093245.27207.42465.launchpad@gac.canonical.com>

** Changed in: cinder
    Milestone: icehouse-3 => 2014.1

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

Title:
  Cinder's rootwrap filters allow to run find as root, which allows
  arbitrary commands

Status in Cinder:
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Invalid
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  The patch
  https://github.com/openstack/cinder/commit/688c515b9d662486395d36c303ca599376a1dc0d
  added the find command to etc/cinder/rootwrap.d/volume.filters. This
  introduces a security hole as the find command is able to call exec,
  and so the cinder user can run any command as root. For example:

  vagrant at controller:~$ sudo -u cinder bash
  cinder at controller:~$ id
  uid=109(cinder) gid=115(cinder) groups=115(cinder)

  cinder at controller:~$ sudo /usr/bin/cinder-rootwrap
  /etc/cinder/rootwrap.conf find /etc/hosts -exec bash \;

  root at controller:~# id
  uid=0(root) gid=0(root) groups=0(root)

  
  I guess the way to fix this is to add a FindFilter to Oslo that rejects calls to find with the -exec or -execdir argument.

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



From thierry.carrez+lp at gmail.com  Thu Apr 17 09:59:25 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 09:59:25 -0000
Subject: [Openstack-security] [Bug 1289033] Re: [OSSA-2014-010] XSS in
 Horizon-Orchestration (CVE-2014-0157)
References: <20140306223232.13317.99583.malonedeb@gac.canonical.com>
Message-ID: <20140417095927.24269.58590.launchpad@wampee.canonical.com>

** Changed in: horizon
    Milestone: icehouse-rc2 => 2014.1

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

Title:
  [OSSA-2014-010] XSS in Horizon-Orchestration (CVE-2014-0157)

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Dashboard (Horizon) havana series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released

Bug description:
  *Description*
  XSS vulnerability identified in Horizon-Orchestration while uploading a stack template.
  Arbitrary Javascript code may be introduced via the "Description" fields of Heat templates; such code was found to be executed by Horizon.

  *Threat Description*
  -Potential Adversaries: malicious Heat templates owners/malicious Heat templates catalogs.
  -Potential Assets: horizon user/admin access credentials (session cookies/CSRF tokens), VMs/Network configuration/management, tenants confidential informartion, etc.
  -Potential Threats: Malicious Heat template owner/catalog makes an Horizon user to utilize a malicious template, which once introduced in Horizon obtains user access credentials and send them back to the attacker. 

  *Environment*
  One node with Devstack over Ubuntu13.10, latest Icehouse code, Firefox web browser and the following OpenStack configuration:
  shell, key, horizon, g-reg, g-api, n-api, n-cpu, n-cond, n-crt, n-net, n-sch, n-novnc, n-xvnc, n-cauth, n-obj, c-api, c-sch, c-vol, ceilometer-acompute, ceilometer-acentral, ceilometer-collector, ceilometer-api, ceilometer-alarm-notifier, ceilometer-alarm-evaluator, h-eng, h-api, h-api-cfn, h-api-cw  

  *Steps to reproduce*
  1- Sign-in to Horizon and click on Orchestration/Stack section.
  2- Click on "Launch Stack"
  3- Select "Direct input", and copy-paste into "Template data" the contents of some template (I have used: 
  https://github.com/openstack/heat-templates/blob/master/cfn/F17/AutoScalingMultiAZSample.template)
  4- Update the contents of the DBUsername "Description" field with the following:
     "DBUsername": {
  	...
        "Description" : "<script>alert('XSS!!!')</script>",
  	...
      },
  5- Click on Next
  6- Being on the Launch Stack form, click on DBUsername text box as if you were going to modify its value.
  7- A pop-up saying "XSS!!!" will appear, confirming the XSS vulnerability.

  *How to fix*
  - Perform input validation for "Description" fields in templates (need to take into account all template input methods: upload from URL, upload from file, direct input).
  - Perform output sanitization when displaying template's "Description" messages.

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



From thierry.carrez+lp at gmail.com  Thu Apr 17 10:15:03 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 10:15:03 -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: <20140417101505.26670.84338.launchpad@gac.canonical.com>

** Changed in: heat
    Milestone: icehouse-2 => 2014.1

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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  Thu Apr 17 11:07:10 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 11:07:10 -0000
Subject: [Openstack-security] [Bug 1251518] Re: Glance needs a config option
 to limit the number of additional image properties
References: <20131115051405.19741.28287.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140417110713.26566.46299.launchpad@gac.canonical.com>

** Changed in: glance
    Milestone: icehouse-1 => 2014.1

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

Title:
  Glance needs a config option to limit the number of additional image
  properties

Status in OpenStack Image Registry and Delivery Service (Glance):
  Fix Released
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  Impact: The vulnerability occurs when glance is directly exposed to
  users.  If users can only hit glance via the compute API, then no
  vulnerability.

  Nova has a configuration option quota_metadata_items (default value
  128) that's documented to limit the number of metadata items that can
  be put on an instance. (I verified that it also applies to image
  metadata using a havana devstack.)

  Glance does not appear to have such an option (I was able to put >500
  additional properties on an image using the glanceclient). I think
  this is a DOS attack vector, since someone could fill the glance
  database with garbage and slow everything down.

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



From thierry.carrez+lp at gmail.com  Thu Apr 17 13:18:17 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Apr 2014 13:18:17 -0000
Subject: [Openstack-security] [Bug 1299012] Re: V3 api authentication method
	chaining
References: <20140328141330.5958.57146.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140417131818.4508.77335.launchpad@soybean.canonical.com>

** Tags removed: icehouse-rc-potential
** Tags added: icehouse-backport-potential

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

Title:
  V3 api authentication method chaining

Status in OpenStack Identity (Keystone):
  In Progress
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  When using authentication method chaining for token creation (POST)
  in Keystone V3 api , it is possible to use authentication credentials
  for two different users . For example, if i have an existing token for
  a Demo user, say 6bb934a0120f097a32b5d3cc71f83beb ( created earlier
  for demo tenant) and i have a user say 'test131' in admin tenant

  Now i can make an authentication call using auth method chaining

  {
     "auth":{
        "identity":{
           "methods":[
              "password",
              "token" 
           ],
          "token":{
              "id":"6bb934a0120f097a32b5d3cc71f83beb"
           },
          "password":{
              "user":{
                 "domain":{
                    "id":"default"
                 },
                 "name":"test131",
                 "password":"test131"
              }
           }
        }
     }
  }

  The call will succeed even though two different users authentication
  credentials are used.  The generated token will get properties of
  test131 user although the expirary date is set by demo user token.  If
  we change the methods sequence, the generated token will get all
  properties from demo users token.

  
  This is an undesired security behaviour - token should not  be allowed to generate using credentials from two different users.

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



From oguzyarimtepe at gmail.com  Thu Apr 17 14:49:25 2014
From: oguzyarimtepe at gmail.com (=?UTF-8?B?T8SfdXogWWFyxLFtdGVwZQ==?=)
Date: Thu, 17 Apr 2014 17:49:25 +0300
Subject: [Openstack-security] architectural question about security as a
	service
Message-ID: <CAKtWOTS0pJQJ+rgtytCKqs2b206-9n9XawdVJY-rFxf2kwcPng@mail.gmail.com>

Hi,

I am working on a project to create a DDoS as a service. My aim was to
focus on web based attacks so i was planning to make my design using DNS
redirection and reverse proxy type architecture. This is quiet a clean
solution for me.

Now  i am thinking what will i do if i want to define prevention methods
for different protocols and want a design that will work tenant base.
Whenever a tenant is asked, only for the required machines or subnets, the
requests coming from Internet should be passing through a couple of IDS/IPS
structure that i designed. I am not sure how to do it or where to start for
reading about it.

Any suggestion or a sample architectural design will be welcomed.



-- 
Oğuz Yarımtepe
http://about.me/oguzy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140417/5ee3a6da/attachment.html>

From gerrit2 at review.openstack.org  Thu Apr 17 15:56:51 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 17 Apr 2014 15:56:51 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WaogF-0006Nk-IN@review.openstack.org>


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

Log:
commit 04852e6ce32ec90ef5d7dd1864af394580bd33b2
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From bdpayne at acm.org  Thu Apr 17 17:03:00 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Thu, 17 Apr 2014 10:03:00 -0700
Subject: [Openstack-security] Fuzzy test framework Dev Session in Atlanta
In-Reply-To: <CF753EE4.97D7%robert.clark@hp.com>
References: <CAFpPvXAcHVxSJA8_wFViFdm3Z0th_T+HWUhBMwxEdF+gi+KRjA@mail.gmail.com>
 <CF753EE4.97D7%robert.clark@hp.com>
Message-ID: <CAFpPvXAxBY+NDJaLWKdz0x0HXhUYND5PCKUTr+tc6wR1o50Kxw@mail.gmail.com>

>
> Bryan – should we look to make a schedule that highlights all the
> interesting talks/sessions for the summit ?
>

We have done this in the past and I'm not sure that others have found it
too useful / valuable.  May not be worth the effort this time around.
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140417/a7d0332f/attachment.html>

From nkinder at redhat.com  Thu Apr 17 23:27:30 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Thu, 17 Apr 2014 16:27:30 -0700
Subject: [Openstack-security] Cryptographic Export Controls and OpenStack
In-Reply-To: <CAFpPvXBGzQiJc9AH2Tqh5e89L2YoOu21cKhrLYOdxFJeGRbhyQ@mail.gmail.com>
References: <CF72AE8A.9208%robert.clark@hp.com>
 <CAFpPvXBGzQiJc9AH2Tqh5e89L2YoOu21cKhrLYOdxFJeGRbhyQ@mail.gmail.com>
Message-ID: <53506362.3020106@redhat.com>

On 04/16/2014 10:28 AM, Bryan D. Payne wrote:
> I'm not aware of a list of the specific changes, but this seems quite
> related to the work that Nathan has started played with... discussed on
> his blog here:
> 
> https://blog-nkinder.rhcloud.com/?p=51

This is definitely related to the security audit effort that I'm
driving.  It's hard to make recommendations on configurations and
deployment architectures from a security perspective when we don't even
have a clear picture of the current state of things are in the code from
a security standpoint.  This clear picture is what I'm trying to get to
right now (along with keeping this picture up to date so it doesn't get
stale).

Once we know things such as what crypto algorithms are used and how
sensitive data is being handled, we can see what is configurable and
make recommendations.  We'll surely find that not everything is
configurable and sensitive data isn't well protected in areas, which are
things that we can turn into blueprints and bugs and work on improving
in development.

It's still up in the air as to where this information should be
published once it's been compiled.  It might be on the wiki, or possibly
in the documentation (Security Guide seems like a likely candidate).
There was some discussion of this with the PTLs from the Project Meeting
from 2 weeks ago:


http://eavesdrop.openstack.org/meetings/project/2014/project.2014-04-08-21.03.html

I'm not so worried myself about where this should be published, as that
doesn't matter if we don't have accurate and comprehensive information
collected in the first place.  My current focus is on the collection and
maintenance of this info on a project by project basis.  Keystone and
Heat have started, which is great!:

  https://wiki.openstack.org/wiki/Security/Icehouse/Keystone
  https://wiki.openstack.org/wiki/Security/Icehouse/Heat

If any other OSSG members are developers on any of the projects, it
would be great if you could help drive this effort within your project.

Thanks,
-NGK
> 
> Cheers,
> -bryan
> 
> 
> 
> On Tue, Apr 15, 2014 at 1:38 AM, Clark, Robert Graham
> <robert.clark at hp.com <mailto:robert.clark at hp.com>> wrote:
> 
>     Does anyone have a documented run-down of changes that must be made
>     to OpenStack configurations to allow them to comply with EAR
>     requirements?
>     http://www.bis.doc.gov/index.php/policy-guidance/encryption
> 
>     It seems like something we should consider putting into the security
>     guide. I realise that most of the time it’s just “don’t use your own
>     libraries, call to others, make algorithms configurable” etc but
>     it’s a question I’m seeing more and more, the security guide’s
>     compliance section looks like a great place to have something about EAR.
> 
>     -Rob
> 
>     _______________________________________________
>     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
> 
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 




From mhu at enovance.com  Fri Apr 18 15:57:51 2014
From: mhu at enovance.com (Matthieu Huin)
Date: Fri, 18 Apr 2014 15:57:51 -0000
Subject: [Openstack-security] [Bug 1236675] Re: Keystone getting oauth
 access token by brute-forcing oauth_verifier code
References: <20131008030759.26826.41914.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140418155752.4116.86225.launchpad@soybean.canonical.com>

** Changed in: keystone
     Assignee: (unassigned) => Matthieu Huin (mhu-s)

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

Title:
  Keystone getting oauth access token by brute-forcing oauth_verifier
  code

Status in OpenStack Identity (Keystone):
  Confirmed

Bug description:
  Title: Keystone getting oauth access token by brute-forcing
  oauth_verifier code
  Reporter: Phuong Cao
  Products: openstack/keystone
  Affects: keystone/master branch as of Oct 7th 2013

  Description:
  Phuong Cao reported a vulnerability in OAuth SQL backend of
  keystone/master branch.

  How does the attack work?
  By creating many access token requests with oauth_verifier code selected
  from the range 1000 to 9999,
  an attacker can request a valid access token to a role and a project,
  overriding a user who actually request access to the role and the project.

  Before describing in detail how the attack works, this is how OAuth
  works (summarized from RFC5849)

  1. Alice registers as a consumer with the Openstack admin.
  2. Alice asks the Openstack admin a token with a specified role and a
  project on behalf of Bob (Bob is the owner of the project).
  3. The Openstack admin returns to Alice a request token key.
  4. Alice sends the request token key to Bob to ask for permissions to
  access the project.
  5. Bob authorizes Alice's request token to have access to the project
  with the specified role.
  6. Bob generates an oauth_verifier code ranging from 1000 to 9999, then
  sends back to Alice an oauth_verifier code.
  7. Alice use the oauth_verifier code and the request token key to ask
  the Openstack admin for the access token to the project.

  This is how the attack works:
  At step 4, assuming an attacker can sniff Alice's request token key.
  This can be done by acting as a man in the middle if Alice interacts
  with Keystone using HTTP requests,
  or acting as a local user to list the process arguments if Alice is
  interacts with Keystone using openstack commandline tools (this case is
  similar to CVE 2013-2013).

  Now the attacker has Alice's request token key, he/she need to wait for
  Bob to authorizes Alice's request token (step 5), then repeatedly
  brute-forcing Keystone with the pair(oauth_verifier, Alice's request
  token key) using oauth_verifier from the range 1000 to 9999. Since the
  oauth_verifier is in a short range, and Openstack/Keystone doesn't have
  any mechanism to limit number of requests, the attacker can bruteforce
  for the valid oauth_verifier key until the request token expires.

  A more aggressive way is to keep brute-forcing Keystone until Bob
  authorizes Alice's request token, by doing this the attacker will have
  more chance getting the access token key before Alice.

  Where are the vulnerable code locations?
  Line 210 of sql.py file:
  https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210

  In OAuth SQL backend of keystone/master branch, the oauth_verifier code,
  a fundamental part of OAuth1 protocol, is generated using random numbers
  from 1000 to 9999.
  This is a small range of numbers and it is easy to be guessed/brute-forced.
  This attack is classified as "CWE-330: Use of Insufficiently Random
  Values" (http://cwe.mitre.org/data/definitions/330.html).

  What are the possible fixes?
  We suggest using a long random string (e.g., 32-bit or 64-bit). Using
  os.urandom() is a good one, it has been recommended for generating
  random number for cryptographic purposes.
  A patch is attached in the attached file (please note: we haven't tested
  this patch).

  Where is the exploit code?
  We attach a snippet code that we modify from test_bad_verifier()
  Keystone test case.
  The snippet is a sketch of how oauth_verifier code brute-forcing can be
  implemented.

  What is the affected version?
  The keystone/master on github as of Oct 7th 2013 is affected.

  References:
  Link to oauth1 file and vulnerable code location (sql.py, line #210):
  https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210
  CWE-330: Use of Insufficiently Random Values:
  (http://cwe.mitre.org/data/definitions/330.html).
  RFC5849: http://tools.ietf.org/html/rfc5849
  os.urandom(): http://docs.python.org/2/library/os.html
  OAuth in keystone tutorial:
  http://www.unitedstack.com/blog/oauth-in-keystone/

  # Patch
  --- /tmp/keystone/keystone/contrib/oauth1/backends/sql.py       2013-10-07 17:06:04.170603933 -0500
  +++ /home/vagrant/keystone/keystone/contrib/oauth1/backends/sql.py      2013-10-07 17:01:39.124008733 -0500
  @@ -17,6 +17,8 @@
   import datetime
   import random
   import uuid
  +import os
  +import binascii

   from keystone.common import sql
   from keystone.common.sql import migration
  @@ -207,7 +209,7 @@
               token_ref = self._get_request_token(session, request_token_id)
               token_dict = token_ref.to_dict()
               token_dict['authorizing_user_id'] = user_id
  -            token_dict['verifier'] = str(random.randint(1000, 9999))
  +            token_dict['verifier'] = binascii.b2a_hex(os.urandom(16))
               token_dict['role_ids'] = jsonutils.dumps(role_ids)

               new_token = RequestToken.from_dict(token_dict)

  # Test brute force
  class MaliciousOAuth1Tests(OAuth1Tests):

      # modified from test_bad_verifier()
      def test_bruteforce_verifier(self):
          
          # create consumer for oauth
          consumer = self._create_single_consumer()
          consumer_id = consumer.get('id')
          consumer_secret = consumer.get('secret')
          consumer = oauth1.Consumer(consumer_id, consumer_secret)

          url, headers = self._create_request_token(consumer,
                                                    self.project_id)
          # get request token
          content = self.post(url, headers=headers)
          credentials = urlparse.parse_qs(content.result)
          request_key = credentials.get('oauth_token')[0]
          request_secret = credentials.get('oauth_token_secret')[0]
          request_token = oauth1.Token(request_key, request_secret)

  
          # authorize request token
          url = self._authorize_request_token(request_key)
          
          body = {'roles': [{'id': self.role_id}]}
          resp = self.put(url, body=body, expected_status=200)
          verifier = resp.result['token']['oauth_verifier']
          self.assertIsNotNone(verifier)

          # we are not going to use received oauth_verifier here, instead, we brute-force to find the valid oauth_verifier
          for i in range(1000,10000):
              request_token.set_verifier(str(i))
              url, headers = self._create_access_token(consumer,
                                                       request_token)
              # We expect 401 status code for most of requests since most oauth_verifier code
              # that we try will be invalid.
              # The test will crash at the valid oauth_verifier code when returned status = 201,
              # which is different from the expected 401 status.
              r = self.post(url, headers=headers, expected_status=401)
              
              # Print out oauth_verifier, and raw response request that contains access token.
              if (r == 201): # We have found correct oauth_verifier code
                  print 'oauth_verifier: {}, raw access_token response request: {}'.format(str(i), str(r))

  
  We are looking forward hearing from you.

  Thank you.

  Best,

  Phuong Cao
  Research Assistant
  DEPEND group
  Coordinated Science Laboratory
  University of Illinois at Urbana Champaign
  Urbana, IL 61801, USA

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



From devoid at anl.gov  Mon Apr 21 16:26:17 2014
From: devoid at anl.gov (Scott Devoid)
Date: Mon, 21 Apr 2014 16:26:17 -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: <20140421162617.4545.68635.malone@soybean.canonical.com>

Right, I think this is bad behavior at both the API and the command line
level. We probably can't change the behavior of the API but we should
change the behavior of the client. My suggestion is to return an error
message if the "tenant_id" argument does not correspond to a tenant_id
in keystone.

** Changed in: python-novaclient
       Status: New => Confirmed

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

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

Status in Python client library for Nova:
  Confirmed

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  Mon Apr 21 17:49:57 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 21 Apr 2014 17:49:57 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WcILt-0008Kp-BY@review.openstack.org>


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

Log:
commit 64b16cafe13a6be3b1a19ab45b7e83de609f98be
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From gerrit2 at review.openstack.org  Mon Apr 21 18:06:39 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 21 Apr 2014 18:06:39 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b
Message-ID: <E1WcIc3-0001Yg-T3@review.openstack.org>


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

Log:
commit 5d64be2080ab6c0b2a5de2b75bdeceeda58fd4ad
Author: Daniel Gollub <d.gollub at telekom.de>
Date:   Sat Feb 22 21:37:59 2014 +0100

    Replace HTTPSConnection in zadara with Requests
    
    SSL Verification is from now on enabled by default.
    
    This changes the default behaviour and is the primary intention of this
    change: verify SSL certificates.
    
    This might break existing configuration/setups where the SSL certificate
    used by the SAN would not pass the verification.
    
    Old behaviour can be forced by using `san_ssl_insecure=True`.
    
    SecurityImpact
    DocImpact
    Partial-Bug: 1188189
    
    Change-Id: I4799c2c5376fb54e5ebbdc4f9b6a1c526e7b8a8b




From noloader at gmail.com  Mon Apr 21 21:52:21 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 21 Apr 2014 17:52:21 -0400
Subject: [Openstack-security] Fine grain Cross-VM Attacks on Xen and VMware
	are possible!
Message-ID: <CAH8yC8kBLusAyQKQObf1QW9Wzz64qvE9QHE1KRA5Onm4Qrb5fg@mail.gmail.com>

Interesting paper on cross-VM attacks on AES....
http://eprint.iacr.org/2014/248.

Abstract: This work exposes further vulnerabilities in virtualized
cloud servers by mounting Cross-VM cache attacks in Xen and VMware VMs
targeting AES running in the victim VM. Even though there exists a
rich literature on cache attacks on AES, so far only a single work,
demonstrating a working attack on an ARM platform running a L4Re
virtualization layer has been published. Here we show that AES in a
number popular cryptographic libraries including OpenSSL, PolarSSL and
Libgcrypt are vulnerable to Bernstein’s correlation attack when run in
Xen and VMware (bare metal version) VMs, the most popular VMs used by
cloud service providers (CSP) such as Amazon and Rackspace. We also
show that the vulnerability persists even if the VMs are placed on
different cores in the same machine. The results of this study shows
that there is a great security risk to AES and (data encrypted under
AES) on popular cloud services.



From alawson at aqorn.com  Mon Apr 21 23:26:12 2014
From: alawson at aqorn.com (Adam Lawson)
Date: Mon, 21 Apr 2014 16:26:12 -0700
Subject: [Openstack-security] Credentials in clear text
Message-ID: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>

Have .conf files containing credentials and tokens been addressed or being
addressed? Seems there are a lot of keys to the kingdom clearly visible to
staff who have access to systems for day-to-day admin work but
don't/shouldn't be able to view them. If they have sudo access, they have
everything they need to get where they don't belong. Really strikes me as
an obvious audit issue...


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140421/da207841/attachment.html>

From bdpayne at acm.org  Mon Apr 21 23:41:03 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Mon, 21 Apr 2014 16:41:03 -0700
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
Message-ID: <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>

This would be a nice hardening step, but if you have sudo on the box
there's a lot of things you can do see.  This is just the tip of the
iceberg.  For example, access to the backend db?  Access to traffic on the
network / unix sockets / etc?  Access to logs.

I am not aware of any current efforts to mask this information from the
config files.  But that doesn't mean it's not happening.  If someone is
aware of such an effort, I'd certainly be interested in learning more about
it.

Cheers,
-bryan




On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com> wrote:

> Have .conf files containing credentials and tokens been addressed or being
> addressed? Seems there are a lot of keys to the kingdom clearly visible to
> staff who have access to systems for day-to-day admin work but
> don't/shouldn't be able to view them. If they have sudo access, they have
> everything they need to get where they don't belong. Really strikes me as
> an obvious audit issue...
>
>
> *Adam Lawson*
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW
> Direct: +1 (302) 268-6914
>
>
> _______________________________________________
> 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/20140421/ee53d5a1/attachment.html>

From alawson at aqorn.com  Mon Apr 21 23:46:30 2014
From: alawson at aqorn.com (Adam Lawson)
Date: Mon, 21 Apr 2014 16:46:30 -0700
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
Message-ID: <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>

My initial concern is specific to Swift and gaining global access to all
data by virtue of having access to a single proxy node. It seems more than
access to system resources but a flaw in how data is controlled (and
passwords are controlled).


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914



On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

> This would be a nice hardening step, but if you have sudo on the box
> there's a lot of things you can do see.  This is just the tip of the
> iceberg.  For example, access to the backend db?  Access to traffic on the
> network / unix sockets / etc?  Access to logs.
>
> I am not aware of any current efforts to mask this information from the
> config files.  But that doesn't mean it's not happening.  If someone is
> aware of such an effort, I'd certainly be interested in learning more about
> it.
>
> Cheers,
> -bryan
>
>
>
>
> On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>> Have .conf files containing credentials and tokens been addressed or
>> being addressed? Seems there are a lot of keys to the kingdom clearly
>> visible to staff who have access to systems for day-to-day admin work but
>> don't/shouldn't be able to view them. If they have sudo access, they have
>> everything they need to get where they don't belong. Really strikes me as
>> an obvious audit issue...
>>
>>
>> *Adam Lawson*
>> AQORN, Inc.
>> 427 North Tatnall Street
>> Ste. 58461
>> Wilmington, Delaware 19801-2230
>> Toll-free: (844) 4-AQORN-NOW
>> Direct: +1 (302) 268-6914
>>
>>
>> _______________________________________________
>> 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/20140421/4f3d4df2/attachment.html>

From alawson at aqorn.com  Mon Apr 21 23:47:31 2014
From: alawson at aqorn.com (Adam Lawson)
Date: Mon, 21 Apr 2014 16:47:31 -0700
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
Message-ID: <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>

Preventing access to passwords for the purpose of preventing unauthorized
access to data as another way I look at it.


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914



On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com> wrote:

> My initial concern is specific to Swift and gaining global access to all
> data by virtue of having access to a single proxy node. It seems more than
> access to system resources but a flaw in how data is controlled (and
> passwords are controlled).
>
>
> *Adam Lawson*
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW
> Direct: +1 (302) 268-6914
>
>
>
> On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>
>> This would be a nice hardening step, but if you have sudo on the box
>> there's a lot of things you can do see.  This is just the tip of the
>> iceberg.  For example, access to the backend db?  Access to traffic on the
>> network / unix sockets / etc?  Access to logs.
>>
>> I am not aware of any current efforts to mask this information from the
>> config files.  But that doesn't mean it's not happening.  If someone is
>> aware of such an effort, I'd certainly be interested in learning more about
>> it.
>>
>> Cheers,
>> -bryan
>>
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com> wrote:
>>
>>> Have .conf files containing credentials and tokens been addressed or
>>> being addressed? Seems there are a lot of keys to the kingdom clearly
>>> visible to staff who have access to systems for day-to-day admin work but
>>> don't/shouldn't be able to view them. If they have sudo access, they have
>>> everything they need to get where they don't belong. Really strikes me as
>>> an obvious audit issue...
>>>
>>>
>>> *Adam Lawson*
>>> AQORN, Inc.
>>> 427 North Tatnall Street
>>> Ste. 58461
>>> Wilmington, Delaware 19801-2230
>>> Toll-free: (844) 4-AQORN-NOW
>>> Direct: +1 (302) 268-6914
>>>
>>>
>>> _______________________________________________
>>> 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/20140421/0b102d64/attachment.html>

From bdpayne at acm.org  Tue Apr 22 00:15:52 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Mon, 21 Apr 2014 17:15:52 -0700
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
Message-ID: <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>

This is fair.  I'm not personally familiar with Swift, so I will let others
chime in on that.
-bryan


On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com> wrote:

> Preventing access to passwords for the purpose of preventing unauthorized
> access to data as another way I look at it.
>
>
> *Adam Lawson*
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW
> Direct: +1 (302) 268-6914
>
>
>
> On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>> My initial concern is specific to Swift and gaining global access to all
>> data by virtue of having access to a single proxy node. It seems more than
>> access to system resources but a flaw in how data is controlled (and
>> passwords are controlled).
>>
>>
>> *Adam Lawson*
>> AQORN, Inc.
>> 427 North Tatnall Street
>> Ste. 58461
>> Wilmington, Delaware 19801-2230
>> Toll-free: (844) 4-AQORN-NOW
>> Direct: +1 (302) 268-6914
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>>
>>> This would be a nice hardening step, but if you have sudo on the box
>>> there's a lot of things you can do see.  This is just the tip of the
>>> iceberg.  For example, access to the backend db?  Access to traffic on the
>>> network / unix sockets / etc?  Access to logs.
>>>
>>> I am not aware of any current efforts to mask this information from the
>>> config files.  But that doesn't mean it's not happening.  If someone is
>>> aware of such an effort, I'd certainly be interested in learning more about
>>> it.
>>>
>>> Cheers,
>>> -bryan
>>>
>>>
>>>
>>>
>>> On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com> wrote:
>>>
>>>> Have .conf files containing credentials and tokens been addressed or
>>>> being addressed? Seems there are a lot of keys to the kingdom clearly
>>>> visible to staff who have access to systems for day-to-day admin work but
>>>> don't/shouldn't be able to view them. If they have sudo access, they have
>>>> everything they need to get where they don't belong. Really strikes me as
>>>> an obvious audit issue...
>>>>
>>>>
>>>> *Adam Lawson*
>>>> AQORN, Inc.
>>>> 427 North Tatnall Street
>>>> Ste. 58461
>>>> Wilmington, Delaware 19801-2230
>>>> Toll-free: (844) 4-AQORN-NOW
>>>> Direct: +1 (302) 268-6914
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20140421/230d2c17/attachment.html>

From 1118066 at bugs.launchpad.net  Tue Apr 22 04:45:12 2014
From: 1118066 at bugs.launchpad.net (vaibhav)
Date: Tue, 22 Apr 2014 04:45:12 -0000
Subject: [Openstack-security] [Bug 1118066] Re: Nova should confirm quota
	requests against Keystone
References: <20130207064604.19234.83660.malonedeb@gac.canonical.com>
Message-ID: <20140422044515.24532.48983.launchpad@wampee.canonical.com>

** Changed in: nova
     Assignee: (unassigned) => vaibhav (vaibhav-bhatkar)

-- 
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 m.koderer at telekom.de  Tue Apr 22 06:38:14 2014
From: m.koderer at telekom.de (Koderer, Marc)
Date: Tue, 22 Apr 2014 08:38:14 +0200
Subject: [Openstack-security] Fuzzy test framework Dev Session in Atlanta
In-Reply-To: <CAFpPvXAxBY+NDJaLWKdz0x0HXhUYND5PCKUTr+tc6wR1o50Kxw@mail.gmail.com>
References: <CAFpPvXAcHVxSJA8_wFViFdm3Z0th_T+HWUhBMwxEdF+gi+KRjA@mail.gmail.com>
 <CF753EE4.97D7%robert.clark@hp.com>
 <CAFpPvXAxBY+NDJaLWKdz0x0HXhUYND5PCKUTr+tc6wR1o50Kxw@mail.gmail.com>
Message-ID: <FD9023AAE9C10145BD4DDD6CB11F8D580D49E51483@QEO40075.de.t-online.corp>

Hi Gents,

Cool!
could you add a short comment on the session that you are interested. We have many session proposals this year and this would increase the chances to get it in.


http://summit.openstack.org/cfp/details/323

Regards
Marc

Von: bdpayne at gmail.com [mailto:bdpayne at gmail.com] Im Auftrag von Bryan D. Payne
Gesendet: Donnerstag, 17. April 2014 19:03
An: Clark, Robert Graham
Cc: Koderer, Marc; openstack-security at lists.openstack.org
Betreff: Re: [Openstack-security] Fuzzy test framework Dev Session in Atlanta

Bryan – should we look to make a schedule that highlights all the interesting talks/sessions for the summit ?

We have done this in the past and I'm not sure that others have found it too useful / valuable.  May not be worth the effort this time around.
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140422/679944a9/attachment.html>

From alawson at aqorn.com  Mon Apr 21 23:19:55 2014
From: alawson at aqorn.com (Adam Lawson)
Date: Mon, 21 Apr 2014 16:19:55 -0700
Subject: [Openstack-security] subscribe
Message-ID: <CAJfWK48BXucArFgTCixNYQa0Ohi8zmkqhk20F_fm=xqLHHL3qA@mail.gmail.com>

*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140421/a01c1b7d/attachment.html>

From robert.clark at hp.com  Tue Apr 22 15:29:11 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 22 Apr 2014 15:29:11 +0000
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>

As Bryan mentioned already, a user with access to production systems, particularly one with sudo/root access – is in an incredibly privileged position. On its own this is an auditing issue but it’s a recognised one. In most deployments subject to auditing (i.e. production) it’s likely that compensating controls such as gated access, user logging, MAC etc. are all in place to control the risk.

It’s a messy problem to deal with. I’ve seen approaches where the process and configuration file are both owned by an elevated user, once the process has loaded the configuration file it drops privs and can no longer read the file, this can be useful as a mechanism for avoiding directory traversal in web services etc I’m not sure how viable an approach this would be with something like Swift.

 

-Rob

 

From: Bryan D. Payne [mailto:bdpayne at acm.org] 
Sent: 22 April 2014 01:16
To: Adam Lawson
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Credentials in clear text

 

This is fair.  I'm not personally familiar with Swift, so I will let others chime in on that.

-bryan

 

On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com <mailto:alawson at aqorn.com> > wrote:

Preventing access to passwords for the purpose of preventing unauthorized access to data as another way I look at it.





Adam Lawson

AQORN, Inc.

427 North Tatnall Street

Ste. 58461

Wilmington, Delaware 19801-2230

Toll-free: (844) 4-AQORN-NOW

Direct:  <tel:%2B1%20%28302%29%20268-6914> +1 (302) 268-6914

  <http://www.aqorn.com/images/logo.png> 

 

On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com <mailto:alawson at aqorn.com> > wrote:

My initial concern is specific to Swift and gaining global access to all data by virtue of having access to a single proxy node. It seems more than access to system resources but a flaw in how data is controlled (and passwords are controlled).





Adam Lawson

AQORN, Inc.

427 North Tatnall Street

Ste. 58461

Wilmington, Delaware 19801-2230

Toll-free: (844) 4-AQORN-NOW

Direct:  <tel:%2B1%20%28302%29%20268-6914> +1 (302) 268-6914

  <http://www.aqorn.com/images/logo.png> 

 

On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org <mailto:bdpayne at acm.org> > wrote:

This would be a nice hardening step, but if you have sudo on the box there's a lot of things you can do see.  This is just the tip of the iceberg.  For example, access to the backend db?  Access to traffic on the network / unix sockets / etc?  Access to logs.

 

I am not aware of any current efforts to mask this information from the config files.  But that doesn't mean it's not happening.  If someone is aware of such an effort, I'd certainly be interested in learning more about it.

 

Cheers,

-bryan

 

 

 

On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com <mailto:alawson at aqorn.com> > wrote:

Have .conf files containing credentials and tokens been addressed or being addressed? Seems there are a lot of keys to the kingdom clearly visible to staff who have access to systems for day-to-day admin work but don't/shouldn't be able to view them. If they have sudo access, they have everything they need to get where they don't belong. Really strikes me as an obvious audit issue...





Adam Lawson

AQORN, Inc.

427 North Tatnall Street

Ste. 58461

Wilmington, Delaware 19801-2230

Toll-free: (844) 4-AQORN-NOW

Direct:  <tel:%2B1%20%28302%29%20268-6914> +1 (302) 268-6914

  <http://www.aqorn.com/images/logo.png> 

 

_______________________________________________
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

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140422/4b4ff7a9/attachment.html>
-------------- 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/20140422/4b4ff7a9/attachment.bin>

From xfan888 at yahoo.com  Tue Apr 22 16:45:16 2014
From: xfan888 at yahoo.com (Vivian Fan)
Date: Tue, 22 Apr 2014 09:45:16 -0700 (PDT)
Subject: [Openstack-security] OpenStack Auditing Standards
Message-ID: <1398185116.91461.YahooMailNeo@web142501.mail.bf1.yahoo.com>

Hi,

My name is Vivian Fan and I am new to this mailing list.  I am interested to know how OpenStack security group is currently addressing the compliance needs of Companies who are adopting this platform and issue auditing standards to facilitate the subscribers' compliance activities.  I looked through the new document released by the security group but the guidance is very high level and not specific to OpenStack.  Where can I get more info?

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

From ayoung at redhat.com  Wed Apr 23 04:21:47 2014
From: ayoung at redhat.com (Adam Young)
Date: Wed, 23 Apr 2014 00:21:47 -0400
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
Message-ID: <53573FDB.4040409@redhat.com>

On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:
>
> As Bryan mentioned already, a user with access to production systems, 
> particularly one with sudo/root access -- is in an incredibly 
> privileged position. On its own this is an auditing issue but it's a 
> recognised one. In most deployments subject to auditing (i.e. 
> production) it's likely that compensating controls such as gated 
> access, user logging, MAC etc. are all in place to control the risk.
>
> It's a messy problem to deal with. I've seen approaches where the 
> process and configuration file are both owned by an elevated user, 
> once the process has loaded the configuration file it drops privs and 
> can no longer read the file, this can be useful as a mechanism for 
> avoiding directory traversal in web services etc I'm not sure how 
> viable an approach this would be with something like Swift.
>
> -Rob
>

I'd like to see a concerted effort to allowing all servcie to get 
keystone tokens with either Kerberos (keytabs) or X509 Client certificates.

> *From:*Bryan D. Payne [mailto:bdpayne at acm.org]
> *Sent:* 22 April 2014 01:16
> *To:* Adam Lawson
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] Credentials in clear text
>
> This is fair.  I'm not personally familiar with Swift, so I will let 
> others chime in on that.
>
> -bryan
>
> On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com 
> <mailto:alawson at aqorn.com>> wrote:
>
>     Preventing access to passwords for the purpose of preventing
>     unauthorized access to data as another way I look at it.
>
>
>     */
>     Adam Lawson/*
>
>     AQORN, Inc.
>
>     427 North Tatnall Street
>
>     Ste. 58461
>
>     Wilmington, Delaware 19801-2230
>
>     Toll-free: (844) 4-AQORN-NOW
>
>     Direct: +1 (302) 268-6914 <tel:%2B1%20%28302%29%20268-6914>
>
>     http://www.aqorn.com/images/logo.png
>
>     On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com
>     <mailto:alawson at aqorn.com>> wrote:
>
>         My initial concern is specific to Swift and gaining global
>         access to all data by virtue of having access to a single
>         proxy node. It seems more than access to system resources but
>         a flaw in how data is controlled (and passwords are controlled).
>
>
>         */
>         Adam Lawson/*
>
>         AQORN, Inc.
>
>         427 North Tatnall Street
>
>         Ste. 58461
>
>         Wilmington, Delaware 19801-2230
>
>         Toll-free: (844) 4-AQORN-NOW
>
>         Direct: +1 (302) 268-6914 <tel:%2B1%20%28302%29%20268-6914>
>
>         http://www.aqorn.com/images/logo.png
>
>         On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne
>         <bdpayne at acm.org <mailto:bdpayne at acm.org>> wrote:
>
>             This would be a nice hardening step, but if you have sudo
>             on the box there's a lot of things you can do see.  This
>             is just the tip of the iceberg.  For example, access to
>             the backend db?  Access to traffic on the network / unix
>             sockets / etc?  Access to logs.
>
>             I am not aware of any current efforts to mask this
>             information from the config files.  But that doesn't mean
>             it's not happening.  If someone is aware of such an
>             effort, I'd certainly be interested in learning more about it.
>
>             Cheers,
>
>             -bryan
>
>             On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson
>             <alawson at aqorn.com <mailto:alawson at aqorn.com>> wrote:
>
>                 Have .conf files containing credentials and tokens
>                 been addressed or being addressed? Seems there are a
>                 lot of keys to the kingdom clearly visible to staff
>                 who have access to systems for day-to-day admin work
>                 but don't/shouldn't be able to view them. If they have
>                 sudo access, they have everything they need to get
>                 where they don't belong. Really strikes me as an
>                 obvious audit issue...
>
>
>                 */
>                 Adam Lawson/*
>
>                 AQORN, Inc.
>
>                 427 North Tatnall Street
>
>                 Ste. 58461
>
>                 Wilmington, Delaware 19801-2230
>
>                 Toll-free: (844) 4-AQORN-NOW
>
>                 Direct: +1 (302) 268-6914
>                 <tel:%2B1%20%28302%29%20268-6914>
>
>                 http://www.aqorn.com/images/logo.png
>
>                 _______________________________________________
>                 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
>
>
>
> _______________________________________________
> 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/20140423/c1da6e93/attachment.html>

From 1174499 at bugs.launchpad.net  Wed Apr 23 05:42:56 2014
From: 1174499 at bugs.launchpad.net (Openstack Gerrit)
Date: Wed, 23 Apr 2014 05:42:56 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140423054256.24269.14815.malone@wampee.canonical.com>

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

commit bf4ff96472991675f76c95dde8c027417d0deafd
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Apr 9 19:13:09 2014 -0500

    Configurable token hash algorithm
    
    Tokens were always hashed with MD5. This change allows tokens to
    be hashed with SHA256 (or any other algorithm supported by the
    keystoneclient token hash function). This is for security
    hardening.
    
    There's a new configuration option 'hash_algorithm' in the [token]
    section. This is the algorithm to use for hashing PKI tokens, so is
    used
    
    a) when storing the token in the db
    b) as the hash in the revocation list
    
    hash_algorithm defaults to 'md5' for backwards compatibility.
    
    SecurityImpact
    DocImpact
    Closes-Bug: #1174499
    
    Change-Id: Iafe3c975d59818c8f362647f7ea5149a03deee47


** 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/1174499

Title:
  Keystone token hashing is MD5

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

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



From robert.clark at hp.com  Wed Apr 23 07:20:37 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 23 Apr 2014 07:20:37 +0000
Subject: [Openstack-security] OpenStack Auditing Standards
In-Reply-To: <1398185116.91461.YahooMailNeo@web142501.mail.bf1.yahoo.com>
Message-ID: <CF7D280A.A359%robert.clark@hp.com>

Hi Vivian,

The compliance needs of companies should really be addressed by themselves, through working with OpenStack to improve the project in areas that will benefit everyone’s compliance efforts – maybe checkout the compliance section in the OpenStack security guide?

From: Vivian Fan <xfan888 at yahoo.com<mailto:xfan888 at yahoo.com>>
Reply-To: Vivian Fan <xfan888 at yahoo.com<mailto:xfan888 at yahoo.com>>
Date: Tue, 22 Apr 2014 09:45:16 -0700
To: "openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>" <openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>>
Subject: [Openstack-security] OpenStack Auditing Standards

Hi,

My name is Vivian Fan and I am new to this mailing list.  I am interested to know how OpenStack security group is currently addressing the compliance needs of Companies who are adopting this platform and issue auditing standards to facilitate the subscribers' compliance activities.  I looked through the new document released by the security group but the guidance is very high level and not specific to OpenStack.  Where can I get more info?

Thanks,
Vivian
_______________________________________________ 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



From nathanael.i.burton.work at gmail.com  Wed Apr 23 12:29:16 2014
From: nathanael.i.burton.work at gmail.com (Nathanael Burton)
Date: Wed, 23 Apr 2014 08:29:16 -0400
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <53573FDB.4040409@redhat.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
 <53573FDB.4040409@redhat.com>
Message-ID: <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>

We do this today with X509 certificates using the external auth plugin for
Keystone. Services and users auth directly with X509 certificates to get
tokens.

Nate
On Apr 23, 2014 12:23 AM, "Adam Young" <ayoung at redhat.com> wrote:

>  On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:
>
>  As Bryan mentioned already, a user with access to production systems,
> particularly one with sudo/root access – is in an incredibly privileged
> position. On its own this is an auditing issue but it’s a recognised one.
> In most deployments subject to auditing (i.e. production) it’s likely that
> compensating controls such as gated access, user logging, MAC etc. are all
> in place to control the risk.
>
>  It’s a messy problem to deal with. I’ve seen approaches where the
> process and configuration file are both owned by an elevated user, once the
> process has loaded the configuration file it drops privs and can no longer
> read the file, this can be useful as a mechanism for avoiding directory
> traversal in web services etc I’m not sure how viable an approach this
> would be with something like Swift.
>
>
>
> -Rob
>
>
> I'd like to see a concerted effort to allowing all servcie to get keystone
> tokens with either Kerberos (keytabs) or X509 Client certificates.
>
>
>
> *From:* Bryan D. Payne [mailto:bdpayne at acm.org <bdpayne at acm.org>]
> *Sent:* 22 April 2014 01:16
> *To:* Adam Lawson
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] Credentials in clear text
>
>
>
> This is fair.  I'm not personally familiar with Swift, so I will let
> others chime in on that.
>
> -bryan
>
>
>
> On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>  Preventing access to passwords for the purpose of preventing
> unauthorized access to data as another way I look at it.
>
>
>
> * Adam Lawson*
>
> AQORN, Inc.
>
> 427 North Tatnall Street
>
> Ste. 58461
>
> Wilmington, Delaware 19801-2230
>
> Toll-free: (844) 4-AQORN-NOW
>
> Direct: +1 (302) 268-6914 <%2B1%20%28302%29%20268-6914>
>
> [image: http://www.aqorn.com/images/logo.png]
>
>
>
> On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>  My initial concern is specific to Swift and gaining global access to all
> data by virtue of having access to a single proxy node. It seems more than
> access to system resources but a flaw in how data is controlled (and
> passwords are controlled).
>
>
>
> * Adam Lawson*
>
> AQORN, Inc.
>
> 427 North Tatnall Street
>
> Ste. 58461
>
> Wilmington, Delaware 19801-2230
>
> Toll-free: (844) 4-AQORN-NOW
>
> Direct: +1 (302) 268-6914 <%2B1%20%28302%29%20268-6914>
>
> [image: http://www.aqorn.com/images/logo.png]
>
>
>
> On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>
>  This would be a nice hardening step, but if you have sudo on the box
> there's a lot of things you can do see.  This is just the tip of the
> iceberg.  For example, access to the backend db?  Access to traffic on the
> network / unix sockets / etc?  Access to logs.
>
>
>
> I am not aware of any current efforts to mask this information from the
> config files.  But that doesn't mean it's not happening.  If someone is
> aware of such an effort, I'd certainly be interested in learning more about
> it.
>
>
>
> Cheers,
>
> -bryan
>
>
>
>
>
>
>
> On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>   Have .conf files containing credentials and tokens been addressed or
> being addressed? Seems there are a lot of keys to the kingdom clearly
> visible to staff who have access to systems for day-to-day admin work but
> don't/shouldn't be able to view them. If they have sudo access, they have
> everything they need to get where they don't belong. Really strikes me as
> an obvious audit issue...
>
>
>
> * Adam Lawson*
>
> AQORN, Inc.
>
> 427 North Tatnall Street
>
> Ste. 58461
>
> Wilmington, Delaware 19801-2230
>
> Toll-free: (844) 4-AQORN-NOW
>
> Direct: +1 (302) 268-6914 <%2B1%20%28302%29%20268-6914>
>
> [image: http://www.aqorn.com/images/logo.png]
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Openstack-security mailing listOpenstack-security at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/044242c7/attachment.html>

From nathanael.i.burton.work at gmail.com  Wed Apr 23 12:42:10 2014
From: nathanael.i.burton.work at gmail.com (Nathanael Burton)
Date: Wed, 23 Apr 2014 08:42:10 -0400
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <5357B305.6080302@redhat.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
 <53573FDB.4040409@redhat.com>
 <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>
 <5357B305.6080302@redhat.com>
Message-ID: <CAM+Mi=tmnyVcUO=s-57Nf2ajt6592WeJCoqFbPCzsff2BFui+g@mail.gmail.com>

We have to configure the Apache layer to set the component we want as the
REMOTE_USER, but other than that I believe that's pretty much all it takes
on the Keystone side. Changes were necessary to some of the Python clients
and service code, mainly to get them to pass certificates along.  Not all
these changes have been proposed upstream yet, although we plan to.

Thanks,

Nate
On Apr 23, 2014 8:33 AM, "Adam Young" <ayoung at redhat.com> wrote:

>  On 04/23/2014 08:29 AM, Nathanael Burton wrote:
>
> We do this today with X509 certificates using the external auth plugin for
> Keystone. Services and users auth directly with X509 certificates to get
> tokens.
>
>
> Have you modified it at all?  I have yet to try, but I though with mod_ssl
> and external, REMOTE_USER was not set.  It was my understanding that the
> following vars were set in its place:
>
> http://www.freeipa.org/page/Environment_Variables#X.509_Authentication
>
>  Nate
> On Apr 23, 2014 12:23 AM, "Adam Young" <ayoung at redhat.com> wrote:
>
>>  On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:
>>
>>  As Bryan mentioned already, a user with access to production systems,
>> particularly one with sudo/root access – is in an incredibly privileged
>> position. On its own this is an auditing issue but it’s a recognised one.
>> In most deployments subject to auditing (i.e. production) it’s likely that
>> compensating controls such as gated access, user logging, MAC etc. are all
>> in place to control the risk.
>>
>>  It’s a messy problem to deal with. I’ve seen approaches where the
>> process and configuration file are both owned by an elevated user, once the
>> process has loaded the configuration file it drops privs and can no longer
>> read the file, this can be useful as a mechanism for avoiding directory
>> traversal in web services etc I’m not sure how viable an approach this
>> would be with something like Swift.
>>
>>
>>
>> -Rob
>>
>>
>> I'd like to see a concerted effort to allowing all servcie to get
>> keystone tokens with either Kerberos (keytabs) or X509 Client certificates.
>>
>>
>>
>> *From:* Bryan D. Payne [mailto:bdpayne at acm.org <bdpayne at acm.org>]
>> *Sent:* 22 April 2014 01:16
>> *To:* Adam Lawson
>> *Cc:* openstack-security at lists.openstack.org
>> *Subject:* Re: [Openstack-security] Credentials in clear text
>>
>>
>>
>> This is fair.  I'm not personally familiar with Swift, so I will let
>> others chime in on that.
>>
>> -bryan
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com> wrote:
>>
>>  Preventing access to passwords for the purpose of preventing
>> unauthorized access to data as another way I look at it.
>>
>>
>>
>> * Adam Lawson*
>>
>> AQORN, Inc.
>>
>> 427 North Tatnall Street
>>
>> Ste. 58461
>>
>> Wilmington, Delaware 19801-2230
>>
>> Toll-free: (844) 4-AQORN-NOW
>>
>> Direct: +1 (302) 268-6914 <%2B1%20%28302%29%20268-6914>
>>
>> [image: http://www.aqorn.com/images/logo.png]
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com> wrote:
>>
>>  My initial concern is specific to Swift and gaining global access to
>> all data by virtue of having access to a single proxy node. It seems more
>> than access to system resources but a flaw in how data is controlled (and
>> passwords are controlled).
>>
>>
>>
>> * Adam Lawson*
>>
>> AQORN, Inc.
>>
>> 427 North Tatnall Street
>>
>> Ste. 58461
>>
>> Wilmington, Delaware 19801-2230
>>
>> Toll-free: (844) 4-AQORN-NOW
>>
>> Direct: +1 (302) 268-6914 <%2B1%20%28302%29%20268-6914>
>>
>> [image: http://www.aqorn.com/images/logo.png]
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>>
>>  This would be a nice hardening step, but if you have sudo on the box
>> there's a lot of things you can do see.  This is just the tip of the
>> iceberg.  For example, access to the backend db?  Access to traffic on the
>> network / unix sockets / etc?  Access to logs.
>>
>>
>>
>> I am not aware of any current efforts to mask this information from the
>> config files.  But that doesn't mean it's not happening.  If someone is
>> aware of such an effort, I'd certainly be interested in learning more about
>> it.
>>
>>
>>
>> Cheers,
>>
>> -bryan
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com> wrote:
>>
>>   Have .conf files containing credentials and tokens been addressed or
>> being addressed? Seems there are a lot of keys to the kingdom clearly
>> visible to staff who have access to systems for day-to-day admin work but
>> don't/shouldn't be able to view them. If they have sudo access, they have
>> everything they need to get where they don't belong. Really strikes me as
>> an obvious audit issue...
>>
>>
>>
>> * Adam Lawson*
>>
>> AQORN, Inc.
>>
>> 427 North Tatnall Street
>>
>> Ste. 58461
>>
>> Wilmington, Delaware 19801-2230
>>
>> Toll-free: (844) 4-AQORN-NOW
>>
>> Direct: +1 (302) 268-6914 <%2B1%20%28302%29%20268-6914>
>>
>> [image: http://www.aqorn.com/images/logo.png]
>>
>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openstack-security mailing listOpenstack-security at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/650194b0/attachment.html>

From ayoung at redhat.com  Wed Apr 23 12:33:09 2014
From: ayoung at redhat.com (Adam Young)
Date: Wed, 23 Apr 2014 08:33:09 -0400
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>	<CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>	<CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>	<CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>	<CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>	<A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>	<53573FDB.4040409@redhat.com>
 <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>
Message-ID: <5357B305.6080302@redhat.com>

On 04/23/2014 08:29 AM, Nathanael Burton wrote:
>
> We do this today with X509 certificates using the external auth plugin 
> for Keystone. Services and users auth directly with X509 certificates 
> to get tokens.
>

Have you modified it at all?  I have yet to try, but I though with 
mod_ssl and external, REMOTE_USER was not set.  It was my understanding 
that the following vars were set in its place:

http://www.freeipa.org/page/Environment_Variables#X.509_Authentication

> Nate
>
> On Apr 23, 2014 12:23 AM, "Adam Young" <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:
>>
>>     As Bryan mentioned already, a user with access to production
>>     systems, particularly one with sudo/root access – is in an
>>     incredibly privileged position. On its own this is an auditing
>>     issue but it’s a recognised one. In most deployments subject to
>>     auditing (i.e. production) it’s likely that compensating controls
>>     such as gated access, user logging, MAC etc. are all in place to
>>     control the risk.
>>
>>     It’s a messy problem to deal with. I’ve seen approaches where the
>>     process and configuration file are both owned by an elevated
>>     user, once the process has loaded the configuration file it drops
>>     privs and can no longer read the file, this can be useful as a
>>     mechanism for avoiding directory traversal in web services etc
>>     I’m not sure how viable an approach this would be with something
>>     like Swift.
>>
>>     -Rob
>>
>
>     I'd like to see a concerted effort to allowing all servcie to get
>     keystone tokens with either Kerberos (keytabs) or X509 Client
>     certificates.
>
>>     *From:*Bryan D. Payne [mailto:bdpayne at acm.org]
>>     *Sent:* 22 April 2014 01:16
>>     *To:* Adam Lawson
>>     *Cc:* openstack-security at lists.openstack.org
>>     <mailto:openstack-security at lists.openstack.org>
>>     *Subject:* Re: [Openstack-security] Credentials in clear text
>>
>>     This is fair.  I'm not personally familiar with Swift, so I will
>>     let others chime in on that.
>>
>>     -bryan
>>
>>     On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com
>>     <mailto:alawson at aqorn.com>> wrote:
>>
>>         Preventing access to passwords for the purpose of preventing
>>         unauthorized access to data as another way I look at it.
>>
>>
>>         */
>>         Adam Lawson/*
>>
>>         AQORN, Inc.
>>
>>         427 North Tatnall Street
>>
>>         Ste. 58461
>>
>>         Wilmington, Delaware 19801-2230
>>
>>         Toll-free: (844) 4-AQORN-NOW
>>
>>         Direct: +1 (302) 268-6914 <tel:%2B1%20%28302%29%20268-6914>
>>
>>         http://www.aqorn.com/images/logo.png
>>
>>         On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson
>>         <alawson at aqorn.com <mailto:alawson at aqorn.com>> wrote:
>>
>>             My initial concern is specific to Swift and gaining
>>             global access to all data by virtue of having access to a
>>             single proxy node. It seems more than access to system
>>             resources but a flaw in how data is controlled (and
>>             passwords are controlled).
>>
>>
>>             */
>>             Adam Lawson/*
>>
>>             AQORN, Inc.
>>
>>             427 North Tatnall Street
>>
>>             Ste. 58461
>>
>>             Wilmington, Delaware 19801-2230
>>
>>             Toll-free: (844) 4-AQORN-NOW
>>
>>             Direct: +1 (302) 268-6914 <tel:%2B1%20%28302%29%20268-6914>
>>
>>             http://www.aqorn.com/images/logo.png
>>
>>             On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne
>>             <bdpayne at acm.org <mailto:bdpayne at acm.org>> wrote:
>>
>>                 This would be a nice hardening step, but if you have
>>                 sudo on the box there's a lot of things you can do
>>                 see.  This is just the tip of the iceberg.  For
>>                 example, access to the backend db?  Access to traffic
>>                 on the network / unix sockets / etc?  Access to logs.
>>
>>                 I am not aware of any current efforts to mask this
>>                 information from the config files.  But that doesn't
>>                 mean it's not happening.  If someone is aware of such
>>                 an effort, I'd certainly be interested in learning
>>                 more about it.
>>
>>                 Cheers,
>>
>>                 -bryan
>>
>>                 On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson
>>                 <alawson at aqorn.com <mailto:alawson at aqorn.com>> wrote:
>>
>>                     Have .conf files containing credentials and
>>                     tokens been addressed or being addressed? Seems
>>                     there are a lot of keys to the kingdom clearly
>>                     visible to staff who have access to systems for
>>                     day-to-day admin work but don't/shouldn't be able
>>                     to view them. If they have sudo access, they have
>>                     everything they need to get where they don't
>>                     belong. Really strikes me as an obvious audit
>>                     issue...
>>
>>
>>                     */
>>                     Adam Lawson/*
>>
>>                     AQORN, Inc.
>>
>>                     427 North Tatnall Street
>>
>>                     Ste. 58461
>>
>>                     Wilmington, Delaware 19801-2230
>>
>>                     Toll-free: (844) 4-AQORN-NOW
>>
>>                     Direct: +1 (302) 268-6914
>>                     <tel:%2B1%20%28302%29%20268-6914>
>>
>>                     http://www.aqorn.com/images/logo.png
>>
>>                     _______________________________________________
>>                     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
>>
>>
>>
>>     _______________________________________________
>>     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
>
>
>     _______________________________________________
>     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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/979b6789/attachment.html>

From Tim.Bell at cern.ch  Wed Apr 23 14:24:41 2014
From: Tim.Bell at cern.ch (Tim Bell)
Date: Wed, 23 Apr 2014 14:24:41 +0000
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAM+Mi=tmnyVcUO=s-57Nf2ajt6592WeJCoqFbPCzsff2BFui+g@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
 <53573FDB.4040409@redhat.com>
 <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>
 <5357B305.6080302@redhat.com>
 <CAM+Mi=tmnyVcUO=s-57Nf2ajt6592WeJCoqFbPCzsff2BFui+g@mail.gmail.com>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5D9B56F5E@CERNXCHG41.cern.ch>


I think Jose from CERN has been putting in some work on the clients and the server for Kerberos in this area.

There were some problems with the Kerberos packaging and pre-reqs along with how to fake a Kerberos server in the test suite but he was making progress.

Is this on the summit agenda ? It would be good to get it working since I think it was on my summit talk in Boston.

Tim

Activity Log
[http://www.gravatar.com/avatar/a1040384?s=64&d=identicon]
Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
08 Apr 2014 07:14:32 in python-keystoneclient<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>
Review “Initial kerberos plugin implementation.”
Submitted by: Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>) (#35)
Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8<https://review.openstack.org/74974>
Code Review: 1
[http://www.gravatar.com/avatar/a1040384?s=64&d=identicon]
Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
02 Apr 2014 14:59:32 in requirements<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=requirements>
Review “kerberos requires an additional requests library. Older versions break in py33”
Submitted by: Adam Young<http://stackalytics.com/?user_id=ayoung&project_type=all&release=all&metric=all&company=> (Red Hat<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=Red+Hat>) (#200)
Change Id: I2100915f123c0fea41d5b17d01947901aa0119c5<https://review.openstack.org/84740>
Code Review: 1
[http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon]
Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
20 Feb 2014 09:21:31 in python-keystoneclient<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>
Patch “Initial kerberos plugin implementation.”
Current Status: ABANDONED
Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8<https://review.openstack.org/74974>
[http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon]
Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
18 Feb 2014 10:19:23 in keystone<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=keystone>
Patch “Initial kerberos plugin implementation.”
Current Status: ABANDONED
Change Id: I2fad67c3613c273187f6ca32985d360352c81bf8<https://review.openstack.org/74317>



From: Nathanael Burton [mailto:nathanael.i.burton.work at gmail.com]
Sent: 23 April 2014 14:42
To: Adam Young
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Credentials in clear text


We have to configure the Apache layer to set the component we want as the REMOTE_USER, but other than that I believe that's pretty much all it takes on the Keystone side. Changes were necessary to some of the Python clients and service code, mainly to get them to pass certificates along.  Not all these changes have been proposed upstream yet, although we plan to.

Thanks,

Nate
On Apr 23, 2014 8:33 AM, "Adam Young" <ayoung at redhat.com<mailto:ayoung at redhat.com>> wrote:
On 04/23/2014 08:29 AM, Nathanael Burton wrote:

We do this today with X509 certificates using the external auth plugin for Keystone. Services and users auth directly with X509 certificates to get tokens.

Have you modified it at all?  I have yet to try, but I though with mod_ssl and external, REMOTE_USER was not set.  It was my understanding that the following vars were set in its place:

http://www.freeipa.org/page/Environment_Variables#X.509_Authentication



Nate
On Apr 23, 2014 12:23 AM, "Adam Young" <ayoung at redhat.com<mailto:ayoung at redhat.com>> wrote:
On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:
As Bryan mentioned already, a user with access to production systems, particularly one with sudo/root access – is in an incredibly privileged position. On its own this is an auditing issue but it’s a recognised one. In most deployments subject to auditing (i.e. production) it’s likely that compensating controls such as gated access, user logging, MAC etc. are all in place to control the risk.
It’s a messy problem to deal with. I’ve seen approaches where the process and configuration file are both owned by an elevated user, once the process has loaded the configuration file it drops privs and can no longer read the file, this can be useful as a mechanism for avoiding directory traversal in web services etc I’m not sure how viable an approach this would be with something like Swift.

-Rob

I'd like to see a concerted effort to allowing all servcie to get keystone tokens with either Kerberos (keytabs) or X509 Client certificates.



From: Bryan D. Payne [mailto:bdpayne at acm.org]
Sent: 22 April 2014 01:16
To: Adam Lawson
Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
Subject: Re: [Openstack-security] Credentials in clear text

This is fair.  I'm not personally familiar with Swift, so I will let others chime in on that.
-bryan

On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com<mailto:alawson at aqorn.com>> wrote:
Preventing access to passwords for the purpose of preventing unauthorized access to data as another way I look at it.


Adam Lawson
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914<tel:%2B1%20%28302%29%20268-6914>
[Image removed by sender. http://www.aqorn.com/images/logo.png]

On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com<mailto:alawson at aqorn.com>> wrote:
My initial concern is specific to Swift and gaining global access to all data by virtue of having access to a single proxy node. It seems more than access to system resources but a flaw in how data is controlled (and passwords are controlled).


Adam Lawson
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914<tel:%2B1%20%28302%29%20268-6914>
[Image removed by sender. http://www.aqorn.com/images/logo.png]

On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>> wrote:
This would be a nice hardening step, but if you have sudo on the box there's a lot of things you can do see.  This is just the tip of the iceberg.  For example, access to the backend db?  Access to traffic on the network / unix sockets / etc?  Access to logs.

I am not aware of any current efforts to mask this information from the config files.  But that doesn't mean it's not happening.  If someone is aware of such an effort, I'd certainly be interested in learning more about it.

Cheers,
-bryan



On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com<mailto:alawson at aqorn.com>> wrote:
Have .conf files containing credentials and tokens been addressed or being addressed? Seems there are a lot of keys to the kingdom clearly visible to staff who have access to systems for day-to-day admin work but don't/shouldn't be able to view them. If they have sudo access, they have everything they need to get where they don't belong. Really strikes me as an obvious audit issue...


Adam Lawson
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914<tel:%2B1%20%28302%29%20268-6914>
[Image removed by sender. http://www.aqorn.com/images/logo.png]

_______________________________________________
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






_______________________________________________

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


_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f2ca3a04/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4333 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f2ca3a04/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1686 bytes
Desc: image002.png
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f2ca3a04/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 410 bytes
Desc: image003.jpg
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f2ca3a04/attachment.jpg>

From alawson at aqorn.com  Wed Apr 23 16:48:39 2014
From: alawson at aqorn.com (Adam Lawson)
Date: Wed, 23 Apr 2014 09:48:39 -0700
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5D9B56F5E@CERNXCHG41.cern.ch>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
 <53573FDB.4040409@redhat.com>
 <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>
 <5357B305.6080302@redhat.com>
 <CAM+Mi=tmnyVcUO=s-57Nf2ajt6592WeJCoqFbPCzsff2BFui+g@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5D9B56F5E@CERNXCHG41.cern.ch>
Message-ID: <CAJfWK4_CUTKBLjZdxKAjmGnYhLBHZCTxjUjWsfUdTUrpy5EwXw@mail.gmail.com>

How feasible (or unfeasible) would it be for each service to look for an
encrypted conf file and use the clear text version if the encrypted file
doesn't exist? The file could be all settings but technically only
credentials and tokens would need this level of protection in my estimation.

I could envision doing this, for example, with OpenSSL as follows (bash for
example):
 #!/bin/bash
 #OpenSSL file encryption
decrypt=credentials.txt
encrypt=${decrypt}.encrypted
if [[ $# -eq 0 ]] ; then #encrypt creds in file
    read username
    read -s password
    #write creds to the file
echo ${username}:${password} | openssl des3 -salt  -out $encrypt
elif [[ $1 = '-d' ]] ; then #decrypt creds from file
    openssl des3 -d -salt -in $encrypt -out $decrypt
else
    echo "Error: $1 invalid. Decrypt='-d', Encrypt=no-args" >&2
    exit 1
fi

Thoughts? It just seems (to me of course) like a meaningful design option
for companies who cannot afford to give credentials to all sysadmins with
sudo access to *any* of the nodes for a given solution.




*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914



On Wed, Apr 23, 2014 at 7:24 AM, Tim Bell <Tim.Bell at cern.ch> wrote:

>
>
> I think Jose from CERN has been putting in some work on the clients and
> the server for Kerberos in this area.
>
>
>
> There were some problems with the Kerberos packaging and pre-reqs along
> with how to fake a Kerberos server in the test suite but he was making
> progress.
>
>
>
> Is this on the summit agenda ? It would be good to get it working since I
> think it was on my summit talk in Boston.
>
>
>
> Tim
>
>
>
> *Activity Log*
>
> [image: http://www.gravatar.com/avatar/a1040384?s=64&d=identicon]
>
> *Jose Castro Leon
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *08 Apr 2014 07:14:32 in python-keystoneclient
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>*
>
> *Review "Initial kerberos plugin implementation."*
>
> Submitted by: Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=>
>  (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
> (#35)
>
> Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8<https://review.openstack.org/74974>
>
> Code Review: *1*
>
> [image: http://www.gravatar.com/avatar/a1040384?s=64&d=identicon]
>
> *Jose Castro Leon
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *02 Apr 2014 14:59:32 in requirements
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=requirements>*
>
> *Review "kerberos requires an additional requests library. Older versions
> break in py33"*
>
> Submitted by: Adam Young<http://stackalytics.com/?user_id=ayoung&project_type=all&release=all&metric=all&company=>
>  (Red Hat<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=Red+Hat>)
> (#200)
>
> Change Id: I2100915f123c0fea41d5b17d01947901aa0119c5<https://review.openstack.org/84740>
>
> Code Review: *1*
>
> [image: http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon]
>
> *Jose Castro Leon
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *20 Feb 2014 09:21:31 in python-keystoneclient
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>*
>
> *Patch "Initial kerberos plugin implementation."*
>
> Current Status: ABANDONED
>
> Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8<https://review.openstack.org/74974>
>
> [image: http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon]
>
> *Jose Castro Leon
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *18 Feb 2014 10:19:23 in keystone
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=keystone>*
>
> *Patch "Initial kerberos plugin implementation."*
>
> Current Status: ABANDONED
>
> Change Id: I2fad67c3613c273187f6ca32985d360352c81bf8<https://review.openstack.org/74317>
>
>
>
>
>
>
>
> *From:* Nathanael Burton [mailto:nathanael.i.burton.work at gmail.com]
> *Sent:* 23 April 2014 14:42
> *To:* Adam Young
>
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] Credentials in clear text
>
>
>
> We have to configure the Apache layer to set the component we want as the
> REMOTE_USER, but other than that I believe that's pretty much all it takes
> on the Keystone side. Changes were necessary to some of the Python clients
> and service code, mainly to get them to pass certificates along.  Not all
> these changes have been proposed upstream yet, although we plan to.
>
> Thanks,
>
> Nate
>
> On Apr 23, 2014 8:33 AM, "Adam Young" <ayoung at redhat.com> wrote:
>
>  On 04/23/2014 08:29 AM, Nathanael Burton wrote:
>
> We do this today with X509 certificates using the external auth plugin for
> Keystone. Services and users auth directly with X509 certificates to get
> tokens.
>
>
> Have you modified it at all?  I have yet to try, but I though with mod_ssl
> and external, REMOTE_USER was not set.  It was my understanding that the
> following vars were set in its place:
>
> http://www.freeipa.org/page/Environment_Variables#X.509_Authentication
>
>
>  Nate
>
> On Apr 23, 2014 12:23 AM, "Adam Young" <ayoung at redhat.com> wrote:
>
>  On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:
>
>  As Bryan mentioned already, a user with access to production systems,
> particularly one with sudo/root access - is in an incredibly privileged
> position. On its own this is an auditing issue but it's a recognised one.
> In most deployments subject to auditing (i.e. production) it's likely that
> compensating controls such as gated access, user logging, MAC etc. are all
> in place to control the risk.
>
> It's a messy problem to deal with. I've seen approaches where the process
> and configuration file are both owned by an elevated user, once the process
> has loaded the configuration file it drops privs and can no longer read the
> file, this can be useful as a mechanism for avoiding directory traversal in
> web services etc I'm not sure how viable an approach this would be with
> something like Swift.
>
>
>
> -Rob
>
>
> I'd like to see a concerted effort to allowing all servcie to get keystone
> tokens with either Kerberos (keytabs) or X509 Client certificates.
>
>
>
>
> *From:* Bryan D. Payne [mailto:bdpayne at acm.org <bdpayne at acm.org>]
> *Sent:* 22 April 2014 01:16
> *To:* Adam Lawson
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] Credentials in clear text
>
>
>
> This is fair.  I'm not personally familiar with Swift, so I will let
> others chime in on that.
>
> -bryan
>
>
>
> On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>  Preventing access to passwords for the purpose of preventing
> unauthorized access to data as another way I look at it.
>
>
>
> * Adam Lawson*
>
> AQORN, Inc.
>
> 427 North Tatnall Street
>
> Ste. 58461
>
> Wilmington, Delaware 19801-2230
>
> Toll-free: (844) 4-AQORN-NOW
>
> Direct: +1 (302) 268-6914
>
> [image: Image removed by sender. http://www.aqorn.com/images/logo.png]
>
>
>
> On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>  My initial concern is specific to Swift and gaining global access to all
> data by virtue of having access to a single proxy node. It seems more than
> access to system resources but a flaw in how data is controlled (and
> passwords are controlled).
>
>
>
> * Adam Lawson*
>
> AQORN, Inc.
>
> 427 North Tatnall Street
>
> Ste. 58461
>
> Wilmington, Delaware 19801-2230
>
> Toll-free: (844) 4-AQORN-NOW
>
> Direct: +1 (302) 268-6914
>
> [image: Image removed by sender. http://www.aqorn.com/images/logo.png]
>
>
>
> On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>
>  This would be a nice hardening step, but if you have sudo on the box
> there's a lot of things you can do see.  This is just the tip of the
> iceberg.  For example, access to the backend db?  Access to traffic on the
> network / unix sockets / etc?  Access to logs.
>
>
>
> I am not aware of any current efforts to mask this information from the
> config files.  But that doesn't mean it's not happening.  If someone is
> aware of such an effort, I'd certainly be interested in learning more about
> it.
>
>
>
> Cheers,
>
> -bryan
>
>
>
>
>
>
>
> On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>   Have .conf files containing credentials and tokens been addressed or
> being addressed? Seems there are a lot of keys to the kingdom clearly
> visible to staff who have access to systems for day-to-day admin work but
> don't/shouldn't be able to view them. If they have sudo access, they have
> everything they need to get where they don't belong. Really strikes me as
> an obvious audit issue...
>
>
>
> * Adam Lawson*
>
> AQORN, Inc.
>
> 427 North Tatnall Street
>
> Ste. 58461
>
> Wilmington, Delaware 19801-2230
>
> Toll-free: (844) 4-AQORN-NOW
>
> Direct: +1 (302) 268-6914
>
> [image: Image removed by sender. http://www.aqorn.com/images/logo.png]
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Openstack-security mailing list
>
> Openstack-security at lists.openstack.org
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f96467bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 410 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f96467bd/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1686 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f96467bd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4333 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f96467bd/attachment-0001.png>

From gerrit2 at review.openstack.org  Wed Apr 23 17:27:09 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 23 Apr 2014 17:27:09 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1Wd0wv-0002Rc-My@review.openstack.org>


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

Log:
commit e7ff0fd0e2f3939875b92911fa6f23ce9946969d
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From bdpayne at acm.org  Wed Apr 23 20:30:11 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Wed, 23 Apr 2014 13:30:11 -0700
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAJfWK4_CUTKBLjZdxKAjmGnYhLBHZCTxjUjWsfUdTUrpy5EwXw@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
 <53573FDB.4040409@redhat.com>
 <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>
 <5357B305.6080302@redhat.com>
 <CAM+Mi=tmnyVcUO=s-57Nf2ajt6592WeJCoqFbPCzsff2BFui+g@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5D9B56F5E@CERNXCHG41.cern.ch>
 <CAJfWK4_CUTKBLjZdxKAjmGnYhLBHZCTxjUjWsfUdTUrpy5EwXw@mail.gmail.com>
Message-ID: <CAFpPvXAGbxXSa0Kb8JaxLW8EsoHZM4aLRxww50S+iT9o9F90dQ@mail.gmail.com>

There are several issues with this approach and the code below.  But
perhaps the clearest way to understand the issue here is to ask, "Where
would the decryption password be stored?"

-bryan


On Wed, Apr 23, 2014 at 9:48 AM, Adam Lawson <alawson at aqorn.com> wrote:

> How feasible (or unfeasible) would it be for each service to look for an
> encrypted conf file and use the clear text version if the encrypted file
> doesn't exist? The file could be all settings but technically only
> credentials and tokens would need this level of protection in my estimation.
>
> I could envision doing this, for example, with OpenSSL as follows (bash
> for example):
>  #!/bin/bash
>  #OpenSSL file encryption
> decrypt=credentials.txt
> encrypt=${decrypt}.encrypted
> if [[ $# -eq 0 ]] ; then #encrypt creds in file
>     read username
>     read -s password
>     #write creds to the file
> echo ${username}:${password} | openssl des3 -salt  -out $encrypt
> elif [[ $1 = '-d' ]] ; then #decrypt creds from file
>     openssl des3 -d -salt -in $encrypt -out $decrypt
> else
>     echo "Error: $1 invalid. Decrypt='-d', Encrypt=no-args" >&2
>     exit 1
> fi
>
> Thoughts? It just seems (to me of course) like a meaningful design option
> for companies who cannot afford to give credentials to all sysadmins with
> sudo access to *any* of the nodes for a given solution.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/76c057d4/attachment.html>

From alawson at aqorn.com  Wed Apr 23 21:25:38 2014
From: alawson at aqorn.com (Adam Lawson)
Date: Wed, 23 Apr 2014 14:25:38 -0700
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAFpPvXAGbxXSa0Kb8JaxLW8EsoHZM4aLRxww50S+iT9o9F90dQ@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
 <53573FDB.4040409@redhat.com>
 <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>
 <5357B305.6080302@redhat.com>
 <CAM+Mi=tmnyVcUO=s-57Nf2ajt6592WeJCoqFbPCzsff2BFui+g@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5D9B56F5E@CERNXCHG41.cern.ch>
 <CAJfWK4_CUTKBLjZdxKAjmGnYhLBHZCTxjUjWsfUdTUrpy5EwXw@mail.gmail.com>
 <CAFpPvXAGbxXSa0Kb8JaxLW8EsoHZM4aLRxww50S+iT9o9F90dQ@mail.gmail.com>
Message-ID: <CAJfWK4_S2iaUBa_BPSFnMf5BFV3uKiz59hGstYXNCqTQy=tAeA@mail.gmail.com>

Totally fair Bryan - just trying to sort through this because it came up as
an audit finding. Re that last question, that's the rub for me. For a
service to start, decryption requires a key. Armed with the key, a
nefarious sysadmin can open the file and get the rest of the data. But I'm
struggling with the all or nothing dynamic. I know in Windows, a local
user/password can be set to start a service and that password cannot be
identified by looking at some text file. Unix works a little differently I
know. Okay, a lot differently. ; )

Ideas I had (feel free to blow these up):

   - encrypting the conf file
   - encrypting just the tokens/passwords values within the conf file
   - starting services from a remote location which reduces the credential
   exposure to sysadmins

Also open to other ideas. Is the problem statement clear though / what I'm
trying to sort through? Is embedding credentials in text files best
practice or is it such a common practice that the method isn't really that
big of a deal? Would prefer not to boil the ocean if I can avoid it but
trying to find a path forward...



*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW
Direct: +1 (302) 268-6914



On Wed, Apr 23, 2014 at 1:30 PM, Bryan D. Payne <bdpayne at acm.org> wrote:

> There are several issues with this approach and the code below.  But
> perhaps the clearest way to understand the issue here is to ask, "Where
> would the decryption password be stored?"
>
> -bryan
>
>
> On Wed, Apr 23, 2014 at 9:48 AM, Adam Lawson <alawson at aqorn.com> wrote:
>
>> How feasible (or unfeasible) would it be for each service to look for an
>> encrypted conf file and use the clear text version if the encrypted file
>> doesn't exist? The file could be all settings but technically only
>> credentials and tokens would need this level of protection in my estimation.
>>
>> I could envision doing this, for example, with OpenSSL as follows (bash
>> for example):
>>  #!/bin/bash
>>  #OpenSSL file encryption
>> decrypt=credentials.txt
>> encrypt=${decrypt}.encrypted
>> if [[ $# -eq 0 ]] ; then #encrypt creds in file
>>     read username
>>     read -s password
>>     #write creds to the file
>> echo ${username}:${password} | openssl des3 -salt  -out $encrypt
>> elif [[ $1 = '-d' ]] ; then #decrypt creds from file
>>     openssl des3 -d -salt -in $encrypt -out $decrypt
>> else
>>     echo "Error: $1 invalid. Decrypt='-d', Encrypt=no-args" >&2
>>     exit 1
>> fi
>>
>> Thoughts? It just seems (to me of course) like a meaningful design option
>> for companies who cannot afford to give credentials to all sysadmins with
>> sudo access to *any* of the nodes for a given solution.
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/df9ee57b/attachment.html>

From robert.clark at hp.com  Wed Apr 23 17:06:58 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 23 Apr 2014 17:06:58 +0000
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <CAJfWK4_CUTKBLjZdxKAjmGnYhLBHZCTxjUjWsfUdTUrpy5EwXw@mail.gmail.com>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
 <53573FDB.4040409@redhat.com>
 <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>
 <5357B305.6080302@redhat.com>
 <CAM+Mi=tmnyVcUO=s-57Nf2ajt6592WeJCoqFbPCzsff2BFui+g@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5D9B56F5E@CERNXCHG41.cern.ch>
 <CAJfWK4_CUTKBLjZdxKAjmGnYhLBHZCTxjUjWsfUdTUrpy5EwXw@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A1122D5865@G4W3229.americas.hpqcorp.net>

So in this example you'd require manual intervention to provide the
encryption key. (I believe 'read' takes data from the CLI).

 

That's not going to work for anyone running OpenStack at any sort of
scale. Of course if systems had valid ways to authenticate with Keystone
they could query Barbican for key material, once Barbican is a little
more mature. Then maybe you could look at encrypted configuration files
a little more realistically.

 

-Rob

 

From: Adam Lawson [mailto:alawson at aqorn.com] 
Sent: 23 April 2014 17:49
To: Tim Bell
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Credentials in clear text

 

How feasible (or unfeasible) would it be for each service to look for an
encrypted conf file and use the clear text version if the encrypted file
doesn't exist? The file could be all settings but technically only
credentials and tokens would need this level of protection in my
estimation.

 

I could envision doing this, for example, with OpenSSL as follows (bash
for example):

 #!/bin/bash

 #OpenSSL file encryption

decrypt=credentials.txt

encrypt=${decrypt}.encrypted

if [[ $# -eq 0 ]] ; then #encrypt creds in file

    read username

    read -s password

    #write creds to the file

          echo ${username}:${password} | openssl des3 -salt  -out
$encrypt

elif [[ $1 = '-d' ]] ; then         #decrypt creds from file

    openssl des3 -d -salt -in $encrypt -out $decrypt

else

    echo "Error: $1 invalid. Decrypt='-d', Encrypt=no-args" >&2

    exit 1

fi

 

Thoughts? It just seems (to me of course) like a meaningful design
option for companies who cannot afford to give credentials to all
sysadmins with sudo access to *any* of the nodes for a given solution.

 

 





Adam Lawson

AQORN, Inc.

427 North Tatnall Street

Ste. 58461

Wilmington, Delaware 19801-2230

Toll-free: (844) 4-AQORN-NOW

Direct: +1 (302) 268-6914

  <http://www.aqorn.com/images/logo.png> 

 

On Wed, Apr 23, 2014 at 7:24 AM, Tim Bell <Tim.Bell at cern.ch
<mailto:Tim.Bell at cern.ch> > wrote:

 

I think Jose from CERN has been putting in some work on the clients and
the server for Kerberos in this area. 

 

There were some problems with the Kerberos packaging and pre-reqs along
with how to fake a Kerberos server in the test suite but he was making
progress.

 

Is this on the summit agenda ? It would be good to get it working since
I think it was on my summit talk in Boston.

 

Tim

 

Activity Log



 
<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN)

08 Apr 2014 07:14:32 in
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=&module=python-keystoneclient> python-keystoneclient

Review "Initial kerberos plugin implementation."

Submitted by:
<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN) (#35)

Change Id:  <https://review.openstack.org/74974>
Idf02bf27b5933c00827dd08d11ac131896184ad8

Code Review: 1



 
<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN)

02 Apr 2014 14:59:32 in
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=&module=requirements> requirements

Review "kerberos requires an additional requests library. Older versions
break in py33"

Submitted by:
<http://stackalytics.com/?user_id=ayoung&project_type=all&release=all&me
tric=all&company=> Adam Young (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=Red+Hat> Red Hat) (#200)

Change Id:  <https://review.openstack.org/84740>
I2100915f123c0fea41d5b17d01947901aa0119c5

Code Review: 1



 
<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN)

20 Feb 2014 09:21:31 in
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=&module=python-keystoneclient> python-keystoneclient

Patch "Initial kerberos plugin implementation."

Current Status: ABANDONED

Change Id:  <https://review.openstack.org/74974>
Idf02bf27b5933c00827dd08d11ac131896184ad8



 
<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN)

18 Feb 2014 10:19:23 in
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=&module=keystone> keystone

Patch "Initial kerberos plugin implementation."

Current Status: ABANDONED

Change Id:  <https://review.openstack.org/74317>
I2fad67c3613c273187f6ca32985d360352c81bf8

 

 

 

From: Nathanael Burton [mailto:nathanael.i.burton.work at gmail.com
<mailto:nathanael.i.burton.work at gmail.com> ] 
Sent: 23 April 2014 14:42
To: Adam Young


Cc: openstack-security at lists.openstack.org
<mailto:openstack-security at lists.openstack.org> 
Subject: Re: [Openstack-security] Credentials in clear text

 

We have to configure the Apache layer to set the component we want as
the REMOTE_USER, but other than that I believe that's pretty much all it
takes on the Keystone side. Changes were necessary to some of the Python
clients and service code, mainly to get them to pass certificates along.
Not all these changes have been proposed upstream yet, although we plan
to.

Thanks,

Nate

On Apr 23, 2014 8:33 AM, "Adam Young" <ayoung at redhat.com
<mailto:ayoung at redhat.com> > wrote:

On 04/23/2014 08:29 AM, Nathanael Burton wrote:

We do this today with X509 certificates using the external auth plugin
for Keystone. Services and users auth directly with X509 certificates to
get tokens.


Have you modified it at all?  I have yet to try, but I though with
mod_ssl and external, REMOTE_USER was not set.  It was my understanding
that the following vars were set in its place:

http://www.freeipa.org/page/Environment_Variables#X.509_Authentication



Nate

On Apr 23, 2014 12:23 AM, "Adam Young" <ayoung at redhat.com
<mailto:ayoung at redhat.com> > wrote:

On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:

As Bryan mentioned already, a user with access to production systems,
particularly one with sudo/root access - is in an incredibly privileged
position. On its own this is an auditing issue but it's a recognised
one. In most deployments subject to auditing (i.e. production) it's
likely that compensating controls such as gated access, user logging,
MAC etc. are all in place to control the risk.

It's a messy problem to deal with. I've seen approaches where the
process and configuration file are both owned by an elevated user, once
the process has loaded the configuration file it drops privs and can no
longer read the file, this can be useful as a mechanism for avoiding
directory traversal in web services etc I'm not sure how viable an
approach this would be with something like Swift.

 

-Rob


I'd like to see a concerted effort to allowing all servcie to get
keystone tokens with either Kerberos (keytabs) or X509 Client
certificates.



 

From: Bryan D. Payne [mailto:bdpayne at acm.org] 
Sent: 22 April 2014 01:16
To: Adam Lawson
Cc: openstack-security at lists.openstack.org
<mailto:openstack-security at lists.openstack.org> 
Subject: Re: [Openstack-security] Credentials in clear text

 

This is fair.  I'm not personally familiar with Swift, so I will let
others chime in on that.

-bryan

 

On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com
<mailto:alawson at aqorn.com> > wrote:

Preventing access to passwords for the purpose of preventing
unauthorized access to data as another way I look at it.





Adam Lawson

AQORN, Inc.

427 North Tatnall Street

Ste. 58461

Wilmington, Delaware 19801-2230

Toll-free: (844) 4-AQORN-NOW

Direct:  <tel:%2B1%20%28302%29%20268-6914> +1 (302) 268-6914



 

On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com
<mailto:alawson at aqorn.com> > wrote:

My initial concern is specific to Swift and gaining global access to all
data by virtue of having access to a single proxy node. It seems more
than access to system resources but a flaw in how data is controlled
(and passwords are controlled).





Adam Lawson

AQORN, Inc.

427 North Tatnall Street

Ste. 58461

Wilmington, Delaware 19801-2230

Toll-free: (844) 4-AQORN-NOW

Direct:  <tel:%2B1%20%28302%29%20268-6914> +1 (302) 268-6914



 

On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org
<mailto:bdpayne at acm.org> > wrote:

This would be a nice hardening step, but if you have sudo on the box
there's a lot of things you can do see.  This is just the tip of the
iceberg.  For example, access to the backend db?  Access to traffic on
the network / unix sockets / etc?  Access to logs.

 

I am not aware of any current efforts to mask this information from the
config files.  But that doesn't mean it's not happening.  If someone is
aware of such an effort, I'd certainly be interested in learning more
about it.

 

Cheers,

-bryan

 

 

 

On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com
<mailto:alawson at aqorn.com> > wrote:

Have .conf files containing credentials and tokens been addressed or
being addressed? Seems there are a lot of keys to the kingdom clearly
visible to staff who have access to systems for day-to-day admin work
but don't/shouldn't be able to view them. If they have sudo access, they
have everything they need to get where they don't belong. Really strikes
me as an obvious audit issue...





Adam Lawson

AQORN, Inc.

427 North Tatnall Street

Ste. 58461

Wilmington, Delaware 19801-2230

Toll-free: (844) 4-AQORN-NOW

Direct:  <tel:%2B1%20%28302%29%20268-6914> +1 (302) 268-6914



 

_______________________________________________
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

 

 

 

 

 

_______________________________________________
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

 


_______________________________________________
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

 


_______________________________________________
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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/46a572bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4333 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/46a572bd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1686 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/46a572bd/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 410 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/46a572bd/attachment.jpg>
-------------- 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/20140423/46a572bd/attachment.bin>

From ayoung at redhat.com  Thu Apr 24 01:54:26 2014
From: ayoung at redhat.com (Adam Young)
Date: Wed, 23 Apr 2014 21:54:26 -0400
Subject: [Openstack-security] Credentials in clear text
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5D9B56F5E@CERNXCHG41.cern.ch>
References: <CAJfWK4_af5Yx+EhyS0yWgSFji-=6NXwMKo_O6+17RFMy-9suuA@mail.gmail.com>
 <CAFpPvXAp1D9gsh_MB3rNq8kYi8QwB3xty-dRWVJw+m5BysC2uA@mail.gmail.com>
 <CAJfWK48iepX5vr2WEguu9k2oys4nBdn2ZZA=qdxKx4nRaQqPRQ@mail.gmail.com>
 <CAJfWK4_qK884bkZA-OjoViVKjOESRPUbLgiNo-M7BH7D8twejA@mail.gmail.com>
 <CAFpPvXDLHLOxxWy-5vr0J3fhHrxoQV0sESKuipe_=TH_bbZsOw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122D290F@G4W3229.americas.hpqcorp.net>
 <53573FDB.4040409@redhat.com>
 <CAM+Mi=vas5XJeoszb=jm90Se6asMmAvEgFTHM2tQg_5+vCk61A@mail.gmail.com>
 <5357B305.6080302@redhat.com>
 <CAM+Mi=tmnyVcUO=s-57Nf2ajt6592WeJCoqFbPCzsff2BFui+g@mail.gmail.com>
 <5D7F9996EA547448BC6C54C8C5AAF4E5D9B56F5E@CERNXCHG41.cern.ch>
Message-ID: <53586ED2.2020506@redhat.com>

On 04/23/2014 10:24 AM, Tim Bell wrote:
>
> I think Jose from CERN has been putting in some work on the clients 
> and the server for Kerberos in this area.
>
Yes, I've been working with him on this.  Jamie Lennox is working on the 
necessary Client mechanisms to make various auth plugins available from 
the Unified CLI, etc.
>
> There were some problems with the Kerberos packaging and pre-reqs 
> along with how to fake a Kerberos server in the test suite but he was 
> making progress.
>

Kerberos Requests needs an upstream release we can pull in.  There is a 
change in master not in a released package that we need for Python33

> Is this on the summit agenda ? It would be good to get it working 
> since I think it was on my summit talk in Boston.
>

There is a client talk, but not about this specifically.  We can work 
out details in the Developers lounge, though, and also in the General 
client talks.

> Tim
>
> *Activity Log*
>
> http://www.gravatar.com/avatar/a1040384?s=64&d=identicon
>
> *Jose Castro Leon 
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *08 Apr 2014 07:14:32 in python-keystoneclient 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>*
>
> *Review “Initial kerberos plugin implementation.”*
>
> Submitted by: Jose Castro Leon 
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>) 
> (#35)
>
> Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8 
> <https://review.openstack.org/74974>
>
> Code Review: *1*
>
> http://www.gravatar.com/avatar/a1040384?s=64&d=identicon
>
> *Jose Castro Leon 
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *02 Apr 2014 14:59:32 in requirements 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=requirements>*
>
> *Review “kerberos requires an additional requests library. Older 
> versions break in py33”*
>
> Submitted by: Adam Young 
> <http://stackalytics.com/?user_id=ayoung&project_type=all&release=all&metric=all&company=> (Red 
> Hat 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=Red+Hat>) 
> (#200)
>
> Change Id: I2100915f123c0fea41d5b17d01947901aa0119c5 
> <https://review.openstack.org/84740>
>
> Code Review: *1*
>
> http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon
>
> *Jose Castro Leon 
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *20 Feb 2014 09:21:31 in python-keystoneclient 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>*
>
> *Patch “Initial kerberos plugin implementation.”*
>
> Current Status: ABANDONED
>
> Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8 
> <https://review.openstack.org/74974>
>
> http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon
>
> *Jose Castro Leon 
> <http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)*
>
> *18 Feb 2014 10:19:23 in keystone 
> <http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=keystone>*
>
> *Patch “Initial kerberos plugin implementation.”*
>
> Current Status: ABANDONED
>
> Change Id: I2fad67c3613c273187f6ca32985d360352c81bf8 
> <https://review.openstack.org/74317>
>
> *From:*Nathanael Burton [mailto:nathanael.i.burton.work at gmail.com]
> *Sent:* 23 April 2014 14:42
> *To:* Adam Young
> *Cc:* openstack-security at lists.openstack.org
> *Subject:* Re: [Openstack-security] Credentials in clear text
>
> We have to configure the Apache layer to set the component we want as 
> the REMOTE_USER, but other than that I believe that's pretty much all 
> it takes on the Keystone side. Changes were necessary to some of the 
> Python clients and service code, mainly to get them to pass 
> certificates along.  Not all these changes have been proposed upstream 
> yet, although we plan to.
>
> Thanks,
>
> Nate
>
> On Apr 23, 2014 8:33 AM, "Adam Young" <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     On 04/23/2014 08:29 AM, Nathanael Burton wrote:
>
>         We do this today with X509 certificates using the external
>         auth plugin for Keystone. Services and users auth directly
>         with X509 certificates to get tokens.
>
>
>     Have you modified it at all?  I have yet to try, but I though with
>     mod_ssl and external, REMOTE_USER was not set.  It was my
>     understanding that the following vars were set in its place:
>
>     http://www.freeipa.org/page/Environment_Variables#X.509_Authentication
>
>
>         Nate
>
>         On Apr 23, 2014 12:23 AM, "Adam Young" <ayoung at redhat.com
>         <mailto:ayoung at redhat.com>> wrote:
>
>             On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:
>
>                 As Bryan mentioned already, a user with access to
>                 production systems, particularly one with sudo/root
>                 access – is in an incredibly privileged position. On
>                 its own this is an auditing issue but it’s a
>                 recognised one. In most deployments subject to
>                 auditing (i.e. production) it’s likely that
>                 compensating controls such as gated access, user
>                 logging, MAC etc. are all in place to control the risk.
>
>                 It’s a messy problem to deal with. I’ve seen
>                 approaches where the process and configuration file
>                 are both owned by an elevated user, once the process
>                 has loaded the configuration file it drops privs and
>                 can no longer read the file, this can be useful as a
>                 mechanism for avoiding directory traversal in web
>                 services etc I’m not sure how viable an approach this
>                 would be with something like Swift.
>
>                 -Rob
>
>
>             I'd like to see a concerted effort to allowing all servcie
>             to get keystone tokens with either Kerberos (keytabs) or
>             X509 Client certificates.
>
>
>                 *From:*Bryan D. Payne [mailto:bdpayne at acm.org]
>                 *Sent:* 22 April 2014 01:16
>                 *To:* Adam Lawson
>                 *Cc:* openstack-security at lists.openstack.org
>                 <mailto:openstack-security at lists.openstack.org>
>                 *Subject:* Re: [Openstack-security] Credentials in
>                 clear text
>
>                 This is fair.  I'm not personally familiar with Swift,
>                 so I will let others chime in on that.
>
>                 -bryan
>
>                 On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson
>                 <alawson at aqorn.com <mailto:alawson at aqorn.com>> wrote:
>
>                     Preventing access to passwords for the purpose of
>                     preventing unauthorized access to data as another
>                     way I look at it.
>
>
>                     */
>                     Adam Lawson/*
>
>                     AQORN, Inc.
>
>                     427 North Tatnall Street
>
>                     Ste. 58461
>
>                     Wilmington, Delaware 19801-2230
>
>                     Toll-free: (844) 4-AQORN-NOW
>
>                     Direct: +1 (302) 268-6914
>                     <tel:%2B1%20%28302%29%20268-6914>
>
>                     Image removed by sender.
>                     http://www.aqorn.com/images/logo.png
>
>                     On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson
>                     <alawson at aqorn.com <mailto:alawson at aqorn.com>> wrote:
>
>                         My initial concern is specific to Swift and
>                         gaining global access to all data by virtue of
>                         having access to a single proxy node. It seems
>                         more than access to system resources but a
>                         flaw in how data is controlled (and passwords
>                         are controlled).
>
>
>                         */
>                         Adam Lawson/*
>
>                         AQORN, Inc.
>
>                         427 North Tatnall Street
>
>                         Ste. 58461
>
>                         Wilmington, Delaware 19801-2230
>
>                         Toll-free: (844) 4-AQORN-NOW
>
>                         Direct: +1 (302) 268-6914
>                         <tel:%2B1%20%28302%29%20268-6914>
>
>                         Image removed by sender.
>                         http://www.aqorn.com/images/logo.png
>
>                         On Mon, Apr 21, 2014 at 4:41 PM, Bryan D.
>                         Payne <bdpayne at acm.org
>                         <mailto:bdpayne at acm.org>> wrote:
>
>                             This would be a nice hardening step, but
>                             if you have sudo on the box there's a lot
>                             of things you can do see.  This is just
>                             the tip of the iceberg.  For example,
>                             access to the backend db?  Access to
>                             traffic on the network / unix sockets /
>                             etc?  Access to logs.
>
>                             I am not aware of any current efforts to
>                             mask this information from the config
>                             files.  But that doesn't mean it's not
>                             happening.  If someone is aware of such an
>                             effort, I'd certainly be interested in
>                             learning more about it.
>
>                             Cheers,
>
>                             -bryan
>
>                             On Mon, Apr 21, 2014 at 4:26 PM, Adam
>                             Lawson <alawson at aqorn.com
>                             <mailto:alawson at aqorn.com>> wrote:
>
>                                 Have .conf files containing
>                                 credentials and tokens been addressed
>                                 or being addressed? Seems there are a
>                                 lot of keys to the kingdom clearly
>                                 visible to staff who have access to
>                                 systems for day-to-day admin work but
>                                 don't/shouldn't be able to view them.
>                                 If they have sudo access, they have
>                                 everything they need to get where they
>                                 don't belong. Really strikes me as an
>                                 obvious audit issue...
>
>
>                                 */
>                                 Adam Lawson/*
>
>                                 AQORN, Inc.
>
>                                 427 North Tatnall Street
>
>                                 Ste. 58461
>
>                                 Wilmington, Delaware 19801-2230
>
>                                 Toll-free: (844) 4-AQORN-NOW
>
>                                 Direct: +1 (302) 268-6914
>                                 <tel:%2B1%20%28302%29%20268-6914>
>
>                                 Image removed by sender.
>                                 http://www.aqorn.com/images/logo.png
>
>                                 _______________________________________________
>                                 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
>
>                 _______________________________________________
>
>                 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
>
>
>             _______________________________________________
>             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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/716b73bb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4333 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/716b73bb/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1686 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/716b73bb/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 410 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/716b73bb/attachment.jpe>

From 1287301 at bugs.launchpad.net  Thu Apr 24 07:53:11 2014
From: 1287301 at bugs.launchpad.net (Openstack Gerrit)
Date: Thu, 24 Apr 2014 07:53:11 -0000
Subject: [Openstack-security] [Bug 1287301] Re: Keystone client token cache
 doesn't respect revoked tokens
References: <20140303181556.13017.43780.malonedeb@wampee.canonical.com>
Message-ID: <20140424075311.19100.98844.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/78241
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=8574256f9342faeba2ce64080ab5190023524e0a
Submitter: Jenkins
Branch:    master

commit 8574256f9342faeba2ce64080ab5190023524e0a
Author: Alexei Kornienko <akornienko at mirantis.com>
Date:   Wed Mar 5 16:50:37 2014 +0200

    Ensure that cached token is not revoked
    
    We need to ensure that tokens won't stay in cache after they have been
    revoked.
    
    Changed default revocation_cache_time 300 -> 10 seconds.
    revocation_cache_time has to be << than token_cache_time to make token
    cache efficient.
    
    Fixes bug #1287301
    
    Change-Id: I14c0eacac3b431c06e40385c891a6636736e5b4a


** Changed in: python-keystoneclient
       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/1287301

Title:
  Keystone client token cache doesn't respect revoked tokens

Status in OpenStack Security Advisories:
  Invalid
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  If we'll enable caching for keystoneclient tokens we'll be able to use
  tokens that are already revoked if they are present in cache:

  https://github.com/openstack/python-
  keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831

  steps to recreate:
  1) get a token
  2) use it to make a request via keystoneclient using default properties (thus it will be cached)
  3) delete the token
  4) use the token to make another request via keystoneclient

  expected result: the token should not work (HTTP 401)
  actual result: the token still works

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



From gerrit2 at review.openstack.org  Thu Apr 24 09:47:32 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 24 Apr 2014 09:47:32 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Ibe4a2e57a02c261d85ba6c0d61696f134c54443e
Message-ID: <E1WdGFg-0003VK-0W@review.openstack.org>


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

Log:
commit 672165b68c1d6a5f9d4538f985b2578deedbf4be
Author: Matthieu Huin <mhu at enovance.com>
Date:   Tue Apr 22 17:14:25 2014 +0200

    More random values for oAuth1 verifier
    
    The oAuth1 verifier was generated as a random number ranging from
    1000 to 9999. This small range of numbers is vulnerable to
    brute-force attacks as described in CWE-330. The verifier is now
    a 8-character long alphanumerical string, a good compromise between
    security against guessing and ease of use.
    
    SecurityImpact
    Change-Id: Ibe4a2e57a02c261d85ba6c0d61696f134c54443e
    Closes-Bug: #1236675




From gerrit2 at review.openstack.org  Thu Apr 24 14:38:09 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 24 Apr 2014 14:38:09 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Ibe4a2e57a02c261d85ba6c0d61696f134c54443e
Message-ID: <E1WdKmv-0004bA-OI@review.openstack.org>


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

Log:
commit fd719997c185d016637dca0237bd8c145415c7e8
Author: Matthieu Huin <mhu at enovance.com>
Date:   Tue Apr 22 17:14:25 2014 +0200

    More random values for oAuth1 verifier
    
    The oAuth1 verifier was generated as a random number ranging from
    1000 to 9999. This small range of numbers is vulnerable to
    brute-force attacks as described in CWE-330. The verifier is now
    a 8-character long alphanumerical string, a good compromise between
    security against guessing and ease of use.
    
    SecurityImpact
    Change-Id: Ibe4a2e57a02c261d85ba6c0d61696f134c54443e
    Closes-Bug: #1236675




From malini.k.bhandaru at intel.com  Thu Apr 24 18:23:07 2014
From: malini.k.bhandaru at intel.com (Malini Bhandaru)
Date: Thu, 24 Apr 2014 18:23:07 -0000
Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set
	insecure file permissions
References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140424182308.27281.67280.launchpad@gac.canonical.com>

** Changed in: ossn
     Assignee: (unassigned) => Malini Bhandaru (malini-k-bhandaru)

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

Title:
  Multiple drivers set insecure file permissions

Status in Cinder:
  In Progress
Status in OpenStack Security Notes:
  Confirmed

Bug description:
  GPFS from various places calls "chmod 666" as root:

  ./cinder/volume/drivers/gpfs.py:        self._execute('chmod', '666', path, run_as_root=True)
  ./cinder/volume/drivers/gpfs.py:            self._execute('chmod', '666', vol_path, run_as_root=True)

  the Huawei driver sets 777 permissions as root on some files:

  ./cinder/volume/drivers/huawei/ssh_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)
  ./cinder/volume/drivers/huawei/rest_common.py: utils.execute('chmod', '777', filepath, run_as_root=True)

  the Scality driver sets 666 permissions on all volumes:

  cinder/volume/drivers/scality.py:

      def _create_file(self, path, size):
          with open(path, "ab") as f:
              f.truncate(size)
          os.chmod(path, 0o666)

  Similarly, the NFS and NEXENTA driver have an implementation of

  def _set_rw_permissions_for_all()

  that is being called on all newly created volumes.

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



From gerrit2 at review.openstack.org  Thu Apr 24 21:13:26 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 24 Apr 2014 21:13:26 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WdQxS-00069E-I3@review.openstack.org>


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

Log:
commit 2c96150979f3df0becfd89591415ad98a1325a5c
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Thu Apr 24 21:41:41 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 24 Apr 2014 21:41:41 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WdROn-0000Lo-RW@review.openstack.org>


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

Log:
commit 9003b6a8a72ebc0ef57e2388bb54c243b6e13430
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Thu Apr 24 23:19:23 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 24 Apr 2014 23:19:23 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WdSvL-0001S6-BO@review.openstack.org>


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

Log:
commit 983fc3606c9f3aab1d89e03ae6e8b029150975f6
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Thu Apr 24 23:38:53 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 24 Apr 2014 23:38:53 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1WdTED-0003Jd-VT@review.openstack.org>


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

Log:
commit 4d21f981a2f99a64ee4fdd17f51143761331907f
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From 1174499 at bugs.launchpad.net  Thu Apr 24 23:38:43 2014
From: 1174499 at bugs.launchpad.net (Openstack Gerrit)
Date: Thu, 24 Apr 2014 23:38:43 -0000
Subject: [Openstack-security] [Bug 1174499] Related fix proposed to
	python-keystoneclient (master)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140424233843.26914.24162.malone@gac.canonical.com>

Related fix proposed to branch: master
Review: https://review.openstack.org/90251

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

Title:
  Keystone token hashing is MD5

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

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



From 1174499 at bugs.launchpad.net  Fri Apr 25 08:08:44 2014
From: 1174499 at bugs.launchpad.net (Openstack Gerrit)
Date: Fri, 25 Apr 2014 08:08:44 -0000
Subject: [Openstack-security] [Bug 1174499] Related fix merged to
	python-keystoneclient (master)
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140425080844.18533.66689.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/90251
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=bef7f497f0fdcb7d9f529c8b0a811d79b4465f3a
Submitter: Jenkins
Branch:    master

commit bef7f497f0fdcb7d9f529c8b0a811d79b4465f3a
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Apr 24 18:29:07 2014 -0500

    Enhance tests for auth_token middleware
    
    There was code in _verify_uuid_token that was not covered by unit
    tests. This change increases the coverage.
    
    Change-Id: I63e171a0a8e63ae599c967adc9ff09670063b807
    Related-Bug: #1174499

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

Title:
  Keystone token hashing is MD5

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Committed
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  In Progress

Bug description:
  https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/common/cms.py

  def cms_hash_token(token_id):
      """
  return: for ans1_token, returns the hash of the passed in token
  otherwise, returns what it was passed in.
  """
      if token_id is None:
          return None
      if is_ans1_token(token_id):
          hasher = hashlib.md5()
          hasher.update(token_id)
          return hasher.hexdigest()
      else:
          return token_id

  
  MD5 is a deprecated mechanism, it should be replaces with at least SHA1, if not SHA256.
  Keystone should be able to support multiple Hash types, and the auth_token middleware should query Keystone to find out which type is in use.

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



From gerrit2 at review.openstack.org  Fri Apr 25 14:07:30 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 25 Apr 2014 14:07:30 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie524125dc5f6f1076bfd47db3a414b178e4dac80
Message-ID: <E1Wdgmo-000806-4T@review.openstack.org>


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

Log:
commit 20f75c47f0dcea2bcb2593c5120cf324663a8f86
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Tue Apr 8 20:52:27 2014 -0500

    auth_token middleware hashes tokens with configurable algorithm
    
    The auth_token middleware always hashed PKI Tokens with MD5. This
    change makes it so that PKI tokens can be hashed with SHA256 or any
    other algorithm supported by hashlib.new(). This is for security
    hardening.
    
    auth_token has a new config option 'hash_algorithms' that is set
    to the list of algorithms that will be used for hashing PKI tokens.
    This will typically be set to a single hash algorithm which must
    match the hash algorithm set in Keystone. Otherwise the tokens
    in the revocation list will not match, leading to revoked tokens
    being still usable.
    
    During a transition from one algorithm to another,
    'hash_algorithms' is set to both the new algorithm and the old
    algorithm. Both of the hash algorithms will be used to match
    against the revocation list and cache. Once the tokens using the
    old algorithm have expired the old algorithm can be removed from
    the list.
    
    'hash_algorithms' defaults to ['md5'] for backwards compatibility.
    
    DocImpact
    SecurityImpact
    Closes-Bug: #1174499
    
    Change-Id: Ie524125dc5f6f1076bfd47db3a414b178e4dac80




From gerrit2 at review.openstack.org  Mon Apr 28 12:25:26 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 28 Apr 2014 12:25:26 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I20ddab5c3359071daf7505268c72331e4c786987
Message-ID: <E1Wekcg-0003Er-RD@review.openstack.org>


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

Log:
commit 32d8517de833159a3d912cfcb3abb673f5394f12
Author: Thomas Leaman <thomas.leaman at hp.com>
Date:   Mon Feb 24 17:03:33 2014 +0000

    Bump python-swiftclient version
    
    https://review.openstack.org/#/c/69187/ introduced SSL certificate checking
    in python-swiftclient (released as v2.0). This patch ensures that the version
    of swiftclient used will verify SSL certificates correctly.
    
    This patch also documents the `swift_store_auth_insecure` configuration
    option for bypassing the cert verification
    
    DocImpact
    SecurityImpact
    
    Change-Id: I20ddab5c3359071daf7505268c72331e4c786987




From sriram at sriramhere.com  Mon Apr 28 18:03:42 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Mon, 28 Apr 2014 11:03:42 -0700
Subject: [Openstack-security] Fuzzy test framework Dev Session in Atlanta
In-Reply-To: <FD9023AAE9C10145BD4DDD6CB11F8D580D49E51483@QEO40075.de.t-online.corp>
References: <CAFpPvXAcHVxSJA8_wFViFdm3Z0th_T+HWUhBMwxEdF+gi+KRjA@mail.gmail.com>
 <CF753EE4.97D7%robert.clark@hp.com>
 <CAFpPvXAxBY+NDJaLWKdz0x0HXhUYND5PCKUTr+tc6wR1o50Kxw@mail.gmail.com>
 <FD9023AAE9C10145BD4DDD6CB11F8D580D49E51483@QEO40075.de.t-online.corp>
Message-ID: <CAP6wb7+6oh21vdgLLh-HG2wreOOSOyYENMHOKujH4dRV1abRLA@mail.gmail.com>

Dear All,

Earlier I had mentioned that we have proposed an project for GSoC related
to this. Happy to announce that it has been selected. Manishanker (cc-ed)
will be the intern working on.

http://www.google-melange.com/gsoc/project/details/google/gsoc2014/manishanker/5649050225344512

We could collaborate/ work together to avoid duplication, would love to
attend this session.

thanks,
-Sriram


On Mon, Apr 21, 2014 at 11:38 PM, Koderer, Marc <m.koderer at telekom.de>wrote:

> Hi Gents,
>
>
>
> Cool!
>
> could you add a short comment on the session that you are interested. We
> have many session proposals this year and this would increase the chances
> to get it in.
>
>
>
> http://summit.openstack.org/cfp/details/323
>
>
>
> Regards
>
> Marc
>
>
>
> *Von:* bdpayne at gmail.com [mailto:bdpayne at gmail.com] *Im Auftrag von *Bryan
> D. Payne
> *Gesendet:* Donnerstag, 17. April 2014 19:03
> *An:* Clark, Robert Graham
> *Cc:* Koderer, Marc; openstack-security at lists.openstack.org
> *Betreff:* Re: [Openstack-security] Fuzzy test framework Dev Session in
> Atlanta
>
>
>
> Bryan - should we look to make a schedule that highlights all the
> interesting talks/sessions for the summit ?
>
>
>
> We have done this in the past and I'm not sure that others have found it
> too useful / valuable.  May not be worth the effort this time around.
>
> -bryan
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>


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

From robert.clark at hp.com  Mon Apr 28 18:04:35 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 28 Apr 2014 18:04:35 +0000
Subject: [Openstack-security] Fuzzy test framework Dev Session in Atlanta
In-Reply-To: <CAP6wb7+6oh21vdgLLh-HG2wreOOSOyYENMHOKujH4dRV1abRLA@mail.gmail.com>
References: <CAFpPvXAcHVxSJA8_wFViFdm3Z0th_T+HWUhBMwxEdF+gi+KRjA@mail.gmail.com>
 <CF753EE4.97D7%robert.clark@hp.com>
 <CAFpPvXAxBY+NDJaLWKdz0x0HXhUYND5PCKUTr+tc6wR1o50Kxw@mail.gmail.com>
 <FD9023AAE9C10145BD4DDD6CB11F8D580D49E51483@QEO40075.de.t-online.corp>
 <CAP6wb7+6oh21vdgLLh-HG2wreOOSOyYENMHOKujH4dRV1abRLA@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A1122D9A77@G4W3229.americas.hpqcorp.net>

This is great news!

 

From: Sriram Subramanian [mailto:sriram at sriramhere.com] 
Sent: 28 April 2014 19:04
To: Koderer, Marc
Cc: Bryan D. Payne; Clark, Robert Graham;
openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Fuzzy test framework Dev Session in
Atlanta

 

Dear All,

 

Earlier I had mentioned that we have proposed an project for GSoC
related to this. Happy to announce that it has been selected.
Manishanker (cc-ed) will be the intern working on.

 

http://www.google-melange.com/gsoc/project/details/google/gsoc2014/manis
hanker/5649050225344512

 

We could collaborate/ work together to avoid duplication, would love to
attend this session. 

 

thanks,

-Sriram

 

On Mon, Apr 21, 2014 at 11:38 PM, Koderer, Marc <m.koderer at telekom.de
<mailto:m.koderer at telekom.de> > wrote:

Hi Gents,

 

Cool!

could you add a short comment on the session that you are interested. We
have many session proposals this year and this would increase the
chances to get it in.

 

 <http://summit.openstack.org/cfp/details/323>
http://summit.openstack.org/cfp/details/323

 

Regards

Marc

 

Von: bdpayne at gmail.com <mailto:bdpayne at gmail.com>
[mailto:bdpayne at gmail.com <mailto:bdpayne at gmail.com> ] Im Auftrag von
Bryan D. Payne
Gesendet: Donnerstag, 17. April 2014 19:03
An: Clark, Robert Graham
Cc: Koderer, Marc; openstack-security at lists.openstack.org
<mailto:openstack-security at lists.openstack.org> 
Betreff: Re: [Openstack-security] Fuzzy test framework Dev Session in
Atlanta

 

Bryan - should we look to make a schedule that highlights all the
interesting talks/sessions for the summit ?

 

We have done this in the past and I'm not sure that others have found it
too useful / valuable.  May not be worth the effort this time around.

-bryan


_______________________________________________
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





 

-- 

Thanks,

-Sriram

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140428/5418fe22/attachment.html>
-------------- 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/20140428/5418fe22/attachment.bin>

From nkinder at redhat.com  Mon Apr 28 18:50:22 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Mon, 28 Apr 2014 11:50:22 -0700
Subject: [Openstack-security] Secure messaging with Kite
Message-ID: <535EA2EE.7020504@redhat.com>

Hi,

There was some discussion in our OSSG meeting last week about secure
messaging and Kite.  There was interest from a few people about knowing
more about how Kite works, so I prepared the following write-up that
goes into the details:

    https://blog-nkinder.rhcloud.com/?p=62

Any feedback or suggestions related to Kite (or secure messaging in
general) are welcome!  I think that this is an important area where we
can make some important improvements to the security of OpenStack.

Thanks,
-NGK



From gerrit2 at review.openstack.org  Tue Apr 29 00:54:47 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 29 Apr 2014 00:54:47 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WewJr-0003zD-LE@review.openstack.org>


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

Log:
commit 7c8ce4027ef31efc0dfbd0d83daf38335d1afaa3
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From shanker.mani0 at gmail.com  Tue Apr 29 06:32:56 2014
From: shanker.mani0 at gmail.com (MANISHANKER TALUSANI)
Date: Tue, 29 Apr 2014 12:02:56 +0530
Subject: [Openstack-security] Fuzzing project in GSOC2014
Message-ID: <CAD3A53hnoVEJBFuf7wT5ZtzWmG+u3J7h3J+hj6XyALNixRxp4A@mail.gmail.com>

Hello everyone,

I am an undergraduate student from India. I have been selected for
GSOC(Google Summer Of Code) to work on one of the Openstack project[1]
under the guidance of   Sriram Subramanian. Further details about GSOC can
be found here [2]. The project idea page is [3] and student proposal for
the project idea is[4].

[1]
http://www.google-melange.com/gsoc/project/details/google/gsoc2014/manishanker/5649050225344512
[2]https://wiki.openstack.org/wiki/GSoC2014
[3]https://wiki.openstack.org/wiki/GSoC2014/Testing/Fuzz
[4]https://wiki.openstack.org/wiki/GSoC2014/Student/Manishanker

Regards
Manishanker Talusani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140429/069f8149/attachment.html>

From gerrit2 at review.openstack.org  Tue Apr 29 10:00:50 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 29 Apr 2014 10:00:50 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Ibe4a2e57a02c261d85ba6c0d61696f134c54443e
Message-ID: <E1Wf4qI-0005sL-Va@review.openstack.org>


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

Log:
commit 9453203bf1b772de93c34680f4e782c55dd7a71e
Author: Matthieu Huin <mhu at enovance.com>
Date:   Tue Apr 22 17:14:25 2014 +0200

    More random values for oAuth1 verifier
    
    The oAuth1 verifier was generated as a random number ranging from
    1000 to 9999. This small range of numbers is vulnerable to
    brute-force attacks as described in CWE-330. The verifier is now
    a 8-character long alphanumerical string, a good compromise between
    security against guessing and ease of use.
    
    SecurityImpact
    Change-Id: Ibe4a2e57a02c261d85ba6c0d61696f134c54443e
    Closes-Bug: #1236675




From hao.1.wang at gmail.com  Tue Apr 29 13:06:19 2014
From: hao.1.wang at gmail.com (Hao Wang)
Date: Tue, 29 Apr 2014 09:06:19 -0400
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
Message-ID: <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>

Adding security group...


On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com> wrote:

> It is the client. I got this message with DEBUG enabled:
> curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
> "Content-Type: application/json" -H "Accept: application/json" -H
> "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin",
> "passwordCredentials": {"username": "admin", "password": "admin"}}}'
>
> It can be seen that username and password are right in the message.
>
> Hao
>
>
> On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister <aaron.knister at gmail.com>wrote:
>
>> Was it the client or the server that exposed the credentials?
>>
>> Sent from my iPhone
>>
>> On Apr 26, 2014, at 2:28 PM, Hao Wang <hao.1.wang at gmail.com> wrote:
>>
>> Hi,
>>
>> I am troubleshooting a neutron case. It was just found that if DEBUG was
>> enabled, neutron would print out JSON data with username and password. I am
>> wondering what kind of protocol is used in production environment to
>> prevent this security risk from happening.
>>
>> Thanks,
>> Hao
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140429/b11a11f2/attachment.html>

From m.channappa.negalur at accenture.com  Tue Apr 29 13:25:58 2014
From: m.channappa.negalur at accenture.com (m.channappa.negalur at accenture.com)
Date: Tue, 29 Apr 2014 13:25:58 +0000
Subject: [Openstack-security] Roles and group access in openstack
Message-ID: <62B2E0AF85006349B035A166913276B20720A982@048-CH1MPN3-393.048d.mgd.msft.net>

Hi Team,

I would like to configure below security settings on my multimode  cloud setup ( Havana, Ubuntu 12.04 LTS-already installed)


1.       I have created DBusers as a tenant , DBAdmin as a role , db1(Role-DBdmin, belongs to DBgrpup) & db2(normal member role, group not assigned) are 2 users.

2.       I have created Appusers as a tenant, Appadmin as a role , app1(Role-DBdmin, belongs to AppGroup) & app2 (normal member role, , group not assigned) & are 2 users.

Now I want to set security  in such a way that db2 user shouldnot be able to attach a volumes as he is  not a part of DBgroup  , but db1 should be able to do it ( as he is a part of DBAdmin role+ DBgrpup).

Also Appuseres should not be able to delete db2 users instance /reboot /attaching..etc......


How can I set this in ..? Do I need to set this in policy.json. if yes...please give some examples .

Your assistance is much appreciated ...

Regards,
Malleshi CN

________________________________

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140429/c55bdcdf/attachment.html>

From robert.clark at hp.com  Tue Apr 29 14:07:59 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 29 Apr 2014 14:07:59 +0000
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>

This is why any production API servers should all be running TLS/SSL – to protect the confidentiality of messages in flight.

 

There have been efforts to remove sensitive information from logs, I’m a little surprised that passwords are logged in Neutron.

 

From: Hao Wang [mailto:hao.1.wang at gmail.com] 
Sent: 29 April 2014 14:06
To: openstack-security at lists.openstack.org
Cc: openstack; Aaron Knister
Subject: Re: [Openstack-security] [Openstack] API Security

 

Adding security group...

 

On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> > wrote:

It is the client. I got this message with DEBUG enabled:

curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "password": "admin"}}}'

 

It can be seen that username and password are right in the message.

 

Hao

 

On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister <aaron.knister at gmail.com <mailto:aaron.knister at gmail.com> > wrote:

Was it the client or the server that exposed the credentials?

Sent from my iPhone


On Apr 26, 2014, at 2:28 PM, Hao Wang <hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> > wrote:

Hi,

 

I am troubleshooting a neutron case. It was just found that if DEBUG was enabled, neutron would print out JSON data with username and password. I am wondering what kind of protocol is used in production environment to prevent this security risk from happening.

 

Thanks,

Hao

_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : openstack at lists.openstack.org <mailto:openstack at lists.openstack.org> 
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140429/d845af24/attachment.html>
-------------- 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/20140429/d845af24/attachment.bin>

From hao.1.wang at gmail.com  Tue Apr 29 14:25:57 2014
From: hao.1.wang at gmail.com (Hao Wang)
Date: Tue, 29 Apr 2014 10:25:57 -0400
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>
Message-ID: <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>

Thanks. It makes sense. The other questions are, would Heartbleed be a
potential risk? Which solution is being used in OpenStack SSL?


On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham
<robert.clark at hp.com>wrote:

> This is why any production API servers should all be running TLS/SSL – to
> protect the confidentiality of messages in flight.
>
>
>
> There have been efforts to remove sensitive information from logs, I’m a
> little surprised that passwords are logged in Neutron.
>
>
>
> *From:* Hao Wang [mailto:hao.1.wang at gmail.com]
> *Sent:* 29 April 2014 14:06
> *To:* openstack-security at lists.openstack.org
> *Cc:* openstack; Aaron Knister
> *Subject:* Re: [Openstack-security] [Openstack] API Security
>
>
>
> Adding security group...
>
>
>
> On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com> wrote:
>
> It is the client. I got this message with DEBUG enabled:
>
> curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
> "Content-Type: application/json" -H "Accept: application/json" -H
> "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin",
> "passwordCredentials": {"username": "admin", "password": "admin"}}}'
>
>
>
> It can be seen that username and password are right in the message.
>
>
>
> Hao
>
>
>
> On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister <aaron.knister at gmail.com>
> wrote:
>
> Was it the client or the server that exposed the credentials?
>
> Sent from my iPhone
>
>
> On Apr 26, 2014, at 2:28 PM, Hao Wang <hao.1.wang at gmail.com> wrote:
>
> Hi,
>
>
>
> I am troubleshooting a neutron case. It was just found that if DEBUG was
> enabled, neutron would print out JSON data with username and password. I am
> wondering what kind of protocol is used in production environment to
> prevent this security risk from happening.
>
>
>
> Thanks,
>
> Hao
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140429/89ebe123/attachment.html>

From robert.clark at hp.com  Tue Apr 29 14:38:36 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 29 Apr 2014 14:38:36 +0000
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>
 <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A1122E432F@G4W3300.americas.hpqcorp.net>

Absolutely, for people that haven’t updated their SSL libraries (where OpenSSL was in use) there could be some level of exposure.

 

This has actually been addressed in an OpenStack Security Note: https://wiki.openstack.org/wiki/OSSN/OSSN-0012

 

From: Hao Wang [mailto:hao.1.wang at gmail.com] 
Sent: 29 April 2014 15:26
To: Clark, Robert Graham
Cc: openstack-security at lists.openstack.org; openstack; Aaron Knister
Subject: Re: [Openstack-security] [Openstack] API Security

 

Thanks. It makes sense. The other questions are, would Heartbleed be a potential risk? Which solution is being used in OpenStack SSL?

 

On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham <robert.clark at hp.com <mailto:robert.clark at hp.com> > wrote:

This is why any production API servers should all be running TLS/SSL – to protect the confidentiality of messages in flight.

 

There have been efforts to remove sensitive information from logs, I’m a little surprised that passwords are logged in Neutron.

 

From: Hao Wang [mailto:hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> ] 
Sent: 29 April 2014 14:06
To: openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> 
Cc: openstack; Aaron Knister
Subject: Re: [Openstack-security] [Openstack] API Security

 

Adding security group...

 

On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> > wrote:

It is the client. I got this message with DEBUG enabled:

curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "password": "admin"}}}'

 

It can be seen that username and password are right in the message.

 

Hao

 

On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister <aaron.knister at gmail.com <mailto:aaron.knister at gmail.com> > wrote:

Was it the client or the server that exposed the credentials?

Sent from my iPhone


On Apr 26, 2014, at 2:28 PM, Hao Wang <hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> > wrote:

Hi,

 

I am troubleshooting a neutron case. It was just found that if DEBUG was enabled, neutron would print out JSON data with username and password. I am wondering what kind of protocol is used in production environment to prevent this security risk from happening.

 

Thanks,

Hao

_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : openstack at lists.openstack.org <mailto:openstack at lists.openstack.org> 
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140429/1585f3d9/attachment.html>
-------------- 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/20140429/1585f3d9/attachment.bin>

From rcritten at redhat.com  Tue Apr 29 14:39:11 2014
From: rcritten at redhat.com (Rob Crittenden)
Date: Tue, 29 Apr 2014 10:39:11 -0400
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>
 <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>
Message-ID: <535FB98F.9050208@redhat.com>

Hao Wang wrote:
> Thanks. It makes sense. The other questions are, would Heartbleed be a
> potential risk? Which solution is being used in OpenStack SSL?

Native SSL services (eventlet) are based on OpenSSL, as is Apache 
(horizon) so yes, the risk is there if you haven't updated your OpenSSL 
libraries.

The general consensus however is to use SSL terminators rather than 
enabling SSL in the endpoints directly. You'd need to investigate the 
SSL library in the terminator you choose, though it would likely be OpenSSL.

Check this out as well, https://blog-nkinder.rhcloud.com/?p=7

rob

>
>
> On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham
> <robert.clark at hp.com <mailto:robert.clark at hp.com>> wrote:
>
>     This is why any production API servers should all be running TLS/SSL
>     – to protect the confidentiality of messages in flight.____
>
>     __ __
>
>     There have been efforts to remove sensitive information from logs,
>     I’m a little surprised that passwords are logged in Neutron.____
>
>     __ __
>
>     *From:*Hao Wang [mailto:hao.1.wang at gmail.com
>     <mailto:hao.1.wang at gmail.com>]
>     *Sent:* 29 April 2014 14:06
>     *To:* openstack-security at lists.openstack.org
>     <mailto:openstack-security at lists.openstack.org>
>     *Cc:* openstack; Aaron Knister
>     *Subject:* Re: [Openstack-security] [Openstack] API Security____
>
>     __ __
>
>     Adding security group...____
>
>     __ __
>
>     On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com
>     <mailto:hao.1.wang at gmail.com>> wrote:____
>
>         It is the client. I got this message with DEBUG enabled:____
>
>         curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
>         "Content-Type: application/json" -H "Accept: application/json"
>         -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName":
>         "admin", "passwordCredentials": {"username": "admin",
>         "password": "admin"}}}'____
>
>         __ __
>
>         It can be seen that username and password are right in the
>         message.____
>
>         __ __
>
>         Hao____
>
>         __ __
>
>         On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister
>         <aaron.knister at gmail.com <mailto:aaron.knister at gmail.com>>
>         wrote:____
>
>             Was it the client or the server that exposed the credentials?
>
>             Sent from my iPhone____
>
>
>             On Apr 26, 2014, at 2:28 PM, Hao Wang <hao.1.wang at gmail.com
>             <mailto:hao.1.wang at gmail.com>> wrote:____
>
>                 Hi,____
>
>                 __ __
>
>                 I am troubleshooting a neutron case. It was just found
>                 that if DEBUG was enabled, neutron would print out JSON
>                 data with username and password. I am wondering what
>                 kind of protocol is used in production environment to
>                 prevent this security risk from happening.____
>
>                 __ __
>
>                 Thanks,____
>
>                 Hao____
>
>                 _______________________________________________
>                 Mailing list:
>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>                 Post to     : openstack at lists.openstack.org
>                 <mailto:openstack at lists.openstack.org>
>                 Unsubscribe :
>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack____
>
>         __ __
>
>     __ __
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>




From robert.clark at hp.com  Tue Apr 29 14:41:38 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 29 Apr 2014 14:41:38 +0000
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <535FB98F.9050208@redhat.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>
 <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>
 <535FB98F.9050208@redhat.com>
Message-ID: <A0C170085C37664D93EE1604364858A1122E4342@G4W3300.americas.hpqcorp.net>

I'd say the top three terminators in use today are probably Stunnel,
Stud and Pound - all rely on OpenSSL. I'm sure there's a plethora of
alternatives but I'd imagine most are OpenSSL based, the most likely
alternative being NSS which is a big library to use for something like a
terminator.

> -----Original Message-----
> From: Rob Crittenden [mailto:rcritten at redhat.com]
> Sent: 29 April 2014 15:39
> To: Hao Wang; Clark, Robert Graham
> Cc: openstack-security at lists.openstack.org; openstack; Aaron Knister
> Subject: Re: [Openstack-security] [Openstack] API Security
> 
> Hao Wang wrote:
> > Thanks. It makes sense. The other questions are, would Heartbleed be
a
> > potential risk? Which solution is being used in OpenStack SSL?
> 
> Native SSL services (eventlet) are based on OpenSSL, as is Apache
> (horizon) so yes, the risk is there if you haven't updated your
OpenSSL
> libraries.
> 
> The general consensus however is to use SSL terminators rather than
> enabling SSL in the endpoints directly. You'd need to investigate the
SSL
> library in the terminator you choose, though it would likely be
OpenSSL.
> 
> Check this out as well, https://blog-nkinder.rhcloud.com/?p=7
> 
> rob
> 
> >
> >
> > On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham
> > <robert.clark at hp.com <mailto:robert.clark at hp.com>> wrote:
> >
> >     This is why any production API servers should all be running
TLS/SSL
> >     - to protect the confidentiality of messages in flight.____
> >
> >     __ __
> >
> >     There have been efforts to remove sensitive information from
logs,
> >     I'm a little surprised that passwords are logged in Neutron.____
> >
> >     __ __
> >
> >     *From:*Hao Wang [mailto:hao.1.wang at gmail.com
> >     <mailto:hao.1.wang at gmail.com>]
> >     *Sent:* 29 April 2014 14:06
> >     *To:* openstack-security at lists.openstack.org
> >     <mailto:openstack-security at lists.openstack.org>
> >     *Cc:* openstack; Aaron Knister
> >     *Subject:* Re: [Openstack-security] [Openstack] API Security____
> >
> >     __ __
> >
> >     Adding security group...____
> >
> >     __ __
> >
> >     On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com
> >     <mailto:hao.1.wang at gmail.com>> wrote:____
> >
> >         It is the client. I got this message with DEBUG enabled:____
> >
> >         curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
> >         "Content-Type: application/json" -H "Accept:
application/json"
> >         -H "User-Agent: python-novaclient" -d '{"auth":
{"tenantName":
> >         "admin", "passwordCredentials": {"username": "admin",
> >         "password": "admin"}}}'____
> >
> >         __ __
> >
> >         It can be seen that username and password are right in the
> >         message.____
> >
> >         __ __
> >
> >         Hao____
> >
> >         __ __
> >
> >         On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister
> >         <aaron.knister at gmail.com <mailto:aaron.knister at gmail.com>>
> >         wrote:____
> >
> >             Was it the client or the server that exposed the
credentials?
> >
> >             Sent from my iPhone____
> >
> >
> >             On Apr 26, 2014, at 2:28 PM, Hao Wang
<hao.1.wang at gmail.com
> >             <mailto:hao.1.wang at gmail.com>> wrote:____
> >
> >                 Hi,____
> >
> >                 __ __
> >
> >                 I am troubleshooting a neutron case. It was just
found
> >                 that if DEBUG was enabled, neutron would print out
JSON
> >                 data with username and password. I am wondering what
> >                 kind of protocol is used in production environment
to
> >                 prevent this security risk from happening.____
> >
> >                 __ __
> >
> >                 Thanks,____
> >
> >                 Hao____
> >
> >                 _______________________________________________
> >                 Mailing list:
> >
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> >                 Post to     : openstack at lists.openstack.org
> >                 <mailto:openstack at lists.openstack.org>
> >                 Unsubscribe :
> >
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack____
> >
> >         __ __
> >
> >     __ __
> >
> >
> >
> >
> > _______________________________________________
> > 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/20140429/c9f6b0ed/attachment.bin>

From hao.1.wang at gmail.com  Tue Apr 29 14:53:13 2014
From: hao.1.wang at gmail.com (Hao Wang)
Date: Tue, 29 Apr 2014 10:53:13 -0400
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <A0C170085C37664D93EE1604364858A1122E432F@G4W3300.americas.hpqcorp.net>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>
 <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122E432F@G4W3300.americas.hpqcorp.net>
Message-ID: <CAAq+zWFehcJWBCNfR0+QSZnydH+Yhk3SxH_sN1D3r4eEcx0paA@mail.gmail.com>

That is great information! Thanks.


On Tue, Apr 29, 2014 at 10:38 AM, Clark, Robert Graham
<robert.clark at hp.com>wrote:

> Absolutely, for people that haven’t updated their SSL libraries (where
> OpenSSL was in use) there could be some level of exposure.
>
>
>
> This has actually been addressed in an OpenStack Security Note:
> https://wiki.openstack.org/wiki/OSSN/OSSN-0012
>
>
>
> *From:* Hao Wang [mailto:hao.1.wang at gmail.com]
> *Sent:* 29 April 2014 15:26
> *To:* Clark, Robert Graham
> *Cc:* openstack-security at lists.openstack.org; openstack; Aaron Knister
>
> *Subject:* Re: [Openstack-security] [Openstack] API Security
>
>
>
> Thanks. It makes sense. The other questions are, would Heartbleed be a
> potential risk? Which solution is being used in OpenStack SSL?
>
>
>
> On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham <
> robert.clark at hp.com> wrote:
>
> This is why any production API servers should all be running TLS/SSL – to
> protect the confidentiality of messages in flight.
>
>
>
> There have been efforts to remove sensitive information from logs, I’m a
> little surprised that passwords are logged in Neutron.
>
>
>
> *From:* Hao Wang [mailto:hao.1.wang at gmail.com]
> *Sent:* 29 April 2014 14:06
> *To:* openstack-security at lists.openstack.org
> *Cc:* openstack; Aaron Knister
> *Subject:* Re: [Openstack-security] [Openstack] API Security
>
>
>
> Adding security group...
>
>
>
> On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com> wrote:
>
> It is the client. I got this message with DEBUG enabled:
>
> curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
> "Content-Type: application/json" -H "Accept: application/json" -H
> "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin",
> "passwordCredentials": {"username": "admin", "password": "admin"}}}'
>
>
>
> It can be seen that username and password are right in the message.
>
>
>
> Hao
>
>
>
> On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister <aaron.knister at gmail.com>
> wrote:
>
> Was it the client or the server that exposed the credentials?
>
> Sent from my iPhone
>
>
> On Apr 26, 2014, at 2:28 PM, Hao Wang <hao.1.wang at gmail.com> wrote:
>
> Hi,
>
>
>
> I am troubleshooting a neutron case. It was just found that if DEBUG was
> enabled, neutron would print out JSON data with username and password. I am
> wondering what kind of protocol is used in production environment to
> prevent this security risk from happening.
>
>
>
> Thanks,
>
> Hao
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140429/85417fc7/attachment.html>

From hao.1.wang at gmail.com  Tue Apr 29 15:03:33 2014
From: hao.1.wang at gmail.com (Hao Wang)
Date: Tue, 29 Apr 2014 11:03:33 -0400
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <535FB98F.9050208@redhat.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>
 <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>
 <535FB98F.9050208@redhat.com>
Message-ID: <CAAq+zWEOx-4OwDkrPTT8zN6uZpHwPEiFiK68Xs5eQHPO7oGd-A@mail.gmail.com>

SSL terminator will terminates at the network boundary. I am thinking if
the crackers can figure out a way to sneak into the internal network and
capture all the sensitive information still. Is this a concern for a
private cloud?


On Tue, Apr 29, 2014 at 10:39 AM, Rob Crittenden <rcritten at redhat.com>wrote:

> Hao Wang wrote:
>
>> Thanks. It makes sense. The other questions are, would Heartbleed be a
>> potential risk? Which solution is being used in OpenStack SSL?
>>
>
> Native SSL services (eventlet) are based on OpenSSL, as is Apache
> (horizon) so yes, the risk is there if you haven't updated your OpenSSL
> libraries.
>
> The general consensus however is to use SSL terminators rather than
> enabling SSL in the endpoints directly. You'd need to investigate the SSL
> library in the terminator you choose, though it would likely be OpenSSL.
>
> Check this out as well, https://blog-nkinder.rhcloud.com/?p=7
>
> rob
>
>
>>
>> On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham
>> <robert.clark at hp.com <mailto:robert.clark at hp.com>> wrote:
>>
>>     This is why any production API servers should all be running TLS/SSL
>>     – to protect the confidentiality of messages in flight.____
>>
>>     __ __
>>
>>
>>     There have been efforts to remove sensitive information from logs,
>>     I’m a little surprised that passwords are logged in Neutron.____
>>
>>     __ __
>>
>>     *From:*Hao Wang [mailto:hao.1.wang at gmail.com
>>     <mailto:hao.1.wang at gmail.com>]
>>     *Sent:* 29 April 2014 14:06
>>     *To:* openstack-security at lists.openstack.org
>>     <mailto:openstack-security at lists.openstack.org>
>>     *Cc:* openstack; Aaron Knister
>>     *Subject:* Re: [Openstack-security] [Openstack] API Security____
>>
>>     __ __
>>
>>     Adding security group...____
>>
>>     __ __
>>
>>
>>     On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com
>>     <mailto:hao.1.wang at gmail.com>> wrote:____
>>
>>         It is the client. I got this message with DEBUG enabled:____
>>
>>
>>         curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
>>         "Content-Type: application/json" -H "Accept: application/json"
>>         -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName":
>>         "admin", "passwordCredentials": {"username": "admin",
>>         "password": "admin"}}}'____
>>
>>         __ __
>>
>>
>>         It can be seen that username and password are right in the
>>         message.____
>>
>>         __ __
>>
>>         Hao____
>>
>>         __ __
>>
>>
>>         On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister
>>         <aaron.knister at gmail.com <mailto:aaron.knister at gmail.com>>
>>         wrote:____
>>
>>
>>             Was it the client or the server that exposed the credentials?
>>
>>             Sent from my iPhone____
>>
>>
>>
>>             On Apr 26, 2014, at 2:28 PM, Hao Wang <hao.1.wang at gmail.com
>>             <mailto:hao.1.wang at gmail.com>> wrote:____
>>
>>                 Hi,____
>>
>>                 __ __
>>
>>
>>                 I am troubleshooting a neutron case. It was just found
>>                 that if DEBUG was enabled, neutron would print out JSON
>>                 data with username and password. I am wondering what
>>                 kind of protocol is used in production environment to
>>                 prevent this security risk from happening.____
>>
>>                 __ __
>>
>>                 Thanks,____
>>
>>                 Hao____
>>
>>
>>                 _______________________________________________
>>                 Mailing list:
>>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack
>>                 Post to     : openstack at lists.openstack.org
>>                 <mailto:openstack at lists.openstack.org>
>>                 Unsubscribe :
>>                 http://lists.openstack.org/cgi-bin/mailman/listinfo/
>> openstack____
>>
>>         __ __
>>
>>     __ __
>>
>>
>>
>>
>> _______________________________________________
>> 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/20140429/1c052535/attachment.html>

From robert.clark at hp.com  Tue Apr 29 15:15:59 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 29 Apr 2014 15:15:59 +0000
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <CAAq+zWEOx-4OwDkrPTT8zN6uZpHwPEiFiK68Xs5eQHPO7oGd-A@mail.gmail.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>
 <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>
 <535FB98F.9050208@redhat.com>
 <CAAq+zWEOx-4OwDkrPTT8zN6uZpHwPEiFiK68Xs5eQHPO7oGd-A@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A1122E43D3@G4W3300.americas.hpqcorp.net>

You can terminate SSL anywhere, it doesn’t have to be at the boundary necessarily. Many larger deployments will utilize hardware terminators at the network edge and then internally use software based terminators (like Stunnel).

 

There’s a growing effort to use SSL everywhere, I can second Rob Crittenden’s comments – check out Nathan Kinders blog entry on the topic https://blog-nkinder.rhcloud.com/?p=7

 

From: Hao Wang [mailto:hao.1.wang at gmail.com] 
Sent: 29 April 2014 16:04
To: Rob Crittenden
Cc: Clark, Robert Graham; openstack-security at lists.openstack.org; openstack; Aaron Knister
Subject: Re: [Openstack-security] [Openstack] API Security

 

SSL terminator will terminates at the network boundary. I am thinking if the crackers can figure out a way to sneak into the internal network and capture all the sensitive information still. Is this a concern for a private cloud?

 

On Tue, Apr 29, 2014 at 10:39 AM, Rob Crittenden <rcritten at redhat.com <mailto:rcritten at redhat.com> > wrote:

Hao Wang wrote:

Thanks. It makes sense. The other questions are, would Heartbleed be a
potential risk? Which solution is being used in OpenStack SSL?

 

Native SSL services (eventlet) are based on OpenSSL, as is Apache (horizon) so yes, the risk is there if you haven't updated your OpenSSL libraries.

The general consensus however is to use SSL terminators rather than enabling SSL in the endpoints directly. You'd need to investigate the SSL library in the terminator you choose, though it would likely be OpenSSL.

Check this out as well, https://blog-nkinder.rhcloud.com/?p=7

rob



On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham

<robert.clark at hp.com <mailto:robert.clark at hp.com>  <mailto:robert.clark at hp.com <mailto:robert.clark at hp.com> >> wrote:

    This is why any production API servers should all be running TLS/SSL

    – to protect the confidentiality of messages in flight.____

    __ __



    There have been efforts to remove sensitive information from logs,

    I’m a little surprised that passwords are logged in Neutron.____

    __ __

    *From:*Hao Wang [mailto:hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> 
    <mailto:hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> >]
    *Sent:* 29 April 2014 14:06
    *To:* openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> 
    <mailto:openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> >
    *Cc:* openstack; Aaron Knister
    *Subject:* Re: [Openstack-security] [Openstack] API Security____

    __ __

    Adding security group...____

    __ __



    On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> 

    <mailto:hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> >> wrote:____

        It is the client. I got this message with DEBUG enabled:____



        curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
        "Content-Type: application/json" -H "Accept: application/json"
        -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName":
        "admin", "passwordCredentials": {"username": "admin",

        "password": "admin"}}}'____

        __ __



        It can be seen that username and password are right in the

        message.____

        __ __

        Hao____

        __ __



        On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister

        <aaron.knister at gmail.com <mailto:aaron.knister at gmail.com>  <mailto:aaron.knister at gmail.com <mailto:aaron.knister at gmail.com> >>
        wrote:____



            Was it the client or the server that exposed the credentials?

            Sent from my iPhone____




            On Apr 26, 2014, at 2:28 PM, Hao Wang <hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> 

            <mailto:hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com> >> wrote:____

                Hi,____

                __ __



                I am troubleshooting a neutron case. It was just found
                that if DEBUG was enabled, neutron would print out JSON
                data with username and password. I am wondering what
                kind of protocol is used in production environment to

                prevent this security risk from happening.____

                __ __

                Thanks,____

                Hao____



                _______________________________________________
                Mailing list:
                http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
                Post to     : openstack at lists.openstack.org <mailto:openstack at lists.openstack.org> 

                <mailto:openstack at lists.openstack.org <mailto:openstack at lists.openstack.org> >
                Unsubscribe :
                http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack____

        __ __

    __ __




_______________________________________________
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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140429/e2e44718/attachment.html>
-------------- 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/20140429/e2e44718/attachment.bin>

From nkinder at redhat.com  Tue Apr 29 15:10:01 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Tue, 29 Apr 2014 08:10:01 -0700
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <CAAq+zWEOx-4OwDkrPTT8zN6uZpHwPEiFiK68Xs5eQHPO7oGd-A@mail.gmail.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A1122E42D0@G4W3300.americas.hpqcorp.net>
 <CAAq+zWHY9_ZUZViiXVuyVLG2ceu9GwRAZOpsdpLpQdjMzhv96A@mail.gmail.com>
 <535FB98F.9050208@redhat.com>
 <CAAq+zWEOx-4OwDkrPTT8zN6uZpHwPEiFiK68Xs5eQHPO7oGd-A@mail.gmail.com>
Message-ID: <535FC0C9.3070505@redhat.com>



On 04/29/2014 08:03 AM, Hao Wang wrote:
> SSL terminator will terminates at the network boundary. I am thinking if
> the crackers can figure out a way to sneak into the internal network and
> capture all the sensitive information still. Is this a concern for a
> private cloud?

Yes, it's definitely still a concern.  If you read the blog post that
Rob mentioned, it's talking about setting up a SSL/TLS terminator on the
same physical system as the API endpoints to prevent traffic from being
sent over the network in the clear.  You might also have SSL/TLS
termination at the network boundary for load-balancing purposes, then a
re-encryption to protect traffic on the internal networks.

-NGK

> 
> 
> On Tue, Apr 29, 2014 at 10:39 AM, Rob Crittenden <rcritten at redhat.com
> <mailto:rcritten at redhat.com>> wrote:
> 
>     Hao Wang wrote:
> 
>         Thanks. It makes sense. The other questions are, would
>         Heartbleed be a
>         potential risk? Which solution is being used in OpenStack SSL?
> 
> 
>     Native SSL services (eventlet) are based on OpenSSL, as is Apache
>     (horizon) so yes, the risk is there if you haven't updated your
>     OpenSSL libraries.
> 
>     The general consensus however is to use SSL terminators rather than
>     enabling SSL in the endpoints directly. You'd need to investigate
>     the SSL library in the terminator you choose, though it would likely
>     be OpenSSL.
> 
>     Check this out as well, https://blog-nkinder.rhcloud.__com/?p=7
>     <https://blog-nkinder.rhcloud.com/?p=7>
> 
>     rob
> 
> 
> 
>         On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham
>         <robert.clark at hp.com <mailto:robert.clark at hp.com>
>         <mailto:robert.clark at hp.com <mailto:robert.clark at hp.com>>> wrote:
> 
>             This is why any production API servers should all be running
>         TLS/SSL
>             – to protect the confidentiality of messages in flight.____
> 
>             __ __
> 
> 
>             There have been efforts to remove sensitive information from
>         logs,
>             I’m a little surprised that passwords are logged in Neutron.____
> 
>             __ __
> 
>             *From:*Hao Wang [mailto:hao.1.wang at gmail.com
>         <mailto:hao.1.wang at gmail.com>
>             <mailto:hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com>>]
>             *Sent:* 29 April 2014 14:06
>             *To:* openstack-security at lists.__openstack.org
>         <mailto:openstack-security at lists.openstack.org>
>             <mailto:openstack-security at __lists.openstack.org
>         <mailto:openstack-security at lists.openstack.org>>
>             *Cc:* openstack; Aaron Knister
>             *Subject:* Re: [Openstack-security] [Openstack] API Security____
> 
>             __ __
> 
>             Adding security group...____
> 
>             __ __
> 
> 
>             On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang
>         <hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com>
>             <mailto:hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com>>>
>         wrote:____
> 
>                 It is the client. I got this message with DEBUG enabled:____
> 
> 
>                 curl -i 'http://192.168.56.103:35357/__v2.0/tokens
>         <http://192.168.56.103:35357/v2.0/tokens>' -X POST -H
>                 "Content-Type: application/json" -H "Accept:
>         application/json"
>                 -H "User-Agent: python-novaclient" -d '{"auth":
>         {"tenantName":
>                 "admin", "passwordCredentials": {"username": "admin",
>                 "password": "admin"}}}'____
> 
>                 __ __
> 
> 
>                 It can be seen that username and password are right in the
>                 message.____
> 
>                 __ __
> 
>                 Hao____
> 
>                 __ __
> 
> 
>                 On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister
>                 <aaron.knister at gmail.com
>         <mailto:aaron.knister at gmail.com>
>         <mailto:aaron.knister at gmail.__com <mailto:aaron.knister at gmail.com>>>
>                 wrote:____
> 
> 
>                     Was it the client or the server that exposed the
>         credentials?
> 
>                     Sent from my iPhone____
> 
> 
> 
>                     On Apr 26, 2014, at 2:28 PM, Hao Wang
>         <hao.1.wang at gmail.com <mailto:hao.1.wang at gmail.com>
>                     <mailto:hao.1.wang at gmail.com
>         <mailto:hao.1.wang at gmail.com>>> wrote:____
> 
>                         Hi,____
> 
>                         __ __
> 
> 
>                         I am troubleshooting a neutron case. It was just
>         found
>                         that if DEBUG was enabled, neutron would print
>         out JSON
>                         data with username and password. I am wondering what
>                         kind of protocol is used in production
>         environment to
>                         prevent this security risk from happening.____
> 
>                         __ __
> 
>                         Thanks,____
> 
>                         Hao____
> 
> 
>                         _________________________________________________
>                         Mailing list:
>                        
>         http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack>
>                         Post to     : openstack at lists.openstack.org
>         <mailto:openstack at lists.openstack.org>
>                         <mailto:openstack at lists.__openstack.org
>         <mailto:openstack at lists.openstack.org>>
>                         Unsubscribe :
>                        
>         http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack____
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack____>
> 
>                 __ __
> 
>             __ __
> 
> 
> 
> 
>         _________________________________________________
>         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
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security>
> 
> 
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



From nathanael.i.burton.work at gmail.com  Tue Apr 29 16:28:48 2014
From: nathanael.i.burton.work at gmail.com (Nathanael Burton)
Date: Tue, 29 Apr 2014 12:28:48 -0400
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
Message-ID: <CAM+Mi=u=vmkrG-RihuYp+nc4PRtxrkad4BXmV43xDGe_U2EuSA@mail.gmail.com>

This isn't logging on the service side, this is logging on the client
because the user ran --debug.  This isn't a big security issue other than a
documentation or user educational one.

Natr
On Apr 29, 2014 9:07 AM, "Hao Wang" <hao.1.wang at gmail.com> wrote:

> Adding security group...
>
>
> On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang <hao.1.wang at gmail.com> wrote:
>
>> It is the client. I got this message with DEBUG enabled:
>> curl -i 'http://192.168.56.103:35357/v2.0/tokens' -X POST -H
>> "Content-Type: application/json" -H "Accept: application/json" -H
>> "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "admin",
>> "passwordCredentials": {"username": "admin", "password": "admin"}}}'
>>
>> It can be seen that username and password are right in the message.
>>
>> Hao
>>
>>
>> On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister <aaron.knister at gmail.com>wrote:
>>
>>> Was it the client or the server that exposed the credentials?
>>>
>>> Sent from my iPhone
>>>
>>> On Apr 26, 2014, at 2:28 PM, Hao Wang <hao.1.wang at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I am troubleshooting a neutron case. It was just found that if DEBUG was
>>> enabled, neutron would print out JSON data with username and password. I am
>>> wondering what kind of protocol is used in production environment to
>>> prevent this security risk from happening.
>>>
>>> Thanks,
>>> Hao
>>>
>>> _______________________________________________
>>> Mailing list:
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to     : openstack at lists.openstack.org
>>> Unsubscribe :
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>
>>>
>>
>
> _______________________________________________
> 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/20140429/b78ae432/attachment.html>

From gerrit2 at review.openstack.org  Tue Apr 29 17:41:44 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 29 Apr 2014 17:41:44 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WfC2K-0005DB-OM@review.openstack.org>


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

Log:
commit 616390f7bcca78adefd385209239c146906d8399
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance. The easiest way to use it is to enable direct_url in Glance, but
    you can set the appropriate config options to avoid needing to enable it.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From fungi at yuggoth.org  Tue Apr 29 18:44:02 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 29 Apr 2014 18:44:02 +0000
Subject: [Openstack-security] [Openstack] API Security
In-Reply-To: <CAM+Mi=u=vmkrG-RihuYp+nc4PRtxrkad4BXmV43xDGe_U2EuSA@mail.gmail.com>
References: <CAAq+zWFgQ+7Xmey_ev12KjW0J5V_XS0OqXNtNcU+XVu07p2taA@mail.gmail.com>
 <8E235CE9-313C-46FD-B435-933B25445557@gmail.com>
 <CAAq+zWHqoyhr6iepDvtM9zHx47g4wQ-pm2dMT2tNmzcuN8KpZw@mail.gmail.com>
 <CAAq+zWFFGv5a9p=7=x-A6Bm=93_iY27o71aNAquzbShKP9Gx_Q@mail.gmail.com>
 <CAM+Mi=u=vmkrG-RihuYp+nc4PRtxrkad4BXmV43xDGe_U2EuSA@mail.gmail.com>
Message-ID: <20140429184401.GH11154@yuggoth.org>

On 2014-04-29 12:28:48 -0400 (-0400), Nathanael Burton wrote:
> This isn't logging on the service side, this is logging on the
> client because the user ran --debug. This isn't a big security
> issue other than a documentation or user educational one.

Agreed. See, for example, the big red (pink?) box at...

http://docs.openstack.org/developer/horizon/topics/deployment.html#logging

...and also the related bug report...

https://launchpad.net/bugs/1004114

-- 
Jeremy Stanley



From sross at redhat.com  Tue Apr 29 20:12:59 2014
From: sross at redhat.com (Solly Ross)
Date: Tue, 29 Apr 2014 16:12:59 -0400 (EDT)
Subject: [Openstack-security] Request for security review on blueprint
In-Reply-To: <1130109906.14429553.1398802345310.JavaMail.zimbra@redhat.com>
Message-ID: <443187001.14429864.1398802379069.JavaMail.zimbra@redhat.com>

Hi Security People,

I was wondering if I could get someone from the security team
to throw in their two cents (or whatever your preferred unit of
currency is) about this Nova blueprint up for review:
https://review.openstack.org/#/c/86422/.  Please leave comments
on the Gerrit page.  Thanks!

Best Regards,
Solly Ross



From gerrit2 at review.openstack.org  Tue Apr 29 20:42:38 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 29 Apr 2014 20:42:38 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WfErO-0007lD-1L@review.openstack.org>


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

Log:
commit 80a6aa918735e13f69f7e1fa95386f81a42bd0a1
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance. The easiest way to use it is to enable direct_url in Glance, but
    you can set the appropriate config options to avoid needing to enable it.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From gerrit2 at review.openstack.org  Tue Apr 29 22:28:21 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 29 Apr 2014 22:28:21 +0000
Subject: [Openstack-security] [openstack/ironic] SecurityImpact review
 request change I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e
Message-ID: <E1WfGVh-0007HG-17@review.openstack.org>


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

Log:
commit ac26164f5553b1cf2d1c977e9845a2293c614997
Author: Josh Gachnang <josh at pcsforeducation.com>
Date:   Wed Mar 19 16:47:38 2014 -0700

    Adding swift temp url support
    
    This patch will allow properly configured Glance servers to return a temporary
    URL for an object hosted on Swift. It will require Glance to use Swift
    as its backend. A temporary URL will let the agent download an image from
    Glance without requiring an auth_token, which gives access more than just
    Glance. The easiest way to use it is to enable direct_url in Glance, but
    you can set the appropriate config options to avoid needing to enable it.
    
    We/I need to add a note in the docs about Swift being a possible dependency
    for Ironic deploys using IPA, along with how to set the Temp URL key.
    
    Swift perfomance concerns will be addressed in this blueprint:
    https://blueprints.launchpad.net/ironic/+spec/improve-swift-agent-downloads
    
    SecurityImpact
    DocImpact
    
    Implements: blueprint swift-temp-urls
    Change-Id: I10e4784eee63e8edc9ba30a9c5004a08aa3a6d8e




From sriram at sriramhere.com  Wed Apr 30 04:27:05 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Tue, 29 Apr 2014 21:27:05 -0700
Subject: [Openstack-security] Fuzzing project in GSOC2014
In-Reply-To: <CAD3A53hnoVEJBFuf7wT5ZtzWmG+u3J7h3J+hj6XyALNixRxp4A@mail.gmail.com>
References: <CAD3A53hnoVEJBFuf7wT5ZtzWmG+u3J7h3J+hj6XyALNixRxp4A@mail.gmail.com>
Message-ID: <CAP6wb7+DZEGxDmNyHpW=MR3vkuFBjA7pQnpHHR59QmToWEE61w@mail.gmail.com>

Mani,

Please subscribe to OSSG mailing list and get acquainted with what OSSG[1]
is and how to contribute[2]. Please also take a look at the proposed blue
print for Fuzzing. Let us rock!

thanks,
-Sriram

[1] https://wiki.openstack.org/wiki/Security
[2] https://wiki.openstack.org/wiki/Security/How_To_Contribute
[3] http://summit.openstack.org/cfp/details/323


On Mon, Apr 28, 2014 at 11:32 PM, MANISHANKER TALUSANI <
shanker.mani0 at gmail.com> wrote:

> Hello everyone,
>
> I am an undergraduate student from India. I have been selected for
> GSOC(Google Summer Of Code) to work on one of the Openstack project[1]
> under the guidance of   Sriram Subramanian. Further details about GSOC
> can be found here [2]. The project idea page is [3] and student proposal
> for the project idea is[4].
>
> [1]
> http://www.google-melange.com/gsoc/project/details/google/gsoc2014/manishanker/5649050225344512
> [2]https://wiki.openstack.org/wiki/GSoC2014
> [3]https://wiki.openstack.org/wiki/GSoC2014/Testing/Fuzz
> [4]https://wiki.openstack.org/wiki/GSoC2014/Student/Manishanker
>
> Regards
> Manishanker Talusani
>
>
> _______________________________________________
> 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/20140429/80aca3fb/attachment.html>

From m.koderer at telekom.de  Wed Apr 30 05:45:23 2014
From: m.koderer at telekom.de (Koderer, Marc)
Date: Wed, 30 Apr 2014 07:45:23 +0200
Subject: [Openstack-security] Fuzzing project in GSOC2014
In-Reply-To: <CAP6wb7+DZEGxDmNyHpW=MR3vkuFBjA7pQnpHHR59QmToWEE61w@mail.gmail.com>
References: <CAD3A53hnoVEJBFuf7wT5ZtzWmG+u3J7h3J+hj6XyALNixRxp4A@mail.gmail.com>,
 <CAP6wb7+DZEGxDmNyHpW=MR3vkuFBjA7pQnpHHR59QmToWEE61w@mail.gmail.com>
Message-ID: <FD9023AAE9C10145BD4DDD6CB11F8D580D49F25899@QEO40075.de.t-online.corp>

Hi Sriram, hi Mani,

great to hear! So my session got approved:

http://sched.co/1tHrVUm

Will you both be around in Atlanta? Otherwise I would suggest to have a Hangout call before the session.
I definitely want to support this and we should combine our efforts.

Please also have a look to this merged patch:

https://review.openstack.org/#/c/73982/

Regards
Marc
________________________________________
From: Sriram Subramanian [sriram at sriramhere.com]
Sent: Wednesday, April 30, 2014 6:27 AM
To: MANISHANKER TALUSANI
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Fuzzing project in GSOC2014

Mani,

Please subscribe to OSSG mailing list and get acquainted with what OSSG[1] is and how to contribute[2]. Please also take a look at the proposed blue print for Fuzzing. Let us rock!

thanks,
-Sriram

[1] https://wiki.openstack.org/wiki/Security
[2] https://wiki.openstack.org/wiki/Security/How_To_Contribute
[3] http://summit.openstack.org/cfp/details/323


On Mon, Apr 28, 2014 at 11:32 PM, MANISHANKER TALUSANI <shanker.mani0 at gmail.com<mailto:shanker.mani0 at gmail.com>> wrote:
Hello everyone,

I am an undergraduate student from India. I have been selected for GSOC(Google Summer Of Code) to work on one of the Openstack project[1] under the guidance of   Sriram Subramanian. Further details about GSOC can be found here [2]. The project idea page is [3] and student proposal for the project idea is[4].

[1]http://www.google-melange.com/gsoc/project/details/google/gsoc2014/manishanker/5649050225344512
[2]https://wiki.openstack.org/wiki/GSoC2014
[3]https://wiki.openstack.org/wiki/GSoC2014/Testing/Fuzz
[4]https://wiki.openstack.org/wiki/GSoC2014/Student/Manishanker

Regards
Manishanker Talusani


_______________________________________________
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




--
Thanks,
-Sriram


From robert.clark at hp.com  Wed Apr 30 07:25:41 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 30 Apr 2014 07:25:41 +0000
Subject: [Openstack-security] Fuzzing project in GSOC2014
In-Reply-To: <FD9023AAE9C10145BD4DDD6CB11F8D580D49F25899@QEO40075.de.t-online.corp>
References: <CAD3A53hnoVEJBFuf7wT5ZtzWmG+u3J7h3J+hj6XyALNixRxp4A@mail.gmail.com>, 
 <CAP6wb7+DZEGxDmNyHpW=MR3vkuFBjA7pQnpHHR59QmToWEE61w@mail.gmail.com>
 <FD9023AAE9C10145BD4DDD6CB11F8D580D49F25899@QEO40075.de.t-online.corp>
Message-ID: <A0C170085C37664D93EE1604364858A1122E68AC@G4W3300.americas.hpqcorp.net>

I'd very much like to meet up with you guys in Atlanta too.

-Rob

> -----Original Message-----
> From: Koderer, Marc [mailto:m.koderer at telekom.de]
> Sent: 30 April 2014 06:45
> To: Sriram Subramanian; MANISHANKER TALUSANI
> Cc: openstack-security at lists.openstack.org
> Subject: Re: [Openstack-security] Fuzzing project in GSOC2014
> 
> Hi Sriram, hi Mani,
> 
> great to hear! So my session got approved:
> 
> http://sched.co/1tHrVUm
> 
> Will you both be around in Atlanta? Otherwise I would suggest to have
a
> Hangout call before the session.
> I definitely want to support this and we should combine our efforts.
> 
> Please also have a look to this merged patch:
> 
> https://review.openstack.org/#/c/73982/
> 
> Regards
> Marc
> ________________________________________
> From: Sriram Subramanian [sriram at sriramhere.com]
> Sent: Wednesday, April 30, 2014 6:27 AM
> To: MANISHANKER TALUSANI
> Cc: openstack-security at lists.openstack.org
> Subject: Re: [Openstack-security] Fuzzing project in GSOC2014
> 
> Mani,
> 
> Please subscribe to OSSG mailing list and get acquainted with what
OSSG[1]
> is and how to contribute[2]. Please also take a look at the proposed
blue
> print for Fuzzing. Let us rock!
> 
> thanks,
> -Sriram
> 
> [1] https://wiki.openstack.org/wiki/Security
> [2] https://wiki.openstack.org/wiki/Security/How_To_Contribute
> [3] http://summit.openstack.org/cfp/details/323
> 
> 
> On Mon, Apr 28, 2014 at 11:32 PM, MANISHANKER TALUSANI
> <shanker.mani0 at gmail.com<mailto:shanker.mani0 at gmail.com>> wrote:
> Hello everyone,
> 
> I am an undergraduate student from India. I have been selected for
> GSOC(Google Summer Of Code) to work on one of the Openstack project[1]
> under the guidance of   Sriram Subramanian. Further details about GSOC
can
> be found here [2]. The project idea page is [3] and student proposal
for the
> project idea is[4].
> 
> [1]http://www.google-
> melange.com/gsoc/project/details/google/gsoc2014/manishanker/564905
> 0225344512
> [2]https://wiki.openstack.org/wiki/GSoC2014
> [3]https://wiki.openstack.org/wiki/GSoC2014/Testing/Fuzz
> [4]https://wiki.openstack.org/wiki/GSoC2014/Student/Manishanker
> 
> Regards
> Manishanker Talusani
> 
> 
> _______________________________________________
> 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
> 
> 
> 
> 
> --
> Thanks,
> -Sriram
> _______________________________________________
> 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/20140430/5000ea51/attachment.bin>

From sriram at sriramhere.com  Wed Apr 30 08:03:51 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Wed, 30 Apr 2014 01:03:51 -0700
Subject: [Openstack-security] Fuzzing project in GSOC2014
In-Reply-To: <A0C170085C37664D93EE1604364858A1122E68AC@G4W3300.americas.hpqcorp.net>
References: <CAD3A53hnoVEJBFuf7wT5ZtzWmG+u3J7h3J+hj6XyALNixRxp4A@mail.gmail.com>
 <CAP6wb7+DZEGxDmNyHpW=MR3vkuFBjA7pQnpHHR59QmToWEE61w@mail.gmail.com>
 <FD9023AAE9C10145BD4DDD6CB11F8D580D49F25899@QEO40075.de.t-online.corp>
 <A0C170085C37664D93EE1604364858A1122E68AC@G4W3300.americas.hpqcorp.net>
Message-ID: <CAP6wb7KP4nCF2DgeatxbCgVeaa8WZLJZq3PUYu7MpK09L0pbZw@mail.gmail.com>

Rob, Mani won't be there, but I will be! Let us meet up. Is there any OSSG
lunch/ meetup planned yet?


On Wed, Apr 30, 2014 at 12:25 AM, Clark, Robert Graham
<robert.clark at hp.com>wrote:

> I'd very much like to meet up with you guys in Atlanta too.
>
> -Rob
>
> > -----Original Message-----
> > From: Koderer, Marc [mailto:m.koderer at telekom.de]
> > Sent: 30 April 2014 06:45
> > To: Sriram Subramanian; MANISHANKER TALUSANI
> > Cc: openstack-security at lists.openstack.org
> > Subject: Re: [Openstack-security] Fuzzing project in GSOC2014
> >
> > Hi Sriram, hi Mani,
> >
> > great to hear! So my session got approved:
> >
> > http://sched.co/1tHrVUm
> >
> > Will you both be around in Atlanta? Otherwise I would suggest to have
> a
> > Hangout call before the session.
> > I definitely want to support this and we should combine our efforts.
> >
> > Please also have a look to this merged patch:
> >
> > https://review.openstack.org/#/c/73982/
> >
> > Regards
> > Marc
> > ________________________________________
> > From: Sriram Subramanian [sriram at sriramhere.com]
> > Sent: Wednesday, April 30, 2014 6:27 AM
> > To: MANISHANKER TALUSANI
> > Cc: openstack-security at lists.openstack.org
> > Subject: Re: [Openstack-security] Fuzzing project in GSOC2014
> >
> > Mani,
> >
> > Please subscribe to OSSG mailing list and get acquainted with what
> OSSG[1]
> > is and how to contribute[2]. Please also take a look at the proposed
> blue
> > print for Fuzzing. Let us rock!
> >
> > thanks,
> > -Sriram
> >
> > [1] https://wiki.openstack.org/wiki/Security
> > [2] https://wiki.openstack.org/wiki/Security/How_To_Contribute
> > [3] http://summit.openstack.org/cfp/details/323
> >
> >
> > On Mon, Apr 28, 2014 at 11:32 PM, MANISHANKER TALUSANI
> > <shanker.mani0 at gmail.com<mailto:shanker.mani0 at gmail.com>> wrote:
> > Hello everyone,
> >
> > I am an undergraduate student from India. I have been selected for
> > GSOC(Google Summer Of Code) to work on one of the Openstack project[1]
> > under the guidance of   Sriram Subramanian. Further details about GSOC
> can
> > be found here [2]. The project idea page is [3] and student proposal
> for the
> > project idea is[4].
> >
> > [1]http://www.google-
> > melange.com/gsoc/project/details/google/gsoc2014/manishanker/564905
> > 0225344512
> > [2]https://wiki.openstack.org/wiki/GSoC2014
> > [3]https://wiki.openstack.org/wiki/GSoC2014/Testing/Fuzz
> > [4]https://wiki.openstack.org/wiki/GSoC2014/Student/Manishanker
> >
> > Regards
> > Manishanker Talusani
> >
> >
> > _______________________________________________
> > 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
> >
> >
> >
> >
> > --
> > Thanks,
> > -Sriram
> > _______________________________________________
> > Openstack-security mailing list
> > Openstack-security at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>



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

From m.koderer at telekom.de  Wed Apr 30 10:06:19 2014
From: m.koderer at telekom.de (Koderer, Marc)
Date: Wed, 30 Apr 2014 12:06:19 +0200
Subject: [Openstack-security] Fuzzing project in GSOC2014
In-Reply-To: <CAP6wb7KP4nCF2DgeatxbCgVeaa8WZLJZq3PUYu7MpK09L0pbZw@mail.gmail.com>
References: <CAD3A53hnoVEJBFuf7wT5ZtzWmG+u3J7h3J+hj6XyALNixRxp4A@mail.gmail.com>
 <CAP6wb7+DZEGxDmNyHpW=MR3vkuFBjA7pQnpHHR59QmToWEE61w@mail.gmail.com>
 <FD9023AAE9C10145BD4DDD6CB11F8D580D49F25899@QEO40075.de.t-online.corp>
 <A0C170085C37664D93EE1604364858A1122E68AC@G4W3300.americas.hpqcorp.net>,
 <CAP6wb7KP4nCF2DgeatxbCgVeaa8WZLJZq3PUYu7MpK09L0pbZw@mail.gmail.com>
Message-ID: <FD9023AAE9C10145BD4DDD6CB11F8D580D49F2589D@QEO40075.de.t-online.corp>

Hi folks,

yep let's have a meet up before Thursday 15th in Atlanta.
Usually QA is doing a meetup one day before Summit starts. We could also combine it.

Regards
Marc
________________________________________
From: Sriram Subramanian [sriram at sriramhere.com]
Sent: Wednesday, April 30, 2014 10:03 AM
To: Clark, Robert Graham
Cc: Koderer, Marc; MANISHANKER TALUSANI; openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Fuzzing project in GSOC2014

Rob, Mani won't be there, but I will be! Let us meet up. Is there any OSSG lunch/ meetup planned yet?


On Wed, Apr 30, 2014 at 12:25 AM, Clark, Robert Graham <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
I'd very much like to meet up with you guys in Atlanta too.

-Rob

> -----Original Message-----
> From: Koderer, Marc [mailto:m.koderer at telekom.de<mailto:m.koderer at telekom.de>]
> Sent: 30 April 2014 06:45
> To: Sriram Subramanian; MANISHANKER TALUSANI
> Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
> Subject: Re: [Openstack-security] Fuzzing project in GSOC2014
>
> Hi Sriram, hi Mani,
>
> great to hear! So my session got approved:
>
> http://sched.co/1tHrVUm
>
> Will you both be around in Atlanta? Otherwise I would suggest to have
a
> Hangout call before the session.
> I definitely want to support this and we should combine our efforts.
>
> Please also have a look to this merged patch:
>
> https://review.openstack.org/#/c/73982/
>
> Regards
> Marc
> ________________________________________
> From: Sriram Subramanian [sriram at sriramhere.com<mailto:sriram at sriramhere.com>]
> Sent: Wednesday, April 30, 2014 6:27 AM
> To: MANISHANKER TALUSANI
> Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>
> Subject: Re: [Openstack-security] Fuzzing project in GSOC2014
>
> Mani,
>
> Please subscribe to OSSG mailing list and get acquainted with what
OSSG[1]
> is and how to contribute[2]. Please also take a look at the proposed
blue
> print for Fuzzing. Let us rock!
>
> thanks,
> -Sriram
>
> [1] https://wiki.openstack.org/wiki/Security
> [2] https://wiki.openstack.org/wiki/Security/How_To_Contribute
> [3] http://summit.openstack.org/cfp/details/323
>
>
> On Mon, Apr 28, 2014 at 11:32 PM, MANISHANKER TALUSANI
> <shanker.mani0 at gmail.com<mailto:shanker.mani0 at gmail.com><mailto:shanker.mani0 at gmail.com<mailto:shanker.mani0 at gmail.com>>> wrote:
> Hello everyone,
>
> I am an undergraduate student from India. I have been selected for
> GSOC(Google Summer Of Code) to work on one of the Openstack project[1]
> under the guidance of   Sriram Subramanian. Further details about GSOC
can
> be found here [2]. The project idea page is [3] and student proposal
for the
> project idea is[4].
>
> [1]http://www.google-
> melange.com/gsoc/project/details/google/gsoc2014/manishanker/564905<http://melange.com/gsoc/project/details/google/gsoc2014/manishanker/564905>
> 0225344512
> [2]https://wiki.openstack.org/wiki/GSoC2014
> [3]https://wiki.openstack.org/wiki/GSoC2014/Testing/Fuzz
> [4]https://wiki.openstack.org/wiki/GSoC2014/Student/Manishanker
>
> Regards
> Manishanker Talusani
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org><mailto:Openstack-<mailto:Openstack->
> security at lists.openstack.org<mailto:security at lists.openstack.org>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
>
>
> --
> Thanks,
> -Sriram
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security



--
Thanks,
-Sriram


From gerrit2 at review.openstack.org  Wed Apr 30 15:11:23 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 30 Apr 2014 15:11:23 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Ibe4a2e57a02c261d85ba6c0d61696f134c54443e
Message-ID: <E1WfWAN-0000H7-VY@review.openstack.org>


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

Log:
commit fd02a9c3d03dde51e7ec808552256dea7fef865c
Author: Matthieu Huin <mhu at enovance.com>
Date:   Tue Apr 22 17:14:25 2014 +0200

    More random values for oAuth1 verifier
    
    The oAuth1 verifier was generated as a random number ranging from
    1000 to 9999. This small range of numbers is vulnerable to
    brute-force attacks as described in CWE-330. The verifier is now
    a 8-character long alphanumerical string, a good compromise between
    security against guessing and ease of use.
    
    SecurityImpact
    Change-Id: Ibe4a2e57a02c261d85ba6c0d61696f134c54443e
    Closes-Bug: #1236675