From 1465922 at bugs.launchpad.net  Mon Jan  4 04:53:22 2016
From: 1465922 at bugs.launchpad.net (Stanislaw Pitucha)
Date: Mon, 04 Jan 2016 04:53:22 -0000
Subject: [Openstack-security] [Bug 1465922] Re: Password visible in clear
 text in keystone.log when user created and keystone debug logging is
 enabled
References: <20150617025422.18505.35016.malonedeb@gac.canonical.com>
Message-ID: <20160104045322.25727.58521.malone@soybean.canonical.com>

For Bandit I'm marking "Won't fix":
Offending code is:

    LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {
        'action': action,
        'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])})

There's no indication of what the kwargs are, so without a runtime
integration (tainting) or symbolic execution this is not realistic to
pick up. At the call sites the kwargs are not a literal dict, but rather
values from up the call chain, so not easy to analyse.

It would be great to pick this up, but it's way out of reach for the
engine currently or in reasonable future.

** Changed in: bandit
       Status: New => Won't Fix

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

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

Title:
  Password visible in clear text in keystone.log when user created and
  keystone debug logging is enabled

Status in Bandit:
  Won't Fix
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) juno series:
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  grep CLEARTEXTPASSWORD keystone.log

  2015-06-16 06:44:39.770 20986 DEBUG keystone.common.controller [-]
  RBAC: Authorizing identity:create_user(user={u'domain_id': u'default',
  u'password': u'CLEARTEXTPASSWORD', u'enabled': True,
  u'default_project_id': u'0175b43419064ae38c4b74006baaeb8d', u'name':
  u'DermotJ'}) _build_policy_check_credentials /usr/lib/python2.7/site-
  packages/keystone/common/controller.py:57

  Issue code:
  https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L57

      LOG.debug('RBAC: Authorizing %(action)s(%(kwargs)s)', {
          'action': action,
          'kwargs': ', '.join(['%s=%s' % (k, kwargs[k]) for k in kwargs])})

  Shadow the values of sensitive fields like 'password' by some
  meaningless garbled text like "XXXXX" is one way to fix.

  Well, in addition to this, I think we should never pass the 'password'
  with its original value along the code and save it in any persistence,
  instead we should convert it to a strong hash value as early as
  possible. With the help of a good hash system, we never have to need
  the original value of the password, right?

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



From 1479523 at bugs.launchpad.net  Wed Jan  6 09:09:04 2016
From: 1479523 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 06 Jan 2016 09:09:04 -0000
Subject: [Openstack-security] [Bug 1479523] Re: Stop using debug for
	insecure responses
References: <20150729211446.8945.2269.malonedeb@gac.canonical.com>
Message-ID: <20160106090904.27604.50510.malone@gac.canonical.com>

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

commit 2afad4dc30cd1e210f2353ce987fe1bbdd8b93d7
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Wed Jul 29 16:29:42 2015 -0500

    Config option for insecure responses
    
    oslo.log's "debug" option was co-opted to also indicate that the
    responses should include more information. A separate config
    option should be used instead so that deployers don't mistakenly
    expose themselves to security issues.
    
    The debug option still is used for what it does in oslo.log and
    how it works on all other projects -- if you're not using a log
    config file it sets the base logger to debug.
    
    SecurityImpact
    
    Change-Id: Icf8dd2f0b88abc89092d487bbcefb525960c4ec6
    Closes-Bug: 1479523


** Changed in: keystone
       Status: In Progress => 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/1479523

Title:
  Stop using debug for insecure responses

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  
  If you set debug=true in keystone.conf the server 1) logs at debug level, and 2) sends out insecure responses. Deployers might think that debug=true only does 1, not knowing about 2 since it's not documented in the sample config. The behaviors should be decoupled to improve security a bit.

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



From tdecacqu at redhat.com  Mon Jan 11 16:37:02 2016
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Mon, 11 Jan 2016 16:37:02 -0000
Subject: [Openstack-security] [Bug 1501808] Re: Enabling soft-deletes opens
	a DOS on compute hosts
References: <20151001152652.22834.78736.malonedeb@gac.canonical.com>
Message-ID: <20160111163702.8854.56741.malone@wampee.canonical.com>

I've removed the privacy settings and put the OSSA tasks as Won't Fix
based on comment #3. This can be put back to incomplete if the situation
changes.

** Tags added: security

** 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.
- 
  If the user sets reclaim_instance_interval to anything other than 0,
  then when a user requests an instance delete, it will instead be soft
  deleted. Soft delete explicitly releases the user's quota, but does not
  release the instance's resources until period task
  _reclaim_queued_deletes runs with a period of reclaim_instance_interval
  seconds.
  
  A malicious authenticated user can repeatedly create and delete
  instances without limit, which will consume resources on the host
  without consuming their quota. If done quickly enough, this will exhaust
  host resources.
  
  I'm not entirely sure what to suggest in remediation, as this seems to
  be a deliberate design. The most obvious fix would be to not release
  quota until the instance is reaped, but that would be a significant
  change in behaviour.
  
  This is very similar to https://bugs.launchpad.net/bugs/cve/2015-3280 ,
  except that we do it deliberately.

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

** Information type changed from Private Security to Public

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

Title:
  Enabling soft-deletes opens a DOS on compute hosts

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

Bug description:
  If the user sets reclaim_instance_interval to anything other than 0,
  then when a user requests an instance delete, it will instead be soft
  deleted. Soft delete explicitly releases the user's quota, but does
  not release the instance's resources until period task
  _reclaim_queued_deletes runs with a period of
  reclaim_instance_interval seconds.

  A malicious authenticated user can repeatedly create and delete
  instances without limit, which will consume resources on the host
  without consuming their quota. If done quickly enough, this will
  exhaust host resources.

  I'm not entirely sure what to suggest in remediation, as this seems to
  be a deliberate design. The most obvious fix would be to not release
  quota until the instance is reaped, but that would be a significant
  change in behaviour.

  This is very similar to https://bugs.launchpad.net/bugs/cve/2015-3280
  , except that we do it deliberately.

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



From fungi at yuggoth.org  Thu Jan 14 14:37:24 2016
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 14 Jan 2016 14:37:24 -0000
Subject: [Openstack-security] [Bug 1533065] Re: stack_create 500 Error with
	non-string stack_name
References: <20160112054500.16030.6854.malonedeb@gac.canonical.com>
Message-ID: <20160114143724.26194.79940.malone@soybean.canonical.com>

Based on the discussion above, this sounds like class C1 (not considered
a practical vulnerability https://security.openstack.org/vmt-
process.html#incident-report-taxonomy ) so I'm switching the security
advisory task to Won't Fix and triaging this in public as a hardening
opportunity. If new details emerge, this decision can be revisited.

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

Title:
  stack_create 500 Error with non-string stack_name

Status in heat:
  Confirmed
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.

  When sending a stack create request using the REST API through curl
  with the stack_name parameter set to either a list, or a dictionary a
  Server Error occurs.

  The major problem with this is that when this occurs the response of
  the request will show what database backend the cloud is utilising
  whether it be MySQL, or PostgreSQL. This information could be used by
  a malicious user to exploit the databases. Additionally to the
  database engine being known, the query itself is also printed in the
  response.

  This occurs regardless of the level of logging being set for the heat
  service.

  This has been seen in the master branch as of 12/01/2016.

  I have attached the response of a request with a Traceback.

  The data being sent is the following:
  {
      "files": {},
      "disable_rollback": true,
      "parameters": {
          "flavor": "m1.tiny"
      },
      "stack_name": {"test": "sample"},
      "template": {
          "heat_template_version": "2013-05-23",
          "description": "Simple template to test heat commands",
          "parameters": {
              "flavor": {
                  "default": "m1.tiny",
                  "type": "string"
              }
          },
          "resources": {
              "hello_world": {
                  "type": "OS::Nova::Server",
                  "properties": {
                      "key_name": "heat_key",
                      "flavor": {
                          "get_param": "flavor"
                      },
                      "image": "40be8d1a-3eb9-40de-8abd-43237517384f",
                      "user_data": "#!/bin/bash -xv\necho \"hello world\" &gt; /root/hello-world.txt\n"
                  }
              }
          }
      },
      "timeout_mins": 60
  }

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



From 1533065 at bugs.launchpad.net  Thu Jan 14 15:02:58 2016
From: 1533065 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 14 Jan 2016 15:02:58 -0000
Subject: [Openstack-security] [Bug 1533065] Re: stack_create 500 Error with
	non-string stack_name
References: <20160112054500.16030.6854.malonedeb@gac.canonical.com>
Message-ID: <20160114150258.26548.21805.malone@soybean.canonical.com>

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

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

Title:
  stack_create 500 Error with non-string stack_name

Status in heat:
  In Progress
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.

  When sending a stack create request using the REST API through curl
  with the stack_name parameter set to either a list, or a dictionary a
  Server Error occurs.

  The major problem with this is that when this occurs the response of
  the request will show what database backend the cloud is utilising
  whether it be MySQL, or PostgreSQL. This information could be used by
  a malicious user to exploit the databases. Additionally to the
  database engine being known, the query itself is also printed in the
  response.

  This occurs regardless of the level of logging being set for the heat
  service.

  This has been seen in the master branch as of 12/01/2016.

  I have attached the response of a request with a Traceback.

  The data being sent is the following:
  {
      "files": {},
      "disable_rollback": true,
      "parameters": {
          "flavor": "m1.tiny"
      },
      "stack_name": {"test": "sample"},
      "template": {
          "heat_template_version": "2013-05-23",
          "description": "Simple template to test heat commands",
          "parameters": {
              "flavor": {
                  "default": "m1.tiny",
                  "type": "string"
              }
          },
          "resources": {
              "hello_world": {
                  "type": "OS::Nova::Server",
                  "properties": {
                      "key_name": "heat_key",
                      "flavor": {
                          "get_param": "flavor"
                      },
                      "image": "40be8d1a-3eb9-40de-8abd-43237517384f",
                      "user_data": "#!/bin/bash -xv\necho \"hello world\" &gt; /root/hello-world.txt\n"
                  }
              }
          }
      },
      "timeout_mins": 60
  }

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



From 1533065 at bugs.launchpad.net  Thu Jan 14 18:33:46 2016
From: 1533065 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 14 Jan 2016 18:33:46 -0000
Subject: [Openstack-security] [Bug 1533065] Re: stack_create 500 Error with
	non-string stack_name
References: <20160112054500.16030.6854.malonedeb@gac.canonical.com>
Message-ID: <20160114183346.29431.58923.malone@chaenomeles.canonical.com>

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

commit 1636b3b0530f2e8422997fff810188e4676de511
Author: Steven Hardy <shardy at redhat.com>
Date:   Wed Jan 13 10:34:18 2016 +0000

    Handle invalid stack names which are non-string
    
    If we get passed a non-string stack name, e.g a map or list, we
    fail with a DB error associated with looking up the existing stack.
    
    So instead force all stack lookups to use string identifiers, and
    make the name validation for new stacks robust to fail gracefully
    when there is an invalid (non string) argument passed.
    
    Change-Id: I052dc4a715773895d070e1e9f26183c6a1cf3d7f
    Closes-Bug: #1533065


** Changed in: heat
       Status: In Progress => 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/1533065

Title:
  stack_create 500 Error with non-string stack_name

Status in heat:
  Fix Released
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.

  When sending a stack create request using the REST API through curl
  with the stack_name parameter set to either a list, or a dictionary a
  Server Error occurs.

  The major problem with this is that when this occurs the response of
  the request will show what database backend the cloud is utilising
  whether it be MySQL, or PostgreSQL. This information could be used by
  a malicious user to exploit the databases. Additionally to the
  database engine being known, the query itself is also printed in the
  response.

  This occurs regardless of the level of logging being set for the heat
  service.

  This has been seen in the master branch as of 12/01/2016.

  I have attached the response of a request with a Traceback.

  The data being sent is the following:
  {
      "files": {},
      "disable_rollback": true,
      "parameters": {
          "flavor": "m1.tiny"
      },
      "stack_name": {"test": "sample"},
      "template": {
          "heat_template_version": "2013-05-23",
          "description": "Simple template to test heat commands",
          "parameters": {
              "flavor": {
                  "default": "m1.tiny",
                  "type": "string"
              }
          },
          "resources": {
              "hello_world": {
                  "type": "OS::Nova::Server",
                  "properties": {
                      "key_name": "heat_key",
                      "flavor": {
                          "get_param": "flavor"
                      },
                      "image": "40be8d1a-3eb9-40de-8abd-43237517384f",
                      "user_data": "#!/bin/bash -xv\necho \"hello world\" &gt; /root/hello-world.txt\n"
                  }
              }
          }
      },
      "timeout_mins": 60
  }

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



From fungi at yuggoth.org  Thu Jan 14 21:30:14 2016
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 14 Jan 2016 21:30:14 -0000
Subject: [Openstack-security] [Bug 1533065] Re: stack_create 500 Error with
	non-string stack_name
References: <20160112054500.16030.6854.malonedeb@gac.canonical.com>
Message-ID: <20160114213015.29990.66425.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.
- 
  When sending a stack create request using the REST API through curl with
  the stack_name parameter set to either a list, or a dictionary a Server
  Error occurs.
  
  The major problem with this is that when this occurs the response of the
  request will show what database backend the cloud is utilising whether
  it be MySQL, or PostgreSQL. This information could be used by a
  malicious user to exploit the databases. Additionally to the database
  engine being known, the query itself is also printed in the response.
  
  This occurs regardless of the level of logging being set for the heat
  service.
  
  This has been seen in the master branch as of 12/01/2016.
  
  I have attached the response of a request with a Traceback.
  
  The data being sent is the following:
  {
      "files": {},
      "disable_rollback": true,
      "parameters": {
          "flavor": "m1.tiny"
      },
      "stack_name": {"test": "sample"},
      "template": {
          "heat_template_version": "2013-05-23",
          "description": "Simple template to test heat commands",
          "parameters": {
              "flavor": {
                  "default": "m1.tiny",
                  "type": "string"
              }
          },
          "resources": {
              "hello_world": {
                  "type": "OS::Nova::Server",
                  "properties": {
                      "key_name": "heat_key",
                      "flavor": {
                          "get_param": "flavor"
                      },
                      "image": "40be8d1a-3eb9-40de-8abd-43237517384f",
                      "user_data": "#!/bin/bash -xv\necho \"hello world\" &gt; /root/hello-world.txt\n"
                  }
              }
          }
      },
      "timeout_mins": 60
  }

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

Title:
  stack_create 500 Error with non-string stack_name

Status in heat:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  When sending a stack create request using the REST API through curl
  with the stack_name parameter set to either a list, or a dictionary a
  Server Error occurs.

  The major problem with this is that when this occurs the response of
  the request will show what database backend the cloud is utilising
  whether it be MySQL, or PostgreSQL. This information could be used by
  a malicious user to exploit the databases. Additionally to the
  database engine being known, the query itself is also printed in the
  response.

  This occurs regardless of the level of logging being set for the heat
  service.

  This has been seen in the master branch as of 12/01/2016.

  I have attached the response of a request with a Traceback.

  The data being sent is the following:
  {
      "files": {},
      "disable_rollback": true,
      "parameters": {
          "flavor": "m1.tiny"
      },
      "stack_name": {"test": "sample"},
      "template": {
          "heat_template_version": "2013-05-23",
          "description": "Simple template to test heat commands",
          "parameters": {
              "flavor": {
                  "default": "m1.tiny",
                  "type": "string"
              }
          },
          "resources": {
              "hello_world": {
                  "type": "OS::Nova::Server",
                  "properties": {
                      "key_name": "heat_key",
                      "flavor": {
                          "get_param": "flavor"
                      },
                      "image": "40be8d1a-3eb9-40de-8abd-43237517384f",
                      "user_data": "#!/bin/bash -xv\necho \"hello world\" &gt; /root/hello-world.txt\n"
                  }
              }
          }
      },
      "timeout_mins": 60
  }

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



From tdecacqu at redhat.com  Fri Jan 15 15:11:37 2016
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Fri, 15 Jan 2016 15:11:37 -0000
Subject: [Openstack-security] [Bug 1534322] Re: On new port,
 traffic flow is allowed before security groups are programmed
References: <20160114214439.14625.28884.malonedeb@wampee.canonical.com>
Message-ID: <20160115151138.25969.53876.launchpad@soybean.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/1534322

Title:
  On new port, traffic flow is allowed before security groups are
  programmed

Status in neutron:
  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.

  --

  Description:
  During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed.

  File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
  Funtion: process_network_ports

  Step-by-step:
  During the creation of a neutron port, the following calls are made:
  - treat_devices_added_or_updated
  - sg_agent.setup_port_filters
  - _bind_devices

  Before early November, process_network_ports called
  sg_agent.setup_port_filters before it called _bind_devices. This meant
  that security groups were programmed before traffic flow is enabled by
  _bind_devices, which sets the port-lvm mapping in br-int.

  Bug #1512636 reversed this order of operation, so that _bind_devices
  is called before sg_agent.setup_port_filters. This opens up a brief
  security hole, allowing traffic to flow for a short time before
  security groups are applied.

  Proposed solution:
  Revert bug# 1512636

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



From tdecacqu at redhat.com  Fri Jan 15 15:11:27 2016
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Fri, 15 Jan 2016 15:11:27 -0000
Subject: [Openstack-security] [Bug 1534299] Re: keystoneclient needs to mark
	secret config options
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160115151127.28540.86026.malone@gac.canonical.com>

I've removed the privacy settings and put the OSSA tasks as Won't Fix
since it's a B3 type of bug (according to VMT taxonomy
https://security.openstack.org/vmt-process.html#incident-report-taxonomy
), This can be put back to incomplete if the situation changes.

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  New
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  New

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From 1534322 at bugs.launchpad.net  Fri Jan 15 15:22:12 2016
From: 1534322 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 15 Jan 2016 15:22:12 -0000
Subject: [Openstack-security] [Bug 1534322] Re: On new port,
 traffic flow is allowed before security groups are programmed
References: <20160114214439.14625.28884.malonedeb@wampee.canonical.com>
Message-ID: <20160115152212.15304.37873.malone@wampee.canonical.com>

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

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

Title:
  On new port, traffic flow is allowed before security groups are
  programmed

Status in neutron:
  In Progress
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.

  --

  Description:
  During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed.

  File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
  Funtion: process_network_ports

  Step-by-step:
  During the creation of a neutron port, the following calls are made:
  - treat_devices_added_or_updated
  - sg_agent.setup_port_filters
  - _bind_devices

  Before early November, process_network_ports called
  sg_agent.setup_port_filters before it called _bind_devices. This meant
  that security groups were programmed before traffic flow is enabled by
  _bind_devices, which sets the port-lvm mapping in br-int.

  Bug #1512636 reversed this order of operation, so that _bind_devices
  is called before sg_agent.setup_port_filters. This opens up a brief
  security hole, allowing traffic to flow for a short time before
  security groups are applied.

  Proposed solution:
  Revert bug# 1512636

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



From 1534322 at bugs.launchpad.net  Fri Jan 15 15:23:20 2016
From: 1534322 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 15 Jan 2016 15:23:20 -0000
Subject: [Openstack-security] [Bug 1534322] Fix proposed to neutron
	(stable/liberty)
References: <20160114214439.14625.28884.malonedeb@wampee.canonical.com>
Message-ID: <20160115152321.14983.85408.malone@wampee.canonical.com>

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/268194

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

Title:
  On new port, traffic flow is allowed before security groups are
  programmed

Status in neutron:
  In Progress
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.

  --

  Description:
  During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed.

  File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
  Funtion: process_network_ports

  Step-by-step:
  During the creation of a neutron port, the following calls are made:
  - treat_devices_added_or_updated
  - sg_agent.setup_port_filters
  - _bind_devices

  Before early November, process_network_ports called
  sg_agent.setup_port_filters before it called _bind_devices. This meant
  that security groups were programmed before traffic flow is enabled by
  _bind_devices, which sets the port-lvm mapping in br-int.

  Bug #1512636 reversed this order of operation, so that _bind_devices
  is called before sg_agent.setup_port_filters. This opens up a brief
  security hole, allowing traffic to flow for a short time before
  security groups are applied.

  Proposed solution:
  Revert bug# 1512636

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



From 1534299 at bugs.launchpad.net  Fri Jan 15 15:27:50 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 15 Jan 2016 15:27:50 -0000
Subject: [Openstack-security] [Bug 1534299] Re: keystoneclient needs to mark
	secret config options
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160115152750.14736.70829.malone@wampee.canonical.com>

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

** Changed in: python-keystoneclient
       Status: New => In Progress

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

** Changed in: keystoneauth
     Assignee: (unassigned) => Brant Knudson (blk-u)

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  In Progress

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From 1534299 at bugs.launchpad.net  Fri Jan 15 15:29:26 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 15 Jan 2016 15:29:26 -0000
Subject: [Openstack-security] [Bug 1534299] Fix proposed to keystoneauth
	(master)
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160115152926.28044.56044.malone@gac.canonical.com>

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

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  In Progress

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From cihand at skyatlas.com  Thu Jan  7 12:00:50 2016
From: cihand at skyatlas.com (Fahri Cihan Demirci)
Date: Thu, 07 Jan 2016 12:00:50 -0000
Subject: [Openstack-security] [Bug 1511541] Re: Possible incomplete fix for
	OSSA-2015-005
References: <20151029214642.13606.53636.malonedeb@wampee.canonical.com>
Message-ID: <20160107120050.28272.86246.launchpad@gac.canonical.com>

** Tags added: console

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

Title:
  Possible incomplete fix for OSSA-2015-005

Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking
  Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete.

  https://bugs.launchpad.net/nova/+bug/1409142/comments/146
  https://bugs.launchpad.net/nova/+bug/1409142/comments/149

  Further investigation is needed.

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



From rcresswe at cisco.com  Tue Jan 12 13:15:42 2016
From: rcresswe at cisco.com (Rob Cresswell)
Date: Tue, 12 Jan 2016 13:15:42 -0000
Subject: [Openstack-security] [Bug 1369870] Re: The "message" cookie is not
	marked as "secure"
References: <20140916063505.5162.66017.malonedeb@wampee.canonical.com>
Message-ID: <20160112131543.14625.63173.malone@wampee.canonical.com>

The default value for SESSION_COOKIE_SECURE is False, but the deployment
guide advises changing it to True.

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

** Changed in: horizon
     Assignee: Kent Wang (k.wang) => (unassigned)

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

Title:
  The "message" cookie is not marked as "secure"

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

Bug description:
  The message cookie is not marked as 'secure', as identified by the
  following security report.  If might contain sensitive information,
  and would benefit from being marked as secure.

  ---

  Affected URL: https://Ip_address/settings/
  Affected Entity: messages, django_timezone, horizon_pagesize, and horizon_language
  Risk: It may be possible to steal user and session information (cookies) that was sent during an encrypted session

  Causes: The web application sends non-secure cookies over SSL

  Recommend Fix: Add the 'Secure' attribute to all sensitive cookies

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



From major at mhtx.net  Fri Jan 15 16:30:11 2016
From: major at mhtx.net (Major Hayden)
Date: Fri, 15 Jan 2016 16:30:11 -0000
Subject: [Openstack-security] [Bug 1534658] [NEW] [security] Don't
 initialize AIDE database by default
Message-ID: <20160115163011.28009.69253.malonedeb@gac.canonical.com>

Public bug reported:

The AIDE database initialization consumes a lot of CPU time and I/O
resources. We shouldn't initialize the database by default, but this
should be configurable by the deployer. This needs to be documented in
the Ansible code and within the docs.

** Affects: openstack-ansible
     Importance: Undecided
         Status: New


** Tags: security

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

Title:
  [security] Don't initialize AIDE database by default

Status in openstack-ansible:
  New

Bug description:
  The AIDE database initialization consumes a lot of CPU time and I/O
  resources. We shouldn't initialize the database by default, but this
  should be configurable by the deployer. This needs to be documented in
  the Ansible code and within the docs.

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



From major at mhtx.net  Fri Jan 15 16:39:36 2016
From: major at mhtx.net (Major Hayden)
Date: Fri, 15 Jan 2016 16:39:36 -0000
Subject: [Openstack-security] [Bug 1534658] Re: [security] Don't initialize
	AIDE database by default
References: <20160115163011.28009.69253.malonedeb@gac.canonical.com>
Message-ID: <20160115163936.14590.74866.malone@wampee.canonical.com>

Fix proposed in: https://review.openstack.org/#/c/268222/

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

Title:
  [security] Don't initialize AIDE database by default

Status in openstack-ansible:
  New

Bug description:
  The AIDE database initialization consumes a lot of CPU time and I/O
  resources. We shouldn't initialize the database by default, but this
  should be configurable by the deployer. This needs to be documented in
  the Ansible code and within the docs.

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



From 1534299 at bugs.launchpad.net  Fri Jan 15 22:43:46 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 15 Jan 2016 22:43:46 -0000
Subject: [Openstack-security] [Bug 1534299] Re: keystoneclient needs to mark
	secret config options
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160115224347.28298.5209.launchpad@gac.canonical.com>

** Changed in: keystoneauth
     Assignee: Brant Knudson (blk-u) => Steve Martinelli (stevemar)

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  In Progress

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From stevemar at ca.ibm.com  Fri Jan 15 22:51:31 2016
From: stevemar at ca.ibm.com (Steve Martinelli)
Date: Fri, 15 Jan 2016 22:51:31 -0000
Subject: [Openstack-security] [Bug 1534299] Re: keystoneclient needs to mark
	secret config options
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160115225132.29871.89452.launchpad@chaenomeles.canonical.com>

** Changed in: keystoneauth
     Assignee: Steve Martinelli (stevemar) => Brant Knudson (blk-u)

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  In Progress

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From 1534299 at bugs.launchpad.net  Sat Jan 16 00:31:34 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Sat, 16 Jan 2016 00:31:34 -0000
Subject: [Openstack-security] [Bug 1534299] Re: keystoneclient needs to mark
	secret config options
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160116003134.14949.63447.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/268198
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=04f9f33b4b6079d39c3feea0b1ec1211a1de6a04
Submitter: Jenkins
Branch:    master

commit 04f9f33b4b6079d39c3feea0b1ec1211a1de6a04
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Jan 14 16:22:04 2016 -0600

    Mark password/secret options as secret
    
    Password, token, and secret options should be marked as secret=True
    so that when the value is logged the logger knows to obfuscate the
    value.
    
    Change-Id: I6ebdfa3bf6faf37bc11640a5826b3b55bb920fc4
    Closes-Bug: 1534299


** Changed in: python-keystoneclient
       Status: In Progress => 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/1534299

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  In Progress
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  Fix Released

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From 1534299 at bugs.launchpad.net  Sat Jan 16 02:14:13 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Sat, 16 Jan 2016 02:14:13 -0000
Subject: [Openstack-security] [Bug 1534299] Re: keystoneclient needs to mark
	secret config options
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160116021413.25683.77583.malone@soybean.canonical.com>

Reviewed:  https://review.openstack.org/268199
Committed: https://git.openstack.org/cgit/openstack/keystoneauth/commit/?id=fcd9538eaf2b374ec5188426454a5c598621b902
Submitter: Jenkins
Branch:    master

commit fcd9538eaf2b374ec5188426454a5c598621b902
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Jan 14 16:43:55 2016 -0600

    Mark password/secret options as secret
    
    Password, token, and secret options should be marked as secret=True
    so that when the value is logged the logger knows to obfuscate the
    value.
    
    Change-Id: I4818c4cc04cc6a4e1e3cf09d5e0b7b4ffefbb892
    Closes-Bug: 1534299


** Changed in: keystoneauth
       Status: In Progress => 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/1534299

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  Fix Released

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From 1534322 at bugs.launchpad.net  Sat Jan 16 13:41:18 2016
From: 1534322 at bugs.launchpad.net (OpenStack Infra)
Date: Sat, 16 Jan 2016 13:41:18 -0000
Subject: [Openstack-security] [Bug 1534322] Re: On new port,
 traffic flow is allowed before security groups are programmed
References: <20160114214439.14625.28884.malonedeb@wampee.canonical.com>
Message-ID: <20160116134118.30157.80298.malone@chaenomeles.canonical.com>

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

commit 29dffc084164c29b4726dc08bb986f7961e9fa9f
Author: Kevin Benton <kevinbenton at buttewifi.com>
Date:   Fri Jan 15 15:22:03 2016 +0000

    Revert "Change function call order in ovs_neutron_agent."
    
    This reverts commit 9c72bac0ea37971b2d5430246295c5e8b859b4ed.
    
    Change-Id: I9b6b588b68f63f6688749d011dc8b20ef80edadc
    Closes-Bug: #1534322


** Changed in: neutron
       Status: In Progress => 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/1534322

Title:
  On new port, traffic flow is allowed before security groups are
  programmed

Status in neutron:
  Fix Released
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.

  --

  Description:
  During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed.

  File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
  Funtion: process_network_ports

  Step-by-step:
  During the creation of a neutron port, the following calls are made:
  - treat_devices_added_or_updated
  - sg_agent.setup_port_filters
  - _bind_devices

  Before early November, process_network_ports called
  sg_agent.setup_port_filters before it called _bind_devices. This meant
  that security groups were programmed before traffic flow is enabled by
  _bind_devices, which sets the port-lvm mapping in br-int.

  Bug #1512636 reversed this order of operation, so that _bind_devices
  is called before sg_agent.setup_port_filters. This opens up a brief
  security hole, allowing traffic to flow for a short time before
  security groups are applied.

  Proposed solution:
  Revert bug# 1512636

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



From grant.murphy at hp.com  Mon Jan 18 15:10:24 2016
From: grant.murphy at hp.com (Grant Murphy)
Date: Mon, 18 Jan 2016 15:10:24 -0000
Subject: [Openstack-security] [Bug 1511541] Re: Possible incomplete fix for
	OSSA-2015-005
References: <20151029214642.13606.53636.malonedeb@wampee.canonical.com>
Message-ID: <20160118151024.14590.99516.malone@wampee.canonical.com>

@Tony do have any further input on this? I suspect that the header isn't
being sent for the localhost in the testing scenario but need to
confirm. Would like to move this bug along regardless.

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

Title:
  Possible incomplete fix for OSSA-2015-005

Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking
  Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete.

  https://bugs.launchpad.net/nova/+bug/1409142/comments/146
  https://bugs.launchpad.net/nova/+bug/1409142/comments/149

  Further investigation is needed.

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



From gerrit2 at review.openstack.org  Mon Jan 18 17:53:06 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 18 Jan 2016 17:53:06 +0000
Subject: [Openstack-security] [openstack/swift] SecurityImpact review
 request change I1f629987fbc8c59406432faad9cb2bfa34b5eccc
Message-ID: <E1aLDzG-0004st-NQ@review.openstack.org>


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

Log:
commit 0e4ee8d9a0ce658c90f675535b9acd9af2fd14b1
Author: janonymous <janonymous.codevulture at gmail.com>
Date:   Fri Sep 25 19:13:28 2015 +0530

    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.
    Allows closing idle client connections after a period of
    time.
    
    Comments in config files are based on their own keepalive default option
    set to true/false.
    
    eg:
    $ time nc localhost 8776/8080
    real 1m0.063s
    
    Added Parameters in Initial commit that needs to be changed as appropriate
    for swift configuration.
    
    DocImpact:
    Added keepalive option (default=False).
    
    SecurityImpact
    Closes-Bug: #1361360
    
    Change-Id: I1f629987fbc8c59406432faad9cb2bfa34b5eccc




From tony at bakeyournoodle.com  Mon Jan 18 18:23:06 2016
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Mon, 18 Jan 2016 18:23:06 -0000
Subject: [Openstack-security] [Bug 1511541] Re: Possible incomplete fix for
	OSSA-2015-005
References: <20151029214642.13606.53636.malonedeb@wampee.canonical.com>
Message-ID: <20160118182306.30033.9516.malone@chaenomeles.canonical.com>

So I have recreated this report and Yes the Origin Header is *not* being
sent.

we could enhance the code to look at the Referer header if the origin
Header is absent.

@Dave where did you see the Origin header being used?

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

Title:
  Possible incomplete fix for OSSA-2015-005

Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking
  Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete.

  https://bugs.launchpad.net/nova/+bug/1409142/comments/146
  https://bugs.launchpad.net/nova/+bug/1409142/comments/149

  Further investigation is needed.

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



From 1534658 at bugs.launchpad.net  Mon Jan 18 18:58:04 2016
From: 1534658 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 18 Jan 2016 18:58:04 -0000
Subject: [Openstack-security] [Bug 1534658] Re: [security] Don't initialize
	AIDE database by default
References: <20160115163011.28009.69253.malonedeb@gac.canonical.com>
Message-ID: <20160118185804.28765.90211.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/268222
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=99d1bc39acfa8fb9fe24c85456969a9e7fb73154
Submitter: Jenkins
Branch:    master

commit 99d1bc39acfa8fb9fe24c85456969a9e7fb73154
Author: Major Hayden <major at mhtx.net>
Date:   Fri Jan 15 10:30:43 2016 -0600

    Skip AIDE initialization by default
    
    The AIDE database initialization consumes a lot of CPU time and I/O resources.
    We shouldn't initialize the database by default, but this should be
    configurable by the deployer.
    
    Closes-bug: 1534658
    
    Change-Id: If680000619c35914e58ed8b7883c7eaa7928cec4


** Changed in: openstack-ansible
       Status: New => 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/1534658

Title:
  [security] Don't initialize AIDE database by default

Status in openstack-ansible:
  Fix Released

Bug description:
  The AIDE database initialization consumes a lot of CPU time and I/O
  resources. We shouldn't initialize the database by default, but this
  should be configurable by the deployer. This needs to be documented in
  the Ansible code and within the docs.

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



From tony at bakeyournoodle.com  Mon Jan 18 19:38:57 2016
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Mon, 18 Jan 2016 19:38:57 -0000
Subject: [Openstack-security] [Bug 1511541] Re: Possible incomplete fix for
	OSSA-2015-005
References: <20151029214642.13606.53636.malonedeb@wampee.canonical.com>
Message-ID: <20160118193857.25650.68567.malone@soybean.canonical.com>

Ahh okay I understand things a little better now, the Referer check
isn't something we can do in nova.  We'd need to do it in websockify.
I'll look at the original bug tomorrow.

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

Title:
  Possible incomplete fix for OSSA-2015-005

Status in OpenStack Compute (nova):
  New
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  Multiple reports that the fix for [OSSA 2015-005] Websocket Hijacking
  Vulnerability in Nova VNC Server (CVE-2015-0259) is incomplete.

  https://bugs.launchpad.net/nova/+bug/1409142/comments/146
  https://bugs.launchpad.net/nova/+bug/1409142/comments/149

  Further investigation is needed.

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



From 1534299 at bugs.launchpad.net  Mon Jan 18 23:19:16 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 18 Jan 2016 23:19:16 -0000
Subject: [Openstack-security] [Bug 1534299] Fix proposed to
	python-keystoneclient (stable/liberty)
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160118231916.30073.373.malone@chaenomeles.canonical.com>

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/269363

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  Fix Released

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From 1534299 at bugs.launchpad.net  Mon Jan 18 23:41:39 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 18 Jan 2016 23:41:39 -0000
Subject: [Openstack-security] [Bug 1534299] Fix proposed to
	python-keystoneclient (stable/kilo)
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160118234139.25928.17762.malone@soybean.canonical.com>

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

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  Fix Released

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From 1534299 at bugs.launchpad.net  Mon Jan 18 23:54:55 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 18 Jan 2016 23:54:55 -0000
Subject: [Openstack-security] [Bug 1534299] Fix proposed to keystoneauth
	(stable/liberty)
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160118235455.27976.38538.malone@gac.canonical.com>

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/269372

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  Fix Released

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From 1534299 at bugs.launchpad.net  Mon Jan 18 23:57:34 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 18 Jan 2016 23:57:34 -0000
Subject: [Openstack-security] [Bug 1534299] Change abandoned on
	python-keystoneclient (stable/kilo)
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160118235734.28540.84709.malone@gac.canonical.com>

Change abandoned by Brant Knudson (bknudson at us.ibm.com) on branch: stable/kilo
Review: https://review.openstack.org/269368
Reason: Doesn't conform to stable policy -- only critical patches.

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  Fix Released

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From stevemar at ca.ibm.com  Tue Jan 19 00:30:02 2016
From: stevemar at ca.ibm.com (Steve Martinelli)
Date: Tue, 19 Jan 2016 00:30:02 -0000
Subject: [Openstack-security] [Bug 1534299] Re: keystoneclient needs to mark
	secret config options
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160119003003.28765.18832.launchpad@gac.canonical.com>

** Changed in: python-keystoneclient
   Importance: Undecided => Medium

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

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  Fix Released

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From 1534322 at bugs.launchpad.net  Tue Jan 19 12:01:19 2016
From: 1534322 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 19 Jan 2016 12:01:19 -0000
Subject: [Openstack-security] [Bug 1534322] Re: On new port,
 traffic flow is allowed before security groups are programmed
References: <20160114214439.14625.28884.malonedeb@wampee.canonical.com>
Message-ID: <20160119120119.30236.77225.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/268194
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=ca193d023285e5b5b1b07a5f673a9864e75a2d8d
Submitter: Jenkins
Branch:    stable/liberty

commit ca193d023285e5b5b1b07a5f673a9864e75a2d8d
Author: Kevin Benton <kevinbenton at buttewifi.com>
Date:   Fri Jan 15 15:22:43 2016 +0000

    Revert "Change function call order in ovs_neutron_agent."
    
    This reverts commit c5629d59e3699cbee0adbbd3c4b296431294d307.
    
    Change-Id: Ie8779fae4210e71e8a0416ecd35b97fe35d4276e
    Closes-Bug: #1534322


** Tags added: in-stable-liberty

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

Title:
  On new port, traffic flow is allowed before security groups are
  programmed

Status in neutron:
  Fix Released
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.

  --

  Description:
  During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed.

  File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
  Funtion: process_network_ports

  Step-by-step:
  During the creation of a neutron port, the following calls are made:
  - treat_devices_added_or_updated
  - sg_agent.setup_port_filters
  - _bind_devices

  Before early November, process_network_ports called
  sg_agent.setup_port_filters before it called _bind_devices. This meant
  that security groups were programmed before traffic flow is enabled by
  _bind_devices, which sets the port-lvm mapping in br-int.

  Bug #1512636 reversed this order of operation, so that _bind_devices
  is called before sg_agent.setup_port_filters. This opens up a brief
  security hole, allowing traffic to flow for a short time before
  security groups are applied.

  Proposed solution:
  Revert bug# 1512636

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



From tdecacqu at redhat.com  Tue Jan 19 16:40:33 2016
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Tue, 19 Jan 2016 16:40:33 -0000
Subject: [Openstack-security] [Bug 1534288] Re: keystoneclient should not be
	using pickle
References: <20160114195928.28540.47395.malonedeb@gac.canonical.com>
Message-ID: <20160119164033.28044.29248.malone@gac.canonical.com>

I've removed the privacy settings and put the OSSA tasks as Won't Fix
based on above comments. This can be put back to incomplete if the
situation changes.

** 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.
- 
- --
- 
  keystoneclient uses pickle to pull the keystoneclient_auth value out of
  the keyring. pickle is not safe to use since it can run commands as the
  user. I guess someone could use this to run some code as the nova user
  by putting something into the keystoneclient_auth value in the nova
  user's keyring and then getting nova to use keystoneclient.httpclient.
  
  There's probably a safer way to do serialize the auth info using JSON or
  some other format.
  
  Opening this as private security since there's a potential attack here
  although I don't have any proof.
  
  This was found using bandit 0.17.0.

** Tags added: security

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

** Information type changed from Private Security to Public

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

Title:
  keystoneclient should not be using pickle

Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  New

Bug description:
  keystoneclient uses pickle to pull the keystoneclient_auth value out
  of the keyring. pickle is not safe to use since it can run commands as
  the user. I guess someone could use this to run some code as the nova
  user by putting something into the keystoneclient_auth value in the
  nova user's keyring and then getting nova to use
  keystoneclient.httpclient.

  There's probably a safer way to do serialize the auth info using JSON
  or some other format.

  Opening this as private security since there's a potential attack here
  although I don't have any proof.

  This was found using bandit 0.17.0.

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



From morgan.fainberg at gmail.com  Tue Jan 19 16:39:54 2016
From: morgan.fainberg at gmail.com (Morgan Fainberg)
Date: Tue, 19 Jan 2016 16:39:54 -0000
Subject: [Openstack-security] [Bug 1435530] Re: keystonemiddleware without
 TRL checking and default cache config can allow access after token
 revocation
References: <20150323201925.7521.48815.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160119163956.29540.70181.launchpad@chaenomeles.canonical.com>

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

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

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

Title:
  keystonemiddleware without TRL checking and default cache config can
  allow access after token revocation

Status in keystonemiddleware:
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  *** This can probably be made public right away, but I am erring on
  the side of caution and letting the VMT make this call ***

  Yukihiro KAWADA reported an issue with Keystone that indirectly
  led/confirmed an issue with Keystonemiddleware when the Token
  Revocation List (TRL) is not utilized and caching is enabled
  (default). If the TRL is not used (common with UUID tokens, as PKI
  signing is not setup), a token that is used on an endpoint is valid
  for 300s (default, may be more/less based on config) even if the token
  is revoked within keystone (this include disabling of the user).

  Worse, the default is is to cache the tokens in-process memory, which
  means that the token may appear to be revoked/invalid in some cases
  and then become re-valid on subsequent requests unless a shared cache
  is used.

  This appears to be insane default(s) that lead to a window of exposure
  that is not clearly communicated either with defaults or when caching
  times are adjusted.

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



From tdecacqu at redhat.com  Tue Jan 19 16:45:26 2016
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Tue, 19 Jan 2016 16:45:26 -0000
Subject: [Openstack-security] [Bug 1534284] Re: keystoneclient should not
	use etree XML parsing
References: <20160114194930.29365.34205.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160119164526.26266.4745.malone@soybean.canonical.com>

I've removed the privacy settings and put the OSSA task as Won't Fix
based on above comments. This can be put back to incomplete if the
situation changes.

** 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.
- 
- --
- 
  XML parsing is surprisingly difficult and fraught with danger, for
  example entity expansion makes it easy to cause a lot of memory to be
  used and therefore crash your system. keystoneclient is using etree
  parsing which has these potential issues, although in the case of
  keystoneclient it's the response from the IdP which I think is generally
  trusted.
  
  This is in python-keystoneclient/keystoneclient/contrib/auth/v3/saml2.py
  
  There's a defusedxml parser that has protections against these attacks
  and should therefore be used instead if possible -
  https://pypi.python.org/pypi/defusedxml - the docs for this page also
  include some examples of other possible attacks.
  
  This was caught by bandit 0.17.0.
  
  I'm going to start this out as private security so we can think about it
  some more before it goes public, even though it's probably not something
  that needs an issue since I think the source is generally trusted. If
  you can't trust your IdP then who can you trust?

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

** Information type changed from Private Security to Public

** Tags added: security

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

Title:
  keystoneclient should not use etree XML parsing

Status in keystoneauth:
  New
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  New

Bug description:
  XML parsing is surprisingly difficult and fraught with danger, for
  example entity expansion makes it easy to cause a lot of memory to be
  used and therefore crash your system. keystoneclient is using etree
  parsing which has these potential issues, although in the case of
  keystoneclient it's the response from the IdP which I think is
  generally trusted.

  This is in python-
  keystoneclient/keystoneclient/contrib/auth/v3/saml2.py

  There's a defusedxml parser that has protections against these attacks
  and should therefore be used instead if possible -
  https://pypi.python.org/pypi/defusedxml - the docs for this page also
  include some examples of other possible attacks.

  This was caught by bandit 0.17.0.

  I'm going to start this out as private security so we can think about
  it some more before it goes public, even though it's probably not
  something that needs an issue since I think the source is generally
  trusted. If you can't trust your IdP then who can you trust?

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



From thierry.carrez+lp at gmail.com  Tue Jan 19 16:57:59 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Tue, 19 Jan 2016 16:57:59 -0000
Subject: [Openstack-security] [Bug 1534322] Fix included in
	openstack/neutron 8.0.0.0b2
References: <20160114214439.14625.28884.malonedeb@wampee.canonical.com>
Message-ID: <20160119165759.26384.35228.malone@soybean.canonical.com>

This issue was fixed in the openstack/neutron 8.0.0.0b2 development
milestone.

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

Title:
  On new port, traffic flow is allowed before security groups are
  programmed

Status in neutron:
  Fix Released
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.

  --

  Description:
  During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed.

  File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
  Funtion: process_network_ports

  Step-by-step:
  During the creation of a neutron port, the following calls are made:
  - treat_devices_added_or_updated
  - sg_agent.setup_port_filters
  - _bind_devices

  Before early November, process_network_ports called
  sg_agent.setup_port_filters before it called _bind_devices. This meant
  that security groups were programmed before traffic flow is enabled by
  _bind_devices, which sets the port-lvm mapping in br-int.

  Bug #1512636 reversed this order of operation, so that _bind_devices
  is called before sg_agent.setup_port_filters. This opens up a brief
  security hole, allowing traffic to flow for a short time before
  security groups are applied.

  Proposed solution:
  Revert bug# 1512636

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



From thierry.carrez+lp at gmail.com  Wed Jan 20 10:47:48 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 20 Jan 2016 10:47:48 -0000
Subject: [Openstack-security] [Bug 1533065] Fix included in openstack/heat
	6.0.0.0b2
References: <20160112054500.16030.6854.malonedeb@gac.canonical.com>
Message-ID: <20160120104749.29505.32840.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/heat 6.0.0.0b2 development
milestone.

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

Title:
  stack_create 500 Error with non-string stack_name

Status in heat:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  When sending a stack create request using the REST API through curl
  with the stack_name parameter set to either a list, or a dictionary a
  Server Error occurs.

  The major problem with this is that when this occurs the response of
  the request will show what database backend the cloud is utilising
  whether it be MySQL, or PostgreSQL. This information could be used by
  a malicious user to exploit the databases. Additionally to the
  database engine being known, the query itself is also printed in the
  response.

  This occurs regardless of the level of logging being set for the heat
  service.

  This has been seen in the master branch as of 12/01/2016.

  I have attached the response of a request with a Traceback.

  The data being sent is the following:
  {
      "files": {},
      "disable_rollback": true,
      "parameters": {
          "flavor": "m1.tiny"
      },
      "stack_name": {"test": "sample"},
      "template": {
          "heat_template_version": "2013-05-23",
          "description": "Simple template to test heat commands",
          "parameters": {
              "flavor": {
                  "default": "m1.tiny",
                  "type": "string"
              }
          },
          "resources": {
              "hello_world": {
                  "type": "OS::Nova::Server",
                  "properties": {
                      "key_name": "heat_key",
                      "flavor": {
                          "get_param": "flavor"
                      },
                      "image": "40be8d1a-3eb9-40de-8abd-43237517384f",
                      "user_data": "#!/bin/bash -xv\necho \"hello world\" &gt; /root/hello-world.txt\n"
                  }
              }
          }
      },
      "timeout_mins": 60
  }

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



From doug at doughellmann.com  Wed Jan 20 16:22:52 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Wed, 20 Jan 2016 16:22:52 -0000
Subject: [Openstack-security] [Bug 1533065] Fix included in openstack/heat
	6.0.0.0b2
References: <20160112054500.16030.6854.malonedeb@gac.canonical.com>
Message-ID: <20160120162252.30113.95344.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/heat 6.0.0.0b2 development
milestone.

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

Title:
  stack_create 500 Error with non-string stack_name

Status in heat:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  When sending a stack create request using the REST API through curl
  with the stack_name parameter set to either a list, or a dictionary a
  Server Error occurs.

  The major problem with this is that when this occurs the response of
  the request will show what database backend the cloud is utilising
  whether it be MySQL, or PostgreSQL. This information could be used by
  a malicious user to exploit the databases. Additionally to the
  database engine being known, the query itself is also printed in the
  response.

  This occurs regardless of the level of logging being set for the heat
  service.

  This has been seen in the master branch as of 12/01/2016.

  I have attached the response of a request with a Traceback.

  The data being sent is the following:
  {
      "files": {},
      "disable_rollback": true,
      "parameters": {
          "flavor": "m1.tiny"
      },
      "stack_name": {"test": "sample"},
      "template": {
          "heat_template_version": "2013-05-23",
          "description": "Simple template to test heat commands",
          "parameters": {
              "flavor": {
                  "default": "m1.tiny",
                  "type": "string"
              }
          },
          "resources": {
              "hello_world": {
                  "type": "OS::Nova::Server",
                  "properties": {
                      "key_name": "heat_key",
                      "flavor": {
                          "get_param": "flavor"
                      },
                      "image": "40be8d1a-3eb9-40de-8abd-43237517384f",
                      "user_data": "#!/bin/bash -xv\necho \"hello world\" &gt; /root/hello-world.txt\n"
                  }
              }
          }
      },
      "timeout_mins": 60
  }

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



From major at mhtx.net  Wed Jan 20 18:46:04 2016
From: major at mhtx.net (Major Hayden)
Date: Wed, 20 Jan 2016 18:46:04 -0000
Subject: [Openstack-security] [Bug 1536325] [NEW] [security] Auditd chmod
	rules causing high load
Message-ID: <20160120184604.29686.85751.malonedeb@chaenomeles.canonical.com>

Public bug reported:

The auditd rules that monitor filesystem permission changes are causing
high loads during OpenStack-Ansible deployments. They should be disabled
by default and the exception needs to be documented.

** Affects: openstack-ansible
     Importance: Undecided
     Assignee: Major Hayden (rackerhacker)
         Status: New


** Tags: security

** Changed in: openstack-ansible
     Assignee: (unassigned) => Major Hayden (rackerhacker)

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

Title:
  [security] Auditd chmod rules causing high load

Status in openstack-ansible:
  New

Bug description:
  The auditd rules that monitor filesystem permission changes are
  causing high loads during OpenStack-Ansible deployments. They should
  be disabled by default and the exception needs to be documented.

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



From 1534322 at bugs.launchpad.net  Wed Jan 20 18:52:32 2016
From: 1534322 at bugs.launchpad.net (Armando Migliaccio)
Date: Wed, 20 Jan 2016 18:52:32 -0000
Subject: [Openstack-security] [Bug 1534322] Re: On new port,
 traffic flow is allowed before security groups are programmed
References: <20160114214439.14625.28884.malonedeb@wampee.canonical.com>
Message-ID: <20160120185234.29871.99041.launchpad@chaenomeles.canonical.com>

** Changed in: neutron
    Milestone: mitaka-3 => mitaka-2

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

Title:
  On new port, traffic flow is allowed before security groups are
  programmed

Status in neutron:
  Fix Released
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.

  --

  Description:
  During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed.

  File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
  Funtion: process_network_ports

  Step-by-step:
  During the creation of a neutron port, the following calls are made:
  - treat_devices_added_or_updated
  - sg_agent.setup_port_filters
  - _bind_devices

  Before early November, process_network_ports called
  sg_agent.setup_port_filters before it called _bind_devices. This meant
  that security groups were programmed before traffic flow is enabled by
  _bind_devices, which sets the port-lvm mapping in br-int.

  Bug #1512636 reversed this order of operation, so that _bind_devices
  is called before sg_agent.setup_port_filters. This opens up a brief
  security hole, allowing traffic to flow for a short time before
  security groups are applied.

  Proposed solution:
  Revert bug# 1512636

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



From 1536325 at bugs.launchpad.net  Wed Jan 20 18:55:56 2016
From: 1536325 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 20 Jan 2016 18:55:56 -0000
Subject: [Openstack-security] [Bug 1536325] Re: [security] Auditd chmod
	rules causing high load
References: <20160120184604.29686.85751.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160120185556.28765.62691.malone@gac.canonical.com>

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

** Changed in: openstack-ansible
       Status: New => 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/1536325

Title:
  [security] Auditd chmod rules causing high load

Status in openstack-ansible:
  In Progress

Bug description:
  The auditd rules that monitor filesystem permission changes are
  causing high loads during OpenStack-Ansible deployments. They should
  be disabled by default and the exception needs to be documented.

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



From gerrit2 at review.openstack.org  Thu Jan 21 08:49:58 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Jan 2016 08:49:58 +0000
Subject: [Openstack-security] [openstack/glance] SecurityImpact review
 request change I5a6f587086e926a1f7e9b3f1dac9d7e10710d72a
Message-ID: <E1aMAwI-0005oP-DD@review.openstack.org>


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

Log:
commit f07f36fa3789a4997b84639530e5d6ab1c603983
Author: kairat_kushaev <kkushaev at mirantis.com>
Date:   Mon Oct 12 15:56:58 2015 +0300

    Allow image-list if access to attrs is forbidden
    
    If access to some attributes is forbidden (f.e. get_image_location
    policy is set to role:admin and user is not admin) glance should
    just exclude these attributes from image-show, image-list output
    instead of generating Forbidden exception.
    Otherwise, the policies such as get_image_location is not useful.
    
    APIImpact
    SecurityImpact
    Change-Id: I5a6f587086e926a1f7e9b3f1dac9d7e10710d72a
    Closes-bug: #1502136




From thierry.carrez+lp at gmail.com  Thu Jan 21 13:06:33 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 21 Jan 2016 13:06:33 -0000
Subject: [Openstack-security] [Bug 1431944] Fix included in openstack/sahara
	4.0.0.0b2
References: <20150313161221.24854.14570.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160121130633.28540.9568.malone@gac.canonical.com>

This issue was fixed in the openstack/sahara 4.0.0.0b2 development
milestone.

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

Title:
  Swift passwords should use key manager interface

Status in Sahara:
  Fix Released

Bug description:
  Swift passwords are currently stored in the default database. This
  behavior should be migrated to the key manager interface to allow for
  storage in an external manager (when enabled).

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



From thierry.carrez+lp at gmail.com  Thu Jan 21 13:30:24 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 21 Jan 2016 13:30:24 -0000
Subject: [Openstack-security] [Bug 1514569] Fix included in openstack/trove
	5.0.0.0b2
References: <20151109195235.21620.71031.malonedeb@soybean.canonical.com>
Message-ID: <20160121133024.14662.44234.malone@wampee.canonical.com>

This issue was fixed in the openstack/trove 5.0.0.0b2 development
milestone.

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

Title:
  Fix Postgres root-enable

Status in Trove:
  Fix Committed

Bug description:
  Fix PostgreSQL root functions

  The default PostgreSQL administration account is 'postgres'.

  In the current implementation Trove uses the 'postgres' account and
  return a new superuser called 'root' when the root access is requested.
  The user 'root' has however no special meaning in PostgreSQL and the
  existing applications may rely on the default superuser name 'postgres'.

  Trove should be using its own administrative account (os_admin)
  instead.

  Notes:

   The current implementation is broken for variaous reasons:

   - It uses UUIDs in place of 'secure' password.
   - It creates a 'root' user, but no database for it.
     The clients won't be able to authenticate without explicitly
     providing an existing database name.
   - The created 'root' user has no 'SUPERUSER' attribute and
     hence is not a real superuser (cannot perform certain tasks)...
   - The implementation suffers a defect that allows a non-root user
     gain root access to an instance without marking is as 'root-enabled'
     A similar defect exists in other datastores (MySQL) too:

   1. Create an instance.
   2. Enable root.
   3. Use your root access to change the password of the built-in
  'postgres' account (Trove will still work because it uses the
  'peer' authentication method - the UNIX account).
   4. Login as 'postgres' using the changed password and drop the
  created 'root' account.
   5. Backup & restore the instance.
   6. Trove reports the root has never been enabled (it checks for existence of
  superuser accounts other than the built-in 'postgres').
   7. You enjoy the root access of the 'postgres' user
  (the password is not reset on restore).

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



From thierry.carrez+lp at gmail.com  Thu Jan 21 13:26:56 2016
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 21 Jan 2016 13:26:56 -0000
Subject: [Openstack-security] [Bug 1479523] Fix included in
	openstack/keystone 9.0.0.0b2
References: <20150729211446.8945.2269.malonedeb@gac.canonical.com>
Message-ID: <20160121132656.29910.95474.malone@chaenomeles.canonical.com>

This issue was fixed in the openstack/keystone 9.0.0.0b2 development
milestone.

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

Title:
  Stop using debug for insecure responses

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  
  If you set debug=true in keystone.conf the server 1) logs at debug level, and 2) sends out insecure responses. Deployers might think that debug=true only does 1, not knowing about 2 since it's not documented in the sample config. The behaviors should be decoupled to improve security a bit.

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



From gerrit2 at review.openstack.org  Thu Jan 21 17:50:31 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Jan 2016 17:50:31 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1aMJNP-00020P-Ld@review.openstack.org>


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

Log:
commit 0e74c4a3d271e95de7fb9ed4c8c36e29389bf12c
Author: Solly Ross <sross at redhat.com>
Date:   Tue Aug 19 18:48:00 2014 -0400

    Introduce VNC Security Proxy Framework
    
    This commit introduces the security proxying framework for
    VNC.  Which class is being used to do the security proxying
    can be set on a per-traffic-type basis by pointing
    the appropriate configuration option to an appropriate
    subclass.
    
    Currently, only VNC is supported, via the configuration
    option 'novncproxy_security_driver'.
    
    The workflow for adding a new VNC security proxy driver is
    to subclass the traffic-type-specific security proxy
    base classes (e.g. RFBSecurityProxyHelper), and implement
    the `choose_security_type` and `security_handshake` methods.
    
    DocImpact
    SecurityImpact
    Implements bp: websocket-proxy-to-host-security
    
    Change-Id: Id586b2558fd4c7ed0eda3d3555d51fcd019eb414




From gerrit2 at review.openstack.org  Thu Jan 21 17:50:40 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 21 Jan 2016 17:50:40 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1aMJNY-00021z-2u@review.openstack.org>


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

Log:
commit 2ef5a20cea01e4a48ddae9422e6393cab7b8ec31
Author: Solly Ross <sross at redhat.com>
Date:   Tue Aug 19 19:21:52 2014 -0400

    Add VeNCrypt (TLS/x509) Security Proxy Driver
    
    This adds support for using x509/TLS security
    between the compute node and websocket proxy when
    using websockify to proxy VNC traffic.
    
    In order to use this with x509, an operator would
    have to set up client keys and certificates, as
    well as CA certificates, and configure libvirt
    to pass the appropriate options to QEmu (this
    is configured globally for libvirt, not by Nova).
    This process is documented on the libvirt
    website.
    
    Then, the operator would enable this driver and
    set the following options in /etc/nova/nova.conf:
    
       [console_proxy_tls]
       client_key = /path/to/client/keyfile
       client_cert = /path/to/client/cert.pem
       ca_certs = /path/to/ca/cert.pem
    
    SecurityImpact
    DocImpact
    Implements bp: websocket-proxy-to-host-security
    
    Change-Id: I64859ad01120782fb17308aac3abb125597c3ea2




From email at daviey.com  Thu Jan 21 20:23:18 2016
From: email at daviey.com (Dave Walker)
Date: Thu, 21 Jan 2016 20:23:18 -0000
Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not
 released back to the pool leading to choking of new requests
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20160121202326.9602.45460.launchpad@wampee.canonical.com>

** Changed in: heat/kilo
       Status: Fix Released => Fix Committed

** Changed in: heat/kilo
    Milestone: None => 2015.1.3

-- 
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 Glance juno series:
  Fix Released
Status in heat:
  Fix Released
Status in heat kilo series:
  Fix Committed
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) juno series:
  Fix Released
Status in OpenStack Identity (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:
  Won't Fix
Status in Sahara:
  Fix Released

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 email at daviey.com  Thu Jan 21 20:27:27 2016
From: email at daviey.com (Dave Walker)
Date: Thu, 21 Jan 2016 20:27:27 -0000
Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user
 attribute in k2k assertions with different domains
References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com>
Message-ID: <20160121202730.29256.88871.launchpad@soybean.canonical.com>

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

** Changed in: keystone/kilo
    Milestone: 2015.1.2 => 2015.1.3

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

Title:
  Mapping openstack_user attribute in k2k assertions with different
  domains

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Fix Committed

Bug description:
  We can have two users with the same username in different domains. So
  if we have a "User A" in "Domain X" and a "User A" in "Domain Y",
  there is no way to differ what "User A" is being used in a SAML
  assertion generated by this IdP (we have only the openstack_user
  attribute in the SAML assertion).

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



From 1163569 at bugs.launchpad.net  Thu Jan 21 21:57:22 2016
From: 1163569 at bugs.launchpad.net (Cedric Brandily)
Date: Thu, 21 Jan 2016 21:57:22 -0000
Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work
 with LBaaS vip and ovs plugin
References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com>
Message-ID: <20160121215725.9564.76141.launchpad@wampee.canonical.com>

** Changed in: neutron
     Assignee: Doug Wiegley (dougwig) => (unassigned)

-- 
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 LBaaS vip and ovs plugin

Status in neutron:
  Confirmed
Status in OpenStack Security Notes:
  Won't Fix

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 email at daviey.com  Thu Jan 21 23:13:56 2016
From: email at daviey.com (Dave Walker)
Date: Thu, 21 Jan 2016 23:13:56 -0000
Subject: [Openstack-security] [Bug 1361360] Re: Eventlet green threads not
 released back to the pool leading to choking of new requests
References: <20140825203231.13086.48412.malonedeb@wampee.canonical.com>
Message-ID: <20160121231401.11783.61399.launchpad@chaenomeles.canonical.com>

** Changed in: heat/kilo
       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/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 Glance juno series:
  Fix Released
Status in heat:
  Fix Released
Status in heat kilo series:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) juno series:
  Fix Released
Status in OpenStack Identity (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:
  Won't Fix
Status in Sahara:
  Fix Released

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 email at daviey.com  Thu Jan 21 23:16:44 2016
From: email at daviey.com (Dave Walker)
Date: Thu, 21 Jan 2016 23:16:44 -0000
Subject: [Openstack-security] [Bug 1442787] Re: Mapping openstack_user
 attribute in k2k assertions with different domains
References: <20150410195742.13839.10394.malonedeb@wampee.canonical.com>
Message-ID: <20160121231646.9488.84649.launchpad@wampee.canonical.com>

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

Title:
  Mapping openstack_user attribute in k2k assertions with different
  domains

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) kilo series:
  Fix Released

Bug description:
  We can have two users with the same username in different domains. So
  if we have a "User A" in "Domain X" and a "User A" in "Domain Y",
  there is no way to differ what "User A" is being used in a SAML
  assertion generated by this IdP (we have only the openstack_user
  attribute in the SAML assertion).

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



From gerrit2 at review.openstack.org  Fri Jan 22 14:00:35 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 22 Jan 2016 14:00:35 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1aMcGR-0005Ub-HD@review.openstack.org>


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

Log:
commit f3973b97fefb0a8bd3fea61544992f0c35889571
Author: Solly Ross <sross at redhat.com>
Date:   Tue Aug 19 18:48:00 2014 -0400

    Introduce VNC Security Proxy Framework
    
    This commit introduces the security proxying framework for
    VNC.  Which class is being used to do the security proxying
    can be set on a per-traffic-type basis by pointing
    the appropriate configuration option to an appropriate
    subclass.
    
    Currently, only VNC is supported, via the configuration
    option 'novncproxy_security_driver'.
    
    The workflow for adding a new VNC security proxy driver is
    to subclass the traffic-type-specific security proxy
    base classes (e.g. RFBSecurityProxyHelper), and implement
    the `choose_security_type` and `security_handshake` methods.
    
    DocImpact
    SecurityImpact
    Implements bp: websocket-proxy-to-host-security
    
    Change-Id: Id586b2558fd4c7ed0eda3d3555d51fcd019eb414




From gerrit2 at review.openstack.org  Fri Jan 22 14:00:42 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 22 Jan 2016 14:00:42 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1aMcGY-0005W2-7Y@review.openstack.org>


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

Log:
commit a4e23fbd881054ccafccb7e51200f5fb3ffbe13d
Author: Solly Ross <sross at redhat.com>
Date:   Tue Aug 19 19:21:52 2014 -0400

    Add VeNCrypt (TLS/x509) Security Proxy Driver
    
    This adds support for using x509/TLS security
    between the compute node and websocket proxy when
    using websockify to proxy VNC traffic.
    
    In order to use this with x509, an operator would
    have to set up client keys and certificates, as
    well as CA certificates, and configure libvirt
    to pass the appropriate options to QEmu (this
    is configured globally for libvirt, not by Nova).
    This process is documented on the libvirt
    website.
    
    Then, the operator would enable this driver and
    set the following options in /etc/nova/nova.conf:
    
       [console_proxy_tls]
       client_key = /path/to/client/keyfile
       client_cert = /path/to/client/cert.pem
       ca_certs = /path/to/ca/cert.pem
    
    SecurityImpact
    DocImpact
    Implements bp: websocket-proxy-to-host-security
    
    Change-Id: I64859ad01120782fb17308aac3abb125597c3ea2




From tdecacqu at redhat.com  Fri Jan 22 19:39:38 2016
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Fri, 22 Jan 2016 19:39:38 -0000
Subject: [Openstack-security] [Bug 1537175] Re: /info for Swift clusters
	includes Swift version
References: <20160122191108.9488.29502.malonedeb@wampee.canonical.com>
Message-ID: <20160122193938.11389.60900.malone@chaenomeles.canonical.com>

I removed the privacy settings based on above comments.

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

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

** Information type changed from Private Security to Public

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

Title:
  /info for Swift clusters includes Swift version

Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Object Storage (swift):
  Invalid

Bug description:
  If querying /info on a Swift cluster, like
  https://swift.example.com/info, it will return the Swift version it
  runs.

  Example: "version": "2.5.0.2.1"

  This is a security risk, especially for Internet-facing clusters. In
  light of the recent CVEs (released on or around 2016-01-21), any
  Internet-facing cluster not yet patched with the fixes, can be easily
  queried for its version and the vulnerabilities can be readily taken
  advantage of. Hence, /info should probably not include the running
  Swift version.

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



From david.comay at oracle.com  Mon Jan 25 02:04:01 2016
From: david.comay at oracle.com (David Comay)
Date: Mon, 25 Jan 2016 02:04:01 -0000
Subject: [Openstack-security] [Bug 1493448] Re: All operations are perfomed
 with admin priveleges when 'use_user_token' is False
References: <20150908163321.8816.82829.malonedeb@wampee.canonical.com>
Message-ID: <20160125020402.11647.67514.malone@chaenomeles.canonical.com>

Is there a schedule for this OSSN to be published?

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

Title:
  All operations are perfomed with admin priveleges when
  'use_user_token' is False

Status in Glance:
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  In glance-api.conf we have a param called 'use_user_token' which is
  enabled by default. It was introduced to allow for reauthentication
  when tokens expire and prevents requests from silently failing.
  https://review.openstack.org/#/c/29967/

  Unfortunately disabling this parameter leads to security issues and
  allows a regular user to perform any operation with admin rights.

  Steps to reproduce on devstack:
  1. Change /etc/glance/glance-api.conf parameters and restart glance-api:
  # Pass the user's token through for API requests to the registry.
  # Default: True
  use_user_token = False

  # If 'use_user_token' is not in effect then admin credentials
  # can be specified. Requests to the registry on behalf of
  # the API will use these credentials.
  # Admin user name
  admin_user = glance
  # Admin password
  admin_password = nova
  # Admin tenant name
  admin_tenant_name = service
  # Keystone endpoint
  auth_url = http://127.0.0.1:5000/v2.0

  (for v2 api it's required to enable registry service, too: data_api =
  glance.db.registry.api)

  2. Create a private image with admin user:
  source openrc admin admin
  glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab
  +------------------+--------------------------------------+
  | Property         | Value                                |
  +------------------+--------------------------------------+
  | checksum         | e533283e6aac072533d1d091a7d2e413     |
  | container_format | bare                                 |
  | created_at       | 2015-09-01T22:17:25.000000           |
  | deleted          | False                                |
  | deleted_at       | None                                 |
  | disk_format      | qcow2                                |
  | id               | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 |
  | is_public        | False                                |
  | min_disk         | 0                                    |
  | min_ram          | 0                                    |
  | name             | private                              |
  | owner            | e1cec705e33b4dfaaece11b623f3c680     |
  | protected        | False                                |
  | size             | 616                                  |
  | status           | active                               |
  | updated_at       | 2015-09-01T22:17:27.000000           |
  | virtual_size     | None                                 |
  +------------------+--------------------------------------+

  3. Check the image list with admin user:
  glance --os-image-api-version 1 image-list
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | ID                                   | Name                            | Disk Format | Container Format | Size     | Status |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec         | ami         | ami              | 25165824 | active |
  | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel  | aki         | aki              | 4979632  | active |
  | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari         | ari              | 3740163  | active |
  | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private                         | qcow2       | bare             | 616      | active |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+

  4. Enable demo user and get the image list:
  source openrc demo demo
  glance --os-image-api-version 1 image-list
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | ID                                   | Name                            | Disk Format | Container Format | Size     | Status |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec         | ami         | ami              | 25165824 | active |
  | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel  | aki         | aki              | 4979632  | active |
  | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari         | ari              | 3740163  | active |
  | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private                         | qcow2       | bare             | 616      | active |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+

  5. Try to get access to admin's private image with demo user:

  glance --os-image-api-version 1 image-show private
  +------------------+--------------------------------------+
  | Property         | Value                                |
  +------------------+--------------------------------------+
  | checksum         | e533283e6aac072533d1d091a7d2e413     |
  | container_format | bare                                 |
  | created_at       | 2015-09-01T22:17:25.000000           |
  | deleted          | False                                |
  | disk_format      | qcow2                                |
  | id               | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 |
  | is_public        | False                                |
  | min_disk         | 0                                    |
  | min_ram          | 0                                    |
  | name             | private                              |
  | owner            | e1cec705e33b4dfaaece11b623f3c680     |
  | protected        | False                                |
  | size             | 616                                  |
  | status           | active                               |
  | updated_at       | 2015-09-01T22:17:27.000000           |
  +------------------+--------------------------------------+

  The same happens when demo user wants to create/update/delete any
  image. v2 with enabled registry backend is affected too.

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



From 1536325 at bugs.launchpad.net  Mon Jan 25 13:38:18 2016
From: 1536325 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 25 Jan 2016 13:38:18 -0000
Subject: [Openstack-security] [Bug 1536325] Re: [security] Auditd chmod
	rules causing high load
References: <20160120184604.29686.85751.malonedeb@chaenomeles.canonical.com>
Message-ID: <20160125133818.11571.71768.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/270421
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible-security/commit/?id=83cf2701eb5274a008e81afd6bddc4ec4dc5f9d8
Submitter: Jenkins
Branch:    master

commit 83cf2701eb5274a008e81afd6bddc4ec4dc5f9d8
Author: Major Hayden <major at mhtx.net>
Date:   Wed Jan 20 12:54:57 2016 -0600

    Disable chmod auditd rules
    
    These rules can cause high load during periods of large changes
    on a system.
    
    Closes-bug: 1536325
    
    Change-Id: Ic088586c3059fd0dbef06a38f2478c14e7f88702


** Changed in: openstack-ansible
       Status: In Progress => 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/1536325

Title:
  [security] Auditd chmod rules causing high load

Status in openstack-ansible:
  Fix Released

Bug description:
  The auditd rules that monitor filesystem permission changes are
  causing high loads during OpenStack-Ansible deployments. They should
  be disabled by default and the exception needs to be documented.

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



From 1493448 at bugs.launchpad.net  Mon Jan 25 16:34:29 2016
From: 1493448 at bugs.launchpad.net (Robert Clark)
Date: Mon, 25 Jan 2016 16:34:29 -0000
Subject: [Openstack-security] [Bug 1493448] Re: All operations are perfomed
 with admin priveleges when 'use_user_token' is False
References: <20150908163321.8816.82829.malonedeb@wampee.canonical.com>
Message-ID: <20160125163429.30645.99359.malone@gac.canonical.com>

Somehow it slipped through the net - the embargo'd one went out on time
but the public one didn't.

It's just gone through review and is merging now:
https://review.openstack.org/#/c/272151

We've also published it on the wiki, as per our process. Travis should
be sending the email out in the next few minutes.

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

Title:
  All operations are perfomed with admin priveleges when
  'use_user_token' is False

Status in Glance:
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  New

Bug description:
  In glance-api.conf we have a param called 'use_user_token' which is
  enabled by default. It was introduced to allow for reauthentication
  when tokens expire and prevents requests from silently failing.
  https://review.openstack.org/#/c/29967/

  Unfortunately disabling this parameter leads to security issues and
  allows a regular user to perform any operation with admin rights.

  Steps to reproduce on devstack:
  1. Change /etc/glance/glance-api.conf parameters and restart glance-api:
  # Pass the user's token through for API requests to the registry.
  # Default: True
  use_user_token = False

  # If 'use_user_token' is not in effect then admin credentials
  # can be specified. Requests to the registry on behalf of
  # the API will use these credentials.
  # Admin user name
  admin_user = glance
  # Admin password
  admin_password = nova
  # Admin tenant name
  admin_tenant_name = service
  # Keystone endpoint
  auth_url = http://127.0.0.1:5000/v2.0

  (for v2 api it's required to enable registry service, too: data_api =
  glance.db.registry.api)

  2. Create a private image with admin user:
  source openrc admin admin
  glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab
  +------------------+--------------------------------------+
  | Property         | Value                                |
  +------------------+--------------------------------------+
  | checksum         | e533283e6aac072533d1d091a7d2e413     |
  | container_format | bare                                 |
  | created_at       | 2015-09-01T22:17:25.000000           |
  | deleted          | False                                |
  | deleted_at       | None                                 |
  | disk_format      | qcow2                                |
  | id               | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 |
  | is_public        | False                                |
  | min_disk         | 0                                    |
  | min_ram          | 0                                    |
  | name             | private                              |
  | owner            | e1cec705e33b4dfaaece11b623f3c680     |
  | protected        | False                                |
  | size             | 616                                  |
  | status           | active                               |
  | updated_at       | 2015-09-01T22:17:27.000000           |
  | virtual_size     | None                                 |
  +------------------+--------------------------------------+

  3. Check the image list with admin user:
  glance --os-image-api-version 1 image-list
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | ID                                   | Name                            | Disk Format | Container Format | Size     | Status |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec         | ami         | ami              | 25165824 | active |
  | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel  | aki         | aki              | 4979632  | active |
  | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari         | ari              | 3740163  | active |
  | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private                         | qcow2       | bare             | 616      | active |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+

  4. Enable demo user and get the image list:
  source openrc demo demo
  glance --os-image-api-version 1 image-list
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | ID                                   | Name                            | Disk Format | Container Format | Size     | Status |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec         | ami         | ami              | 25165824 | active |
  | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel  | aki         | aki              | 4979632  | active |
  | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari         | ari              | 3740163  | active |
  | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private                         | qcow2       | bare             | 616      | active |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+

  5. Try to get access to admin's private image with demo user:

  glance --os-image-api-version 1 image-show private
  +------------------+--------------------------------------+
  | Property         | Value                                |
  +------------------+--------------------------------------+
  | checksum         | e533283e6aac072533d1d091a7d2e413     |
  | container_format | bare                                 |
  | created_at       | 2015-09-01T22:17:25.000000           |
  | deleted          | False                                |
  | disk_format      | qcow2                                |
  | id               | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 |
  | is_public        | False                                |
  | min_disk         | 0                                    |
  | min_ram          | 0                                    |
  | name             | private                              |
  | owner            | e1cec705e33b4dfaaece11b623f3c680     |
  | protected        | False                                |
  | size             | 616                                  |
  | status           | active                               |
  | updated_at       | 2015-09-01T22:17:27.000000           |
  +------------------+--------------------------------------+

  The same happens when demo user wants to create/update/delete any
  image. v2 with enabled registry backend is affected too.

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



From 1534299 at bugs.launchpad.net  Mon Jan 25 19:18:48 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 25 Jan 2016 19:18:48 -0000
Subject: [Openstack-security] [Bug 1534299] Re: keystoneclient needs to mark
	secret config options
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160125191848.10012.73017.malone@wampee.canonical.com>

Reviewed:  https://review.openstack.org/269372
Committed: https://git.openstack.org/cgit/openstack/keystoneauth/commit/?id=877ddce29191c2bfdade1d298e7b86c87d945025
Submitter: Jenkins
Branch:    stable/liberty

commit 877ddce29191c2bfdade1d298e7b86c87d945025
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Jan 14 16:43:55 2016 -0600

    Mark password/secret options as secret
    
    Password, token, and secret options should be marked as secret=True
    so that when the value is logged the logger knows to obfuscate the
    value.
    
    Conflicts:
    	keystoneauth1/extras/_saml2/_loading.py
    	keystoneauth1/loading/_plugins/identity/v3.py
    
    - There was no saml2 plugin in keystoneauth1.
    - The OpenIDConnectPassword and OpenIDConnectAuthorizationCode
      plugins didn't exist.
    
    Change-Id: I4818c4cc04cc6a4e1e3cf09d5e0b7b4ffefbb892
    Closes-Bug: 1534299
    (cherry picked from commit fcd9538eaf2b374ec5188426454a5c598621b902)


** Tags added: in-stable-liberty

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  Fix Released

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From nkinder at redhat.com  Mon Jan 25 20:57:29 2016
From: nkinder at redhat.com (Nathan Kinder)
Date: Mon, 25 Jan 2016 20:57:29 -0000
Subject: [Openstack-security] [Bug 1493448] Re: All operations are perfomed
 with admin priveleges when 'use_user_token' is False
References: <20150908163321.8816.82829.malonedeb@wampee.canonical.com>
Message-ID: <20160125205730.9639.30318.malone@wampee.canonical.com>

This has been published as OSSN-0060:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0060

** Changed in: ossn
       Status: New => 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/1493448

Title:
  All operations are perfomed with admin priveleges when
  'use_user_token' is False

Status in Glance:
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  In glance-api.conf we have a param called 'use_user_token' which is
  enabled by default. It was introduced to allow for reauthentication
  when tokens expire and prevents requests from silently failing.
  https://review.openstack.org/#/c/29967/

  Unfortunately disabling this parameter leads to security issues and
  allows a regular user to perform any operation with admin rights.

  Steps to reproduce on devstack:
  1. Change /etc/glance/glance-api.conf parameters and restart glance-api:
  # Pass the user's token through for API requests to the registry.
  # Default: True
  use_user_token = False

  # If 'use_user_token' is not in effect then admin credentials
  # can be specified. Requests to the registry on behalf of
  # the API will use these credentials.
  # Admin user name
  admin_user = glance
  # Admin password
  admin_password = nova
  # Admin tenant name
  admin_tenant_name = service
  # Keystone endpoint
  auth_url = http://127.0.0.1:5000/v2.0

  (for v2 api it's required to enable registry service, too: data_api =
  glance.db.registry.api)

  2. Create a private image with admin user:
  source openrc admin admin
  glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab
  +------------------+--------------------------------------+
  | Property         | Value                                |
  +------------------+--------------------------------------+
  | checksum         | e533283e6aac072533d1d091a7d2e413     |
  | container_format | bare                                 |
  | created_at       | 2015-09-01T22:17:25.000000           |
  | deleted          | False                                |
  | deleted_at       | None                                 |
  | disk_format      | qcow2                                |
  | id               | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 |
  | is_public        | False                                |
  | min_disk         | 0                                    |
  | min_ram          | 0                                    |
  | name             | private                              |
  | owner            | e1cec705e33b4dfaaece11b623f3c680     |
  | protected        | False                                |
  | size             | 616                                  |
  | status           | active                               |
  | updated_at       | 2015-09-01T22:17:27.000000           |
  | virtual_size     | None                                 |
  +------------------+--------------------------------------+

  3. Check the image list with admin user:
  glance --os-image-api-version 1 image-list
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | ID                                   | Name                            | Disk Format | Container Format | Size     | Status |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec         | ami         | ami              | 25165824 | active |
  | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel  | aki         | aki              | 4979632  | active |
  | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari         | ari              | 3740163  | active |
  | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private                         | qcow2       | bare             | 616      | active |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+

  4. Enable demo user and get the image list:
  source openrc demo demo
  glance --os-image-api-version 1 image-list
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | ID                                   | Name                            | Disk Format | Container Format | Size     | Status |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
  | 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec         | ami         | ami              | 25165824 | active |
  | c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel  | aki         | aki              | 4979632  | active |
  | de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari         | ari              | 3740163  | active |
  | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private                         | qcow2       | bare             | 616      | active |
  +--------------------------------------+---------------------------------+-------------+------------------+----------+--------+

  5. Try to get access to admin's private image with demo user:

  glance --os-image-api-version 1 image-show private
  +------------------+--------------------------------------+
  | Property         | Value                                |
  +------------------+--------------------------------------+
  | checksum         | e533283e6aac072533d1d091a7d2e413     |
  | container_format | bare                                 |
  | created_at       | 2015-09-01T22:17:25.000000           |
  | deleted          | False                                |
  | disk_format      | qcow2                                |
  | id               | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 |
  | is_public        | False                                |
  | min_disk         | 0                                    |
  | min_ram          | 0                                    |
  | name             | private                              |
  | owner            | e1cec705e33b4dfaaece11b623f3c680     |
  | protected        | False                                |
  | size             | 616                                  |
  | status           | active                               |
  | updated_at       | 2015-09-01T22:17:27.000000           |
  +------------------+--------------------------------------+

  The same happens when demo user wants to create/update/delete any
  image. v2 with enabled registry backend is affected too.

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



From gerrit2 at review.openstack.org  Tue Jan 26 09:45:29 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 26 Jan 2016 09:45:29 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1aO0Bl-0002WG-AA@review.openstack.org>


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

Log:
commit a8e60b8ec48055c17d5df6fc9a422da2b2e2653c
Author: Solly Ross <sross at redhat.com>
Date:   Tue Aug 19 18:48:00 2014 -0400

    Introduce VNC Security Proxy Framework
    
    This commit introduces the security proxying framework for
    VNC.  Which class is being used to do the security proxying
    can be set on a per-traffic-type basis by pointing
    the appropriate configuration option to an appropriate
    subclass.
    
    Currently, only VNC is supported, via the configuration
    option 'novncproxy_security_driver'.
    
    The workflow for adding a new VNC security proxy driver is
    to subclass the traffic-type-specific security proxy
    base classes (e.g. RFBSecurityProxyHelper), and implement
    the `choose_security_type` and `security_handshake` methods.
    
    DocImpact
    SecurityImpact
    Implements bp: websocket-proxy-to-host-security
    
    Change-Id: Id586b2558fd4c7ed0eda3d3555d51fcd019eb414




From gerrit2 at review.openstack.org  Tue Jan 26 09:45:36 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 26 Jan 2016 09:45:36 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1aO0Bs-0002Y0-HF@review.openstack.org>


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

Log:
commit 5deb4bd34bde3fefcca53ade297fddc276a48e69
Author: Solly Ross <sross at redhat.com>
Date:   Tue Aug 19 19:21:52 2014 -0400

    Add VeNCrypt (TLS/x509) Security Proxy Driver
    
    This adds support for using x509/TLS security
    between the compute node and websocket proxy when
    using websockify to proxy VNC traffic.
    
    In order to use this with x509, an operator would
    have to set up client keys and certificates, as
    well as CA certificates, and configure libvirt
    to pass the appropriate options to QEmu (this
    is configured globally for libvirt, not by Nova).
    This process is documented on the libvirt
    website.
    
    Then, the operator would enable this driver and
    set the following options in /etc/nova/nova.conf:
    
       [console_proxy_tls]
       client_key = /path/to/client/keyfile
       client_cert = /path/to/client/cert.pem
       ca_certs = /path/to/ca/cert.pem
    
    SecurityImpact
    DocImpact
    Implements bp: websocket-proxy-to-host-security
    
    Change-Id: I64859ad01120782fb17308aac3abb125597c3ea2




From gerrit2 at review.openstack.org  Tue Jan 26 11:32:42 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 26 Jan 2016 11:32:42 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Id586b2558fd4c7ed0eda3d3555d51fcd019eb414
Message-ID: <E1aO1rW-0000yd-Aj@review.openstack.org>


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

Log:
commit 397b6ff181d8d6530ce7205e593591f8cf3b2eb6
Author: Solly Ross <sross at redhat.com>
Date:   Tue Aug 19 18:48:00 2014 -0400

    Introduce VNC Security Proxy Framework
    
    This commit introduces the security proxying framework for
    VNC.  Which class is being used to do the security proxying
    can be set on a per-traffic-type basis by pointing
    the appropriate configuration option to an appropriate
    subclass.
    
    Currently, only VNC is supported, via the configuration
    option 'novncproxy_security_driver'.
    
    The workflow for adding a new VNC security proxy driver is
    to subclass the traffic-type-specific security proxy
    base classes (e.g. RFBSecurityProxyHelper), and implement
    the `choose_security_type` and `security_handshake` methods.
    
    DocImpact
    SecurityImpact
    Implements bp: websocket-proxy-to-host-security
    
    Change-Id: Id586b2558fd4c7ed0eda3d3555d51fcd019eb414




From gerrit2 at review.openstack.org  Tue Jan 26 11:32:49 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 26 Jan 2016 11:32:49 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I64859ad01120782fb17308aac3abb125597c3ea2
Message-ID: <E1aO1rd-0000zE-SR@review.openstack.org>


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

Log:
commit 46b2604380244a45ab466a55153a3ba6b94e7651
Author: Solly Ross <sross at redhat.com>
Date:   Tue Aug 19 19:21:52 2014 -0400

    Add VeNCrypt (TLS/x509) Security Proxy Driver
    
    This adds support for using x509/TLS security
    between the compute node and websocket proxy when
    using websockify to proxy VNC traffic.
    
    In order to use this with x509, an operator would
    have to set up client keys and certificates, as
    well as CA certificates, and configure libvirt
    to pass the appropriate options to QEmu (this
    is configured globally for libvirt, not by Nova).
    This process is documented on the libvirt
    website.
    
    Then, the operator would enable this driver and
    set the following options in /etc/nova/nova.conf:
    
       [console_proxy_tls]
       client_key = /path/to/client/keyfile
       client_cert = /path/to/client/cert.pem
       ca_certs = /path/to/ca/cert.pem
    
    SecurityImpact
    DocImpact
    Implements bp: websocket-proxy-to-host-security
    
    Change-Id: I64859ad01120782fb17308aac3abb125597c3ea2




From 1516031 at bugs.launchpad.net  Wed Jan 27 01:58:32 2016
From: 1516031 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 27 Jan 2016 01:58:32 -0000
Subject: [Openstack-security] [Bug 1516031] Fix merged to glance (master)
References: <20151113142716.4469.80964.malonedeb@gac.canonical.com>
Message-ID: <20160127015833.31105.75258.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/271513
Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=eab1567d48a18fa968c7b66c3641dd037da1f84e
Submitter: Jenkins
Branch:    master

commit eab1567d48a18fa968c7b66c3641dd037da1f84e
Author: Brianna Poulos <Brianna.Poulos at jhuapl.edu>
Date:   Fri Jan 22 15:13:35 2016 -0500

    Remove unneeded glance unit test assert calls
    
    The glance_store library now accepts a verifier object for use with
    verifying signatures, as a result of a recently merged patch [1].
    There are some glance unit tests that do not expect this verifier
    object to be passed to the add method of glance_store, and will
    therefore fail with a new release of the glance_store library.
    
    This patch removes the assert lines for the tests that will fail,
    since it is not necessary for glance to test glance_store in that
    way at the glance level.
    
    [1] https://review.openstack.org/#/c/183110/
    
    Change-Id: I404fbc40dafa159a63a6dfee563f05ee80c073dc
    Partial-Bug: #1516031

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

Title:
  Use of MD5 in OpenStack Glance image signature (CVE-2015-8234)

Status in Glance:
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  This have been reported by Daniel P. Berrange:
  "
  In the OpenStack Liberty release, the Glance project added support for image signature verification.

  http://specs.openstack.org/openstack/glance-specs/specs/liberty/image-
  signing-and-verification-support.html

  The verification code was added in the following git commit

  https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e

  
  Unfortunately the design of this signature verification method is flawed by design.

  The generalized approach to creating signatures of content is to apply
  a hash to the content and then encrypt it in some manner. Consider
  that the signature is defined to use hash=sha256 and cipher=rsa we can
  describe the signature computation as

  signature = rsa(sha256(content))

  In the case of verifying a disk image, the content we care about
  verifying is the complete disk image file. Unfortunately, the glance
  specification chose *not* to compute the signature against the disk
  image file. Glance already had an MD5 checksum calculated for the disk
  image file, so they instead chose to compute the signature against the
  MD5 checksum instead. ie glance is running

  signature = rsa(sha256(md5(disk-image-content)))

  This degrades the security of the system to that of the weakest hash,
  which is obviously MD5 here.

  The code where glance verifies the signature is in the
  glance/locations.py, the 'set_data' method where is does

   result = signature_utils.verify_signature(
   self.context, checksum, self.image.extra_properties)
   if result:
   LOG.info(_LI("Successfully verified signature for image %s"),
   self.image.image_id)

  The 'checksum' variable is populate by the glance_store driver, but it
  is hardcoded to always be md5 in all current glance storage backends:

   $ git grep hashlib glance_store/_drivers/ | grep checksum
   glance_store/_drivers/filesystem.py: checksum = hashlib.md5()
   glance_store/_drivers/rbd.py: checksum = hashlib.md5()
   glance_store/_drivers/s3.py: checksum = hashlib.md5()
   glance_store/_drivers/s3.py: checksum = hashlib.md5()
   glance_store/_drivers/sheepdog.py: checksum = hashlib.md5()
   glance_store/_drivers/swift/store.py: checksum =
   hashlib.md5()
   glance_store/_drivers/vmware_datastore.py: self.checksum =
   hashlib.md5()

  
  Since we will soon be shipping OpenStack Liberty release, we need to at least give a security notice to alert our customers to the fact that the signature verification is cryptographically weak/broken. IMHO, it quite likely deserves a CVE though

  NB, this is public knowledge as I first became aware of this flawed
  design in comments / discussion on a public specification proposed to
  implement the same approach in the Nova project.

  My suggested way to fix this is to simply abandon the current impl and
  re-do it such that it directly computes the signature against  the
  disk image, and does not use the existing md5 checksum in any way.

  Regards,
  Daniel
  "

  Mailing list thread for Nova impl: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079348.html
  Nova Spec: https://review.openstack.org/#/c/188874/

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



From dougwig at parkside.io  Thu Jan 21 21:55:54 2016
From: dougwig at parkside.io (Doug Wiegley)
Date: Thu, 21 Jan 2016 21:55:54 -0000
Subject: [Openstack-security] [Bug 1163569] Re: security groups don't work
 with LBaaS vip and ovs plugin
References: <20130402204346.20639.18981.malonedeb@wampee.canonical.com>
Message-ID: <20160121215557.31105.37225.launchpad@gac.canonical.com>

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

-- 
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 LBaaS vip and ovs plugin

Status in neutron:
  Confirmed
Status in OpenStack Security Notes:
  Won't Fix

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 fungi at yuggoth.org  Wed Jan 27 13:46:03 2016
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 27 Jan 2016 13:46:03 -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: <20160127134603.9639.79474.malone@wampee.canonical.com>

Since this bug was switched from public back to public security with no
comment explaining why, I have reset it to public again. Please,
whenever moving a bug to a security type, add a comment with your
reasoning.

** Information type changed from Public Security to Public

-- 
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 doug at doughellmann.com  Wed Jan 27 17:14:27 2016
From: doug at doughellmann.com (Doug Hellmann)
Date: Wed, 27 Jan 2016 17:14:27 -0000
Subject: [Openstack-security] [Bug 1534322] Fix included in
	openstack/neutron 7.0.2
References: <20160114214439.14625.28884.malonedeb@wampee.canonical.com>
Message-ID: <20160127171427.29030.15383.malone@soybean.canonical.com>

This issue was fixed in the openstack/neutron 7.0.2 release.

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

Title:
  On new port, traffic flow is allowed before security groups are
  programmed

Status in neutron:
  Fix Released
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.

  --

  Description:
  During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed.

  File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
  Funtion: process_network_ports

  Step-by-step:
  During the creation of a neutron port, the following calls are made:
  - treat_devices_added_or_updated
  - sg_agent.setup_port_filters
  - _bind_devices

  Before early November, process_network_ports called
  sg_agent.setup_port_filters before it called _bind_devices. This meant
  that security groups were programmed before traffic flow is enabled by
  _bind_devices, which sets the port-lvm mapping in br-int.

  Bug #1512636 reversed this order of operation, so that _bind_devices
  is called before sg_agent.setup_port_filters. This opens up a brief
  security hole, allowing traffic to flow for a short time before
  security groups are applied.

  Proposed solution:
  Revert bug# 1512636

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



From 1534299 at bugs.launchpad.net  Thu Jan 28 21:45:41 2016
From: 1534299 at bugs.launchpad.net (OpenStack Infra)
Date: Thu, 28 Jan 2016 21:45:41 -0000
Subject: [Openstack-security] [Bug 1534299] Fix merged to
	python-keystoneclient (stable/liberty)
References: <20160114203831.26502.33062.malonedeb@soybean.canonical.com>
Message-ID: <20160128214541.11137.56360.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/269363
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=1da2c545c3c9099eedf81ebc8b95ab08b311a8c0
Submitter: Jenkins
Branch:    stable/liberty

commit 1da2c545c3c9099eedf81ebc8b95ab08b311a8c0
Author: Brant Knudson <bknudson at us.ibm.com>
Date:   Thu Jan 14 16:22:04 2016 -0600

    Mark password/secret options as secret
    
    Password, token, and secret options should be marked as secret=True
    so that when the value is logged the logger knows to obfuscate the
    value.
    
    Change-Id: I6ebdfa3bf6faf37bc11640a5826b3b55bb920fc4
    Closes-Bug: 1534299
    (cherry picked from commit 04f9f33b4b6079d39c3feea0b1ec1211a1de6a04)

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

Title:
  keystoneclient needs to mark secret config options

Status in keystoneauth:
  Fix Released
Status in OpenStack Security Advisory:
  Won't Fix
Status in python-keystoneclient:
  Fix Released

Bug description:
  oslo_config allows marking config options such as password as
  "secret", such that when/if the config options are logged they're
  masked out of the logs.

  keystoneclient defines several options for auth plugins that should be
  secret but are not, such as the user's password in the identity, oidc,
  and saml2 plugins.

  I don't know if these really need to be private security but might as
  well start out that way.

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



From gerrit2 at review.openstack.org  Fri Jan 29 00:33:46 2016
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 29 Jan 2016 00:33:46 +0000
Subject: [Openstack-security] [openstack/barbican-specs] SecurityImpact
 review request change I02054d80f68f38145b399909d60db80a4d91c1ba
Message-ID: <E1aOx0U-0001sQ-Ru@review.openstack.org>


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

Log:
commit 19cffa72544ca96b084a514d96c5494b043ce568
Author: Arun Kant <arun.kant at hpe.com>
Date:   Tue Jan 5 16:37:53 2016 -0800

    Adding spec for supporting multiple secret store backends
    
    Updated patch to clarify review comments.
    
    APIImpact
    SecurityImpact
    
    Change-Id: I02054d80f68f38145b399909d60db80a4d91c1ba