From 1472331 at bugs.launchpad.net  Mon Aug  3 06:55:03 2015
From: 1472331 at bugs.launchpad.net (Serg Melikyan)
Date: Mon, 03 Aug 2015 06:55:03 -0000
Subject: [Openstack-security] [Bug 1472331] Re: Trust id is not hidden in
	logs
References: <20150707162751.20498.27948.malonedeb@soybean.canonical.com>
Message-ID: <20150803065506.1542.82940.launchpad@wampee.canonical.com>

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

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

Title:
  Trust id is not hidden in logs

Status in murano:
  Fix Released
Status in murano kilo series:
  Fix Committed

Bug description:
  When murano creates trustes and operates with data, contains it, the
  value of trust is not hidden:

   "SystemData": {"TrustId": "d5f1261a5a4f482d9c65a01bd385255b"}},
  "token": "*** SANITIZED ***",

  Need to use *** like it's done with token

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



From 1464219 at bugs.launchpad.net  Mon Aug  3 06:54:52 2015
From: 1464219 at bugs.launchpad.net (Serg Melikyan)
Date: Mon, 03 Aug 2015 06:54:52 -0000
Subject: [Openstack-security] [Bug 1464219] Re: [api] there are no checks of
 request tenant_id during abandoning of an environment
References: <20150611110620.13354.78142.malonedeb@wampee.canonical.com>
Message-ID: <20150803065454.6096.15271.launchpad@gac.canonical.com>

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

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

Title:
  [api] there are no checks of request tenant_id during abandoning of an
  environment

Status in murano:
  Fix Released

Bug description:
  Looks like the code currently does not check, that a given env belongs
  to current requests tenant.

  Therefore it might be possible for users from different tenants to
  delete/deploy environments.

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



From gerrit2 at review.openstack.org  Mon Aug  3 21:34:46 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 03 Aug 2015 21:34:46 +0000
Subject: [Openstack-security] [openstack/ceilometer-specs] SecurityImpact
 review request change Id25d154eac90e14c5501f806e81e04a059f5a836
Message-ID: <E1ZMNNe-0002xY-Tk@review.openstack.org>


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

Log:
commit cb6397064681d9f55ec91a05d6c6f728dcf0c5cf
Author: Matthew Edmonds <edmondsw at us.ibm.com>
Date:   Wed Jul 29 13:45:23 2015 -0400

    Events RBAC via Policy
    
    OpenStack needs to support granular, customizable Role-Based Access
    Control (RBAC) for ceilometer events. Policy should be dependent on
    policy.json rather than simply hard-coded.
    
    APIImpact
    SecurityImpact
    UpgradeImpact
    
    Change-Id: Id25d154eac90e14c5501f806e81e04a059f5a836




From elena.reshetova at intel.com  Tue Aug  4 17:01:57 2015
From: elena.reshetova at intel.com (Reshetova, Elena)
Date: Tue, 4 Aug 2015 17:01:57 +0000
Subject: [Openstack-security] Would people see a value in the cve-check-tool?
Message-ID: <2236FBA76BA1254E88B949DDB74E612B418EAC44@IRSMSX102.ger.corp.intel.com>

Hi,

 

Sorry for the double posting, I have got a recommendation to send this to
the security mailing list also and not to the dev one.

 

We would like to ask opinions if people find it valuable to include a
cve-check-tool into the OpenStack continuous integration process? 

A tool can be run against the package and module dependencies of OpenStack
components and detect any CVEs (in future there are also plans to integrate
more functionality to the tool, such as scanning of other vulnerability
databases and etc.). It would not only provide fast detection of new
vulnerabilities that are being released for existing dependencies, but also
control that people are not introducing new vulnerable dependencies. 

 

The tool is located here: https://github.com/ikeydoherty/cve-check-tool

 

I am attaching an example of a very simple Python wrapper for the tool,
which is able to process formats like:
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.
txt

and an example of html output if you would be running it for the python
module requests 2.2.1 version (which is vulnerable to 3 CVEs). 

 

Best Regards,
Elena.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/bac955fc/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/bac955fc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CVECheckTool.py
Type: application/octet-stream
Size: 3858 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/bac955fc/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CVECheckToolTest.py
Type: application/octet-stream
Size: 180 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/bac955fc/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7586 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/bac955fc/attachment.bin>

From gerrit2 at review.openstack.org  Tue Aug  4 17:15:22 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 04 Aug 2015 17:15:22 +0000
Subject: [Openstack-security] [openstack/ceilometer-specs] SecurityImpact
 review request change Id25d154eac90e14c5501f806e81e04a059f5a836
Message-ID: <E1ZMfoA-0001bn-W3@review.openstack.org>


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

Log:
commit 917d20718bfcfd51579dd40dd2d89f5a8d81372e
Author: Matthew Edmonds <edmondsw at us.ibm.com>
Date:   Wed Jul 29 13:45:23 2015 -0400

    Events RBAC via Policy
    
    OpenStack needs to support granular, customizable Role-Based Access
    Control (RBAC) for ceilometer events. Policy should be dependent on
    policy.json rather than simply hard-coded.
    
    APIImpact
    SecurityImpact
    UpgradeImpact
    
    Change-Id: Id25d154eac90e14c5501f806e81e04a059f5a836




From tnurlygayanov at mirantis.com  Tue Aug  4 17:19:36 2015
From: tnurlygayanov at mirantis.com (Timur Nurlygayanov)
Date: Tue, 4 Aug 2015 20:19:36 +0300
Subject: [Openstack-security] Would people see a value in the
	cve-check-tool?
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B418EAC44@IRSMSX102.ger.corp.intel.com>
References: <2236FBA76BA1254E88B949DDB74E612B418EAC44@IRSMSX102.ger.corp.intel.com>
Message-ID: <CAHCYybPq==7PPJDPcHRcr1E=Uv-_v=46VNcz=wJGNeoeS6UuEw@mail.gmail.com>

Hi Elena,

I like the idea, probably we can prepare some scripts which will allow to
run this tool for any OpenStack components like it is done for Bandit tool
[1].

[1] https://github.com/openstack/bandit

On Tue, Aug 4, 2015 at 8:01 PM, Reshetova, Elena <elena.reshetova at intel.com>
wrote:

> Hi,
>
>
>
> Sorry for the double posting, I have got a recommendation to send this to
> the security mailing list also and not to the dev one.
>
>
>
> We would like to ask opinions if people find it valuable to include a
> cve-check-tool into the OpenStack continuous integration process?
>
> A tool can be run against the package and module dependencies of OpenStack
> components and detect any CVEs (in future there are also plans to integrate
> more functionality to the tool, such as scanning of other vulnerability
> databases and etc.). It would not only provide fast detection of new
> vulnerabilities that are being released for existing dependencies, but also
> control that people are not introducing new vulnerable dependencies.
>
>
>
> The tool is located here: https://github.com/ikeydoherty/cve-check-tool
>
>
>
> I am attaching an example of a very simple Python wrapper for the tool,
> which is able to process formats like:
> http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
>
> and an example of html output if you would be running it for the python
> module requests 2.2.1 version (which is vulnerable to 3 CVEs).
>
>
>
> Best Regards,
> Elena.
>
>
>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>


-- 

Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/3b02bebc/attachment.html>

From robert.clark at hp.com  Tue Aug  4 17:51:18 2015
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 4 Aug 2015 17:51:18 +0000
Subject: [Openstack-security] Would people see a value in
	the	cve-check-tool?
In-Reply-To: <CAHCYybPq==7PPJDPcHRcr1E=Uv-_v=46VNcz=wJGNeoeS6UuEw@mail.gmail.com>
References: <2236FBA76BA1254E88B949DDB74E612B418EAC44@IRSMSX102.ger.corp.intel.com>
 <CAHCYybPq==7PPJDPcHRcr1E=Uv-_v=46VNcz=wJGNeoeS6UuEw@mail.gmail.com>
Message-ID: <A0C170085C37664D93EE1604364858A11FDD4239@G9W0763.americas.hpqcorp.net>

Can you move this over to OpenStack Development Mailing List (openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>) with the [Security] tag please?

We’re trying to wind down the security ML.

-Rob

From: Timur Nurlygayanov [mailto:tnurlygayanov at mirantis.com]
Sent: 04 August 2015 18:20
To: Reshetova, Elena
Cc: openstack-security at lists.openstack.org; Heath, Constanza M; Ding, Jian-feng
Subject: Re: [Openstack-security] Would people see a value in the cve-check-tool?

Hi Elena,
I like the idea, probably we can prepare some scripts which will allow to run this tool for any OpenStack components like it is done for Bandit tool [1].

[1] https://github.com/openstack/bandit

On Tue, Aug 4, 2015 at 8:01 PM, Reshetova, Elena <elena.reshetova at intel.com<mailto:elena.reshetova at intel.com>> wrote:
Hi,

Sorry for the double posting, I have got a recommendation to send this to the security mailing list also and not to the dev one.

We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process?
A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies.

The tool is located here: https://github.com/ikeydoherty/cve-check-tool

I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs).

Best Regards,
Elena.



_______________________________________________
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



--

Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/d28bd625/attachment.html>

From travis.mcpeak at hp.com  Tue Aug  4 17:56:32 2015
From: travis.mcpeak at hp.com (McPeak, Travis)
Date: Tue, 4 Aug 2015 17:56:32 +0000
Subject: [Openstack-security] Openstack-security Digest, Vol 30, Issue 4
In-Reply-To: <mailman.16400.1438708524.14112.openstack-security@lists.openstack.org>
References: <mailman.16400.1438708524.14112.openstack-security@lists.openstack.org>
Message-ID: <D1E65852.51C9%travis.mcpeak@hp.com>

Hi Elena,

IMO this would make a great gate process. In particular if cve-check were
implemented as a gate in requirements, we could detect when a new
vulnerable
version of a project is made available for use in OpenStack.

Have you run the tool against the current requirements list?  I¹d be
curious to see what the baseline results look like.

Thanks,
 -Travis

On 8/4/15, 11:15 AM, "openstack-security-request at lists.openstack.org"
<openstack-security-request at lists.openstack.org> wrote:

>Sorry for the double posting, I have got a recommendation to send this to
>the security mailing list also and not to the dev one.
>
>
>We would like to ask opinions if people find it valuable to include a
>cve-check-tool into the OpenStack continuous integration process?
>
>A tool can be run against the package and module dependencies of OpenStack
>components and detect any CVEs (in future there are also plans to
>integrate
>more functionality to the tool, such as scanning of other vulnerability
>databases and etc.). It would not only provide fast detection of new
>vulnerabilities that are being released for existing dependencies, but
>also
>control that people are not introducing new vulnerable dependencies.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2751 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/90ba98f4/attachment.bin>

From elena.reshetova at intel.com  Tue Aug  4 17:59:30 2015
From: elena.reshetova at intel.com (Reshetova, Elena)
Date: Tue, 4 Aug 2015 17:59:30 +0000
Subject: [Openstack-security] Would people see a value in
	the	cve-check-tool?
In-Reply-To: <A0C170085C37664D93EE1604364858A11FDD4239@G9W0763.americas.hpqcorp.net>
References: <2236FBA76BA1254E88B949DDB74E612B418EAC44@IRSMSX102.ger.corp.intel.com>
 <CAHCYybPq==7PPJDPcHRcr1E=Uv-_v=46VNcz=wJGNeoeS6UuEw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A11FDD4239@G9W0763.americas.hpqcorp.net>
Message-ID: <2236FBA76BA1254E88B949DDB74E612B418EAD35@IRSMSX102.ger.corp.intel.com>

Funny, I originally posted it to the OpenStack Development Mailing List, but I got suggestion to post it to the security ML instead. 

Anyway, now I have this request in both places… 

 

Best Regards,
Elena.

 

From: Clark, Robert Graham [mailto:robert.clark at hp.com] 
Sent: Tuesday, August 4, 2015 10:51 AM
To: Timur Nurlygayanov; Reshetova, Elena
Cc: openstack-security at lists.openstack.org; Heath, Constanza M; Ding, Jian-feng
Subject: RE: [Openstack-security] Would people see a value in the cve-check-tool?

 

Can you move this over to OpenStack Development Mailing List (openstack-dev at lists.openstack.org <mailto:openstack-dev at lists.openstack.org> ) with the [Security] tag please?

 

We’re trying to wind down the security ML.

 

-Rob

 

From: Timur Nurlygayanov [mailto:tnurlygayanov at mirantis.com] 
Sent: 04 August 2015 18:20
To: Reshetova, Elena
Cc: openstack-security at lists.openstack.org <mailto:openstack-security at lists.openstack.org> ; Heath, Constanza M; Ding, Jian-feng
Subject: Re: [Openstack-security] Would people see a value in the cve-check-tool?

 

Hi Elena,

I like the idea, probably we can prepare some scripts which will allow to run this tool for any OpenStack components like it is done for Bandit tool [1].

[1] https://github.com/openstack/bandit

 

On Tue, Aug 4, 2015 at 8:01 PM, Reshetova, Elena <elena.reshetova at intel.com <mailto:elena.reshetova at intel.com> > wrote:

Hi,

 

Sorry for the double posting, I have got a recommendation to send this to the security mailing list also and not to the dev one.

 

We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process? 

A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies. 

 

The tool is located here: https://github.com/ikeydoherty/cve-check-tool

 

I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt

and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs). 

 

Best Regards,
Elena.

 

 


_______________________________________________
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




-- 

 

Timur,

Senior QA Engineer

OpenStack Projects

Mirantis Inc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/a1240c82/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7586 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/a1240c82/attachment.bin>

From robert.clark at hp.com  Tue Aug  4 17:59:00 2015
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Tue, 4 Aug 2015 17:59:00 +0000
Subject: [Openstack-security] Would people see a value
	in	the	cve-check-tool?
In-Reply-To: <A0C170085C37664D93EE1604364858A11FDD4239@G9W0763.americas.hpqcorp.net>
References: <2236FBA76BA1254E88B949DDB74E612B418EAC44@IRSMSX102.ger.corp.intel.com>
 <CAHCYybPq==7PPJDPcHRcr1E=Uv-_v=46VNcz=wJGNeoeS6UuEw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A11FDD4239@G9W0763.americas.hpqcorp.net>
Message-ID: <A0C170085C37664D93EE1604364858A11FDD4267@G9W0763.americas.hpqcorp.net>

Sorry, didn’t see the note re:doublepost – I’ll reply on the main thread.
-Rob

From: Clark, Robert Graham
Sent: 04 August 2015 18:51
To: Timur Nurlygayanov; Reshetova, Elena
Cc: openstack-security at lists.openstack.org; Heath, Constanza M; Ding, Jian-feng
Subject: Re: [Openstack-security] Would people see a value in the cve-check-tool?

Can you move this over to OpenStack Development Mailing List (openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>) with the [Security] tag please?

We’re trying to wind down the security ML.

-Rob

From: Timur Nurlygayanov [mailto:tnurlygayanov at mirantis.com]
Sent: 04 August 2015 18:20
To: Reshetova, Elena
Cc: openstack-security at lists.openstack.org<mailto:openstack-security at lists.openstack.org>; Heath, Constanza M; Ding, Jian-feng
Subject: Re: [Openstack-security] Would people see a value in the cve-check-tool?

Hi Elena,
I like the idea, probably we can prepare some scripts which will allow to run this tool for any OpenStack components like it is done for Bandit tool [1].

[1] https://github.com/openstack/bandit

On Tue, Aug 4, 2015 at 8:01 PM, Reshetova, Elena <elena.reshetova at intel.com<mailto:elena.reshetova at intel.com>> wrote:
Hi,

Sorry for the double posting, I have got a recommendation to send this to the security mailing list also and not to the dev one.

We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process?
A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies.

The tool is located here: https://github.com/ikeydoherty/cve-check-tool

I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs).

Best Regards,
Elena.



_______________________________________________
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



--

Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150804/87248981/attachment.html>

From vryzhenkin at mirantis.com  Tue Aug  4 18:07:27 2015
From: vryzhenkin at mirantis.com (Victor Ryzhenkin)
Date: Tue, 4 Aug 2015 21:07:27 +0300
Subject: [Openstack-security] Would people see a value in the
 cve-check-tool?
In-Reply-To: <2236FBA76BA1254E88B949DDB74E612B418EAD35@IRSMSX102.ger.corp.intel.com>
References: <2236FBA76BA1254E88B949DDB74E612B418EAC44@IRSMSX102.ger.corp.intel.com>
 <CAHCYybPq==7PPJDPcHRcr1E=Uv-_v=46VNcz=wJGNeoeS6UuEw@mail.gmail.com>
 <A0C170085C37664D93EE1604364858A11FDD4239@G9W0763.americas.hpqcorp.net>
 <2236FBA76BA1254E88B949DDB74E612B418EAD35@IRSMSX102.ger.corp.intel.com>
Message-ID: <etPan.55c0ff5f.56333c20.167@pegasus.local>

Hi folks!

Idea really looks good.

I am attaching an example of a very simple Python wrapper for the tool


Looks like this wrapper is lightweight. But maybe try to integrate it with Bandit and not to create a new tool?

-- 
Victor Ryzhenkin
freerunner on #freenode

Включено 4 августа 2015 г. в 21:04:39, Reshetova, Elena (elena.reshetova at intel.com) написал:

Funny, I originally posted it to the OpenStack Development Mailing List, but I got suggestion to post it to the security ML instead.

Anyway, now I have this request in both places…

 

Best Regards,
Elena.

 

From: Clark, Robert Graham [mailto:robert.clark at hp.com]
Sent: Tuesday, August 4, 2015 10:51 AM
To: Timur Nurlygayanov; Reshetova, Elena
Cc: openstack-security at lists.openstack.org; Heath, Constanza M; Ding, Jian-feng
Subject: RE: [Openstack-security] Would people see a value in the cve-check-tool?

 

Can you move this over to OpenStack Development Mailing List (openstack-dev at lists.openstack.org) with the [Security] tag please?

 

We’re trying to wind down the security ML.

 

-Rob

 

From: Timur Nurlygayanov [mailto:tnurlygayanov at mirantis.com]
Sent: 04 August 2015 18:20
To: Reshetova, Elena
Cc: openstack-security at lists.openstack.org; Heath, Constanza M; Ding, Jian-feng
Subject: Re: [Openstack-security] Would people see a value in the cve-check-tool?

 

Hi Elena,

I like the idea, probably we can prepare some scripts which will allow to run this tool for any OpenStack components like it is done for Bandit tool [1].

[1] https://github.com/openstack/bandit

 

On Tue, Aug 4, 2015 at 8:01 PM, Reshetova, Elena <elena.reshetova at intel.com> wrote:

Hi,

 

Sorry for the double posting, I have got a recommendation to send this to the security mailing list also and not to the dev one.

 

We would like to ask opinions if people find it valuable to include a cve-check-tool into the OpenStack continuous integration process?

A tool can be run against the package and module dependencies of OpenStack components and detect any CVEs (in future there are also plans to integrate more functionality to the tool, such as scanning of other vulnerability databases and etc.). It would not only provide fast detection of new vulnerabilities that are being released for existing dependencies, but also control that people are not introducing new vulnerable dependencies.

 

The tool is located here: https://github.com/ikeydoherty/cve-check-tool

 

I am attaching an example of a very simple Python wrapper for the tool, which is able to process formats like: http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt

and an example of html output if you would be running it for the python module requests 2.2.1 version (which is vulnerable to 3 CVEs).

 

Best Regards,
Elena.

 

 


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




--

 

Timur,

Senior QA Engineer

OpenStack Projects

Mirantis Inc

_______________________________________________  
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/20150804/b452bfa5/attachment.html>

From 1274034 at bugs.launchpad.net  Tue Aug  4 20:19:36 2015
From: 1274034 at bugs.launchpad.net (Chet Burgess)
Date: Tue, 04 Aug 2015 20:19:36 -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: <20150804201937.1632.34028.malone@wampee.canonical.com>

I don't know if upstream want a back port to juno but for people who
want a patch, attached is a patch against the latest stable/juno.  I'm
happy to submit this as a review to stable/juno if upstream things it
back port worth.

NOTE: I don't have a facility for running the functional tests, and the
structure seems to have changed quite a bit between master and juno. As
a result I didn't back port the functional tests from master but I did
write unit tests for juno.


** Patch added: "juno backport"
   https://bugs.launchpad.net/neutron/+bug/1274034/+attachment/4439215/+files/0001-Add-ARP-spoofing-protection-for-LinuxBridge-agent.patch

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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 1274034 at bugs.launchpad.net  Wed Aug  5 18:51:20 2015
From: 1274034 at bugs.launchpad.net (Kevin Benton)
Date: Wed, 05 Aug 2015 18:51:20 -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: <20150805185120.2068.18666.malone@wampee.canonical.com>

submit it to gerrit and I will help review it. I think an argument can
be made in its favor.

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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 1274034 at bugs.launchpad.net  Wed Aug  5 23:02:23 2015
From: 1274034 at bugs.launchpad.net (Chet Burgess)
Date: Wed, 05 Aug 2015 23:02:23 -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: <20150805230223.6231.43251.malone@gac.canonical.com>

OK I will work on that in the next day or two.

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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 1274034 at bugs.launchpad.net  Wed Aug  5 23:28:48 2015
From: 1274034 at bugs.launchpad.net (Kevin Benton)
Date: Wed, 05 Aug 2015 23:28: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: <20150805232848.1789.2240.malone@wampee.canonical.com>

thanks, when you do be sure to upload it under change-id:
I0b0e3b1272472385dff060897ecbd25e93fd78e7 so its easy to find from the
original.

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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 1274034 at bugs.launchpad.net  Wed Aug  5 23:42:29 2015
From: 1274034 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 05 Aug 2015 23:42:29 -0000
Subject: [Openstack-security] [Bug 1274034] Fix proposed to neutron
	(stable/kilo)
References: <20140129101504.12361.90017.malonedeb@gac.canonical.com>
Message-ID: <20150805234229.5996.22134.malone@gac.canonical.com>

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/209705

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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 1274034 at bugs.launchpad.net  Wed Aug  5 23:56:46 2015
From: 1274034 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 05 Aug 2015 23:56:46 -0000
Subject: [Openstack-security] [Bug 1274034] Fix proposed to neutron
	(stable/juno)
References: <20140129101504.12361.90017.malonedeb@gac.canonical.com>
Message-ID: <20150805235646.25398.38424.malone@chaenomeles.canonical.com>

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/209707

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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 1274034 at bugs.launchpad.net  Wed Aug  5 23:58:16 2015
From: 1274034 at bugs.launchpad.net (Chet Burgess)
Date: Wed, 05 Aug 2015 23:58:16 -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: <20150805235816.24365.78831.malone@soybean.canonical.com>

Opps.. let me go fix the change ID. Sorry.

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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 1274034 at bugs.launchpad.net  Wed Aug  5 23:59:53 2015
From: 1274034 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 05 Aug 2015 23:59:53 -0000
Subject: [Openstack-security] [Bug 1274034] Fix proposed to neutron
	(stable/juno)
References: <20140129101504.12361.90017.malonedeb@gac.canonical.com>
Message-ID: <20150805235953.1601.94495.malone@wampee.canonical.com>

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/209708

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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 1274034 at bugs.launchpad.net  Wed Aug  5 23:59:59 2015
From: 1274034 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 05 Aug 2015 23:59:59 -0000
Subject: [Openstack-security] [Bug 1274034] Change abandoned on neutron
	(stable/juno)
References: <20140129101504.12361.90017.malonedeb@gac.canonical.com>
Message-ID: <20150805235959.24459.21042.malone@soybean.canonical.com>

Change abandoned by Chet Burgess (cfb at metacloud.com) on branch: stable/juno
Review: https://review.openstack.org/209707
Reason: Replaced by https://review.openstack.org/#/c/209708/

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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 1274034 at bugs.launchpad.net  Thu Aug  6 00:00:05 2015
From: 1274034 at bugs.launchpad.net (Chet Burgess)
Date: Thu, 06 Aug 2015 00:00: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: <20150806000005.6132.21842.malone@gac.canonical.com>

OK fixed.

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

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

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Invalid
Status in OpenStack Security Notes:
  Fix Released

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

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

  This is a security vulnerability, especially on shared networks.

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

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

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



From gerrit2 at review.openstack.org  Thu Aug  6 10:26:56 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 10:26:56 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9
Message-ID: <E1ZNIO0-0004BW-VN@review.openstack.org>


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

Log:
commit d3843ce61bc9062002fe845a96f394a58d4c1064
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Mon Jul 6 01:51:26 2015 -0700

    libvirt: Kill rsync/scp processes before deleting instance
    
    In the resize operation, during copying files from source to
    destination compute node scp/rsync processes are not aborted after
    the instance is deleted because linux kernel doesn't delete instance
    files physically until all processes using the file handle is closed
    completely. Hence rsync/scp process keeps on running until it
    transfers 100% of file data.
    
    Added new module instancejobtracker to libvirt driver which will add,
    remove or terminate the processes running against particular instances.
    Added callback methods to execute call which will store the pid of
    scp/rsync process in cache as a key: value pair and to remove the
    pid from the cache after process completion. Process id will be used to
    kill the process if it is running while deleting the instance. Instance
    uuid is used as a key in the cache and pid will be the value.
    
    Conflicts:
            nova/virt/libvirt/driver.py
    
    SecurityImpact
    
    Closes-bug: #1387543
    Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9
    (cherry picked from commit 7ab75d5b0b75fc3426323bef19bf436a258b9707)




From gerrit2 at review.openstack.org  Thu Aug  6 11:30:18 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 11:30:18 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ic0780a0d1ccf96c14f1e0ad9c3e9b23e2b0db0ea
Message-ID: <E1ZNJNK-0001lC-TL@review.openstack.org>


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

Log:
commit 97ed4d2d785ea2dd4f14ee4dda9f7ef475f93a4f
Author: Eli Qiao <liyong.qiao at intel.com>
Date:   Thu Jun 4 10:05:33 2015 +0800

    Add missing rules in policy.json
    
    'etc/nova/policy.json' is sample file for polcy configration. But
    there are a lot of rule missing in it. The user is hard to find
    out which rule can be used in nova.
    
    This patch adds the missing rule back to policy.json. Also adds a
    test case to veify the contents of policy.
    
    SecurityImpact
    UpgradeImpact:
    "os_compute_api:servers:create:forced_host" is missing in policy.json.
    That means it will be default rule. But actually it should be admin
    only API. This patch adds this rule back to policy.json and with
    correct rule. Deployer should update their policy.json to match the
    original permission also.
    
    Co-Authored-By: Alex Xu <hejie.xu at intel.com>
    
    Closes-Bug: #1435390
    Change-Id: Ic0780a0d1ccf96c14f1e0ad9c3e9b23e2b0db0ea




From gerrit2 at review.openstack.org  Thu Aug  6 11:36:04 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 11:36:04 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9
Message-ID: <E1ZNJSu-00030O-6V@review.openstack.org>


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

Log:
commit b5020a047fc487f35b76fc05f31e52665a1afda1
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Mon Jul 6 01:51:26 2015 -0700

    libvirt: Kill rsync/scp processes before deleting instance
    
    In the resize operation, during copying files from source to
    destination compute node scp/rsync processes are not aborted after
    the instance is deleted because linux kernel doesn't delete instance
    files physically until all processes using the file handle is closed
    completely. Hence rsync/scp process keeps on running until it
    transfers 100% of file data.
    
    Added new module instancejobtracker to libvirt driver which will add,
    remove or terminate the processes running against particular instances.
    Added callback methods to execute call which will store the pid of
    scp/rsync process in cache as a key: value pair and to remove the
    pid from the cache after process completion. Process id will be used to
    kill the process if it is running while deleting the instance. Instance
    uuid is used as a key in the cache and pid will be the value.
    
    Conflicts:
            nova/virt/libvirt/driver.py
    
    SecurityImpact
    
    Closes-bug: #1387543
    Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9
    (cherry picked from commit 7ab75d5b0b75fc3426323bef19bf436a258b9707)




From gerrit2 at review.openstack.org  Thu Aug  6 12:01:35 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 12:01:35 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7
Message-ID: <E1ZNJrb-0000P4-2l@review.openstack.org>


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

Log:
commit d2d6aba069ea3101dfbc3363689eb6142ffb6d1f
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:10:57 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Add a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of
    time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Conflicts:
            keystone/common/config.py
            keystone/common/environment/eventlet_server.py
    
    NOTE: This is not 1:1 cherry-pick because 'eventlet_server' config
    group is not present in juno.
    
    Closes-Bug: #1361360
    Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7
    (cherry picked from commit 3b08644eb9cf4c5aca51a36250ae93105c17f6c4)
    (cherry picked from commit 67cda0ccae04471340bcada099d945d90979e64d)




From gerrit2 at review.openstack.org  Thu Aug  6 12:35:58 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 12:35:58 +0000
Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review
 request change Ia8e7fcc21d7c15e480facbe30af88cdce2d73159
Message-ID: <E1ZNKOs-0006nW-Vy@review.openstack.org>


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

Log:
commit 284e533c3d801cf434c8159ddf049c0e064e9b59
Author: Dane Fichter <dane.fichter at jhuapl.edu>
Date:   Fri Jun 5 13:25:11 2015 -0400

    Nova Support of Glance Image Signing
    
    This spec is related to work in the Glance project which handles
    signed images.
    
    SecurityImpact
    DocImpact
    
    It depends on this glance spec:
    Depends-On: I305b2ae86415c8d256c641abb2795af663bee56a
    
    Change-Id: Ia8e7fcc21d7c15e480facbe30af88cdce2d73159
    Implements: blueprint nova-support-image-signing




From gerrit2 at review.openstack.org  Thu Aug  6 13:03:08 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 13:03:08 +0000
Subject: [Openstack-security] [openstack/nova-specs] SecurityImpact review
 request change Ia8e7fcc21d7c15e480facbe30af88cdce2d73159
Message-ID: <E1ZNKpA-00054e-9U@review.openstack.org>


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

Log:
commit bc25865bc9cb222ab9a69391a9ee5e74b9e0075d
Author: Dane Fichter <dane.fichter at jhuapl.edu>
Date:   Fri Jun 5 13:25:11 2015 -0400

    Nova Support of Glance Image Signing
    
    This spec is related to work in the Glance project which handles
    signed images.
    
    SecurityImpact
    DocImpact
    
    It depends on this glance spec:
    Depends-On: I305b2ae86415c8d256c641abb2795af663bee56a
    
    Change-Id: Ia8e7fcc21d7c15e480facbe30af88cdce2d73159
    Implements: blueprint nova-support-image-signing




From gerrit2 at review.openstack.org  Thu Aug  6 16:56:51 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 16:56:51 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change Ie68afe7610a414bbcc42ff3bee33a9779303c115
Message-ID: <E1ZNOTL-0004hL-5M@review.openstack.org>


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

Log:
commit da1ccf5dcf663cff310ac7031e6f7a08431a771e
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:29:28 2015 +0000

    Add mechanism to limit Request ID size
    
    Adding 'max_request_id_length' defaulting to 0 for backportability.
    
    DocImpact
    SecurityImpact
    
    Closes-Bug: #1482301
    Change-Id: Ie68afe7610a414bbcc42ff3bee33a9779303c115




From gerrit2 at review.openstack.org  Thu Aug  6 16:56:58 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 16:56:58 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I52ebf810f4699826baa2bdf91d28e24d902cf950
Message-ID: <E1ZNOTS-0004i6-JI@review.openstack.org>


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

Log:
commit 51d140dbd8799ec4248985e9226afa9c5efeebfe
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:33:07 2015 +0000

    Setting default max_request_id_length to 64
    
    Setting sensible maximum size for Request ID. 64 should be enough for
    normal use cases but limited enough from current 16384 to not flood
    the logs by malicious requests.
    
    DocImpact
    SecurityImpact
    
    Related-to-bug: #1482301
    Change-Id: I52ebf810f4699826baa2bdf91d28e24d902cf950




From gerrit2 at review.openstack.org  Thu Aug  6 17:16:43 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 17:16:43 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change Ie68afe7610a414bbcc42ff3bee33a9779303c115
Message-ID: <E1ZNOmZ-0000kh-7Q@review.openstack.org>


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

Log:
commit f1cc07d43764c7d3e6aea5abfd571df92b7ada00
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:29:28 2015 +0000

    Add mechanism to limit Request ID size
    
    Adding 'max_request_id_length' defaulting to 0 for backportability.
    
    DocImpact
    SecurityImpact
    
    Conflicts:
    	doc/source/configuring.rst
    	glance/api/middleware/context.py
    
    Closes-Bug: #1482301
    Change-Id: Ie68afe7610a414bbcc42ff3bee33a9779303c115
    (cherry picked from commit da1ccf5dcf663cff310ac7031e6f7a08431a771e)




From gerrit2 at review.openstack.org  Thu Aug  6 17:17:50 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 17:17:50 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change Ie68afe7610a414bbcc42ff3bee33a9779303c115
Message-ID: <E1ZNOne-0000wY-Ls@review.openstack.org>


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

Log:
commit 4fa9a38999a1900f8b297c21e6d48222359046cf
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:29:28 2015 +0000

    Add mechanism to limit Request ID size
    
    Adding 'max_request_id_length' defaulting to 0 for backportability.
    
    DocImpact
    SecurityImpact
    
    Conflicts:
    	glance/api/middleware/context.py
    
    Closes-Bug: #1482301
    Change-Id: Ie68afe7610a414bbcc42ff3bee33a9779303c115
    (cherry picked from commit da1ccf5dcf663cff310ac7031e6f7a08431a771e)




From 1246160 at bugs.launchpad.net  Thu Aug  6 19:31:12 2015
From: 1246160 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 06 Aug 2015 19:31:12 -0000
Subject: [Openstack-security] [Bug 1246160] Re: shuffle method bring
	potential security issue
References: <20131030014106.17323.98896.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150806193112.25198.18660.malone@chaenomeles.canonical.com>

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

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

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

Title:
  shuffle method bring potential security issue

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Invalid

Bug description:
  In the /nova/utils.py, line 328, the source code is below

              r.shuffle(password)

  This code is using shuffle method to generate a random number,
  Standard random number generators should not be used to generate
  randomness used for security reasons. For security sensitive
  randomness a crytographic randomness generator that provides
  sufficient entropy should be used.

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



From gerrit2 at review.openstack.org  Thu Aug  6 21:40:54 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 21:40:54 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I52ebf810f4699826baa2bdf91d28e24d902cf950
Message-ID: <E1ZNSuE-0006HZ-I9@review.openstack.org>


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

Log:
commit b5b031fbeefc584681a67a0143f6c331e44696b8
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:33:07 2015 +0000

    Setting default max_request_id_length to 64
    
    Setting sensible maximum size for Request ID. 64 should be enough for
    normal use cases but limited enough from current 16384 to not flood
    the logs by malicious requests.
    
    DocImpact
    SecurityImpact
    
    Related-to-bug: #1482301
    Change-Id: I52ebf810f4699826baa2bdf91d28e24d902cf950




From gerrit2 at review.openstack.org  Thu Aug  6 21:41:01 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 21:41:01 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change Ie68afe7610a414bbcc42ff3bee33a9779303c115
Message-ID: <E1ZNSuL-0006JR-QF@review.openstack.org>


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

Log:
commit bff1d6fc204e8eba7642ee798462d11120ea1acb
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:29:28 2015 +0000

    Add mechanism to limit Request ID size
    
    Adding 'max_request_id_length' defaulting to 0 for backportability.
    
    DocImpact
    SecurityImpact
    
    Closes-Bug: #1482301
    Change-Id: Ie68afe7610a414bbcc42ff3bee33a9779303c115




From gerrit2 at review.openstack.org  Thu Aug  6 22:03:47 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 06 Aug 2015 22:03:47 +0000
Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review
 request change I305b2ae86415c8d256c641abb2795af663bee56a
Message-ID: <E1ZNTGN-0002EJ-0f@review.openstack.org>


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

Log:
commit 17eda5ab4e2b1dcc54f2d1a7956b471542bd75f1
Author: Brianna Poulos <Brianna.Poulos at jhuapl.edu>
Date:   Mon Apr 27 15:35:51 2015 -0400

    Image Signing and Verification Support
    
    This spec describes a means to support signing and signature
    validation of bootable images.
    
    DocImpact
    SecurityImpact
    
    Implements: blueprint image-signing-and-verification-support
    Change-Id: I305b2ae86415c8d256c641abb2795af663bee56a




From gerrit2 at review.openstack.org  Fri Aug  7 13:14:17 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 07 Aug 2015 13:14:17 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Idbe37922c5f944e3d567ce16913ce5d87af41fef
Message-ID: <E1ZNhTV-0005L1-D4@review.openstack.org>


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

Log:
commit ea548525a696b984891ecd9de741581c39e67835
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Aug 6 17:26:12 2015 -0400

    libvirt: Disconnect dm-crypt on instance suspend/stop
    
    Strengthens protection provided by ephemeral storage encryption
    feature by disconnecting the dm-crypt device, which provides
    access to unencrypted disk, when an encrypted instance is
    suspended or stopped.
    
    Co-Authored-By: Joel Coffman <joel.coffman at jhuapl.edu>
    
    Implements: blueprint stop-dmcrypt-on-suspend
    SecurityImpact
    
    Change-Id: Idbe37922c5f944e3d567ce16913ce5d87af41fef




From 1447679 at bugs.launchpad.net  Fri Aug  7 13:20:36 2015
From: 1447679 at bugs.launchpad.net (Daniel Berrange)
Date: Fri, 07 Aug 2015 13:20:36 -0000
Subject: [Openstack-security] [Bug 1447679] Re: service No-VNC (port 6080)
 doesn't require authentication
References: <20150423154044.13260.70404.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150807132036.25632.74324.malone@chaenomeles.canonical.com>

NB, with any discussion regarding consoles it is important to remember
that SPICE consoles involve the opening of many TCP connections (as many
as 10 separate connections). So if you make tokens single-use it will
break SPICE, so I don't think that's really a viable approach.

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

Title:
  service No-VNC (port 6080) doesn't require authentication

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Reported via private E-mail from Anass ANNOUR:

  I found that the service No-VNC (port 6080) doesn't require
  authentication, if you know the URL (ex:
  http://192.168.198.164:6080/vnc_auto.html?token=3640a3c8-ad10-45da-a523-18d3793ef8ec)
  you can access the machine from any other computer without any
  authentication before the token expires. (or in the same time as user
  still use the console)

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



From 1246160 at bugs.launchpad.net  Fri Aug  7 14:24:55 2015
From: 1246160 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 07 Aug 2015 14:24:55 -0000
Subject: [Openstack-security] [Bug 1246160] Re: shuffle method bring
	potential security issue
References: <20131030014106.17323.98896.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150807142456.25074.42783.launchpad@chaenomeles.canonical.com>

** Changed in: nova
     Assignee: Cale Rath (ctrath) => Alexis Lee (alexisl)

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

Title:
  shuffle method bring potential security issue

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Invalid

Bug description:
  In the /nova/utils.py, line 328, the source code is below

              r.shuffle(password)

  This code is using shuffle method to generate a random number,
  Standard random number generators should not be used to generate
  randomness used for security reasons. For security sensitive
  randomness a crytographic randomness generator that provides
  sufficient entropy should be used.

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



From gerrit2 at review.openstack.org  Fri Aug  7 15:53:43 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 07 Aug 2015 15:53:43 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I52ebf810f4699826baa2bdf91d28e24d902cf950
Message-ID: <E1ZNjxn-0008Lx-8P@review.openstack.org>


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

Log:
commit 74baef917be98af86c92068e9f15eadef6860b94
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:33:07 2015 +0000

    Setting default max_request_id_length to 64
    
    Setting sensible maximum size for Request ID. 64 should be enough for
    normal use cases but limited enough from current 16384 to not flood
    the logs by malicious requests.
    
    DocImpact
    SecurityImpact
    
    Related-to-bug: #1482301
    Change-Id: I52ebf810f4699826baa2bdf91d28e24d902cf950




From gerrit2 at review.openstack.org  Fri Aug  7 15:53:49 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 07 Aug 2015 15:53:49 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change Ie68afe7610a414bbcc42ff3bee33a9779303c115
Message-ID: <E1ZNjxt-0008Ms-4n@review.openstack.org>


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

Log:
commit 226fb0d4e75512431c6fd1b0628bb7d377ee7b91
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:29:28 2015 +0000

    Add mechanism to limit Request ID size
    
    Adding 'max_request_id_length' defaulting to 0 for backportability.
    
    DocImpact
    SecurityImpact
    
    Closes-Bug: #1482301
    Change-Id: Ie68afe7610a414bbcc42ff3bee33a9779303c115




From 1464750 at bugs.launchpad.net  Fri Aug  7 18:12:06 2015
From: 1464750 at bugs.launchpad.net (Adam Young)
Date: Fri, 07 Aug 2015 18:12:06 -0000
Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used
	to login horizon
References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150807181206.6196.44393.malone@gac.canonical.com>

A service user should have the "Service" role which can be used to
validate a token, and little else.  THis can be enforced with existing
policy mechanisms.

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

Title:
  Service accounts can be used to login horizon

Status in OpenStack Dashboard (Horizon):
  Incomplete
Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress

Bug description:
  This is not a bug and may / may not be a security issue ... but it
  appears that the service account created in keystone are of the same
  privileges level as any other admin accounts created through keystone
  and I don't like that.

  Would it be possible to implement something that would distinguish
  user accounts from service accounts?  Is there a way to isolate some
  service accounts from the remaining of the openstack APIs?

  One kick example on this is that any service accounts have admin
  privileges on all the other services .   At this point, I'm trying to
  figure out why are we creating a distinct service account for each
  service if nothing isolate them.

  IE:

  glance account can spawn a VM
  cinder account can delete an image
  heat account can delete a volume
  nova account can create an image

  
  All of these service accounts have access to the horizon dashboard.  One small hack could be to prevent those accounts from logging in Horizon.

  Thanks,

  Dave

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



From 1464750 at bugs.launchpad.net  Fri Aug  7 18:12:50 2015
From: 1464750 at bugs.launchpad.net (Adam Young)
Date: Fri, 07 Aug 2015 18:12:50 -0000
Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used
	to login horizon
References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150807181250.1942.49981.malone@wampee.canonical.com>

It might make sense to have Horizon limit login to users with the Member
or Admin roles only.

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

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

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

Title:
  Service accounts can be used to login horizon

Status in OpenStack Dashboard (Horizon):
  Incomplete
Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress

Bug description:
  This is not a bug and may / may not be a security issue ... but it
  appears that the service account created in keystone are of the same
  privileges level as any other admin accounts created through keystone
  and I don't like that.

  Would it be possible to implement something that would distinguish
  user accounts from service accounts?  Is there a way to isolate some
  service accounts from the remaining of the openstack APIs?

  One kick example on this is that any service accounts have admin
  privileges on all the other services .   At this point, I'm trying to
  figure out why are we creating a distinct service account for each
  service if nothing isolate them.

  IE:

  glance account can spawn a VM
  cinder account can delete an image
  heat account can delete a volume
  nova account can create an image

  
  All of these service accounts have access to the horizon dashboard.  One small hack could be to prevent those accounts from logging in Horizon.

  Thanks,

  Dave

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



From gerrit2 at review.openstack.org  Sat Aug  8 13:14:44 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sat, 08 Aug 2015 13:14:44 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I52ebf810f4699826baa2bdf91d28e24d902cf950
Message-ID: <E1ZO3xU-0002TA-3y@review.openstack.org>


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

Log:
commit fab6d3d2b9674d6013e8c74970a1499b1e799948
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:33:07 2015 +0000

    Setting default max_request_id_length to 64
    
    Setting sensible maximum size for Request ID. 64 should be enough for
    normal use cases but limited enough from current 16384 to not flood
    the logs by malicious requests.
    
    DocImpact
    SecurityImpact
    
    Related-to-bug: #1482301
    Change-Id: I52ebf810f4699826baa2bdf91d28e24d902cf950




From gerrit2 at review.openstack.org  Sat Aug  8 13:14:49 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sat, 08 Aug 2015 13:14:49 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change Ie68afe7610a414bbcc42ff3bee33a9779303c115
Message-ID: <E1ZO3xZ-0002TY-Sr@review.openstack.org>


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

Log:
commit 70f90d3c6e424a33650b27a9b636a2690d94cb5a
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:29:28 2015 +0000

    Add mechanism to limit Request ID size
    
    Adding 'max_request_id_length' defaulting to 0 for backportability.
    
    DocImpact
    SecurityImpact
    
    Closes-Bug: #1482301
    Change-Id: Ie68afe7610a414bbcc42ff3bee33a9779303c115




From mzoeller at de.ibm.com  Mon Aug 10 07:27:12 2015
From: mzoeller at de.ibm.com (Markus Zoeller)
Date: Mon, 10 Aug 2015 07:27:12 -0000
Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko
 change breaks third-party tools
References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com>
Message-ID: <20150810072713.19376.5062.launchpad@wampee.canonical.com>

** Tags added: encryption security

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

Title:
  ssh-keygen-to-Paramiko change breaks third-party tools

Status in OpenStack Compute (nova):
  New

Bug description:
  Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko
  library [1][2] changed (unintentionally?) the ASN.1 encoding format of
  SSH private keys from DER to BER.  (DER is a strict subset of BER, so
  anything that can read BER can read DER, but not necessarily the other
  way around.)

  Some third-party tools only support DER and this has created at least
  one issue [3] (specifically because Go's standard library only
  supports DER).

  I have provided Paramiko with a small change that makes its SSH
  private key output equal to OpenSSH's ssh-keygen output (and
  presumably DER formatted) [4].

  Providing a change to Paramiko is just one method of addressing this
  backwards-incompatibility and interoperability issue.  Should the
  Paramiko change be accepted the unit test output vectors will need to
  be changed, but should it not, is a reversion of or modification to
  Nova acceptable to maintain backwards-compatibility and
  interoperability?

  [1] https://review.openstack.org/157931
  [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a
  [3] https://github.com/mitchellh/packer/issues/2526
  [4] https://github.com/paramiko/paramiko/pull/572

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



From mzoeller at de.ibm.com  Mon Aug 10 07:43:53 2015
From: mzoeller at de.ibm.com (Markus Zoeller)
Date: Mon, 10 Aug 2015 07:43:53 -0000
Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko
 change breaks third-party tools
References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com>
Message-ID: <20150810074353.5481.30488.launchpad@gac.canonical.com>

** Tags removed: encryption
** Tags added: crypto

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

Title:
  ssh-keygen-to-Paramiko change breaks third-party tools

Status in OpenStack Compute (nova):
  New

Bug description:
  Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko
  library [1][2] changed (unintentionally?) the ASN.1 encoding format of
  SSH private keys from DER to BER.  (DER is a strict subset of BER, so
  anything that can read BER can read DER, but not necessarily the other
  way around.)

  Some third-party tools only support DER and this has created at least
  one issue [3] (specifically because Go's standard library only
  supports DER).

  I have provided Paramiko with a small change that makes its SSH
  private key output equal to OpenSSH's ssh-keygen output (and
  presumably DER formatted) [4].

  Providing a change to Paramiko is just one method of addressing this
  backwards-incompatibility and interoperability issue.  Should the
  Paramiko change be accepted the unit test output vectors will need to
  be changed, but should it not, is a reversion of or modification to
  Nova acceptable to maintain backwards-compatibility and
  interoperability?

  [1] https://review.openstack.org/157931
  [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a
  [3] https://github.com/mitchellh/packer/issues/2526
  [4] https://github.com/paramiko/paramiko/pull/572

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



From mzoeller at de.ibm.com  Mon Aug 10 07:54:21 2015
From: mzoeller at de.ibm.com (Markus Zoeller)
Date: Mon, 10 Aug 2015 07:54:21 -0000
Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko
 change breaks third-party tools
References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com>
Message-ID: <20150810075421.6053.6078.malone@gac.canonical.com>

Note: The backport of this change to stable/kilo got stopped [1].

[1] https://review.openstack.org/#/c/191206/

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

Title:
  ssh-keygen-to-Paramiko change breaks third-party tools

Status in OpenStack Compute (nova):
  New

Bug description:
  Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko
  library [1][2] changed (unintentionally?) the ASN.1 encoding format of
  SSH private keys from DER to BER.  (DER is a strict subset of BER, so
  anything that can read BER can read DER, but not necessarily the other
  way around.)

  Some third-party tools only support DER and this has created at least
  one issue [3] (specifically because Go's standard library only
  supports DER).

  I have provided Paramiko with a small change that makes its SSH
  private key output equal to OpenSSH's ssh-keygen output (and
  presumably DER formatted) [4].

  Providing a change to Paramiko is just one method of addressing this
  backwards-incompatibility and interoperability issue.  Should the
  Paramiko change be accepted the unit test output vectors will need to
  be changed, but should it not, is a reversion of or modification to
  Nova acceptable to maintain backwards-compatibility and
  interoperability?

  [1] https://review.openstack.org/157931
  [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a
  [3] https://github.com/mitchellh/packer/issues/2526
  [4] https://github.com/paramiko/paramiko/pull/572

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



From mzoeller at de.ibm.com  Mon Aug 10 08:52:11 2015
From: mzoeller at de.ibm.com (Markus Zoeller)
Date: Mon, 10 Aug 2015 08:52:11 -0000
Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko
 change breaks third-party tools
References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com>
Message-ID: <20150810085211.25572.47478.malone@chaenomeles.canonical.com>

The review [1] doesn't waste a word about the encoding, so I would
assume that this was unintentional. I struggle with myself to decide if
the private SSH key of a keypair should be seen as an interface which
Nova exposes for consumption for third party tools. From a security
point of view, the stricter DER seems to fit better our needs, so I
would assume that a rollback of [1] would be justifiable. Unfortunately
I'm no expert here and I need another opinion.

[1] https://review.openstack.org/157931

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

Title:
  ssh-keygen-to-Paramiko change breaks third-party tools

Status in OpenStack Compute (nova):
  New

Bug description:
  Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko
  library [1][2] changed (unintentionally?) the ASN.1 encoding format of
  SSH private keys from DER to BER.  (DER is a strict subset of BER, so
  anything that can read BER can read DER, but not necessarily the other
  way around.)

  Some third-party tools only support DER and this has created at least
  one issue [3] (specifically because Go's standard library only
  supports DER).

  I have provided Paramiko with a small change that makes its SSH
  private key output equal to OpenSSH's ssh-keygen output (and
  presumably DER formatted) [4].

  Providing a change to Paramiko is just one method of addressing this
  backwards-incompatibility and interoperability issue.  Should the
  Paramiko change be accepted the unit test output vectors will need to
  be changed, but should it not, is a reversion of or modification to
  Nova acceptable to maintain backwards-compatibility and
  interoperability?

  [1] https://review.openstack.org/157931
  [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a
  [3] https://github.com/mitchellh/packer/issues/2526
  [4] https://github.com/paramiko/paramiko/pull/572

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



From 1369627 at bugs.launchpad.net  Mon Aug 10 10:13:08 2015
From: 1369627 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 10 Aug 2015 10:13:08 -0000
Subject: [Openstack-security] [Bug 1369627] Related fix merged to nova
	(master)
References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150810101308.5197.58744.malone@gac.canonical.com>

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

commit adecf780d3ed4315e4ce305cb1821d493650494b
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Nov 25 15:42:47 2014 +0300

    Handle config drives being stored on rbd
    
    rbd is the only example of a currently supported image storage
    backend where it makes sense to put the config drive in the
    configured storage backend instead of local hypervisor disk. I
    don't think this makes sense for LVM, where we would be creating
    a LV for a tens of megabytes file, which seems like overkill to
    me. The other storage backends use local disk for their data
    already.
    
    This use case was covered by the now reverted changes:
      228d0221763b12f11ecbacde4db38b1151f96e31
      0b01e846d40f3b343da9ebe1dae89cca8bc2ac66
      ecce888c469c62374a3cc43e3cede11d8aa1e799
    
    Support this special case by moving the image to rbd once it has
    been created in the local instance directory on the hypervisor.
    
    I've tested this change in devstack and it works.
    
    Related-bug: #1369627
    Related-bug: #1361840
    Related-bug: #1246201
    
    Co-Authored-By: Mehdi Abaakouk <sileht at redhat.com>
    Co-Authored-By: Dan Smith <dms at danplanet.com>
    
    Change-Id: Ia3ca5a18c79d62b71b9c042a612d12dd074b245e

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

Title:
  libvirt disk.config will have issues when booting two with different
  config drive values

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Currently, in the image creating code for Juno we have

          if configdrive.required_by(instance):
              LOG.info(_LI('Using config drive'), instance=instance)

              image_type = self._get_configdrive_image_type()
              backend = image('disk.config', image_type)
              backend.cache(fetch_func=self._create_configdrive,
                            filename='disk.config' + suffix,
                            instance=instance,
                            admin_pass=admin_pass,
                            files=files,
                            network_info=network_info)

  The important thing to notice here is that we have
  "filename='disk.confg' + suffix".  This means that the filename for
  the config drive in the cache directory will be simply 'disk.config'
  followed by any potential suffix (e.g. '.rescue').  This name is not
  unique to the instance whose config drive we are creating.  Therefore,
  when we go to boot another instance with a different config drive, the
  cache function will detect the old config drive, and decide it doesn't
  need to create the new config drive with the appropriate config for
  the new instance.

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



From rpodolyaka+bugs at mirantis.com  Wed Aug  5 09:35:09 2015
From: rpodolyaka+bugs at mirantis.com (Roman Podoliaka)
Date: Wed, 05 Aug 2015 09:35:09 -0000
Subject: [Openstack-security] [Bug 1450798] Re: Multiple command injection
	vulns in schema_diff tool
References: <20150501135051.16168.63595.malonedeb@gac.canonical.com>
Message-ID: <20150805093510.6611.7743.launchpad@gac.canonical.com>

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

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

** Changed in: nova
     Assignee: (unassigned) => Roman Podoliaka (rpodolyaka)

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

** Changed in: nova
    Milestone: None => liberty-3

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

Title:
  Multiple command injection vulns in schema_diff tool

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  These lines in the latest Nova (as of May 1, 2015) are vulnerable to
  command injection

  https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86
  https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103
  https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117

  
  In this case (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L86 ), if a malicious filename such as "; rm -rf /etc" is provided, the /etc directory will be removed with the privileges of the user running this script.

  In this case
  (https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L103),
  if either a malicious name or filename are provided, the command will
  be executed with the privileges of the running user.

  In this
  case(https://github.com/openstack/nova/blob/master/tools/db/schema_diff.py#L117),
  if either a malicious name or filename are provided, the command will
  be executed with the privileges of the running user.

  
  I'm not familiar enough with the usage of this module to know all of the places these inputs can come from, but presumably it can be used in automation, potentially with elevated privileges.  I'm sure the idea of this script is to allow certain functionality, not unrestricted commands.  The way this has been developed allows unrestricted command execution by tampering with any of the above mentioned inputs.

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



From ctrath at us.ibm.com  Wed Aug  5 21:17:34 2015
From: ctrath at us.ibm.com (Cale Rath)
Date: Wed, 05 Aug 2015 21:17:34 -0000
Subject: [Openstack-security] [Bug 1246160] Re: shuffle method bring
	potential security issue
References: <20131030014106.17323.98896.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150805211736.6297.17971.launchpad@gac.canonical.com>

** Changed in: nova
     Assignee: (unassigned) => Cale Rath (ctrath)

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

Title:
  shuffle method bring potential security issue

Status in OpenStack Compute (nova):
  Confirmed
Status in OpenStack Security Advisory:
  Invalid

Bug description:
  In the /nova/utils.py, line 328, the source code is below

              r.shuffle(password)

  This code is using shuffle method to generate a random number,
  Standard random number generators should not be used to generate
  randomness used for security reasons. For security sensitive
  randomness a crytographic randomness generator that provides
  sufficient entropy should be used.

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



From bpiotrowski at mirantis.com  Thu Aug  6 09:55:06 2015
From: bpiotrowski at mirantis.com (Bartlomiej Piotrowski)
Date: Thu, 06 Aug 2015 09:55:06 -0000
Subject: [Openstack-security] [Bug 1355509] Re: Better conductor deployment
References: <20140811234559.17538.36052.malonedeb@soybean.canonical.com>
Message-ID: <20150806095507.25599.52881.launchpad@chaenomeles.canonical.com>

** Also affects: fuel/7.0.x
   Importance: Low
     Assignee: Fuel Library Team (fuel-library)
       Status: Triaged

** Also affects: fuel/8.0
   Importance: Undecided
       Status: New

** Changed in: fuel/7.0.x
       Status: Triaged => Won't Fix

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

** Changed in: fuel/8.0
   Importance: Undecided => Low

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

** Changed in: fuel/8.0
    Milestone: None => 8.0

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

Title:
  Better conductor deployment

Status in Fuel for OpenStack:
  Triaged
Status in Fuel for OpenStack 6.0.x series:
  Won't Fix
Status in Fuel for OpenStack 7.0.x series:
  Won't Fix
Status in Fuel for OpenStack 8.0 series:
  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 davanum at gmail.com  Fri Aug  7 20:39:57 2015
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Fri, 07 Aug 2015 20:39:57 -0000
Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used
	to login horizon
References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150807204001.2367.96787.launchpad@wampee.canonical.com>

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

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

Title:
  Service accounts can be used to login horizon

Status in OpenStack Dashboard (Horizon):
  Incomplete
Status in OpenStack Compute (nova):
  Incomplete
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress

Bug description:
  This is not a bug and may / may not be a security issue ... but it
  appears that the service account created in keystone are of the same
  privileges level as any other admin accounts created through keystone
  and I don't like that.

  Would it be possible to implement something that would distinguish
  user accounts from service accounts?  Is there a way to isolate some
  service accounts from the remaining of the openstack APIs?

  One kick example on this is that any service accounts have admin
  privileges on all the other services .   At this point, I'm trying to
  figure out why are we creating a distinct service account for each
  service if nothing isolate them.

  IE:

  glance account can spawn a VM
  cinder account can delete an image
  heat account can delete a volume
  nova account can create an image

  
  All of these service accounts have access to the horizon dashboard.  One small hack could be to prevent those accounts from logging in Horizon.

  Thanks,

  Dave

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



From aheczko at mirantis.com  Mon Aug 10 15:07:14 2015
From: aheczko at mirantis.com (Adam Heczko)
Date: Mon, 10 Aug 2015 15:07:14 -0000
Subject: [Openstack-security] [Bug 1464750] Re: Service accounts can be used
	to login horizon
References: <20150612190422.17171.4199.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150810150714.32317.37389.malone@soybean.canonical.com>

Agree with Adam Y., although it's a pity that for example existing
install guides are missing it and suggests to use "admin" role for
services deployment.

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

Title:
  Service accounts can be used to login horizon

Status in OpenStack Dashboard (Horizon):
  Incomplete
Status in OpenStack Compute (nova):
  Incomplete
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress

Bug description:
  This is not a bug and may / may not be a security issue ... but it
  appears that the service account created in keystone are of the same
  privileges level as any other admin accounts created through keystone
  and I don't like that.

  Would it be possible to implement something that would distinguish
  user accounts from service accounts?  Is there a way to isolate some
  service accounts from the remaining of the openstack APIs?

  One kick example on this is that any service accounts have admin
  privileges on all the other services .   At this point, I'm trying to
  figure out why are we creating a distinct service account for each
  service if nothing isolate them.

  IE:

  glance account can spawn a VM
  cinder account can delete an image
  heat account can delete a volume
  nova account can create an image

  
  All of these service accounts have access to the horizon dashboard.  One small hack could be to prevent those accounts from logging in Horizon.

  Thanks,

  Dave

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



From browne at vmware.com  Mon Aug 10 21:03:13 2015
From: browne at vmware.com (Eric Brown)
Date: Mon, 10 Aug 2015 21:03:13 -0000
Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko
 change breaks third-party tools
References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com>
Message-ID: <20150810210314.5806.74230.launchpad@gac.canonical.com>

** Changed in: nova
     Assignee: (unassigned) => Eric Brown (ericwb)

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

Title:
  ssh-keygen-to-Paramiko change breaks third-party tools

Status in OpenStack Compute (nova):
  New

Bug description:
  Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko
  library [1][2] changed (unintentionally?) the ASN.1 encoding format of
  SSH private keys from DER to BER.  (DER is a strict subset of BER, so
  anything that can read BER can read DER, but not necessarily the other
  way around.)

  Some third-party tools only support DER and this has created at least
  one issue [3] (specifically because Go's standard library only
  supports DER).

  I have provided Paramiko with a small change that makes its SSH
  private key output equal to OpenSSH's ssh-keygen output (and
  presumably DER formatted) [4].

  Providing a change to Paramiko is just one method of addressing this
  backwards-incompatibility and interoperability issue.  Should the
  Paramiko change be accepted the unit test output vectors will need to
  be changed, but should it not, is a reversion of or modification to
  Nova acceptable to maintain backwards-compatibility and
  interoperability?

  [1] https://review.openstack.org/157931
  [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a
  [3] https://github.com/mitchellh/packer/issues/2526
  [4] https://github.com/paramiko/paramiko/pull/572

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



From stanislaw.pitucha at hp.com  Tue Aug 11 00:53:58 2015
From: stanislaw.pitucha at hp.com (Pitucha, Stanislaw Izaak)
Date: Tue, 11 Aug 2015 00:53:58 +0000
Subject: [Openstack-security] [Anchor] Almost security-impact review -
 getting rid of openssl
In-Reply-To: <F2CEBDD2D596EC45A4D5479F72C865C504D59C0B@G2W2436.americas.hpqcorp.net>
References: <F2CEBDD2D596EC45A4D5479F72C865C504D56936@G2W2436.americas.hpqcorp.net>
 <55AF6022.5060709@Oracle.COM> <D1D52485.24648%robert.clark@hp.com>
 <F2CEBDD2D596EC45A4D5479F72C865C504D59C0B@G2W2436.americas.hpqcorp.net>
Message-ID: <F2CEBDD2D596EC45A4D5479F72C865C504D6DEA4@G1W3786.americas.hpqcorp.net>

Just to follow up - the patch is now complete and ready for reviews at https://review.openstack.org/204368
It does not use pycrypto after all but cryptography.io - but only for the actual crypto; certificate parsing / modifications use pyasn1.

This enabled DSA in addition to RSA. Other signatures will be also available soon.
Overall, I think the change was even better than I originally expected. While openssl is still accessed, it's only via small part of cryptography.io. It's also not used for any of the user input.

Best Regards,
Stanisław Pitucha

-----Original Message-----
From: Pitucha, Stanislaw Izaak 
Sent: Friday, July 24, 2015 10:07 AM
To: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] [Anchor] Almost security-impact review - getting rid of openssl

Now available at https://review.openstack.org/205328

Best Regards,
Stanisław Pitucha

-----Original Message-----
From: Clark, Robert Graham 
Sent: Wednesday, July 22, 2015 7:50 PM
To: Darren J Moffat; Pitucha, Stanislaw Izaak; openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] [Anchor] Almost security-impact review - getting rid of openssl

I tend to agree with Darren.

As it's quite a big change I think it should be discussed in a
security-specification.

-Rob


On 22/07/2015 10:19, "Darren J Moffat" <Darren.Moffat at Oracle.COM> wrote:

>
>
>On 07/22/15 05:29, Pitucha, Stanislaw Izaak wrote:
>> Hi all,
>> I'd like to get people interested in Anchor development to look at a
>>WIP patch I uploaded now:
>> https://review.openstack.org/204368
>>
>> It changes the backend of Anchor from relying on openssl (and all the
>>issues that go with it) to using pyasn1/pycrypto to directly operate on
>>the certificate/csr.
>> While it's not complete and I'm still waiting for some answers to
>>enable extensions
>>(http://stackoverflow.com/questions/31552798/parsing-x509-extensions-with
>>-pyasn1), it's functional. By definition - test_functional passes ;)
>
>I think this is the exact opposite of the direction we should be going in.
>
>pycrypto is old and not well featured.  Other parts of OpenStack and
>dependent projects such as paramiko are moving to cryptography.io which
>is a modern Python layer over OpenSSL.
>
>Please do not add more dependencies on pycrypto.
>
>> It's going to be a big change and take quite some time, so any feedback
>>is appreciated early on. The original rationale for the change can be
>>read at https://etherpad.openstack.org/p/Anchor_direct_asn1 and while
>>there were some issues on the way, I believe that everything I expected
>>to improve, improved a lot. What I'm most happy about is that the change
>>gets rid of magic string parsing / output and memory management of
>>openssl. Things like string and date manipulation either disappeared or
>>got much shorter. Also many error checks are not needed anymore.
>>
>> I didn't correct all function comments, so some of them may mention
>>wrong types. But the interface stayed pretty much the same - higher
>>level functionality like certificate_ops/signing has only cosmetic
>>changes.
>>
>> So if you're interested in Anchor, please have a look.
>>
>> Best Regards,
>> Stanisław Pitucha
>>
>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>
>-- 
>Darren J Moffat
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3508 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150811/651a3d0e/attachment.bin>

From gerrit2 at review.openstack.org  Tue Aug 11 10:43:37 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 11 Aug 2015 10:43:37 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I52ebf810f4699826baa2bdf91d28e24d902cf950
Message-ID: <E1ZP71t-0004TW-V7@review.openstack.org>


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

Log:
commit bd593ddbe67715534b404f3138298ab1232490f5
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:33:07 2015 +0000

    Setting default max_request_id_length to 64
    
    Setting sensible maximum size for Request ID. 64 should be enough for
    normal use cases but limited enough from current 16384 to not flood
    the logs by malicious requests.
    
    DocImpact
    SecurityImpact
    
    Related-to-bug: #1482301
    Change-Id: I52ebf810f4699826baa2bdf91d28e24d902cf950




From gerrit2 at review.openstack.org  Tue Aug 11 10:43:44 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 11 Aug 2015 10:43:44 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change Ie68afe7610a414bbcc42ff3bee33a9779303c115
Message-ID: <E1ZP720-0004V6-7V@review.openstack.org>


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

Log:
commit 9fdc92b57bfb1e92fdb90e9bffc07bd928801630
Author: Erno Kuvaja <jokke at usr.fi>
Date:   Thu Aug 6 16:29:28 2015 +0000

    Add mechanism to limit Request ID size
    
    Adding 'max_request_id_length' defaulting to 0 for backportability.
    
    DocImpact
    SecurityImpact
    
    Closes-Bug: #1482301
    Change-Id: Ie68afe7610a414bbcc42ff3bee33a9779303c115




From 1163569 at bugs.launchpad.net  Tue Aug 11 13:07:44 2015
From: 1163569 at bugs.launchpad.net (Kyle Mestery)
Date: Tue, 11 Aug 2015 13:07:44 -0000
Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work
	with vip and ovs plugin
References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com>
Message-ID: <20150811130744.25844.56517.malone@chaenomeles.canonical.com>

Doug, assigning this to you. Can you have someone from LBaaS triage this
a bit more and determine if it should still be high priority, and if the
fix is simple enough? See Steve's fix from above. Thanks!

** Changed in: neutron
     Assignee: Steven Weston (steve.weston) => Doug Wiegley (dougwig)

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

Title:
  security groups don't work with vip and ovs plugin

Status in neutron:
  Confirmed
Status in OpenStack Security Notes:
  In Progress

Bug description:
  http://codepad.org/xU8G4s00

  I pinged nachi and he suggested to try using:

  interface_driver = quantum.agent.linux.interface.BridgeInterfaceDriver

  But after setting this it seems like the vip does not work at all.

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



From gerrit2 at review.openstack.org  Tue Aug 11 19:49:03 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 11 Aug 2015 19:49:03 +0000
Subject: [Openstack-security] [openstack/glance-specs] SecurityImpact review
 request change I305b2ae86415c8d256c641abb2795af663bee56a
Message-ID: <E1ZPFXj-0006Ex-30@review.openstack.org>


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

Log:
commit 4a35f198f8e27c41bda9528589f40b8464f7d69d
Author: Brianna Poulos <Brianna.Poulos at jhuapl.edu>
Date:   Mon Apr 27 15:35:51 2015 -0400

    Image Signing and Verification Support
    
    This spec describes a means to support signing and signature
    validation of bootable images.
    
    DocImpact
    SecurityImpact
    
    Implements: blueprint image-signing-and-verification-support
    Change-Id: I305b2ae86415c8d256c641abb2795af663bee56a




From 1246160 at bugs.launchpad.net  Wed Aug 12 16:20:29 2015
From: 1246160 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 12 Aug 2015 16:20:29 -0000
Subject: [Openstack-security] [Bug 1246160] Re: shuffle method bring
	potential security issue
References: <20131030014106.17323.98896.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150812162031.25106.74715.launchpad@chaenomeles.canonical.com>

** Changed in: nova
     Assignee: Alexis Lee (alexisl) => Cale Rath (ctrath)

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

Title:
  shuffle method bring potential security issue

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Security Advisory:
  Invalid

Bug description:
  In the /nova/utils.py, line 328, the source code is below

              r.shuffle(password)

  This code is using shuffle method to generate a random number,
  Standard random number generators should not be used to generate
  randomness used for security reasons. For security sensitive
  randomness a crytographic randomness generator that provides
  sufficient entropy should be used.

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



From gerrit2 at review.openstack.org  Thu Aug 13 08:07:28 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 13 Aug 2015 08:07:28 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ic0780a0d1ccf96c14f1e0ad9c3e9b23e2b0db0ea
Message-ID: <E1ZPnXs-0007V4-Iy@review.openstack.org>


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

Log:
commit 9c917816048482e3a42aa06e2aa4933a1a6f7f8c
Author: Eli Qiao <liyong.qiao at intel.com>
Date:   Thu Jun 4 10:05:33 2015 +0800

    Add missing rules in policy.json
    
    'etc/nova/policy.json' is sample file for polcy configration. But
    there are a lot of rule missing in it. The user is hard to find
    out which rule can be used in nova.
    
    This patch adds the missing rule back to policy.json. Also adds a
    test case to veify the contents of policy.
    
    SecurityImpact
    UpgradeImpact:
    "os_compute_api:servers:create:forced_host" is missing in policy.json.
    That means it will be default rule. But actually it should be admin
    only API. This patch adds this rule back to policy.json and with
    correct rule. Deployer should update their policy.json to match the
    original permission also.
    
    Co-Authored-By: Alex Xu <hejie.xu at intel.com>
    
    Closes-Bug: #1435390
    Change-Id: Ic0780a0d1ccf96c14f1e0ad9c3e9b23e2b0db0ea




From damedeu at gmail.com  Thu Aug 13 15:51:16 2015
From: damedeu at gmail.com (Damedeu Eric)
Date: Thu, 13 Aug 2015 16:51:16 +0100
Subject: [Openstack-security] Security concern VMs isolation
Message-ID: <CAB=gJJwUgE+q59EKN1t+V0JcgNU7VJqdDLb330fxtKXePn1sKQ@mail.gmail.com>

Hi all,
I'm a new guy using Openstack and want to know how to well isolate VMs when
it instanced by the hypervisor. This is avoid attack by  covert channel.

Best regards
***************************************
*DAMEDEU ERIC MARTIAL*
*BP 34941 Yaoundé - CAMEROUN*

*Tél: +237 675 98 56 18 / +237 222 766788*

*Ingénieur Polytechnicien *

*Master Pro en Sécurité des S.I. et Communications*
*Master  en Télécoms et Réseaux Informatiques*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150813/e4354d68/attachment.html>

From Darren.Moffat at Oracle.COM  Fri Aug 14 14:05:21 2015
From: Darren.Moffat at Oracle.COM (Darren J Moffat)
Date: Fri, 14 Aug 2015 15:05:21 +0100
Subject: [Openstack-security] Security concern VMs isolation
In-Reply-To: <CAB=gJJwUgE+q59EKN1t+V0JcgNU7VJqdDLb330fxtKXePn1sKQ@mail.gmail.com>
References: <CAB=gJJwUgE+q59EKN1t+V0JcgNU7VJqdDLb330fxtKXePn1sKQ@mail.gmail.com>
Message-ID: <55CDF5A1.40502@Oracle.COM>



On 08/13/15 16:51, Damedeu Eric wrote:
> Hi all,
> I'm a new guy using Openstack and want to know how to well isolate VMs
> when it instanced by the hypervisor. This is avoid attack by  covert
> channel.

That depends which hypervisor your are using and on which OS platform. 
You should look at your hypervisor and OS vendors documentation for that 
information.  OpenStack just configures and deploys the VMs it doesn't 
provide the security isolation boundaries.

-- 
Darren J Moffat



From travis.mcpeak at hp.com  Fri Aug 14 14:05:21 2015
From: travis.mcpeak at hp.com (McPeak, Travis)
Date: Fri, 14 Aug 2015 14:05:21 +0000
Subject: [Openstack-security] Security concern VMs isolation (Damedeu
	Eric)
Message-ID: <D1F34EBF.54B0%travis.mcpeak@hp.com>

Hi Eric,

First off welcome to OpenStack!  Generally for security related
questions we use the OpenStack-dev mailing list and preface the
subject with a [Security] tag.

One of the functions of a hypervisor is to ensure proper isolation of
tenant VMs.  That being said I highly recommend deploying some kind of
mandatory access control system as a fail-safe.  Two leading MAC
solutions with good QEMU support are AppArmor and SELinux.

The MAC controls that apply specifically to the hypervisor are known
as sVirt.  When QEMU launches a virutal machine it does so in a
separate process.  sVirt ensures that each process is only allowed to
access its own resources.

The net result is that if a hypervisor breakout occurs (code within
the virutal machine process is able to access resources on the host
system) it is still only able to access a limited set of resources on
the host system.

I will also add this thread on OpenStack-dev so that others can chime
in if they have any good pointers.

Thanks,
 -Travis



>Hi all,
>I'm a new guy using Openstack and want to know how to well isolate VMs
>when
>it instanced by the hypervisor. This is avoid attack by  covert channel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2751 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150814/4d928a3f/attachment.bin>

From robert.clark at hp.com  Fri Aug 14 14:33:31 2015
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 14 Aug 2015 14:33:31 +0000
Subject: [Openstack-security] Security concern VMs isolation
In-Reply-To: <55CDF5A1.40502@Oracle.COM>
References: <CAB=gJJwUgE+q59EKN1t+V0JcgNU7VJqdDLb330fxtKXePn1sKQ@mail.gmail.com>
 <55CDF5A1.40502@Oracle.COM>
Message-ID: <D1F3BA4E.278BD%robert.clark@hp.com>

There¹s a few summit talks on the the topic:

https://www.youtube.com/watch?v=y8L6B6Q5EdI

https://www.youtube.com/watch?v=43ffumzzfKU


It¹s also a big topic in the OpenStack Security Guide:
http://docs.openstack.org/sec/


Hope this helps.

-Rob


On 14/08/2015 15:05, "Darren J Moffat" <Darren.Moffat at Oracle.COM> wrote:

>
>
>On 08/13/15 16:51, Damedeu Eric wrote:
>> Hi all,
>> I'm a new guy using Openstack and want to know how to well isolate VMs
>> when it instanced by the hypervisor. This is avoid attack by  covert
>> channel.
>
>That depends which hypervisor your are using and on which OS platform.
>You should look at your hypervisor and OS vendors documentation for that
>information.  OpenStack just configures and deploys the VMs it doesn't
>provide the security isolation boundaries.
>
>-- 
>Darren J Moffat
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security




From stanislaw.pitucha at hp.com  Tue Aug 18 05:55:27 2015
From: stanislaw.pitucha at hp.com (Pitucha, Stanislaw Izaak)
Date: Tue, 18 Aug 2015 05:55:27 +0000
Subject: [Openstack-security] [Anchor] validators feedback request
Message-ID: <F2CEBDD2D596EC45A4D5479F72C865C504D755BC@G2W2436.americas.hpqcorp.net>

Hi all,

Anchor needs to get the validators refreshed / improved in many ways.

The details are in the spec at https://review.openstack.org/213997

But the most important part is: if you’re either interested in Anchor or are using it now, I’d like to hear what kind of certificate validation you need / want to see. If you have an opinion, please leave some feedback!

 

Best Regards,

Stanisław Pitucha

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150818/f5385a04/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3508 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20150818/f5385a04/attachment.bin>

From josh.gibbs at RACKSPACE.COM  Fri Aug 14 14:49:39 2015
From: josh.gibbs at RACKSPACE.COM (Josh Gibbs)
Date: Fri, 14 Aug 2015 14:49:39 +0000
Subject: [Openstack-security] Security concern VMs isolation
In-Reply-To: <D1F3BA4E.278BD%robert.clark@hp.com>
Message-ID: <D1F36A3E.19EC0%josh.gibbs@rackspace.com>

Processor architecture may also play a role in this.

https://blog.trailofbits.com/2015/07/21/hardware-side-channels-in-the-cloud
/

-Josh




On 8/14/15, 9:33 AM, "Clark, Robert Graham" <robert.clark at hp.com> wrote:

>There¹s a few summit talks on the the topic:
>
>https://www.youtube.com/watch?v=y8L6B6Q5EdI
>
>https://www.youtube.com/watch?v=43ffumzzfKU
>
>
>It¹s also a big topic in the OpenStack Security Guide:
>http://docs.openstack.org/sec/
>
>
>Hope this helps.
>
>-Rob
>
>
>On 14/08/2015 15:05, "Darren J Moffat" <Darren.Moffat at Oracle.COM> wrote:
>
>>
>>
>>On 08/13/15 16:51, Damedeu Eric wrote:
>>> Hi all,
>>> I'm a new guy using Openstack and want to know how to well isolate VMs
>>> when it instanced by the hypervisor. This is avoid attack by  covert
>>> channel.
>>
>>That depends which hypervisor your are using and on which OS platform.
>>You should look at your hypervisor and OS vendors documentation for that
>>information.  OpenStack just configures and deploys the VMs it doesn't
>>provide the security isolation boundaries.
>>
>>-- 
>>Darren J Moffat
>>
>>_______________________________________________
>>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 mriedem at us.ibm.com  Tue Aug 18 18:54:28 2015
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Tue, 18 Aug 2015 18:54:28 -0000
Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed,
 lun-id couldn't be rollback in havana
References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150818185428.27301.28590.malone@chaenomeles.canonical.com>

I have a feeling that this is fixed via
https://review.openstack.org/#/c/211051/ .

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

Title:
  when live-migrate failed, lun-id couldn't be rollback in havana

Status in OpenStack Compute (nova):
  Confirmed
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Hi, guys

  When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback.
  and failed VM can have others volume.

  my test environment is following :

  Openstack Version : Havana ( 2013.2.3)
  Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

  test step is :

  1) create 2 Compute node (host#1 and host#2)
  2) create 1 VM on host#1 (vm01)
  3) create 1 cinder volume (vol01)
  4) attach 1 volume to vm01 (/dev/vdb)
  5) live-migrate vm01 from host#1 to host#2
  6) live-migrate success
       - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.
         and the status of devices is "failed faulty"
       - please check the lun-id of vol01
  7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4)
  8) live-migrate fail
       - please check the mapper in host#1
       - please check the lun-id of vol01, then you can find the lun hav "two" igroups
       - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback

  This Bug is critical security issue because the failed VM can have
  others volume.

  and every backend storage of cinder-volume can have same problem
  because this is the bug of live-migration's rollback process.

  I suggest below methods to solve issue :

  1) when live-migrate is complete, nova should delete mapper devices at origin host
  2) when live-migrate is failed, nova should rollback lun-id in connection_info column
  3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...)
  4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping

  please check this bug.

  Thank you.

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



From mriedem at us.ibm.com  Tue Aug 18 18:57:06 2015
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Tue, 18 Aug 2015 18:57:06 -0000
Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed,
 lun-id couldn't be rollback in havana
References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150818185706.27342.74076.malone@chaenomeles.canonical.com>

Per comment 17, maybe not given that's post live migration which is only
called for a successful live migration, the rollback is called for a
failed live migration.

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

Title:
  when live-migrate failed, lun-id couldn't be rollback in havana

Status in OpenStack Compute (nova):
  Confirmed
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Hi, guys

  When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback.
  and failed VM can have others volume.

  my test environment is following :

  Openstack Version : Havana ( 2013.2.3)
  Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

  test step is :

  1) create 2 Compute node (host#1 and host#2)
  2) create 1 VM on host#1 (vm01)
  3) create 1 cinder volume (vol01)
  4) attach 1 volume to vm01 (/dev/vdb)
  5) live-migrate vm01 from host#1 to host#2
  6) live-migrate success
       - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.
         and the status of devices is "failed faulty"
       - please check the lun-id of vol01
  7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4)
  8) live-migrate fail
       - please check the mapper in host#1
       - please check the lun-id of vol01, then you can find the lun hav "two" igroups
       - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback

  This Bug is critical security issue because the failed VM can have
  others volume.

  and every backend storage of cinder-volume can have same problem
  because this is the bug of live-migration's rollback process.

  I suggest below methods to solve issue :

  1) when live-migrate is complete, nova should delete mapper devices at origin host
  2) when live-migrate is failed, nova should rollback lun-id in connection_info column
  3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...)
  4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping

  please check this bug.

  Thank you.

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



From mriedem at us.ibm.com  Tue Aug 18 18:57:31 2015
From: mriedem at us.ibm.com (Matt Riedemann)
Date: Tue, 18 Aug 2015 18:57:31 -0000
Subject: [Openstack-security] [Bug 1419577] Re: when live-migrate failed,
 lun-id couldn't be rollback in havana
References: <20150209012956.20741.53343.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150818185731.22054.58830.malone@gac.canonical.com>

@Justin, per comment 16, this was reported against Havana but as far as
I can tell this is not yet resolved in master (Liberty right now).

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

Title:
  when live-migrate failed, lun-id couldn't be rollback in havana

Status in OpenStack Compute (nova):
  Confirmed
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Hi, guys

  When live-migrate failed with error, lun-id of connection_info column in Nova's block_deivce_mapping table couldn't be rollback.
  and failed VM can have others volume.

  my test environment is following :

  Openstack Version : Havana ( 2013.2.3)
  Compute Node OS : 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
  Compute Node multipath : multipath-tools 0.4.9-3ubuntu7.2

  test step is :

  1) create 2 Compute node (host#1 and host#2)
  2) create 1 VM on host#1 (vm01)
  3) create 1 cinder volume (vol01)
  4) attach 1 volume to vm01 (/dev/vdb)
  5) live-migrate vm01 from host#1 to host#2
  6) live-migrate success
       - please check the mapper by using multipath command in host#1 (# multipath -ll), then you can find mapper is not deleted.
         and the status of devices is "failed faulty"
       - please check the lun-id of vol01
  7) Again, live-migrate vm01 from host#2 to host#1 (vm01 was migrated to host#2 at step 4)
  8) live-migrate fail
       - please check the mapper in host#1
       - please check the lun-id of vol01, then you can find the lun hav "two" igroups
       - please check the connection_info column in Nova's block_deivce_mapping table, then you can find lun-id couldn't be rollback

  This Bug is critical security issue because the failed VM can have
  others volume.

  and every backend storage of cinder-volume can have same problem
  because this is the bug of live-migration's rollback process.

  I suggest below methods to solve issue :

  1) when live-migrate is complete, nova should delete mapper devices at origin host
  2) when live-migrate is failed, nova should rollback lun-id in connection_info column
  3) when live-migrate is failed, cinder should delete the mapping between lun and host (Netapp : igroup, EMC : storage_group ...)
  4) when volume-attach is requested , cinder volume driver of vendors should make lun-id randomly for reduce of probability of mis-mapping

  please check this bug.

  Thank you.

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



From gerrit2 at review.openstack.org  Wed Aug 19 09:21:41 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 19 Aug 2015 09:21:41 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9
Message-ID: <E1ZRzYz-0005o5-F2@review.openstack.org>


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

Log:
commit c79cf98efb526753897530ccc384efb1212bcaa1
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Mon Jul 6 01:51:26 2015 -0700

    libvirt: Kill rsync/scp processes before deleting instance
    
    In the resize operation, during copying files from source to
    destination compute node scp/rsync processes are not aborted after
    the instance is deleted because linux kernel doesn't delete instance
    files physically until all processes using the file handle is closed
    completely. Hence rsync/scp process keeps on running until it
    transfers 100% of file data.
    
    Added new module instancejobtracker to libvirt driver which will add,
    remove or terminate the processes running against particular instances.
    Added callback methods to execute call which will store the pid of
    scp/rsync process in cache as a key: value pair and to remove the
    pid from the cache after process completion. Process id will be used to
    kill the process if it is running while deleting the instance. Instance
    uuid is used as a key in the cache and pid will be the value.
    
    Conflicts:
            nova/tests/unit/virt/libvirt/test_driver.py
            nova/tests/unit/virt/libvirt/test_utils.py
            nova/virt/libvirt/driver.py
            nova/virt/libvirt/utils.py
    
    Note: The required unit-tests are manually added to the below path,
    as new path for unit-tests is not present in stable/juno release.
    nova/tests/virt/libvirt/test_driver.py
    nova/tests/virt/libvirt/test_utils.py
    
    SecurityImpact
    
    Closes-bug: #1387543
    Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9
    (cherry picked from commit 7ab75d5b0b75fc3426323bef19bf436a258b9707)
    (cherry picked from commit b5020a047fc487f35b76fc05f31e52665a1afda1)




From gerrit2 at review.openstack.org  Wed Aug 19 10:16:09 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 19 Aug 2015 10:16:09 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9
Message-ID: <E1ZS0Ph-0007eP-6Q@review.openstack.org>


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

Log:
commit 539693e40388c4729c99a2c133b573896296df2a
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Mon Jul 6 01:51:26 2015 -0700

    libvirt: Kill rsync/scp processes before deleting instance
    
    In the resize operation, during copying files from source to
    destination compute node scp/rsync processes are not aborted after
    the instance is deleted because linux kernel doesn't delete instance
    files physically until all processes using the file handle is closed
    completely. Hence rsync/scp process keeps on running until it
    transfers 100% of file data.
    
    Added new module instancejobtracker to libvirt driver which will add,
    remove or terminate the processes running against particular instances.
    Added callback methods to execute call which will store the pid of
    scp/rsync process in cache as a key: value pair and to remove the
    pid from the cache after process completion. Process id will be used to
    kill the process if it is running while deleting the instance. Instance
    uuid is used as a key in the cache and pid will be the value.
    
    Conflicts:
            nova/tests/unit/virt/libvirt/test_driver.py
            nova/tests/unit/virt/libvirt/test_utils.py
            nova/virt/libvirt/driver.py
            nova/virt/libvirt/utils.py
    
    Note: The required unit-tests are manually added to the below path,
    as new path for unit-tests is not present in stable/juno release.
    nova/tests/virt/libvirt/test_driver.py
    nova/tests/virt/libvirt/test_utils.py
    
    SecurityImpact
    
    Closes-bug: #1387543
    Change-Id: Ie03acc00a7c904aec13c90ae6a53938d08e5e0c9
    (cherry picked from commit 7ab75d5b0b75fc3426323bef19bf436a258b9707)
    (cherry picked from commit b5020a047fc487f35b76fc05f31e52665a1afda1)




From 1369627 at bugs.launchpad.net  Wed Aug 19 19:36:35 2015
From: 1369627 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 19 Aug 2015 19:36:35 -0000
Subject: [Openstack-security] [Bug 1369627] Related fix proposed to nova
	(stable/kilo)
References: <20140915153310.17745.11485.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150819193635.19662.3148.malone@soybean.canonical.com>

Related fix proposed to branch: stable/kilo
Review: https://review.openstack.org/214773

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

Title:
  libvirt disk.config will have issues when booting two with different
  config drive values

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Currently, in the image creating code for Juno we have

          if configdrive.required_by(instance):
              LOG.info(_LI('Using config drive'), instance=instance)

              image_type = self._get_configdrive_image_type()
              backend = image('disk.config', image_type)
              backend.cache(fetch_func=self._create_configdrive,
                            filename='disk.config' + suffix,
                            instance=instance,
                            admin_pass=admin_pass,
                            files=files,
                            network_info=network_info)

  The important thing to notice here is that we have
  "filename='disk.confg' + suffix".  This means that the filename for
  the config drive in the cache directory will be simply 'disk.config'
  followed by any potential suffix (e.g. '.rescue').  This name is not
  unique to the instance whose config drive we are creating.  Therefore,
  when we go to boot another instance with a different config drive, the
  cache function will detect the old config drive, and decide it doesn't
  need to create the new config drive with the appropriate config for
  the new instance.

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



From fungi at yuggoth.org  Fri Aug 21 11:57:20 2015
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 21 Aug 2015 11:57:20 -0000
Subject: [Openstack-security] [Bug 1454074] Re: denial of service via large
 number of logout page requests
References: <20150512061448.3019.99351.malonedeb@wampee.canonical.com>
Message-ID: <20150821115721.21320.38397.launchpad@gac.canonical.com>

** Information type changed from Private Security to Public

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

** Tags added: security

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

Title:
  denial of service via large number of logout page requests

Status in OpenStack Dashboard (Horizon):
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  This issue is being treated as a potential security risk under
  embargo. Please do not make any public mention of embargoed (private)
  security vulnerabilities before their coordinated publication by the
  OpenStack Vulnerability Management Team in the form of an official
  OpenStack Security Advisory. This includes discussion of the bug or
  associated fixes in public forums such as mailing lists, code review
  systems and bug trackers. Please also avoid private disclosure to
  other individuals not already approved for access to this information,
  and provide this same reminder to those who are made aware of the
  issue prior to publication. All discussion should remain confined to
  this private bug report, and any proposed fixes should be added to the
  bug as attachments.

  While investigating CVE-2014-8124
  (https://bugs.launchpad.net/horizon/+bug/1394370) I think I found
  another instance of the underlying issue, but with the logout form.

  I'm on Ubuntu 14.04 LTS, with distro-packaged openstack-dashboard
  1:2014.1.4-0ubuntu2. I verified the patch from
  https://review.openstack.org/140356 is applied to the installed files.
  I configured horizon to use mysql datastore, and ran the following
  command:

  while true ; do wget http://localhost/horizon/auth/logout/ ; done

  While this command was running I checked the mysql dash database table
  django_sessions and found it growing without apparent bound:

  select * from django_session;
  ...
  231 rows in set (0.00 sec)

  Is this an issue?

  Thanks

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



From tdecacqu at redhat.com  Fri Aug 21 13:07:46 2015
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Fri, 21 Aug 2015 13:07:46 -0000
Subject: [Openstack-security] [Bug 1454074] Re: denial of service via large
 number of logout page requests
References: <20150512061448.3019.99351.malonedeb@wampee.canonical.com>
Message-ID: <20150821130746.27416.57947.launchpad@chaenomeles.canonical.com>

** Description changed:

- This issue is being treated as a potential security risk under embargo.
- Please do not make any public mention of embargoed (private) security
- vulnerabilities before their coordinated publication by the OpenStack
- Vulnerability Management Team in the form of an official OpenStack
- Security Advisory. This includes discussion of the bug or associated
- fixes in public forums such as mailing lists, code review systems and
- bug trackers. Please also avoid private disclosure to other individuals
- not already approved for access to this information, and provide this
- same reminder to those who are made aware of the issue prior to
- publication. All discussion should remain confined to this private bug
- report, and any proposed fixes should be added to the bug as
- attachments.
- 
  While investigating CVE-2014-8124
  (https://bugs.launchpad.net/horizon/+bug/1394370) I think I found
  another instance of the underlying issue, but with the logout form.
  
  I'm on Ubuntu 14.04 LTS, with distro-packaged openstack-dashboard
  1:2014.1.4-0ubuntu2. I verified the patch from
  https://review.openstack.org/140356 is applied to the installed files. I
  configured horizon to use mysql datastore, and ran the following
  command:
  
  while true ; do wget http://localhost/horizon/auth/logout/ ; done
  
  While this command was running I checked the mysql dash database table
  django_sessions and found it growing without apparent bound:
  
  select * from django_session;
  ...
  231 rows in set (0.00 sec)
  
  Is this an issue?
  
  Thanks

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

Title:
  denial of service via large number of logout page requests

Status in OpenStack Dashboard (Horizon):
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  While investigating CVE-2014-8124
  (https://bugs.launchpad.net/horizon/+bug/1394370) I think I found
  another instance of the underlying issue, but with the logout form.

  I'm on Ubuntu 14.04 LTS, with distro-packaged openstack-dashboard
  1:2014.1.4-0ubuntu2. I verified the patch from
  https://review.openstack.org/140356 is applied to the installed files.
  I configured horizon to use mysql datastore, and ran the following
  command:

  while true ; do wget http://localhost/horizon/auth/logout/ ; done

  While this command was running I checked the mysql dash database table
  django_sessions and found it growing without apparent bound:

  select * from django_session;
  ...
  231 rows in set (0.00 sec)

  Is this an issue?

  Thanks

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



From 1454074 at bugs.launchpad.net  Fri Aug 21 15:53:20 2015
From: 1454074 at bugs.launchpad.net (Lin Hua Cheng)
Date: Fri, 21 Aug 2015 15:53:20 -0000
Subject: [Openstack-security] [Bug 1454074] Re: denial of service via large
 number of logout page requests
References: <20150512061448.3019.99351.malonedeb@wampee.canonical.com>
Message-ID: <20150821155322.27114.9066.launchpad@chaenomeles.canonical.com>

** Changed in: horizon
       Status: Triaged => Won't Fix

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

Title:
  denial of service via large number of logout page requests

Status in OpenStack Dashboard (Horizon):
  Won't Fix
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  While investigating CVE-2014-8124
  (https://bugs.launchpad.net/horizon/+bug/1394370) I think I found
  another instance of the underlying issue, but with the logout form.

  I'm on Ubuntu 14.04 LTS, with distro-packaged openstack-dashboard
  1:2014.1.4-0ubuntu2. I verified the patch from
  https://review.openstack.org/140356 is applied to the installed files.
  I configured horizon to use mysql datastore, and ran the following
  command:

  while true ; do wget http://localhost/horizon/auth/logout/ ; done

  While this command was running I checked the mysql dash database table
  django_sessions and found it growing without apparent bound:

  select * from django_session;
  ...
  231 rows in set (0.00 sec)

  Is this an issue?

  Thanks

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



From fungi at yuggoth.org  Fri Aug 21 20:41:41 2015
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 21 Aug 2015 20:41:41 -0000
Subject: [Openstack-security] [Bug 1484237] Re: token revocations not always
 respected when using fernet tokens
References: <20150812185544.5991.94491.malonedeb@gac.canonical.com>
Message-ID: <20150821204141.19745.86834.malone@soybean.canonical.com>

I agree this seems like a very impractical/unlikely vulnerability in any
real-world deployment, so class C1 in our report taxonomy:
https://security.openstack.org/vmt-process.html#incident-report-taxonomy

** Information type changed from Private Security to Public

** Tags added: security

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

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

Title:
  token revocations not always respected when using fernet tokens

Status in Keystone:
  Confirmed
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  A simple test that shows that fernet tokens are not always being
  invalidated.

  Simple test steps:

  1) gets a token
  2) deletes a token
  3) tries to validate the deleted token

  When I run this in production on 10 tokens, I get about a 20% success
  rate on the token being detected as invalid, 80% of the time, keystone
  tells me the token is valid.

  I have validated that the token is showing in the revocation event
  table.

  I've tried a 5 second delay between the calls which did not change the
  behavior.

  My current script (below) will look for 204 and 404 to show failure
  and will wait forever. I've let it wait over 5 minutes, it seems to me
  that either keystone knows immediately that the token is invalid or
  not at all.

  I do not have memcache enabled on these nodes.

  The same test has a 100% pass rate with UUID tokens.

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



From 1484237 at bugs.launchpad.net  Fri Aug 21 23:27:50 2015
From: 1484237 at bugs.launchpad.net (Dolph Mathews)
Date: Fri, 21 Aug 2015 23:27:50 -0000
Subject: [Openstack-security] [Bug 1484237] Re: token revocations not always
 respected when using fernet tokens
References: <20150812185544.5991.94491.malonedeb@gac.canonical.com>
Message-ID: <20150821232752.21766.79148.launchpad@gac.canonical.com>

** Changed in: keystone
     Assignee: (unassigned) => Dolph Mathews (dolph)

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

Title:
  token revocations not always respected when using fernet tokens

Status in Keystone:
  Confirmed
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  A simple test that shows that fernet tokens are not always being
  invalidated.

  Simple test steps:

  1) gets a token
  2) deletes a token
  3) tries to validate the deleted token

  When I run this in production on 10 tokens, I get about a 20% success
  rate on the token being detected as invalid, 80% of the time, keystone
  tells me the token is valid.

  I have validated that the token is showing in the revocation event
  table.

  I've tried a 5 second delay between the calls which did not change the
  behavior.

  My current script (below) will look for 204 and 404 to show failure
  and will wait forever. I've let it wait over 5 minutes, it seems to me
  that either keystone knows immediately that the token is invalid or
  not at all.

  I do not have memcache enabled on these nodes.

  The same test has a 100% pass rate with UUID tokens.

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



From 1361360 at bugs.launchpad.net  Fri Aug 21 23:57:03 2015
From: 1361360 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 21 Aug 2015 23:57:03 -0000
Subject: [Openstack-security] [Bug 1361360] Fix merged to keystone
	(stable/juno)
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20150821235703.21852.41609.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/177686
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=d2d6aba069ea3101dfbc3363689eb6142ffb6d1f
Submitter: Jenkins
Branch:    stable/juno

commit d2d6aba069ea3101dfbc3363689eb6142ffb6d1f
Author: abhishekkekane <abhishek.kekane at nttdata.com>
Date:   Tue Oct 21 04:10:57 2014 -0700

    Eventlet green threads not released back to pool
    
    Presently, the wsgi server allows persist connections hence even after
    the response is sent to the client, it doesn't close the client socket
    connection.
    Because of this problem, the green thread is not released back to the pool.
    
    In order to close the client socket connection explicitly after the
    response is sent and read successfully by the client, you simply have to
    set keepalive to False when you create a wsgi server.
    
    Add a parameter to take advantage of the new(ish) eventlet socket timeout
    behaviour. Allows closing idle client connections after a period of
    time, eg:
    
    $ time nc localhost 8776
    real    1m0.063s
    
    Setting 'client_socket_timeout = 0' means do not timeout.
    
    DocImpact:
    Added wsgi_keep_alive option (default=True).
    Added client_socket_timeout option (default=900).
    
    SecurityImpact
    
    Conflicts:
            keystone/common/config.py
            keystone/common/environment/eventlet_server.py
    
    NOTE: This is not 1:1 cherry-pick because 'eventlet_server' config
    group is not present in juno.
    
    Closes-Bug: #1361360
    Change-Id: I03b9c5c64f4bd8bca78dfc83199ef17d9a7ea5b7
    (cherry picked from commit 3b08644eb9cf4c5aca51a36250ae93105c17f6c4)
    (cherry picked from commit 67cda0ccae04471340bcada099d945d90979e64d)

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

Title:
  Eventlet green threads not released back to the pool leading to
  choking of new requests

Status in Cinder:
  Fix Released
Status in Cinder icehouse series:
  Fix Released
Status in Cinder juno series:
  Fix Released
Status in Glance:
  Fix Released
Status in Glance icehouse series:
  Fix Committed
Status in heat:
  Fix Released
Status in Keystone:
  Fix Released
Status in Keystone icehouse series:
  Confirmed
Status in Keystone juno series:
  Fix Committed
Status in Keystone kilo series:
  Fix Released
Status in Manila:
  Fix Released
Status in neutron:
  Fix Released
Status in neutron icehouse series:
  Fix Released
Status in neutron juno series:
  Fix Committed
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) icehouse series:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  New
Status in Sahara:
  Confirmed

Bug description:
  Currently reproduced  on Juno milestone 2. but this issue should be
  reproducible in all releases since its inception.

  It is possible to choke OpenStack API controller services using
  wsgi+eventlet library by simply not closing the client socket
  connection. Whenever a request is received by any OpenStack API
  service for example nova api service, eventlet library creates a green
  thread from the pool and starts processing the request. Even after the
  response is sent to the caller, the green thread is not returned back
  to the pool until the client socket connection is closed. This way,
  any malicious user can send many API requests to the API controller
  node and determine the wsgi pool size configured for the given service
  and then send those many requests to the service and after receiving
  the response, wait there infinitely doing nothing leading to
  disrupting services for other tenants. Even when service providers
  have enabled rate limiting feature, it is possible to choke the API
  services with a group (many tenants) attack.

  Following program illustrates choking of nova-api services (but this
  problem is omnipresent in all other OpenStack API Services using
  wsgi+eventlet)

  Note: I have explicitly set the wsi_default_pool_size default value to 10 in order to reproduce this problem in nova/wsgi.py.
  After you run the below program, you should try to invoke API
  ============================================================================================
  import time
  import requests
  from multiprocessing import Process

  def request(number):
     #Port is important here
     path = 'http://127.0.0.1:8774/servers'
      try:
          response = requests.get(path)
          print "RESPONSE %s-%d" % (response.status_code, number)
          #during this sleep time, check if the client socket connection is released or not on the API controller node.
          time.sleep(1000)
          print “Thread %d complete" % number
      except requests.exceptions.RequestException as ex:
          print “Exception occurred %d-%s" % (number, str(ex))

  if __name__ == '__main__':
      processes = []
      for number in range(40):
          p = Process(target=request, args=(number,))
          p.start()
          processes.append(p)
      for p in processes:
          p.join()

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

  Presently, the wsgi server allows persist connections if you configure keepalive to True which is default.
  In order to close the client socket connection explicitly after the response is sent and read successfully by the client, you simply have to set keepalive to False when you create a wsgi server.

  Additional information: By default eventlet passes “Connection: keepalive” if keepalive is set to True when a response is sent to the client. But it doesn’t have capability to set the timeout and max parameter.
  For example.
  Keep-Alive: timeout=10, max=5

  Note: After we have disabled keepalive in all the OpenStack API
  service using wsgi library, then it might impact all existing
  applications built with the assumptions that OpenStack API services
  uses persistent connections. They might need to modify their
  applications if reconnection logic is not in place and also they might
  experience the performance has slowed down as it will need to
  reestablish the http connection for every request.

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



From 1484237 at bugs.launchpad.net  Mon Aug 24 12:29:32 2015
From: 1484237 at bugs.launchpad.net (Dolph Mathews)
Date: Mon, 24 Aug 2015 12:29:32 -0000
Subject: [Openstack-security] [Bug 1484237] Re: token revocations not always
 respected when using fernet tokens
References: <20150812185544.5991.94491.malonedeb@gac.canonical.com>
Message-ID: <20150824122933.21696.90495.launchpad@gac.canonical.com>

** Tags added: kilo-backport-potential

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

Title:
  token revocations not always respected when using fernet tokens

Status in Keystone:
  Confirmed
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  A simple test that shows that fernet tokens are not always being
  invalidated.

  Simple test steps:

  1) gets a token
  2) deletes a token
  3) tries to validate the deleted token

  When I run this in production on 10 tokens, I get about a 20% success
  rate on the token being detected as invalid, 80% of the time, keystone
  tells me the token is valid.

  I have validated that the token is showing in the revocation event
  table.

  I've tried a 5 second delay between the calls which did not change the
  behavior.

  My current script (below) will look for 204 and 404 to show failure
  and will wait forever. I've let it wait over 5 minutes, it seems to me
  that either keystone knows immediately that the token is invalid or
  not at all.

  I do not have memcache enabled on these nodes.

  The same test has a 100% pass rate with UUID tokens.

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



From 1484237 at bugs.launchpad.net  Mon Aug 24 18:18:23 2015
From: 1484237 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 24 Aug 2015 18:18:23 -0000
Subject: [Openstack-security] [Bug 1484237] Re: token revocations not always
 respected when using fernet tokens
References: <20150812185544.5991.94491.malonedeb@gac.canonical.com>
Message-ID: <20150824181824.19148.28872.launchpad@wampee.canonical.com>

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

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

Title:
  token revocations not always respected when using fernet tokens

Status in Keystone:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  A simple test that shows that fernet tokens are not always being
  invalidated.

  Simple test steps:

  1) gets a token
  2) deletes a token
  3) tries to validate the deleted token

  When I run this in production on 10 tokens, I get about a 20% success
  rate on the token being detected as invalid, 80% of the time, keystone
  tells me the token is valid.

  I have validated that the token is showing in the revocation event
  table.

  I've tried a 5 second delay between the calls which did not change the
  behavior.

  My current script (below) will look for 204 and 404 to show failure
  and will wait forever. I've let it wait over 5 minutes, it seems to me
  that either keystone knows immediately that the token is invalid or
  not at all.

  I do not have memcache enabled on these nodes.

  The same test has a 100% pass rate with UUID tokens.

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



From fungi at yuggoth.org  Tue Aug 25 17:55:40 2015
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 25 Aug 2015 17:55:40 -0000
Subject: [Openstack-security] [Bug 1488362] Re: Network ports are not down
 when network admin-state is made down
References: <20150825071613.21285.8577.malonedeb@gac.canonical.com>
Message-ID: <20150825175540.18971.6808.malone@wampee.canonical.com>

I've switched this to a regular public bug and marked the security
advisory task "won't fix" since this doesn't seem to represent an
exploitable security vulnerability on its own. It may indicate
incomplete Neutron documentation around caveats of "downing" a network,
and could also be seen as a security-related/hardening feature request.

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

** Information type changed from Public Security to Public

** Tags added: security

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

Title:
  Network ports are not down when network admin-state is made down

Status in neutron:
  Opinion
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  Neutron ports continue to be admin-state up and operational. It is
  expected that when network admin-state is made down, the ports of it
  should also be brought down and should not work.

  $ neutron net-create net2
  Created a new network:
  +---------------------------+--------------------------------------+
  | Field                     | Value                                |
  +---------------------------+--------------------------------------+
  | admin_state_up            | True                                 |
  | id                        | 860bd682-74cc-4864-8b12-e756dfcd9475 |
  | name                      | net2                                 |
  | provider:network_type     | vxlan                                |
  | provider:physical_network |                                      |
  | provider:segmentation_id  | 1020                                 |
  | router:external           | False                                |
  | shared                    | False                                |
  | status                    | ACTIVE                               |
  | subnets                   |                                      |
  | tenant_id                 | b3a57548ddf54b57a2f40411843b6c92     |
  +---------------------------+--------------------------------------+
  $ neutron subnet-create net2 192.168.2.0/24
  Created a new subnet:
  +-------------------+--------------------------------------------------+
  | Field             | Value                                            |
  +-------------------+--------------------------------------------------+
  | allocation_pools  | {"start": "192.168.2.2", "end": "192.168.2.254"} |
  | cidr              | 192.168.2.0/24                                   |
  | dns_nameservers   |                                                  |
  | enable_dhcp       | True                                             |
  | gateway_ip        | 192.168.2.1                                      |
  | host_routes       |                                                  |
  | id                | f29a5119-ba5c-4092-8d00-71d53c668d89             |
  | ip_version        | 4                                                |
  | ipv6_address_mode |                                                  |
  | ipv6_ra_mode      |                                                  |
  | name              |                                                  |
  | network_id        | 860bd682-74cc-4864-8b12-e756dfcd9475             |
  | tenant_id         | b3a57548ddf54b57a2f40411843b6c92                 |
  +-------------------+--------------------------------------------------+
   $ nova boot --image cirros-0.3.2-x86_64-uec --flavor 1 --nic net-id=860bd682-74cc-4864-8b12-e756dfcd9475 i3
  +--------------------------------------+----------------------------------------------------------------+
  | Property                             | Value                                                          |
  +--------------------------------------+----------------------------------------------------------------+
  | OS-DCF:diskConfig                    | MANUAL                                                         |
  | OS-EXT-AZ:availability_zone          | nova                                                           |
  | OS-EXT-SRV-ATTR:host                 | -                                                              |
  | OS-EXT-SRV-ATTR:hypervisor_hostname  | -                                                              |
  | OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                              |
  | OS-EXT-STS:power_state               | 0                                                              |
  | OS-EXT-STS:task_state                | scheduling                                                     |
  | OS-EXT-STS:vm_state                  | building                                                       |
  | OS-SRV-USG:launched_at               | -                                                              |
  | OS-SRV-USG:terminated_at             | -                                                              |
  | accessIPv4                           |                                                                |
  | accessIPv6                           |                                                                |
  | adminPass                            | UT2jcpsSSiQQ                                                   |
  | config_drive                         |                                                                |
  | created                              | 2015-08-25T07:01:44Z                                           |
  | flavor                               | m1.tiny (1)                                                    |
  | hostId                               |                                                                |
  | id                                   | 350c66d3-2817-408e-85d9-9cd1b4c47e39                           |
  | image                                | cirros-0.3.2-x86_64-uec (98a6a3ee-4008-4dac-a634-534bb457a5f7) |
  | key_name                             | -                                                              |
  | metadata                             | {}                                                             |
  | name                                 | i3                                                             |
  | os-extended-volumes:volumes_attached | []                                                             |
  | progress                             | 0                                                              |
  | security_groups                      | default                                                        |
  | status                               | BUILD                                                          |
  | tenant_id                            | b3a57548ddf54b57a2f40411843b6c92                               |
  | updated                              | 2015-08-25T07:01:44Z                                           |
  | user_id                              | b4f34210995d44bba288e0559f68b18d                               |
  +--------------------------------------+----------------------------------------------------------------+
  $ neutron router-interface-add router1 f29a5119-ba5c-4092-8d00-71d53c668d89
  Added interface ea75f789-628a-4341-94ae-0d55bc1d6244 to router router1.
  $ neutron net-update net2 --admin-state-up False
  Updated network: net2
  juno at Juno:~$ neutron net-show net2
  +---------------------------+--------------------------------------+
  | Field                     | Value                                |
  +---------------------------+--------------------------------------+
  | admin_state_up            | False                                |
  | id                        | 860bd682-74cc-4864-8b12-e756dfcd9475 |
  | name                      | net2                                 |
  | provider:network_type     | vxlan                                |
  | provider:physical_network |                                      |
  | provider:segmentation_id  | 1020                                 |
  | router:external           | False                                |
  | shared                    | False                                |
  | status                    | ACTIVE                               |
  | subnets                   | f29a5119-ba5c-4092-8d00-71d53c668d89 |
  | tenant_id                 | b3a57548ddf54b57a2f40411843b6c92     |
  +---------------------------+--------------------------------------+
  $ sudo ip netns exec qrouter-03931f82-98ef-43bb-a7e0-66875b9558bb ping 192.168.2.1
  PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
  64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.119 ms
  64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.083 ms
  ^C
  --- 192.168.2.1 ping statistics ---
  2 packets transmitted, 2 received, 0% packet loss, time 999ms
  rtt min/avg/max/mdev = 0.083/0.101/0.119/0.018 ms
  $ sudo ip netns exec qrouter-03931f82-98ef-43bb-a7e0-66875b9558bb ping 192.168.2.2
  PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data.
  64 bytes from 192.168.2.2: icmp_seq=4 ttl=64 time=4.41 ms
  64 bytes from 192.168.2.2: icmp_seq=5 ttl=64 time=1.06 ms
  64 bytes from 192.168.2.2: icmp_seq=6 ttl=64 time=1.11 ms
  64 bytes from 192.168.2.2: icmp_seq=7 ttl=64 time=1.11 ms
  ^C
  --- 192.168.2.2 ping statistics ---
  7 packets transmitted, 4 received, 42% packet loss, time 6027ms
  rtt min/avg/max/mdev = 1.062/1.925/4.412/1.436 ms

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



From 1175905 at bugs.launchpad.net  Thu Aug 27 00:41:56 2015
From: 1175905 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 27 Aug 2015 00:41: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: <20150827004156.27301.70769.malone@chaenomeles.canonical.com>

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

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

** Changed in: keystone
     Assignee: (unassigned) => Eric Brown (ericwb)

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

Title:
  passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE

Status in Keystone:
  In Progress

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 dstanek at dstanek.com  Thu Aug 27 16:38:07 2015
From: dstanek at dstanek.com (David Stanek)
Date: Thu, 27 Aug 2015 16:38:07 -0000
Subject: [Openstack-security] [Bug 1461822] Re: Lack of password complexity
	verification in Keystone
References: <20150604074737.12226.25346.malonedeb@soybean.canonical.com>
Message-ID: <20150827163807.19118.21419.malone@soybean.canonical.com>

Marking as WONTFIX because we are actively trying not to build a full
IdP solution into Keystone.

** Changed in: keystone
       Status: Triaged => Won't Fix

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

Title:
  Lack of password complexity verification in Keystone

Status in Keystone:
  Won't Fix

Bug description:
  Currently, we can specified an arbitrary string as password when
  creating a user (or updating user's password) by keystone. In normally
  use cases, the user's password shouldn't be weak, because it may cause
  potential security issues.

  Keystone should add a mechanism to perform password complexity
  verification, and to fit different scenarios, this mechanism can be
  enabled or disabled by config option. The checking rules should follow
  the industry general standard.

  There is a similar situation about instance's password in Nova, see
  bug[1] and mail thread[2].

  [1] https://bugs.launchpad.net/nova/+bug/1461431
  [2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/065600.html

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



From gerrit2 at review.openstack.org  Thu Aug 27 18:45:16 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 27 Aug 2015 18:45:16 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I1f8311f1b9ae1be02afde3e9078e49c6da373a88
Message-ID: <E1ZV2Am-0004GQ-B8@review.openstack.org>


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

Log:
commit 9ab79bbb66e0868aea15a24a3a8799cea3412221
Author: sridhargaddam <sridhar.gaddam at enovance.com>
Date:   Tue Jul 14 16:18:06 2015 +0000

    Add IPv6 Address Resolution protection
    
    Similar to IPv4 arp protection support, this patch adds the necessary OVS
    rules to prevent ports attached to agent from sending any icmpv6 neighbor
    advertisement messages that contain an IPv6 address not belonging to the port.
    
    For details please refer to "Figure 3. Attack against IPv6 Address Resolution"
    http://www.cisco.com/web/about/security/intelligence/ipv6_first_hop.html
    
    Pending items:
    Functional tests.
    
    DocImpact
    SecurityImpact
    
    Partial-Bug: #1274034
    Change-Id: I1f8311f1b9ae1be02afde3e9078e49c6da373a88




From gerrit2 at review.openstack.org  Fri Aug 28 09:42:04 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 28 Aug 2015 09:42:04 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I1f8311f1b9ae1be02afde3e9078e49c6da373a88
Message-ID: <E1ZVGAe-0006ya-LF@review.openstack.org>


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

Log:
commit b0287cdc1f045b99a3f4602833c5d503b1632765
Author: sridhargaddam <sridhar.gaddam at enovance.com>
Date:   Tue Jul 14 16:18:06 2015 +0000

    Add IPv6 Address Resolution protection
    
    Similar to IPv4 arp protection support, this patch adds the necessary OVS
    rules to prevent ports attached to agent from sending any icmpv6 neighbor
    advertisement messages that contain an IPv6 address not belonging to the port.
    
    For details please refer to "Figure 3. Attack against IPv6 Address Resolution"
    http://www.cisco.com/web/about/security/intelligence/ipv6_first_hop.html
    
    DocImpact
    SecurityImpact
    
    Partial-Bug: #1274034
    Change-Id: I1f8311f1b9ae1be02afde3e9078e49c6da373a88




From 1175905 at bugs.launchpad.net  Fri Aug 28 13:05:33 2015
From: 1175905 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 28 Aug 2015 13:05:33 -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: <20150828130533.7274.89514.malone@soybean.canonical.com>

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

commit a7235fc0511c643a8441efd3d21fc334535066e2
Author: Eric Brown <browne at vmware.com>
Date:   Wed Aug 26 17:38:04 2015 -0700

    Set max on max_password_length to passlib max
    
    With this patch if someone overrides the PASSLIB_MAX_PASSWORD_SIZE
    environment variable, keystone will fail to start with a config
    error instead of a passlib.exc.PasswordSizeError when creating
    a user.
    
    Change-Id: Ic59a7964d8044ba3ab7cb6539fecca1d190dbbcc
    Closes-Bug: #1175905


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

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

Title:
  passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE

Status in Keystone:
  Fix Committed

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 1461433 at bugs.launchpad.net  Sun Aug 30 04:17:38 2015
From: 1461433 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Sun, 30 Aug 2015 04:17:38 -0000
Subject: [Openstack-security] [Bug 1461433] Re: Automatically generated
 admin password is not complex enough
References: <20150603080018.10006.86026.malonedeb@wampee.canonical.com>
Message-ID: <20150830041738.2218.75919.malone@loganberry.canonical.com>

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
       Status: Incomplete => Expired

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

Title:
  Automatically generated admin password is not complex enough

Status in OpenStack Compute (nova):
  Expired
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  When performing actions such as create instances, evacuate instances,
  rebuild instances, rescue instances and update instances' admin
  password. When the user dose not provide admin password,
  generate_password() in utils.py is used to generate an admin password.
  Generate_password() now uses two password symbol groups: default and
  easier, the default symbol group contains numbers, upper case letters
  and small case letters. the easier symbol group contains only numbers
  and upper case letters.  The generated password is not complex enough
  and can cause security problems.

  One possible solution is to add a new symbol group:
  STRONGER_PASSWORD_SYMBOLS which contains numbers, upper case letters,
  lower case letters and also special characters such as
  `~!@#$%^&*()-_=+ and space. Then adding a new option in configuration
  file: generate_strong_password = True, when this option is set, nova
  will generate password using STRONGER_PASSWORD_SYMBOLS symbol group
  and with longer password length. If this option is not set, the
  password will be generated using the default symbol group and default
  length.

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



From 1461431 at bugs.launchpad.net  Sun Aug 30 04:17:33 2015
From: 1461431 at bugs.launchpad.net (Launchpad Bug Tracker)
Date: Sun, 30 Aug 2015 04:17:33 -0000
Subject: [Openstack-security] [Bug 1461431] Re: Enable admin password
	complexity verification
References: <20150603073922.10444.48985.malonedeb@wampee.canonical.com>
Message-ID: <20150830041734.2218.51577.malone@loganberry.canonical.com>

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
       Status: Incomplete => Expired

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

Title:
  Enable admin password complexity verification

Status in OpenStack Compute (nova):
  Expired
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  When performing actions such as create instances, evacuate instances,
  rebuild instances, rescue instances and update instances' admin
  password. The complexity of user provided admin password has not been
  verified. This can cause security problems.

  One solution will be adding a configuration option:
  using_complex_admin_password = True, if this option is set in
  configure file by administrator, then Nova will perform password
  complexity checks, the check standards can be set to following the IT
  industry general standard, if the provided admin password is not
  complex enough, an exception will be throw. If this option is not set
  in configure file, then the complexity check will be skipped.

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



From gerrit2 at review.openstack.org  Sun Aug 30 15:01:01 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 30 Aug 2015 15:01:01 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I1f8311f1b9ae1be02afde3e9078e49c6da373a88
Message-ID: <E1ZW46P-0004dW-77@review.openstack.org>


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

Log:
commit b786af96efd5670064ea3c0c6f7c05285d5b2886
Author: sridhargaddam <sridhar.gaddam at enovance.com>
Date:   Tue Jul 14 16:18:06 2015 +0000

    Add IPv6 Address Resolution protection
    
    Similar to IPv4 arp protection support, this patch adds the necessary OVS
    rules to prevent ports attached to agent from sending any icmpv6 neighbor
    advertisement messages that contain an IPv6 address not belonging to the port.
    
    For details please refer to "Figure 3. Attack against IPv6 Address Resolution"
    http://www.cisco.com/web/about/security/intelligence/ipv6_first_hop.html
    
    DocImpact
    SecurityImpact
    
    Partial-Bug: #1274034
    Change-Id: I1f8311f1b9ae1be02afde3e9078e49c6da373a88




From gerrit2 at review.openstack.org  Sun Aug 30 16:44:12 2015
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 30 Aug 2015 16:44:12 +0000
Subject: [Openstack-security] [openstack/neutron] SecurityImpact review
 request change I1f8311f1b9ae1be02afde3e9078e49c6da373a88
Message-ID: <E1ZW5iG-0004vr-Me@review.openstack.org>


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

Log:
commit 5966efd573d8bb9d23abc7ad8bcd4f17d10ee3d4
Author: sridhargaddam <sridhar.gaddam at enovance.com>
Date:   Tue Jul 14 16:18:06 2015 +0000

    Add IPv6 Address Resolution protection
    
    Similar to IPv4 arp protection support, this patch adds the necessary OVS
    rules to prevent ports attached to agent from sending any icmpv6 neighbor
    advertisement messages that contain an IPv6 address not belonging to the port.
    
    For details please refer to "Figure 3. Attack against IPv6 Address Resolution"
    http://www.cisco.com/web/about/security/intelligence/ipv6_first_hop.html
    
    DocImpact
    SecurityImpact
    
    Partial-Bug: #1274034
    Change-Id: I1f8311f1b9ae1be02afde3e9078e49c6da373a88




From SlickNik at gmail.com  Mon Aug 31 07:59:22 2015
From: SlickNik at gmail.com (Nikhil Manchanda)
Date: Mon, 31 Aug 2015 07:59:22 -0000
Subject: [Openstack-security] [Bug 1434545] Re: Several command injection
 vulnerabilities in guestagent/pkg
References: <20150320131103.23017.37206.malonedeb@chaenomeles.canonical.com>
Message-ID: <20150831075924.27085.96486.launchpad@chaenomeles.canonical.com>

** Changed in: trove
    Milestone: liberty-3 => ongoing

** Changed in: trove
     Assignee: Anna Shen (ruiyuan-shen) => (unassigned)

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

Title:
  Several command injection vulnerabilities in guestagent/pkg

Status in OpenStack Security Advisory:
  Won't Fix
Status in Trove:
  Triaged

Bug description:
  At several places in the file guestagent/pkg.py, there are shell
  injection vulnerabilities:

  https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L209

  In this line, the cmd_list is being built parameterized, but then it
  is just combined into one big string and called directly on a shell
  through the command getstatusoutput, which does a popen.  If package
  name is set maliciously, the command will execute arbitrary code with
  the privilege of the trove process.

  The same is true on this line,
  https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L258
  , where a package named something like "abc; rm -rf /etc" will cause
  all files in /etc which Trove has permissions for, to be deleted.

  Again, on this line:
  https://github.com/openstack/trove/blob/master/trove/guestagent/pkg.py#L371
  , a malicious package name will cause arbitrary code injection with
  the privileges of the Trove process.

  I'm not nearly familiar enough with the Trove code and uses to know
  all the ways that package names for this code can be set, but these
  commands should be parameterized.

  Finally, os.popen is a deprecated function.  The subprocess module
  should be used instead.

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



From edmondsw at us.ibm.com  Mon Aug 31 22:26:06 2015
From: edmondsw at us.ibm.com (Matthew Edmonds)
Date: Mon, 31 Aug 2015 22:26:06 -0000
Subject: [Openstack-security] [Bug 1490693] Re: session fails to sanitize
	response body of passwords
References: <20150831192731.19704.45527.malonedeb@soybean.canonical.com>
Message-ID: <20150831222606.21285.16550.launchpad@gac.canonical.com>

** Tags added: security

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

Title:
  session fails to sanitize response body of passwords

Status in python-keystoneclient:
  In Progress

Bug description:
  Seeing this in the n-cpu logs when nova calls the os-
  initialize_connection API via python-cinderclient and cinder returns a
  response body with credentials in it:

  http://logs.openstack.org/66/218666/1/check/gate-tempest-dsvm-
  full/3ac1f2b/logs/screen-n-cpu.txt.gz#_2015-08-30_16_33_09_578

  keystoneclient.session is logging the response body without sanitizing
  it first.

  2015-08-30 16:33:09.578 DEBUG keystoneclient.session [req-ff63c358-41b0-4aac-8d8c-e369d82a0d5e tempest-TestMinimumBasicScenario-472140388 tempest-TestMinimumBasicScenario-192291337] REQ: curl -g -i -X POST http://127.0.0.1:8776/v2/8a98625b8c5445afbc72496ce2f7ab7f/volumes/744d2085-8e78-40a5-8659-ef3cffb2480e/action -H "User-Agent: python-cinderclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}fbdcb6c88ebb8ec83181b62e338a1a4b909f7031" -d '{"os-initialize_connection": {"connector": {"initiator": "iqn.1993-08.org.debian:01:f991bccc0", "ip": "172.99.69.228", "platform": "x86_64", "host": "devstack-trusty-rax-iad-4640004", "os_type": "linux2", "multipath": false}}}' _http_log_request /usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:195
  2015-08-30 16:33:10.674 DEBUG keystoneclient.session [req-ff63c358-41b0-4aac-8d8c-e369d82a0d5e tempest-TestMinimumBasicScenario-472140388 tempest-TestMinimumBasicScenario-192291337] RESP: [200] content-length: 447 x-compute-request-id: req-747a68eb-f62e-4a43-aa8a-ff332c92783d connection: keep-alive date: Sun, 30 Aug 2015 16:33:10 GMT content-type: application/json x-openstack-request-id: req-747a68eb-f62e-4a43-aa8a-ff332c92783d 
  RESP BODY: {"connection_info": {"driver_volume_type": "iscsi", "data": {"auth_password": "FF5vCvAvks8iQ2Vx", "target_discovered": false, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.2010-10.org.openstack:volume-744d2085-8e78-40a5-8659-ef3cffb2480e", "target_portal": "172.99.69.228:3260", "volume_id": "744d2085-8e78-40a5-8659-ef3cffb2480e", "target_lun": 1, "access_mode": "rw", "auth_username": "82tvLceDnfHjg6jrTwpq", "auth_method": "CHAP"}}}

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



From corey.wright at rackspace.com  Wed Aug 19 23:40:53 2015
From: corey.wright at rackspace.com (Corey Wright)
Date: Wed, 19 Aug 2015 23:40:53 -0000
Subject: [Openstack-security] [Bug 1483132] Re: ssh-keygen-to-Paramiko
 change breaks third-party tools
References: <20150810064713.19114.43085.malonedeb@wampee.canonical.com>
Message-ID: <20150819233405.19469.82225.malone@soybean.canonical.com>

Paramiko update: Once https://github.com/paramiko/paramiko/pull/394 is
merged (switching Paramiko from PyCrypto to Cryptography which uses
OpenSSL) and a new release is made (planned for September), then the
private key output will be DER.

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

Title:
  ssh-keygen-to-Paramiko change breaks third-party tools

Status in OpenStack Compute (nova):
  New

Bug description:
  Changing ssh key generation from OpenSSH's ssh-keygen to the Paramiko
  library [1][2] changed (unintentionally?) the ASN.1 encoding format of
  SSH private keys from DER to BER.  (DER is a strict subset of BER, so
  anything that can read BER can read DER, but not necessarily the other
  way around.)

  Some third-party tools only support DER and this has created at least
  one issue [3] (specifically because Go's standard library only
  supports DER).

  I have provided Paramiko with a small change that makes its SSH
  private key output equal to OpenSSH's ssh-keygen output (and
  presumably DER formatted) [4].

  Providing a change to Paramiko is just one method of addressing this
  backwards-incompatibility and interoperability issue.  Should the
  Paramiko change be accepted the unit test output vectors will need to
  be changed, but should it not, is a reversion of or modification to
  Nova acceptable to maintain backwards-compatibility and
  interoperability?

  [1] https://review.openstack.org/157931
  [2] http://git.openstack.org/cgit/openstack/nova/commit/?id=3f3f9bf22efd2fb209d2a2fe0246f4857cd2d21a
  [3] https://github.com/mitchellh/packer/issues/2526
  [4] https://github.com/paramiko/paramiko/pull/572

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