From ishakhat at mirantis.com  Fri Aug  1 08:09:02 2014
From: ishakhat at mirantis.com (Ilya Shakhat)
Date: Fri, 01 Aug 2014 08:09:02 -0000
Subject: [Openstack-security] [Bug 1290486] Re: neutron-openvswitch-agent
 does not recreate flows after ovsdb-server restarts
References: <20140310180245.8017.61086.malonedeb@soybean.canonical.com>
Message-ID: <20140801080902.12438.79217.malone@chaenomeles.canonical.com>

The issue that Roman complains about is tracked as bug
https://bugs.launchpad.net/tripleo/+bug/1292105 and resolved by patch
https://review.openstack.org/#/c/101447/

** Changed in: neutron
       Status: Incomplete => 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/1290486

Title:
  neutron-openvswitch-agent does not recreate flows after ovsdb-server
  restarts

Status in OpenStack Neutron (virtual network service):
  Fix Committed
Status in neutron icehouse series:
  Fix Released
Status in tripleo - openstack on openstack:
  Fix Released

Bug description:
  The DHCP requests were not being responded to after they were seen on
  the undercloud network interface.  The neutron services were restarted
  in an attempt to ensure they had the newest configuration and knew
  they were supposed to respond to the requests.

  Rather than using the heat stack create (called in
  devtest_overcloud.sh) to test, it was simple to use the following to
  directly boot a baremetal node.

      nova boot --flavor $(nova flavor-list | grep "|[[:space:]]*baremetal[[:space:]]*|" | awk '{print $2}) \
            --image $(nova image-list | grep "|[[:space:]]*overcloud-control[[:space:]]*|" | awk '{print $2}') \
            bm-test1

  Whilst the baremetal node was attempting to pxe boot a restart of the
  neutron services was performed.  This allowed the baremetal node to
  boot.

  It has been observed that a neutron restart was needed for each
  subsequent reboot of the baremetal nodes to succeed.

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



From Travis_McPeak at symantec.com  Fri Aug  1 16:37:16 2014
From: Travis_McPeak at symantec.com (Travis McPeak)
Date: Fri, 1 Aug 2014 09:37:16 -0700
Subject: [Openstack-security] OSSG Meet up and Progress
Message-ID: <D0010F89.4A50%travis_mcpeak@symantec.com>

I¹m amazed at what it¹s possible to accomplish in four days with a group
of smart people, who are passionate about security, working together.  It
was a real pleasure meeting those of you that were able to attend, and for
those that weren¹t, I hope to have the opportunity to meet you soon!

Thanks,
 -Travis




From gerrit2 at review.openstack.org  Fri Aug  1 17:31:21 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 01 Aug 2014 17:31:21 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Ie1a0c286ff7e513cd964d4a93855230c78b98c6c
Message-ID: <E1XDGfp-0004EA-9X@review.openstack.org>


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

Log:
commit 23b2c8476051eacf3c4f08fbe32667886c7aa234
Author: Nathan Kinder <nkinder at redhat.com>
Date:   Wed Jul 23 12:06:22 2014 -0700

    Trust unit tests should target additional threat scenarios
    
    This adds unit tests for two threat scenarios around the trust functionality
    that are not currently tested.
    
    The first scenario is related to deletion of a grant that has been previously
    delegated via a trust. We need to ensure that executing a trust for a role that
    the trustor no longer has is rejected.
    
    The second scenario is related to an attempt to use a trust token with
    impersonation to execute another trust as the impersonated user. We need to
    ensure that a trust token can't be used to execute another trust.
    
    SecurityImpact
    Closes-Bug: #1347909
    Change-Id: Ie1a0c286ff7e513cd964d4a93855230c78b98c6c




From michael.xin at RACKSPACE.COM  Fri Aug  1 18:57:03 2014
From: michael.xin at RACKSPACE.COM (Michael Xin)
Date: Fri, 1 Aug 2014 18:57:03 +0000
Subject: [Openstack-security] The wiki page with all submitted talks
Message-ID: <D0014C6F.280FC%michael.xin@rackspace.com>

hi, guys:
Here is the wiki page with all submitted talks for Paris Summit:
https://wiki.openstack.org/wiki/Security/Talks


Thanks and have a great day.

Yours,
Michael

-----------------------------------------------------------------------------
Michael Xin | Manager, Security Engineering - US
Product Security  |Rackspace Hosting
Office #: 501-7341   or  210-312-7341
Mobile #: 210-284-8674
5000 Walzem Road, San Antonio, Tx 78218
----------------------------------------------------------------------------
Experience fanatical support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140801/95c083be/attachment.html>

From nkinder at redhat.com  Fri Aug  1 22:16:18 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Fri, 01 Aug 2014 15:16:18 -0700
Subject: [Openstack-security] The wiki page with all submitted talks
In-Reply-To: <D0014C6F.280FC%michael.xin@rackspace.com>
References: <D0014C6F.280FC%michael.xin@rackspace.com>
Message-ID: <53DC11B2.7000309@redhat.com>



On 08/01/2014 11:57 AM, Michael Xin wrote:
> hi, guys:
> Here is the wiki page with all submitted talks for Paris Summit:
> https://wiki.openstack.org/wiki/Security/Talks

Thanks for putting this together Michael!  I've added my proposed talk
to the list as well.

-NGK

> 
> 
> Thanks and have a great day. 
> 
> Yours,
> Michael 
> 
> -----------------------------------------------------------------------------
> Michael Xin | Manager, Security Engineering - US 
> Product Security  |Rackspace Hosting
> Office #: 501-7341   or  210-312-7341
> Mobile #: 210-284-8674 
> 5000 Walzem Road, San Antonio, Tx 78218
> ----------------------------------------------------------------------------
> Experience fanatical support
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



From Priti_Desai at symantec.com  Sat Aug  2 17:59:59 2014
From: Priti_Desai at symantec.com (Priti Desai)
Date: Sat, 2 Aug 2014 10:59:59 -0700
Subject: [Openstack-security] The wiki page with all submitted talks
In-Reply-To: <53DC11B2.7000309@redhat.com>
References: <D0014C6F.280FC%michael.xin@rackspace.com>
 <53DC11B2.7000309@redhat.com>
Message-ID: <D00274F2.350CD%priti_desai@symantec.com>

Thanks Guys. I have added two of my talks as well.

Cheers
Priti

On 8/1/14 3:16 PM, "Nathan Kinder" <nkinder at redhat.com> wrote:

>
>
>On 08/01/2014 11:57 AM, Michael Xin wrote:
>> hi, guys:
>> Here is the wiki page with all submitted talks for Paris Summit:
>> https://wiki.openstack.org/wiki/Security/Talks
>
>Thanks for putting this together Michael!  I've added my proposed talk
>to the list as well.
>
>-NGK
>
>> 
>> 
>> Thanks and have a great day.
>> 
>> Yours,
>> Michael 
>> 
>> 
>>-------------------------------------------------------------------------
>>----
>> Michael Xin | Manager, Security Engineering - US
>> Product Security  |Rackspace Hosting
>> Office #: 501-7341   or  210-312-7341
>> Mobile #: 210-284-8674
>> 5000 Walzem Road, San Antonio, Tx 78218
>> 
>>-------------------------------------------------------------------------
>>---
>> Experience fanatical support
>> 
>> 
>> 
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> 
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security




From jason.hullinger at hp.com  Sun Aug  3 18:52:51 2014
From: jason.hullinger at hp.com (Hullinger, Jason (Cloud Services))
Date: Sun, 3 Aug 2014 18:52:51 +0000
Subject: [Openstack-security] The wiki page with all submitted talks
In-Reply-To: <D00274F2.350CD%priti_desai@symantec.com>
References: <D0014C6F.280FC%michael.xin@rackspace.com>
 <53DC11B2.7000309@redhat.com>,<D00274F2.350CD%priti_desai@symantec.com>
Message-ID: <D5705CD6-3827-489B-A9BB-36D0D3F75146@hp.com>

Add mine as well.
Best,
Jason

> On Aug 2, 2014, at 11:01 AM, "Priti Desai" <Priti_Desai at symantec.com> wrote:
> 
> Thanks Guys. I have added two of my talks as well.
> 
> Cheers
> Priti
> 
>> On 8/1/14 3:16 PM, "Nathan Kinder" <nkinder at redhat.com> wrote:
>> 
>> 
>> 
>>> On 08/01/2014 11:57 AM, Michael Xin wrote:
>>> hi, guys:
>>> Here is the wiki page with all submitted talks for Paris Summit:
>>> https://wiki.openstack.org/wiki/Security/Talks
>> 
>> Thanks for putting this together Michael!  I've added my proposed talk
>> to the list as well.
>> 
>> -NGK
>> 
>>> 
>>> 
>>> Thanks and have a great day.
>>> 
>>> Yours,
>>> Michael 
>>> 
>>> 
>>> -------------------------------------------------------------------------
>>> ----
>>> Michael Xin | Manager, Security Engineering - US
>>> Product Security  |Rackspace Hosting
>>> Office #: 501-7341   or  210-312-7341
>>> Mobile #: 210-284-8674
>>> 5000 Walzem Road, San Antonio, Tx 78218
>>> 
>>> -------------------------------------------------------------------------
>>> ---
>>> Experience fanatical support
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Openstack-security mailing list
>>> Openstack-security at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> 
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security



From jason.hullinger at hp.com  Sun Aug  3 19:08:59 2014
From: jason.hullinger at hp.com (Hullinger, Jason (Cloud Services))
Date: Sun, 3 Aug 2014 19:08:59 +0000
Subject: [Openstack-security] The wiki page with all submitted talks
In-Reply-To: <D5705CD6-3827-489B-A9BB-36D0D3F75146@hp.com>
References: <D0014C6F.280FC%michael.xin@rackspace.com>
 <53DC11B2.7000309@redhat.com>, <D00274F2.350CD%priti_desai@symantec.com>,
 <D5705CD6-3827-489B-A9BB-36D0D3F75146@hp.com>
Message-ID: <A513347F-89FF-433F-A8F2-52E075417360@hp.com>

Sorry, "added" mine as well :)

Sent from my iPhone

> On Aug 3, 2014, at 11:55 AM, "Hullinger, Jason (Cloud Services)" <jason.hullinger at hp.com> wrote:
> 
> Add mine as well.
> Best,
> Jason
> 
>> On Aug 2, 2014, at 11:01 AM, "Priti Desai" <Priti_Desai at symantec.com> wrote:
>> 
>> Thanks Guys. I have added two of my talks as well.
>> 
>> Cheers
>> Priti
>> 
>>> On 8/1/14 3:16 PM, "Nathan Kinder" <nkinder at redhat.com> wrote:
>>> 
>>> 
>>> 
>>>> On 08/01/2014 11:57 AM, Michael Xin wrote:
>>>> hi, guys:
>>>> Here is the wiki page with all submitted talks for Paris Summit:
>>>> https://wiki.openstack.org/wiki/Security/Talks
>>> 
>>> Thanks for putting this together Michael!  I've added my proposed talk
>>> to the list as well.
>>> 
>>> -NGK
>>> 
>>>> 
>>>> 
>>>> Thanks and have a great day.
>>>> 
>>>> Yours,
>>>> Michael 
>>>> 
>>>> 
>>>> -------------------------------------------------------------------------
>>>> ----
>>>> Michael Xin | Manager, Security Engineering - US
>>>> Product Security  |Rackspace Hosting
>>>> Office #: 501-7341   or  210-312-7341
>>>> Mobile #: 210-284-8674
>>>> 5000 Walzem Road, San Antonio, Tx 78218
>>>> 
>>>> -------------------------------------------------------------------------
>>>> ---
>>>> Experience fanatical support
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Openstack-security mailing list
>>>> Openstack-security at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>> 
>>> _______________________________________________
>>> Openstack-security mailing list
>>> Openstack-security at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> 
>> 
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security



From alawson at aqorn.com  Sun Aug  3 19:59:30 2014
From: alawson at aqorn.com (Adam Lawson)
Date: Sun, 3 Aug 2014 12:59:30 -0700
Subject: [Openstack-security] The wiki page with all submitted talks
In-Reply-To: <A513347F-89FF-433F-A8F2-52E075417360@hp.com>
References: <D0014C6F.280FC%michael.xin@rackspace.com>
 <53DC11B2.7000309@redhat.com>
 <D00274F2.350CD%priti_desai@symantec.com>
 <D5705CD6-3827-489B-A9BB-36D0D3F75146@hp.com>
 <A513347F-89FF-433F-A8F2-52E075417360@hp.com>
Message-ID: <CAJfWK4_0=adt9ZUGyYpFPmY6MLzzeCRfpuwgg5dExJKvCaJDmw@mail.gmail.com>

Added mine re Keystone Federation as well.

Mahalo,
Adam


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Sun, Aug 3, 2014 at 12:08 PM, Hullinger, Jason (Cloud Services) <
jason.hullinger at hp.com> wrote:

> Sorry, "added" mine as well :)
>
> Sent from my iPhone
>
> > On Aug 3, 2014, at 11:55 AM, "Hullinger, Jason (Cloud Services)" <
> jason.hullinger at hp.com> wrote:
> >
> > Add mine as well.
> > Best,
> > Jason
> >
> >> On Aug 2, 2014, at 11:01 AM, "Priti Desai" <Priti_Desai at symantec.com>
> wrote:
> >>
> >> Thanks Guys. I have added two of my talks as well.
> >>
> >> Cheers
> >> Priti
> >>
> >>> On 8/1/14 3:16 PM, "Nathan Kinder" <nkinder at redhat.com> wrote:
> >>>
> >>>
> >>>
> >>>> On 08/01/2014 11:57 AM, Michael Xin wrote:
> >>>> hi, guys:
> >>>> Here is the wiki page with all submitted talks for Paris Summit:
> >>>> https://wiki.openstack.org/wiki/Security/Talks
> >>>
> >>> Thanks for putting this together Michael!  I've added my proposed talk
> >>> to the list as well.
> >>>
> >>> -NGK
> >>>
> >>>>
> >>>>
> >>>> Thanks and have a great day.
> >>>>
> >>>> Yours,
> >>>> Michael
> >>>>
> >>>>
> >>>>
> -------------------------------------------------------------------------
> >>>> ----
> >>>> Michael Xin | Manager, Security Engineering - US
> >>>> Product Security  |Rackspace Hosting
> >>>> Office #: 501-7341   or  210-312-7341
> >>>> Mobile #: 210-284-8674
> >>>> 5000 Walzem Road, San Antonio, Tx 78218
> >>>>
> >>>>
> -------------------------------------------------------------------------
> >>>> ---
> >>>> Experience fanatical support
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Openstack-security mailing list
> >>>> Openstack-security at lists.openstack.org
> >>>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> >>>
> >>> _______________________________________________
> >>> Openstack-security mailing list
> >>> Openstack-security at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> >>
> >>
> >> _______________________________________________
> >> Openstack-security mailing list
> >> Openstack-security at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> >
> > _______________________________________________
> > Openstack-security mailing list
> > Openstack-security at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140803/44f1f75a/attachment.html>

From alawson at aqorn.com  Sun Aug  3 20:04:25 2014
From: alawson at aqorn.com (Adam Lawson)
Date: Sun, 3 Aug 2014 13:04:25 -0700
Subject: [Openstack-security] The wiki page with all submitted talks
In-Reply-To: <CAJfWK4_0=adt9ZUGyYpFPmY6MLzzeCRfpuwgg5dExJKvCaJDmw@mail.gmail.com>
References: <D0014C6F.280FC%michael.xin@rackspace.com>
 <53DC11B2.7000309@redhat.com>
 <D00274F2.350CD%priti_desai@symantec.com>
 <D5705CD6-3827-489B-A9BB-36D0D3F75146@hp.com>
 <A513347F-89FF-433F-A8F2-52E075417360@hp.com>
 <CAJfWK4_0=adt9ZUGyYpFPmY6MLzzeCRfpuwgg5dExJKvCaJDmw@mail.gmail.com>
Message-ID: <CAJfWK49BQM93KJzzQXjZZRhM63mjTn6pL9B+9QKkij1NwKZogQ@mail.gmail.com>

Incidentally, OSSG has some of the best proposals. I voted for you all ; )


*Adam Lawson*
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Sun, Aug 3, 2014 at 12:59 PM, Adam Lawson <alawson at aqorn.com> wrote:

> Added mine re Keystone Federation as well.
>
> Mahalo,
> Adam
>
>
> *Adam Lawson*
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
>
>
> On Sun, Aug 3, 2014 at 12:08 PM, Hullinger, Jason (Cloud Services) <
> jason.hullinger at hp.com> wrote:
>
>> Sorry, "added" mine as well :)
>>
>> Sent from my iPhone
>>
>> > On Aug 3, 2014, at 11:55 AM, "Hullinger, Jason (Cloud Services)" <
>> jason.hullinger at hp.com> wrote:
>> >
>> > Add mine as well.
>> > Best,
>> > Jason
>> >
>> >> On Aug 2, 2014, at 11:01 AM, "Priti Desai" <Priti_Desai at symantec.com>
>> wrote:
>> >>
>> >> Thanks Guys. I have added two of my talks as well.
>> >>
>> >> Cheers
>> >> Priti
>> >>
>> >>> On 8/1/14 3:16 PM, "Nathan Kinder" <nkinder at redhat.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>>> On 08/01/2014 11:57 AM, Michael Xin wrote:
>> >>>> hi, guys:
>> >>>> Here is the wiki page with all submitted talks for Paris Summit:
>> >>>> https://wiki.openstack.org/wiki/Security/Talks
>> >>>
>> >>> Thanks for putting this together Michael!  I've added my proposed talk
>> >>> to the list as well.
>> >>>
>> >>> -NGK
>> >>>
>> >>>>
>> >>>>
>> >>>> Thanks and have a great day.
>> >>>>
>> >>>> Yours,
>> >>>> Michael
>> >>>>
>> >>>>
>> >>>>
>> -------------------------------------------------------------------------
>> >>>> ----
>> >>>> Michael Xin | Manager, Security Engineering - US
>> >>>> Product Security  |Rackspace Hosting
>> >>>> Office #: 501-7341   or  210-312-7341
>> >>>> Mobile #: 210-284-8674
>> >>>> 5000 Walzem Road, San Antonio, Tx 78218
>> >>>>
>> >>>>
>> -------------------------------------------------------------------------
>> >>>> ---
>> >>>> Experience fanatical support
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Openstack-security mailing list
>> >>>> Openstack-security at lists.openstack.org
>> >>>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> >>>
>> >>> _______________________________________________
>> >>> Openstack-security mailing list
>> >>> Openstack-security at lists.openstack.org
>> >>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> >>
>> >>
>> >> _______________________________________________
>> >> Openstack-security mailing list
>> >> Openstack-security at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> >
>> > _______________________________________________
>> > Openstack-security mailing list
>> > Openstack-security at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140803/77b2301b/attachment.html>

From 1004114 at bugs.launchpad.net  Mon Aug  4 06:53:20 2014
From: 1004114 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 04 Aug 2014 06:53:20 -0000
Subject: [Openstack-security] [Bug 1004114] Re: Password logging
References: <20120524190215.26515.18198.malonedeb@gac.canonical.com>
Message-ID: <20140804065320.7623.78374.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/110117
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=605577192d7158ecf40bd9a94b7cf3acc2ce1c95
Submitter: Jenkins
Branch:    master

commit 605577192d7158ecf40bd9a94b7cf3acc2ce1c95
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Mon Jul 28 14:34:53 2014 -0500

    Redact tokens in request headers
    
    Tokens shouldn't be logged since a token could be gathered from a
    log file and used. The client was logging the X-Auth-Token and
    X-Subject-Token request headers. With this change, the X-Auth-Token
    and X-Subject-Token are shown as "TOKEN_REDACTED".
    
    Also, the "Authentication" header is also redacted.
    
    This is for security hardening.
    
    SecurityImpact
    
    Closes-Bug: #1004114
    Closes-Bug: #1327019
    
    Change-Id: I1edc3821ed028471102cc9b95eb9f3b54c9e2778


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

Title:
  Password logging

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Security Notes:
  New
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  When the log level is set to DEBUG, keystoneclient's full-request
  logging mechanism kicks in, exposing plaintext passwords, etc.

  This bug is mostly out of the scope of Horizon, however Horizon can
  also be more secure in this regard. We should make sure that wherever
  we *are* handling sensitive data we use Django's error report
  filtering mechanisms so they don't appear in tracebacks, etc.
  (https://docs.djangoproject.com/en/dev/howto/error-reporting
  /#filtering-error-reports)

  Keystone may also want to look at respecting such annotations in their
  logging mechanism, i.e. if Django were properly annotating these data
  objects, keystoneclient could check for those annotations and properly
  sanitize the log output.

  If not this exact mechanism, then something similar would be wise.

  For the time being, it's also worth documenting in both projects that
  a log level of DEBUG will log passwords in plain text.

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



From thierry.carrez+lp at gmail.com  Mon Aug  4 14:41:32 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 04 Aug 2014 14:41:32 -0000
Subject: [Openstack-security] [Bug 1348416] Re: Popen with shell=True
References: <20140724231826.32391.31334.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140804144134.23480.82987.launchpad@wampee.canonical.com>

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Information type changed from Private Security to Public

** Tags added: security

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

Title:
  Popen with shell=True

Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  Glance uses subprocess.Popen with shell=True in
  glance/tests/unit/test_migrations.py line 175 in function
  _reset_datases:

          def execute_cmd(cmd=None):
              proc = subprocess.Popen(cmd, stdout=subprocess.PIPE,
                                      stderr=subprocess.STDOUT, shell=True)

  If execute_cmd contains, either accidentally or maliciously, a double
  quote then arbitrary data will be executed. Popen should be called
  with an argument list instead of directly through the shell. For more
  information on subprocess, shell=True and command injection see:
  https://docs.python.org/2/library/subprocess.html#frequently-used-
  arguments

  Since these are unit tests and the likelihood of malicious input is
  low the severity should also be low.

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



From thierry.carrez+lp at gmail.com  Mon Aug  4 14:46:33 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 04 Aug 2014 14:46:33 -0000
Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup
	strategies
References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com>
Message-ID: <20140804144633.26514.49538.malone@gac.canonical.com>

@Robert: sounds good.

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Information type changed from Private Security to Public

** Tags added: security

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

Title:
  Shell Injection in backup strategies

Status in OpenStack Security Advisories:
  Won't Fix
Status in Openstack Database (Trove):
  New

Bug description:
  Trove uses subprocess.Popen with shell=True in
  trove/trove/guestagent/strategies/backup/base.py line 61:

      def run(self):
          self.process = subprocess.Popen(self.command, shell=True,
                                          stdout=subprocess.PIPE,
                                          stderr=subprocess.PIPE,
                                          preexec_fn=os.setsid)
          self.pid = self.process.pid

  This could be used, maliciously or not, to inject arbitrary commands
  into a command line string. An example of this could be triggered is
  in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It
  is creating a MySQL string with single quote. If the password, either
  maliciously or just happens to contain another single quote, it will
  escape from the command and arbitrary data will be executed instead.

  For more information on subprocess, shell=True and command injection
  see: https://docs.python.org/2/library/subprocess.html#frequently-
  used-arguments

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



From michael.xin at RACKSPACE.COM  Mon Aug  4 15:57:44 2014
From: michael.xin at RACKSPACE.COM (Michael Xin)
Date: Mon, 4 Aug 2014 15:57:44 +0000
Subject: [Openstack-security] The wiki page with all submitted talks
In-Reply-To: <CAJfWK49BQM93KJzzQXjZZRhM63mjTn6pL9B+9QKkij1NwKZogQ@mail.gmail.com>
References: <D0014C6F.280FC%michael.xin@rackspace.com>
 <53DC11B2.7000309@redhat.com> <D00274F2.350CD%priti_desai@symantec.com>
 <D5705CD6-3827-489B-A9BB-36D0D3F75146@hp.com>
 <A513347F-89FF-433F-A8F2-52E075417360@hp.com>
 <CAJfWK4_0=adt9ZUGyYpFPmY6MLzzeCRfpuwgg5dExJKvCaJDmw@mail.gmail.com>
 <CAJfWK49BQM93KJzzQXjZZRhM63mjTn6pL9B+9QKkij1NwKZogQ@mail.gmail.com>
Message-ID: <D005179F.28417%michael.xin@rackspace.com>

Adam:
Thanks for your votes.  :-)

Thanks and have a great day.

Yours,
Michael

-----------------------------------------------------------------------------
Michael Xin | Manager, Security Engineering - US
Product Security  |Rackspace Hosting
Office #: 501-7341   or  210-312-7341
Mobile #: 210-284-8674
5000 Walzem Road, San Antonio, Tx 78218
----------------------------------------------------------------------------
Experience fanatical support


From: Adam Lawson <alawson at aqorn.com<mailto:alawson at aqorn.com>>
Date: Sunday, August 3, 2014 at 3:04 PM
To: "Hullinger, Jason (Cloud Services)" <jason.hullinger at hp.com<mailto:jason.hullinger at hp.com>>
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] The wiki page with all submitted talks

Incidentally, OSSG has some of the best proposals. I voted for you all ; )


Adam Lawson
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
[http://www.aqorn.com/images/logo.png]


On Sun, Aug 3, 2014 at 12:59 PM, Adam Lawson <alawson at aqorn.com<mailto:alawson at aqorn.com>> wrote:
Added mine re Keystone Federation as well.

Mahalo,
Adam


Adam Lawson
AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660<tel:%2B1%20302-387-4660>
Direct: +1 916-246-2072<tel:%2B1%20916-246-2072>
[http://www.aqorn.com/images/logo.png]


On Sun, Aug 3, 2014 at 12:08 PM, Hullinger, Jason (Cloud Services) <jason.hullinger at hp.com<mailto:jason.hullinger at hp.com>> wrote:
Sorry, "added" mine as well :)

Sent from my iPhone

> On Aug 3, 2014, at 11:55 AM, "Hullinger, Jason (Cloud Services)" <jason.hullinger at hp.com<mailto:jason.hullinger at hp.com>> wrote:
>
> Add mine as well.
> Best,
> Jason
>
>> On Aug 2, 2014, at 11:01 AM, "Priti Desai" <Priti_Desai at symantec.com<mailto:Priti_Desai at symantec.com>> wrote:
>>
>> Thanks Guys. I have added two of my talks as well.
>>
>> Cheers
>> Priti
>>
>>> On 8/1/14 3:16 PM, "Nathan Kinder" <nkinder at redhat.com<mailto:nkinder at redhat.com>> wrote:
>>>
>>>
>>>
>>>> On 08/01/2014 11:57 AM, Michael Xin wrote:
>>>> hi, guys:
>>>> Here is the wiki page with all submitted talks for Paris Summit:
>>>> https://wiki.openstack.org/wiki/Security/Talks
>>>
>>> Thanks for putting this together Michael!  I've added my proposed talk
>>> to the list as well.
>>>
>>> -NGK
>>>
>>>>
>>>>
>>>> Thanks and have a great day.
>>>>
>>>> Yours,
>>>> Michael
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> ----
>>>> Michael Xin | Manager, Security Engineering - US
>>>> Product Security  |Rackspace Hosting
>>>> Office #: 501-7341   or  210-312-7341<tel:210-312-7341>
>>>> Mobile #: 210-284-8674<tel:210-284-8674>
>>>> 5000 Walzem Road, San Antonio, Tx 78218
>>>>
>>>> -------------------------------------------------------------------------
>>>> ---
>>>> Experience fanatical support
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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

_______________________________________________
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/20140804/580c14cb/attachment.html>

From gmurphy at redhat.com  Tue Aug  5 02:44:56 2014
From: gmurphy at redhat.com (Grant Murphy)
Date: Tue, 5 Aug 2014 12:44:56 +1000
Subject: [Openstack-security] Why are we still seeing XSS flaws?
Message-ID: <20140805024455.GA32168@lappy.bne.redhat.com>

Hi,

I've been trying to put together some historical information about the
security vulnerabilities that we are seeing in OpenStack [1]. The one thing
that I've noticed is that we don't seem to be learning from our mistakes.

The particular example that I'd like to call out is XSS.  This is a
very well known problem with a simple solution. Most template
frameworks when used correctly will automatically escape input unless
autoescape is explicitly disabled. So why are we still seeing this class of
bug turn up in 2014?

I'd like to propose that the OSSG does a review of horizon's current
strategy for mitigating this type of flaw and find a better way forward
for future releases. Is anybody able to help out with this?

[1] http://openstack-security.info  (#wip)

--
Grant

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140805/d39b0e9c/attachment.sig>

From matt at nycresistor.com  Tue Aug  5 05:42:44 2014
From: matt at nycresistor.com (matt)
Date: Tue, 5 Aug 2014 01:42:44 -0400
Subject: [Openstack-security] Why are we still seeing XSS flaws?
In-Reply-To: <20140805024455.GA32168@lappy.bne.redhat.com>
References: <20140805024455.GA32168@lappy.bne.redhat.com>
Message-ID: <CAP_sDUFTGCFwoKz+GZSd6P53LTAN=bET81jt2HPCZQ9RE6XX2g@mail.gmail.com>

XSS is hard to test for automatically due to logically flows in the
application not being easily discoverable.  Also it kind of requires
functional testing.

But if you can write the test infra would probably merge the code.


On Mon, Aug 4, 2014 at 10:44 PM, Grant Murphy <gmurphy at redhat.com> wrote:

> Hi,
>
> I've been trying to put together some historical information about the
> security vulnerabilities that we are seeing in OpenStack [1]. The one thing
> that I've noticed is that we don't seem to be learning from our mistakes.
>
> The particular example that I'd like to call out is XSS.  This is a
> very well known problem with a simple solution. Most template
> frameworks when used correctly will automatically escape input unless
> autoescape is explicitly disabled. So why are we still seeing this class of
> bug turn up in 2014?
>
> I'd like to propose that the OSSG does a review of horizon's current
> strategy for mitigating this type of flaw and find a better way forward
> for future releases. Is anybody able to help out with this?
>
> [1] http://openstack-security.info  (#wip)
>
> --
> Grant
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140805/a8479e82/attachment.html>

From 1319943 at bugs.launchpad.net  Tue Aug  5 07:24:59 2014
From: 1319943 at bugs.launchpad.net (Alan Pevec)
Date: Tue, 05 Aug 2014 07:24:59 -0000
Subject: [Openstack-security] [Bug 1319943] Re: libvirt driver's to_xml
 method logs iscsi auth_password if debug
References: <20140515172919.15967.70050.malonedeb@gac.canonical.com>
Message-ID: <20140805072500.21699.65189.launchpad@soybean.canonical.com>

** Also affects: nova/icehouse
   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/1319943

Title:
  libvirt driver's to_xml method logs iscsi auth_password if debug

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) icehouse series:
  New

Bug description:
  If you have debug logging enabled the libvirt driver's to_xml method
  logs the iscsi auth_password in plain text.

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



From michael_steffens at posteo.de  Mon Aug  4 06:38:22 2014
From: michael_steffens at posteo.de (Michael Steffens)
Date: Mon, 04 Aug 2014 06:38:22 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140804063823.7308.4142.launchpad@chaenomeles.canonical.com>

** Tags added: compute

** Tags added: libvirt 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/1350766

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

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



From michael_steffens at posteo.de  Mon Aug  4 11:41:00 2014
From: michael_steffens at posteo.de (Michael Steffens)
Date: Mon, 04 Aug 2014 11:41:00 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140804114101.26128.61841.launchpad@gac.canonical.com>

** Description changed:

  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/
  
  Reason: When first instantiating a QCOW2 image, it's
  
  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img
  
  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not guarantee
  the resulting data to be written to disk on file close. Consequently,
  the source image file may not be written completely when qemu-img sub-
  process starts reading in step (2). Whether the result is good or bad
  depends on speed of download, file size, and how quickly qemu-image can
  digest its input.
  
  Proposed fix: enforce fsync on output File object before returning from
  download. Patch attached.
+ 
+ Security considerations:
+ 
+  * Due to the race between resources shared between users and tenants
+ (compute node network and filesystem IO) a failure can be triggered
+ across tenants, implying the risk of DoS.
+ 
+  * To make things worse -- with the default setting of not cleaning the
+ image cache -- any corrupted image will remain in cache until replaced
+ with fresh upload using a new image ID. Affected snapshots remain
+ unusable forever, until ex- and re-imported manually under better
+ conditions.
+ 
+  * Base image corruptions here are not detected and cannot be caught.
+ Theoretically (a bit esoteric, quite unlikely, but not impossible), an
+ attacker might modulate resource usage to precisely create an
+ incompletely written image, that boots and runs, but has access control
+ information stripped.

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From 1319943 at bugs.launchpad.net  Tue Aug  5 08:02:32 2014
From: 1319943 at bugs.launchpad.net (Alan Pevec)
Date: Tue, 05 Aug 2014 08:02:32 -0000
Subject: [Openstack-security] [Bug 1319943] Re: libvirt driver's to_xml
 method logs iscsi auth_password if debug
References: <20140515172919.15967.70050.malonedeb@gac.canonical.com>
Message-ID: <20140805080234.7413.61160.launchpad@chaenomeles.canonical.com>

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

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

** Changed in: nova/icehouse
     Assignee: (unassigned) => Yaguang Tang (heut2008)

** Changed in: nova/icehouse
    Milestone: None => 2014.1.2

** Tags removed: 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/1319943

Title:
  libvirt driver's to_xml method logs iscsi auth_password if debug

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) icehouse series:
  In Progress

Bug description:
  If you have debug logging enabled the libvirt driver's to_xml method
  logs the iscsi auth_password in plain text.

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



From 1319943 at bugs.launchpad.net  Tue Aug  5 08:21:53 2014
From: 1319943 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 05 Aug 2014 08:21:53 -0000
Subject: [Openstack-security] [Bug 1319943] Re: libvirt driver's to_xml
 method logs iscsi auth_password if debug
References: <20140515172919.15967.70050.malonedeb@gac.canonical.com>
Message-ID: <20140805082153.21061.79060.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/99536
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=14080812961e5a2f6a7054a45d2afa013e4f3899
Submitter: Jenkins
Branch:    stable/icehouse

commit 14080812961e5a2f6a7054a45d2afa013e4f3899
Author: Matt Riedemann <mriedem at us.ibm.com>
Date:   Thu May 15 12:22:19 2014 -0700

    Mask block_device_info auth_password in virt driver debug logs
    
    The block_device_info object can have an auth_password key which is
    getting logged at debug level in several virt drivers so we need to
    sanitize the message getting logged.
    
    Adds tests to ensure the logged messages are properly sanitized.
    
    Note that bug 1321785 was opened to track the long-term design issues
    with storing the password in the block_device_info dict since this can
    crop up elsewhere if it's logged.  The immediate fix here is to mask
    what's already exposed.
    
    Closes-Bug: #1319943
    
    (cherry picked from commit 5dda3a6ab2becb5dd0b58c088f6daad807e12276)
    
    Conflicts:
    	nova/tests/virt/libvirt/test_libvirt.py
    	nova/tests/virt/vmwareapi/test_vmops.py
    
    Change-Id: I0eae07ce3f0f39861eb97ec3dec44895386c7d04


** Changed in: nova/icehouse
       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/1319943

Title:
  libvirt driver's to_xml method logs iscsi auth_password if debug

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) icehouse series:
  Fix Committed

Bug description:
  If you have debug logging enabled the libvirt driver's to_xml method
  logs the iscsi auth_password in plain text.

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



From michael_steffens at posteo.de  Tue Aug  5 11:04:32 2014
From: michael_steffens at posteo.de (Michael Steffens)
Date: Tue, 05 Aug 2014 11:04:32 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140805110433.7167.8519.launchpad@chaenomeles.canonical.com>

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From tristan.cacqueray at enovance.com  Tue Aug  5 14:18:52 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Tue, 05 Aug 2014 14:18:52 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140805141852.21061.3908.malone@soybean.canonical.com>

Thanks for the report, the OSSA task is set to incompete pending for
additional security detail from nova-coresec.

What is the likeliness to trigger this race in production ?

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

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From Travis_McPeak at symantec.com  Tue Aug  5 17:24:27 2014
From: Travis_McPeak at symantec.com (Travis McPeak)
Date: Tue, 5 Aug 2014 10:24:27 -0700
Subject: [Openstack-security] Why are we will seeing XSS flaws?
Message-ID: <D00660C9.4AE0%travis_mcpeak@symantec.com>

Hi Grant,

I think this is a great project for OSSG and I¹d definitely like to get
involved.  We¹ll kick it around at the next OSSG meeting this Thursday.

Thanks,
  -Travis




On 8/4/14, 10:42 PM, "openstack-security-request at lists.openstack.org"
<openstack-security-request at lists.openstack.org> wrote:

>Message: 4
>Date: Tue, 5 Aug 2014 12:44:56 +1000
>From: Grant Murphy <gmurphy at redhat.com>
>To: openstack-security at lists.openstack.org
>Subject: [Openstack-security] Why are we still seeing XSS flaws?
>Message-ID: <20140805024455.GA32168 at lappy.bne.redhat.com>
>Content-Type: text/plain; charset="us-ascii"
>
>Hi,
>
>I've been trying to put together some historical information about the
>security vulnerabilities that we are seeing in OpenStack [1]. The one
>thing
>that I've noticed is that we don't seem to be learning from our mistakes.
>
>The particular example that I'd like to call out is XSS.  This is a
>very well known problem with a simple solution. Most template
>frameworks when used correctly will automatically escape input unless
>autoescape is explicitly disabled. So why are we still seeing this class
>of
>bug turn up in 2014?
>
>I'd like to propose that the OSSG does a review of horizon's current
>strategy for mitigating this type of flaw and find a better way forward
>for future releases. Is anybody able to help out with this?




From bknudson at us.ibm.com  Tue Aug  5 22:51:27 2014
From: bknudson at us.ibm.com (Brant Knudson)
Date: Tue, 05 Aug 2014 22:51:27 -0000
Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm
References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com>
Message-ID: <20140805225127.26547.26075.malone@gac.canonical.com>

Can you make it configurable, and have it default to md5?

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

Title:
  Use of weak MD5 algorithm

Status in OpenStack Security Advisories:
  Won't Fix
Status in Openstack Database (Trove):
  Triaged

Bug description:
  The file: trove/trove/guestagent/strategies/storage/swift.py line 54
  uses a weak hashing algorithm, MD5. It would be pretty simple
  hardening upgrade to use at least hashlib.SHA256.

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



From gmurphy at redhat.com  Wed Aug  6 00:08:21 2014
From: gmurphy at redhat.com (Grant Murphy)
Date: Wed, 6 Aug 2014 10:08:21 +1000
Subject: [Openstack-security] Why are we will seeing XSS flaws?
In-Reply-To: <D00660C9.4AE0%travis_mcpeak@symantec.com>
References: <D00660C9.4AE0%travis_mcpeak@symantec.com>
Message-ID: <20140806000821.GA26824@lappy.bne.redhat.com>

Hi Travis,

That sounds like a good plan. It's 3am in my timezone when OSSG meetings are
usually held so it is a bit hard for me to make the meetings.  I'll try to
be there but If I sleep through my alarm I'll be sure to read the scrollback
& follow up on any action items assigned to me.

- Grant

On Tue, Aug 05, 2014 at 10:24:27AM -0700, Travis McPeak wrote:
> Hi Grant,
> 
> I think this is a great project for OSSG and I¹d definitely like to get
> involved.  We¹ll kick it around at the next OSSG meeting this Thursday.
> 
> Thanks,
>   -Travis
> 
> 
> 
> 
> On 8/4/14, 10:42 PM, "openstack-security-request at lists.openstack.org"
> <openstack-security-request at lists.openstack.org> wrote:
> 
> >Message: 4
> >Date: Tue, 5 Aug 2014 12:44:56 +1000
> >From: Grant Murphy <gmurphy at redhat.com>
> >To: openstack-security at lists.openstack.org
> >Subject: [Openstack-security] Why are we still seeing XSS flaws?
> >Message-ID: <20140805024455.GA32168 at lappy.bne.redhat.com>
> >Content-Type: text/plain; charset="us-ascii"
> >
> >Hi,
> >
> >I've been trying to put together some historical information about the
> >security vulnerabilities that we are seeing in OpenStack [1]. The one
> >thing
> >that I've noticed is that we don't seem to be learning from our mistakes.
> >
> >The particular example that I'd like to call out is XSS.  This is a
> >very well known problem with a simple solution. Most template
> >frameworks when used correctly will automatically escape input unless
> >autoescape is explicitly disabled. So why are we still seeing this class
> >of
> >bug turn up in 2014?
> >
> >I'd like to propose that the OSSG does a review of horizon's current
> >strategy for mitigating this type of flaw and find a better way forward
> >for future releases. Is anybody able to help out with this?
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

-- 
Grant Murphy / Red Hat Product Security

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140806/e424a50b/attachment.sig>

From SlickNik at gmail.com  Wed Aug  6 01:22:23 2014
From: SlickNik at gmail.com (Nikhil Manchanda)
Date: Wed, 06 Aug 2014 01:22:23 -0000
Subject: [Openstack-security] [Bug 1348339] Re: Use of weak MD5 algorithm
References: <20140724193709.21159.54059.malonedeb@wampee.canonical.com>
Message-ID: <20140806012223.26227.93691.malone@gac.canonical.com>

So I looked into this a bit more, and schang is correct. 
Trove is limited by the implementation that swift supports which is currently only MD5.
If we want to support file verification based on SHA256 or something else, we will need to have this added to swift. 

** Changed in: trove
       Status: Triaged => Opinion

** Changed in: trove
       Status: Opinion => Won't Fix

** Changed in: trove
     Assignee: Simon Chang (changsimon) => (unassigned)

** Changed in: trove
    Milestone: ongoing => 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/1348339

Title:
  Use of weak MD5 algorithm

Status in OpenStack Security Advisories:
  Won't Fix
Status in Openstack Database (Trove):
  Won't Fix

Bug description:
  The file: trove/trove/guestagent/strategies/storage/swift.py line 54
  uses a weak hashing algorithm, MD5. It would be pretty simple
  hardening upgrade to use at least hashlib.SHA256.

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



From michael_steffens at posteo.de  Wed Aug  6 08:13:23 2014
From: michael_steffens at posteo.de (Michael Steffens)
Date: Wed, 06 Aug 2014 08:13:23 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140806081323.26652.26179.malone@gac.canonical.com>

That is really tough to guess. I don't know any reason why a production
environment would be less susceptible by principle.

During my tests almost all QCOW2 instantiations and launches of
snapshots failed, until applying the fsync fix. Notable exceptions:

 * The cirros and ubuntu original images instantiated right after OpenStack setup, with no other load on the system at all.
 * Windows (due to its size! qemu-img can consume the disk head without catching up, while nova download is far away still writing the disk tail).

Failures of the others were varying, from no boot disk found at all, to
failures during boot. Thus, I wouldn't be too surprised if even a
certain fraction of running instances in production got clipped
unnoticed, but only lost chunks not being read so early, or not at all.

How big that fraction is depends on too many boundary conditions.

What's bothering me most with respect to security is the failure's
stickiness. Once a base image is broken on a compute node, it requires
careful intervention not get promoted into all subsequent
instantiations, also of other users and tenants.

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From michael_steffens at posteo.de  Wed Aug  6 09:14:23 2014
From: michael_steffens at posteo.de (Michael Steffens)
Date: Wed, 06 Aug 2014 09:14:23 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140806091423.26062.17217.malone@gac.canonical.com>

To answer you question more precisely: the race is triggered always,
also in production. Whether the right runner wins, and whether you
notice the damage if not, depends.

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From 1343657 at bugs.launchpad.net  Tue Aug  5 14:41:49 2014
From: 1343657 at bugs.launchpad.net (Robert Clark)
Date: Tue, 05 Aug 2014 14:41:49 -0000
Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup
	strategies
References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com>
Message-ID: <20140805144149.21666.66908.launchpad@soybean.canonical.com>

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

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

Title:
  Shell Injection in backup strategies

Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New
Status in Openstack Database (Trove):
  New

Bug description:
  Trove uses subprocess.Popen with shell=True in
  trove/trove/guestagent/strategies/backup/base.py line 61:

      def run(self):
          self.process = subprocess.Popen(self.command, shell=True,
                                          stdout=subprocess.PIPE,
                                          stderr=subprocess.PIPE,
                                          preexec_fn=os.setsid)
          self.pid = self.process.pid

  This could be used, maliciously or not, to inject arbitrary commands
  into a command line string. An example of this could be triggered is
  in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It
  is creating a MySQL string with single quote. If the password, either
  maliciously or just happens to contain another single quote, it will
  escape from the command and arbitrary data will be executed instead.

  For more information on subprocess, shell=True and command injection
  see: https://docs.python.org/2/library/subprocess.html#frequently-
  used-arguments

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



From doug at doughellmann.com  Tue Aug  5 19:06:44 2014
From: doug at doughellmann.com (Doug Hellmann)
Date: Tue, 05 Aug 2014 19:06:44 -0000
Subject: [Openstack-security] [Bug 1328488] Re: oslo apiclient logs
	sensitive data
References: <20140610105701.26336.80011.malonedeb@wampee.canonical.com>
Message-ID: <20140805190646.23375.63330.launchpad@wampee.canonical.com>

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

** Changed in: oslo
       Status: New => Triaged

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

Title:
  oslo apiclient logs sensitive data

Status in Oslo - a Library of Common OpenStack Code:
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  When trying to clean up the tempest logs in the gate, we leak
  passwords and keystone tokens everywhere. For instance, python-
  novaclient logs the auth token.

  What's more problematic though is that apiclient does the following:

      def _http_log_req(self, method, url, kwargs):
          if not self.debug:
              return

          string_parts = [
              "curl -i",
              "-X '%s'" % method,
              "'%s'" % url,
          ]

          for element in kwargs['headers']:
              header = "-H '%s: %s'" % (element, kwargs['headers'][element])
              string_parts.append(header)

          _logger.debug("REQ: %s" % " ".join(string_parts))
          if 'data' in kwargs:
              _logger.debug("REQ BODY: %s\n" % (kwargs['data']))

  The argument that it's at DEBUG level doesn't hold, because from the
  Atlanta operators summit it was clear that *all* operators are running
  their servers at DEBUG, because OpenStack is impossible to actually
  troubleshoot at any other logging level. And if you run neutron at
  debug level, then all your nova credentials are in your logs.

  This is coupled with the fact that a large amount of users are
  streaming all their logs directly into logstash. Which means they've
  now got a potentially public endpoint that lets them search for
  credentials.

  We need to stop doing that in a blanket way across OpenStack.

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



From tristan.cacqueray at enovance.com  Wed Aug  6 11:58:58 2014
From: tristan.cacqueray at enovance.com (Tristan Cacqueray)
Date: Wed, 06 Aug 2014 11:58:58 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140806115858.26227.6370.malone@gac.canonical.com>

Thanks you for the additional details.

There is a clear risk of compute node DoS through base image corruption.
This seems to impact up to Havana. Can @nova-coresec have a look at this
report please ?

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From Priti_Desai at symantec.com  Wed Aug  6 20:22:31 2014
From: Priti_Desai at symantec.com (Priti Desai)
Date: Wed, 6 Aug 2014 13:22:31 -0700
Subject: [Openstack-security] Invitation: Cloud Security - Deep Dive
 into OSSG and Threat Modeling
Message-ID: <D007DBA9.35385%priti_desai@symantec.com>

Hi Guys,

I have scheduled a meetup in Bay Area with the help of Bryan (Thanks Bryan) and team at Symantec.

This a kickoff meetup before we start a series of Hackthons @ Symantec, primarily focusing on OSSG activities.

Please make sure to RSVP and attend it if you are in area.

Cheers
Priti

From: Cloud Platform at Symantec <info at meetup.com<mailto:info at meetup.com>>
Date: Wednesday, August 6, 2014 11:57 AM
To: Priti Desai <priti_desai at symantec.com<mailto:priti_desai at symantec.com>>
Subject: Invitation: Cloud Security - Deep Dive into OSSG and Threat Modeling


        [http://www.meetup.com/z/img/ea1/MSMxMTI3OTg3ODIjMjAxNC0wOC0wNiAxNDo1NzozMiM3NjRiMGM5OS1kYmIwLTQ5NWEtYjJjYy1mZTlhMTNhMGM5MDg%3D/logo_52x35.gif] <http://www.meetup.com/t/ea1_1/>


New Meetup
Cloud Security - Deep Dive into OSSG and Threat Modeling<http://www.meetup.com/__ms112798782/Cloud-Platform-at-Symantec/events/199393922/t/ea1_grp/?rv=ea1&_af_eid=199393922&_af=event&expires=1407524252768&sig=3b8b953734dab397a6a453f9a7fd6f8c8782a698>
Cloud Platform at Symantec
Added by Priti Desai
Wednesday, August 27, 2014
6:30 PM

350 Ellis Street
Mountain View, CA 94043
I'm going
Change your RSVP<http://www.meetup.com/Cloud-Platform-at-Symantec/events/199393922/t/ea1_upd/?rv=ea1>
6:30 pm: Arrival & networking Drinks and Pizza will be provided. 7:00 pm: How can you contribute to OSSG - Dr. Bryan Payne, Nebula The OpenStack Security Group (OSSG) is the primary driving force for security throughout the OpenStack community. T...
Learn more<http://www.meetup.com/Cloud-Platform-at-Symantec/events/199393922/t/ea1_grp/?rv=ea1>

Follow us! [http://img1.meetupstatic.com/img/externalservice/socialmediaicons/website-16x16.png] <https://cpe.symantec.com>


Reading this on your phone? Get the Meetup app.

[http://img1.meetupstatic.com/img/email/download-appstore at 2x.png] <http://www.meetup.com/r/email/iphone/0/ea1_appstore/http://itunes.apple.com/us/app/meetup/id375990038> [http://img1.meetupstatic.com/img/email/download-playstore at 2x.png]  <http://www.meetup.com/r/email/android/0/ea1_appstore/http://play.google.com/store/apps/details?id=com.meetup&referrer=utm_source%3Demailfooter>

Unsubscribe<http://www.meetup.com/__ms112798782/Cloud-Platform-at-Symantec/optout/?submit=true&eo=ea1&_ms_unsub=true&email=nuMuMail&expires=1409943452768&sig=6fecea2eed14c80704353f52d5838d3a8d905b93> from similar emails from this Meetup Group

Add info at meetup.com<mailto:info at meetup.com> to your address book to receive all Meetup emails

Meetup, POB 4668 #37895 NY NY USA 10163

Meetup HQ in NYC is hiring! meetup.com/jobs<http://www.meetup.com/jobs/>

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

From seanrob at yahoo-inc.com  Wed Aug  6 20:42:34 2014
From: seanrob at yahoo-inc.com (Sean Roberts)
Date: Wed, 6 Aug 2014 20:42:34 +0000
Subject: [Openstack-security] Invitation: Cloud Security - Deep Dive
 into OSSG and Threat Modeling
In-Reply-To: <D007DBA9.35385%priti_desai@symantec.com>
References: <D007DBA9.35385%priti_desai@symantec.com>
Message-ID: <489A1240-C822-451C-87F0-B45AA4DCE379@yahoo-inc.com>

Why not use the established SFBay Openstack user group to promote security focused meetups? We have a lot of members already to help get local people to discuss your security topics. Let me know how we can help.

~sean

On Aug 6, 2014, at 1:25 PM, "Priti Desai" <Priti_Desai at symantec.com<mailto:Priti_Desai at symantec.com>> wrote:

Hi Guys,

I have scheduled a meetup in Bay Area with the help of Bryan (Thanks Bryan) and team at Symantec.

This a kickoff meetup before we start a series of Hackthons @ Symantec, primarily focusing on OSSG activities.

Please make sure to RSVP and attend it if you are in area.

Cheers
Priti

From: Cloud Platform at Symantec <info at meetup.com<mailto:info at meetup.com>>
Date: Wednesday, August 6, 2014 11:57 AM
To: Priti Desai <priti_desai at symantec.com<mailto:priti_desai at symantec.com>>
Subject: Invitation: Cloud Security - Deep Dive into OSSG and Threat Modeling


        [Meetup] <http://www.meetup.com/t/ea1_1/>


New Meetup
Cloud Security - Deep Dive into OSSG and Threat Modeling<http://www.meetup.com/__ms112798782/Cloud-Platform-at-Symantec/events/199393922/t/ea1_grp/?rv=ea1&_af_eid=199393922&_af=event&expires=1407524252768&sig=3b8b953734dab397a6a453f9a7fd6f8c8782a698>
Cloud Platform at Symantec
Added by Priti Desai
Wednesday, August 27, 2014
6:30 PM

350 Ellis Street
Mountain View, CA 94043
I'm going
Change your RSVP<http://www.meetup.com/Cloud-Platform-at-Symantec/events/199393922/t/ea1_upd/?rv=ea1>
6:30 pm: Arrival & networking Drinks and Pizza will be provided. 7:00 pm: How can you contribute to OSSG - Dr. Bryan Payne, Nebula The OpenStack Security Group (OSSG) is the primary driving force for security throughout the OpenStack community. T...
Learn more<http://www.meetup.com/Cloud-Platform-at-Symantec/events/199393922/t/ea1_grp/?rv=ea1>

Follow us! [http://img1.meetupstatic.com/img/externalservice/socialmediaicons/website-16x16.png] <https://cpe.symantec.com>


Reading this on your phone? Get the Meetup app.

[iPhone App Store] <http://www.meetup.com/r/email/iphone/0/ea1_appstore/http://itunes.apple.com/us/app/meetup/id375990038> [Google Play]  <http://www.meetup.com/r/email/android/0/ea1_appstore/http://play.google.com/store/apps/details?id=com.meetup&referrer=utm_source%3Demailfooter>

Unsubscribe<http://www.meetup.com/__ms112798782/Cloud-Platform-at-Symantec/optout/?submit=true&eo=ea1&_ms_unsub=true&email=nuMuMail&expires=1409943452768&sig=6fecea2eed14c80704353f52d5838d3a8d905b93> from similar emails from this Meetup Group

Add info at meetup.com<mailto:info at meetup.com> to your address book to receive all Meetup emails

Meetup, POB 4668 #37895 NY NY USA 10163

Meetup HQ in NYC is hiring! meetup.com/jobs<http://www.meetup.com/jobs/>

_______________________________________________
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/20140806/f9191d7e/attachment.html>

From enikanorov at mirantis.com  Thu Aug  7 09:52:26 2014
From: enikanorov at mirantis.com (Eugene Nikanorov)
Date: Thu, 07 Aug 2014 09:52:26 -0000
Subject: [Openstack-security] [Bug 1278843] Re: Neutron doesn't report using
	a stale CA certificate
References: <20140211121101.2015.95668.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140807095228.26444.17908.launchpad@gac.canonical.com>

** Changed in: neutron
   Importance: High => 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/1278843

Title:
  Neutron doesn't report using a stale CA certificate

Status in OpenStack Neutron (virtual network service):
  Confirmed

Bug description:
  It seems that when the CA certificate cashed locally by Neutron in
  /var/lib/neutron/keystone-signing/ is stale (does not match the
  current CA cert used by keystone), it is not possible to start a new
  instance. This is  understandable. However, the stacktrace error you
  get while trying to start as instance in such a situation is a hugely
  misleading:

  "ERROR: Error: unsupported operand type(s) for +: 'NoneType' and
  'str'"

  It's rather tricky to debug the issue.

  To reproduce just redo the pki-setup for keystone on a deployed and
  otherwise healthy openstack cluster. This will create a new CA cert
  for keystone, however neutron-server will be completely oblivious to
  this fact and will still insist on using it's local copy of the
  cacert.

  I'm running Havana on rhel6.4

  ----------
  /var/log/nova/compute.log  on the compute node when trying to start a vm

  OpenStack (nova:4668) ERROR: Instance failed network setup after 1 attempt(s)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager Traceback (most recent call last):
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1238, in _allocate_network_async
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     dhcp_options=dhcp_options)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/api.py", line 49, in wrapper
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     res = f(self, context, *args, **kwargs)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 358, in allocate_for_instance
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     LOG.exception(msg, port_id)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 323, in allocate_for_instance
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     port_req_body)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 392, in _populate_neutron_extension_values
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     self._refresh_neutron_extensions_cache()
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 376, in _refresh_neutron_extensions_cache
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     extensions_list = neutron.list_extensions()['extensions']
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 108, in with_params
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     ret = self.function(instance, *args, **kwargs)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 286, in list_extensions
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     return self.get(self.extensions_path, params=_params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1183, in get
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     headers=headers, params=params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1168, in retry_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     headers=headers, params=params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1103, in do_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     resp, replybody = self.httpclient.do_request(action, method, body=body)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 188, in do_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     self.authenticate()
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 224, in authenticate
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     token_url = self.auth_url + "/tokens"
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager

  ----------------
  /var/log/neutron/server.log on the controller when trying to start a vm

  OpenStack (neutron:29274) DEBUG: Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-
  Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role
  OpenStack (neutron:29274) INFO: Starting new HTTP connection (1): openstack
  OpenStack (neutron:29274) DEBUG: received {u'_context_roles': [u'admin'], u'_context_read_deleted': u'no', u'_context_tenant_id': None, u'args': {u'agent_state': {u'agent_state': {u'topic': u'N/A', u'binary'
  : u'neutron-openvswitch-agent', u'host': u'node001', u'agent_type': u'Open vSwitch agent', u'configurations': {u'tunnel_types': [], u'tunneling_ip': u'', u'bridge_mappings': {u'ph-eth0': u'br0'}, u'l2_popula
  tion': False, u'devices': 0}}}, u'time': u'2014-02-11T12:06:32.434133'}, u'namespace': None, u'_unique_id': u'ae5c6b608f6547f7b630dace2c5411bd', u'_context_is_admin': True, u'version': u'1.0', u'_context_pro
  ject_id': None, u'_context_timestamp': u'2014-02-11 12:00:14.386557', u'_context_user_id': None, u'method': u'report_state'}
  OpenStack (neutron:29274) DEBUG: unpacked context: {'user_id': None, 'roles': [u'admin'], 'tenant_id': None, 'is_admin': True, 'timestamp': u'2014-02-11 12:00:14.386557', 'project_id': None, 'read_deleted': u'no'}
  OpenStack (neutron:29274) DEBUG: "GET /v2.0/tokens/revoked HTTP/1.1" 200 1234
  OpenStack (neutron:29274) WARNING: Verify error: Command 'openssl' returned non-zero exit status 4
  OpenStack (neutron:29274) DEBUG: Token validation failure.
  Traceback (most recent call last):
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 808, in _validate_user_token
      verified = self.verify_signed_token(user_token)
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1165, in verify_signed_token
      if self.is_signed_token_revoked(signed_text):
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1127, in is_signed_token_revoked
      revocation_list = self.token_revocation_list
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1217, in token_revocation_list
      self.token_revocation_list = self.fetch_revocation_list()
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1247, in fetch_revocation_list
      return self.cms_verify(data['signed'])
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1160, in cms_verify
      raise err
  CalledProcessError: Command 'openssl' returned non-zero exit status 4
  OpenStack (neutron:29274) DEBUG: Marking token c5e1c4ed4d0ab0db8bbaffbb33e139ba as unauthorized in memcache
  OpenStack (neutron:29274) WARNING: Authorization failed for token c5e1c4ed4d0ab0db8bbaffbb33e139ba
  OpenStack (neutron:29274) INFO: Invalid user token - rejecting request

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



From dstanek at dstanek.com  Thu Aug  7 13:46:52 2014
From: dstanek at dstanek.com (David Stanek)
Date: Thu, 7 Aug 2014 09:46:52 -0400
Subject: [Openstack-security] Why are we will seeing XSS flaws?
In-Reply-To: <D00660C9.4AE0%travis_mcpeak@symantec.com>
References: <D00660C9.4AE0%travis_mcpeak@symantec.com>
Message-ID: <46D99142-13D5-4794-8003-A14D557FA472@dstanek.com>


On Aug 5, 2014, at 13:24, Travis McPeak <Travis_McPeak at symantec.com> wrote:

> Hi Grant,
> 
> I think this is a great project for OSSG and I¹d definitely like to get
> involved.  We¹ll kick it around at the next OSSG meeting this Thursday.
> 

I’m also very interested in this topic. I’ll be at the meeting to see how I can help out.

— David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140807/1c55f6e9/attachment.sig>

From thierry.carrez+lp at gmail.com  Thu Aug  7 15:30:47 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 07 Aug 2014 15:30:47 -0000
Subject: [Openstack-security] [Bug 1337349] Re: Nova qemu hypervisor host
 smbios serial number is leaked to guest
References: <20140703142824.27562.82896.malonedeb@gac.canonical.com>
Message-ID: <20140807153049.6965.58059.launchpad@chaenomeles.canonical.com>

** Information type changed from Private Security to Public

** Changed in: ossa
       Status: Incomplete => Won't Fix

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

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

Title:
  Nova qemu hypervisor host smbios serial number is leaked to guest

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  Erwan Velu from eNovance reported a vulnerability in OpenStack Nova.

  The hypervisor is passing host system uuid (-smbios version) to guests, and this happen to be a critical info leak.
  The defect have been pinpointed to:
   https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3054

  From a simple virtual machine, this may allow numerous info leak like:
      Allow compute hardware enumeration from guests
      Deduce service tag and get all hardware configuration
      Ability to know if two instances are on the same compute

  Dell hardware is particulary impacted as :
      - the uuid encodes the service tag
      - the service tag can be used on support site to determine:
      - detailled hardware configuration
      - date & country where the hw was shipped
      - date & type of support contract
      - amount of servers bought during this shipment

  If there is no use case for this, we should scrambled that piece of
  information.

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



From 1308727 at bugs.launchpad.net  Thu Aug  7 18:29:56 2014
From: 1308727 at bugs.launchpad.net (Alan Pevec)
Date: Thu, 07 Aug 2014 18:29:56 -0000
Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in
 Horizon Heat template - resource name (CVE-2014-3473)
References: <20140416193338.27100.82700.malonedeb@gac.canonical.com>
Message-ID: <20140807182958.28771.70191.launchpad@chaenomeles.canonical.com>

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

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

** Tags removed: in-stable-icehouse

** Changed in: horizon/havana
     Assignee: (unassigned) => Julie Pichon (jpichon)

** Changed in: horizon/icehouse
     Assignee: (unassigned) => Julie Pichon (jpichon)

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

Title:
  [OSSA 2014-023] XSS in Horizon Heat template - resource name
  (CVE-2014-3473)

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

Bug description:
  The attached yaml will result in a Cross Site Script when viewing the
  resources or events of an Orchestration stack in the following paths:

  /project/stacks/stack/{stack_id}/?tab=stack_details__resources
  /project/stacks/stack/{stack_id}/?tab=stack_details__events

  The A tag's href attribute does not properly URL encode the name of
  the resource string resulting in escaping out of the attribute and
  arbitrary HTML written to the page.

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



From 1321080 at bugs.launchpad.net  Thu Aug  7 23:39:35 2014
From: 1321080 at bugs.launchpad.net (Eoghan Glynn)
Date: Thu, 07 Aug 2014 23:39:35 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140807233937.4866.32004.launchpad@gac.canonical.com>

** Changed in: ceilometer/icehouse
    Milestone: 2014.1.2 => None

** Changed in: ceilometer/icehouse
     Assignee: (unassigned) => gordon chung (chungg)

** Changed in: ceilometer/icehouse
   Importance: Undecided => Critical

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Committed
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released
Status in oslo havana series:
  Fix Committed
Status in oslo icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From matt at nycresistor.com  Fri Aug  8 03:03:45 2014
From: matt at nycresistor.com (matt)
Date: Thu, 7 Aug 2014 23:03:45 -0400
Subject: [Openstack-security] Dan Geer - Blackhat Keynote 2014 ( A must
	watch )
Message-ID: <CAP_sDUH4jcQEg6+ZDENK5O6RrrL3V-sj_-N4U8JPQvc-3LeAGg@mail.gmail.com>

https://www.youtube.com/watch?v=nT-TGvYOBpI

I highly recommend taking the time to watch this end to end in a quiet
place.


-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140807/d4e9e823/attachment.html>

From chuck.short at canonical.com  Thu Aug  7 02:42:58 2014
From: chuck.short at canonical.com (Chuck Short)
Date: Thu, 07 Aug 2014 02:42:58 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140807024302.6870.88092.launchpad@chaenomeles.canonical.com>

** Changed in: neutron/icehouse
    Milestone: None => 2014.1.2

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Committed
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Committed
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released
Status in oslo havana series:
  Fix Committed
Status in oslo icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From chuck.short at canonical.com  Thu Aug  7 12:02:19 2014
From: chuck.short at canonical.com (Chuck Short)
Date: Thu, 07 Aug 2014 12:02:19 -0000
Subject: [Openstack-security] [Bug 1321785] Re: RFE: block_device_info dict
 should have a password key rather than clear password
References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com>
Message-ID: <20140807120219.26336.25376.launchpad@gac.canonical.com>

** Also affects: nova/icehouse
   Importance: Undecided
       Status: New

** Changed in: nova/icehouse
       Status: New => Invalid

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

Title:
  RFE: block_device_info dict should have a password key rather than
  clear password

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Compute (nova) icehouse series:
  Invalid

Bug description:
  See bug 1319943 and the related patch
  https://review.openstack.org/#/c/93787/ for details, but right now the
  block_device_info dict passed around in the nova virt driver can
  contain a clear text password for the auth_password key.

  That bug and patch are masking the password when logged in the
  immediate known locations, but this could continue to crop up so we
  should change the design such that the block_device_info dict doesn't
  contain the password but rather a key to a store that nova can
  retrieve the password for use.

  Comment from Daniel Berrange in the patch above:

  "Long term I think we need to figure out a way to remove the passwords
  from any data dicts we pass around. Ideally the block device info
  would merely contain something like a UUID to identify a password,
  which Nova could use to fetch the actual password from a secure
  password manager service at time of use. Thus we wouldn't have to
  worry about random objects/dicts containing actual passwords.
  Obviously this isn't something we can do now, but could you file an
  RFE to address this from a design POV, because masking passwords at
  time of logging call is not really a viable long term strategy IMHO."

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



From chuck.short at canonical.com  Thu Aug  7 13:05:37 2014
From: chuck.short at canonical.com (Chuck Short)
Date: Thu, 07 Aug 2014 13:05:37 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140807130541.21032.54666.launchpad@soybean.canonical.com>

** Changed in: ceilometer/icehouse
    Milestone: None => 2014.1.2

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Committed
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Committed
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released
Status in oslo havana series:
  Fix Committed
Status in oslo icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From chuck.short at canonical.com  Thu Aug  7 13:27:13 2014
From: chuck.short at canonical.com (Chuck Short)
Date: Thu, 07 Aug 2014 13:27:13 -0000
Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in
 Horizon Heat template - resource name (CVE-2014-3473)
References: <20140416193338.27100.82700.malonedeb@gac.canonical.com>
Message-ID: <20140807132714.26194.69298.launchpad@gac.canonical.com>

** Changed in: horizon/icehouse
    Milestone: None => 2014.1.2

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

Title:
  [OSSA 2014-023] XSS in Horizon Heat template - resource name
  (CVE-2014-3473)

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

Bug description:
  The attached yaml will result in a Cross Site Script when viewing the
  resources or events of an Orchestration stack in the following paths:

  /project/stacks/stack/{stack_id}/?tab=stack_details__resources
  /project/stacks/stack/{stack_id}/?tab=stack_details__events

  The A tag's href attribute does not properly URL encode the name of
  the resource string resulting in escaping out of the attribute and
  arbitrary HTML written to the page.

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



From chuck.short at canonical.com  Thu Aug  7 16:56:52 2014
From: chuck.short at canonical.com (Chuck Short)
Date: Thu, 07 Aug 2014 16:56:52 -0000
Subject: [Openstack-security] [Bug 1319943] Re: libvirt driver's to_xml
 method logs iscsi auth_password if debug
References: <20140515172919.15967.70050.malonedeb@gac.canonical.com>
Message-ID: <20140807165655.28676.63430.launchpad@chaenomeles.canonical.com>

** Changed in: nova/icehouse
       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/1319943

Title:
  libvirt driver's to_xml method logs iscsi auth_password if debug

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) icehouse series:
  Fix Released

Bug description:
  If you have debug logging enabled the libvirt driver's to_xml method
  logs the iscsi auth_password in plain text.

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



From chuck.short at canonical.com  Thu Aug  7 19:43:02 2014
From: chuck.short at canonical.com (Chuck Short)
Date: Thu, 07 Aug 2014 19:43:02 -0000
Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in
 Horizon Heat template - resource name (CVE-2014-3473)
References: <20140416193338.27100.82700.malonedeb@gac.canonical.com>
Message-ID: <20140807194306.23974.57264.launchpad@wampee.canonical.com>

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

Title:
  [OSSA 2014-023] XSS in Horizon Heat template - resource name
  (CVE-2014-3473)

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

Bug description:
  The attached yaml will result in a Cross Site Script when viewing the
  resources or events of an Orchestration stack in the following paths:

  /project/stacks/stack/{stack_id}/?tab=stack_details__resources
  /project/stacks/stack/{stack_id}/?tab=stack_details__events

  The A tag's href attribute does not properly URL encode the name of
  the resource string resulting in escaping out of the attribute and
  arbitrary HTML written to the page.

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



From chuck.short at canonical.com  Thu Aug  7 22:42:22 2014
From: chuck.short at canonical.com (Chuck Short)
Date: Thu, 07 Aug 2014 22:42:22 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140807224227.23709.32625.launchpad@wampee.canonical.com>

** Changed in: neutron/icehouse
       Status: Fix Committed => Fix Released

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Committed
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released
Status in oslo havana series:
  Fix Committed
Status in oslo icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From bdpayne at acm.org  Fri Aug  8 21:09:27 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Fri, 8 Aug 2014 14:09:27 -0700
Subject: [Openstack-security] Invitation: Cloud Security - Deep Dive
 into OSSG and Threat Modeling
In-Reply-To: <489A1240-C822-451C-87F0-B45AA4DCE379@yahoo-inc.com>
References: <D007DBA9.35385%priti_desai@symantec.com>
 <489A1240-C822-451C-87F0-B45AA4DCE379@yahoo-inc.com>
Message-ID: <CAFpPvXCyax_GxKPvNWiK64kB9+O5bLJf9e2Kk6nSQODSxgozRA@mail.gmail.com>

Sean, I actually agree that this would make sense.  Priti, thoughts?
-bryan


On Wed, Aug 6, 2014 at 1:42 PM, Sean Roberts <seanrob at yahoo-inc.com> wrote:

>  Why not use the established SFBay Openstack user group to promote
> security focused meetups? We have a lot of members already to help get
> local people to discuss your security topics. Let me know how we can help.
>
> ~sean
>
> On Aug 6, 2014, at 1:25 PM, "Priti Desai" <Priti_Desai at symantec.com>
> wrote:
>
>   Hi Guys,
>
>  I have scheduled a meetup in Bay Area with the help of Bryan (Thanks
> Bryan) and team at Symantec.
>
>  This a kickoff meetup before we start a series of Hackthons @ Symantec,
> primarily focusing on OSSG activities.
>
>  Please make sure to RSVP and attend it if you are in area.
>
>  Cheers
> Priti
>
>   From: Cloud Platform at Symantec <info at meetup.com>
> Date: Wednesday, August 6, 2014 11:57 AM
> To: Priti Desai <priti_desai at symantec.com>
> Subject: Invitation: Cloud Security - Deep Dive into OSSG and Threat
> Modeling
>
>
>  [image: Meetup]
>
>    New Meetup
>  Cloud Security - Deep Dive into OSSG and Threat Modeling
>  Cloud Platform at Symantec
>  Added by Priti Desai
>   Wednesday, August 27, 2014
> 6:30 PM
>
> 350 Ellis Street
> Mountain View, CA 94043
>     I'm going
> Change your RSVP
>   6:30 pm: Arrival & networking Drinks and Pizza will be provided. 7:00
> pm: How can you contribute to OSSG - Dr. Bryan Payne, Nebula The OpenStack
> Security Group (OSSG) is the primary driving force for security throughout
> the OpenStack community. T...
> Learn more
>
>  Follow us!
>
>  Reading this on your phone? Get the Meetup app.
> [image: iPhone App Store] [image: Google Play]
>
> Unsubscribe from similar emails from this Meetup Group
>
> Add info at meetup.com to your address book to receive all Meetup emails
>
> Meetup, POB 4668 #37895 NY NY USA 10163
>
> *Meetup HQ in NYC is hiring!* meetup.com/jobs
>
>   _______________________________________________
> 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/20140808/df56b549/attachment.html>

From 1004114 at bugs.launchpad.net  Mon Aug 11 10:25:46 2014
From: 1004114 at bugs.launchpad.net (Abu Shohel Ahmed)
Date: Mon, 11 Aug 2014 10:25:46 -0000
Subject: [Openstack-security] [Bug 1004114] Re: Password logging
References: <20120524190215.26515.18198.malonedeb@gac.canonical.com>
Message-ID: <20140811102549.28868.29796.launchpad@chaenomeles.canonical.com>

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

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

Title:
  Password logging

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Security Notes:
  In Progress
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  When the log level is set to DEBUG, keystoneclient's full-request
  logging mechanism kicks in, exposing plaintext passwords, etc.

  This bug is mostly out of the scope of Horizon, however Horizon can
  also be more secure in this regard. We should make sure that wherever
  we *are* handling sensitive data we use Django's error report
  filtering mechanisms so they don't appear in tracebacks, etc.
  (https://docs.djangoproject.com/en/dev/howto/error-reporting
  /#filtering-error-reports)

  Keystone may also want to look at respecting such annotations in their
  logging mechanism, i.e. if Django were properly annotating these data
  objects, keystoneclient could check for those annotations and properly
  sanitize the log output.

  If not this exact mechanism, then something similar would be wise.

  For the time being, it's also worth documenting in both projects that
  a log level of DEBUG will log passwords in plain text.

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



From thierry.carrez+lp at gmail.com  Mon Aug 11 14:57:57 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 11 Aug 2014 14:57:57 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140811145757.5231.26138.malone@gac.canonical.com>

This feels like a corruption bug, I'm not sure an "attacker" would act
differently from a normal user here, so i'm not sure it really qualifies
as a vulnerability.

If the user had to do something special to trigger corruption, I would
change my mind, but I think most setups do not hit this condition
(otherwise this bug would have surfaced earlier) and normal usage
triggers the exact same issue as an attack.

I'd definitely a bug though, and it should definitely be fixed. the
question is, should we go through the delays of private security
bugfixing or fix it asap.

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From gerrit2 at review.openstack.org  Mon Aug 11 16:31:35 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 11 Aug 2014 16:31:35 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I7ba7dbd65e913a66efe35a1d6490a85bec8413da
Message-ID: <E1XGsVT-0003Yp-Dw@review.openstack.org>


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

Log:
commit 626adcb0a68b4232bdde35629f97bb38c113c0bd
Author: Daniel P. Berrange <berrange at redhat.com>
Date:   Mon Jul 28 15:15:44 2014 +0100

    libvirt: make sysinfo serial number configurable
    
    The 'serial' field in guest SMBIOS tables gets populated
    based on the libvirt reported UUID of the host hardware.
    The rationale is to allow correlation of guests running
    on the same host.
    
    Unfortunately some hardware vendors use a subset of the
    host UUID as a key for retrieving hardware support
    contract information without requiring any authentication.
    So exposing the host UUID to the guest is an information
    leak for those vendors. It is possible to override the
    use of SMBIOS data by libvirt in /etc/libvirt/libvirtd.conf
    by setting the 'host_uuid' parameter.
    
    As a way to reduce the configuration burden though, it is
    preferrable to use the /etc/machine-id UUID, instead of
    the host hardware UUID. The former is a recent standard
    for Linux distros introduced by systemd to provide a UUID
    that is unique per operating system install. This means
    that even containers will see a separate /etc/machine-id
    value. This /etc/machine-id can be expected to be widely
    available in current and future distros. If missing, it
    is still possible to fallback to the libvirt reported
    host UUID.
    
    The host UUID exposed could theoretically be leveraged
    by a cloud user to get an approximate count of the number
    of unique hosts available to them in the cloud by launching
    many short lived VMs. Administrators concerned about this
    may wish to disable reporting of any sysinfo serial field
    at all.
    
    Introduce a 'sysinfo_serial' config parameter to the libvirt
    driver to control behaviour, accepting values:
    
     - 'auto' - try /etc/machine-id, fallback to
       libvirt reported host UUID (new default)
     - 'hardware' - always use libvirt host UUID (old default)
     - 'os' - always use /etc/machine-id, error if missing
     - 'none' - do not report any value to the guest
    
    DocImpact
    SecurityImpact
    Closes-bug: #1337349
    Change-Id: I7ba7dbd65e913a66efe35a1d6490a85bec8413da




From michael_steffens at posteo.de  Tue Aug 12 07:46:27 2014
From: michael_steffens at posteo.de (Michael Steffens)
Date: Tue, 12 Aug 2014 07:46:27 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140812074627.28945.34641.malone@chaenomeles.canonical.com>

A vulnerability exploited by normal user behavior (such as putting load
on a system),  that can be used to cause corruption across different
user instances I'd even be more concerned about, than something that
needs special actions. On the other hand, modulating the load in manner
that a specific corruption (such as selectively dropping chunks), would
require very sophisticated actions, I agree.

Nevertheless, yesterday, after a regular Ubuntu nova-compute update
reverted my local fix to defective behavior, I observed a new variant of
corruption: A new snapshot booted fine,  but then exposed filesystem
errors. After redoing the whole exercise using the same image after
reapplying the fsync patch, everything was fine.

I wouldn't be surprised if such issues do already surface in production
now and then (less frequent than in my environment, though), but are
then blamed on guest OS issues instead. Let me illustrate.:

This is how it looks to the end user: Take a snapshot, launch, fails.
Launch the same snapshot again, fails the same way. Looks like the
snaphost itself is defective, doesn't it? Most suspected: the filesystem
has been in inconsistent state when doing the snapshot. So let's do a
new snapshot. And indeed that either works, or fails consistently in a
different way than the first.

Who wouldn't conclude that it's the guest OS or the way the snapshot is
done (nothing OpenStack could do anything about) that is at fault,
rather than the image being corrupted after download from glance, and
then cached?

Is there anything I can provide to get this ticket out of the incomplete
and unassigned state?

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From fungi at yuggoth.org  Tue Aug 12 12:51:00 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 12 Aug 2014 12:51:00 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140812125100.17820.92090.malone@soybean.canonical.com>

If you want to propose a patch to nova addressing the issue, you can
assign the nova bugtask to yourself, otherwise it will need to wait for
nova bug supervisors to triage it and an interested developer to pick it
up and start work on a solution.

The vulnerability management team will probably end up
removing/invalidating the security advisory task and switching this to a
normal public bug, but that really shouldn't affect the nova triage and
development work on it.

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From edmondsw at us.ibm.com  Tue Aug 12 13:20:05 2014
From: edmondsw at us.ibm.com (Matthew Edmonds)
Date: Tue, 12 Aug 2014 13:20:05 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140812132005.17509.89826.malone@soybean.canonical.com>

why is the CVE for this still not public? It still just says it has been
reserved... "This candidate has been reserved by an organization or
individual that will use it when announcing a new security problem. When
the candidate has been publicized, the details for this candidate will
be provided."

I'm guessing this was just an oversight. Can someone fix it?

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Committed
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released
Status in oslo havana series:
  Fix Committed
Status in oslo icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From thierry.carrez+lp at gmail.com  Tue Aug 12 14:04:18 2014
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Tue, 12 Aug 2014 14:04:18 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140812140418.4928.95370.malone@gac.canonical.com>

It takes months, sometimes years for MITRE to come back to a reserved
CVE and fill the appropriate information on their website. In the mean
time, the CVE number serves as a reference number for all the people
that need to coordinate on an issue.

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Committed
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released
Status in oslo havana series:
  Fix Committed
Status in oslo icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From 1329737 at bugs.launchpad.net  Tue Aug 12 14:16:24 2014
From: 1329737 at bugs.launchpad.net (Dolph Mathews)
Date: Tue, 12 Aug 2014 14:16:24 -0000
Subject: [Openstack-security] [Bug 1329737] Re: Valid tokens may remain
 after token's user was deleted
References: <20140613111922.26567.45578.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140812141626.28398.72079.launchpad@chaenomeles.canonical.com>

** Changed in: keystone
     Assignee: (unassigned) => Adam Young (ayoung)

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

Title:
  Valid tokens may remain after token's user was deleted

Status in OpenStack Identity (Keystone):
  Triaged
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  When user is deleted, deleted user's tokens are expired after committing transaction for deleting user.
  If database dies while tokens are being expired, remaining tokens will lose the chance to expire until 24 hours later.
  (Because user is already deleted.)
  In this case, remaining tokens are able to used to authenticate despite the fact that token's user was deleted.

  I think this case is dangerous from the security point of view.

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



From fungi at yuggoth.org  Tue Aug 12 14:16:51 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 12 Aug 2014 14:16:51 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140812141651.5164.11127.malone@gac.canonical.com>

It was publicly assigned by MITRE in http://www.openwall.com/lists/oss-
security/2014/06/24/6 and sometimes it takes their editorial board a
while to compose and publish the official CVE description (can be on the
order of several months).

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Committed
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released
Status in oslo havana series:
  Fix Committed
Status in oslo icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From michael_steffens at posteo.de  Tue Aug 12 15:12:58 2014
From: michael_steffens at posteo.de (Michael Steffens)
Date: Tue, 12 Aug 2014 15:12:58 -0000
Subject: [Openstack-security] [Bug 1350766] Re: Race condition: compute
 intermittently corrupts base images on download from glance
References: <20140731093840.27155.74652.malonedeb@soybean.canonical.com>
Message-ID: <20140812151258.23877.45401.malone@wampee.canonical.com>

The patch was proposed in the very beginning, see
https://bugs.launchpad.net/nova/+bug/1350766/+attachment/4166489/+files
/nova-glance.patch

It's copies a snipplet of utils code from swift, in order not to
introduce a cross service dependency. The actual fix is then a one-
liner: fsync the image before returning from download.

The modification itself is quite self contained. Whether the style is
acceptable needs review. But should be low hanging fruit.

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

Title:
  Race condition: compute intermittently corrupts base images on
  download from glance

Status in OpenStack Compute (Nova):
  New
Status in OpenStack Security Advisories:
  Incomplete

Bug description:
  Under certain conditions, which I happen to meet often on my Icehouse
  single node setup, uploaded images or snapshots fail to boot. See also
  https://ask.openstack.org/en/question/42804/icehouse-how-to-boot-a
  -snapshot-from-a-running-instance/

  Reason: When first instantiating a QCOW2 image, it's

  (1)  downloaded as QCOW2 to /var/lib/nova/instances/_base/IMAGEID.part
  (2)  converted to RAW format base /var/lib/nova/instances/_base/IMAGEID.converted using qemu-img

  The step (1) is performed in nova/image/glance.py,
  GlanceImageService.download using buffered IO, which does not
  guarantee the resulting data to be written to disk on file close.
  Consequently, the source image file may not be written completely when
  qemu-img sub-process starts reading in step (2). Whether the result is
  good or bad depends on speed of download, file size, and how quickly
  qemu-image can digest its input.

  Proposed fix: enforce fsync on output File object before returning
  from download. Patch attached.

  Security considerations:

   * Due to the race between resources shared between users and tenants
  (compute node network and filesystem IO) a failure can be triggered
  across tenants, implying the risk of DoS.

   * To make things worse -- with the default setting of not cleaning
  the image cache -- any corrupted image will remain in cache until
  replaced with fresh upload using a new image ID. Affected snapshots
  remain unusable forever, until ex- and re-imported manually under
  better conditions.

   * Base image corruptions here are not detected and cannot be caught.
  Theoretically (a bit esoteric, quite unlikely, but not impossible), an
  attacker might modulate resource usage to precisely create an
  incompletely written image, that boots and runs, but has access
  control information stripped.

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



From paul.mcmillan at nebula.com  Tue Aug 12 20:30:02 2014
From: paul.mcmillan at nebula.com (Paul McMillan)
Date: Tue, 12 Aug 2014 20:30:02 +0000
Subject: [Openstack-security]  Why are we still seeing XSS flaws?
Message-ID: <1407875401982.83284@nebula.com>

Horizon uses the Django framework, which provides good escaping. The problem is, as Horizon has grown and changed, many contributors have been interested in solving their localized problem as fast as possible, which means that output sanitization has largely turned into an adhoc mismash of bandaids to fix each security issue as it is reported. At present, it is nearly impossible to reason about the safety of any particular string which gets rendered out, and so new bugs get added regularly as inexpert contributors follow existing code without understanding the underlying reasoning.

The fundamental issue here is that Horizon has mixed HTML into the codebase, rather than keeping it all at the templating layer. This means that it's passing around strings which have been marked safe when they should not be, and the default response from new developers is "I don't know why I'm seeing escape codes, I'll just mark this as safe". We can fix the underlying issues by removing HTML generation from the code, and moving everything back to the template rendering system as it should have been in the first place. Once we've done this, we can add an automated test which rejects any patch which includes a call to mark_safe(), or similar techniques.

I'm familiar with the horizon code, I'm familiar with how to do it right (I'm a member of the Django security team). I've had conversations with Horizon contributors, conversations in patches, and conversations on many of these XSS bug tickets, about how to fix the problem at the architectural level. Unfortunately, I'm not able to undertake the fairly large architectural project to fix this all by myself. I'm happy to sit down (preferably in person) with Horizon contributors who explicitly have time to do the work, and carefully work through what needs to be fixed. I'm not willing to write a report detailing exactly where things are wrong, which will then be ignored because fixing architectural flaws is lower priority than all other dev work.

This seems like it might  be a good thing to plan to do for several days at a summit, but we'd need buyin from several people qualified to undertake the work. I think if we had several devs who know the horizon codebase, and a commitment to 2 or 3 days of focused hacking, we could fix the flow of this type of bug nearly permanently.

It's time to stop the bandaids.

-Paul

On Mon, Aug 4, 2014 at 10:44 PM, Grant Murphy <gmurphy at redhat.com> wrote:

> Hi,
>
> I've been trying to put together some historical information about the
> security vulnerabilities that we are seeing in OpenStack [1]. The one thing
> that I've noticed is that we don't seem to be learning from our mistakes.
>
> The particular example that I'd like to call out is XSS.  This is a
> very well known problem with a simple solution. Most template
> frameworks when used correctly will automatically escape input unless
> autoescape is explicitly disabled. So why are we still seeing this class of
> bug turn up in 2014?
>
> I'd like to propose that the OSSG does a review of horizon's current
> strategy for mitigating this type of flaw and find a better way forward
> for future releases. Is anybody able to help out with this?
>
> [1] http://openstack-security.info  (#wip)
>
> --
> Grant
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>


From 1329214 at bugs.launchpad.net  Tue Aug 12 20:45:59 2014
From: 1329214 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 12 Aug 2014 20:45:59 -0000
Subject: [Openstack-security] [Bug 1329214] Change abandoned on cinder
	(master)
References: <20140612080140.21505.11780.malonedeb@gac.canonical.com>
Message-ID: <20140812204559.17538.34368.malone@soybean.canonical.com>

Change abandoned by Duncan Thomas (duncan.thomas at gmail.com) on branch: master
Review: https://review.openstack.org/102420
Reason: Abandoning change: No update for more than 14 days

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

Title:
  tgtadm iscsi chap does not work

Status in Cinder:
  In Progress

Bug description:
  When using LVMISCSIDriver and iscsi_helper tgtadm, it should support chap unidirectional authentication because target configuration file and db.volume  has record chap user and chap passwd. 
  By testing, I found that tgtadm iscsi chap does not work.
  Is it a security bug for iscsi_helper tgtadm? 

  My detail test work is as follows.
  1. Test details as follows without modify the source code:
  1) Devstack all in one server A(10.250.10.190); another testing server B(10.250.10.191)
  2) create a vm  VM-A  and a cinder volume VOLUME-A, attach VOLUME-A to VM-A
  3) server B directly login the iscsi target that server-A export and get VOLUME-A sucessfully . 
      iscsiadm -m discovery -t sendtargets -p 10.250.10.190
      iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login

  2. Test details as follows with modify the source code:
  1) add creating user/passwd and binding user to tid code before leaving the function TgtAdm:create_iscsi_target. 
          type, name, passwd = chap_auth.split()
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'new',
                        '--user',
                        name,
                        '--password',
                        passwd)
          self._execute('tgtadm',
                        '--lld',
                        'iscsi',
                        '--mode',
                        'account',
                        '--op',
                        'bind',
                        '--tid',
                        tid,
                        '--user',
                        name
                        )

  2) try to login VOLUME-A as the steps in item 1, it reported an authorization error as follows.
  root at devaio1:/etc/iscsi#     iscsiadm -m node -T  iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e -p 10.250.10.190 -l --login
  Logging in to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260] (multiple)
  iscsiadm: Could not login to [iface: default, target: iqn.2010-10.org.openstack:volume-ee32035f-73d2-4312-a468-c7773f90a75e, portal: 10.250.10.190,3260].
  iscsiadm: initiator reported error (24 - iSCSI login failed due to authorization failure)
  iscsiadm: Could not log into all portals

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



From 1188189 at bugs.launchpad.net  Tue Aug 12 20:47:40 2014
From: 1188189 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 12 Aug 2014 20:47:40 -0000
Subject: [Openstack-security] [Bug 1188189] Change abandoned on cinder
	(master)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20140812204741.23877.27980.malone@wampee.canonical.com>

Change abandoned by Duncan Thomas (duncan.thomas at gmail.com) on branch: master
Review: https://review.openstack.org/77346
Reason: Abandoning change: No update for more than 14 days

-- 
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 1278843 at bugs.launchpad.net  Mon Aug 11 15:11:47 2014
From: 1278843 at bugs.launchpad.net (Adam Young)
Date: Mon, 11 Aug 2014 15:11:47 -0000
Subject: [Openstack-security] [Bug 1278843] Re: Neutron doesn't report using
	a stale CA certificate
References: <20140211121101.2015.95668.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140811151147.28300.44275.launchpad@chaenomeles.canonical.com>

** Also affects: keystonemiddleware
   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/1278843

Title:
  Neutron doesn't report using a stale CA certificate

Status in OpenStack Identity  (Keystone) Middleware:
  New
Status in OpenStack Neutron (virtual network service):
  Confirmed

Bug description:
  It seems that when the CA certificate cashed locally by Neutron in
  /var/lib/neutron/keystone-signing/ is stale (does not match the
  current CA cert used by keystone), it is not possible to start a new
  instance. This is  understandable. However, the stacktrace error you
  get while trying to start as instance in such a situation is a hugely
  misleading:

  "ERROR: Error: unsupported operand type(s) for +: 'NoneType' and
  'str'"

  It's rather tricky to debug the issue.

  To reproduce just redo the pki-setup for keystone on a deployed and
  otherwise healthy openstack cluster. This will create a new CA cert
  for keystone, however neutron-server will be completely oblivious to
  this fact and will still insist on using it's local copy of the
  cacert.

  I'm running Havana on rhel6.4

  ----------
  /var/log/nova/compute.log  on the compute node when trying to start a vm

  OpenStack (nova:4668) ERROR: Instance failed network setup after 1 attempt(s)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager Traceback (most recent call last):
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1238, in _allocate_network_async
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     dhcp_options=dhcp_options)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/api.py", line 49, in wrapper
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     res = f(self, context, *args, **kwargs)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 358, in allocate_for_instance
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     LOG.exception(msg, port_id)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 323, in allocate_for_instance
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     port_req_body)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 392, in _populate_neutron_extension_values
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     self._refresh_neutron_extensions_cache()
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 376, in _refresh_neutron_extensions_cache
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     extensions_list = neutron.list_extensions()['extensions']
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 108, in with_params
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     ret = self.function(instance, *args, **kwargs)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 286, in list_extensions
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     return self.get(self.extensions_path, params=_params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1183, in get
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     headers=headers, params=params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1168, in retry_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     headers=headers, params=params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1103, in do_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     resp, replybody = self.httpclient.do_request(action, method, body=body)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 188, in do_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     self.authenticate()
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 224, in authenticate
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     token_url = self.auth_url + "/tokens"
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager

  ----------------
  /var/log/neutron/server.log on the controller when trying to start a vm

  OpenStack (neutron:29274) DEBUG: Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-
  Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role
  OpenStack (neutron:29274) INFO: Starting new HTTP connection (1): openstack
  OpenStack (neutron:29274) DEBUG: received {u'_context_roles': [u'admin'], u'_context_read_deleted': u'no', u'_context_tenant_id': None, u'args': {u'agent_state': {u'agent_state': {u'topic': u'N/A', u'binary'
  : u'neutron-openvswitch-agent', u'host': u'node001', u'agent_type': u'Open vSwitch agent', u'configurations': {u'tunnel_types': [], u'tunneling_ip': u'', u'bridge_mappings': {u'ph-eth0': u'br0'}, u'l2_popula
  tion': False, u'devices': 0}}}, u'time': u'2014-02-11T12:06:32.434133'}, u'namespace': None, u'_unique_id': u'ae5c6b608f6547f7b630dace2c5411bd', u'_context_is_admin': True, u'version': u'1.0', u'_context_pro
  ject_id': None, u'_context_timestamp': u'2014-02-11 12:00:14.386557', u'_context_user_id': None, u'method': u'report_state'}
  OpenStack (neutron:29274) DEBUG: unpacked context: {'user_id': None, 'roles': [u'admin'], 'tenant_id': None, 'is_admin': True, 'timestamp': u'2014-02-11 12:00:14.386557', 'project_id': None, 'read_deleted': u'no'}
  OpenStack (neutron:29274) DEBUG: "GET /v2.0/tokens/revoked HTTP/1.1" 200 1234
  OpenStack (neutron:29274) WARNING: Verify error: Command 'openssl' returned non-zero exit status 4
  OpenStack (neutron:29274) DEBUG: Token validation failure.
  Traceback (most recent call last):
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 808, in _validate_user_token
      verified = self.verify_signed_token(user_token)
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1165, in verify_signed_token
      if self.is_signed_token_revoked(signed_text):
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1127, in is_signed_token_revoked
      revocation_list = self.token_revocation_list
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1217, in token_revocation_list
      self.token_revocation_list = self.fetch_revocation_list()
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1247, in fetch_revocation_list
      return self.cms_verify(data['signed'])
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1160, in cms_verify
      raise err
  CalledProcessError: Command 'openssl' returned non-zero exit status 4
  OpenStack (neutron:29274) DEBUG: Marking token c5e1c4ed4d0ab0db8bbaffbb33e139ba as unauthorized in memcache
  OpenStack (neutron:29274) WARNING: Authorization failed for token c5e1c4ed4d0ab0db8bbaffbb33e139ba
  OpenStack (neutron:29274) INFO: Invalid user token - rejecting request

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



From 1278843 at bugs.launchpad.net  Mon Aug 11 15:23:40 2014
From: 1278843 at bugs.launchpad.net (Adam Young)
Date: Mon, 11 Aug 2014 15:23:40 -0000
Subject: [Openstack-security] [Bug 1278843] Re: Neutron doesn't report using
	a stale CA certificate
References: <20140211121101.2015.95668.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140811152340.17853.49955.malone@soybean.canonical.com>

Not a security issue:  it defaults to denial, which is acceptable.  The
problem is in auth_token middleware, which is currently hosted in
python-keystoneclient, but we are moving the services over to using the
version in the keystonemiddleware repo.

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

Title:
  Neutron doesn't report using a stale CA certificate

Status in OpenStack Identity  (Keystone) Middleware:
  New
Status in OpenStack Neutron (virtual network service):
  Confirmed

Bug description:
  It seems that when the CA certificate cashed locally by Neutron in
  /var/lib/neutron/keystone-signing/ is stale (does not match the
  current CA cert used by keystone), it is not possible to start a new
  instance. This is  understandable. However, the stacktrace error you
  get while trying to start as instance in such a situation is a hugely
  misleading:

  "ERROR: Error: unsupported operand type(s) for +: 'NoneType' and
  'str'"

  It's rather tricky to debug the issue.

  To reproduce just redo the pki-setup for keystone on a deployed and
  otherwise healthy openstack cluster. This will create a new CA cert
  for keystone, however neutron-server will be completely oblivious to
  this fact and will still insist on using it's local copy of the
  cacert.

  I'm running Havana on rhel6.4

  ----------
  /var/log/nova/compute.log  on the compute node when trying to start a vm

  OpenStack (nova:4668) ERROR: Instance failed network setup after 1 attempt(s)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager Traceback (most recent call last):
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1238, in _allocate_network_async
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     dhcp_options=dhcp_options)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/api.py", line 49, in wrapper
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     res = f(self, context, *args, **kwargs)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 358, in allocate_for_instance
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     LOG.exception(msg, port_id)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 323, in allocate_for_instance
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     port_req_body)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 392, in _populate_neutron_extension_values
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     self._refresh_neutron_extensions_cache()
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 376, in _refresh_neutron_extensions_cache
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     extensions_list = neutron.list_extensions()['extensions']
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 108, in with_params
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     ret = self.function(instance, *args, **kwargs)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 286, in list_extensions
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     return self.get(self.extensions_path, params=_params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1183, in get
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     headers=headers, params=params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1168, in retry_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     headers=headers, params=params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1103, in do_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     resp, replybody = self.httpclient.do_request(action, method, body=body)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 188, in do_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     self.authenticate()
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 224, in authenticate
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     token_url = self.auth_url + "/tokens"
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager

  ----------------
  /var/log/neutron/server.log on the controller when trying to start a vm

  OpenStack (neutron:29274) DEBUG: Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-
  Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role
  OpenStack (neutron:29274) INFO: Starting new HTTP connection (1): openstack
  OpenStack (neutron:29274) DEBUG: received {u'_context_roles': [u'admin'], u'_context_read_deleted': u'no', u'_context_tenant_id': None, u'args': {u'agent_state': {u'agent_state': {u'topic': u'N/A', u'binary'
  : u'neutron-openvswitch-agent', u'host': u'node001', u'agent_type': u'Open vSwitch agent', u'configurations': {u'tunnel_types': [], u'tunneling_ip': u'', u'bridge_mappings': {u'ph-eth0': u'br0'}, u'l2_popula
  tion': False, u'devices': 0}}}, u'time': u'2014-02-11T12:06:32.434133'}, u'namespace': None, u'_unique_id': u'ae5c6b608f6547f7b630dace2c5411bd', u'_context_is_admin': True, u'version': u'1.0', u'_context_pro
  ject_id': None, u'_context_timestamp': u'2014-02-11 12:00:14.386557', u'_context_user_id': None, u'method': u'report_state'}
  OpenStack (neutron:29274) DEBUG: unpacked context: {'user_id': None, 'roles': [u'admin'], 'tenant_id': None, 'is_admin': True, 'timestamp': u'2014-02-11 12:00:14.386557', 'project_id': None, 'read_deleted': u'no'}
  OpenStack (neutron:29274) DEBUG: "GET /v2.0/tokens/revoked HTTP/1.1" 200 1234
  OpenStack (neutron:29274) WARNING: Verify error: Command 'openssl' returned non-zero exit status 4
  OpenStack (neutron:29274) DEBUG: Token validation failure.
  Traceback (most recent call last):
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 808, in _validate_user_token
      verified = self.verify_signed_token(user_token)
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1165, in verify_signed_token
      if self.is_signed_token_revoked(signed_text):
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1127, in is_signed_token_revoked
      revocation_list = self.token_revocation_list
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1217, in token_revocation_list
      self.token_revocation_list = self.fetch_revocation_list()
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1247, in fetch_revocation_list
      return self.cms_verify(data['signed'])
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1160, in cms_verify
      raise err
  CalledProcessError: Command 'openssl' returned non-zero exit status 4
  OpenStack (neutron:29274) DEBUG: Marking token c5e1c4ed4d0ab0db8bbaffbb33e139ba as unauthorized in memcache
  OpenStack (neutron:29274) WARNING: Authorization failed for token c5e1c4ed4d0ab0db8bbaffbb33e139ba
  OpenStack (neutron:29274) INFO: Invalid user token - rejecting request

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



From 1337349 at bugs.launchpad.net  Mon Aug 11 16:31:32 2014
From: 1337349 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 11 Aug 2014 16:31:32 -0000
Subject: [Openstack-security] [Bug 1337349] Re: Nova qemu hypervisor host
 smbios serial number is leaked to guest
References: <20140703142824.27562.82896.malonedeb@gac.canonical.com>
Message-ID: <20140811163132.23877.92904.malone@wampee.canonical.com>

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

** Changed in: nova
     Assignee: (unassigned) => Daniel Berrange (berrange)

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

Title:
  Nova qemu hypervisor host smbios serial number is leaked to guest

Status in OpenStack Compute (Nova):
  In Progress
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  Erwan Velu from eNovance reported a vulnerability in OpenStack Nova.

  The hypervisor is passing host system uuid (-smbios version) to guests, and this happen to be a critical info leak.
  The defect have been pinpointed to:
   https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3054

  From a simple virtual machine, this may allow numerous info leak like:
      Allow compute hardware enumeration from guests
      Deduce service tag and get all hardware configuration
      Ability to know if two instances are on the same compute

  Dell hardware is particulary impacted as :
      - the uuid encodes the service tag
      - the service tag can be used on support site to determine:
      - detailled hardware configuration
      - date & country where the hw was shipped
      - date & type of support contract
      - amount of servers bought during this shipment

  If there is no use case for this, we should scrambled that piece of
  information.

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



From aurlapova at mirantis.com  Tue Aug 12 18:54:09 2014
From: aurlapova at mirantis.com (Nastya Urlapova)
Date: Tue, 12 Aug 2014 18:54:09 -0000
Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment
References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com>
Message-ID: <20140812185410.28536.6349.launchpad@chaenomeles.canonical.com>

** Information type changed from Private Security to Public

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

** Changed in: fuel
     Assignee: (unassigned) => Fuel Library Team (fuel-library)

** Changed in: fuel
    Milestone: None => 6.0

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

Title:
  Better conductor deployment

Status in Fuel: OpenStack installer that works:
  New

Bug description:
  Here is several issues with how MOS deploys conductor.

  1 By default all deployment variants assume deployments with conductor enabled. But this requires  to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps  sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor.
  One of the reason for creating  conductor service was to provide security level for nova.  

  2 by default it not possible to disable conductor using MOS tools.
  Customers who prefer performance over security should have  this
  options. Conductor can introduce significant delay in all actions
  required database access.

  
  This two enchantments are tied together.

  The following actions are required to  disable usage of conductor.

  On all compute nodes:

  1 make use mysql port is accessible from compute nodes and all necessary grange are present.
  2 add into nova.conf 
  [DEFAULT]
  sql_connection = mysql://nova:password at mysqlhost/nova_db

  [conductor]
  use_local=true

   3 service openstack-nova-compute restart

  4 optionally stop conductor process on controllers

  Monitoring tuning may be required..

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



From ralekseenkov at mirantis.com  Wed Aug 13 06:12:35 2014
From: ralekseenkov at mirantis.com (Roman Alekseenkov)
Date: Wed, 13 Aug 2014 06:12:35 -0000
Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment
References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com>
Message-ID: <20140813061236.28868.58834.launchpad@chaenomeles.canonical.com>

** Tags added: customer-found

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

Title:
  Better conductor deployment

Status in Fuel: OpenStack installer that works:
  New

Bug description:
  Here is several issues with how MOS deploys conductor.

  1 By default all deployment variants assume deployments with conductor enabled. But this requires  to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps  sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor.
  One of the reason for creating  conductor service was to provide security level for nova.  

  2 by default it not possible to disable conductor using MOS tools.
  Customers who prefer performance over security should have  this
  options. Conductor can introduce significant delay in all actions
  required database access.

  
  This two enchantments are tied together.

  The following actions are required to  disable usage of conductor.

  On all compute nodes:

  1 make use mysql port is accessible from compute nodes and all necessary grange are present.
  2 add into nova.conf 
  [DEFAULT]
  sql_connection = mysql://nova:password at mysqlhost/nova_db

  [conductor]
  use_local=true

   3 service openstack-nova-compute restart

  4 optionally stop conductor process on controllers

  Monitoring tuning may be required..

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



From 1278843 at bugs.launchpad.net  Wed Aug 13 09:03:35 2014
From: 1278843 at bugs.launchpad.net (Robert Clark)
Date: Wed, 13 Aug 2014 09:03:35 -0000
Subject: [Openstack-security] [Bug 1278843] Re: Neutron doesn't report using
	a stale CA certificate
References: <20140211121101.2015.95668.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140813090335.5297.65983.malone@gac.canonical.com>

+1 Adam, fails closed.

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

Title:
  Neutron doesn't report using a stale CA certificate

Status in OpenStack Identity  (Keystone) Middleware:
  New
Status in OpenStack Neutron (virtual network service):
  Confirmed

Bug description:
  It seems that when the CA certificate cashed locally by Neutron in
  /var/lib/neutron/keystone-signing/ is stale (does not match the
  current CA cert used by keystone), it is not possible to start a new
  instance. This is  understandable. However, the stacktrace error you
  get while trying to start as instance in such a situation is a hugely
  misleading:

  "ERROR: Error: unsupported operand type(s) for +: 'NoneType' and
  'str'"

  It's rather tricky to debug the issue.

  To reproduce just redo the pki-setup for keystone on a deployed and
  otherwise healthy openstack cluster. This will create a new CA cert
  for keystone, however neutron-server will be completely oblivious to
  this fact and will still insist on using it's local copy of the
  cacert.

  I'm running Havana on rhel6.4

  ----------
  /var/log/nova/compute.log  on the compute node when trying to start a vm

  OpenStack (nova:4668) ERROR: Instance failed network setup after 1 attempt(s)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager Traceback (most recent call last):
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1238, in _allocate_network_async
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     dhcp_options=dhcp_options)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/api.py", line 49, in wrapper
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     res = f(self, context, *args, **kwargs)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 358, in allocate_for_instance
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     LOG.exception(msg, port_id)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 323, in allocate_for_instance
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     port_req_body)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 392, in _populate_neutron_extension_values
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     self._refresh_neutron_extensions_cache()
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 376, in _refresh_neutron_extensions_cache
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     extensions_list = neutron.list_extensions()['extensions']
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 108, in with_params
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     ret = self.function(instance, *args, **kwargs)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 286, in list_extensions
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     return self.get(self.extensions_path, params=_params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1183, in get
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     headers=headers, params=params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1168, in retry_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     headers=headers, params=params)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/v2_0/client.py", line 1103, in do_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     resp, replybody = self.httpclient.do_request(action, method, body=body)
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 188, in do_request
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     self.authenticate()
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager   File "/usr/lib/python2.6/site-packages/neutronclient/client.py", line 224, in authenticate
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager     token_url = self.auth_url + "/tokens"
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
  2014-02-11 13:02:38.429 4668 TRACE nova.compute.manager

  ----------------
  /var/log/neutron/server.log on the controller when trying to start a vm

  OpenStack (neutron:29274) DEBUG: Removing headers from request environment: X-Identity-Status,X-Domain-Id,X-Domain-Name,X-Project-Id,X-Project-Name,X-Project-Domain-Id,X-Project-Domain-Name,X-User-Id,X-User-
  Name,X-User-Domain-Id,X-User-Domain-Name,X-Roles,X-Service-Catalog,X-User,X-Tenant-Id,X-Tenant-Name,X-Tenant,X-Role
  OpenStack (neutron:29274) INFO: Starting new HTTP connection (1): openstack
  OpenStack (neutron:29274) DEBUG: received {u'_context_roles': [u'admin'], u'_context_read_deleted': u'no', u'_context_tenant_id': None, u'args': {u'agent_state': {u'agent_state': {u'topic': u'N/A', u'binary'
  : u'neutron-openvswitch-agent', u'host': u'node001', u'agent_type': u'Open vSwitch agent', u'configurations': {u'tunnel_types': [], u'tunneling_ip': u'', u'bridge_mappings': {u'ph-eth0': u'br0'}, u'l2_popula
  tion': False, u'devices': 0}}}, u'time': u'2014-02-11T12:06:32.434133'}, u'namespace': None, u'_unique_id': u'ae5c6b608f6547f7b630dace2c5411bd', u'_context_is_admin': True, u'version': u'1.0', u'_context_pro
  ject_id': None, u'_context_timestamp': u'2014-02-11 12:00:14.386557', u'_context_user_id': None, u'method': u'report_state'}
  OpenStack (neutron:29274) DEBUG: unpacked context: {'user_id': None, 'roles': [u'admin'], 'tenant_id': None, 'is_admin': True, 'timestamp': u'2014-02-11 12:00:14.386557', 'project_id': None, 'read_deleted': u'no'}
  OpenStack (neutron:29274) DEBUG: "GET /v2.0/tokens/revoked HTTP/1.1" 200 1234
  OpenStack (neutron:29274) WARNING: Verify error: Command 'openssl' returned non-zero exit status 4
  OpenStack (neutron:29274) DEBUG: Token validation failure.
  Traceback (most recent call last):
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 808, in _validate_user_token
      verified = self.verify_signed_token(user_token)
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1165, in verify_signed_token
      if self.is_signed_token_revoked(signed_text):
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1127, in is_signed_token_revoked
      revocation_list = self.token_revocation_list
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1217, in token_revocation_list
      self.token_revocation_list = self.fetch_revocation_list()
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1247, in fetch_revocation_list
      return self.cms_verify(data['signed'])
    File "/usr/lib/python2.6/site-packages/keystoneclient/middleware/auth_token.py", line 1160, in cms_verify
      raise err
  CalledProcessError: Command 'openssl' returned non-zero exit status 4
  OpenStack (neutron:29274) DEBUG: Marking token c5e1c4ed4d0ab0db8bbaffbb33e139ba as unauthorized in memcache
  OpenStack (neutron:29274) WARNING: Authorization failed for token c5e1c4ed4d0ab0db8bbaffbb33e139ba
  OpenStack (neutron:29274) INFO: Invalid user token - rejecting request

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



From davanum at gmail.com  Wed Aug 13 12:01:21 2014
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Wed, 13 Aug 2014 12:01:21 -0000
Subject: [Openstack-security] [Bug 1321785] Re: RFE: block_device_info dict
 should have a password key rather than clear password
References: <20140521143043.29900.37913.malonedeb@wampee.canonical.com>
Message-ID: <20140813120124.17148.96811.launchpad@soybean.canonical.com>

** Changed in: nova
       Status: New => Confirmed

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

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

Title:
  RFE: block_device_info dict should have a password key rather than
  clear password

Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Compute (nova) icehouse series:
  Invalid

Bug description:
  See bug 1319943 and the related patch
  https://review.openstack.org/#/c/93787/ for details, but right now the
  block_device_info dict passed around in the nova virt driver can
  contain a clear text password for the auth_password key.

  That bug and patch are masking the password when logged in the
  immediate known locations, but this could continue to crop up so we
  should change the design such that the block_device_info dict doesn't
  contain the password but rather a key to a store that nova can
  retrieve the password for use.

  Comment from Daniel Berrange in the patch above:

  "Long term I think we need to figure out a way to remove the passwords
  from any data dicts we pass around. Ideally the block device info
  would merely contain something like a UUID to identify a password,
  which Nova could use to fetch the actual password from a secure
  password manager service at time of use. Thus we wouldn't have to
  worry about random objects/dicts containing actual passwords.
  Obviously this isn't something we can do now, but could you file an
  RFE to address this from a design POV, because masking passwords at
  time of logging call is not really a viable long term strategy IMHO."

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



From nkinder at redhat.com  Wed Aug 13 13:48:04 2014
From: nkinder at redhat.com (Nathan Kinder)
Date: Wed, 13 Aug 2014 06:48:04 -0700
Subject: [Openstack-security] IMPORTANT: OpenStack Security Notes -
 Repository Migration
In-Reply-To: <53D1B8DB.9010608@redhat.com>
References: <53D1B8DB.9010608@redhat.com>
Message-ID: <53EB6C94.6020009@redhat.com>

Apologies for the top-post...

This repository migration is now complete.  Security Notes are now kept
in the security-doc repository:

    https://git.openstack.org/cgit/openstack/security-doc/

The Security Note Process page [1] has been updated to reflect this change.

All new Security Note reviews should be proposed against the new
repository.  The old repository will be moved to openstack-attic soon [2].

Thanks,
-NGK

[1] https://wiki.openstack.org/wiki/Security/Security_Note_Process
[2] https://review.openstack.org/113614

On 07/24/2014 06:54 PM, Nathan Kinder wrote:
> Hi,
> 
> I am in the process of migrating the openstack-security-notes
> repository[1] that we use for OSSNs to the security-doc repository[2]
> where the Security Guide is kept.  This has been discussed numerous
> times in our weekly meetings, so hopefully the effort is not a surprise
> to anyone.  The main reasons for the move are:
> 
> - Automatically publishing OSSNs into an appendix of the Security Guide
> should be much easier.
> 
> - We can hook into the existing documentation gate tests more easily
> since they are already used by the new repository.
> 
> - IRC channel notifications are already set up for the new repository.
> 
> During this cut-over period, I would like to halt the creation of any
> new OSSN patches.  This should be a short window.  I would like to wrap
> up the existing notes that are in-progress:
> 
>   OSSN-0020 - https://review.openstack.org/106837
>   OSSN-0021 - https://review.openstack.org/107426
>   OSSN-0022 - https://review.openstack.org/108349
> 
> After these are merged, I will sync them into the patch I've prepared to
> switch repositories[3].  I will then clear out the old repository and
> get it removed to prevent confusion.  We will start using the new
> repository for OSSN-0023.
> 
> So, if you're working on one of the OSSNs that's in-progress, let's
> hurry and get it wrapped up! :)  If you're not an author of one of these
> in-progress notes, please review them to help get them finished.
> 
> Please let me know if you have any questions or concerns!
> 
> Thanks,
> -NGK
> 
> [1] https://git.openstack.org/cgit/openstack/openstack-security-notes/
> [2] https://git.openstack.org/cgit/openstack/security-doc/
> [3] https://review.openstack.org/109464
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



From gmurphy at redhat.com  Thu Aug 14 06:23:05 2014
From: gmurphy at redhat.com (Grant Murphy)
Date: Thu, 14 Aug 2014 16:23:05 +1000
Subject: [Openstack-security] [gmurphy@redhat.com: Re: Why are we still
 seeing XSS flaws?]
Message-ID: <20140814062305.GC29256@lappy.bne.redhat.com>


Might help if I included the list on my reply..

----- Forwarded message from Grant Murphy <gmurphy at redhat.com> -----

Date: Thu, 14 Aug 2014 16:18:50 +1000
From: Grant Murphy <gmurphy at redhat.com>
To: Paul McMillan <paul.mcmillan at nebula.com>
Subject: Re: [Openstack-security]  Why are we still seeing XSS flaws?
User-Agent: Mutt/1.5.23 (2014-03-12)

Hi Paul,

Thanks for a brilliant response. After spending a bit of time today
combing through the horizon code base I have to say you've hit the nail on
the head there. I put some of my notes up on an etherpad [1], they basically
backup the exact scenario you've described.

I'll raise this issue again at tonights OSSG meeting. I agree that in order
to fix this there will need to be an architectural overhaul. In the meantime
we can probably do a couple of things to try and drive down the technical
debt. Perhaps introducing some openstack-hacking rules that flag the types
of issues outlined in [1]?

1. https://etherpad.openstack.org/p/dashboard_xss_analysis

- Grant.


On Tue, Aug 12, 2014 at 08:30:02PM +0000, Paul McMillan wrote:
> Horizon uses the Django framework, which provides good escaping. The problem is, as Horizon has grown and changed, many contributors have been interested in solving their localized problem as fast as possible, which means that output sanitization has largely turned into an adhoc mismash of bandaids to fix each security issue as it is reported. At present, it is nearly impossible to reason about the safety of any particular string which gets rendered out, and so new bugs get added regularly as inexpert contributors follow existing code without understanding the underlying reasoning.
> 
> The fundamental issue here is that Horizon has mixed HTML into the codebase, rather than keeping it all at the templating layer. This means that it's passing around strings which have been marked safe when they should not be, and the default response from new developers is "I don't know why I'm seeing escape codes, I'll just mark this as safe". We can fix the underlying issues by removing HTML generation from the code, and moving everything back to the template rendering system as it should have been in the first place. Once we've done this, we can add an automated test which rejects any patch which includes a call to mark_safe(), or similar techniques.
> 
> I'm familiar with the horizon code, I'm familiar with how to do it right (I'm a member of the Django security team). I've had conversations with Horizon contributors, conversations in patches, and conversations on many of these XSS bug tickets, about how to fix the problem at the architectural level. Unfortunately, I'm not able to undertake the fairly large architectural project to fix this all by myself. I'm happy to sit down (preferably in person) with Horizon contributors who explicitly have time to do the work, and carefully work through what needs to be fixed. I'm not willing to write a report detailing exactly where things are wrong, which will then be ignored because fixing architectural flaws is lower priority than all other dev work.
> 
> This seems like it might  be a good thing to plan to do for several days at a summit, but we'd need buyin from several people qualified to undertake the work. I think if we had several devs who know the horizon codebase, and a commitment to 2 or 3 days of focused hacking, we could fix the flow of this type of bug nearly permanently.
> 
> It's time to stop the bandaids.
> 
> -Paul
> 
> On Mon, Aug 4, 2014 at 10:44 PM, Grant Murphy <gmurphy at redhat.com> wrote:
> 
> > Hi,
> >
> > I've been trying to put together some historical information about the
> > security vulnerabilities that we are seeing in OpenStack [1]. The one thing
> > that I've noticed is that we don't seem to be learning from our mistakes.
> >
> > The particular example that I'd like to call out is XSS.  This is a
> > very well known problem with a simple solution. Most template
> > frameworks when used correctly will automatically escape input unless
> > autoescape is explicitly disabled. So why are we still seeing this class of
> > bug turn up in 2014?
> >
> > I'd like to propose that the OSSG does a review of horizon's current
> > strategy for mitigating this type of flaw and find a better way forward
> > for future releases. Is anybody able to help out with this?
> >
> > [1] http://openstack-security.info  (#wip)
> >
> > --
> > Grant
> >
> >
> > _______________________________________________
> > 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

-- 
Grant Murphy / Red Hat Product Security




----- End forwarded message -----

-- 
Grant Murphy / Red Hat Product Security

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140814/d6727d37/attachment.sig>

From maurice at leeflang.net  Thu Aug 14 09:19:08 2014
From: maurice at leeflang.net (Maurice Leeflang)
Date: Thu, 14 Aug 2014 09:19:08 -0000
Subject: [Openstack-security] [Bug 1252519] Re: Live migration failed
 because of file permission changed
References: <20131119003108.27374.76789.malonedeb@gac.canonical.com>
Message-ID: <20140814091908.23413.57474.malone@wampee.canonical.com>

I have the same problem. 
I am currently trying to isolate the cause to it. 

The first live migration of an instance works, but the second one (back to the first node) fails.
The ownership changed, but even manually as root I am not allowed to read the disk file.
Only when kvm closes the fd's on these files (when I suspend the instance, for example), the files can be read again. The files can still be read when the instance is resumed, even a live migration is possible again, then. The ownership after a resume is qemu again (not root), so I can understand why Barrow points that way.

It smells like some locking situation on the gluster side, but I am not able to pinpoint it to a configuration option or bug yet
I will do some more tests to see why (and how)  gluster is spoiling the fun. 
Please do not put the blame on some gluster bug or behaviour yet. 
The fact that the ownership of instance files on shared storage changes indicates that there is still a resize or something being done (post migration), which, IMHO, is not needed in the case of a live migration with de nova instances directory on shared storage for all compute nodes participating.

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

Title:
  Live migration failed because of file permission changed

Status in OpenStack Compute (Nova):
  Triaged

Bug description:
  Openstack : Havana
  OS : CentOS 6.4
  Shared storage with GlusterFS :  /var/lib/nova/instances mounted on glusterfs shared

  
  Instance start up fine on node01.  When live migration happen, it moved to node02 but failed with the following error

  2013-11-18 16:27:37.813 9837 ERROR nova.openstack.common.periodic_task [-] Error during ComputeManager.update_available_resource: Unexpected error while running command.
  Command: env LC_ALL=C LANG=C qemu-img info /var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk
  Exit code: 1
  Stdout: ''
  Stderr: "qemu-img: Could not open '/var/lib/nova/instances/aa1deb40-ae1d-45e4-a37e-7b0607df372f/disk'\n"
  2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task Traceback (most recent call last):
  2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task   File "/usr/lib/python2.6/site-packages/nova/openstack/common/periodic_task.py", line 180, in run_periodic_tasks
  2013-11-18 16:27:37.813 9837 TRACE nova.openstack.common.periodic_task     task(self, context)


  The problem is with the file ownership of "console.log" and "disk".
  Those file should be owned by user "qemu" and group "qemu" but after
  the migration, both files are owned by root

  
  drwxr-xr-x 2 nova nova       53 Nov 18 13:40 .
  drwxr-xr-x 6 nova nova      110 Nov 18 13:43 ..
  -rw-rw---- 1 root root     1546 Nov 18 13:43 console.log
  -rw-r--r-- 1 root root 12058624 Nov 18 13:42 disk
  -rw-r--r-- 1 nova nova     1569 Nov 18 13:42 libvirt.xml

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



From gerrit2 at review.openstack.org  Thu Aug 14 12:10:29 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 14 Aug 2014 12:10:29 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I7ba7dbd65e913a66efe35a1d6490a85bec8413da
Message-ID: <E1XHtrR-0008M7-JT@review.openstack.org>


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

Log:
commit 8c2c3aa4246f4085b6e31aa30aa847f06a4dcf69
Author: Daniel P. Berrange <berrange at redhat.com>
Date:   Mon Jul 28 15:15:44 2014 +0100

    libvirt: make sysinfo serial number configurable
    
    The 'serial' field in guest SMBIOS tables gets populated
    based on the libvirt reported UUID of the host hardware.
    The rationale is to allow correlation of guests running
    on the same host.
    
    Unfortunately some hardware vendors use a subset of the
    host UUID as a key for retrieving hardware support
    contract information without requiring any authentication.
    So exposing the host UUID to the guest is an information
    leak for those vendors. It is possible to override the
    use of SMBIOS data by libvirt in /etc/libvirt/libvirtd.conf
    by setting the 'host_uuid' parameter.
    
    As a way to reduce the configuration burden though, it is
    preferrable to use the /etc/machine-id UUID, instead of
    the host hardware UUID. The former is a recent standard
    for Linux distros introduced by systemd to provide a UUID
    that is unique per operating system install. This means
    that even containers will see a separate /etc/machine-id
    value. This /etc/machine-id can be expected to be widely
    available in current and future distros. If missing, it
    is still possible to fallback to the libvirt reported
    host UUID.
    
    The host UUID exposed could theoretically be leveraged
    by a cloud user to get an approximate count of the number
    of unique hosts available to them in the cloud by launching
    many short lived VMs. Administrators concerned about this
    may wish to disable reporting of any sysinfo serial field
    at all.
    
    Introduce a 'sysinfo_serial' config parameter to the libvirt
    driver to control behaviour, accepting values:
    
     - 'auto' - try /etc/machine-id, fallback to
       libvirt reported host UUID (new default)
     - 'hardware' - always use libvirt host UUID (old default)
     - 'os' - always use /etc/machine-id, error if missing
     - 'none' - do not report any value to the guest
    
    DocImpact
    SecurityImpact
    Closes-bug: #1337349
    Change-Id: I7ba7dbd65e913a66efe35a1d6490a85bec8413da




From rpodolyaka at mirantis.com  Thu Aug 14 14:18:31 2014
From: rpodolyaka at mirantis.com (Roman Podoliaka)
Date: Thu, 14 Aug 2014 14:18:31 -0000
Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment
References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com>
Message-ID: <20140814141833.5198.83656.launchpad@gac.canonical.com>

** Changed in: fuel
       Status: New => Triaged

** Changed in: fuel
   Importance: Medium => Low

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

Title:
  Better conductor deployment

Status in Fuel: OpenStack installer that works:
  Triaged
Status in Mirantis OpenStack:
  Triaged

Bug description:
  Here is several issues with how MOS deploys conductor.

  1 By default all deployment variants assume deployments with conductor enabled. But this requires  to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps  sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor.
  One of the reason for creating  conductor service was to provide security level for nova.  

  2 by default it not possible to disable conductor using MOS tools.
  Customers who prefer performance over security should have  this
  options. Conductor can introduce significant delay in all actions
  required database access.

  
  This two enchantments are tied together.

  The following actions are required to  disable usage of conductor.

  On all compute nodes:

  1 make use mysql port is accessible from compute nodes and all necessary grange are present.
  2 add into nova.conf 
  [DEFAULT]
  sql_connection = mysql://nova:password at mysqlhost/nova_db

  [conductor]
  use_local=true

   3 service openstack-nova-compute restart

  4 optionally stop conductor process on controllers

  Monitoring tuning may be required..

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



From gerrit2 at review.openstack.org  Thu Aug 14 20:55:37 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 14 Aug 2014 20:55:37 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XI23d-0004ZN-0l@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 bf81ea8d3be5a0da16e3a4decb36bc3fe470301d
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Wed Aug 13 12:52:52 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Thu Aug 14 22:09:47 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 14 Aug 2014 22:09:47 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XI3DP-0002Xf-9B@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 0cc1482b0f874d78399dfb0c0b06eebf0b7473c4
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Wed Aug 13 12:52:52 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From mdurnosvistov at mirantis.com  Thu Aug 14 12:59:47 2014
From: mdurnosvistov at mirantis.com (Mikhail Durnosvistov)
Date: Thu, 14 Aug 2014 12:59:47 -0000
Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment
References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com>
Message-ID: <20140814125948.28676.1701.launchpad@chaenomeles.canonical.com>

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

** Changed in: mos
       Status: New => Triaged

** Changed in: mos
   Importance: Undecided => Low

** Changed in: mos
     Assignee: (unassigned) => MOS Nova (mos-nova)

** Changed in: mos
    Milestone: None => 6.0

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

Title:
  Better conductor deployment

Status in Fuel: OpenStack installer that works:
  New
Status in Mirantis OpenStack:
  Triaged

Bug description:
  Here is several issues with how MOS deploys conductor.

  1 By default all deployment variants assume deployments with conductor enabled. But this requires  to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps  sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor.
  One of the reason for creating  conductor service was to provide security level for nova.  

  2 by default it not possible to disable conductor using MOS tools.
  Customers who prefer performance over security should have  this
  options. Conductor can introduce significant delay in all actions
  required database access.

  
  This two enchantments are tied together.

  The following actions are required to  disable usage of conductor.

  On all compute nodes:

  1 make use mysql port is accessible from compute nodes and all necessary grange are present.
  2 add into nova.conf 
  [DEFAULT]
  sql_connection = mysql://nova:password at mysqlhost/nova_db

  [conductor]
  use_local=true

   3 service openstack-nova-compute restart

  4 optionally stop conductor process on controllers

  Monitoring tuning may be required..

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



From gerrit2 at review.openstack.org  Fri Aug 15 12:20:31 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 15 Aug 2014 12:20:31 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I7ba7dbd65e913a66efe35a1d6490a85bec8413da
Message-ID: <E1XIGUh-00014O-EH@review.openstack.org>


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

Log:
commit de22de7f58b45dfe4c3392946be3476b2cc20bb3
Author: Daniel P. Berrange <berrange at redhat.com>
Date:   Mon Jul 28 15:15:44 2014 +0100

    libvirt: make sysinfo serial number configurable
    
    The 'serial' field in guest SMBIOS tables gets populated
    based on the libvirt reported UUID of the host hardware.
    The rationale is to allow correlation of guests running
    on the same host.
    
    Unfortunately some hardware vendors use a subset of the
    host UUID as a key for retrieving hardware support
    contract information without requiring any authentication.
    So exposing the host UUID to the guest is an information
    leak for those vendors. It is possible to override the
    use of SMBIOS data by libvirt in /etc/libvirt/libvirtd.conf
    by setting the 'host_uuid' parameter.
    
    As a way to reduce the configuration burden though, it is
    preferrable to use the /etc/machine-id UUID, instead of
    the host hardware UUID. The former is a recent standard
    for Linux distros introduced by systemd to provide a UUID
    that is unique per operating system install. This means
    that even containers will see a separate /etc/machine-id
    value. This /etc/machine-id can be expected to be widely
    available in current and future distros. If missing, it
    is still possible to fallback to the libvirt reported
    host UUID.
    
    The host UUID exposed could theoretically be leveraged
    by a cloud user to get an approximate count of the number
    of unique hosts available to them in the cloud by launching
    many short lived VMs. Administrators concerned about this
    may wish to disable reporting of any sysinfo serial field
    at all.
    
    Introduce a 'sysinfo_serial' config parameter to the libvirt
    driver to control behaviour, accepting values:
    
     - 'auto' - try /etc/machine-id, fallback to
       libvirt reported host UUID (new default)
     - 'hardware' - always use libvirt host UUID (old default)
     - 'os' - always use /etc/machine-id, error if missing
     - 'none' - do not report any value to the guest
    
    DocImpact
    SecurityImpact
    Closes-bug: #1337349
    Change-Id: I7ba7dbd65e913a66efe35a1d6490a85bec8413da




From gerrit2 at review.openstack.org  Fri Aug 15 12:26:34 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 15 Aug 2014 12:26:34 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I7ba7dbd65e913a66efe35a1d6490a85bec8413da
Message-ID: <E1XIGaY-0001LA-AA@review.openstack.org>


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

Log:
commit 9a947b53cf45fba0e86612562ca775263c0d5008
Author: Daniel P. Berrange <berrange at redhat.com>
Date:   Mon Jul 28 15:15:44 2014 +0100

    libvirt: make sysinfo serial number configurable
    
    The 'serial' field in guest SMBIOS tables gets populated
    based on the libvirt reported UUID of the host hardware.
    The rationale is to allow correlation of guests running
    on the same host.
    
    Unfortunately some hardware vendors use a subset of the
    host UUID as a key for retrieving hardware support
    contract information without requiring any authentication.
    So exposing the host UUID to the guest is an information
    leak for those vendors. It is possible to override the
    use of SMBIOS data by libvirt in /etc/libvirt/libvirtd.conf
    by setting the 'host_uuid' parameter.
    
    As a way to reduce the configuration burden though, it is
    preferrable to use the /etc/machine-id UUID, instead of
    the host hardware UUID. The former is a recent standard
    for Linux distros introduced by systemd to provide a UUID
    that is unique per operating system install. This means
    that even containers will see a separate /etc/machine-id
    value. This /etc/machine-id can be expected to be widely
    available in current and future distros. If missing, it
    is still possible to fallback to the libvirt reported
    host UUID.
    
    The host UUID exposed could theoretically be leveraged
    by a cloud user to get an approximate count of the number
    of unique hosts available to them in the cloud by launching
    many short lived VMs. Administrators concerned about this
    may wish to disable reporting of any sysinfo serial field
    at all.
    
    Introduce a 'sysinfo_serial' config parameter to the libvirt
    driver to control behaviour, accepting values:
    
     - 'auto' - try /etc/machine-id, fallback to
       libvirt reported host UUID (new default)
     - 'hardware' - always use libvirt host UUID (old default)
     - 'os' - always use /etc/machine-id, error if missing
     - 'none' - do not report any value to the guest
    
    DocImpact
    SecurityImpact
    Closes-bug: #1337349
    Change-Id: I7ba7dbd65e913a66efe35a1d6490a85bec8413da




From gerrit2 at review.openstack.org  Fri Aug 15 13:18:52 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 15 Aug 2014 13:18:52 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XIHPA-0004kO-W8@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 77e808c84d4aeabfd137cc84906e12fb9cc257d9
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Wed Aug 13 12:52:52 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From jamie.finnigan at hp.com  Fri Aug 15 14:31:26 2014
From: jamie.finnigan at hp.com (Finnigan, Jamie)
Date: Fri, 15 Aug 2014 14:31:26 +0000
Subject: [Openstack-security] Bandit status and next-steps
Message-ID: <D01367CB.1716A%jamie.finnigan@hp.com>

Hi all – as promised in the IRC meeting this week, here’s an update on Bandit.

For those of you who weren’t at the OSSG mid-cycle meetup, Bandit provides a framework for performing analysis against Python source code, utilizing the ast module from the Python standard library.  It was created with security testing in mind and is intended to provide a framework that allows tests to be defined and run against Python source code.  In some cases it may be essentially a glorified grep, but it others it may allow us to write smarter tests that give us more accurate results.  Bandit currently runs as a standalone tool, but it may eventually be integrated into the OpenStack CI gate tests.

Bandit is up on GitHub at https://github.com/chair6/bandit.  Yesterday I updated the README to provide a little more explanation as to how Bandit works, and some basic guidance as to how writing tests might be tackled.

It would be great to get more people looking at, using, and contributing to this tool.  One particular area of focus would be around the set of tests that are included:
 - Look at hacking-based tests written during the OSSG mid-cycle and port into Bandit tests.
 - Consider other recent OpenStack vulnerabilities or common Python security anti-patterns and write new Bandit tests to detect those.

We’ll also be looking at ways to improve the Bandit framework and make it simpler to write tests, so feel free to propose changes or let me know any issues you run into.

Thanks,
Jamie




From gerrit2 at review.openstack.org  Fri Aug 15 15:47:09 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 15 Aug 2014 15:47:09 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XIJif-0002Rd-TO@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 7453c344214664cfec75bc8494b755914863e5c8
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Wed Aug 13 12:52:52 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Fri Aug 15 17:27:19 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 15 Aug 2014 17:27:19 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XILHb-000402-Bx@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 3e29f546365ed298b853d311718dc12212d454fa
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Wed Aug 13 12:52:52 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Fri Aug 15 19:27:13 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 15 Aug 2014 19:27:13 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XIN9d-0005AC-Fn@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 3d4f5830876965cf76928ec7c7ef2b59eb6a69bc
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Wed Aug 13 12:52:52 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Fri Aug 15 20:37:15 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 15 Aug 2014 20:37:15 +0000
Subject: [Openstack-security] [openstack/keystonemiddleware] SecurityImpact
 review request change I24cb09edd9a6c9e99e48042a623c7818321f2ead
Message-ID: <E1XIOFP-0002Ht-36@review.openstack.org>


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

Log:
commit 62465a186ca383aa5193e164b6f69654c5b29ec3
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:13:59 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were being check for format and hashed
    
    Closes-Bug: 1355125
    
    
    SecurityImpact
    
    Change-Id: I24cb09edd9a6c9e99e48042a623c7818321f2ead




From gerrit2 at review.openstack.org  Fri Aug 15 20:43:50 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 15 Aug 2014 20:43:50 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iefedde7f168e2ff1870905041fa95301934452e5
Message-ID: <E1XIOLm-0002kz-20@review.openstack.org>


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

Log:
commit 8d3872172bbdef0dce6df6c72f1e37ac042626c6
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:37:32 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were being check for format and hashed
    
    Closes-Bug: 1355125
    
    SecurityImpact
    
    Change-Id: Iefedde7f168e2ff1870905041fa95301934452e5




From gary.w.smith at hp.com  Fri Aug 15 15:49:40 2014
From: gary.w.smith at hp.com (Gary W. Smith)
Date: Fri, 15 Aug 2014 15:49:40 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20140815154942.28269.84541.launchpad@chaenomeles.canonical.com>

** Tags added: security

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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From 1355509 at bugs.launchpad.net  Fri Aug 15 16:47:41 2014
From: 1355509 at bugs.launchpad.net (Dmitry Mescheryakov)
Date: Fri, 15 Aug 2014 16:47:41 -0000
Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment
References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com>
Message-ID: <20140815164742.28269.31189.malone@chaenomeles.canonical.com>

This task requires change only in Nova deployment, no need to change
anything in Nova code. So I am removing MOS as an affected project.

** No longer affects: mos

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

Title:
  Better conductor deployment

Status in Fuel: OpenStack installer that works:
  Triaged

Bug description:
  Here is several issues with how MOS deploys conductor.

  1 By default all deployment variants assume deployments with conductor enabled. But this requires  to remove sql_connection option in nova.conf on compute nodes. MOS does not do this. it keeps  sql_connection option in nova.conf on compute nodes while all compute services are configured to use conductor.
  One of the reason for creating  conductor service was to provide security level for nova.  

  2 by default it not possible to disable conductor using MOS tools.
  Customers who prefer performance over security should have  this
  options. Conductor can introduce significant delay in all actions
  required database access.

  
  This two enchantments are tied together.

  The following actions are required to  disable usage of conductor.

  On all compute nodes:

  1 make use mysql port is accessible from compute nodes and all necessary grange are present.
  2 add into nova.conf 
  [DEFAULT]
  sql_connection = mysql://nova:password at mysqlhost/nova_db

  [conductor]
  use_local=true

   3 service openstack-nova-compute restart

  4 optionally stop conductor process on controllers

  Monitoring tuning may be required..

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



From 1355125 at bugs.launchpad.net  Fri Aug 15 20:20:25 2014
From: 1355125 at bugs.launchpad.net (Dolph Mathews)
Date: Fri, 15 Aug 2014 20:20:25 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20140815202025.23603.98718.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/1355125

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in OpenStack Identity (Keystone):
  Triaged
Status in OpenStack Identity  (Keystone) Middleware:
  In Progress

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

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



From 1355125 at bugs.launchpad.net  Fri Aug 15 20:32:43 2014
From: 1355125 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 15 Aug 2014 20:32:43 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20140815203245.4835.21381.launchpad@gac.canonical.com>

** Changed in: keystonemiddleware
     Assignee: Morgan Fainberg (mdrnstm) => Adam Young (ayoung)

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

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in OpenStack Identity  (Keystone) Middleware:
  In Progress
Status in Python client library for Keystone:
  New

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

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



From 1355125 at bugs.launchpad.net  Fri Aug 15 20:33:14 2014
From: 1355125 at bugs.launchpad.net (Adam Young)
Date: Fri, 15 Aug 2014 20:33:14 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20140815203315.23479.11972.launchpad@wampee.canonical.com>

** Also affects: python-keystoneclient
   Importance: Undecided
       Status: New

** No longer affects: keystone

** Changed in: python-keystoneclient
     Assignee: (unassigned) => Adam Young (ayoung)

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

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in OpenStack Identity  (Keystone) Middleware:
  In Progress
Status in Python client library for Keystone:
  New

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

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



From 1355125 at bugs.launchpad.net  Fri Aug 15 20:43:48 2014
From: 1355125 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 15 Aug 2014 20:43:48 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20140815204348.17681.48574.malone@soybean.canonical.com>

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

** Changed in: python-keystoneclient
       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/1355125

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in OpenStack Identity  (Keystone) Middleware:
  In Progress
Status in Python client library for Keystone:
  In Progress

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

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



From morgan.fainberg at gmail.com  Sun Aug 17 16:28:03 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Sun, 17 Aug 2014 16:28:03 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20140817162803.5394.17911.malone@gac.canonical.com>

Hi David,

We are actually moving to just that, a unique id for the token. Each
token will hopefully also have an option original parent token id (eg
for audit you know what the first non-rescoped token unique id is.

Hopefully In the next release or so we can also limit the depth of the
token chain by limiting rescope of token to only occur from the unscoped
token (separate bug/spec that is still being discussed).

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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From gerrit2 at review.openstack.org  Mon Aug 18 12:39:28 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 18 Aug 2014 12:39:28 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I7ba7dbd65e913a66efe35a1d6490a85bec8413da
Message-ID: <E1XJMDg-00071X-AA@review.openstack.org>


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

Log:
commit 288a96215331fc7c60cfbea09e9b2f5367e320db
Author: Daniel P. Berrange <berrange at redhat.com>
Date:   Mon Jul 28 15:15:44 2014 +0100

    libvirt: make sysinfo serial number configurable
    
    The 'serial' field in guest SMBIOS tables gets populated
    based on the libvirt reported UUID of the host hardware.
    The rationale is to allow correlation of guests running
    on the same host.
    
    Unfortunately some hardware vendors use a subset of the
    host UUID as a key for retrieving hardware support
    contract information without requiring any authentication.
    So exposing the host UUID to the guest is an information
    leak for those vendors. It is possible to override the
    use of SMBIOS data by libvirt in /etc/libvirt/libvirtd.conf
    by setting the 'host_uuid' parameter.
    
    As a way to reduce the configuration burden though, it is
    preferrable to use the /etc/machine-id UUID, instead of
    the host hardware UUID. The former is a recent standard
    for Linux distros introduced by systemd to provide a UUID
    that is unique per operating system install. This means
    that even containers will see a separate /etc/machine-id
    value. This /etc/machine-id can be expected to be widely
    available in current and future distros. If missing, it
    is still possible to fallback to the libvirt reported
    host UUID.
    
    The host UUID exposed could theoretically be leveraged
    by a cloud user to get an approximate count of the number
    of unique hosts available to them in the cloud by launching
    many short lived VMs. Administrators concerned about this
    may wish to disable reporting of any sysinfo serial field
    at all.
    
    Introduce a 'sysinfo_serial' config parameter to the libvirt
    driver to control behaviour, accepting values:
    
     - 'auto' - try /etc/machine-id, fallback to
       libvirt reported host UUID (new default)
     - 'hardware' - always use libvirt host UUID (old default)
     - 'os' - always use /etc/machine-id, error if missing
     - 'none' - do not report any value to the guest
    
    DocImpact: new libvirt.sysinfo_serial config parameter
    SecurityImpact
    Closes-bug: #1337349
    Change-Id: I7ba7dbd65e913a66efe35a1d6490a85bec8413da




From gerrit2 at review.openstack.org  Mon Aug 18 17:15:35 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 18 Aug 2014 17:15:35 +0000
Subject: [Openstack-security] [openstack/keystonemiddleware] SecurityImpact
 review request change I24cb09edd9a6c9e99e48042a623c7818321f2ead
Message-ID: <E1XJQWt-0002Z8-VS@review.openstack.org>


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

Log:
commit 4c5df677e384f57725815c2f3fda323fca6409c6
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:13:59 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were being check for format and hashed
    
    Closes-Bug: 1355125
    
    SecurityImpact
    
    Change-Id: I24cb09edd9a6c9e99e48042a623c7818321f2ead




From gerrit2 at review.openstack.org  Mon Aug 18 17:53:11 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 18 Aug 2014 17:53:11 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XJR7H-0006Bj-5w@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 29022740cbdd477e46205bb40951bfa06f5fc756
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Wed Aug 13 12:52:52 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Mon Aug 18 19:38:42 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 18 Aug 2014 19:38:42 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iefedde7f168e2ff1870905041fa95301934452e5
Message-ID: <E1XJSlO-0008Jz-KN@review.openstack.org>


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

Log:
commit d675829a1ab90651303ace1fbb984e189ddaf043
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:37:32 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were checked for format and hashed
    
    Closes-Bug: 1355125
    
    SecurityImpact
    
    Change-Id: Iefedde7f168e2ff1870905041fa95301934452e5




From gerrit2 at review.openstack.org  Mon Aug 18 20:29:24 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 18 Aug 2014 20:29:24 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XJTYS-0003ej-S2@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 81e4d5f018c0d0bba39c7976de50b4682b4da71e
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Mon Aug 18 15:25:00 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Mon Aug 18 20:40:33 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 18 Aug 2014 20:40:33 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XJTjF-0005BW-0m@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 f00974cd0bc96ccf6ea163b2423830cc7b322468
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Mon Aug 18 16:41:02 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From 1305566 at bugs.launchpad.net  Tue Aug 19 02:59:17 2014
From: 1305566 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 19 Aug 2014 02:59:17 -0000
Subject: [Openstack-security] [Bug 1305566] Change abandoned on keystone
	(master)
References: <20140410083249.25765.8738.malonedeb@soybean.canonical.com>
Message-ID: <20140819025917.17470.18009.malone@soybean.canonical.com>

Change abandoned by wanghong (w.wanghong at huawei.com) on branch: master
Review: https://review.openstack.org/87450

-- 
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 1292283 at bugs.launchpad.net  Sun Aug 17 15:41:50 2014
From: 1292283 at bugs.launchpad.net (David Chadwick)
Date: Sun, 17 Aug 2014 15:41:50 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20140817154150.28398.1582.malone@chaenomeles.canonical.com>

Revoking tokens based on either their creation time or expiration time
is conceptually wrong, because you can never guarantee that two totally
unrelated tokens do not have the same time stamps. So revoking one would
automatically revoke the other, and this is undesirable. Tokens should
have unique serial numbers, and revocation should be based on this. In
this way you can guarantee to revoke any single token without impacting
any other token. If you want to revoke a family of delegated tokens,
then you could hold the parent serial number in the child token, and
revoke parent and child either together or separately, or revoke all
tokens with the same parent serial number. For grandparents you would
need to follow the lineage - but how deep are these trees likely to get?

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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From 1292283 at bugs.launchpad.net  Mon Aug 18 01:21:24 2014
From: 1292283 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 18 Aug 2014 01:21:24 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20140818012124.5231.98737.malone@gac.canonical.com>

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

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

** Changed in: keystone
     Assignee: Adam Young (ayoung) => Morgan Fainberg (mdrnstm)

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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From jbrendel at cisco.com  Tue Aug 19 02:40:25 2014
From: jbrendel at cisco.com (Juergen Brendel)
Date: Tue, 19 Aug 2014 02:40:25 -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: <20140819024029.23748.98762.launchpad@wampee.canonical.com>

** Changed in: neutron
     Assignee: (unassigned) => Juergen Brendel (jbrendel)

-- 
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 Aug 19 11:16:15 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 19 Aug 2014 11:16:15 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I7ba7dbd65e913a66efe35a1d6490a85bec8413da
Message-ID: <E1XJhOh-000474-0I@review.openstack.org>


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

Log:
commit 4431eec1c94c4a353b45e5d873854b3fb1eaa11b
Author: Daniel P. Berrange <berrange at redhat.com>
Date:   Mon Jul 28 15:15:44 2014 +0100

    libvirt: make sysinfo serial number configurable
    
    The 'serial' field in guest SMBIOS tables gets populated
    based on the libvirt reported UUID of the host hardware.
    The rationale is to allow correlation of guests running
    on the same host.
    
    Unfortunately some hardware vendors use a subset of the
    host UUID as a key for retrieving hardware support
    contract information without requiring any authentication.
    So exposing the host UUID to the guest is an information
    leak for those vendors. It is possible to override the
    use of SMBIOS data by libvirt in /etc/libvirt/libvirtd.conf
    by setting the 'host_uuid' parameter.
    
    As a way to reduce the configuration burden though, it is
    preferrable to use the /etc/machine-id UUID, instead of
    the host hardware UUID. The former is a recent standard
    for Linux distros introduced by systemd to provide a UUID
    that is unique per operating system install. This means
    that even containers will see a separate /etc/machine-id
    value. This /etc/machine-id can be expected to be widely
    available in current and future distros. If missing, it
    is still possible to fallback to the libvirt reported
    host UUID.
    
    The host UUID exposed could theoretically be leveraged
    by a cloud user to get an approximate count of the number
    of unique hosts available to them in the cloud by launching
    many short lived VMs. Administrators concerned about this
    may wish to disable reporting of any sysinfo serial field
    at all.
    
    Introduce a 'sysinfo_serial' config parameter to the libvirt
    driver to control behaviour, accepting values:
    
     - 'auto' - try /etc/machine-id, fallback to
       libvirt reported host UUID (new default)
     - 'hardware' - always use libvirt host UUID (old default)
     - 'os' - always use /etc/machine-id, error if missing
     - 'none' - do not report any value to the guest
    
    DocImpact: new libvirt.sysinfo_serial config parameter
    SecurityImpact
    Closes-bug: #1337349
    Change-Id: I7ba7dbd65e913a66efe35a1d6490a85bec8413da




From 1274034 at bugs.launchpad.net  Tue Aug 19 11:16:13 2014
From: 1274034 at bugs.launchpad.net (Robert Clark)
Date: Tue, 19 Aug 2014 11:16:13 -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: <20140819111613.23479.5882.malone@wampee.canonical.com>

I could have read this incorrectly but my understanding is that this
failure in tenant network isolation is not being considered a severe
security issue?

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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 Aug 19 14:01:22 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 19 Aug 2014 14:01:22 +0000
Subject: [Openstack-security] [openstack/keystonemiddleware] SecurityImpact
 review request change I24cb09edd9a6c9e99e48042a623c7818321f2ead
Message-ID: <E1XJjyU-0007aq-MD@review.openstack.org>


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

Log:
commit 8196d5327d43ab4860f2c6105c9342f5f6faf35a
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:13:59 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were checked for format and hashed
    
    Closes-Bug: 1355125
    
    SecurityImpact
    
    Change-Id: I24cb09edd9a6c9e99e48042a623c7818321f2ead




From gerrit2 at review.openstack.org  Tue Aug 19 15:25:04 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 19 Aug 2014 15:25:04 +0000
Subject: [Openstack-security] [openstack/keystonemiddleware] SecurityImpact
 review request change I24cb09edd9a6c9e99e48042a623c7818321f2ead
Message-ID: <E1XJlHU-0000ED-1z@review.openstack.org>


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

Log:
commit fc53b9eedad1fea325f651a6861a82616b715a27
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:13:59 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were checked for format and hashed
    
    Closes-Bug: 1355125
    
    SecurityImpact
    
    Change-Id: I24cb09edd9a6c9e99e48042a623c7818321f2ead




From 1355125 at bugs.launchpad.net  Tue Aug 19 15:25:01 2014
From: 1355125 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 19 Aug 2014 15:25:01 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20140819152503.17263.68906.launchpad@chaenomeles.canonical.com>

** Changed in: keystonemiddleware
     Assignee: Adam Young (ayoung) => Brant Knudson (blk-u)

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

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in OpenStack Identity  (Keystone) Middleware:
  In Progress
Status in Python client library for Keystone:
  In Progress

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

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



From fungi at yuggoth.org  Tue Aug 19 16:28:25 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 19 Aug 2014 16:28:25 -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: <20140819162825.16966.36383.malone@chaenomeles.canonical.com>

I believe the assertion is that Neutron's flat networking implementation
does not provide layer 2 filtering guarantees between tenants on the
same broadcast domain, unlike Nova's, and that this is a design
shortcoming/feature parity gap which should be better documented for
existing releases and fixed in new releases as a priority feature for
security hardening reasons.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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 1334926 at bugs.launchpad.net  Wed Aug 20 14:53:13 2014
From: 1334926 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 20 Aug 2014 14:53:13 -0000
Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working
 once connected even after it is disociated
References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com>
Message-ID: <20140820145315.5615.38706.launchpad@gac.canonical.com>

** Changed in: neutron
     Assignee: yong sheng gong (gongysh) => Carl Baldwin (carl-baldwin)

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

Title:
  floatingip still working once connected even after it is disociated

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

Bug description:
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still
  access the VM via that connection. Namely, SSH is not disconnected
  when the floating ip is not valid

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



From 1334926 at bugs.launchpad.net  Wed Aug 20 16:23:08 2014
From: 1334926 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 20 Aug 2014 16:23:08 -0000
Subject: [Openstack-security] [Bug 1334926] Re: floatingip still working
 once connected even after it is disociated
References: <20140627021809.32583.22324.malonedeb@soybean.canonical.com>
Message-ID: <20140820162312.27449.15913.launchpad@soybean.canonical.com>

** Changed in: neutron
     Assignee: Carl Baldwin (carl-baldwin) => yong sheng gong (gongysh)

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

Title:
  floatingip still working once connected even after it is disociated

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

Bug description:
  After we create an SSH connection to a VM via its floating ip, even
  though we have removed the floating ip association, we can still
  access the VM via that connection. Namely, SSH is not disconnected
  when the floating ip is not valid

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



From 1355125 at bugs.launchpad.net  Wed Aug 20 17:31:08 2014
From: 1355125 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 20 Aug 2014 17:31:08 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20140820173108.27480.21047.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/114646
Committed: https://git.openstack.org/cgit/openstack/keystonemiddleware/commit/?id=fc53b9eedad1fea325f651a6861a82616b715a27
Submitter: Jenkins
Branch:    master

commit fc53b9eedad1fea325f651a6861a82616b715a27
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:13:59 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were checked for format and hashed
    
    Closes-Bug: 1355125
    
    SecurityImpact
    
    Change-Id: I24cb09edd9a6c9e99e48042a623c7818321f2ead


** Changed in: keystonemiddleware
       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/1355125

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in OpenStack Identity  (Keystone) Middleware:
  Fix Committed
Status in Python client library for Keystone:
  In Progress

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

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



From 1260679 at bugs.launchpad.net  Wed Aug 20 17:58:25 2014
From: 1260679 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 20 Aug 2014 17:58:25 -0000
Subject: [Openstack-security] [Bug 1260679] Re: Multiple drivers set
	insecure file permissions
References: <20131213105542.17101.92136.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140820175827.16966.5827.launchpad@chaenomeles.canonical.com>

** Changed in: cinder
     Assignee: (unassigned) => Glenn M. Gobeli (glenng)

-- 
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:
  Fix Released

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  Wed Aug 20 19:03:17 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 20 Aug 2014 19:03:17 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iefedde7f168e2ff1870905041fa95301934452e5
Message-ID: <E1XKBAD-0007kR-9y@review.openstack.org>


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

Log:
commit b72d247c8f8d340b0aace0be8a9454c4b2485c7d
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:37:32 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were checked for format and hashed
    
    Closes-Bug: 1355125
    
    SecurityImpact
    
    Change-Id: Iefedde7f168e2ff1870905041fa95301934452e5




From gerrit2 at review.openstack.org  Thu Aug 21 15:07:52 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Aug 2014 15:07:52 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XKTxw-0007iq-Og@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 188e02c36a814a8aaa980d4c1e9131a3b3dc5c24
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Thu Aug 21 11:00:59 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From 1004114 at bugs.launchpad.net  Thu Aug 21 17:08:18 2014
From: 1004114 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 21 Aug 2014 17:08:18 -0000
Subject: [Openstack-security] [Bug 1004114] Re: Password logging
References: <20120524190215.26515.18198.malonedeb@gac.canonical.com>
Message-ID: <20140821170821.27324.73396.launchpad@soybean.canonical.com>

** Changed in: python-keystoneclient
    Milestone: 0.10.1 => 0.11.0

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

Title:
  Password logging

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Security Notes:
  In Progress
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  When the log level is set to DEBUG, keystoneclient's full-request
  logging mechanism kicks in, exposing plaintext passwords, etc.

  This bug is mostly out of the scope of Horizon, however Horizon can
  also be more secure in this regard. We should make sure that wherever
  we *are* handling sensitive data we use Django's error report
  filtering mechanisms so they don't appear in tracebacks, etc.
  (https://docs.djangoproject.com/en/dev/howto/error-reporting
  /#filtering-error-reports)

  Keystone may also want to look at respecting such annotations in their
  logging mechanism, i.e. if Django were properly annotating these data
  objects, keystoneclient could check for those annotations and properly
  sanitize the log output.

  If not this exact mechanism, then something similar would be wise.

  For the time being, it's also worth documenting in both projects that
  a log level of DEBUG will log passwords in plain text.

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



From 1355125 at bugs.launchpad.net  Thu Aug 21 17:09:28 2014
From: 1355125 at bugs.launchpad.net (Dolph Mathews)
Date: Thu, 21 Aug 2014 17:09:28 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20140821170929.4986.9452.launchpad@gac.canonical.com>

** Changed in: keystonemiddleware
    Milestone: None => 1.2.0

** Changed in: keystonemiddleware
    Milestone: 1.2.0 => 1.1.1

** Changed in: keystonemiddleware
       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/1355125

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in OpenStack Identity  (Keystone) Middleware:
  Fix Released
Status in Python client library for Keystone:
  In Progress

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

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



From gerrit2 at review.openstack.org  Thu Aug 21 17:46:58 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Aug 2014 17:46:58 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XKWRu-0006ji-4X@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 6f2013551739682831f0de3c49db30a83a3dbaad
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Thu Aug 21 11:00:59 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Thu Aug 21 18:10:32 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Aug 2014 18:10:32 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XKWoi-0000vk-6Z@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 bac1c97ca8b829846078b8248563825f2c207865
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Thu Aug 21 11:00:59 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Thu Aug 21 19:14:48 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Aug 2014 19:14:48 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iefedde7f168e2ff1870905041fa95301934452e5
Message-ID: <E1XKXou-0005ea-1S@review.openstack.org>


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

Log:
commit eb54dfa3f7ef89502e723d4ade41d8930ffb48d5
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:37:32 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were checked for format and hashed
    
    Closes-Bug: 1355125
    
    SecurityImpact
    
    Change-Id: Iefedde7f168e2ff1870905041fa95301934452e5




From 1321080 at bugs.launchpad.net  Thu Aug 21 19:53:01 2014
From: 1321080 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Thu, 21 Aug 2014 19:53:01 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140821195302.24767.82865.launchpad@ackee.canonical.com>

** Branch linked: lp:ubuntu/trusty-security/neutron

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Committed
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released
Status in oslo havana series:
  Fix Committed
Status in oslo icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From 1308727 at bugs.launchpad.net  Thu Aug 21 19:54:18 2014
From: 1308727 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Thu, 21 Aug 2014 19:54:18 -0000
Subject: [Openstack-security] [Bug 1308727] Re: [OSSA 2014-023] XSS in
 Horizon Heat template - resource name (CVE-2014-3473)
References: <20140416193338.27100.82700.malonedeb@gac.canonical.com>
Message-ID: <20140821195423.24766.51521.launchpad@ackee.canonical.com>

** Branch linked: lp:ubuntu/trusty-security/horizon

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

Title:
  [OSSA 2014-023] XSS in Horizon Heat template - resource name
  (CVE-2014-3473)

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

Bug description:
  The attached yaml will result in a Cross Site Script when viewing the
  resources or events of an Orchestration stack in the following paths:

  /project/stacks/stack/{stack_id}/?tab=stack_details__resources
  /project/stacks/stack/{stack_id}/?tab=stack_details__events

  The A tag's href attribute does not properly URL encode the name of
  the resource string resulting in escaping out of the attribute and
  arbitrary HTML written to the page.

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



From 1321080 at bugs.launchpad.net  Thu Aug 21 20:04:17 2014
From: 1321080 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Thu, 21 Aug 2014 20:04:17 -0000
Subject: [Openstack-security] [Bug 1321080] Re: [OSSA 2014-021] auth token
 is exposed in meter http.request (CVE-2014-4615)
References: <20140520034711.18972.46814.malonedeb@wampee.canonical.com>
Message-ID: <20140821200418.24766.498.launchpad@ackee.canonical.com>

** Branch linked: lp:ubuntu/trusty-updates/neutron

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

Title:
  [OSSA 2014-021] auth token is exposed in meter http.request
  (CVE-2014-4615)

Status in OpenStack Telemetry (Ceilometer):
  Invalid
Status in Ceilometer havana series:
  Fix Committed
Status in Ceilometer icehouse series:
  Fix Committed
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in Oslo - a Library of Common OpenStack Code:
  Fix Released
Status in oslo havana series:
  Fix Committed
Status in oslo icehouse series:
  Fix Committed
Status in OpenStack Security Advisories:
  Fix Released
Status in pyCADF:
  Fix Released

Bug description:
  auth token is exposed in meter http.request

  # curl -i -X GET -H 'X-Auth-Token: 258ab6539b3b4eae8b3af307b8f5eadd'
  -H 'Content-Type: application/json' -H 'Accept: application/json' -H
  'User-Agent: python-ceilometerclient'
  http://0.0.0.0:8777/v2/meters/http.request

  -----------
  snip..
  {"counter_name": "http.request", "user_id": "0", "resource_id": "ip-9-37-74-33:8774", "timestamp": "2014-05-16T17:42:16.851000", "recorded_at": "2014-05-16T17:42:17.039000", "resource_metadata": {"request.CADF_EVENT:initiator:host:address": "9.44.143.6", "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478", "request.RAW_PATH_INFO": "/v2/9af97e383dad44969bd650ebd55edfe0/servers/060c76a5-0031-430d-aa1e-01f9b3db234b", "request.REQUEST_METHOD": "DELETE", "event_type": "http.request", "request.HTTP_X_TENANT_ID": "9af97e383dad44969bd650ebd55edfe0", "request.CADF_EVENT:typeURI": "http://schemas.dmtf.org/cloud/audit/1.0/event", "request.HTTP_X_PROJECT_NAME": "ibm-default", "host": "nova-api", "request.SERVER_PORT": "8774", "request.REMOTE_PORT": "55258", "request.HTTP_X_USER_ID": "0", "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478", "request.CADF_EVENT:action": "delete", "request.CADF_EVENT:target:typeURI": "service/compute/servers/server", "request.HTTP_USER_AGENT": "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0",
  snip...

  auth token is masked in "request.CADF_EVENT:initiator:credential:token": "4724 xxxxxxxx 8478".
  But it is exposed in  "request.HTTP_X_AUTH_TOKEN": "4724d3dd6b984079a58eecf406298478"

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



From gary.w.smith at hp.com  Thu Aug 21 22:40:41 2014
From: gary.w.smith at hp.com (Gary W. Smith)
Date: Thu, 21 Aug 2014 22:40:41 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140821224041.5546.42094.malone@gac.canonical.com>

Are any changes needed to horizon for this bug?

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

Title:
  Keystone token hashing is MD5

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

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 1274034 at bugs.launchpad.net  Fri Aug 22 09:32:48 2014
From: 1274034 at bugs.launchpad.net (Robert Clark)
Date: Fri, 22 Aug 2014 09:32:48 -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: <20140822093248.16931.75314.malone@chaenomeles.canonical.com>

Personally I think this is pretty severe as it's a failure to provide
fundamental separation that is a base requirement of a multi-tenant
compute platform.

However, I've added it to the OSSN queue to document the issue.

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

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

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 fungi at yuggoth.org  Fri Aug 22 13:53:00 2014
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 22 Aug 2014 13:53:00 -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: <20140822135300.5084.72826.malone@gac.canonical.com>

Mostly going on Mark's comment about the "security tradeoffs" of shared
networks, suggesting that this should be a known risk to most network-
savvy deployers and so we ought to make sure it's clearly documented...
I agree the result, for an unsuspecting operator, is fairly severe,
however I think it's better to have these design discussions out in the
open (for instance, the current patch proposed to solve this for Juno is
blocked on lack of a blueprint and design specification).

If it turns out that this risk can be mitigated cleanly on stable
branches, to the satisfaction of the stable maintainers and Neutron core
reviewers alike, then it might be possible to revisit an advisory. In
the meantime, visibly documenting this issue can only help improve the
security of our user base so that operators who have not already can
take preventative action.

-- 
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
Status in OpenStack Security Notes:
  New

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 1174499 at bugs.launchpad.net  Fri Aug 22 14:23:51 2014
From: 1174499 at bugs.launchpad.net (Adam Young)
Date: Fri, 22 Aug 2014 14:23:51 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140822142352.5648.35871.malone@gac.canonical.com>

Yes, Horizon needs some chane, and I am not certain what the best
approach is.   Ideally, Horizon would get the Keystone configuration
option,  but Keystone has no way of publishing it to a remote server.
The "Pass a hash"  approach for Horizon was never intended to be a long
term solution, and so I'm reluctant to put too much effort in to making
it even more usable.  I suspect that the  best compromise is a
configuration field for Horizon to establish the hash algorithm to use.

-- 
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 Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

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 gary.w.smith at hp.com  Fri Aug 22 17:52:32 2014
From: gary.w.smith at hp.com (Gary W. Smith)
Date: Fri, 22 Aug 2014 17:52:32 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140822175232.16859.70252.malone@chaenomeles.canonical.com>

Thanks Adam. Marking the horizon as low priority in keeping with the
priority of the other parts of this change, and due to the comments
above about its low risk (such as #6 and #7).

** Changed in: horizon
       Status: New => Confirmed

** Changed in: horizon
   Importance: Undecided => Low

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

Title:
  Keystone token hashing is MD5

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

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 bdpayne at acm.org  Fri Aug 22 18:14:17 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Fri, 22 Aug 2014 11:14:17 -0700
Subject: [Openstack-security] Updates on the Security Guide
Message-ID: <CAFpPvXC-y80f-9Ym9KQngzb2wqPJg1S09_920uS=YOXDQzZR9g@mail.gmail.com>

Over the past couple of months we have renewed our momentum on the
OpenStack Security Guide (http://docs.openstack.org/sec/). Along with this
has come some logistics changes and some new plans for the guide. I wanted
to take a brief moment to update everyone on this work.

At a high level, we are pushing ahead on two paths in parallel: (1)
cleaning up the book through improved organization, presentation clarity,
and grammatical or spelling corrections; (2) setting the course for longer
term book improvements and release cycles. To help facilitate some of these
goals, we have also made some logistical changes.

Book cleanup: The OpenStack Security Group (OSSG) has enlisted the help of
many new contributors to review portions of the book and file bug reports.
 At a recent mid-cycle meet up, we filed 50+ bugs against the book.  We
have also been training new contributors on how to fix these bugs by
walking through the gerrit change request process. We have already resolved
many of these bugs, but plenty remain. This is a great opportunity for new
contributors to step in and help out! We would still appreciate more eyes
to review the book and file bugs. And we'd appreciate people working to
close the bugs, too.

Future directions: I'm organizing a small group of contributors that will
work together to set the future directions for the book effort. I am aiming
for this group to act as a steering committee for the book. We will be
considering issues such as the release cycle, major content areas that are
missing, and overall management of the project. If you are interested in
being involved at this level, please contact me directly.

Logistics: The book recently moved to a new git repository:
https://github.com/openstack/security-doc. This was done, in part, to
simplify the integration of some related security documentation efforts
with the book including the OpenStack Security Notes and OSSG's threat
modeling work. Along with this move, we formalized the approval process for
changes to the book. All changes much receive a +2 from one of the
documentation team members assigned to the project (Andreas Jaeger, Christian
Berendt, and Anne Gentle) and a +2 from one of the OSSG members assigned to
the project (Bryan Payne, Nathan Kinder, and Rob Clark). This is aimed to
maintain high standards from both a documentation and a security
perspective.

We're excited to see things moving ahead with this project, and new
contributors are certainly always welcome!

Cheers,
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140822/a0eb94dc/attachment.html>

From 1337349 at bugs.launchpad.net  Sat Aug 23 01:45:19 2014
From: 1337349 at bugs.launchpad.net (OpenStack Infra)
Date: Sat, 23 Aug 2014 01:45:19 -0000
Subject: [Openstack-security] [Bug 1337349] Re: Nova qemu hypervisor host
 smbios serial number is leaked to guest
References: <20140703142824.27562.82896.malonedeb@gac.canonical.com>
Message-ID: <20140823014520.27387.35074.malone@soybean.canonical.com>

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

commit 4431eec1c94c4a353b45e5d873854b3fb1eaa11b
Author: Daniel P. Berrange <berrange at redhat.com>
Date:   Mon Jul 28 15:15:44 2014 +0100

    libvirt: make sysinfo serial number configurable
    
    The 'serial' field in guest SMBIOS tables gets populated
    based on the libvirt reported UUID of the host hardware.
    The rationale is to allow correlation of guests running
    on the same host.
    
    Unfortunately some hardware vendors use a subset of the
    host UUID as a key for retrieving hardware support
    contract information without requiring any authentication.
    So exposing the host UUID to the guest is an information
    leak for those vendors. It is possible to override the
    use of SMBIOS data by libvirt in /etc/libvirt/libvirtd.conf
    by setting the 'host_uuid' parameter.
    
    As a way to reduce the configuration burden though, it is
    preferrable to use the /etc/machine-id UUID, instead of
    the host hardware UUID. The former is a recent standard
    for Linux distros introduced by systemd to provide a UUID
    that is unique per operating system install. This means
    that even containers will see a separate /etc/machine-id
    value. This /etc/machine-id can be expected to be widely
    available in current and future distros. If missing, it
    is still possible to fallback to the libvirt reported
    host UUID.
    
    The host UUID exposed could theoretically be leveraged
    by a cloud user to get an approximate count of the number
    of unique hosts available to them in the cloud by launching
    many short lived VMs. Administrators concerned about this
    may wish to disable reporting of any sysinfo serial field
    at all.
    
    Introduce a 'sysinfo_serial' config parameter to the libvirt
    driver to control behaviour, accepting values:
    
     - 'auto' - try /etc/machine-id, fallback to
       libvirt reported host UUID (new default)
     - 'hardware' - always use libvirt host UUID (old default)
     - 'os' - always use /etc/machine-id, error if missing
     - 'none' - do not report any value to the guest
    
    DocImpact: new libvirt.sysinfo_serial config parameter
    SecurityImpact
    Closes-bug: #1337349
    Change-Id: I7ba7dbd65e913a66efe35a1d6490a85bec8413da


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

Title:
  Nova qemu hypervisor host smbios serial number is leaked to guest

Status in OpenStack Compute (Nova):
  Fix Committed
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  Erwan Velu from eNovance reported a vulnerability in OpenStack Nova.

  The hypervisor is passing host system uuid (-smbios version) to guests, and this happen to be a critical info leak.
  The defect have been pinpointed to:
   https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3054

  From a simple virtual machine, this may allow numerous info leak like:
      Allow compute hardware enumeration from guests
      Deduce service tag and get all hardware configuration
      Ability to know if two instances are on the same compute

  Dell hardware is particulary impacted as :
      - the uuid encodes the service tag
      - the service tag can be used on support site to determine:
      - detailled hardware configuration
      - date & country where the hw was shipped
      - date & type of support contract
      - amount of servers bought during this shipment

  If there is no use case for this, we should scrambled that piece of
  information.

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



From gerrit2 at review.openstack.org  Sun Aug 24 15:01:44 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 24 Aug 2014 15:01:44 +0000
Subject: [Openstack-security] [openstack/django_openstack_auth]
 SecurityImpact review request change
 I9e3eba7e0a12ae40a08d0ed851ea916ec6591bcc
Message-ID: <E1XLZIe-0000zb-U4@review.openstack.org>


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

Log:
commit 632ef6fcb105e5db45bee088389e3f7b4ea375eb
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Sat Aug 23 11:35:25 2014 -0500

    Configuration token hashing algorithm
    
    The user's authentication token was hashed using the MD5 algorithm.
    The MD5 algorithm shouldn't be used because of the potential for
    hash collisions. Some security standards mandate a SHA2 algorithm
    or better must be used.
    
    With this change the algorithm to use for hashing tokens can be
    configured by setting the OPENSTACK_TOKEN_HASH_ALGORITHM
    configuration option to a hash algorithm supported by Python's
    hashlib library[1]. For example, a deployer could set the option to
    'sha256' to meet a SHA2 security standard.
    
    The algorithm chosen must match the hash algorithm that the
    identity server is configured to use (Keystone and the auth_token
    middleware can be configured to use any hash algorithm supported by
    hashlib).
    
    This is for security hardening.
    
    [1] https://docs.python.org/2/library/hashlib.html
    
    DocImpact
    SecurityImpact
    
    Change-Id: I9e3eba7e0a12ae40a08d0ed851ea916ec6591bcc
    Closes-Bug: #1174499




From gerrit2 at review.openstack.org  Sun Aug 24 15:07:55 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 24 Aug 2014 15:07:55 +0000
Subject: [Openstack-security] [openstack/horizon] SecurityImpact review
 request change I6774b9b7215d191259586e4721e357487bb777cd
Message-ID: <E1XLZOd-0001AU-0q@review.openstack.org>


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

Log:
commit f9b3684a6ef82290e57d20e5e141031abfd5b768
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Sun Aug 24 10:04:10 2014 -0500

    Document token hash algorithm option
    
    With https://review.openstack.org/#/c/116509/ ,
    django-openstack-auth will support a new option for the token hash
    algorithm. This adds the documentation to Horizon's local settings
    example file.
    
    This is for security hardening. The token hash algorithm defaults
    to MD5, which is considered too weak due to the potential for hash
    collisions. Some security standards require a SHA2 hash algorithm to
    be used.
    
    DocImpact
    SecurityImpact
    
    Change-Id: I6774b9b7215d191259586e4721e357487bb777cd
    Closes-Bug: #1174499




From bknudson at us.ibm.com  Sun Aug 24 15:03:38 2014
From: bknudson at us.ibm.com (Brant Knudson)
Date: Sun, 24 Aug 2014 15:03:38 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140824150338.13360.85732.malone@wampee.canonical.com>

Change proposed for django-openstack-auth :
https://review.openstack.org/#/c/116509/

** Also affects: django-openstack-auth
   Importance: Undecided
       Status: New

** Changed in: django-openstack-auth
       Status: New => In Progress

** Changed in: django-openstack-auth
     Assignee: (unassigned) => Brant Knudson (blk-u)

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

Title:
  Keystone token hashing is MD5

Status in Django OpenStack Auth:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

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/django-openstack-auth/+bug/1174499/+subscriptions



From 1174499 at bugs.launchpad.net  Sun Aug 24 15:07:52 2014
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Sun, 24 Aug 2014 15:07:52 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140824150752.27324.98736.malone@soybean.canonical.com>

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

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

** Changed in: horizon
     Assignee: (unassigned) => Brant Knudson (blk-u)

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

Title:
  Keystone token hashing is MD5

Status in Django OpenStack Auth:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

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/django-openstack-auth/+bug/1174499/+subscriptions



From bknudson at us.ibm.com  Sun Aug 24 15:08:28 2014
From: bknudson at us.ibm.com (Brant Knudson)
Date: Sun, 24 Aug 2014 15:08:28 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20140824150828.5084.11792.malone@gac.canonical.com>

Change proposed to horizon: https://review.openstack.org/#/c/116510/

-- 
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 Django OpenStack Auth:
  In Progress
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack API documentation site:
  Confirmed
Status in Python client library for Keystone:
  Fix Released

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/django-openstack-auth/+bug/1174499/+subscriptions



From gerrit2 at review.openstack.org  Sun Aug 24 23:23:57 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 24 Aug 2014 23:23:57 +0000
Subject: [Openstack-security] [openstack/django_openstack_auth]
 SecurityImpact review request change
 I9e3eba7e0a12ae40a08d0ed851ea916ec6591bcc
Message-ID: <E1XLh8f-0002Qn-Da@review.openstack.org>


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

Log:
commit ed1e31eca6cd34677feb6674973c4f8989b2b4e4
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Sat Aug 23 11:35:25 2014 -0500

    Configurable token hashing algorithm
    
    The user's authentication token was hashed using the MD5 algorithm.
    The MD5 algorithm shouldn't be used because of the potential for
    hash collisions. Some security standards mandate a SHA2 algorithm
    or better must be used.
    
    With this change the algorithm to use for hashing tokens can be
    configured by setting the OPENSTACK_TOKEN_HASH_ALGORITHM
    configuration option to a hash algorithm supported by Python's
    hashlib library[1]. For example, a deployer could set the option to
    'sha256' to meet a SHA2 security standard.
    
    The algorithm chosen must match the hash algorithm that the
    identity server is configured to use (Keystone and the auth_token
    middleware can be configured to use any hash algorithm supported by
    hashlib).
    
    This is for security hardening.
    
    [1] https://docs.python.org/2/library/hashlib.html
    
    DocImpact
    SecurityImpact
    
    Change-Id: I9e3eba7e0a12ae40a08d0ed851ea916ec6591bcc
    Closes-Bug: #1174499




From gerrit2 at review.openstack.org  Mon Aug 25 13:41:13 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 25 Aug 2014 13:41:13 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XLuWH-0002MU-Gd@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 e76643fe7f3236d3403f9843834ac84aaa672ada
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Thu Aug 21 11:00:59 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From sriram at sriramhere.com  Mon Aug 25 14:40:11 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Mon, 25 Aug 2014 09:40:11 -0500
Subject: [Openstack-security] Where do we stand on formal process for
 classifying the severity of security bugs?
Message-ID: <CAP6wb7LkuTYiU2abV8Pr+sNB=VzbHt7TPoS6A4-yw37h83NzJA@mail.gmail.com>

I am at the OpenStack Ops Midcyle Meetup in San Antonio and asked to
moderate the Security session here (like how Bryan and I did in Atlanta).

I am looking at feedback from Atlanta meetup and one of the feedback from
operators was regarding more clarity on the classification.

I see some note saying "need to work on formal process'. What is our
current status on the same?

Anything I can point to?

Here is the etherpad from Atl:
https://etherpad.openstack.org/p/juno-summit-ops-security


   - 4) Are there objective measures on severity/ classification?


   -


   - Informal as of now. Need to work on a formal process


-- 
Thanks,
-Sriram
425-610-8465
www.sriramhere.com | www.clouddon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140825/637c2151/attachment.html>

From 1274034 at bugs.launchpad.net  Mon Aug 25 14:57:05 2014
From: 1274034 at bugs.launchpad.net (Kyle Mestery)
Date: Mon, 25 Aug 2014 14:57:05 -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: <20140825145708.5482.86370.launchpad@gac.canonical.com>

** Changed in: neutron
   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/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
Status in OpenStack Security Notes:
  New

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 sriram at sriramhere.com  Mon Aug 25 15:08:29 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Mon, 25 Aug 2014 10:08:29 -0500
Subject: [Openstack-security] The wiki page with all submitted talks
In-Reply-To: <D005179F.28417%michael.xin@rackspace.com>
References: <D0014C6F.280FC%michael.xin@rackspace.com>
 <53DC11B2.7000309@redhat.com>
 <D00274F2.350CD%priti_desai@symantec.com>
 <D5705CD6-3827-489B-A9BB-36D0D3F75146@hp.com>
 <A513347F-89FF-433F-A8F2-52E075417360@hp.com>
 <CAJfWK4_0=adt9ZUGyYpFPmY6MLzzeCRfpuwgg5dExJKvCaJDmw@mail.gmail.com>
 <CAJfWK49BQM93KJzzQXjZZRhM63mjTn6pL9B+9QKkij1NwKZogQ@mail.gmail.com>
 <D005179F.28417%michael.xin@rackspace.com>
Message-ID: <CAP6wb7+T133i-UGE_T+vYmJXBLKC29XxCup8t81aAQnoiXVtvQ@mail.gmail.com>

How many talks got accepted?


On Mon, Aug 4, 2014 at 10:57 AM, Michael Xin <michael.xin at rackspace.com>
wrote:

>   Adam:
> Thanks for your votes.  :-)
>
>   Thanks and have a great day.
>
>  Yours,
> Michael
>
>
> -----------------------------------------------------------------------------
> Michael Xin | Manager, Security Engineering - US
> Product Security  |Rackspace Hosting
> Office #: 501-7341   or  210-312-7341
> Mobile #: 210-284-8674
> 5000 Walzem Road, San Antonio, Tx 78218
>
> ----------------------------------------------------------------------------
> Experience fanatical support
>
>
>   From: Adam Lawson <alawson at aqorn.com>
> Date: Sunday, August 3, 2014 at 3:04 PM
> To: "Hullinger, Jason (Cloud Services)" <jason.hullinger at hp.com>
> Cc: "openstack-security at lists.openstack.org" <
> openstack-security at lists.openstack.org>
> Subject: Re: [Openstack-security] The wiki page with all submitted talks
>
>   Incidentally, OSSG has some of the best proposals. I voted for you all
> ; )
>
>
> * Adam Lawson*
>  AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
>  Direct: +1 916-246-2072
>
>
>
> On Sun, Aug 3, 2014 at 12:59 PM, Adam Lawson <alawson at aqorn.com> wrote:
>
>> Added mine re Keystone Federation as well.
>>
>>  Mahalo,
>> Adam
>>
>>
>> * Adam Lawson*
>>  AQORN, Inc.
>> 427 North Tatnall Street
>> Ste. 58461
>> Wilmington, Delaware 19801-2230
>> Toll-free: (844) 4-AQORN-NOW ext. 101
>> International: +1 302-387-4660
>>  Direct: +1 916-246-2072
>>
>>
>>
>> On Sun, Aug 3, 2014 at 12:08 PM, Hullinger, Jason (Cloud Services) <
>> jason.hullinger at hp.com> wrote:
>>
>>> Sorry, "added" mine as well :)
>>>
>>> Sent from my iPhone
>>>
>>> > On Aug 3, 2014, at 11:55 AM, "Hullinger, Jason (Cloud Services)" <
>>> jason.hullinger at hp.com> wrote:
>>> >
>>> > Add mine as well.
>>> > Best,
>>> > Jason
>>> >
>>> >> On Aug 2, 2014, at 11:01 AM, "Priti Desai" <Priti_Desai at symantec.com>
>>> wrote:
>>> >>
>>> >> Thanks Guys. I have added two of my talks as well.
>>> >>
>>> >> Cheers
>>> >> Priti
>>> >>
>>> >>> On 8/1/14 3:16 PM, "Nathan Kinder" <nkinder at redhat.com> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>>> On 08/01/2014 11:57 AM, Michael Xin wrote:
>>> >>>> hi, guys:
>>> >>>> Here is the wiki page with all submitted talks for Paris Summit:
>>> >>>> https://wiki.openstack.org/wiki/Security/Talks
>>> >>>
>>> >>> Thanks for putting this together Michael!  I've added my proposed
>>> talk
>>> >>> to the list as well.
>>> >>>
>>> >>> -NGK
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Thanks and have a great day.
>>> >>>>
>>> >>>> Yours,
>>> >>>> Michael
>>> >>>>
>>> >>>>
>>> >>>>
>>> -------------------------------------------------------------------------
>>> >>>> ----
>>> >>>> Michael Xin | Manager, Security Engineering - US
>>> >>>> Product Security  |Rackspace Hosting
>>> >>>> Office #: 501-7341   or  210-312-7341
>>> >>>> Mobile #: 210-284-8674
>>> >>>> 5000 Walzem Road, San Antonio, Tx 78218
>>> >>>>
>>> >>>>
>>> -------------------------------------------------------------------------
>>> >>>> ---
>>> >>>> Experience fanatical support
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Openstack-security mailing list
>>> >>>> Openstack-security at lists.openstack.org
>>> >>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>> >>>
>>> >>> _______________________________________________
>>> >>> Openstack-security mailing list
>>> >>> Openstack-security at lists.openstack.org
>>> >>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Openstack-security mailing list
>>> >> Openstack-security at lists.openstack.org
>>> >>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>> >
>>> > _______________________________________________
>>> > Openstack-security mailing list
>>> > Openstack-security at lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>>
>>> _______________________________________________
>>> Openstack-security mailing list
>>> Openstack-security at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>>
>>
>>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>


-- 
Thanks,
-Sriram
425-610-8465
www.sriramhere.com | www.clouddon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140825/89b8ee6e/attachment.html>

From thierry at openstack.org  Mon Aug 25 16:03:46 2014
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 25 Aug 2014 18:03:46 +0200
Subject: [Openstack-security] Where do we stand on formal process for
 classifying the severity of security bugs?
In-Reply-To: <CAP6wb7LkuTYiU2abV8Pr+sNB=VzbHt7TPoS6A4-yw37h83NzJA@mail.gmail.com>
References: <CAP6wb7LkuTYiU2abV8Pr+sNB=VzbHt7TPoS6A4-yw37h83NzJA@mail.gmail.com>
Message-ID: <53FB5E62.5060405@openstack.org>

Sriram Subramanian wrote:
> I am at the OpenStack Ops Midcyle Meetup in San Antonio and asked to
> moderate the Security session here (like how Bryan and I did in Atlanta).
> 
> I am looking at feedback from Atlanta meetup and one of the feedback
> from operators was regarding more clarity on the classification. 
> 
> I see some note saying "need to work on formal process'. What is our
> current status on the same?

Rob proposed something based on CVSS, but I've yet to see a process that
we could include as part of the vulnerability management team processes.

-- 
Thierry Carrez (ttx)



From sriram at sriramhere.com  Mon Aug 25 16:11:48 2014
From: sriram at sriramhere.com (Sriram Subramanian)
Date: Mon, 25 Aug 2014 11:11:48 -0500
Subject: [Openstack-security] Where do we stand on formal process for
 classifying the severity of security bugs?
In-Reply-To: <53FB5E62.5060405@openstack.org>
References: <CAP6wb7LkuTYiU2abV8Pr+sNB=VzbHt7TPoS6A4-yw37h83NzJA@mail.gmail.com>
 <53FB5E62.5060405@openstack.org>
Message-ID: <CAP6wb7J8Gwf3NCevmXgDfaNnmWtnG2NxyHazahAHeTcOQ8QxtQ@mail.gmail.com>

thanks Thierry. That's my recollection too. Thanks!


On Mon, Aug 25, 2014 at 11:03 AM, Thierry Carrez <thierry at openstack.org>
wrote:

> Sriram Subramanian wrote:
> > I am at the OpenStack Ops Midcyle Meetup in San Antonio and asked to
> > moderate the Security session here (like how Bryan and I did in Atlanta).
> >
> > I am looking at feedback from Atlanta meetup and one of the feedback
> > from operators was regarding more clarity on the classification.
> >
> > I see some note saying "need to work on formal process'. What is our
> > current status on the same?
>
> Rob proposed something based on CVSS, but I've yet to see a process that
> we could include as part of the vulnerability management team processes.
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>



-- 
Thanks,
-Sriram
425-610-8465
www.sriramhere.com | www.clouddon.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140825/c7bb6b74/attachment.html>

From gerrit2 at review.openstack.org  Mon Aug 25 16:21:00 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 25 Aug 2014 16:21:00 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XLx0u-0007k3-KE@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 f4e34f1b1670aa6535c5fb6a1ed7747a7bc7765d
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Thu Aug 21 11:00:59 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From bdpayne at acm.org  Mon Aug 25 17:19:03 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Mon, 25 Aug 2014 10:19:03 -0700
Subject: [Openstack-security] Where do we stand on formal process for
 classifying the severity of security bugs?
In-Reply-To: <53FB5E62.5060405@openstack.org>
References: <CAP6wb7LkuTYiU2abV8Pr+sNB=VzbHt7TPoS6A4-yw37h83NzJA@mail.gmail.com>
 <53FB5E62.5060405@openstack.org>
Message-ID: <CAFpPvXD29XHWn3Bgsu2H3OWgFtZRfFnPE=SBVhZkr0jxDWJ-ZQ@mail.gmail.com>

>
> Rob proposed something based on CVSS, but I've yet to see a process that
>  we could include as part of the vulnerability management team processes.
>

Could you provide a little more detail as to what is missing?  It would be
nice to move ahead with doing something like this.  But perhaps I don't
know what problems remain to be solved (or where OSSG could help with those
problems).

Thanks,
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140825/0933ebba/attachment.html>

From robert.clark at hp.com  Mon Aug 25 17:44:21 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Mon, 25 Aug 2014 17:44:21 +0000
Subject: [Openstack-security] Where do we stand on formal process for
 classifying the severity of security bugs?
In-Reply-To: <CAFpPvXD29XHWn3Bgsu2H3OWgFtZRfFnPE=SBVhZkr0jxDWJ-ZQ@mail.gmail.com>
References: <CAP6wb7LkuTYiU2abV8Pr+sNB=VzbHt7TPoS6A4-yw37h83NzJA@mail.gmail.com>
 <53FB5E62.5060405@openstack.org>
 <CAFpPvXD29XHWn3Bgsu2H3OWgFtZRfFnPE=SBVhZkr0jxDWJ-ZQ@mail.gmail.com>
Message-ID: <D02133A9.1DE76%robert.clark@hp.com>

So typically I use CVSSv2 as a good example of a metric that _doesn’t_ work well for OpenStack – or any virtualisation product.

Proposing a vulnerability metric for OpenStack was on the agenda for the OSSG meet up but lower down the list than some other things and we didn’t get around to it. I asked Doug Chivers to provide some background research which he sent to the list some time ago and had some positive feedback.

This might be a good thing to address in a design session, with appropriate preliminary work.



From: Bryan Payne <bdpayne at acm.org<mailto:bdpayne at acm.org>>
Date: Monday, 25 August 2014 18:19
To: Thierry Carrez <thierry at openstack.org<mailto:thierry at openstack.org>>
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] Where do we stand on formal process for classifying the severity of security bugs?

Rob proposed something based on CVSS, but I've yet to see a process that
we could include as part of the vulnerability management team processes.

Could you provide a little more detail as to what is missing?  It would be nice to move ahead with doing something like this.  But perhaps I don't know what problems remain to be solved (or where OSSG could help with those problems).

Thanks,
-bryan




From gerrit2 at review.openstack.org  Mon Aug 25 21:16:28 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 25 Aug 2014 21:16:28 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XM1cq-0003pK-Ox@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 45c63f5816c4515a8c891ee0f1cd20a556fa23a1
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Thu Aug 21 11:00:59 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From 1355125 at bugs.launchpad.net  Mon Aug 25 21:34:24 2014
From: 1355125 at bugs.launchpad.net (Dolph Mathews)
Date: Mon, 25 Aug 2014 21:34:24 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20140825213427.16704.78777.launchpad@chaenomeles.canonical.com>

** Changed in: python-keystoneclient
   Importance: Undecided => Critical

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

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in OpenStack Identity  (Keystone) Middleware:
  Fix Released
Status in Python client library for Keystone:
  In Progress

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

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



From 1316822 at bugs.launchpad.net  Mon Aug 25 22:30:58 2014
From: 1316822 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 25 Aug 2014 22:30:58 -0000
Subject: [Openstack-security] [Bug 1316822] Change abandoned on nova (master)
References: <20140506221318.20885.39818.malonedeb@gac.canonical.com>
Message-ID: <20140825223059.16735.16117.malone@chaenomeles.canonical.com>

Change abandoned by Abhishek Chanda (abhishek at cloudscaling.com) on branch: master
Review: https://review.openstack.org/101021

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

Title:
  soft reboot of instance does not ensure iptables rules are present

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

Bug description:
  The iptables rules needed to implement instance security group rules
  get inserted by the "_create_domain_and_network" function in
  nova/virt/libvirt/driver.py

  This function is called by the following functions: _hard_reboot,
  resume and spawn (also in a couple of migration related functions).

  Doing "nova reboot <instance_id>" only does a soft reboot
  (_soft_reboot) and assumes that the rules are already present and
  therefore does not check or try to add them.

  If the instances is stopped (nova stop <instance_id>) and nova-compute
  is restarted (for example for a maintenance or problem), the iptables
  rules are removed as observed via output displayed in iptables -S.

  If the instance is started via  nova reboot <instance_id> the rule is
  NOT reapplied until a service nova-compute restart is issued. I have
  reports that this may affect "nova start <instance_id>" as well.

  Depending on if the Cloud is public facing, this opens up a
  potentially huge security vulnerability as an instance can be powered
  on without being protected by any security group rules (not even the
  sg-fallback rule). This is unbeknownst to the instance owner or Cloud
  operators unless they specifically monitor for this situation.

  The code should not do a soft reboot/start and error out or fallback
  to a resume (start)or hard reboot if it detects that the domain is not
  running.

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



From 1355125 at bugs.launchpad.net  Tue Aug 26 00:18:34 2014
From: 1355125 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 26 Aug 2014 00:18:34 -0000
Subject: [Openstack-security] [Bug 1355125] Re: keystonemiddleware appears
	not to hash PKIZ tokens
References: <20140811105447.23844.43062.malonedeb@wampee.canonical.com>
Message-ID: <20140826001834.13188.74531.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/114654
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=eb54dfa3f7ef89502e723d4ade41d8930ffb48d5
Submitter: Jenkins
Branch:    master

commit eb54dfa3f7ef89502e723d4ade41d8930ffb48d5
Author: Adam Young <ayoung at redhat.com>
Date:   Fri Aug 15 16:37:32 2014 -0400

    Hash for PKIZ
    
    Only PKI (asn1) based tokens were checked for format and hashed
    
    Closes-Bug: 1355125
    
    SecurityImpact
    
    Change-Id: Iefedde7f168e2ff1870905041fa95301934452e5


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

Title:
  keystonemiddleware appears not to hash PKIZ tokens

Status in OpenStack Identity  (Keystone) Middleware:
  Fix Released
Status in Python client library for Keystone:
  Fix Committed

Bug description:
  It looks like Keystone hashes only PKI tokens [1] and test test_verify_signed_token_raises_exception_for_revoked_pkiz_token [2] does not take hashing into account (and checks only already hashed data and not hashing itself)
  And that should make token revocation for PKIZ tokens broken.

  
  [1] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/auth_token.py#L1399
  [2] https://github.com/openstack/keystonemiddleware/blob/c9036a00ef3f7c4b9475799d5b713db7a2d94961/keystonemiddleware/tests/test_auth_token_middleware.py#L741

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



From bdpayne at acm.org  Tue Aug 26 06:33:20 2014
From: bdpayne at acm.org (Bryan D. Payne)
Date: Mon, 25 Aug 2014 23:33:20 -0700
Subject: [Openstack-security] Where do we stand on formal process for
 classifying the severity of security bugs?
In-Reply-To: <D02133A9.1DE76%robert.clark@hp.com>
References: <CAP6wb7LkuTYiU2abV8Pr+sNB=VzbHt7TPoS6A4-yw37h83NzJA@mail.gmail.com>
 <53FB5E62.5060405@openstack.org>
 <CAFpPvXD29XHWn3Bgsu2H3OWgFtZRfFnPE=SBVhZkr0jxDWJ-ZQ@mail.gmail.com>
 <D02133A9.1DE76%robert.clark@hp.com>
Message-ID: <CAFpPvXDX8bYkyuAMAJdSDJBBuBXqWcghWcX63UM1skUW+qnKCA@mail.gmail.com>

>
> This might be a good thing to address in a design session, with
> appropriate preliminary work.
>

+1

Would be nice to move ahead with this one.  Seems like something we (as a
community) should be able to solve.

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

From 1292283 at bugs.launchpad.net  Tue Aug 26 16:47:55 2014
From: 1292283 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 26 Aug 2014 16:47:55 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20140826164755.5350.72030.malone@gac.canonical.com>

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

commit ea185a25a235d339d0d9282fbc08905fa1949b92
Author: Morgan Fainberg <morgan.fainberg at gmail.com>
Date:   Mon Aug 25 20:17:47 2014 -0700

    Revoke by Audit Id / Audit Id Chain instead of expires
    
    Instead of using the expiry of the token which can collide (is non
    unique in some/many cases) use the new Audit ID for the tokens when
    revoking a single token via the token revocation events.
    
    Support for revoking by the audit_chain_id has been added to the
    token provider, however, the REST API has not been updated to
    accept an argument to revoke the chain. Support for revoking
    the entire chain is in place to allow Keystone to internally
    revoke an entire chain in certain circumstances. Exposing the
    ability to revoke the entire chain via the REST API may occur
    based upon further design discussions.
    
    Change-Id: I840355ccd9bcfcd88aa139184731c056808c2c8f
    bp: non-persistent-tokens
    Closes-Bug: 1292283


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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  Fix Committed

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From gerrit2 at review.openstack.org  Tue Aug 26 20:09:08 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 26 Aug 2014 20:09:08 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XMN3E-0002MY-Kd@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 ddab514b5ec8596043ff3384f418a78e359f2b6f
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Thu Aug 21 11:00:59 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Tue Aug 26 23:48:02 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 26 Aug 2014 23:48:02 +0000
Subject: [Openstack-security] [openstack/horizon] SecurityImpact review
 request change I6774b9b7215d191259586e4721e357487bb777cd
Message-ID: <E1XMQT4-00052Z-Mh@review.openstack.org>


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

Log:
commit c3d1bf37c27eb292827625391ec72da54308743b
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Sun Aug 24 10:04:10 2014 -0500

    Document token hash algorithm option
    
    With https://review.openstack.org/#/c/116509/ ,
    django-openstack-auth will support a new option for the token hash
    algorithm. This adds the documentation to Horizon's local settings
    example file.
    
    This is for security hardening. The token hash algorithm defaults
    to MD5, which is considered too weak due to the potential for hash
    collisions. Some security standards require a SHA2 hash algorithm to
    be used.
    
    DocImpact
    SecurityImpact
    
    Change-Id: I6774b9b7215d191259586e4721e357487bb777cd
    Closes-Bug: #1174499




From gerrit2 at review.openstack.org  Wed Aug 27 13:31:55 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 27 Aug 2014 13:31:55 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1XMdKN-0002Hp-4n@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 e25b909b63d1cf274468d7265801067fe3973879
Author: Daniel Genin <Daniel.Genin at jhuapl.edu>
Date:   Thu Aug 21 11:00:59 2014 -0400

    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 lvm-ephemeral-storage-encryption
    Change-Id: I871af4018f99ddfcc8408708bdaaf480088ac477
    DocImpact
    SecurityImpact




From gerrit2 at review.openstack.org  Wed Aug 27 22:46:59 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 27 Aug 2014 22:46:59 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I241ca72329f1ec9df778498b346d7b29c224d528
Message-ID: <E1XMlzX-0007C0-V2@review.openstack.org>


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

Log:
commit 61cd815ce153be4515ec1e9edf19ae188b781f7a
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:06:44 2014 -0500

    pki/ssl_setup configurable digest
    
    The digest to use for pki_setup couldn't be configured. The value was
    `default`, which means that the digest was sha1. Some security
    standards require the digest to be stronger (SHA2), so making the
    digest configurable will allow deployments to be compliant.
    
    SecurityImpact
    
    DocImpact
    
    New `message_digest_algorithm` configuration options are added to the
    [signing] and [ssl] sections which default to `default`.
    
    Change-Id: I241ca72329f1ec9df778498b346d7b29c224d528
    Closes-Bug: #1362343




From gerrit2 at review.openstack.org  Wed Aug 27 22:47:07 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 27 Aug 2014 22:47:07 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I9e42c9bafc307ba1334fa641bab76f251722044d
Message-ID: <E1XMlzf-0007Cp-F6@review.openstack.org>


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

Log:
commit 17067dc384307d6a8649d283c4efb6c6518094ed
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:11:06 2014 -0500

    Change the default digest for pki/ssl_setup to sha256
    
    The default digest was `default`, which meant that the digest was the
    openssl default of sha1. The default setting should be a SHA2
    algorithm since this meets current security standards.
    
    This is for security hardening.
    
    SecurityImpact
    
    DocImpact
    
    The `default_message_digest` configuration options now default to
    `sha256` instead of `default`.
    
    Change-Id: I9e42c9bafc307ba1334fa641bab76f251722044d
    Related-Bug: #1362343




From gerrit2 at review.openstack.org  Wed Aug 27 23:07:19 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 27 Aug 2014 23:07:19 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iff063149e1f12df69bbf9015222d09d798980872
Message-ID: <E1XMmJD-0008Kl-1S@review.openstack.org>


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

Log:
commit 495eec908e919e8809c8b3ea601c2708792ee7a5
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:50:19 2014 -0500

    Change cms_sign_data to use sha256 message digest
    
    cms_sign_data was not passing the md parameter to openssl, so it was
    using the default digest of sha1. Some security standards require a
    SHA2 algorithm for the digest.
    
    This if for security hardening.
    
    SecurityImpact
    
    Change-Id: Iff063149e1f12df69bbf9015222d09d798980872
    Closes-Bug: #1362343




From gerrit2 at review.openstack.org  Wed Aug 27 23:07:24 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 27 Aug 2014 23:07:24 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie19d093d0494443ce4cd880ae1f92dffd5c361ef
Message-ID: <E1XMmJI-0008LE-Vm@review.openstack.org>


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

Log:
commit 1b2882328fb61f9d64c6f382b7cd50e200293d3a
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:53:41 2014 -0500

    cms_sign_data support alternative message digest
    
    cms_sign_data always used sha256 for the message digest. This might be
    inadequate in the future so the digest algorithm shouldn't be hard-
    coded. A parameter is added to allow choosing a different digest
    algorithm.
    
    SecurityImpact
    
    Change-Id: Ie19d093d0494443ce4cd880ae1f92dffd5c361ef
    Related-Bug: #1362343




From gerrit2 at review.openstack.org  Wed Aug 27 23:42:56 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 27 Aug 2014 23:42:56 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I89543ccd84dd0ed0df39c4c247f354bb08adc23e
Message-ID: <E1XMmrg-00029V-ET@review.openstack.org>


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

Log:
commit 227816aba6fcf8ddd2eb442ad3d93d9f8c868a4f
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 18:41:27 2014 -0500

    Configurable PKI token signature digest
    
    python-keystoneclient's token signing function (cms_sign_data) was
    recently enhanced to support configuring the digest algorithm. This
    adds a configuration option to Keystone to set the digest to use.
    
    SecurityImpact
    
    DocImpact
    
    A new `message_digest_algorithm` option is added to the [token]
    section of the config file.
    
    Change-Id: I89543ccd84dd0ed0df39c4c247f354bb08adc23e
    Related-Bug: #1362343




From 1360260 at bugs.launchpad.net  Fri Aug 22 13:19:15 2014
From: 1360260 at bugs.launchpad.net (danieru)
Date: Fri, 22 Aug 2014 13:19:15 -0000
Subject: [Openstack-security] [Bug 1360260] [NEW]
	'allow_same_net_traffic=true' has no effect
References: <20140822131915.17201.76910.malonedeb@chaenomeles.canonical.com>
Message-ID: <20140822131915.17201.76910.malonedeb@chaenomeles.canonical.com>

Public bug reported:

environment: Ubuntu trusty, icehouse from repos. 
Setup per 'Openstack Installation Guide for Ubuntu 12.04/14.04 LTS' 

**brief**

two instances X and Y are members of security group A. Despite the
following explicit setting in nova.conf:

allow_same_net_traffic=True

...the instances are only allowed to communicate according to the rules
defined in security group A.


**detail**

I first noticed this attempting to run iperf between two instances on
the same security network; they were unable to connect via the default
TCP port 5001.

They were able to ping...looking at rules for the security group they
are are associated with, ping was allowed, so I then suspected the
security group rules were being applied to all communication, despite
them being on the same security group.

To test, I added rules to group A that allowed all communication, and
associated the rules with itself (i.e. security group A) and voila, they
could talk!

I then thought I had remembered incorrectly that by default all traffic
is allowed between instances on the same security group, so I double-
checked the documentation, but according to the documentation I had
remembered correctly:

allow_same_net_traffic = True (BoolOpt) Whether to allow network traffic
from same network

...I searched through my nova.conf files, but there was no
'allow_same_net_traffic' entry, so the default ought to be True, right?
Just to be sure, I explicitly added:

allow_same_net_traffic = True

to nova.conf and restarted nova services, but the security group rules
are still being applied to communication between instances that are
associated with the same security group.

I thought the 'default' security group might be a special case, so I
tested on another security group, but still get the same behaviour.

** Affects: nova
     Importance: Undecided
         Status: New


** Tags: allowsamenettraffic nova 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/1360260

Title:
  'allow_same_net_traffic=true' has no effect

Status in OpenStack Compute (Nova):
  New

Bug description:
  environment: Ubuntu trusty, icehouse from repos. 
  Setup per 'Openstack Installation Guide for Ubuntu 12.04/14.04 LTS' 

  **brief**

  two instances X and Y are members of security group A. Despite the
  following explicit setting in nova.conf:

  allow_same_net_traffic=True

  ...the instances are only allowed to communicate according to the
  rules defined in security group A.

  
  **detail**

  I first noticed this attempting to run iperf between two instances on
  the same security network; they were unable to connect via the default
  TCP port 5001.

  They were able to ping...looking at rules for the security group they
  are are associated with, ping was allowed, so I then suspected the
  security group rules were being applied to all communication, despite
  them being on the same security group.

  To test, I added rules to group A that allowed all communication, and
  associated the rules with itself (i.e. security group A) and voila,
  they could talk!

  I then thought I had remembered incorrectly that by default all
  traffic is allowed between instances on the same security group, so I
  double-checked the documentation, but according to the documentation I
  had remembered correctly:

  allow_same_net_traffic = True (BoolOpt) Whether to allow network
  traffic from same network

  ...I searched through my nova.conf files, but there was no
  'allow_same_net_traffic' entry, so the default ought to be True,
  right? Just to be sure, I explicitly added:

  allow_same_net_traffic = True

  to nova.conf and restarted nova services, but the security group rules
  are still being applied to communication between instances that are
  associated with the same security group.

  I thought the 'default' security group might be a special case, so I
  tested on another security group, but still get the same behaviour.

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



From steve.lewis at rackspace.com  Mon Aug 25 22:11:00 2014
From: steve.lewis at rackspace.com (Steve Lewis)
Date: Mon, 25 Aug 2014 22:11:00 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20140825221103.17099.34324.launchpad@chaenomeles.canonical.com>

** Changed in: horizon
     Assignee: (unassigned) => Steve Lewis (steve-lewis)

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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From tjones at vmware.com  Wed Aug 27 16:43:15 2014
From: tjones at vmware.com (Tracy Jones)
Date: Wed, 27 Aug 2014 16:43:15 -0000
Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache
 poisoning by local attacker
References: <20140715043528.2209.47100.malonedeb@gac.canonical.com>
Message-ID: <20140827164316.2857.31160.launchpad@chaenomeles.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/1341954

Title:
  suds client subject to cache poisoning by local attacker

Status in Cinder:
  In Progress
Status in Gantt:
  New
Status in OpenStack Compute (Nova):
  New
Status in Oslo VMware library for OpenStack projects:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  
  The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. 

  cinder/requirements.txt:suds>=0.4
  gantt/requirements.txt:suds>=0.4
  nova/requirements.txt:suds>=0.4
  oslo.vmware/requirements.txt:suds>=0.4

  
  The details are available here - 
  https://bugzilla.redhat.com/show_bug.cgi?id=978696
  (CVE-2013-2217)

  Although this is an unlikely attack vector steps should be taken to
  prevent this behaviour. Potential ways to fix this are by explicitly
  setting the cache location to a directory created via
  tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or
  using a custom cache implementation that doesn't load / store pickled
  objects from an insecure location.

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



From steve.lewis at rackspace.com  Wed Aug 27 23:19:50 2014
From: steve.lewis at rackspace.com (Steve Lewis)
Date: Wed, 27 Aug 2014 23:19:50 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20140827231953.27958.31982.launchpad@wampee.canonical.com>

** Changed in: horizon
     Assignee: Steve Lewis (steve-lewis) => (unassigned)

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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  Fix Committed

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From bknudson at us.ibm.com  Thu Aug 28 16:41:05 2014
From: bknudson at us.ibm.com (Brant Knudson)
Date: Thu, 28 Aug 2014 16:41:05 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20140828164105.28114.81967.malone@wampee.canonical.com>

With Morgan's changes to revocation events (use of audit id), only the
unscoped token will be revoked. This matches how revocations worked with
the revocation list.

I don't think that there's anything that Horizon could do about this,
unless it's going to change to handle tokens being revoked (as it should
anyways, because they can be revoked at any time due to a password
change).

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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  Fix Committed

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From morgan.fainberg at gmail.com  Thu Aug 28 16:52:43 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Thu, 28 Aug 2014 16:52:43 -0000
Subject: [Openstack-security] [Bug 1292283] Re: revocation events: deleting
 a token revokes all tokens with same expiration
References: <20140314003341.30362.66976.malonedeb@gac.canonical.com>
Message-ID: <20140828165243.2795.69923.malone@chaenomeles.canonical.com>

I agree with Brant's assessment.

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

Title:
  revocation events: deleting a token revokes all tokens with same
  expiration

Status in OpenStack Dashboard (Horizon):
  Confirmed
Status in OpenStack Identity (Keystone):
  Fix Committed

Bug description:
  As part of the design process for revocation events it was determined
  that a mechanism to revoke all dependent tokens was needed. This
  covers the case of revoking a token and ensuring all tokens that were
  created from that token are also revoked.

  To accomplish this, the revocation of a specific token is done by
  expiration_time. The expiration_time attribute is never changed on
  subsequent tokens. This means it is easy to ensure revocation of an
  entire chain of tokens.

  This poses an issue if any specific token (or all tokens that are a
  child of a specific token) should be revoked, but the parent tokens
  should not be revoked.

  Use case:

  Get Unscoped token
  Get Scoped Token from Unscoped token
  Get New Scoped Token
  Revoke first unscoped token
  Now all tokens (including the Unscoped token) are revoked because they share an expiration_time.

  Likely there needs to be a solution that allows for revoking based
  upon expiration_time and issued_at and one that revokes on
  expiration_time alone. Revoking by expiration_time alone is API
  incompatible with previous API mechanisms (both V2 and V3).

  This is the reason bug https://bugs.launchpad.net/horizon/+bug/1291099
  was identified.

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



From morgan.fainberg at gmail.com  Thu Aug 28 17:04:56 2014
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Thu, 28 Aug 2014 17:04:56 -0000
Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize
 env variables PASSLIB_MAX_PASSWORD_SIZE
References: <20130503065127.14958.89453.malonedeb@gac.canonical.com>
Message-ID: <20140828170458.28020.51744.launchpad@wampee.canonical.com>

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

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

Title:
  passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  Grant Murphy originally reported:

  * Usage of passlib

    The keystone server does not appear to sanitize the environment when 
    starting. This means that an unintended value can be set for 
    PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 
    4096 and potentially cause an unhandled passlib.exc.PasswordSizeError.  
    We should ensure sensible defaults are applied here prior to loading passlib.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From travis.mcpeak at hp.com  Thu Aug 28 17:22:42 2014
From: travis.mcpeak at hp.com (Travis McPeak)
Date: Thu, 28 Aug 2014 17:22:42 -0000
Subject: [Openstack-security] [Bug 1343657] Re: Shell Injection in backup
	strategies
References: <20140717230743.8188.12182.malonedeb@soybean.canonical.com>
Message-ID: <20140828172245.28736.2237.launchpad@wampee.canonical.com>

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

** Changed in: ossn
     Assignee: (unassigned) => Travis McPeak (travis-mcpeak)

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

Title:
  Shell Injection in backup strategies

Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New
Status in Openstack Database (Trove):
  New

Bug description:
  Trove uses subprocess.Popen with shell=True in
  trove/trove/guestagent/strategies/backup/base.py line 61:

      def run(self):
          self.process = subprocess.Popen(self.command, shell=True,
                                          stdout=subprocess.PIPE,
                                          stderr=subprocess.PIPE,
                                          preexec_fn=os.setsid)
          self.pid = self.process.pid

  This could be used, maliciously or not, to inject arbitrary commands
  into a command line string. An example of this could be triggered is
  in trove/trove/guestagent/strategies/backup/mysql_imply.py line 37. It
  is creating a MySQL string with single quote. If the password, either
  maliciously or just happens to contain another single quote, it will
  escape from the command and arbitrary data will be executed instead.

  For more information on subprocess, shell=True and command injection
  see: https://docs.python.org/2/library/subprocess.html#frequently-
  used-arguments

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



From robert.clark at hp.com  Thu Aug 28 19:29:03 2014
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Thu, 28 Aug 2014 19:29:03 +0000
Subject: [Openstack-security] Rob Out of Office next week
Message-ID: <A0C170085C37664D93EE1604364858A11240C4D4@G4W3300.americas.hpqcorp.net>

Hi Guys,

I don't have my out of office notifications enabled for external
addresses - too much mailing list spam so please take this message as
notice that I won't be available for the next week.

If you need anything urgent you can try pinging hyakuhei at gmail

Cheers
-Rob

-------------- 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/20140828/64581170/attachment.bin>

From gerrit2 at review.openstack.org  Thu Aug 28 20:56:58 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 28 Aug 2014 20:56:58 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie19d093d0494443ce4cd880ae1f92dffd5c361ef
Message-ID: <E1XN6kc-0000JC-3h@review.openstack.org>


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

Log:
commit 4996c6de6730e7227cbd5a2de4a9707a56294965
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:53:41 2014 -0500

    token signing support alternative message digest
    
    The functions for creating signed tokens in common.cms always used
    sha256 for the message digest. This might be inadequate in the future
    so the digest algorithm shouldn't be hard-coded. A parameter is added
    to allow choosing a different digest algorithm.
    
    SecurityImpact
    
    Change-Id: Ie19d093d0494443ce4cd880ae1f92dffd5c361ef
    Related-Bug: #1362343




From gerrit2 at review.openstack.org  Thu Aug 28 20:57:35 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 28 Aug 2014 20:57:35 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I89543ccd84dd0ed0df39c4c247f354bb08adc23e
Message-ID: <E1XN6lD-0000OO-Oi@review.openstack.org>


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

Log:
commit 7c3f61c3f32ad533966af9b990c8318a88ae414c
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 18:41:27 2014 -0500

    Configurable PKI token signature digest
    
    python-keystoneclient's token signing function (cms_sign_data) was
    recently enhanced to support configuring the digest algorithm. This
    adds a configuration option to Keystone to set the digest to use.
    
    SecurityImpact
    
    DocImpact
    
    A new `message_digest_algorithm` option is added to the [token]
    section of the config file.
    
    Change-Id: I89543ccd84dd0ed0df39c4c247f354bb08adc23e
    Related-Bug: #1362343




From gerrit2 at review.openstack.org  Thu Aug 28 21:02:03 2014
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 28 Aug 2014 21:02:03 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Ie19d093d0494443ce4cd880ae1f92dffd5c361ef
Message-ID: <E1XN6pX-0000zp-Ir@review.openstack.org>


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

Log:
commit 1966cc2674d508effa6bc1fe1d3b93ea74f4f172
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Aug 27 17:53:41 2014 -0500

    token signing support alternative message digest
    
    The functions for creating signed tokens in common.cms always used
    sha256 for the message digest. This might be inadequate in the future
    so the digest algorithm shouldn't be hard-coded. A parameter is added
    to allow choosing a different digest algorithm.
    
    SecurityImpact
    
    Change-Id: Ie19d093d0494443ce4cd880ae1f92dffd5c361ef
    Related-Bug: #1362343




From yaguang.tang at canonical.com  Sun Aug 31 03:01:51 2014
From: yaguang.tang at canonical.com (Yaguang Tang)
Date: Sun, 31 Aug 2014 03:01:51 -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: <20140831030151.18605.88068.malone@soybean.canonical.com>

It's essential to have this feature available in Neutron ASAP,  It‘s
fundamental requirement for a cloud to have tenant isolation, could we
have an exception to get this in the latest release ?

-- 
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
Status in OpenStack Security Notes:
  New

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 1341954 at bugs.launchpad.net  Sun Aug 31 16:22:54 2014
From: 1341954 at bugs.launchpad.net (OpenStack Infra)
Date: Sun, 31 Aug 2014 16:22:54 -0000
Subject: [Openstack-security] [Bug 1341954] Re: suds client subject to cache
 poisoning by local attacker
References: <20140715043528.2209.47100.malonedeb@gac.canonical.com>
Message-ID: <20140831162254.29723.94194.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/116270
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=6a41fe9c5c98a14a355fa81b41aae2c4b0ce0a7b
Submitter: Jenkins
Branch:    master

commit 6a41fe9c5c98a14a355fa81b41aae2c4b0ce0a7b
Author: Vipin Balachandran <vbala at vmware.com>
Date:   Fri Aug 22 10:19:29 2014 +0530

    VMware: Disable suds caching
    
    The default cache implementation in suds store pickled objects in a
    predictable path in /tmp which could lead to attacks. This patch
    turns off suds caching to address this security issue.
    
    Change-Id: I7daaa25a0677004e03896298e9c3026d5c33c6ac
    Closes-Bug: #1341954


** Changed in: cinder
       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/1341954

Title:
  suds client subject to cache poisoning by local attacker

Status in Cinder:
  Fix Committed
Status in Gantt:
  New
Status in OpenStack Compute (Nova):
  New
Status in Oslo VMware library for OpenStack projects:
  Fix Released
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  
  The suds project appears to be largely unmaintained upstream. The default cache implementation stores pickled objects to a predictable path in /tmp. This can be used by a local attacker to redirect SOAP requests via symlinks or run a privilege escalation / code execution attack via a pickle exploit. 

  cinder/requirements.txt:suds>=0.4
  gantt/requirements.txt:suds>=0.4
  nova/requirements.txt:suds>=0.4
  oslo.vmware/requirements.txt:suds>=0.4

  
  The details are available here - 
  https://bugzilla.redhat.com/show_bug.cgi?id=978696
  (CVE-2013-2217)

  Although this is an unlikely attack vector steps should be taken to
  prevent this behaviour. Potential ways to fix this are by explicitly
  setting the cache location to a directory created via
  tempfile.mkdtemp(), disabling cache client.set_options(cache=None), or
  using a custom cache implementation that doesn't load / store pickled
  objects from an insecure location.

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