From gerrit2 at review.openstack.org  Mon Sep  2 10:49:23 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 02 Sep 2013 10:49:23 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VGRhD-0004jx-8A@review.openstack.org>


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

Log:
commit c529d4d9bd719129475869a9750c08fc13d44166
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From gerrit2 at review.openstack.org  Mon Sep  2 11:30:52 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 02 Sep 2013 11:30:52 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VGSLM-0007D6-IR@review.openstack.org>


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

Log:
commit 5ce9d76377251d03dfa09485ab2d6c01c2556cfe
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From 1174499 at bugs.launchpad.net  Mon Sep  2 19:47:49 2013
From: 1174499 at bugs.launchpad.net (OpenStack Infra)
Date: Mon, 02 Sep 2013 19:47:49 -0000
Subject: [Openstack-security] [Bug 1174499] Re: Keystone token hashing is MD5
References: <20130429193226.5432.76936.malonedeb@wampee.canonical.com>
Message-ID: <20130902194750.20101.34683.malone@soybean.canonical.com>

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

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

** Changed in: python-keystoneclient
     Assignee: (unassigned) => Dirk Mueller (dmllr)

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

Title:
  Keystone token hashing is MD5

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

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

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

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

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



From gerrit2 at review.openstack.org  Tue Sep  3 09:09:24 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 03 Sep 2013 09:09:24 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VGmc0-0007jo-PW@review.openstack.org>


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

Log:
commit 03c91f40f6993ec82948e30261fbc5d24a660433
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performanse issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as provding pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    DocImpact
    
    Partially Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From gerrit2 at review.openstack.org  Tue Sep  3 09:26:37 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 03 Sep 2013 09:26:37 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VGmsf-0000RF-PQ@review.openstack.org>


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

Log:
commit 76cdef602bac7f109b989991ace2a7339caa96b5
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performanse issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as provding pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    DocImpact
    
    Partially Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From gerrit2 at review.openstack.org  Tue Sep  3 09:51:40 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 03 Sep 2013 09:51:40 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VGnGu-0002Qn-HQ@review.openstack.org>


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

Log:
commit eadf80068d56b909bec4980b57ee433b17fd6465
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performanse issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as provding pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    DocImpact
    
    Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From thierry.carrez+lp at gmail.com  Tue Sep  3 11:55:16 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Tue, 03 Sep 2013 11:55:16 -0000
Subject: [Openstack-security] [Bug 1218977] Re: DOS by passing an ephemeral
	or swap of arbitrary	size
References: <20130830151826.9129.35686.malonedeb@soybean.canonical.com>
Message-ID: <20130903115517.29940.23847.malone@gac.canonical.com>

Agreed. I opened it, please fix publicly

** Information type changed from Private Security to Public

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

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

Title:
  DOS by passing an ephemeral or swap of arbitrary size

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  Due to a previous bug that was never caught and the fact that we can
  now pass ephemeral and block devices through the API, it is possible
  to ask nova to create an arbitrarily large ephemeral block device -
  which nova will happily do (and by default make it raw).

  The bug was introduced in commit
  0ef7e15e225efcce3e02098cb1d57f9f40181f82 as before that commit the
  ephemeral device size will be defaulted to whatever was in the
  instance_type - due to a bug this defaulting was not done anymore (see
  compute.api.API._update_block_device_mapping).

  Steps to reproduce:

  ndipanov at localhost devstack]$ nova flavor-show 1
  +----------------------------+---------+
  | Property                   | Value   |
  +----------------------------+---------+
  | name                       | m1.tiny |
  | ram                        | 512     |
  | OS-FLV-DISABLED:disabled   | False   |
  | vcpus                      | 1       |
  | extra_specs                | {}      |
  | swap                       |         |
  | os-flavor-access:is_public | True    |
  | rxtx_factor                | 1.0     |
  | OS-FLV-EXT-DATA:ephemeral  | 0       | <--- Ephemeral is 0
  | disk                       | 1       |
  | id                         | 1       |
  +----------------------------+---------+
  [ndipanov at localhost devstack]$ nova --debug boot --image 308f190c-d2f7-44fe-9b6d-7a28e2e2aa64 --flavor 1 --block-device source=blank,dest=local,size=2,device=vdb testvme2 #using the not yet merged novaclient patch https://review.openstack.org/#/c/38815/. The request dict is as follows: '{"server": {"name": "testvme2", "imageRef": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "block_device_mapping_v2": [{"source_type": "image", "delete_on_termination": true, "boot_index": 0, "uuid": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "destination_type": "local"}, {"source_type": "blank", "delete_on_termination": true, "device_name": "vdb", "volume_size": "2", "destination_type": "local"}], "flavorRef": "1", "max_count": 1, "min_count": 1}}'
  [ndipanov at localhost devstack]$ nova list
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | ID                                   | Name     | Status | Task State | Power State | Networks         |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | 6c8a571c-3c1b-4fef-800e-0cecea927566 | testvme2 | ACTIVE | None       | Running     | private=10.0.0.2 |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  [ndipanov at localhost devstack]$ cd /opt/stack/data/nova/instances/_base/
  [ndipanov at localhost _base]$ ls -lah
  total 130M
  drwxrwxr-x. 2 ndipanov libvirtd 4.0K Aug 30 10:59 .
  drwxr-xr-x. 5 ndipanov root     4.0K Aug 30 10:59 ..
  -rw-rw-r--. 1 ndipanov libvirtd 4.8M Aug 30 10:59 65706cf4-0f63-4cf6-a8ee-a1dc447a6380
  -rw-rw-r--. 1 qemu     qemu      24M Aug 30 10:59 8bf383ae7171db9b882fc6e33eebf619896d67b7
  -rw-r--r--. 1 qemu     qemu     2.0G Aug 30 10:59 ephemeral_2_default
  -rw-rw-r--. 1 ndipanov libvirtd 3.6M Aug 30 10:59 fe478037-cd36-4517-b886-fd6e14d7462e

  We can see that the raw image was happily created by nova. completely
  disregarding the limitation.

  I have attached a proposed patch.

  This bug only affects current trunk as of the commit mentioned above.

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



From thierry.carrez+lp at gmail.com  Tue Sep  3 12:15:47 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Tue, 03 Sep 2013 12:15:47 -0000
Subject: [Openstack-security] [Bug 1218977] Re: DOS by passing an ephemeral
	or swap of arbitrary	size
References: <20130830151826.9129.35686.malonedeb@soybean.canonical.com>
Message-ID: <20130903121549.25222.10503.launchpad@chaenomeles.canonical.com>

** Changed in: nova
     Assignee: (unassigned) => Nikola Đipanov (ndipanov)

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

Title:
  DOS by passing an ephemeral or swap of arbitrary size

Status in OpenStack Compute (Nova):
  Confirmed

Bug description:
  Due to a previous bug that was never caught and the fact that we can
  now pass ephemeral and block devices through the API, it is possible
  to ask nova to create an arbitrarily large ephemeral block device -
  which nova will happily do (and by default make it raw).

  The bug was introduced in commit
  0ef7e15e225efcce3e02098cb1d57f9f40181f82 as before that commit the
  ephemeral device size will be defaulted to whatever was in the
  instance_type - due to a bug this defaulting was not done anymore (see
  compute.api.API._update_block_device_mapping).

  Steps to reproduce:

  ndipanov at localhost devstack]$ nova flavor-show 1
  +----------------------------+---------+
  | Property                   | Value   |
  +----------------------------+---------+
  | name                       | m1.tiny |
  | ram                        | 512     |
  | OS-FLV-DISABLED:disabled   | False   |
  | vcpus                      | 1       |
  | extra_specs                | {}      |
  | swap                       |         |
  | os-flavor-access:is_public | True    |
  | rxtx_factor                | 1.0     |
  | OS-FLV-EXT-DATA:ephemeral  | 0       | <--- Ephemeral is 0
  | disk                       | 1       |
  | id                         | 1       |
  +----------------------------+---------+
  [ndipanov at localhost devstack]$ nova --debug boot --image 308f190c-d2f7-44fe-9b6d-7a28e2e2aa64 --flavor 1 --block-device source=blank,dest=local,size=2,device=vdb testvme2 #using the not yet merged novaclient patch https://review.openstack.org/#/c/38815/. The request dict is as follows: '{"server": {"name": "testvme2", "imageRef": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "block_device_mapping_v2": [{"source_type": "image", "delete_on_termination": true, "boot_index": 0, "uuid": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "destination_type": "local"}, {"source_type": "blank", "delete_on_termination": true, "device_name": "vdb", "volume_size": "2", "destination_type": "local"}], "flavorRef": "1", "max_count": 1, "min_count": 1}}'
  [ndipanov at localhost devstack]$ nova list
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | ID                                   | Name     | Status | Task State | Power State | Networks         |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | 6c8a571c-3c1b-4fef-800e-0cecea927566 | testvme2 | ACTIVE | None       | Running     | private=10.0.0.2 |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  [ndipanov at localhost devstack]$ cd /opt/stack/data/nova/instances/_base/
  [ndipanov at localhost _base]$ ls -lah
  total 130M
  drwxrwxr-x. 2 ndipanov libvirtd 4.0K Aug 30 10:59 .
  drwxr-xr-x. 5 ndipanov root     4.0K Aug 30 10:59 ..
  -rw-rw-r--. 1 ndipanov libvirtd 4.8M Aug 30 10:59 65706cf4-0f63-4cf6-a8ee-a1dc447a6380
  -rw-rw-r--. 1 qemu     qemu      24M Aug 30 10:59 8bf383ae7171db9b882fc6e33eebf619896d67b7
  -rw-r--r--. 1 qemu     qemu     2.0G Aug 30 10:59 ephemeral_2_default
  -rw-rw-r--. 1 ndipanov libvirtd 3.6M Aug 30 10:59 fe478037-cd36-4517-b886-fd6e14d7462e

  We can see that the raw image was happily created by nova. completely
  disregarding the limitation.

  I have attached a proposed patch.

  This bug only affects current trunk as of the commit mentioned above.

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



From gerrit2 at review.openstack.org  Tue Sep  3 17:56:43 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 03 Sep 2013 17:56:43 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VGuqJ-0003w8-1d@review.openstack.org>


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

Log:
commit 5de89f0fa107d7dd96f40be52cd43cd5bd52f528
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performanse issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as provding pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    DocImpact
    
    Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From gerrit2 at review.openstack.org  Tue Sep  3 20:30:33 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 03 Sep 2013 20:30:33 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VGxFB-0008Er-1i@review.openstack.org>


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

Log:
commit ac0691e87bd7444ca08b7f11dee0afcc12418dcd
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From gerrit2 at review.openstack.org  Tue Sep  3 22:28:23 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 03 Sep 2013 22:28:23 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I358813b3ecde4f88de7202c1c07d9b1168c2c332
Message-ID: <E1VGz5D-00012f-3M@review.openstack.org>


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

Log:
commit ef0da1bfdb70f2710db91ad80766af42908760b0
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Sep 3 18:18:24 2013 -0400

    Add encryption support for volumes to libvirt
    
    Add support to encrypt Cinder volumes. Hooks within the libvirt
    driver encrypt volumes during the attach call. Created a
    VolumeEncryptor interface as well as several concrete subclasses
    (e.g., CryptsetupEncryptor and LuksEncryptor) to handle encryption.
    
    This feature depends upon related changes that have been accepted
    into Cinder (e.g., storing encryption key UUIDs for encrypted
    volumes).
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332
    SecurityImpact




From gerrit2 at review.openstack.org  Tue Sep  3 23:09:40 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 03 Sep 2013 23:09:40 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VGzjA-00040C-1T@review.openstack.org>


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

Log:
commit 45f71bde90f49f6e652f0d4db53e8ff501a4c6c1
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performance issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as providing pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    DocImpact
    
    Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From gerrit2 at review.openstack.org  Tue Sep  3 23:57:34 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 03 Sep 2013 23:57:34 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VH0TW-0007HL-UP@review.openstack.org>


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

Log:
commit 379c934f377df972890faddf7a3a35577a7deca1
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performance issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as providing pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    
    Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From gerrit2 at review.openstack.org  Wed Sep  4 10:32:19 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 10:32:19 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VHANn-0004zc-2T@review.openstack.org>


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

Log:
commit 66a93021e21d79691ab6271dc6acb7fe4702a190
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performance issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as providing pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    
    Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From gerrit2 at review.openstack.org  Wed Sep  4 10:33:01 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 10:33:01 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VHAOT-00053Z-6d@review.openstack.org>


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

Log:
commit fdca627965a15c268a8bcbb81e90e9a0a1e85778
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From gerrit2 at review.openstack.org  Wed Sep  4 18:05:58 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 18:05:58 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VHHSo-0007PB-5P@review.openstack.org>


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

Log:
commit 683442d70f25fee3cf931e817a25c3db23d32e22
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performance issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as providing pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    
    Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From gerrit2 at review.openstack.org  Wed Sep  4 19:16:10 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 19:16:10 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VHIYk-0004AO-9S@review.openstack.org>


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

Log:
commit 0d54d13676a16c90c77d8002bedc8dbbeb757dad
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Wed Sep 4 15:09:46 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From gerrit2 at review.openstack.org  Wed Sep  4 19:33:59 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 19:33:59 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VHIpz-0005cn-N3@review.openstack.org>


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

Log:
commit 2fe6511447336a53052314897e1b5ad18f9af7db
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Wed Sep 4 15:09:46 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From gerrit2 at review.openstack.org  Wed Sep  4 20:48:43 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 20:48:43 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VHK0J-0004WT-DM@review.openstack.org>


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

Log:
commit be847f6d1e0ac0827c7b37acf769902bc116d286
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Wed Sep 4 16:46:04 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From gerrit2 at review.openstack.org  Wed Sep  4 21:41:45 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 21:41:45 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VHKpd-0000QL-05@review.openstack.org>


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

Log:
commit cc79d5c0a8d8e0115af85d8f7c36cc247dbee106
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performance issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as providing pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    
    Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From gerrit2 at review.openstack.org  Wed Sep  4 21:43:41 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 21:43:41 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VHKrV-0000Zi-9J@review.openstack.org>


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

Log:
commit 6a2e262dff834ee76d95f95a1c3b707b86e1f1ab
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Wed Sep 4 16:46:04 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From gerrit2 at review.openstack.org  Wed Sep  4 22:09:48 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 22:09:48 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I358813b3ecde4f88de7202c1c07d9b1168c2c332
Message-ID: <E1VHLGm-0002kW-PD@review.openstack.org>


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

Log:
commit 2b1ef68edda72cebb79b7763830ce9fe72a4c518
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Wed Sep 4 18:08:30 2013 -0400

    Add encryption support for volumes to libvirt
    
    Add support to encrypt Cinder volumes. Hooks within the libvirt
    driver encrypt volumes during the attach call. Created a
    VolumeEncryptor interface as well as several concrete subclasses
    (e.g., CryptsetupEncryptor and LuksEncryptor) to handle encryption.
    
    This feature depends upon related changes that have been accepted
    into Cinder (e.g., storing encryption key UUIDs for encrypted
    volumes).
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332
    SecurityImpact




From gerrit2 at review.openstack.org  Wed Sep  4 22:58:47 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 04 Sep 2013 22:58:47 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VHM2B-0006e9-VC@review.openstack.org>


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

Log:
commit 6110608e50be982aa417fdd545bfe8e92f27e25f
Author: Henry Nash <henryn at linux.vnet.ibm.com>
Date:   Sun Aug 11 10:26:31 2013 +0100

    Implement filter support in driver backends
    
    Currently filtering is only done at the controller level, leading to
    performance issues since we are not using native filtering capabilities
    of any of the underlying backends (e.g. SQL, LDAP). This patch enables
    such support.
    
    This patch also creates the foundation for implementing truncation of
    lists to size set by the cloud provider as well as providing pagination
    support.  However, both these capabilities are implemented as separate
    patches.
    
    Limitations:
    
    - The LDAP backend does not yet support for filtering, leaving it to the
      controller level.  LDAP support will be added in a separate patch
    - The inexact filters are disabled, pending api review of the changes,
      which is targeted for IceHouse
    - Filtering for service, endpoint and policy is left at the controller
      level, since these operations are not considered performance issues.
    
    SecurityImpact: Please review for Potential for Sql Injection attacks.
    
    Implements bp filtering-backend-support
    
    Change-Id: If5229d89a39dca952dee3b1c4cbf3b34b8afa95b




From thierry.carrez+lp at gmail.com  Thu Sep  5 09:24:18 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 05 Sep 2013 09:24:18 -0000
Subject: [Openstack-security] [Bug 1178032] Re: ldap driver returns hashed
	passwords
References: <20130509001314.14958.69418.malonedeb@gac.canonical.com>
Message-ID: <20130905092421.19469.78349.launchpad@gac.canonical.com>

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

** Changed in: keystone
    Milestone: None => havana-3

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

Title:
  ldap driver returns hashed passwords

Status in OpenStack Identity (Keystone):
  Fix Released

Bug description:
  
  If I'm using the LDAP identity backend, listing group users includes the users' passwords (sha-encoded, but that probably depends on LDAP server configuration).

  Keystone shouldn't be handing out users' passwords.

  The fix is probably to just remove the password attribute. If Keystone
  is just returning all attributes, then it should be changed to only
  return the attributes that are known to be safe.

  Steps to recreate:

  1) start with devstack configured to use LDAP
  # set LDAP options in localrc
  ./stack.sh ...

  2) add the default domain since it doesn't exist by default for some
  reason.

  $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd
  dn: cn=default,ou=Domains,dc=openstack,dc=org
  objectclass: groupOfNames
  member: cn=dummy

  3) Create a couple users

  (set environment variables so you're admin)

  $ keystone user-create --name user1 --pass user1pwd
  (example id is 1db4a4d16ba1458aae139db0f43b0904)
  $ keystone user-create --name user2 --pass user2pwd
  (example id is 4091d11924f5498c8008b655bcf94b9d)

  4) Create a group

  $ ldapadd -x -D dc=Manager,dc=openstack,dc=org -w ldapadminpwd

  dn: ou=UserGroups,dc=openstack,dc=org
  objectclass: organizationalUnit

  dn: cn=group1,ou=UserGroups,dc=openstack,dc=org
  objectclass: groupOfNames
  member: cn=1db4a4d16ba1458aae139db0f43b0904,ou=Users,dc=openstack,dc=org
  member: cn=4091d11924f5498c8008b655bcf94b9d,ou=Users,dc=openstack,dc=org

  5) List the group members:

  $ curl -H "X-Auth-Token: admintoken"
  http://localhost:35357/v3/groups/group1/users | python -m json.tool

  {
      "links": {
          "next": null,
          "previous": null,
          "self": "http://localhost:5000/v3/groups/group1/users"
      },
      "users": [
          {
              "domain_id": "default",
              "id": "1db4a4d16ba1458aae139db0f43b0904",
              "links": {
                  "self": "http://localhost:5000/v3/users/1db4a4d16ba1458aae139db0f43b0904"
              },
              "name": "user1",
              "password": "{SSHA}eQnQSd6SS6tioL/uN4M7odr/cf2SsjbG"
          },
          {
              "domain_id": "default",
              "id": "4091d11924f5498c8008b655bcf94b9d",
              "links": {
                  "self": "http://localhost:5000/v3/users/4091d11924f5498c8008b655bcf94b9d"
              },
              "name": "user2",
              "password": "{SSHA}HDtgM7HcrlXnLM7N85htpz1kKYL2npMS"
          }
      ]
  }

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



From thierry.carrez+lp at gmail.com  Thu Sep  5 10:06:28 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 05 Sep 2013 10:06:28 -0000
Subject: [Openstack-security] [Bug 1201534] Re: heat.common.urlfetch does
	not validate server SSL	certificates
References: <20130715180838.2851.94826.malonedeb@wampee.canonical.com>
Message-ID: <20130905100630.15842.89471.launchpad@soybean.canonical.com>

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

** Changed in: heat
    Milestone: None => havana-3

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

Title:
  heat.common.urlfetch does not validate server SSL certificates

Status in Orchestration API (Heat):
  Fix Released

Bug description:
  urllib2 is not considered "safe" for SSL communications. It does
  nothing to validate the server SSL certificate.

  We should migrate to requests, which has become common in OpenStack.

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



From gerrit2 at review.openstack.org  Thu Sep  5 11:54:55 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 05 Sep 2013 11:54:55 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VHY9H-0006Ch-2y@review.openstack.org>


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

Log:
commit 8a2cf2e7a9824d92e3b5d28ccb6d70d6d3fa0bcf
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Sep 5 07:48:56 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From gerrit2 at review.openstack.org  Thu Sep  5 12:07:39 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 05 Sep 2013 12:07:39 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VHYLb-0006yu-Da@review.openstack.org>


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

Log:
commit c0bcd16477a4a6fa517f10bac9143c7feafe2475
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Sep 5 07:48:56 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From gerrit2 at review.openstack.org  Thu Sep  5 12:56:38 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 05 Sep 2013 12:56:38 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VHZ70-0002Ob-Bv@review.openstack.org>


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

Log:
commit d0692007a96dbef156c55e0d5817abb6ab5c5177
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Sep 5 07:48:56 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From gerrit2 at review.openstack.org  Thu Sep  5 13:00:00 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 05 Sep 2013 13:00:00 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I358813b3ecde4f88de7202c1c07d9b1168c2c332
Message-ID: <E1VHZAG-0002k1-1Z@review.openstack.org>


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

Log:
commit cf7b491482fae2ae15ffec2577648bdaaf4a009d
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Sep 5 08:59:03 2013 -0400

    Add encryption support for volumes to libvirt
    
    Add support to encrypt Cinder volumes. Hooks within the libvirt
    driver encrypt volumes during the attach call. Created a
    VolumeEncryptor interface as well as several concrete subclasses
    (e.g., CryptsetupEncryptor and LuksEncryptor) to handle encryption.
    
    This feature depends upon related changes that have been accepted
    into Cinder (e.g., storing encryption key UUIDs for encrypted
    volumes).
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332
    SecurityImpact




From gerrit2 at review.openstack.org  Thu Sep  5 13:16:22 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 05 Sep 2013 13:16:22 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VHZQ6-0003rJ-8z@review.openstack.org>


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

Log:
commit 0797773f814be0a40d696b510c74da44c9ac9a1d
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Sep 5 09:15:39 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From gerrit2 at review.openstack.org  Thu Sep  5 13:22:06 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 05 Sep 2013 13:22:06 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I358813b3ecde4f88de7202c1c07d9b1168c2c332
Message-ID: <E1VHZVe-0004Ho-NT@review.openstack.org>


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

Log:
commit 1784f0e62cadbaa9f3197725fc1dd13d351c44e0
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Sep 5 09:21:12 2013 -0400

    Add encryption support for volumes to libvirt
    
    Add support to encrypt Cinder volumes. Hooks within the libvirt
    driver encrypt volumes during the attach call. Created a
    VolumeEncryptor interface as well as several concrete subclasses
    (e.g., CryptsetupEncryptor and LuksEncryptor) to handle encryption.
    
    This feature depends upon related changes that have been accepted
    into Cinder (e.g., storing encryption key UUIDs for encrypted
    volumes).
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332
    SecurityImpact




From thierry.carrez+lp at gmail.com  Thu Sep  5 13:38:10 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 05 Sep 2013 13:38:10 -0000
Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should
	not be world-readable
References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com>
Message-ID: <20130905133813.15540.98527.launchpad@soybean.canonical.com>

** Changed in: nova
    Milestone: havana-3 => havana-rc1

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

Title:
  image files in _base should not be world-readable

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 ,
  so probably no point making this private.  But I checked the security
  vulnerability box anyway so someone else can decide.

  We create image files in /var/lib/nova/instances/_base with default
  permissions, usually 644.  It would be better to not make the image
  files world-readable, in case they contain private data.

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



From thierry.carrez+lp at gmail.com  Thu Sep  5 15:37:47 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 05 Sep 2013 15:37:47 -0000
Subject: [Openstack-security] [Bug 1218977] Re: DOS by passing an ephemeral
	or swap of arbitrary	size
References: <20130830151826.9129.35686.malonedeb@soybean.canonical.com>
Message-ID: <20130905153750.15675.85028.launchpad@soybean.canonical.com>

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

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

Title:
  DOS by passing an ephemeral or swap of arbitrary size

Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  Due to a previous bug that was never caught and the fact that we can
  now pass ephemeral and block devices through the API, it is possible
  to ask nova to create an arbitrarily large ephemeral block device -
  which nova will happily do (and by default make it raw).

  The bug was introduced in commit
  0ef7e15e225efcce3e02098cb1d57f9f40181f82 as before that commit the
  ephemeral device size will be defaulted to whatever was in the
  instance_type - due to a bug this defaulting was not done anymore (see
  compute.api.API._update_block_device_mapping).

  Steps to reproduce:

  ndipanov at localhost devstack]$ nova flavor-show 1
  +----------------------------+---------+
  | Property                   | Value   |
  +----------------------------+---------+
  | name                       | m1.tiny |
  | ram                        | 512     |
  | OS-FLV-DISABLED:disabled   | False   |
  | vcpus                      | 1       |
  | extra_specs                | {}      |
  | swap                       |         |
  | os-flavor-access:is_public | True    |
  | rxtx_factor                | 1.0     |
  | OS-FLV-EXT-DATA:ephemeral  | 0       | <--- Ephemeral is 0
  | disk                       | 1       |
  | id                         | 1       |
  +----------------------------+---------+
  [ndipanov at localhost devstack]$ nova --debug boot --image 308f190c-d2f7-44fe-9b6d-7a28e2e2aa64 --flavor 1 --block-device source=blank,dest=local,size=2,device=vdb testvme2 #using the not yet merged novaclient patch https://review.openstack.org/#/c/38815/. The request dict is as follows: '{"server": {"name": "testvme2", "imageRef": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "block_device_mapping_v2": [{"source_type": "image", "delete_on_termination": true, "boot_index": 0, "uuid": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "destination_type": "local"}, {"source_type": "blank", "delete_on_termination": true, "device_name": "vdb", "volume_size": "2", "destination_type": "local"}], "flavorRef": "1", "max_count": 1, "min_count": 1}}'
  [ndipanov at localhost devstack]$ nova list
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | ID                                   | Name     | Status | Task State | Power State | Networks         |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | 6c8a571c-3c1b-4fef-800e-0cecea927566 | testvme2 | ACTIVE | None       | Running     | private=10.0.0.2 |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  [ndipanov at localhost devstack]$ cd /opt/stack/data/nova/instances/_base/
  [ndipanov at localhost _base]$ ls -lah
  total 130M
  drwxrwxr-x. 2 ndipanov libvirtd 4.0K Aug 30 10:59 .
  drwxr-xr-x. 5 ndipanov root     4.0K Aug 30 10:59 ..
  -rw-rw-r--. 1 ndipanov libvirtd 4.8M Aug 30 10:59 65706cf4-0f63-4cf6-a8ee-a1dc447a6380
  -rw-rw-r--. 1 qemu     qemu      24M Aug 30 10:59 8bf383ae7171db9b882fc6e33eebf619896d67b7
  -rw-r--r--. 1 qemu     qemu     2.0G Aug 30 10:59 ephemeral_2_default
  -rw-rw-r--. 1 ndipanov libvirtd 3.6M Aug 30 10:59 fe478037-cd36-4517-b886-fd6e14d7462e

  We can see that the raw image was happily created by nova. completely
  disregarding the limitation.

  I have attached a proposed patch.

  This bug only affects current trunk as of the commit mentioned above.

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



From robert.clark at hp.com  Thu Sep  5 16:11:35 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Thu, 5 Sep 2013 16:11:35 +0000
Subject: [Openstack-security] OSSG meeting today cancelled.
Message-ID: <CE4E6BC7.2DD63%robert.clark@hp.com>

Hi Guys,

Myself, Bryan and Malini are all travelling during out meeting slot today so I think we should skip this weeks meeting.

Please feel free to take this time improving the security guide!

https://review.openstack.org/#/c/44550/
https://review.openstack.org/#/c/44563/

-Rob



From noloader at gmail.com  Thu Sep  5 16:24:48 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 5 Sep 2013 12:24:48 -0400
Subject: [Openstack-security] Security Guide and Introduction To SSL/TLS
In-Reply-To: <CAH8yC8n9oS1PUAsSfQ2e8wro5CbFpAc5fTR+e7KPXZjbX0NFMA@mail.gmail.com>
References: <CAH8yC8n9oS1PUAsSfQ2e8wro5CbFpAc5fTR+e7KPXZjbX0NFMA@mail.gmail.com>
Message-ID: <CAH8yC8kru2s2L+jX1d0QsB0Yx66r7n2JfsV60OdsmMmGeWxkSQ@mail.gmail.com>

Hi Rob,

Here's another one that will probably cause an uproar:

> "We recommend..." - a few other thoughts...
> ...
> * compression should be disabled if the threat model includes an
> attacker on the local LAN
Last one here and then I will leave you alone....

Compression breaks SSLv3, TLS 1.0, TLS 1.1, and TLS 1.2. We knew this
from the papers, but Wikipedia now states it so it must be true. See
the footnotes at
https://en.wikipedia.org/wiki/Transport_Layer_Security#Websites.

The guide mentions compression under Static Media (page 117.3/300),
but it does not offer general guidance.

Perhpas the guide should provide a clear warning about
using/supporting compression.

Jeff

On Fri, Aug 30, 2013 at 2:39 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> Hi All,
>
> I'm reading through the Security Guide. Its very good work. Great job.
>
> Around page 73 a discussion of PKI and SSL/TLS begins. The following
> comments may be helpful.
>
> Most of this is well known, but its not in the marketing literature.
> Its the darker side to PKI and SSL/TLS, and its covered in a number of
> security engineering books, like Peter Gutmann's Engineering Security
> (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf‎) or Ross Anderson's
> Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html).
>
> I think its important to realize the gaps in these systems because
> once the data is lost it cannot be recovered. And not everyone has
> shareholders to pass losses onto.
>
> ****
>
> "The core components of PKI are..." - the list is missing the Relying
> Party. This is important because of the legal behind most PKI
> deployments using the Internet profile (RFC 5280 and friends). There's
> a big disconnect between what the Relying Party is expecting, and what
> the CA is providing. In fact, the a CA's Certification Practice
> Statement (CPS) will likely disclaim nearly all warranties and shed
> all liabilities.
>
> The humor was not lost on me: we - the relying parties - use PKI and
> CAs to solve the key distribution problem. But the infrastructure does
> not deliver what we want, need, or expect in many cases.
>
> *****
>
> "Certification Authority (CA) - defines certificate policies,
> management, and issuance of certificates" - that's getting into
> details usually covered by the CPS. The CA is just a vending machine
> that accepts money and issues certificates.
>
> The details of policies, issuance, management and revocation are
> covered by the CPS. The CPS is legally binding; hence the reason the
> CA disclaims nearly all warranties and sheds all liabilities in its
> CPS.
>
> *****
>
> "We strongly recommend securing all services with Public Key
> Infrastructure (PKI)" - well, that can cut one of two ways. If an
> organization is running its own PKI and *not* using the Internet
> profile, then the recommendation is sound. That is, the organization
> is not conferring trust. However, its a big problem with the Internet
> profile.
>
> We've seen a continual stream of failures when using a PKI under the
> Internet profile. In this case, the users expect end-to-end security
> but they are not getting it. We are conferring too much trust to
> untrustworthy actors, and we have to take additional steps to use it
> safely.
>
> *****
>
> "It is recommended that the OpenStack cloud architect rely on distinct
> sets of CAs" - what precisely is being recommended? It sounds like
> OpenStack is recommending two distinct PKIs - one for internal use
> (management network and internal service communications) and one for
> external use (external users ... public cloud endpoints). I suppose
> most importantly: the trusted roots in the PKIs should not
> cross-pollinate (ignoring different policies, revocation, etc).
>
> I think the confusion (for me) lies in framing it around "sets of
> CAs". For example, the Internet profile has a large set of CAs in an
> implementation - too many to count. But it's one PKI (give or take)
> with a number of implementations (Browsers, VPN clients, etc). I think
> you're really talking about PKIs.
>
> *****
>
> "...and the trusted set of public CA providers for ..." - "trust" is a
> funny word. If the word is going to be used, then it needs to be
> defined. One of the better definitions I have seen is "X trusts Y to
> do Z". However, if: X-> Relying Party, Y -> CA, Z -> Identify Servers
> or Services, then the statement becomes "Relying Party trusts CA to
> Identify Identify Servers or Services". That's a reasonable
> definition, a reasonable expectation, but not what the CAs provide
> (and the CA disclaims nearly all warranties and sheds all liabilities
> in its CPS).
>
> *****
>
> "...allowing external users to verify the identity of the public cloud
> endpoints" - take caution here. This *is* about identifying a server
> or service, but the CAs don't make those claims and don't warrant
> that. About all that is required to issue a certificate is a credit
> card that is accepted for payment and an email address. About all we
> know - as relying parties - is money may have changed hands at some
> time in the past.
>
> Extended Validation certificates are no better. They simply restore CA
> profit levels to 1990s levels. They add nothing of technical value.
>
> *****
>
> "... operators may wish to seek the advice of industry leaders and
> vendors..." - the vendors will "PKI you harder" (to borrow from Dr.
> Gutmann). That's kind of like asking a drunk if he's drunk - you're
> probably not going to get a good answer.
>
> *****
>
> "The SSL/TLS and HTTP services within OpenStack are typically
> implemented using OpenSSL which has been proven to be fairly secure" -
> is the guide talking about SST/TLS, HTTPS, OpenSSL, or a combination
> of them? Also, I believe the folks at Red Hat use NSS as the
> underlying crypto gear, and not OpenSSL.
>
> *****
>
> "We recommend only using TLS v1.1 or v1.2, but suggest SSLv3 and
> TLSv1.0 may be used for compatibility" - I question the suggestion or
> recommendation of SSLv3. Its 2013, and there's no reason to support it
> any longer.
>
> From Loren Weith's "Differences Between SSLv2 SSLv3 and TLS" (circa 1996):
>
> * It is possible to cause a key exchange algorithm rollback if the SSL
> connection is only attempting to provide authenticity services and not
> encryption[10].
> * Replay attacks on anonymous key exchange.
> * Known plaintexts are available to an attacker in certain portions of
> the protocol[10].
> * Ad-hoc use of message authentication codes.
>
> *****
>
> "We recommend..." - a few other thoughts...
>
> * anonymous key agreements should be used for forward secrecy
> * if using anonymous key agreements, then session resumption should be disabled
> * if offered, secure renegotiaion should be provided (and might
> prohibit use of TLSv1.0)
> * compression should be disabled if the threat model includes an
> attacker on the local LAN
> * TLS-SRP and TLS-PSK should be preferred since they properly bind the
> encryption tunnel with the inner authentication mechanism
> * practice certificate or public key pinning
>
> TLS-SRP and TLS-PSK are especially appealing. The user and server
> either share the secret or they do not. If they share the secret, the
> protocol will execute and succeed; otherwise, the protocol will fail.
> There's no need to ask CAs or DNS security related questions - there's
> no need to confer trust.
>
> *****
>
> From the OWASP Cheat Sheet: "The use of self signed certificates is
> never acceptable." - that's bad advice, and the damn browsers are not
> making it any better. Thought experiment:
>
>   Plain HTTP - good, no protection, no user warnings or feed back
>   Self-Signed HTTPS - bad, opportunistic encryption, lots of warnings and flags
>   CA Signed HTTPS - good, encryption, green bar
>
> How is plaintext HTTP better than self signed HTTPS? When and where
> did the security-IQs suddenly drop?
>
> How is CA Signed HTTPS better than Self-Signed HTTPS? Recall the CA
> signed cert is obtained from a vending machine and provides no
> assurances or warranty for the relying party at the time of use. They
> are equivalent for our technical purposes (and worse in some
> instances).
>
> *****
>
> Sorry about the verbosity. Brevity is not one of my strong suites.
>
> Jeffrey Walton
> Baltimore, MD, US



From thierry.carrez+lp at gmail.com  Thu Sep  5 15:58:06 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 05 Sep 2013 15:58:06 -0000
Subject: [Openstack-security] [Bug 1076833] Re: Allow sql password to be
	configured separately from	sql_connection
References: <20121109020911.30587.95948.malonedeb@gac.canonical.com>
Message-ID: <20130905155808.19599.11120.launchpad@gac.canonical.com>

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

** Changed in: oslo
    Milestone: None => havana-3

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

Title:
  Allow sql password to be configured separately from sql_connection

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

Bug description:
  Can we use the nova's way to deal with sql connection value?
          LOG.debug(_('Full set of FLAGS:'))
          for flag in FLAGS:
              flag_get = FLAGS.get(flag, None)
              # hide flag contents from log if contains a password
              # should use secret flag when switch over to openstack-common
              if ("_password" in flag or "_key" in flag or
                      (flag == "sql_connection" and "mysql:" in flag_get)):
                  LOG.debug(_('%(flag)s : FLAG SET ') % locals())
              else:
                  LOG.debug('%(flag)s : %(flag_get)s' % locals())

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



From thierry.carrez+lp at gmail.com  Thu Sep  5 15:44:56 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 05 Sep 2013 15:44:56 -0000
Subject: [Openstack-security] [Bug 1210869] Re: Ratelimiting not working
References: <20130810211701.1599.34997.malonedeb@soybean.canonical.com>
Message-ID: <20130905154500.22855.30276.launchpad@wampee.canonical.com>

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

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

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

Title:
  Ratelimiting not working

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  Current master does not respect ratelimiting, since parsing of the  api-paste.ini is faulty. api-paste.ini configues user limiting by
  setting a line as follows (according to the code and unit test):
      
  user:<user-id>:(GET, *, ".*", 4, minute)
      
  This was passed to the Limiter as kwargs with "user" as a key.
  Thus multiple user limiting is not possible as well as extracting
  the id of the user was bound to fail, since we checked on the key
  with startswith("user:")
     
  An example config in the api-paste.ini has to look as follows:
  limits = (POST, "*", .*, 10, MINUTE)
  limits.<user-id1>:(GET, "*", .*, 4, minute)
  limits.<user-id2>:(GET, "*", .*, 2, minute)

  This can  be then tested by maybe trying to run "cinder list" with a
  configures user and see if the limit is respected.

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



From gerrit2 at review.openstack.org  Thu Sep  5 21:36:46 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 05 Sep 2013 21:36:46 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change If5ac48c5c889034c7b0ba24d977e8f4a14137a12
Message-ID: <E1VHhEM-0003Ec-Ch@review.openstack.org>


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

Log:
commit f7ea65ef3a33494e06c581d904debadf691e7b00
Author: Lance Bragstad <ldbragst at us.ibm.com>
Date:   Mon Jul 1 19:49:21 2013 +0000

    Address security concerns in PowerVM Driver
    
    Add two methods to common.py that will help check commands
    being sent to the remote VIOS system to prevent shell injection.
    
    fixes bug 1192971
    
    [SecurityImpact]
    
    Change-Id: If5ac48c5c889034c7b0ba24d977e8f4a14137a12




From malini.k.bhandaru at intel.com  Fri Sep  6 05:54:12 2013
From: malini.k.bhandaru at intel.com (Bhandaru, Malini K)
Date: Fri, 6 Sep 2013 05:54:12 +0000
Subject: [Openstack-security] Security Guide and Introduction To SSL/TLS
In-Reply-To: <CAH8yC8kru2s2L+jX1d0QsB0Yx66r7n2JfsV60OdsmMmGeWxkSQ@mail.gmail.com>
References: <CAH8yC8n9oS1PUAsSfQ2e8wro5CbFpAc5fTR+e7KPXZjbX0NFMA@mail.gmail.com>
 <CAH8yC8kru2s2L+jX1d0QsB0Yx66r7n2JfsV60OdsmMmGeWxkSQ@mail.gmail.com>
Message-ID: <EE6FFF4F6C34C84C8C98DD2414EEA47E53CE6EAA@FMSMSX102.amr.corp.intel.com>

Rob has an OSSN coming up on turning off compression with HTTPS Django/Horizon https://bugs.launchpad.net/ossn/+bug/1209250
Shall need to update guide in this regard.

Regards
Malini

-----Original Message-----
From: Jeffrey Walton [mailto:noloader at gmail.com] 
Sent: Thursday, September 05, 2013 9:25 AM
To: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Security Guide and Introduction To SSL/TLS

Hi Rob,

Here's another one that will probably cause an uproar:

> "We recommend..." - a few other thoughts...
> ...
> * compression should be disabled if the threat model includes an 
> attacker on the local LAN
Last one here and then I will leave you alone....

Compression breaks SSLv3, TLS 1.0, TLS 1.1, and TLS 1.2. We knew this from the papers, but Wikipedia now states it so it must be true. See the footnotes at https://en.wikipedia.org/wiki/Transport_Layer_Security#Websites.

The guide mentions compression under Static Media (page 117.3/300), but it does not offer general guidance.

Perhpas the guide should provide a clear warning about using/supporting compression.

Jeff

On Fri, Aug 30, 2013 at 2:39 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> Hi All,
>
> I'm reading through the Security Guide. Its very good work. Great job.
>
> Around page 73 a discussion of PKI and SSL/TLS begins. The following 
> comments may be helpful.
>
> Most of this is well known, but its not in the marketing literature.
> Its the darker side to PKI and SSL/TLS, and its covered in a number of 
> security engineering books, like Peter Gutmann's Engineering Security
> (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf‎) or Ross Anderson's 
> Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html).
>
> I think its important to realize the gaps in these systems because 
> once the data is lost it cannot be recovered. And not everyone has 
> shareholders to pass losses onto.
>
> ****
>
> "The core components of PKI are..." - the list is missing the Relying 
> Party. This is important because of the legal behind most PKI 
> deployments using the Internet profile (RFC 5280 and friends). There's 
> a big disconnect between what the Relying Party is expecting, and what 
> the CA is providing. In fact, the a CA's Certification Practice 
> Statement (CPS) will likely disclaim nearly all warranties and shed 
> all liabilities.
>
> The humor was not lost on me: we - the relying parties - use PKI and 
> CAs to solve the key distribution problem. But the infrastructure does 
> not deliver what we want, need, or expect in many cases.
>
> *****
>
> "Certification Authority (CA) - defines certificate policies, 
> management, and issuance of certificates" - that's getting into 
> details usually covered by the CPS. The CA is just a vending machine 
> that accepts money and issues certificates.
>
> The details of policies, issuance, management and revocation are 
> covered by the CPS. The CPS is legally binding; hence the reason the 
> CA disclaims nearly all warranties and sheds all liabilities in its 
> CPS.
>
> *****
>
> "We strongly recommend securing all services with Public Key 
> Infrastructure (PKI)" - well, that can cut one of two ways. If an 
> organization is running its own PKI and *not* using the Internet 
> profile, then the recommendation is sound. That is, the organization 
> is not conferring trust. However, its a big problem with the Internet 
> profile.
>
> We've seen a continual stream of failures when using a PKI under the 
> Internet profile. In this case, the users expect end-to-end security 
> but they are not getting it. We are conferring too much trust to 
> untrustworthy actors, and we have to take additional steps to use it 
> safely.
>
> *****
>
> "It is recommended that the OpenStack cloud architect rely on distinct 
> sets of CAs" - what precisely is being recommended? It sounds like 
> OpenStack is recommending two distinct PKIs - one for internal use 
> (management network and internal service communications) and one for 
> external use (external users ... public cloud endpoints). I suppose 
> most importantly: the trusted roots in the PKIs should not 
> cross-pollinate (ignoring different policies, revocation, etc).
>
> I think the confusion (for me) lies in framing it around "sets of 
> CAs". For example, the Internet profile has a large set of CAs in an 
> implementation - too many to count. But it's one PKI (give or take) 
> with a number of implementations (Browsers, VPN clients, etc). I think 
> you're really talking about PKIs.
>
> *****
>
> "...and the trusted set of public CA providers for ..." - "trust" is a 
> funny word. If the word is going to be used, then it needs to be 
> defined. One of the better definitions I have seen is "X trusts Y to 
> do Z". However, if: X-> Relying Party, Y -> CA, Z -> Identify Servers 
> or Services, then the statement becomes "Relying Party trusts CA to 
> Identify Identify Servers or Services". That's a reasonable 
> definition, a reasonable expectation, but not what the CAs provide 
> (and the CA disclaims nearly all warranties and sheds all liabilities 
> in its CPS).
>
> *****
>
> "...allowing external users to verify the identity of the public cloud 
> endpoints" - take caution here. This *is* about identifying a server 
> or service, but the CAs don't make those claims and don't warrant 
> that. About all that is required to issue a certificate is a credit 
> card that is accepted for payment and an email address. About all we 
> know - as relying parties - is money may have changed hands at some 
> time in the past.
>
> Extended Validation certificates are no better. They simply restore CA 
> profit levels to 1990s levels. They add nothing of technical value.
>
> *****
>
> "... operators may wish to seek the advice of industry leaders and 
> vendors..." - the vendors will "PKI you harder" (to borrow from Dr.
> Gutmann). That's kind of like asking a drunk if he's drunk - you're 
> probably not going to get a good answer.
>
> *****
>
> "The SSL/TLS and HTTP services within OpenStack are typically 
> implemented using OpenSSL which has been proven to be fairly secure" - 
> is the guide talking about SST/TLS, HTTPS, OpenSSL, or a combination 
> of them? Also, I believe the folks at Red Hat use NSS as the 
> underlying crypto gear, and not OpenSSL.
>
> *****
>
> "We recommend only using TLS v1.1 or v1.2, but suggest SSLv3 and
> TLSv1.0 may be used for compatibility" - I question the suggestion or 
> recommendation of SSLv3. Its 2013, and there's no reason to support it 
> any longer.
>
> From Loren Weith's "Differences Between SSLv2 SSLv3 and TLS" (circa 1996):
>
> * It is possible to cause a key exchange algorithm rollback if the SSL 
> connection is only attempting to provide authenticity services and not 
> encryption[10].
> * Replay attacks on anonymous key exchange.
> * Known plaintexts are available to an attacker in certain portions of 
> the protocol[10].
> * Ad-hoc use of message authentication codes.
>
> *****
>
> "We recommend..." - a few other thoughts...
>
> * anonymous key agreements should be used for forward secrecy
> * if using anonymous key agreements, then session resumption should be 
> disabled
> * if offered, secure renegotiaion should be provided (and might 
> prohibit use of TLSv1.0)
> * compression should be disabled if the threat model includes an 
> attacker on the local LAN
> * TLS-SRP and TLS-PSK should be preferred since they properly bind the 
> encryption tunnel with the inner authentication mechanism
> * practice certificate or public key pinning
>
> TLS-SRP and TLS-PSK are especially appealing. The user and server 
> either share the secret or they do not. If they share the secret, the 
> protocol will execute and succeed; otherwise, the protocol will fail.
> There's no need to ask CAs or DNS security related questions - there's 
> no need to confer trust.
>
> *****
>
> From the OWASP Cheat Sheet: "The use of self signed certificates is 
> never acceptable." - that's bad advice, and the damn browsers are not 
> making it any better. Thought experiment:
>
>   Plain HTTP - good, no protection, no user warnings or feed back
>   Self-Signed HTTPS - bad, opportunistic encryption, lots of warnings and flags
>   CA Signed HTTPS - good, encryption, green bar
>
> How is plaintext HTTP better than self signed HTTPS? When and where 
> did the security-IQs suddenly drop?
>
> How is CA Signed HTTPS better than Self-Signed HTTPS? Recall the CA 
> signed cert is obtained from a vending machine and provides no 
> assurances or warranty for the relying party at the time of use. They 
> are equivalent for our technical purposes (and worse in some 
> instances).
>
> *****
>
> Sorry about the verbosity. Brevity is not one of my strong suites.
>
> Jeffrey Walton
> Baltimore, MD, US

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

From 1218977 at bugs.launchpad.net  Tue Sep  3 12:35:52 2013
From: 1218977 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 03 Sep 2013 12:35:52 -0000
Subject: [Openstack-security] [Bug 1218977] Re: DOS by passing an ephemeral
	or swap of arbitrary	size
References: <20130830151826.9129.35686.malonedeb@soybean.canonical.com>
Message-ID: <20130903123553.25535.22137.malone@chaenomeles.canonical.com>

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

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

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

Title:
  DOS by passing an ephemeral or swap of arbitrary size

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  Due to a previous bug that was never caught and the fact that we can
  now pass ephemeral and block devices through the API, it is possible
  to ask nova to create an arbitrarily large ephemeral block device -
  which nova will happily do (and by default make it raw).

  The bug was introduced in commit
  0ef7e15e225efcce3e02098cb1d57f9f40181f82 as before that commit the
  ephemeral device size will be defaulted to whatever was in the
  instance_type - due to a bug this defaulting was not done anymore (see
  compute.api.API._update_block_device_mapping).

  Steps to reproduce:

  ndipanov at localhost devstack]$ nova flavor-show 1
  +----------------------------+---------+
  | Property                   | Value   |
  +----------------------------+---------+
  | name                       | m1.tiny |
  | ram                        | 512     |
  | OS-FLV-DISABLED:disabled   | False   |
  | vcpus                      | 1       |
  | extra_specs                | {}      |
  | swap                       |         |
  | os-flavor-access:is_public | True    |
  | rxtx_factor                | 1.0     |
  | OS-FLV-EXT-DATA:ephemeral  | 0       | <--- Ephemeral is 0
  | disk                       | 1       |
  | id                         | 1       |
  +----------------------------+---------+
  [ndipanov at localhost devstack]$ nova --debug boot --image 308f190c-d2f7-44fe-9b6d-7a28e2e2aa64 --flavor 1 --block-device source=blank,dest=local,size=2,device=vdb testvme2 #using the not yet merged novaclient patch https://review.openstack.org/#/c/38815/. The request dict is as follows: '{"server": {"name": "testvme2", "imageRef": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "block_device_mapping_v2": [{"source_type": "image", "delete_on_termination": true, "boot_index": 0, "uuid": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "destination_type": "local"}, {"source_type": "blank", "delete_on_termination": true, "device_name": "vdb", "volume_size": "2", "destination_type": "local"}], "flavorRef": "1", "max_count": 1, "min_count": 1}}'
  [ndipanov at localhost devstack]$ nova list
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | ID                                   | Name     | Status | Task State | Power State | Networks         |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | 6c8a571c-3c1b-4fef-800e-0cecea927566 | testvme2 | ACTIVE | None       | Running     | private=10.0.0.2 |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  [ndipanov at localhost devstack]$ cd /opt/stack/data/nova/instances/_base/
  [ndipanov at localhost _base]$ ls -lah
  total 130M
  drwxrwxr-x. 2 ndipanov libvirtd 4.0K Aug 30 10:59 .
  drwxr-xr-x. 5 ndipanov root     4.0K Aug 30 10:59 ..
  -rw-rw-r--. 1 ndipanov libvirtd 4.8M Aug 30 10:59 65706cf4-0f63-4cf6-a8ee-a1dc447a6380
  -rw-rw-r--. 1 qemu     qemu      24M Aug 30 10:59 8bf383ae7171db9b882fc6e33eebf619896d67b7
  -rw-r--r--. 1 qemu     qemu     2.0G Aug 30 10:59 ephemeral_2_default
  -rw-rw-r--. 1 ndipanov libvirtd 3.6M Aug 30 10:59 fe478037-cd36-4517-b886-fd6e14d7462e

  We can see that the raw image was happily created by nova. completely
  disregarding the limitation.

  I have attached a proposed patch.

  This bug only affects current trunk as of the commit mentioned above.

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



From 1218977 at bugs.launchpad.net  Tue Sep  3 15:53:40 2013
From: 1218977 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 03 Sep 2013 15:53:40 -0000
Subject: [Openstack-security] [Bug 1218977] Re: DOS by passing an ephemeral
	or swap of arbitrary	size
References: <20130830151826.9129.35686.malonedeb@soybean.canonical.com>
Message-ID: <20130903155340.29940.48841.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/44864
Committed: http://github.com/openstack/nova/commit/fcf712ec3538d4e07e0c0da6fadcd4f2ea7747fc
Submitter: Jenkins
Branch:    master

commit fcf712ec3538d4e07e0c0da6fadcd4f2ea7747fc
Author: Nikola Dipanov <ndipanov at redhat.com>
Date:   Fri Aug 30 16:40:43 2013 +0200

    Check ephemeral and swap size in the API
    
    Validate that ephemeral and swap disks passed in trough the API are
    within size limits for the given instance type. The validation is done
    in the API layer.
    
    Closes-bug #1218977
    
    Change-Id: I96c6e651e4b221313c39dfc41e79d536585fb955


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

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

Title:
  DOS by passing an ephemeral or swap of arbitrary size

Status in OpenStack Compute (Nova):
  Fix Committed

Bug description:
  Due to a previous bug that was never caught and the fact that we can
  now pass ephemeral and block devices through the API, it is possible
  to ask nova to create an arbitrarily large ephemeral block device -
  which nova will happily do (and by default make it raw).

  The bug was introduced in commit
  0ef7e15e225efcce3e02098cb1d57f9f40181f82 as before that commit the
  ephemeral device size will be defaulted to whatever was in the
  instance_type - due to a bug this defaulting was not done anymore (see
  compute.api.API._update_block_device_mapping).

  Steps to reproduce:

  ndipanov at localhost devstack]$ nova flavor-show 1
  +----------------------------+---------+
  | Property                   | Value   |
  +----------------------------+---------+
  | name                       | m1.tiny |
  | ram                        | 512     |
  | OS-FLV-DISABLED:disabled   | False   |
  | vcpus                      | 1       |
  | extra_specs                | {}      |
  | swap                       |         |
  | os-flavor-access:is_public | True    |
  | rxtx_factor                | 1.0     |
  | OS-FLV-EXT-DATA:ephemeral  | 0       | <--- Ephemeral is 0
  | disk                       | 1       |
  | id                         | 1       |
  +----------------------------+---------+
  [ndipanov at localhost devstack]$ nova --debug boot --image 308f190c-d2f7-44fe-9b6d-7a28e2e2aa64 --flavor 1 --block-device source=blank,dest=local,size=2,device=vdb testvme2 #using the not yet merged novaclient patch https://review.openstack.org/#/c/38815/. The request dict is as follows: '{"server": {"name": "testvme2", "imageRef": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "block_device_mapping_v2": [{"source_type": "image", "delete_on_termination": true, "boot_index": 0, "uuid": "308f190c-d2f7-44fe-9b6d-7a28e2e2aa64", "destination_type": "local"}, {"source_type": "blank", "delete_on_termination": true, "device_name": "vdb", "volume_size": "2", "destination_type": "local"}], "flavorRef": "1", "max_count": 1, "min_count": 1}}'
  [ndipanov at localhost devstack]$ nova list
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | ID                                   | Name     | Status | Task State | Power State | Networks         |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  | 6c8a571c-3c1b-4fef-800e-0cecea927566 | testvme2 | ACTIVE | None       | Running     | private=10.0.0.2 |
  +--------------------------------------+----------+--------+------------+-------------+------------------+
  [ndipanov at localhost devstack]$ cd /opt/stack/data/nova/instances/_base/
  [ndipanov at localhost _base]$ ls -lah
  total 130M
  drwxrwxr-x. 2 ndipanov libvirtd 4.0K Aug 30 10:59 .
  drwxr-xr-x. 5 ndipanov root     4.0K Aug 30 10:59 ..
  -rw-rw-r--. 1 ndipanov libvirtd 4.8M Aug 30 10:59 65706cf4-0f63-4cf6-a8ee-a1dc447a6380
  -rw-rw-r--. 1 qemu     qemu      24M Aug 30 10:59 8bf383ae7171db9b882fc6e33eebf619896d67b7
  -rw-r--r--. 1 qemu     qemu     2.0G Aug 30 10:59 ephemeral_2_default
  -rw-rw-r--. 1 ndipanov libvirtd 3.6M Aug 30 10:59 fe478037-cd36-4517-b886-fd6e14d7462e

  We can see that the raw image was happily created by nova. completely
  disregarding the limitation.

  I have attached a proposed patch.

  This bug only affects current trunk as of the commit mentioned above.

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



From jon at jonproulx.com  Fri Sep  6 01:17:22 2013
From: jon at jonproulx.com (Jon Proulx)
Date: Fri, 06 Sep 2013 01:17:22 -0000
Subject: [Openstack-security] [Bug 1210409] Re: Horizon Dashboard
	Installation documentation should	use secure defaults
References: <20130809064348.15935.73795.malonedeb@gac.canonical.com>
Message-ID: <20130906011724.19469.69098.launchpad@gac.canonical.com>

** Changed in: openstack-manuals
     Assignee: (unassigned) => Jon Proulx (jproulx)

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

Title:
  Horizon Dashboard Installation documentation should use secure
  defaults

Status in OpenStack Manuals:
  Triaged

Bug description:
  The documentation for installing Horizon includes a section on
  deploying it behind SSL.

  A recent OSSN highlighted that if you need to deploy Horizon securely
  it really should be configured with HTTP Strict Transport Security
  (HSTS) by default. This OSSN demonstrates the configuration but I
  don't have a horizon setup to test it against -
  https://bugs.launchpad.net/ossn/+bug/1191050

  Similarly, there's an OSSN recommending that Horizon issues cookies
  with Secure attributes, which would avoid it travelling over HTTP and
  protects against a range of attacks:
  https://bugs.launchpad.net/ossn/+bug/1191051

  As the horizon documentation already has guidance on securing the
  connection it should really follow these best practices.

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



From xianghui at cn.ibm.com  Fri Sep  6 07:20:04 2013
From: xianghui at cn.ibm.com (Xiang Hui)
Date: Fri, 06 Sep 2013 07:20:04 -0000
Subject: [Openstack-security] [Bug 1221564] [NEW] Didn't associate a
	security-group to instances
References: <20130906072005.20637.36919.malonedeb@soybean.canonical.com>
Message-ID: <20130906072005.20637.36919.malonedeb@soybean.canonical.com>

Public bug reported:

Define a WikiDatabaseSecurityGroup as below :
"WikiDatabaseSecurityGroup" : {
      "Type" : "AWS::EC2::SecurityGroup",
      "Properties" : {
        "GroupDescription" : "Enable HTTP access via port 80 plus SSH access",
        "SecurityGroupIngress" : [
          {"IpProtocol" : "icmp", "FromPort" : "-1", "ToPort" : "-1", "CidrIp" : "0.0.0.0/0"},
          {"IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0"},
          {"IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : "0.0.0.0/0"}
        ]
      }
    },

refer it to instance properties as "SecurityGroups" : [ {"Ref" : "WikiDatabaseSecurityGroup"} ],
in template WordPress_2_Instances_With_EBS_EIP.template.

But when the instance is spawned, seems the security_group of this
instance is not "WikiDatabaseSecurityGroup", but the "default" one.

[root at oc2603148815 xianghui]# nova show wordpress_1-WikiDatabase-kpjsht332enl
+--------------------------------------+------------------------------------------------------------+
| Property                             | Value                                                      |
+--------------------------------------+------------------------------------------------------------+
| status                               | ACTIVE                                                     |
| updated                              | 2013-08-20T09:32:06Z                                       |
| OS-EXT-STS:task_state                | None                                                       |
| OS-EXT-SRV-ATTR:host                 | oc2603148815.ibm.com                                       |
| key_name                             | userkey                                                    |
| image                                | F17-x86_64-cfntools (53181c83-4e24-4888-be88-1f9e7ed4877c) |
| hostId                               | 5c331878f9858b022f7d92f7f74714f1d58eef066dd6768a77e26264   |
| OS-EXT-STS:vm_state                  | active                                                     |
| OS-EXT-SRV-ATTR:instance_name        | instance-0000008d                                          |
| OS-SRV-USG:launched_at               | 2013-08-20T09:32:06.000000                                 |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | oc2603148815.ibm.com                                       |
| flavor                               | m1.small (2)                                               |
| id                                   | c7e59830-8ca7-43a3-8c17-d670c0263876                       |
| security_groups                      | [{u'name': u'default'}]                                    |
| OS-SRV-USG:terminated_at             | None                                                       |
| vlan-70 network                      | 70.0.0.20, 192.168.12.19                                   |
| user_id                              | 22c367eb5eb34846acc0a2c0c4836f93                           |
| name                                 | wordpress_1-WikiDatabase-kpjsht332enl                      |
| created                              | 2013-08-20T09:31:52Z                                       |
| tenant_id                            | b21a96e16c3c438caab4a27a1f58a5b8                           |
| OS-DCF:diskConfig                    | MANUAL                                                     |
| metadata                             | {}                                                         |
| os-extended-volumes:volumes_attached | [{u'id': u'e190341f-4007-43ce-8099-2e4be1e606da'}]         |
| accessIPv4                           |                                                            |
| accessIPv6                           |                                                            |
| progress                             | 0                                                          |
| OS-EXT-STS:power_state               | 1                                                          |
| OS-EXT-AZ:availability_zone          | nova                                                       |
| config_drive                         |                                                            |
+--------------------------------------+------------------------------------------------------------+

By doing some investigation, the root cause has been found :
 
instance port will be created by calling quantumclient.create_port in /heat/engine/resources/instance.py , 
but the security_group resource created by heat is not passed as a parameter.

** Affects: heat
     Importance: Undecided
     Assignee: Xiang Hui (xianghui)
         Status: New


** Tags: group security

** Changed in: heat
     Assignee: (unassigned) => Xiang Hui (xianghui)

** Tags added: group security

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

Title:
  Didn't associate a security-group to instances

Status in Orchestration API (Heat):
  New

Bug description:
  Define a WikiDatabaseSecurityGroup as below :
  "WikiDatabaseSecurityGroup" : {
        "Type" : "AWS::EC2::SecurityGroup",
        "Properties" : {
          "GroupDescription" : "Enable HTTP access via port 80 plus SSH access",
          "SecurityGroupIngress" : [
            {"IpProtocol" : "icmp", "FromPort" : "-1", "ToPort" : "-1", "CidrIp" : "0.0.0.0/0"},
            {"IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0"},
            {"IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : "0.0.0.0/0"}
          ]
        }
      },

  refer it to instance properties as "SecurityGroups" : [ {"Ref" : "WikiDatabaseSecurityGroup"} ],
  in template WordPress_2_Instances_With_EBS_EIP.template.

  But when the instance is spawned, seems the security_group of this
  instance is not "WikiDatabaseSecurityGroup", but the "default" one.

  [root at oc2603148815 xianghui]# nova show wordpress_1-WikiDatabase-kpjsht332enl
  +--------------------------------------+------------------------------------------------------------+
  | Property                             | Value                                                      |
  +--------------------------------------+------------------------------------------------------------+
  | status                               | ACTIVE                                                     |
  | updated                              | 2013-08-20T09:32:06Z                                       |
  | OS-EXT-STS:task_state                | None                                                       |
  | OS-EXT-SRV-ATTR:host                 | oc2603148815.ibm.com                                       |
  | key_name                             | userkey                                                    |
  | image                                | F17-x86_64-cfntools (53181c83-4e24-4888-be88-1f9e7ed4877c) |
  | hostId                               | 5c331878f9858b022f7d92f7f74714f1d58eef066dd6768a77e26264   |
  | OS-EXT-STS:vm_state                  | active                                                     |
  | OS-EXT-SRV-ATTR:instance_name        | instance-0000008d                                          |
  | OS-SRV-USG:launched_at               | 2013-08-20T09:32:06.000000                                 |
  | OS-EXT-SRV-ATTR:hypervisor_hostname  | oc2603148815.ibm.com                                       |
  | flavor                               | m1.small (2)                                               |
  | id                                   | c7e59830-8ca7-43a3-8c17-d670c0263876                       |
  | security_groups                      | [{u'name': u'default'}]                                    |
  | OS-SRV-USG:terminated_at             | None                                                       |
  | vlan-70 network                      | 70.0.0.20, 192.168.12.19                                   |
  | user_id                              | 22c367eb5eb34846acc0a2c0c4836f93                           |
  | name                                 | wordpress_1-WikiDatabase-kpjsht332enl                      |
  | created                              | 2013-08-20T09:31:52Z                                       |
  | tenant_id                            | b21a96e16c3c438caab4a27a1f58a5b8                           |
  | OS-DCF:diskConfig                    | MANUAL                                                     |
  | metadata                             | {}                                                         |
  | os-extended-volumes:volumes_attached | [{u'id': u'e190341f-4007-43ce-8099-2e4be1e606da'}]         |
  | accessIPv4                           |                                                            |
  | accessIPv6                           |                                                            |
  | progress                             | 0                                                          |
  | OS-EXT-STS:power_state               | 1                                                          |
  | OS-EXT-AZ:availability_zone          | nova                                                       |
  | config_drive                         |                                                            |
  +--------------------------------------+------------------------------------------------------------+

  By doing some investigation, the root cause has been found :
   
  instance port will be created by calling quantumclient.create_port in /heat/engine/resources/instance.py , 
  but the security_group resource created by heat is not passed as a parameter.

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



From 1221564 at bugs.launchpad.net  Fri Sep  6 13:06:33 2013
From: 1221564 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 06 Sep 2013 13:06:33 -0000
Subject: [Openstack-security] [Bug 1221564] Re: Didn't associate a
	security-group to instances
References: <20130906072005.20637.36919.malonedeb@soybean.canonical.com>
Message-ID: <20130906130634.23087.16441.malone@gac.canonical.com>

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

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

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

Title:
  Didn't associate a security-group to instances

Status in Orchestration API (Heat):
  In Progress

Bug description:
  Define a WikiDatabaseSecurityGroup as below :
  "WikiDatabaseSecurityGroup" : {
        "Type" : "AWS::EC2::SecurityGroup",
        "Properties" : {
          "GroupDescription" : "Enable HTTP access via port 80 plus SSH access",
          "SecurityGroupIngress" : [
            {"IpProtocol" : "icmp", "FromPort" : "-1", "ToPort" : "-1", "CidrIp" : "0.0.0.0/0"},
            {"IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0"},
            {"IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : "0.0.0.0/0"}
          ]
        }
      },

  refer it to instance properties as "SecurityGroups" : [ {"Ref" : "WikiDatabaseSecurityGroup"} ],
  in template WordPress_2_Instances_With_EBS_EIP.template.

  But when the instance is spawned, seems the security_group of this
  instance is not "WikiDatabaseSecurityGroup", but the "default" one.

  [root at oc2603148815 xianghui]# nova show wordpress_1-WikiDatabase-kpjsht332enl
  +--------------------------------------+------------------------------------------------------------+
  | Property                             | Value                                                      |
  +--------------------------------------+------------------------------------------------------------+
  | status                               | ACTIVE                                                     |
  | updated                              | 2013-08-20T09:32:06Z                                       |
  | OS-EXT-STS:task_state                | None                                                       |
  | OS-EXT-SRV-ATTR:host                 | oc2603148815.ibm.com                                       |
  | key_name                             | userkey                                                    |
  | image                                | F17-x86_64-cfntools (53181c83-4e24-4888-be88-1f9e7ed4877c) |
  | hostId                               | 5c331878f9858b022f7d92f7f74714f1d58eef066dd6768a77e26264   |
  | OS-EXT-STS:vm_state                  | active                                                     |
  | OS-EXT-SRV-ATTR:instance_name        | instance-0000008d                                          |
  | OS-SRV-USG:launched_at               | 2013-08-20T09:32:06.000000                                 |
  | OS-EXT-SRV-ATTR:hypervisor_hostname  | oc2603148815.ibm.com                                       |
  | flavor                               | m1.small (2)                                               |
  | id                                   | c7e59830-8ca7-43a3-8c17-d670c0263876                       |
  | security_groups                      | [{u'name': u'default'}]                                    |
  | OS-SRV-USG:terminated_at             | None                                                       |
  | vlan-70 network                      | 70.0.0.20, 192.168.12.19                                   |
  | user_id                              | 22c367eb5eb34846acc0a2c0c4836f93                           |
  | name                                 | wordpress_1-WikiDatabase-kpjsht332enl                      |
  | created                              | 2013-08-20T09:31:52Z                                       |
  | tenant_id                            | b21a96e16c3c438caab4a27a1f58a5b8                           |
  | OS-DCF:diskConfig                    | MANUAL                                                     |
  | metadata                             | {}                                                         |
  | os-extended-volumes:volumes_attached | [{u'id': u'e190341f-4007-43ce-8099-2e4be1e606da'}]         |
  | accessIPv4                           |                                                            |
  | accessIPv6                           |                                                            |
  | progress                             | 0                                                          |
  | OS-EXT-STS:power_state               | 1                                                          |
  | OS-EXT-AZ:availability_zone          | nova                                                       |
  | config_drive                         |                                                            |
  +--------------------------------------+------------------------------------------------------------+

  By doing some investigation, the root cause has been found :
   
  instance port will be created by calling quantumclient.create_port in /heat/engine/resources/instance.py , 
  but the security_group resource created by heat is not passed as a parameter.

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



From 1188189 at bugs.launchpad.net  Fri Sep  6 14:59:20 2013
From: 1188189 at bugs.launchpad.net (Dolph Mathews)
Date: Fri, 06 Sep 2013 14:59:20 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
	communication fails to check	certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130906145920.18516.70979.malone@wampee.canonical.com>

Jamie- can you provide a link to your patch/review here?

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

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

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

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

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

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

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

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

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



From jon at jonproulx.com  Fri Sep  6 19:51:03 2013
From: jon at jonproulx.com (Jon Proulx)
Date: Fri, 06 Sep 2013 19:51:03 -0000
Subject: [Openstack-security] [Bug 1210409] Re: Horizon Dashboard
	Installation documentation should	use secure defaults
References: <20130809064348.15935.73795.malonedeb@gac.canonical.com>
Message-ID: <20130906195103.19012.10587.malone@wampee.canonical.com>

This should also be included in the Ubuntu install guide
http://docs.openstack.org/grizzly/openstack-compute/install/apt/content
/installing-openstack-dashboard.html

With some luck the examples affected will be the same in both since it's
not really distro specific and will be or can be made to be a single
source included in both locations...

** Changed in: openstack-manuals
       Status: Triaged => In Progress

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

Title:
  Horizon Dashboard Installation documentation should use secure
  defaults

Status in OpenStack Manuals:
  In Progress

Bug description:
  The documentation for installing Horizon includes a section on
  deploying it behind SSL.

  A recent OSSN highlighted that if you need to deploy Horizon securely
  it really should be configured with HTTP Strict Transport Security
  (HSTS) by default. This OSSN demonstrates the configuration but I
  don't have a horizon setup to test it against -
  https://bugs.launchpad.net/ossn/+bug/1191050

  Similarly, there's an OSSN recommending that Horizon issues cookies
  with Secure attributes, which would avoid it travelling over HTTP and
  protects against a range of attacks:
  https://bugs.launchpad.net/ossn/+bug/1191051

  As the horizon documentation already has guidance on securing the
  connection it should really follow these best practices.

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



From 1210409 at bugs.launchpad.net  Fri Sep  6 20:31:07 2013
From: 1210409 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 06 Sep 2013 20:31:07 -0000
Subject: [Openstack-security] [Bug 1210409] Fix proposed to
	openstack-manuals (master)
References: <20130809064348.15935.73795.malonedeb@gac.canonical.com>
Message-ID: <20130906203107.20399.94637.malone@soybean.canonical.com>

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

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

Title:
  Horizon Dashboard Installation documentation should use secure
  defaults

Status in OpenStack Manuals:
  In Progress

Bug description:
  The documentation for installing Horizon includes a section on
  deploying it behind SSL.

  A recent OSSN highlighted that if you need to deploy Horizon securely
  it really should be configured with HTTP Strict Transport Security
  (HSTS) by default. This OSSN demonstrates the configuration but I
  don't have a horizon setup to test it against -
  https://bugs.launchpad.net/ossn/+bug/1191050

  Similarly, there's an OSSN recommending that Horizon issues cookies
  with Secure attributes, which would avoid it travelling over HTTP and
  protects against a range of attacks:
  https://bugs.launchpad.net/ossn/+bug/1191051

  As the horizon documentation already has guidance on securing the
  connection it should really follow these best practices.

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



From jlennox at redhat.com  Mon Sep  9 00:05:00 2013
From: jlennox at redhat.com (Jamie Lennox)
Date: Mon, 09 Sep 2013 00:05:00 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
	communication fails to check	certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130909000500.25879.54265.malone@chaenomeles.canonical.com>

It appears that the new Partial-Bug syntax doesn't do an automatic link
anymore.

python-keystoneclient: Replace HttpConnection in auth_token with Requests
https://review.openstack.org/#/c/34161/

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

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

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

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

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

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

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

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

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



From fungi at yuggoth.org  Mon Sep  9 19:02:38 2013
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 09 Sep 2013 19:02:38 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
	communication fails to check	certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130909190238.9493.1926.malone@wampee.canonical.com>

It only adds the review link on patchset #1 (to avoid spamming bug
subscribers with comments). You didn't mention this bug in your commit
message until patchset #3 of that review.

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

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

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

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

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

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

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

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

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



From gerrit2 at review.openstack.org  Tue Sep 10 17:05:59 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 10 Sep 2013 17:05:59 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VJRO3-00006u-UT@review.openstack.org>


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

Log:
commit da051b9d12568c55dd7ce103a68cd0c374eeff75
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From gerrit2 at review.openstack.org  Tue Sep 10 21:02:58 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 10 Sep 2013 21:02:58 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VJV5O-0006NY-Hx@review.openstack.org>


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

Log:
commit c5fc8b759d1ce31eed43e904bf0e83fc6bc60dd9
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Sep 10 17:01:08 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From gerrit2 at review.openstack.org  Wed Sep 11 10:44:24 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 11 Sep 2013 10:44:24 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b
Message-ID: <E1VJhuK-0005wA-Q6@review.openstack.org>


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

Log:
commit cf5645fdee2dfb9fc0e34b0355fa8c1e97758ced
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Sep 10 17:01:08 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: Ia6f4c69e699e68065c0f767e769cd0a6f5cc623b




From 1210409 at bugs.launchpad.net  Sun Sep  8 22:13:16 2013
From: 1210409 at bugs.launchpad.net (OpenStack Infra)
Date: Sun, 08 Sep 2013 22:13:16 -0000
Subject: [Openstack-security] [Bug 1210409] Re: Horizon Dashboard
	Installation documentation should	use secure defaults
References: <20130809064348.15935.73795.malonedeb@gac.canonical.com>
Message-ID: <20130908221316.23087.72738.malone@gac.canonical.com>

Reviewed:  https://review.openstack.org/45491
Committed: http://github.com/openstack/openstack-manuals/commit/d5bcc13a00869723e86973a26c67c8de92d79c6a
Submitter: Jenkins
Branch:    master

commit d5bcc13a00869723e86973a26c67c8de92d79c6a
Author: Jon Proulx <jon at jonproulx.com>
Date:   Fri Sep 6 16:25:50 2013 -0400

    Add HSTS and cookie security to dashboard example config
    
    Adds reccomended settings from
    https://bugs.launchpad.net/ossn/+bug/1191050
    https://bugs.launchpad.net/ossn/+bug/1191051
    http://docs.openstack.org/developer/horizon/topics/deployment.html#secure-site-recommendations
    to the configuration instructions for HTTPS
    
    Also includes some gramatical and formating fixes
    
    Affects install guides, compute admin guide, and configuration guide
    
    Note the content is in two nearly identical locations
    https://bugs.launchpad.net/openstack-manuals/+bug/1222006
    has been opened for the organizational bug.
    This fixes the content of both locations identically.
    
    Change-Id: I1b41b3bee0d884ca3d29a1f2667e5b55070131cb
    Closes-Bug: #1210409


** Changed in: openstack-manuals
       Status: In Progress => Fix Released

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

Title:
  Horizon Dashboard Installation documentation should use secure
  defaults

Status in OpenStack Manuals:
  Fix Released

Bug description:
  The documentation for installing Horizon includes a section on
  deploying it behind SSL.

  A recent OSSN highlighted that if you need to deploy Horizon securely
  it really should be configured with HTTP Strict Transport Security
  (HSTS) by default. This OSSN demonstrates the configuration but I
  don't have a horizon setup to test it against -
  https://bugs.launchpad.net/ossn/+bug/1191050

  Similarly, there's an OSSN recommending that Horizon issues cookies
  with Secure attributes, which would avoid it travelling over HTTP and
  protects against a range of attacks:
  https://bugs.launchpad.net/ossn/+bug/1191051

  As the horizon documentation already has guidance on securing the
  connection it should really follow these best practices.

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



From skywalker.nick at gmail.com  Tue Sep 10 00:41:22 2013
From: skywalker.nick at gmail.com (Li Ma)
Date: Tue, 10 Sep 2013 00:41:22 -0000
Subject: [Openstack-security] [Bug 1175905] Re: passlib failure to sanitize
	env variables	PASSLIB_MAX_PASSWORD_SIZE
References: <20130503065127.14958.89453.malonedeb@gac.canonical.com>
Message-ID: <20130910004124.20576.18719.launchpad@chaenomeles.canonical.com>

** Changed in: keystone
     Assignee: Li Ma (nick-ma-b) => (unassigned)

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

Title:
  passlib failure to sanitize env variables PASSLIB_MAX_PASSWORD_SIZE

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  Grant Murphy originally reported:

  * Usage of passlib

    The keystone server does not appear to sanitize the environment when 
    starting. This means that an unintended value can be set for 
    PASSLIB_MAX_PASSWORD_SIZE. Which will overwrite the default value of 
    4096 and potentially cause an unhandled passlib.exc.PasswordSizeError.  
    We should ensure sensible defaults are applied here prior to loading passlib.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From shardy at redhat.com  Tue Sep 10 08:51:34 2013
From: shardy at redhat.com (Steven Hardy)
Date: Tue, 10 Sep 2013 08:51:34 -0000
Subject: [Openstack-security] [Bug 1221564] Re: Didn't associate a
	security-group to instances
References: <20130906072005.20637.36919.malonedeb@soybean.canonical.com>
Message-ID: <20130910085136.25599.23992.launchpad@gac.canonical.com>

** Changed in: heat
    Milestone: None => havana-rc1

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

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

Title:
  Didn't associate a security-group to instances

Status in Orchestration API (Heat):
  In Progress

Bug description:
  Define a WikiDatabaseSecurityGroup as below :
  "WikiDatabaseSecurityGroup" : {
        "Type" : "AWS::EC2::SecurityGroup",
        "Properties" : {
          "GroupDescription" : "Enable HTTP access via port 80 plus SSH access",
          "SecurityGroupIngress" : [
            {"IpProtocol" : "icmp", "FromPort" : "-1", "ToPort" : "-1", "CidrIp" : "0.0.0.0/0"},
            {"IpProtocol" : "tcp", "FromPort" : "80", "ToPort" : "80", "CidrIp" : "0.0.0.0/0"},
            {"IpProtocol" : "tcp", "FromPort" : "22", "ToPort" : "22", "CidrIp" : "0.0.0.0/0"}
          ]
        }
      },

  refer it to instance properties as "SecurityGroups" : [ {"Ref" : "WikiDatabaseSecurityGroup"} ],
  in template WordPress_2_Instances_With_EBS_EIP.template.

  But when the instance is spawned, seems the security_group of this
  instance is not "WikiDatabaseSecurityGroup", but the "default" one.

  [root at oc2603148815 xianghui]# nova show wordpress_1-WikiDatabase-kpjsht332enl
  +--------------------------------------+------------------------------------------------------------+
  | Property                             | Value                                                      |
  +--------------------------------------+------------------------------------------------------------+
  | status                               | ACTIVE                                                     |
  | updated                              | 2013-08-20T09:32:06Z                                       |
  | OS-EXT-STS:task_state                | None                                                       |
  | OS-EXT-SRV-ATTR:host                 | oc2603148815.ibm.com                                       |
  | key_name                             | userkey                                                    |
  | image                                | F17-x86_64-cfntools (53181c83-4e24-4888-be88-1f9e7ed4877c) |
  | hostId                               | 5c331878f9858b022f7d92f7f74714f1d58eef066dd6768a77e26264   |
  | OS-EXT-STS:vm_state                  | active                                                     |
  | OS-EXT-SRV-ATTR:instance_name        | instance-0000008d                                          |
  | OS-SRV-USG:launched_at               | 2013-08-20T09:32:06.000000                                 |
  | OS-EXT-SRV-ATTR:hypervisor_hostname  | oc2603148815.ibm.com                                       |
  | flavor                               | m1.small (2)                                               |
  | id                                   | c7e59830-8ca7-43a3-8c17-d670c0263876                       |
  | security_groups                      | [{u'name': u'default'}]                                    |
  | OS-SRV-USG:terminated_at             | None                                                       |
  | vlan-70 network                      | 70.0.0.20, 192.168.12.19                                   |
  | user_id                              | 22c367eb5eb34846acc0a2c0c4836f93                           |
  | name                                 | wordpress_1-WikiDatabase-kpjsht332enl                      |
  | created                              | 2013-08-20T09:31:52Z                                       |
  | tenant_id                            | b21a96e16c3c438caab4a27a1f58a5b8                           |
  | OS-DCF:diskConfig                    | MANUAL                                                     |
  | metadata                             | {}                                                         |
  | os-extended-volumes:volumes_attached | [{u'id': u'e190341f-4007-43ce-8099-2e4be1e606da'}]         |
  | accessIPv4                           |                                                            |
  | accessIPv6                           |                                                            |
  | progress                             | 0                                                          |
  | OS-EXT-STS:power_state               | 1                                                          |
  | OS-EXT-AZ:availability_zone          | nova                                                       |
  | config_drive                         |                                                            |
  +--------------------------------------+------------------------------------------------------------+

  By doing some investigation, the root cause has been found :
   
  instance port will be created by calling quantumclient.create_port in /heat/engine/resources/instance.py , 
  but the security_group resource created by heat is not passed as a parameter.

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



From gerrit2 at review.openstack.org  Wed Sep 11 16:09:20 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 11 Sep 2013 16:09:20 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VJmym-0007gc-NZ@review.openstack.org>


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

Log:
commit ad8c3d7a2dc60ef04f6786140e3abbc07825a397
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Wed Sep 11 12:08:19 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    This commit copies the ConfKeyManager class from Nova as well as
    synchronizing a few minor changes to the key manager interface in
    Nova.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: I5cb06386410f46cabc490fa6af23272d1d2cb979




From gerrit2 at review.openstack.org  Wed Sep 11 16:17:03 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 11 Sep 2013 16:17:03 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I358813b3ecde4f88de7202c1c07d9b1168c2c332
Message-ID: <E1VJn6F-000894-5L@review.openstack.org>


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

Log:
commit 8c0673d3102478ef34ef1b11c1db156db4b68f62
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Wed Sep 11 12:15:43 2013 -0400

    Add encryption support for volumes to libvirt
    
    Add support to encrypt Cinder volumes. Hooks within the libvirt
    driver encrypt volumes during the attach call. Created a
    VolumeEncryptor interface as well as several concrete subclasses
    (e.g., CryptsetupEncryptor and LuksEncryptor) to handle encryption.
    
    This feature depends upon related changes that have been accepted
    into Cinder (e.g., storing encryption key UUIDs for encrypted
    volumes).
    
    Implements: blueprint encrypt-cinder-volumes
    Change-Id: I358813b3ecde4f88de7202c1c07d9b1168c2c332
    SecurityImpact




From gerrit2 at review.openstack.org  Wed Sep 11 19:19:45 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 11 Sep 2013 19:19:45 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VJpx3-000393-L8@review.openstack.org>


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

Log:
commit a3e183975d34bdca848685ffb2fcc0ee0d1b5364
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Wed Sep 11 12:08:19 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    This commit copies the ConfKeyManager class from Nova as well as
    synchronizing a few minor changes to the key manager interface in
    Nova.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: I5cb06386410f46cabc490fa6af23272d1d2cb979




From gerrit2 at review.openstack.org  Wed Sep 11 20:30:13 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 11 Sep 2013 20:30:13 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1VJr3F-0007ry-7J@review.openstack.org>


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

Log:
commit 2f11618c1387299002e54f8e01bc73ad014e64b7
Author: Dan Genin <Daniel.Genin at jhuapl.edu>
Date:   Mon Sep 2 23:46:49 2013 -0400

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




From gerrit2 at review.openstack.org  Wed Sep 11 21:18:59 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 11 Sep 2013 21:18:59 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1VJroR-0002M1-69@review.openstack.org>


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

Log:
commit d65dfde2a2833cb39899eb19f701728f97cc6f85
Author: Dan Genin <Daniel.Genin at jhuapl.edu>
Date:   Tue Sep 3 00:35:13 2013 -0400

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




From gerrit2 at review.openstack.org  Thu Sep 12 02:07:47 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 12 Sep 2013 02:07:47 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iae94329e7abd105bf95224d28f39f4b746b9eb70
Message-ID: <E1VJwJv-0000HG-Tj@review.openstack.org>


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

Log:
commit 20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c
Author: Jamie Lennox <jlennox at redhat.com>
Date:   Mon Aug 12 13:12:27 2013 +1000

    Replace HttpConnection in auth_token with Requests
    
    Requests is becoming the standard way of doing http communication, it
    also vastly simplifies adding other authentication mechanisms. Use it in
    the auth_token middleware.
    
    This adds the ability to specify a CA file that will be used to verify a
    HTTPS connections or insecure to specifically ignore HTTPS validation.
    
    SecurityImpact
    DocImpact
    Partial-Bug: #1188189
    Change-Id: Iae94329e7abd105bf95224d28f39f4b746b9eb70




From noloader at gmail.com  Thu Sep 12 04:03:59 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 12 Sep 2013 00:03:59 -0400
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iae94329e7abd105bf95224d28f39f4b746b9eb70
In-Reply-To: <E1VJwJv-0000HG-Tj@review.openstack.org>
References: <E1VJwJv-0000HG-Tj@review.openstack.org>
Message-ID: <CAH8yC8mmvFaZgrdH+qzBcnCQ-3-BwG1K30ZvVCEQXLaFRZkZMw@mail.gmail.com>

>     This adds the ability to specify a CA file that will be used to verify a
>     HTTPS connections or insecure to specifically ignore HTTPS validation.
CA file is good, especially if the organization is running its own PKI.

I'm not sure about the other state: no CA means plain text everything.

I'm wondering if a better choice would be to generate a self-signed on
the fly to provide better than nothing security (BTNS).

For those who insist on plain text connections, make them shoot
themselves in the foot by altering a configuration file.

(Sorry about the Gerrit reply. I don't know how to comment on a
concept rather than a particular source file).

On Wed, Sep 11, 2013 at 10:07 PM,  <gerrit2 at review.openstack.org> wrote:
>
> Hi, I'd like you to take a look at this patch for potential
> SecurityImpact.
> https://review.openstack.org/34161
>
> Log:
> commit 20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c
> Author: Jamie Lennox <jlennox at redhat.com>
> Date:   Mon Aug 12 13:12:27 2013 +1000
>
>     Replace HttpConnection in auth_token with Requests
>
>     Requests is becoming the standard way of doing http communication, it
>     also vastly simplifies adding other authentication mechanisms. Use it in
>     the auth_token middleware.
>
>     This adds the ability to specify a CA file that will be used to verify a
>     HTTPS connections or insecure to specifically ignore HTTPS validation.
>
>     SecurityImpact
>     DocImpact
>     Partial-Bug: #1188189
>     Change-Id: Iae94329e7abd105bf95224d28f39f4b746b9eb70



From andrew.nielsen at hds.com  Thu Sep 12 05:07:44 2013
From: andrew.nielsen at hds.com (Andrew Nielsen)
Date: Thu, 12 Sep 2013 05:07:44 +0000
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iae94329e7abd105bf95224d28f39f4b746b9eb70
In-Reply-To: <CAH8yC8mmvFaZgrdH+qzBcnCQ-3-BwG1K30ZvVCEQXLaFRZkZMw@mail.gmail.com>
References: <E1VJwJv-0000HG-Tj@review.openstack.org>,
 <CAH8yC8mmvFaZgrdH+qzBcnCQ-3-BwG1K30ZvVCEQXLaFRZkZMw@mail.gmail.com>
Message-ID: <A8FDD733-7C1A-48F2-AD12-4B2B12C9B3E0@hds.com>

It would be much better to generate a self-signed cert on the fly than to allow plain text by default. The people who are truly security conscious will have the skills, discipline, and expertise to deal with a CA file. For those who don't want any security, it should be a conscious choice to turn it off. A little inconvenience with BTNS is better that OpenStack being labeled as insecure. 

Apologies if I am not using the correct reply format. 

Regards,
Drew

Sent from my iPad

On Sep 11, 2013, at 21:04, "Jeffrey Walton" <noloader at gmail.com> wrote:

>>    This adds the ability to specify a CA file that will be used to verify a
>>    HTTPS connections or insecure to specifically ignore HTTPS validation.
> CA file is good, especially if the organization is running its own PKI.
> 
> I'm not sure about the other state: no CA means plain text everything.
> 
> I'm wondering if a better choice would be to generate a self-signed on
> the fly to provide better than nothing security (BTNS).
> 
> For those who insist on plain text connections, make them shoot
> themselves in the foot by altering a configuration file.
> 
> (Sorry about the Gerrit reply. I don't know how to comment on a
> concept rather than a particular source file).
> 
> On Wed, Sep 11, 2013 at 10:07 PM,  <gerrit2 at review.openstack.org> wrote:
>> 
>> Hi, I'd like you to take a look at this patch for potential
>> SecurityImpact.
>> https://review.openstack.org/34161
>> 
>> Log:
>> commit 20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c
>> Author: Jamie Lennox <jlennox at redhat.com>
>> Date:   Mon Aug 12 13:12:27 2013 +1000
>> 
>>    Replace HttpConnection in auth_token with Requests
>> 
>>    Requests is becoming the standard way of doing http communication, it
>>    also vastly simplifies adding other authentication mechanisms. Use it in
>>    the auth_token middleware.
>> 
>>    This adds the ability to specify a CA file that will be used to verify a
>>    HTTPS connections or insecure to specifically ignore HTTPS validation.
>> 
>>    SecurityImpact
>>    DocImpact
>>    Partial-Bug: #1188189
>>    Change-Id: Iae94329e7abd105bf95224d28f39f4b746b9eb70
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security



From andre.van.daele at ericsson.com  Thu Sep 12 10:15:52 2013
From: andre.van.daele at ericsson.com (=?UTF-8?B?QW5kcsOpIFZhbiBEYWVsZQ==?=)
Date: Thu, 12 Sep 2013 12:15:52 +0200
Subject: [Openstack-security] fuzzing openstack API's
Message-ID: <52319458.5050609@ericsson.com>

Hi,

I do not know if this is the correct place to post this question.
Then please feel free to point me to the right direction.


My question: Is there any kind of fuzzing done on the standard openstack 
API's.
This tests could have been performed by a tool called radamsa or 
defensics or others.

And in case any vulnerabilities found fed back to the openstack 
community for fixes?

Brgds,
André Van Daele





From gerrit2 at review.openstack.org  Thu Sep 12 13:00:28 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 12 Sep 2013 13:00:28 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VK6VY-0002hp-8U@review.openstack.org>


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

Log:
commit 10fdd03e68a088053e07e679d45e55a4239d6a48
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Sep 12 08:57:51 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption. The ConfKeyManager class reads its key
    from the project's configuration file and provides this key for
    *all* requests. As such, this key manager is insecure but allows
    the aforementioned encryption features to be used without further
    integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    This commit copies the ConfKeyManager class from Nova as well as
    synchronizing a few minor changes to the key manager interface in
    Nova.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: I5cb06386410f46cabc490fa6af23272d1d2cb979




From gerrit2 at review.openstack.org  Thu Sep 12 13:02:28 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 12 Sep 2013 13:02:28 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1VK6XU-0002pV-Os@review.openstack.org>


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

Log:
commit 6f9b9989f29a421af7b1797b984c620458381b9f
Author: Dan Genin <Daniel.Genin at jhuapl.edu>
Date:   Tue Sep 3 16:19:25 2013 -0400

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




From thomas at suse.de  Thu Sep 12 14:17:50 2013
From: thomas at suse.de (Thomas Biege)
Date: Thu, 12 Sep 2013 16:17:50 +0200
Subject: [Openstack-security] fuzzing openstack API's
In-Reply-To: <52319458.5050609@ericsson.com>
References: <52319458.5050609@ericsson.com>
Message-ID: <5231CD0E.9010702@suse.de>

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

Hi,

my team made fuzz tests about one year ago using
https://gitorious.org/test-suite/test-suite/source
/1809ffcf2684e53e073e00aeb356b9710969aff2:fuzz_xmlrpc.pl , other
tools and manual requests.

Everything we found was put into the bug tracking system.
Unfortunately I cannot remember the details.

There is also a blueprint for automatic security testing:
https://blueprints.launchpad.net/marconi/+spec/security-testing-basic

Any help is welcome here.

Best,
Thomas

Am 12.09.2013 12:15, schrieb André Van Daele:
> Hi,
> 
> I do not know if this is the correct place to post this question. 
> Then please feel free to point me to the right direction.
> 
> 
> My question: Is there any kind of fuzzing done on the standard
> openstack API's. This tests could have been performed by a tool
> called radamsa or defensics or others.
> 
> And in case any vulnerabilities found fed back to the openstack 
> community for fixes?
> 
> Brgds, André Van Daele
> 
> 
> 
> _______________________________________________ Openstack-security
> mailing list Openstack-security at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


- --
> 
Thomas Biege <thomas at suse.de>, Team Leader MaintenanceSecurity, CSSLP
SUSE LINUX Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
HRB 21284 (AG Nürnberg)
- --
  Wer aufhoert besser werden zu wollen, hoert auf gut zu sein.
                            -- Marie von Ebner-Eschenbach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSMc0OAAoJEJqHoVJVjr8DMKcIAMhECSY1LACb1dBimO9k51FP
Nan9VhAvTxG5DB1WlwNqKuE1M7mHVlWdADhg1eEuR/OId8vrbLUUSK5W9K9ZXX/f
EhoQOP99UrzbnXHA1bNyrWNdCQFi2zaKgP3yLBjCdNzcEyO3hwmP/oa8utZhO/it
H/4V24RD/1N7Mwu//ew9VOM1zuhz6YqstA5c0gk9oyn6gsfbAeCFzrCxZZAxqfh2
408TGfqQfWCgL66x+MCByi0wsgc0O5qgkUOTa3zDr7nWGoV5WRTRN8Q4efKb783J
uJhTLN9NMItrmyhjbBwqGai7mDGqh6JcZqCylqBjc9I3KsjYOJVEet8U1ejqEHs=
=/60c
-----END PGP SIGNATURE-----



From gerrit2 at review.openstack.org  Thu Sep 12 16:08:42 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 12 Sep 2013 16:08:42 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1VK9Ri-00074a-8D@review.openstack.org>


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

Log:
commit e59dae74867b3ff7aa7ab92c9bb1b0e28e2444f2
Author: Dan Genin <Daniel.Genin at jhuapl.edu>
Date:   Tue Sep 3 16:19:25 2013 -0400

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




From gerrit2 at review.openstack.org  Thu Sep 12 17:03:51 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 12 Sep 2013 17:03:51 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VKAJ5-00022T-QW@review.openstack.org>


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

Log:
commit 501df622d1a57df59de5f03a67fa0dc8cf20ad85
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Sep 12 08:57:51 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption -- see
    * https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes
    * https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-storage
    The ConfKeyManager class reads its key from the project's
    configuration file and provides this key for *all* requests. As
    such, this key manager is insecure but allows the aforementioned
    encryption features to be used without further integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    This commit copies the ConfKeyManager class from Nova as well as
    synchronizing a few minor changes to the key manager interface in
    Nova.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: I5cb06386410f46cabc490fa6af23272d1d2cb979




From noloader at gmail.com  Thu Sep 12 22:48:10 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 12 Sep 2013 18:48:10 -0400
Subject: [Openstack-security] fuzzing openstack API's
In-Reply-To: <5231CD0E.9010702@suse.de>
References: <52319458.5050609@ericsson.com>
	<5231CD0E.9010702@suse.de>
Message-ID: <CAH8yC8mcJ2mZzd+3k1z0noW10dD1DkzrZ3Yx3hA=gNQ_sORgUg@mail.gmail.com>

On Thu, Sep 12, 2013 at 10:17 AM, Thomas Biege <thomas at suse.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> ...
> my team made fuzz tests about one year ago using
> https://gitorious.org/test-suite/test-suite/source
> /1809ffcf2684e53e073e00aeb356b9710969aff2:fuzz_xmlrpc.pl , other
> tools and manual requests.
>
> Everything we found was put into the bug tracking system.
> Unfortunately I cannot remember the details.
>
> There is also a blueprint for automatic security testing:
> https://blueprints.launchpad.net/marconi/+spec/security-testing-basic
This is good. It needs to be done with every change to the web gear,
which probably means continuous testing.

Here's some suff that was suggested to me for continuous web app
testing in the past:

  https://www.whitehatsec.com/sentinel_services/sentinel_services.html
  http://www1.contrastsecurity.com/
  https://code.google.com/p/threadfix/

Since HP is active on the project, I would expect Fortify to be available.

Jeff

> Am 12.09.2013 12:15, schrieb André Van Daele:
>> Hi,
>>
>> I do not know if this is the correct place to post this question.
>> Then please feel free to point me to the right direction.
>>
>>
>> My question: Is there any kind of fuzzing done on the standard
>> openstack API's. This tests could have been performed by a tool
>> called radamsa or defensics or others.
>>
>> And in case any vulnerabilities found fed back to the openstack
>> community for fixes?
>>
>> Brgds, André Van Daele



From 1188189 at bugs.launchpad.net  Fri Sep 13 05:11:05 2013
From: 1188189 at bugs.launchpad.net (OpenStack Infra)
Date: Fri, 13 Sep 2013 05:11:05 -0000
Subject: [Openstack-security] [Bug 1188189] Fix merged to
	python-keystoneclient (master)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130913051106.30791.43420.malone@chaenomeles.canonical.com>

Reviewed:  https://review.openstack.org/34161
Committed: http://github.com/openstack/python-keystoneclient/commit/20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c
Submitter: Jenkins
Branch:    master

commit 20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c
Author: Jamie Lennox <jlennox at redhat.com>
Date:   Mon Aug 12 13:12:27 2013 +1000

    Replace HttpConnection in auth_token with Requests
    
    Requests is becoming the standard way of doing http communication, it
    also vastly simplifies adding other authentication mechanisms. Use it in
    the auth_token middleware.
    
    This adds the ability to specify a CA file that will be used to verify a
    HTTPS connections or insecure to specifically ignore HTTPS validation.
    
    SecurityImpact
    DocImpact
    Partial-Bug: #1188189
    Change-Id: Iae94329e7abd105bf95224d28f39f4b746b9eb70

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

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

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

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

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

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

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

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

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



From gerrit2 at review.openstack.org  Fri Sep 13 14:00:06 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 13 Sep 2013 14:00:06 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VKTuo-0000jR-Kq@review.openstack.org>


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

Log:
commit dd3603c51f7933799ac9ac5be7001471d4f6d4d3
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Thu Sep 12 08:57:51 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption -- see
    * https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes
    * https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-storage
    The ConfKeyManager class reads its key from the project's
    configuration file and provides this key for *all* requests. As
    such, this key manager is insecure but allows the aforementioned
    encryption features to be used without further integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    This commit copies the ConfKeyManager class from Nova as well as
    synchronizing a few minor changes to the key manager interface in
    Nova.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: I5cb06386410f46cabc490fa6af23272d1d2cb979




From gerrit2 at review.openstack.org  Sun Sep 15 09:35:04 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 15 Sep 2013 09:35:04 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VL8jQ-0007lt-8m@review.openstack.org>


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

Log:
commit c633b6d11d6d20c70f687ea22d881b14cbc8fbfe
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From gerrit2 at review.openstack.org  Sun Sep 15 11:04:15 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 15 Sep 2013 11:04:15 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VLA7j-0002km-VT@review.openstack.org>


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

Log:
commit 82ebd4a6c1860059b35293388add8f1558fb2ae6
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From gerrit2 at review.openstack.org  Sun Sep 15 23:03:45 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Sun, 15 Sep 2013 23:03:45 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VLLM1-0000XI-AZ@review.openstack.org>


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

Log:
commit 1b3dc4ed820eec14ef0381c4951fa5856d276d6e
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From 1129748 at bugs.launchpad.net  Mon Sep 16 06:33:01 2013
From: 1129748 at bugs.launchpad.net (Matthew Thode)
Date: Mon, 16 Sep 2013 06:33:01 -0000
Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should
	not be world-readable
References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com>
Message-ID: <20130916063301.31196.749.malone@chaenomeles.canonical.com>

This planned for backport to 2012.2 and/or 2013.1?

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

Title:
  image files in _base should not be world-readable

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 ,
  so probably no point making this private.  But I checked the security
  vulnerability box anyway so someone else can decide.

  We create image files in /var/lib/nova/instances/_base with default
  permissions, usually 644.  It would be better to not make the image
  files world-readable, in case they contain private data.

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



From 1225172 at bugs.launchpad.net  Fri Sep 13 20:17:23 2013
From: 1225172 at bugs.launchpad.net (kesten broughton)
Date: Fri, 13 Sep 2013 20:17:23 -0000
Subject: [Openstack-security] [Bug 1225172] [NEW] sercurity groups section
	of docs unclear
References: <20130913201723.7776.608.malonedeb@gac.canonical.com>
Message-ID: <20130913201723.7776.608.malonedeb@gac.canonical.com>

Public bug reported:


following http://savanna.readthedocs.org/en/0.2.1/devref/devstack.html

IP Protocol  From Port  To Port  Source Group  CIDR 
TCP                          1        065535        CIDR          0.0.0.0/0

5.  Now we need to modify security rules. It will allow to connect to
VMs directly from your host. Navigate to project’s “Admin” security tab
and edit default Security Group rules:

however, the dialog box offered by horizon is not the same.

Select
Project tab -> Access & Security and click the "Edit Rules" button.

This brings up the security group rules page

Direction   Ether Type    IP Protocol    Port Range    Remote
ingress       -                       TCP                 1                       0.0.0.0/0 (CIDR)

and the edit dialog does ot offer a "To Port" options as suggested by
the docs.


The docs should be consistent with the horizon display.

** Affects: savanna
     Importance: Undecided
         Status: New


** Tags: horizon install security

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

Title:
  sercurity groups section of docs unclear

Status in Savanna project:
  New

Bug description:
  
  following http://savanna.readthedocs.org/en/0.2.1/devref/devstack.html

  IP Protocol  From Port  To Port  Source Group  CIDR 
  TCP                          1        065535        CIDR          0.0.0.0/0

  5.  Now we need to modify security rules. It will allow to connect to
  VMs directly from your host. Navigate to project’s “Admin” security
  tab and edit default Security Group rules:

  however, the dialog box offered by horizon is not the same.

  Select
  Project tab -> Access & Security and click the "Edit Rules" button.

  This brings up the security group rules page

  Direction   Ether Type    IP Protocol    Port Range    Remote
  ingress       -                       TCP                 1                       0.0.0.0/0 (CIDR)

  and the edit dialog does ot offer a "To Port" options as suggested by
  the docs.


  The docs should be consistent with the horizon display.

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



From SHULMANA at il.ibm.com  Sun Sep 15 20:03:57 2013
From: SHULMANA at il.ibm.com (Alexandra Shulman-Peleg)
Date: Sun, 15 Sep 2013 22:03:57 +0200
Subject: [Openstack-security] [openstack-dev][Swift] Protecting the access
	to memcache
Message-ID: <OFA808FF2E.99581B5B-ONC2257BE7.0065FC97-C2257BE7.006E3E90@il.ibm.com>

Hi,

Following the declaration regarding the memcache vulnerability below, I 
would like to raise a discussion regarding its protection. If we could 
limit/control the access to memcache it would be easier to confine the 
damage in case of an attack. For example, in the attached paper we added a 
gatekeeper to ensure that  the keys/values stored in the memcached of 
Swift are accessed only by the tenant/domain to which they belong (e.g., a 
user from domain A can not access the cached data of users belonging to 
domain B), 

I suggest to provide a generic mechanism allowing insertion of various 
memcache protections as dedicated middleware modules. Practically, 
although in Swift we have a module memcache.py which is part of 
middleware, the module memcached.py is located under "common". What is the 
motivation for this code organization? Can we move the module memcached.py 
to be under "middleware" in Swift? 

Thank you very much,
Alex.
 


----------------------------------------------------------
Alexandra Shulman-Peleg, PhD
Storage Research, Cloud Platforms Dept.
IBM Haifa Research Lab
Tel: +972-3-7689530 | Fax: +972-3-7689545


From:   Thierry Carrez <thierry at openstack.org>
To:     openstack-announce at lists.openstack.org, 
openstack at lists.openstack.org, 
Date:   11/09/2013 06:52 PM
Subject:        [Openstack] [OSSA 2013-025] Token revocation failure using 
Keystone memcache/KVS backends (CVE-2013-4294)



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

OpenStack Security Advisory: 2013-025
CVE: CVE-2013-4294
Date: September 11, 2013
Title: Token revocation failure using Keystone memcache/KVS backends
Reporter: Kieran Spear (University of Melbourne)
Products: Keystone
Affects: Folsom, Grizzly

Description:
Kieran Spear from the University of Melbourne reported a vulnerability
in Keystone memcache and KVS token backends. The PKI token revocation
lists stored the entire token instead of the token ID, triggering
comparison failures, ultimately resulting in revoked PKI tokens still
being considered valid. Only Folsom and Grizzly Keystone setups making
use of PKI tokens with the memcache or KVS token backends are affected.
Havana setups, setups using UUID tokens, or setups using PKI tokens with
the SQL token backend are all unaffected.

Grizzly fix:
https://review.openstack.org/#/c/46080/

Folsom fix:
https://review.openstack.org/#/c/46079/

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4294
https://bugs.launchpad.net/keystone/+bug/1202952

Regards,

- -- 
Thierry Carrez
OpenStack Vulnerability Management Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCAAGBQJSMI+5AAoJEFB6+JAlsQQj2hAQAI/S5bAv+XrYUaXRBgJxvBz4
xVXdrXl/iA7R9iDIlmaFThOCvw4SCsWB7jBYRv8wAk3V3HZw9jEmC3OoebpCFWNb
1q3an25kroviy8rfZyQIqe9KTrwXRa/jDVlun2EEiw7KyUty/HIAjUCVUXVKBhyh
8Bctn90A/Nt2D5Am3hyofsS5fOjmzwW6b73RCY7CDntduxUtPn6lbUthFESXTCwv
lojClZ5X78XnCh2/WJuxKkAEm8EujlNqkIHziGgc3HrForxSc2GKSPzgFbg5eBbt
BaDTxFkDHW3EwSK/69b+699e9BvN/vuBxbNa7YW2ANiM1IJ34QHouPk4XULMZIeH
cZ4QOBX7MtUhvD1htfTlHQfvb1syqlvul49WVmmsk48CMVW6hArSMQvTVbArUqD0
fN2INqfghZMQCkQIlXE+38J88OOL/S+sq6p8dIn96JxP2tnw4rIs9YclSa9E1Ub0
SIDaWPu7NN+wuY1WN+EzHV0zHI8HYs2HkOlrRW3E02JEm3xcEEmYLCwf+c2mwOee
Grick3VlxNuQNBP6bls+NtxCzhUzLVI7nOfaxZyzQtOMLjJPKpip4QKMjzotO3nf
+6JNk5766T2f63fsNtw0kltbtm4R+RzKzv29vVsaOh+ba57w7xnpEkAA1oaYyFa+
IHvUVYkOhX3quLUgBkCR
=pm0d
-----END PGP SIGNATURE-----

_______________________________________________
Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : openstack at lists.openstack.org
Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130915/d6203b31/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi-tenant-isolation.pdf
Type: application/octet-stream
Size: 194912 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130915/d6203b31/attachment.obj>

From me at not.mn  Mon Sep 16 02:51:43 2013
From: me at not.mn (John Dickinson)
Date: Sun, 15 Sep 2013 21:51:43 -0500
Subject: [Openstack-security] [openstack-dev] [Swift] Protecting the
	access to memcache
In-Reply-To: <OFA808FF2E.99581B5B-ONC2257BE7.0065FC97-C2257BE7.006E3E90@il.ibm.com>
References: <OFA808FF2E.99581B5B-ONC2257BE7.0065FC97-C2257BE7.006E3E90@il.ibm.com>
Message-ID: <885CC524-57D0-4E34-B620-F5A5FFC75104@not.mn>

Alex,

You raise two issues, so let me address them independently.

First, you discuss protecting memcache for unauthorized access. Yes, this is something that every deployer of memcache (whether in conjunction with Swift or not) needs to consider. Unchecked access to memcache can allow information leaks and potentially cache poisoning. Memcache servers should be restricted in access to trusted clients. You describe one such way of doing so, and deployers will need to evaluate if your proposed method for themselves. I'd love to see you release the code around your SLIM implementation for Swift, but I do not think it should be in the Swift codebase.

As to the code organization question, swift.common.memcached is a performant memcache client (note there are a couple of outstanding patches to improve this in various ways). swift.common.middleware.memcache is the cache middleware loaded by a Swift WSGI app, and it uses the library module for accessing the memcache pool. The memcache client is used by other middleware (eg ratelimit), so that's why it's in swift/common. The swift/common/middleware directory is for the modules that are available for a WSGI pipeline. (Note that swift.common.middleware.acl may be misplaced by this definition, but it's only used by tempauth.) I think the placement is right the way it is, and I don't think anything should move, especially since there potentially third party modules using these.

--John




On Sep 15, 2013, at 3:03 PM, Alexandra Shulman-Peleg <SHULMANA at il.ibm.com> wrote:

> Hi,
> 
> Following the declaration regarding the memcache vulnerability below, I 
> would like to raise a discussion regarding its protection. If we could 
> limit/control the access to memcache it would be easier to confine the 
> damage in case of an attack. For example, in the attached paper we added a 
> gatekeeper to ensure that  the keys/values stored in the memcached of 
> Swift are accessed only by the tenant/domain to which they belong (e.g., a 
> user from domain A can not access the cached data of users belonging to 
> domain B), 
> 
> I suggest to provide a generic mechanism allowing insertion of various 
> memcache protections as dedicated middleware modules. Practically, 
> although in Swift we have a module memcache.py which is part of 
> middleware, the module memcached.py is located under "common". What is the 
> motivation for this code organization? Can we move the module memcached.py 
> to be under "middleware" in Swift? 
> 
> Thank you very much,
> Alex.
> 
> 
> 
> ----------------------------------------------------------
> Alexandra Shulman-Peleg, PhD
> Storage Research, Cloud Platforms Dept.
> IBM Haifa Research Lab
> Tel: +972-3-7689530 | Fax: +972-3-7689545
> 
> 
> From:   Thierry Carrez <thierry at openstack.org>
> To:     openstack-announce at lists.openstack.org, 
> openstack at lists.openstack.org, 
> Date:   11/09/2013 06:52 PM
> Subject:        [Openstack] [OSSA 2013-025] Token revocation failure using 
> Keystone memcache/KVS backends (CVE-2013-4294)
> 
> 
> 
> Signed PGP part
> OpenStack Security Advisory: 2013-025
> CVE: CVE-2013-4294
> Date: September 11, 2013
> Title: Token revocation failure using Keystone memcache/KVS backends
> Reporter: Kieran Spear (University of Melbourne)
> Products: Keystone
> Affects: Folsom, Grizzly
> 
> Description:
> Kieran Spear from the University of Melbourne reported a vulnerability
> in Keystone memcache and KVS token backends. The PKI token revocation
> lists stored the entire token instead of the token ID, triggering
> comparison failures, ultimately resulting in revoked PKI tokens still
> being considered valid. Only Folsom and Grizzly Keystone setups making
> use of PKI tokens with the memcache or KVS token backends are affected.
> Havana setups, setups using UUID tokens, or setups using PKI tokens with
> the SQL token backend are all unaffected.
> 
> Grizzly fix:
> https://review.openstack.org/#/c/46080/
> 
> Folsom fix:
> https://review.openstack.org/#/c/46079/
> 
> References:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4294
> https://bugs.launchpad.net/keystone/+bug/1202952
> 
> Regards,
> 
> - -- 
> Thierry Carrez
> OpenStack Vulnerability Management Team
> 
> 
> _______________________________________________
> Mailing list: 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> <multi-tenant-isolation.pdf>_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

From 1175906 at bugs.launchpad.net  Mon Sep 16 15:50:32 2013
From: 1175906 at bugs.launchpad.net (Dolph Mathews)
Date: Mon, 16 Sep 2013 15:50:32 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130916155032.11408.84353.malone@wampee.canonical.com>

Unassigning due to inactivity.

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

** Changed in: keystone
     Assignee: Lance Bragstad (ldbragst) => (unassigned)

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From 1175906 at bugs.launchpad.net  Mon Sep 16 16:02:53 2013
From: 1175906 at bugs.launchpad.net (Matthew Thode)
Date: Mon, 16 Sep 2013 16:02:53 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130916160253.7526.2444.malone@gac.canonical.com>

This seems like the same issue that django had (talked about here).

Just set a max password length, have it configurable :D

https://www.djangoproject.com/weblog/2013/sep/15/security/

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From dstanek at dstanek.com  Mon Sep 16 16:38:36 2013
From: dstanek at dstanek.com (David Stanek)
Date: Mon, 16 Sep 2013 16:38:36 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130916163836.31087.72249.malone@chaenomeles.canonical.com>

Is there any reason this bug is marked as Triaged?  I see that Dolph's
patch was merged back in may and I'm wondering if there is more to do
here.

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From 1175906 at bugs.launchpad.net  Mon Sep 16 18:05:52 2013
From: 1175906 at bugs.launchpad.net (Dolph Mathews)
Date: Mon, 16 Sep 2013 18:05:52 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130916180553.11373.1166.malone@wampee.canonical.com>

Fix merged in https://review.openstack.org/#/c/40929/

** Changed in: keystone
    Milestone: None => havana-rc1

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

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Fix Committed

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From 1175906 at bugs.launchpad.net  Mon Sep 16 18:09:16 2013
From: 1175906 at bugs.launchpad.net (Dolph Mathews)
Date: Mon, 16 Sep 2013 18:09:16 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130916180916.11511.36481.malone@wampee.canonical.com>

Looks like I failed to follow up on my patch (thanks Morgan!) and our
friendly neighborhood bot didn't update the status here when the patch
was restored & merged during havana-3.

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Fix Committed

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From 1175906 at bugs.launchpad.net  Mon Sep 16 18:17:46 2013
From: 1175906 at bugs.launchpad.net (Matthew Thode)
Date: Mon, 16 Sep 2013 18:17:46 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130916181746.7557.1903.malone@gac.canonical.com>

backports? grizzly/folsom

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Fix Committed

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From thierry.carrez+lp at gmail.com  Mon Sep 16 21:09:01 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 16 Sep 2013 21:09:01 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130916210901.7526.15692.malone@gac.canonical.com>

This is adding a new config option, which makes it unsuitable for
backport to a stable branch.

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Fix Committed

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From thomas at suse.de  Mon Sep 16 21:17:08 2013
From: thomas at suse.de (Thomas Biege)
Date: Mon, 16 Sep 2013 23:17:08 +0200
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iae94329e7abd105bf95224d28f39f4b746b9eb70
In-Reply-To: <A8FDD733-7C1A-48F2-AD12-4B2B12C9B3E0@hds.com>
References: <E1VJwJv-0000HG-Tj@review.openstack.org>,
 <CAH8yC8mmvFaZgrdH+qzBcnCQ-3-BwG1K30ZvVCEQXLaFRZkZMw@mail.gmail.com>
 <A8FDD733-7C1A-48F2-AD12-4B2B12C9B3E0@hds.com>
Message-ID: <52377554.6080907@suse.de>

On 12.09.13 07:07, Andrew Nielsen wrote:
> It would be much better to generate a self-signed cert on the fly than to allow plain text by default. The people who are truly security conscious will have the skills, discipline, and expertise to deal with a CA file. For those who don't want any security, it should be a conscious choice to turn it off. A little inconvenience with BTNS is better that OpenStack being labeled as insecure. 
> 

+1

Thomas


> Apologies if I am not using the correct reply format. 
> 
> Regards,
> Drew
> 
> Sent from my iPad
> 
> On Sep 11, 2013, at 21:04, "Jeffrey Walton" <noloader at gmail.com> wrote:
> 
>>>    This adds the ability to specify a CA file that will be used to verify a
>>>    HTTPS connections or insecure to specifically ignore HTTPS validation.
>> CA file is good, especially if the organization is running its own PKI.
>>
>> I'm not sure about the other state: no CA means plain text everything.
>>
>> I'm wondering if a better choice would be to generate a self-signed on
>> the fly to provide better than nothing security (BTNS).
>>
>> For those who insist on plain text connections, make them shoot
>> themselves in the foot by altering a configuration file.
>>
>> (Sorry about the Gerrit reply. I don't know how to comment on a
>> concept rather than a particular source file).
>>
>> On Wed, Sep 11, 2013 at 10:07 PM,  <gerrit2 at review.openstack.org> wrote:
>>>
>>> Hi, I'd like you to take a look at this patch for potential
>>> SecurityImpact.
>>> https://review.openstack.org/34161
>>>
>>> Log:
>>> commit 20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c
>>> Author: Jamie Lennox <jlennox at redhat.com>
>>> Date:   Mon Aug 12 13:12:27 2013 +1000
>>>
>>>    Replace HttpConnection in auth_token with Requests
>>>
>>>    Requests is becoming the standard way of doing http communication, it
>>>    also vastly simplifies adding other authentication mechanisms. Use it in
>>>    the auth_token middleware.
>>>
>>>    This adds the ability to specify a CA file that will be used to verify a
>>>    HTTPS connections or insecure to specifically ignore HTTPS validation.
>>>
>>>    SecurityImpact
>>>    DocImpact
>>>    Partial-Bug: #1188189
>>>    Change-Id: Iae94329e7abd105bf95224d28f39f4b746b9eb70
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 


-- 
Thomas Biege <thomas at suse.de>, Team Leader MaintenanceSecurity, CSSLP
SUSE LINUX Products GmbH
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
HRB 21284 (AG Nürnberg)
--
  Wer aufhoert besser werden zu wollen, hoert auf gut zu sein.
                            -- Marie von Ebner-Eschenbach

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

From thierry.carrez+lp at gmail.com  Mon Sep 16 21:01:57 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 16 Sep 2013 21:01:57 -0000
Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should
	not be world-readable
References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com>
Message-ID: <20130916210157.26543.37169.malone@soybean.canonical.com>

No, but depending on the final shape of the fix it might be possible...

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

Title:
  image files in _base should not be world-readable

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 ,
  so probably no point making this private.  But I checked the security
  vulnerability box anyway so someone else can decide.

  We create image files in /var/lib/nova/instances/_base with default
  permissions, usually 644.  It would be better to not make the image
  files world-readable, in case they contain private data.

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



From gerrit2 at review.openstack.org  Tue Sep 17 05:02:54 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 17 Sep 2013 05:02:54 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VLnR8-0003PY-NW@review.openstack.org>


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

Log:
commit 45934e5b03183815efd1ecfb48bc4c1dd97d2d6c
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From gerrit2 at review.openstack.org  Tue Sep 17 07:23:57 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 17 Sep 2013 07:23:57 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VLpdd-0006jY-D8@review.openstack.org>


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

Log:
commit 4c6f4d18c9fa7209e2f74eb1268dffff37db9690
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From noloader at gmail.com  Tue Sep 17 08:29:55 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 17 Sep 2013 01:29:55 -0700
Subject: [Openstack-security] [openstack/python-keystoneclient]
 SecurityImpact review request change
 Iae94329e7abd105bf95224d28f39f4b746b9eb70
In-Reply-To: <CAH8yC8mmvFaZgrdH+qzBcnCQ-3-BwG1K30ZvVCEQXLaFRZkZMw@mail.gmail.com>
References: <E1VJwJv-0000HG-Tj@review.openstack.org>
 <CAH8yC8mmvFaZgrdH+qzBcnCQ-3-BwG1K30ZvVCEQXLaFRZkZMw@mail.gmail.com>
Message-ID: <CAH8yC8m-TirTujHQhxpxnVk6rsamwV484btT+s3t=f82GTbrRA@mail.gmail.com>

On Wed, Sep 11, 2013 at 9:03 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>>     This adds the ability to specify a CA file that will be used to verify a
>>     HTTPS connections or insecure to specifically ignore HTTPS validation.
> CA file is good, especially if the organization is running its own PKI.
>
> I'm not sure about the other state: no CA means plain text everything.
>
> I'm wondering if a better choice would be to generate a self-signed on
> the fly to provide better than nothing security (BTNS).
>
> For those who insist on plain text connections, make them shoot
> themselves in the foot by altering a configuration file.
By the way, did this posting make anyone's radar?

Potential security flaw in network implementation at Digitalocean.com,
http://seclists.org/fulldisclosure/2013/Aug/53.

Opportunistic encryption would be a big help in cases where services
aren't quite configured as well as they could be. Digitalocean.com did
a great job of responding, but the next site to be misconfigured might
not be as responsive as Digitalocean.com.

> On Wed, Sep 11, 2013 at 10:07 PM,  <gerrit2 at review.openstack.org> wrote:
>>
>> Hi, I'd like you to take a look at this patch for potential
>> SecurityImpact.
>> https://review.openstack.org/34161
>>
>> Log:
>> commit 20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c
>> Author: Jamie Lennox <jlennox at redhat.com>
>> Date:   Mon Aug 12 13:12:27 2013 +1000
>>
>>     Replace HttpConnection in auth_token with Requests
>>
>>     Requests is becoming the standard way of doing http communication, it
>>     also vastly simplifies adding other authentication mechanisms. Use it in
>>     the auth_token middleware.
>>
>>     This adds the ability to specify a CA file that will be used to verify a
>>     HTTPS connections or insecure to specifically ignore HTTPS validation.
>>
>>     SecurityImpact
>>     DocImpact
>>     Partial-Bug: #1188189
>>     Change-Id: Iae94329e7abd105bf95224d28f39f4b746b9eb70



From ldbragst at us.ibm.com  Mon Sep 16 16:49:58 2013
From: ldbragst at us.ibm.com (Lance Bragstad)
Date: Mon, 16 Sep 2013 16:49:58 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130916164958.19166.40479.malone@soybean.canonical.com>

Looks like Dolph's patch from comment #28 was resubmitted by Morgan
Fainberg and was merged:

https://review.openstack.org/#/c/40929/1

The review wasn't posted to this bug report.

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From gerrit2 at review.openstack.org  Tue Sep 17 11:28:45 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 17 Sep 2013 11:28:45 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I0fd2f225c7637eb95d82e5dc465313cb7b5c0620
Message-ID: <E1VLtSX-0004tN-2G@review.openstack.org>


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

Log:
commit 43c1f5a81307aa43f21340c2c6e2276fac06d3a7
Author: Michael Still <mikal at stillhq.com>
Date:   Tue Aug 20 15:50:46 2013 +1000

    Implement file rotate for unix domain console logging
    
    This change adds console log file rotation to the unix domain
    socket logging implementation. It also slightly refactors the
    way file logging is handled, but there are no functional changes.
    
    Resolves bug 832507, progresses blueprint fix-libvirt-console-logging.
    
    DocImpact: console log files are now rotated if unix domain
    socket logging is turned on.
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Change-Id: I0fd2f225c7637eb95d82e5dc465313cb7b5c0620




From gerrit2 at review.openstack.org  Tue Sep 17 19:42:04 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 17 Sep 2013 19:42:04 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1VM19w-00048h-2J@review.openstack.org>


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

Log:
commit 2ecd2c32d8fb71c675603207f55e02717e98e228
Author: Dan Genin <Daniel.Genin at jhuapl.edu>
Date:   Tue Sep 3 16:19:25 2013 -0400

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




From gerrit2 at review.openstack.org  Wed Sep 18 14:03:38 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 18 Sep 2013 14:03:38 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1VMILy-00052m-RG@review.openstack.org>


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

Log:
commit ef19390eeb322585d7cf5eb3bcd1085065683355
Author: Dan Genin <Daniel.Genin at jhuapl.edu>
Date:   Tue Sep 3 16:19:25 2013 -0400

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




From thierry.carrez+lp at gmail.com  Wed Sep 18 14:43:42 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 18 Sep 2013 14:43:42 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130918144343.19684.5633.launchpad@wampee.canonical.com>

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

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

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

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

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Fix Committed
Status in Keystone folsom series:
  Won't Fix
Status in Keystone grizzly series:
  Won't Fix

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From 1175906 at bugs.launchpad.net  Wed Sep 18 21:45:22 2013
From: 1175906 at bugs.launchpad.net (Alan Pevec)
Date: Wed, 18 Sep 2013 21:45:22 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20130918214524.19595.44024.launchpad@wampee.canonical.com>

** Changed in: keystone
     Assignee: (unassigned) => Morgan Fainberg (mdrnstm)

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Fix Committed
Status in Keystone folsom series:
  Won't Fix
Status in Keystone grizzly series:
  Won't Fix

Bug description:
  Grant Murphy originally reported:

  * Denial of Service

    The passlib restriction of 4096 for maximum password length is 
    potentially too generous for production environments. On my local machine
    the sha512_crypt algorithm with input of 4096 and 40000
    rounds will potentially introduce a DOS problem:
         feasible length(128) password encrypt:  0.0707409381866  seconds
         feasible length(128) password verify:  0.140727996826  seconds
         excessive length(4096) password encrypt:  1.33277702332  seconds
         excessive length(4096) password verify:  2.66491699219  seconds

  
    I would consider tweaking these values (length or rounds) to reduce 
    the computational overhead here or you're probably going to have a bad time.

  If this is exploitable it will need a CVE, if not we should still
  harden it so it can't be monkeyed with in the future.

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



From 1188189 at bugs.launchpad.net  Thu Sep 19 17:22:00 2013
From: 1188189 at bugs.launchpad.net (Robert Clark)
Date: Thu, 19 Sep 2013 17:22:00 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
	communication fails to check	certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130919172200.7802.71967.malone@chaenomeles.canonical.com>

Some SSL-Enabled connections fail to perform basic certificate checks
----

### Summary ###
In many places OpenStack components use Python 2.x HTTPSConnection to establish an SSL connection between endpoints. This does not provide many of the assurances one would expect when using SSL and leaves connections open to potential man-in-the-middle attacks

### Affected Services / Software ###
keystone/middleware/s3_token.py
keystone/middleware/ec2_token.py
keystone/common/bufferedhttp.py
vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

### Discussion ###
A secure SSL session relies on validation of a X.509 certificate. Basic checks include:
* Is the certificate signed by a CA I recognize
* Has the CA revoked this certificate
* Does the common name on the certificate match the server I'm trying to reach

The HTTPSConnection class is used in a large number of locations and
fails to check that certificates are signed by a valid authority.
Without that check in place, the following checks (some highlighted
above) are largely invalid.

The result is that an attacker who has access to the network traffic
between two endpoints relying on HTTPSConnection can trivially create a
certificate that will be accepted by HTTPSConnection as valid - allowing
the attacker to intercept, read and modify traffic that should be
encrypted by SSL.

### Recommended Actions ###
Consider using an up to date version of the keystone client http://github.com/openstack/python-keystoneclient/commit/20e166fd8a943ee3f91ba362a47e9c14c7cc5f4c

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

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

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

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

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

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

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

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

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

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



From 1188189 at bugs.launchpad.net  Thu Sep 19 17:28:13 2013
From: 1188189 at bugs.launchpad.net (Robert Clark)
Date: Thu, 19 Sep 2013 17:28:13 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
	communication fails to check	certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130919172813.12357.23084.malone@soybean.canonical.com>

Some SSL-Enabled connections fail to perform basic certificate checks
----

### Summary ###
In many places OpenStack components use Python 2.x HTTPSConnection to establish an SSL connection between endpoints. This does not provide many of the assurances one would expect when using SSL and leaves connections open to potential man-in-the-middle attacks

### Affected Services / Software ###
keystone/middleware/s3_token.py
keystone/middleware/ec2_token.py
keystone/common/bufferedhttp.py
vendor/python-keystoneclient-master/keystoneclient/middleware/auth_token.py

### Discussion ###
A secure SSL session relies on validation of a X.509 certificate. Basic checks include:
* Is the certificate signed by a CA I recognize
* Has the CA revoked this certificate
* Does the common name on the certificate match the server I'm trying to reach

The HTTPSConnection class is used in a large number of locations and
fails to check that certificates are signed by a valid authority.
Without that check in place, the following checks (some highlighted
above) are largely invalid.

The result is that an attacker who has access to the network traffic
between two endpoints relying on HTTPSConnection can trivially create a
certificate that will be accepted by HTTPSConnection as valid - allowing
the attacker to intercept, read and modify traffic that should be
encrypted by SSL.

### Recommended Actions ###
Some projects have updated their code to be more secure, others have not. The OSSG suggest cloud deployers check the status of bug https://bugs.launchpad.net/ossn/+bug/1188189 to see if the projects they require have updated.

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

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

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

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

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

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

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

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

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

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



From 1188189 at bugs.launchpad.net  Thu Sep 19 17:36:07 2013
From: 1188189 at bugs.launchpad.net (Robert Clark)
Date: Thu, 19 Sep 2013 17:36:07 -0000
Subject: [Openstack-security] [Bug 1188189] Re: Some server-side 'SSL'
	communication fails to check	certificates (use of HTTPSConnection)
References: <20130606134102.14097.28030.malonedeb@soybean.canonical.com>
Message-ID: <20130919173609.7835.60454.malone@chaenomeles.canonical.com>

Posted to OpenStack ML 19-9-13

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

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

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

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

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

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

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

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

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

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



From 1225172 at bugs.launchpad.net  Thu Sep 19 18:45:57 2013
From: 1225172 at bugs.launchpad.net (Ruslan Kamaldinov)
Date: Thu, 19 Sep 2013 18:45:57 -0000
Subject: [Openstack-security] [Bug 1225172] Re: sercurity groups section of
	docs unclear
References: <20130913201723.7776.608.malonedeb@gac.canonical.com>
Message-ID: <20130919184559.17290.4023.launchpad@soybean.canonical.com>

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

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

Title:
  sercurity groups section of docs unclear

Status in Savanna project:
  New

Bug description:
  
  following http://savanna.readthedocs.org/en/0.2.1/devref/devstack.html

  IP Protocol  From Port  To Port  Source Group  CIDR 
  TCP                          1        065535        CIDR          0.0.0.0/0

  5.  Now we need to modify security rules. It will allow to connect to
  VMs directly from your host. Navigate to project’s “Admin” security
  tab and edit default Security Group rules:

  however, the dialog box offered by horizon is not the same.

  Select
  Project tab -> Access & Security and click the "Edit Rules" button.

  This brings up the security group rules page

  Direction   Ether Type    IP Protocol    Port Range    Remote
  ingress       -                       TCP                 1                       0.0.0.0/0 (CIDR)

  and the edit dialog does ot offer a "To Port" options as suggested by
  the docs.


  The docs should be consistent with the horizon display.

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



From gerrit2 at review.openstack.org  Fri Sep 20 00:14:00 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 20 Sep 2013 00:14:00 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change If5ac48c5c889034c7b0ba24d977e8f4a14137a12
Message-ID: <E1VMoMC-0004ZG-TR@review.openstack.org>


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

Log:
commit 08f0f90a6806b11d9517d3207487d39de2f4bed0
Author: Lance Bragstad <ldbragst at us.ibm.com>
Date:   Mon Jul 1 19:49:21 2013 +0000

    Address security concerns in PowerVM Driver
    
    Add two methods to common.py that will help check commands
    being sent to the remote VIOS system to prevent shell injection.
    
    fixes bug 1192971
    
    [SecurityImpact]
    
    Change-Id: If5ac48c5c889034c7b0ba24d977e8f4a14137a12




From gerrit2 at review.openstack.org  Fri Sep 20 21:07:31 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 20 Sep 2013 21:07:31 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I3513c12ed446171cfba819d8513616a70c983877
Message-ID: <E1VN7vH-0004lg-6t@review.openstack.org>


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

Log:
commit 6a11eedf5d6b3888c356348115635c944ebc5355
Author: Michael Still <mikal at stillhq.com>
Date:   Thu Sep 19 10:38:25 2013 +1000

    Implement unix domain socket consoles for libvirt
    
    For this change to work for you, you'll need to either disable
    apparmor or alter the libvirt templates to allow access to
    /tmp. You also need to change the value of the
    console_log_type flag to "domain". Console logs are then passed
    from libvirt to nova-compute with a unix domain socket. This
    allows us to implement console log file rotation.
    
    This change also makes the way file system elements are shared
    with libvirt configurable. You can specify a chmod value for
    those elements (the previous implementation), or a group to
    chgrp to which is shared by nova-compute and libvirt. If
    neither option is specified, nova-compute will refuse to start
    if using the libvirt hypervisor driver.
    
    This change also slightly refactors how all console logging in
    libvirt works, but there are no functional changes to "file"
    style logging.
    
    New flags:
        console_log_type
        max_rotated_consoles
    
        libvirt_shared_file_mode
        libvirt_shared_group
        libvirt_shared_noop
    
    DocImpact
    
    SecurityImpact: this should reduce the amount of unbounded
    growth we see in libvirt console log files.
    
    Closes-Bug: 832507
    Closes-Bug: 1227027
    Progresses blueprint fix-libvirt-console-logging
    
    This review squashes a series of previous reviews down to one.
    Previous change ids are:
        I6d65acf74e6d2734c16ccea243b3110a97e7f792
        I70e0e21a99fe45dcb2ee3733f382e8f1d0302905
        I5d1cb79375a2ed509262f19af93fa2946e1edf3c
    
    Change-Id: I3513c12ed446171cfba819d8513616a70c983877




From 1197459 at bugs.launchpad.net  Tue Sep 17 18:23:51 2013
From: 1197459 at bugs.launchpad.net (Russell Bryant)
Date: Tue, 17 Sep 2013 18:23:51 -0000
Subject: [Openstack-security] [Bug 1197459] Re: noVNC contains the session
	token in URL and	insecurely sets the session cookie
References: <20130703161152.14968.85936.malonedeb@gac.canonical.com>
Message-ID: <20130917182353.3002.13712.launchpad@gac.canonical.com>

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

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

Title:
  noVNC contains the session token in URL and insecurely sets the
  session cookie

Status in OpenStack Compute (Nova):
  Confirmed
Status in OpenStack Security Advisories:
  Won't Fix

Bug description:
  The VNC Console connection in Nova works by having the user connect to
  the API which returns a URL such as:
  https://example.com:443/?token=abc Where the token has a TTL which is
  then used to create a session from a WebSocket. However, URL's should
  not contain sensitive information such as session tokens with a TTL
  since URL's can be leaked through proxy logs or other types of attacks
  such as Cross-Site Scripting. Additionally, due to the session cookie
  being set with JavaScript it cannot securely be set to HttpOnly nor is
  it set with the Secure flag making it further susceptible to Cross-
  Site Scripting attacks or leakage through a non-SSL connection. To
  limit the exposure of the token being leaked through the URL the
  returned token from the API should be of a one-time use and only used
  as an authentication token in order to obtain a session. The session
  cookie should be set by a Web Service instead of the client in order
  to securely set the cookie with the HttpOnly flag to be set in
  addition to setting the Secure flag.

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



From gerrit2 at review.openstack.org  Mon Sep 23 14:55:29 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 23 Sep 2013 14:55:29 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VO7Xt-0006uu-Kn@review.openstack.org>


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

Log:
commit b3c2685e246f7a0230e4fd132d4a0551715ddb07
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Mon Sep 23 10:52:15 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption -- see
    * https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes
    * https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-storage
    The ConfKeyManager class reads its key from the project's
    configuration file and provides this key for *all* requests. As
    such, this key manager is insecure but allows the aforementioned
    encryption features to be used without further integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    This commit copies the ConfKeyManager class from Nova as well as
    synchronizing changes with the key manager interface in Nova.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: I5cb06386410f46cabc490fa6af23272d1d2cb979




From gerrit2 at review.openstack.org  Tue Sep 24 21:28:52 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 24 Sep 2013 21:28:52 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VOaA8-00076K-RE@review.openstack.org>


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

Log:
commit b3f9b7ba20ecccf818b50b39e28ba9de0e017d3b
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Mon Sep 23 10:52:15 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption -- see
    * https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes
    * https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-storage
    The ConfKeyManager class reads its key from the project's
    configuration file and provides this key for *all* requests. As
    such, this key manager is insecure but allows the aforementioned
    encryption features to be used without further integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    This commit copies the ConfKeyManager class from Nova as well as
    synchronizing changes with the key manager interface in Nova.
    
    Implements blueprint encrypt-cinder-volumes
    SecurityImpact
    
    Change-Id: I5cb06386410f46cabc490fa6af23272d1d2cb979




From gerrit2 at review.openstack.org  Tue Sep 24 23:15:33 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 24 Sep 2013 23:15:33 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VObpN-0007EX-SA@review.openstack.org>


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

Log:
commit 3c7e8c943db15911eee3eb512001b328cc2c713c
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Sep 24 19:10:09 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption -- see
    * https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes
    * https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-storage
    The ConfKeyManager class reads its key from the project's
    configuration file and provides this key for *all* requests. As
    such, this key manager is insecure but allows the aforementioned
    encryption features to be used without further integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    This commit copies the ConfKeyManager class from Nova as well as
    synchronizing changes with the key manager interface in Nova.
    
    Implements blueprint encrypt-cinder-volumes
    DocImpact
    SecurityImpact
    
    Change-Id: I5cb06386410f46cabc490fa6af23272d1d2cb979




From gerrit2 at review.openstack.org  Wed Sep 25 10:33:20 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Wed, 25 Sep 2013 10:33:20 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VOmPI-00029w-Fl@review.openstack.org>


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

Log:
commit e14e1a1624468c002634bf062fd7f9c559cc15c1
Author: Joel Coffman <joel.coffman at jhuapl.edu>
Date:   Tue Sep 24 19:10:09 2013 -0400

    Add key manager implementation with static key
    
    Per feedback received on other patch sets, an example key manager
    driver is required to support ephemeral storage encryption and
    Cinder volume encryption -- see
    * https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes
    * https://blueprints.launchpad.net/nova/+spec/encrypt-ephemeral-storage
    The ConfKeyManager class reads its key from the project's
    configuration file and provides this key for *all* requests. As
    such, this key manager is insecure but allows the aforementioned
    encryption features to be used without further integration effort.
    
    To clarify the above statements, the configuration-based key
    manager uses a single, fixed key. When used to encrypt data (e.g.,
    by the Cinder volume encryption feature), the encryption provides
    limited protection for the confidentiality of data. For example,
    data cannot be read from a lost or stolen disk, and a volume's
    contents cannot be reconstructed if an attacker intercepts the iSCSI
    traffic between the compute and storage host. If the key is ever
    compromised, then any data encrypted with the key can be decrypted.
    
    This commit copies the ConfKeyManager class from Nova as well as
    synchronizing changes with the key manager interface in Nova.
    
    Implements blueprint encrypt-cinder-volumes
    DocImpact
    SecurityImpact
    
    Change-Id: I5cb06386410f46cabc490fa6af23272d1d2cb979




From 1129748 at bugs.launchpad.net  Wed Sep 25 20:08:08 2013
From: 1129748 at bugs.launchpad.net (Russell Bryant)
Date: Wed, 25 Sep 2013 20:08:08 -0000
Subject: [Openstack-security] [Bug 1129748] Re: image files in _base should
	not be world-readable
References: <20130219034904.21134.44738.malonedeb@wampee.canonical.com>
Message-ID: <20130925200810.7385.686.launchpad@gac.canonical.com>

** Changed in: nova
    Milestone: havana-rc1 => None

** Tags added: havana-rc-potential libvirt

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

Title:
  image files in _base should not be world-readable

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 ,
  so probably no point making this private.  But I checked the security
  vulnerability box anyway so someone else can decide.

  We create image files in /var/lib/nova/instances/_base with default
  permissions, usually 644.  It would be better to not make the image
  files world-readable, in case they contain private data.

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



From thierry.carrez+lp at gmail.com  Fri Sep 27 08:57:09 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Fri, 27 Sep 2013 08:57:09 -0000
Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been
	print in log by some	API call
References: <20130926055439.7490.27811.malonedeb@gac.canonical.com>
Message-ID: <20130927085710.28544.15309.malone@gac.canonical.com>

Presence of passwords in debug logs should definitely be fixed, but was
not treated as a vulnerability warranting the publication of an OSSA in
the past. let's get this fixed in havana.

** No longer affects: ossa

** Tags added: security

** Tags added: havana-rc-potential

** Information type changed from Public Security to Public

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

Title:
  Clear text password has been print in log by some API call

Status in OpenStack Compute (Nova):
  New

Bug description:
  In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova.
  i.e:

  2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': <nova.api.openstack.wsgi.Resource object at 0x46d09d0>, 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f
  f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103
  2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926

  This is not secue which the password should be replaced by ***

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



From thierry.carrez+lp at gmail.com  Fri Sep 27 12:48:28 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Fri, 27 Sep 2013 12:48:28 -0000
Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been
	print in log by some	API call
References: <20130926055439.7490.27811.malonedeb@gac.canonical.com>
Message-ID: <20130927124828.22241.18869.malone@soybean.canonical.com>

@Rob: we didn't issue one for past "DEBUG logs in past versions might
contain sensitive information" issues... Your call :)

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

Title:
  Clear text password has been print in log by some API call

Status in OpenStack Compute (Nova):
  New

Bug description:
  In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova.
  i.e:

  2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': <nova.api.openstack.wsgi.Resource object at 0x46d09d0>, 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f
  f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103
  2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926

  This is not secue which the password should be replaced by ***

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



From slukjanov at mirantis.com  Sun Sep 29 06:26:55 2013
From: slukjanov at mirantis.com (Sergey Lukjanov)
Date: Sun, 29 Sep 2013 06:26:55 -0000
Subject: [Openstack-security] [Bug 1225172] Re: Sercurity groups section of
	docs unclear
References: <20130913201723.7776.608.malonedeb@gac.canonical.com>
Message-ID: <20130929062656.28200.32627.launchpad@gac.canonical.com>

** Summary changed:

- sercurity groups section of docs unclear
+ Sercurity groups section of docs unclear

** Changed in: savanna
    Milestone: None => 0.3a1

** Tags removed: horizon install security
** Tags added: 0.3

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

Title:
  Sercurity groups section of docs unclear

Status in Savanna project:
  New

Bug description:
  
  following http://savanna.readthedocs.org/en/0.2.1/devref/devstack.html

  IP Protocol  From Port  To Port  Source Group  CIDR 
  TCP                          1        065535        CIDR          0.0.0.0/0

  5.  Now we need to modify security rules. It will allow to connect to
  VMs directly from your host. Navigate to project’s “Admin” security
  tab and edit default Security Group rules:

  however, the dialog box offered by horizon is not the same.

  Select
  Project tab -> Access & Security and click the "Edit Rules" button.

  This brings up the security group rules page

  Direction   Ether Type    IP Protocol    Port Range    Remote
  ingress       -                       TCP                 1                       0.0.0.0/0 (CIDR)

  and the edit dialog does ot offer a "To Port" options as suggested by
  the docs.


  The docs should be consistent with the horizon display.

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



From 1231263 at bugs.launchpad.net  Fri Sep 27 12:37:21 2013
From: 1231263 at bugs.launchpad.net (Robert Clark)
Date: Fri, 27 Sep 2013 12:37:21 -0000
Subject: [Openstack-security] [Bug 1231263] Re: Clear text password has been
	print in log by some	API call
References: <20130926055439.7490.27811.malonedeb@gac.canonical.com>
Message-ID: <20130927123721.21610.30377.malone@soybean.canonical.com>

I know that my own, and some other orgs filter the logs. Do you think an
OSSN is warranted for this?

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

Title:
  Clear text password has been print in log by some API call

Status in OpenStack Compute (Nova):
  New

Bug description:
  In current implementation, when perform some api call, like change server password, or rescue server, the password has been print in log in nova.
  i.e:

  2013-09-26 13:48:01.711 DEBUG routes.middleware [-] Match dict: {'action': u'action', 'controller': <nova.api.openstack.wsgi.Resource object at 0x46d09d0>, 'project_id': u'05004a24b3304cd9b55a0fcad08107b3', 'id': u'8c4a1dfa-147a-4f
  f8-8116-010d8c346115'} from (pid=10629) __call__ /usr/local/lib/python2.7/dist-packages/routes/middleware.py:103
  2013-09-26 13:48:01.711 DEBUG nova.api.openstack.wsgi [req-10ebd201-ba52-453f-b1ce-1e41fbef8cdd admin demo] Action: 'action', body: {"changePassword": {"adminPass": "1234567"}} from (pid=10629) _process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:926

  This is not secue which the password should be replaced by ***

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