From noloader at gmail.com  Wed Oct  2 09:09:29 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 2 Oct 2013 05:09:29 -0400
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django] Cookie-based
 session storage session invalidation issue
In-Reply-To: <CAAsS5mpV0nEUWzYOnykrbAADeArOWbF-a_G5D5-UOEAWPg9c=Q@mail.gmail.com>
References: <CAAsS5mpV0nEUWzYOnykrbAADeArOWbF-a_G5D5-UOEAWPg9c=Q@mail.gmail.com>
Message-ID: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>

Not sure if this made anyone's radar....

(I'm not sure about the 1.7 version, though).

---------- Forwarded message ----------
From: G. S. McNamara <main at gsmcnamara.com>
Date: Tue, Oct 1, 2013 at 4:20 PM
Subject: [Full-disclosure] [Django] Cookie-based session storage
session invalidation issue
To: full-disclosure at lists.grok.org.uk

FD,

I’m back!

Django versions 1.4 – 1.7 offer a cookie-based session storage option
(not the default this time) that is afflicted by the same issue I
posted about previously concerning Ruby on Rails:

If you obtain a user’s cookie, even if they log out, you can still log
in as them.

The short write-up is here, if needed:
http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/

Cheers,

G. S. McNamara

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/



From thierry.carrez+lp at gmail.com  Wed Oct  2 11:27:29 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Wed, 02 Oct 2013 11:27:29 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20131002112731.29755.10878.launchpad@chaenomeles.canonical.com>

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

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Fix Released
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 robert.clark at hp.com  Wed Oct  2 15:47:20 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Wed, 2 Oct 2013 15:47:20 +0000
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
Message-ID: <CE71FE82.343A8%robert.clark@hp.com>

It's not a django default, does it get turned on in Horizon configurations?

On 02/10/2013 10:09, "Jeffrey Walton" <noloader at gmail.com> wrote:

>Not sure if this made anyone's radar....
>
>(I'm not sure about the 1.7 version, though).
>
>---------- Forwarded message ----------
>From: G. S. McNamara <main at gsmcnamara.com>
>Date: Tue, Oct 1, 2013 at 4:20 PM
>Subject: [Full-disclosure] [Django] Cookie-based session storage
>session invalidation issue
>To: full-disclosure at lists.grok.org.uk
>
>FD,
>
>I¹m back!
>
>Django versions 1.4 ­ 1.7 offer a cookie-based session storage option
>(not the default this time) that is afflicted by the same issue I
>posted about previously concerning Ruby on Rails:
>
>If you obtain a user¹s cookie, even if they log out, you can still log
>in as them.
>
>The short write-up is here, if needed:
>http://maverickblogging.com/security-vulnerability-with-django-cookie-base
>d-sessions/
>
>Cheers,
>
>G. S. McNamara
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsored by Secunia - http://secunia.com/
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security




From gerrit2 at review.openstack.org  Thu Oct  3 03:04:15 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 03 Oct 2013 03:04:15 +0000
Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review
 request change Ic00009e635f81427ba909a9ce4ba168f14ff51df
Message-ID: <E1VRZD5-0006Tw-K9@review.openstack.org>


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

Log:
commit 75655757d624fc86c9c214dc6ad60a3bd47a5404
Author: Simo Sorce <simo at redhat.com>
Date:   Wed Aug 7 14:16:28 2013 -0400

    Key Distribution Server
    
    API for distribution of keys in support of:
    https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation
    
    SecurityImpact
    
    Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df




From gerrit2 at review.openstack.org  Thu Oct  3 03:48:47 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 03 Oct 2013 03:48:47 +0000
Subject: [Openstack-security] [openstack/cinder] SecurityImpact review
 request change I5cb06386410f46cabc490fa6af23272d1d2cb979
Message-ID: <E1VRZuB-00088b-32@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 ae6b7642e8d32ef5fa75cdcfe55be23c052fd547
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 thierry.carrez+lp at gmail.com  Thu Oct  3 09:05:34 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 03 Oct 2013 09:05: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: <20131003090535.4414.88881.launchpad@gac.canonical.com>

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

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

Status in Orchestration API (Heat):
  Fix Released

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 noloader at gmail.com  Thu Oct  3 22:30:37 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 3 Oct 2013 18:30:37 -0400
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <CE71FE82.343A8%robert.clark@hp.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
Message-ID: <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>

Here's some more reading on the subject. It was recently updated, and
effectively states django is susceptible to session management attacks
under some configurations.
https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-cookie-based-sessions.

On Wed, Oct 2, 2013 at 11:47 AM, Clark, Robert Graham
<robert.clark at hp.com> wrote:
> It's not a django default, does it get turned on in Horizon configurations?
>
> On 02/10/2013 10:09, "Jeffrey Walton" <noloader at gmail.com> wrote:
>
>>Not sure if this made anyone's radar....
>>
>>(I'm not sure about the 1.7 version, though).
>>
>>---------- Forwarded message ----------
>>From: G. S. McNamara <main at gsmcnamara.com>
>>Date: Tue, Oct 1, 2013 at 4:20 PM
>>Subject: [Full-disclosure] [Django] Cookie-based session storage
>>session invalidation issue
>>To: full-disclosure at lists.grok.org.uk
>>
>>FD,
>>
>>I¹m back!
>>
>>Django versions 1.4 ­ 1.7 offer a cookie-based session storage option
>>(not the default this time) that is afflicted by the same issue I
>>posted about previously concerning Ruby on Rails:
>>
>>If you obtain a user¹s cookie, even if they log out, you can still log
>>in as them.
>>
>>The short write-up is here, if needed:
>>http://maverickblogging.com/security-vulnerability-with-django-cookie-base
>>d-sessions/
>>
>>Cheers,
>>
>>G. S. McNamara
>>
>>_______________________________________________
>>Full-Disclosure - We believe in it.
>>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>Hosted and sponsored by Secunia - http://secunia.com/
>>
>>_______________________________________________
>>Openstack-security mailing list
>>Openstack-security at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>



From kseifried at redhat.com  Fri Oct  4 01:11:55 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Thu, 03 Oct 2013 19:11:55 -0600
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
References: <CAAsS5mpV0nEUWzYOnykrbAADeArOWbF-a_G5D5-UOEAWPg9c=Q@mail.gmail.com>
 <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
Message-ID: <524E15DB.2030005@redhat.com>

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

On 10/02/2013 03:09 AM, Jeffrey Walton wrote:
> Not sure if this made anyone's radar....
> 
> (I'm not sure about the 1.7 version, though).
> 
> ---------- Forwarded message ---------- From: G. S. McNamara
> <main at gsmcnamara.com> Date: Tue, Oct 1, 2013 at 4:20 PM Subject:
> [Full-disclosure] [Django] Cookie-based session storage session
> invalidation issue To: full-disclosure at lists.grok.org.uk
> 
> FD,
> 
> I’m back!
> 
> Django versions 1.4 – 1.7 offer a cookie-based session storage
> option (not the default this time) that is afflicted by the same
> issue I posted about previously concerning Ruby on Rails:
> 
> If you obtain a user’s cookie, even if they log out, you can still
> log in as them.
> 
> The short write-up is here, if needed: 
> http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/
>
>  Cheers,
> 
> G. S. McNamara

Sounds like this needs a CVE? Has one been requested from Mitre? If
not I can assign it.

https://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSThXbAAoJEBYNRVNeJnmTeGMQAI4jnGSqKxP0vC1nPj4WAYyl
leYsGVX/SmZ1LX7s0KNbmbuN9ERcA5zT7ua7J0osMuPnhkODb7z/dhWuYnZARDIn
nVEaLJyBa6Bu7rcsasgFmuHk4BvXwnEY0ngH/i3Dz/jIxrP3atSr8uaQW8fdVtP1
FkVKx+NDaqEuHjJTpy8snO0UYPj9ZE/gS2Hs9ydyIRyeMGrSspdsnrzI7bxaMejq
pMcu41fH7kZZ3tseUyhc+oBzOzHDlWHYVuJJL/DCuk64RMOPGrp7zyLBoDF3U3gm
u5C85OoIpTCl5XuOE2LLO2kotfCnP2PfUdMm+KdzS9tpTkMtOc6KJFjn6MeohYKN
/TxT+m1rQqEmipxMbFgXc6pulZSEUWEnhy599960aoSmKUPN1Ss9sXK4ARwkfaeA
04L5JLcwocc3g0uHhNayx29ilF3Jsj97SBHUEiaqoe4dBTKumFdv14b61nAJknYd
PA3pCq9/3j1R5r+kDK9lffPjeycL/gaqHoXTH3sTdwExFeuBTPXC0kEeqH/GngWD
U60cSGkr+LVH2z2AF5qRyEjGPOR0QFuE4zo072L+5fFavftgMvLvukkAXTTz/V6C
9ljGyTJ+nA02NKKylAAP7hLksRuKgyQIx/dKK2Btqlb0ZlU/C1igmoyL3JVocIMt
7EuS8NbgPBnQnSYuQ14I
=whZK
-----END PGP SIGNATURE-----



From noloader at gmail.com  Fri Oct  4 02:22:05 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 3 Oct 2013 22:22:05 -0400
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
 <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
Message-ID: <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>

On Thu, Oct 3, 2013 at 6:30 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> Here's some more reading on the subject. It was recently updated, and
> effectively states django is susceptible to session management attacks
> under some configurations.
> https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-cookie-based-sessions.
Its now being tracked: VU#160862 (thanks Kurt).

> On Wed, Oct 2, 2013 at 11:47 AM, Clark, Robert Graham
> <robert.clark at hp.com> wrote:
>> It's not a django default, does it get turned on in Horizon configurations?
>>
>> On 02/10/2013 10:09, "Jeffrey Walton" <noloader at gmail.com> wrote:
>>
>>>Not sure if this made anyone's radar....
>>>
>>>(I'm not sure about the 1.7 version, though).
>>>
>>>---------- Forwarded message ----------
>>>From: G. S. McNamara <main at gsmcnamara.com>
>>>Date: Tue, Oct 1, 2013 at 4:20 PM
>>>Subject: [Full-disclosure] [Django] Cookie-based session storage
>>>session invalidation issue
>>>To: full-disclosure at lists.grok.org.uk
>>>
>>>FD,
>>>
>>>I¹m back!
>>>
>>>Django versions 1.4 ­ 1.7 offer a cookie-based session storage option
>>>(not the default this time) that is afflicted by the same issue I
>>>posted about previously concerning Ruby on Rails:
>>>
>>>If you obtain a user¹s cookie, even if they log out, you can still log
>>>in as them.
>>>
>>>The short write-up is here, if needed:
>>>http://maverickblogging.com/security-vulnerability-with-django-cookie-base
>>>d-sessions/
>>>
>>>Cheers,
>>>
>>>G. S. McNamara



From kseifried at redhat.com  Fri Oct  4 03:09:01 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Thu, 03 Oct 2013 21:09:01 -0600
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
 <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
 <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>
Message-ID: <524E314D.5030700@redhat.com>

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

On 10/03/2013 08:22 PM, Jeffrey Walton wrote:
> On Thu, Oct 3, 2013 at 6:30 PM, Jeffrey Walton <noloader at gmail.com>
> wrote:
>> Here's some more reading on the subject. It was recently updated,
>> and effectively states django is susceptible to session
>> management attacks under some configurations. 
>> https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-cookie-based-sessions.
>
>> 
Its now being tracked: VU#160862 (thanks Kurt).

Just to be clear I didn't do anything yet. That's a US-CERT
Vulnerability Note number, nothing to do with CVE. Did you contact the
Django people about this issue to report it upstream yet? Adding
security at djangoproject.com in case they haven't seen it yet.

This is regarding

http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/

I'm going to assign a CVE if I can somewhat confirm a CVE hasn't been
requested yet.


- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSTjFMAAoJEBYNRVNeJnmTsekP/2igBidUl26EmyQg09qOYT7S
mYbn60jqyaH+yyBpZc6RK6bhWxK5vOrSD46l8ag7oxX3SXQNJmv8dD3ua5nMvJfH
ynrbm9oXboU04tw3ij5Texvux2OmBqdf1wW/zONhEMO4XLP9QaT82zTINbLVMyR7
QVPaFAYWT0Ba/QEEIbG2cJ3v14dRl9lqB/qOlsx1CrcwczqGlLYPjvhctTG4NZRW
op6f+XrEgBb5GAd/YrQdQrKKo5vlIwVRSuSRbYFLaQZU/4gAy0rMCUjuXxO+nt8W
1FaXryBSjr4MBffE2ou7XDwrUSJJkqceEhEKF3mKaRLRTjXbV6/u2Slc9EtlaS9t
k0wu8wMx7xnSsZVTldBaS4Pgh49ZiDqqxGRncb8Gy+GIAvrh3FswLNxJa7w/zDBT
JIewqKvSiWKqgrRc2HPw2w9QWnX3OhXGRxmbTRUuEse/dlQ2OqnT7z1mPG2AmJoj
I+tsis7btojs0OEXeyOOJVJzINWSCZcF1PAz1zwO5c4x7lA9la6dgaOKQPPFctjR
UKq30ztQ66eXiROydt/Vz1zUgPn/KUHB34L2jyPg/otnx/TLLisCEXxXb4TL68nx
0WfPTVK5zRl0SqmSdizwHaCDepaexh756QGIJyRrd8br1O9GKj1Lj5g6Vx4PDiLO
KdabNJIvEImC8HPAPwoE
=lzjh
-----END PGP SIGNATURE-----



From kseifried at redhat.com  Fri Oct  4 03:48:42 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Thu, 03 Oct 2013 21:48:42 -0600
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <CAO_YWRV8AWEM7M5JG3jt7=8wc67Qq1Q8gQbGG+pb6pB74-5t+g@mail.gmail.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
 <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
 <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>
 <524E314D.5030700@redhat.com>
 <CAO_YWRV8AWEM7M5JG3jt7=8wc67Qq1Q8gQbGG+pb6pB74-5t+g@mail.gmail.com>
Message-ID: <524E3A9A.2000308@redhat.com>

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

On 10/03/2013 09:39 PM, Paul McMillan wrote:
> Hi Kurt,
> 
> The upstream Django team would be extremely happy if you refrained 
> from assigning a CVE for a clearly documented security tradeoff,
> which is mentioned covered in both the Django and the Horizon docs,
> as well as in the Openstack Security Guide.
> 
> The upshot of this entire business is that if you rely soly on 
> client-side cookies, logging out deletes the cookie from a local 
> browser, but does not actually invalidate it until the session
> expiry timeout. If you don't like this particular technical
> limitation using client side sessions, you are advised not to use
> that cookie backend.
> 
> https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions
>
>
> 
This does NOT deserve a CVE.
> 
> Regards, -Paul

Yeah this is usually why i research things a bit before assigning a CVE.

So based on

https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions

No freshness guarantee

Note also that while the MAC can guarantee the authenticity of the
data (that it was generated by your site, and not someone else), and
the integrity of the data (that it is all there and correct), it
cannot guarantee freshness i.e. that you are being sent back the last
thing you sent to the client. This means that for some uses of session
data, the cookie backend might open you up to replay attacks. Unlike
other session backends which keep a server-side record of each session
and invalidate it when a user logs out, cookie-based sessions are not
invalidated when a user logs out. Thus if an attacker steals a user’s
cookie, he can use that cookie to login as that user even if the user
logs out. Cookies will only be detected as ‘stale’ if they are older
than your SESSION_COOKIE_AGE.

I would say this falls into the Python Pickle() group (large red
banner), a potentially dangerous feature with a large warning. Ergo no
CVE.

My one comment would be to possibly make the reply warning more
prominent and also mention protecting the cookie with HTTPS (wireless
networks in coffee shops/etc.).


> On Fri, Oct 4, 2013 at 4:09 AM, Kurt Seifried
> <kseifried at redhat.com> wrote: On 10/03/2013 08:22 PM, Jeffrey
> Walton wrote:
>>>> On Thu, Oct 3, 2013 at 6:30 PM, Jeffrey Walton
>>>> <noloader at gmail.com> wrote:
>>>>> Here's some more reading on the subject. It was recently
>>>>> updated, and effectively states django is susceptible to
>>>>> session management attacks under some configurations. 
>>>>> https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-cookie-based-sessions.
>>>>
>>>>>
>
>>>>> 
Its now being tracked: VU#160862 (thanks Kurt).
> 
> Just to be clear I didn't do anything yet. That's a US-CERT 
> Vulnerability Note number, nothing to do with CVE. Did you contact
> the Django people about this issue to report it upstream yet?
> Adding security at djangoproject.com in case they haven't seen it
> yet.
> 
> This is regarding
> 
> http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/
>
>  I'm going to assign a CVE if I can somewhat confirm a CVE hasn't
> been requested yet.
> 
> 

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSTjqaAAoJEBYNRVNeJnmTz+MP/jzKxzkRr3i9G9tMSi9HO8fn
9z3gx1rDQ6YcsucSEma4klqFBa1hV9RE/LQqJBVup7g5wBQYFq6e+V2JHOnz0ohM
hTn7GSRpusQxQaouEZJyy0lK1hrTBIEARaLbbNsn4I2yyb6Kq/xnbUXwmCpBb8Nf
ZhIbamdI/nAdWINRgzypQiGSK6eMjX+VbamRvealgRdk1dm5mlJxDyBkXFqAsXEf
JHrEnsZ7KjNzwjJPRdcif9kS93BegCv/hBnueP0SWipIuRSfizAgTyLn/KlqSVLW
2ByL1OgrvMZkpPTRpfAOXrmYcBdjrJd8lf5ENdookxTf6yK5IZvRy33TP07mKZAv
wDrKfQBllxmTX1ZYAdpKg1yfGlkESU1mSE2TzyUJMsa0fBW0sB8wGpjmL3boZE77
/90MmGfxBzc0DBEuMRMCQ7TaME7IsHbZayG3davN2T+h3N8EHiIDlus3PFai2+rJ
fNOP5aGtTUcBMfJObI3T6m8D9C6tgaB6wuBsgGP/p9X1/+htQjVJtVQWopdBLQ7a
/hTczkeIGGiputzRxZS/EX+OhFFuJ7voMOpy/Mhi08patdHe5ZRy83ltMFGO30mD
wMhYmqOmzWZCsLYCCbEtPSCr0vjHpYBUhAF4Y4MTAv+Vhw8miugBCsWJ4MS+7Ud/
tEq6pZfsZ3dw1Zs/I1vh
=GCVi
-----END PGP SIGNATURE-----



From noloader at gmail.com  Fri Oct  4 04:00:21 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 4 Oct 2013 00:00:21 -0400
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <524E3A9A.2000308@redhat.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
 <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
 <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>
 <524E314D.5030700@redhat.com>
 <CAO_YWRV8AWEM7M5JG3jt7=8wc67Qq1Q8gQbGG+pb6pB74-5t+g@mail.gmail.com>
 <524E3A9A.2000308@redhat.com>
Message-ID: <CAH8yC8m1909uT4Hbw1qwodUM-eeNyKS+KQ=M1-cNt8w-ZKFOaA@mail.gmail.com>

On Thu, Oct 3, 2013 at 11:48 PM, Kurt Seifried <kseifried at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/03/2013 09:39 PM, Paul McMillan wrote:
>> Hi Kurt,
>>
>> The upstream Django team would be extremely happy if you refrained
>> from assigning a CVE for a clearly documented security tradeoff,
>> which is mentioned covered in both the Django and the Horizon docs,
>> as well as in the Openstack Security Guide.
>>
>> The upshot of this entire business is that if you rely soly on
>> client-side cookies, logging out deletes the cookie from a local
>> browser, but does not actually invalidate it until the session
>> expiry timeout. If you don't like this particular technical
>> limitation using client side sessions, you are advised not to use
>> that cookie backend.
>>
>> https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions
>>
>>
>>
> This does NOT deserve a CVE.
>>
>> Regards, -Paul
>
> Yeah this is usually why i research things a bit before assigning a CVE.
>
> So based on
>
> https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions
>
> No freshness guarantee
>
> Note also that while the MAC can guarantee the authenticity of the
> data (that it was generated by your site, and not someone else), and
> the integrity of the data (that it is all there and correct), it
> cannot guarantee freshness i.e. that you are being sent back the last
> thing you sent to the client. This means that for some uses of session
> data, the cookie backend might open you up to replay attacks. Unlike
> other session backends which keep a server-side record of each session
> and invalidate it when a user logs out, cookie-based sessions are not
> invalidated when a user logs out. Thus if an attacker steals a user’s
> cookie, he can use that cookie to login as that user even if the user
> logs out. Cookies will only be detected as ‘stale’ if they are older
> than your SESSION_COOKIE_AGE.
>
> I would say this falls into the Python Pickle() group (large red
> banner), a potentially dangerous feature with a large warning. Ergo no
> CVE.
>
> My one comment would be to possibly make the reply warning more
> prominent and also mention protecting the cookie with HTTPS (wireless
> networks in coffee shops/etc.).
What precisely is OpenStack going to do to ensure Django is always in
an approved configuration (or ships in a secure configuration)?

Are there any UI warnings when moving from a secure configuration to a
potentially insecure configuration?

Are the QA folks or Release team aware they need to inspect a setting
and check a box?

(Forgive my ignorance - I'm still learning policy and procedures).

Jeff



From kseifried at redhat.com  Fri Oct  4 04:04:14 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Thu, 03 Oct 2013 22:04:14 -0600
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <CAH8yC8m1909uT4Hbw1qwodUM-eeNyKS+KQ=M1-cNt8w-ZKFOaA@mail.gmail.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
 <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
 <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>
 <524E314D.5030700@redhat.com>
 <CAO_YWRV8AWEM7M5JG3jt7=8wc67Qq1Q8gQbGG+pb6pB74-5t+g@mail.gmail.com>
 <524E3A9A.2000308@redhat.com>
 <CAH8yC8m1909uT4Hbw1qwodUM-eeNyKS+KQ=M1-cNt8w-ZKFOaA@mail.gmail.com>
Message-ID: <524E3E3E.8090802@redhat.com>

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

On 10/03/2013 10:00 PM, Jeffrey Walton wrote:
> On Thu, Oct 3, 2013 at 11:48 PM, Kurt Seifried
> <kseifried at redhat.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 10/03/2013 09:39 PM, Paul McMillan wrote:
>>> Hi Kurt,
>>> 
>>> The upstream Django team would be extremely happy if you
>>> refrained from assigning a CVE for a clearly documented
>>> security tradeoff, which is mentioned covered in both the
>>> Django and the Horizon docs, as well as in the Openstack
>>> Security Guide.
>>> 
>>> The upshot of this entire business is that if you rely soly on 
>>> client-side cookies, logging out deletes the cookie from a
>>> local browser, but does not actually invalidate it until the
>>> session expiry timeout. If you don't like this particular
>>> technical limitation using client side sessions, you are
>>> advised not to use that cookie backend.
>>> 
>>> https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions
>>>
>>>
>>>
>>
>>> 
This does NOT deserve a CVE.
>>> 
>>> Regards, -Paul
>> 
>> Yeah this is usually why i research things a bit before assigning
>> a CVE.
>> 
>> So based on
>> 
>> https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions
>>
>>
>> 
No freshness guarantee
>> 
>> Note also that while the MAC can guarantee the authenticity of
>> the data (that it was generated by your site, and not someone
>> else), and the integrity of the data (that it is all there and
>> correct), it cannot guarantee freshness i.e. that you are being
>> sent back the last thing you sent to the client. This means that
>> for some uses of session data, the cookie backend might open you
>> up to replay attacks. Unlike other session backends which keep a
>> server-side record of each session and invalidate it when a user
>> logs out, cookie-based sessions are not invalidated when a user
>> logs out. Thus if an attacker steals a user’s cookie, he can use
>> that cookie to login as that user even if the user logs out.
>> Cookies will only be detected as ‘stale’ if they are older than
>> your SESSION_COOKIE_AGE.
>> 
>> I would say this falls into the Python Pickle() group (large red 
>> banner), a potentially dangerous feature with a large warning.
>> Ergo no CVE.
>> 
>> My one comment would be to possibly make the reply warning more 
>> prominent and also mention protecting the cookie with HTTPS
>> (wireless networks in coffee shops/etc.).
> What precisely is OpenStack going to do to ensure Django is always
> in an approved configuration (or ships in a secure configuration)?
> 
> Are there any UI warnings when moving from a secure configuration
> to a potentially insecure configuration?
> 
> Are the QA folks or Release team aware they need to inspect a
> setting and check a box?
> 
> (Forgive my ignorance - I'm still learning policy and procedures).
> 
> Jeff

I assume this would primarily be up to the people packaging and
shipping OpenStack. Having a feature to ensure it is safely configured
and if not to raise a warning in the GUI/etc. would be rgeat, feel
free to file an RFE upstream.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSTj4+AAoJEBYNRVNeJnmT7akP/1X7unKotn09nEANUkCbuFRG
JV/UyEPdrib+ZZAapxLCCAbXPZSrqsjgO6V9E8ZzF7dKYrb3EHlxScGuNW2N+Ys7
pwYtBQG9TNxoTNwyREJBGUjOfByXFB6L5TCNINBXCEDBU+ulIqWWxmqf0f5LG0KD
iCyEt98nn5Up9KS6h7XT/mGOOBrui7jTkQ0lZamrOEQxCEGBxHs9ZXLsGDvncfYK
PGmpmlf6ymRkNaSEt1BMnygsvxuvTCzgH8hqs7QhTM+3xGH1Mw7Cg4An09EmRi0x
72Eflgqh9dkCoc1BDQm48C8LRMSGkWaV/Fczo3ISARCTffarDha9eUG2yWbdzFkQ
I2vN/OOPvyL36TZ1BzEtp8GZBva99Fx92G5/mi/YAUNXDJ4dYub78V9pS2ZznYrz
BzLc87+lvyvZLSY7N7mJQnCnlYJ8Z+uPuQjI1doBUmz18bcS1WW8dOWf7tpCiiO8
j+Rgkr8i2CzthYtPFDLs/KSRkujXEl1nAX2QpmJKgymEGIMZkWQIPuKEej9IsCQJ
v2NFwUFEw019Dqj+wHCDSPjEXUJES4/V9MHxyP9wnXNXKz881aaERLZViO/o77hM
Nt2WWGqavinjVAKn7I9kFXMIHfBl5XET9NEwl2MmlszSXqIMD9QPikQllskNiu/x
+EmopAM4w2nGRZ5EjW6n
=Dvgm
-----END PGP SIGNATURE-----



From main at gsmcnamara.com  Fri Oct  4 01:29:45 2013
From: main at gsmcnamara.com (G. S. McNamara)
Date: Thu, 3 Oct 2013 21:29:45 -0400
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <CAAsS5mrETXXcm_RUWxbgVKyoRxKaMaxcukw=7hChPP+SZrp-Rg@mail.gmail.com>
References: <CAAsS5mpV0nEUWzYOnykrbAADeArOWbF-a_G5D5-UOEAWPg9c=Q@mail.gmail.com>
 <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <524E15DB.2030005@redhat.com>
 <CAAsS5mrETXXcm_RUWxbgVKyoRxKaMaxcukw=7hChPP+SZrp-Rg@mail.gmail.com>
Message-ID: <CAAsS5mosU8znb31dV2W6c5Wd327fcSrzjTp=StyT-xP35Gs65A@mail.gmail.com>

Hi everyone, sorry, I did not see that there were people CC'd on the
original email.

Following on to what I emailed in response to Kurt (included after this
email), here is the response I got when I submitted information about the
similar Ruby on Rails vulnerability to the Vulnerability Analysis Team at
the CERT(R) Coordination Center:

We appreciate you reporting this issue to us. We are tracking this issue as
VU#160862. Please be sure to include VU#160862 in the
subject when replying to this email.

Since you have already made this vulnerability public, we do not feel that
coordination is necessary at this point.
We encourage you to work directly with the Ruby on Rails security team to
resolve this issue.


Hope this helps. Again, do not hesitate to reach out for any information
you might need for the Django or Rails vulnerabilities.

Thanks!

G. S. McNamara


On Thu, Oct 3, 2013 at 9:14 PM, G. S. McNamara <main at gsmcnamara.com> wrote:

> Hi Kurt,
>
> If you could assign a CVE that would be great.
>
> I did not attempt to with this disclosure because my previous disclosure
> of a similar issue with the Ruby on Rails framework detailed here (
> http://maverickblogging.com/logout-is-broken-by-default-ruby-on-rails-web-applications/)
> was rejected on account of me publishing the information publicly.
>
> I'd love to provide you whatever information you need for the CVE.
>
>
> Thanks!
>
> G. S. McNamara
>
> Founder & Head Hustler | Inc.less, An Ideas Company | +1 (202) 507-9703 |
> Washington, D.C. | Linkedin <http://www.linkedin.com/in/GSMcNamara> |
> Twitter <https://twitter.com/GSMcNamara>
>
>
> On Thu, Oct 3, 2013 at 9:11 PM, Kurt Seifried <kseifried at redhat.com>wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 10/02/2013 03:09 AM, Jeffrey Walton wrote:
>> > Not sure if this made anyone's radar....
>> >
>> > (I'm not sure about the 1.7 version, though).
>> >
>> > ---------- Forwarded message ---------- From: G. S. McNamara
>> > <main at gsmcnamara.com> Date: Tue, Oct 1, 2013 at 4:20 PM Subject:
>> > [Full-disclosure] [Django] Cookie-based session storage session
>> > invalidation issue To: full-disclosure at lists.grok.org.uk
>> >
>> > FD,
>> >
>> > I’m back!
>> >
>> > Django versions 1.4 – 1.7 offer a cookie-based session storage
>> > option (not the default this time) that is afflicted by the same
>> > issue I posted about previously concerning Ruby on Rails:
>> >
>> > If you obtain a user’s cookie, even if they log out, you can still
>> > log in as them.
>> >
>> > The short write-up is here, if needed:
>> >
>> http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/
>> >
>> >  Cheers,
>> >
>> > G. S. McNamara
>>
>> Sounds like this needs a CVE? Has one been requested from Mitre? If
>> not I can assign it.
>>
>> https://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html
>>
>> - --
>> Kurt Seifried Red Hat Security Response Team (SRT)
>> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.14 (GNU/Linux)
>>
>> iQIcBAEBAgAGBQJSThXbAAoJEBYNRVNeJnmTeGMQAI4jnGSqKxP0vC1nPj4WAYyl
>> leYsGVX/SmZ1LX7s0KNbmbuN9ERcA5zT7ua7J0osMuPnhkODb7z/dhWuYnZARDIn
>> nVEaLJyBa6Bu7rcsasgFmuHk4BvXwnEY0ngH/i3Dz/jIxrP3atSr8uaQW8fdVtP1
>> FkVKx+NDaqEuHjJTpy8snO0UYPj9ZE/gS2Hs9ydyIRyeMGrSspdsnrzI7bxaMejq
>> pMcu41fH7kZZ3tseUyhc+oBzOzHDlWHYVuJJL/DCuk64RMOPGrp7zyLBoDF3U3gm
>> u5C85OoIpTCl5XuOE2LLO2kotfCnP2PfUdMm+KdzS9tpTkMtOc6KJFjn6MeohYKN
>> /TxT+m1rQqEmipxMbFgXc6pulZSEUWEnhy599960aoSmKUPN1Ss9sXK4ARwkfaeA
>> 04L5JLcwocc3g0uHhNayx29ilF3Jsj97SBHUEiaqoe4dBTKumFdv14b61nAJknYd
>> PA3pCq9/3j1R5r+kDK9lffPjeycL/gaqHoXTH3sTdwExFeuBTPXC0kEeqH/GngWD
>> U60cSGkr+LVH2z2AF5qRyEjGPOR0QFuE4zo072L+5fFavftgMvLvukkAXTTz/V6C
>> 9ljGyTJ+nA02NKKylAAP7hLksRuKgyQIx/dKK2Btqlb0ZlU/C1igmoyL3JVocIMt
>> 7EuS8NbgPBnQnSYuQ14I
>> =whZK
>> -----END PGP SIGNATURE-----
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131003/f6708b01/attachment.html>

From jacob at djangoproject.com  Fri Oct  4 03:24:46 2013
From: jacob at djangoproject.com (Jacob Kaplan-Moss)
Date: Thu, 3 Oct 2013 22:24:46 -0500
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <524E314D.5030700@redhat.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
 <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
 <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>
 <524E314D.5030700@redhat.com>
Message-ID: <CAK8PqJFdi5eOLW_0pqMRB79ynxQ5kDwCf9FAQHhjByBtxJepTw@mail.gmail.com>

We don't agree that this is a security vulnerability, which is why we
haven't addressed the issue. It boils down to "if someone has access to
your computer, then they can pretend to be you", which is a risk, to be
sure, but not one we can address in a web framework.

As the article states, this vulnerability depends on an attacker being able
to "find, steal, or intercept a user’s cookie". Any attacker with this
level of access has a variety of interesting options at their disposal.

Kurt, if you feel this deserves a CVE feel free. I do want to make sure
it's noted, however, that the Django team does not concur that this is a
real vulnerability.

Jacob


On Thu, Oct 3, 2013 at 10:09 PM, Kurt Seifried <kseifried at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/03/2013 08:22 PM, Jeffrey Walton wrote:
> > On Thu, Oct 3, 2013 at 6:30 PM, Jeffrey Walton <noloader at gmail.com>
> > wrote:
> >> Here's some more reading on the subject. It was recently updated,
> >> and effectively states django is susceptible to session
> >> management attacks under some configurations.
> >>
> https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-cookie-based-sessions
> .
> >
> >>
> Its now being tracked: VU#160862 (thanks Kurt).
>
> Just to be clear I didn't do anything yet. That's a US-CERT
> Vulnerability Note number, nothing to do with CVE. Did you contact the
> Django people about this issue to report it upstream yet? Adding
> security at djangoproject.com in case they haven't seen it yet.
>
> This is regarding
>
>
> http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/
>
> I'm going to assign a CVE if I can somewhat confirm a CVE hasn't been
> requested yet.
>
>
> - --
> Kurt Seifried Red Hat Security Response Team (SRT)
> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBAgAGBQJSTjFMAAoJEBYNRVNeJnmTsekP/2igBidUl26EmyQg09qOYT7S
> mYbn60jqyaH+yyBpZc6RK6bhWxK5vOrSD46l8ag7oxX3SXQNJmv8dD3ua5nMvJfH
> ynrbm9oXboU04tw3ij5Texvux2OmBqdf1wW/zONhEMO4XLP9QaT82zTINbLVMyR7
> QVPaFAYWT0Ba/QEEIbG2cJ3v14dRl9lqB/qOlsx1CrcwczqGlLYPjvhctTG4NZRW
> op6f+XrEgBb5GAd/YrQdQrKKo5vlIwVRSuSRbYFLaQZU/4gAy0rMCUjuXxO+nt8W
> 1FaXryBSjr4MBffE2ou7XDwrUSJJkqceEhEKF3mKaRLRTjXbV6/u2Slc9EtlaS9t
> k0wu8wMx7xnSsZVTldBaS4Pgh49ZiDqqxGRncb8Gy+GIAvrh3FswLNxJa7w/zDBT
> JIewqKvSiWKqgrRc2HPw2w9QWnX3OhXGRxmbTRUuEse/dlQ2OqnT7z1mPG2AmJoj
> I+tsis7btojs0OEXeyOOJVJzINWSCZcF1PAz1zwO5c4x7lA9la6dgaOKQPPFctjR
> UKq30ztQ66eXiROydt/Vz1zUgPn/KUHB34L2jyPg/otnx/TLLisCEXxXb4TL68nx
> 0WfPTVK5zRl0SqmSdizwHaCDepaexh756QGIJyRrd8br1O9GKj1Lj5g6Vx4PDiLO
> KdabNJIvEImC8HPAPwoE
> =lzjh
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131003/e8a89e9c/attachment.html>

From paul at mcmillan.ws  Fri Oct  4 03:39:33 2013
From: paul at mcmillan.ws (Paul McMillan)
Date: Fri, 4 Oct 2013 04:39:33 +0100
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <524E314D.5030700@redhat.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
 <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
 <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>
 <524E314D.5030700@redhat.com>
Message-ID: <CAO_YWRV8AWEM7M5JG3jt7=8wc67Qq1Q8gQbGG+pb6pB74-5t+g@mail.gmail.com>

Hi Kurt,

The upstream Django team would be extremely happy if you refrained
from assigning a CVE for a clearly documented security tradeoff, which
is mentioned covered in both the Django and the Horizon docs, as well
as in the Openstack Security Guide.

The upshot of this entire business is that if you rely soly on
client-side cookies, logging out deletes the cookie from a local
browser, but does not actually invalidate it until the session expiry
timeout. If you don't like this particular technical limitation using
client side sessions, you are advised not to use that cookie backend.

https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions

This does NOT deserve a CVE.

Regards,
-Paul

On Fri, Oct 4, 2013 at 4:09 AM, Kurt Seifried <kseifried at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/03/2013 08:22 PM, Jeffrey Walton wrote:
>> On Thu, Oct 3, 2013 at 6:30 PM, Jeffrey Walton <noloader at gmail.com>
>> wrote:
>>> Here's some more reading on the subject. It was recently updated,
>>> and effectively states django is susceptible to session
>>> management attacks under some configurations.
>>> https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-cookie-based-sessions.
>>
>>>
> Its now being tracked: VU#160862 (thanks Kurt).
>
> Just to be clear I didn't do anything yet. That's a US-CERT
> Vulnerability Note number, nothing to do with CVE. Did you contact the
> Django people about this issue to report it upstream yet? Adding
> security at djangoproject.com in case they haven't seen it yet.
>
> This is regarding
>
> http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/
>
> I'm going to assign a CVE if I can somewhat confirm a CVE hasn't been
> requested yet.
>
>
> - --
> Kurt Seifried Red Hat Security Response Team (SRT)
> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBAgAGBQJSTjFMAAoJEBYNRVNeJnmTsekP/2igBidUl26EmyQg09qOYT7S
> mYbn60jqyaH+yyBpZc6RK6bhWxK5vOrSD46l8ag7oxX3SXQNJmv8dD3ua5nMvJfH
> ynrbm9oXboU04tw3ij5Texvux2OmBqdf1wW/zONhEMO4XLP9QaT82zTINbLVMyR7
> QVPaFAYWT0Ba/QEEIbG2cJ3v14dRl9lqB/qOlsx1CrcwczqGlLYPjvhctTG4NZRW
> op6f+XrEgBb5GAd/YrQdQrKKo5vlIwVRSuSRbYFLaQZU/4gAy0rMCUjuXxO+nt8W
> 1FaXryBSjr4MBffE2ou7XDwrUSJJkqceEhEKF3mKaRLRTjXbV6/u2Slc9EtlaS9t
> k0wu8wMx7xnSsZVTldBaS4Pgh49ZiDqqxGRncb8Gy+GIAvrh3FswLNxJa7w/zDBT
> JIewqKvSiWKqgrRc2HPw2w9QWnX3OhXGRxmbTRUuEse/dlQ2OqnT7z1mPG2AmJoj
> I+tsis7btojs0OEXeyOOJVJzINWSCZcF1PAz1zwO5c4x7lA9la6dgaOKQPPFctjR
> UKq30ztQ66eXiROydt/Vz1zUgPn/KUHB34L2jyPg/otnx/TLLisCEXxXb4TL68nx
> 0WfPTVK5zRl0SqmSdizwHaCDepaexh756QGIJyRrd8br1O9GKj1Lj5g6Vx4PDiLO
> KdabNJIvEImC8HPAPwoE
> =lzjh
> -----END PGP SIGNATURE-----



From jacob at djangoproject.com  Fri Oct  4 03:51:14 2013
From: jacob at djangoproject.com (Jacob Kaplan-Moss)
Date: Thu, 3 Oct 2013 22:51:14 -0500
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <524E3A9A.2000308@redhat.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
 <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
 <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>
 <524E314D.5030700@redhat.com>
 <CAO_YWRV8AWEM7M5JG3jt7=8wc67Qq1Q8gQbGG+pb6pB74-5t+g@mail.gmail.com>
 <524E3A9A.2000308@redhat.com>
Message-ID: <CAK8PqJHC_moTsZJzhfDGCVP-poGfEyNNU++FoxxVc-uq9NB58A@mail.gmail.com>

On Thu, Oct 3, 2013 at 10:48 PM, Kurt Seifried <kseifried at redhat.com> wrote:

> My one comment would be to possibly make the reply warning more
>  prominent and also mention protecting the cookie with HTTPS (wireless
> networks in coffee shops/etc.).


That's a good idea; we talk about cookie security and HTTPS elsewhere, but
it's probably worth re-mentioning right there, too. Thanks for the
suggestion!

Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131003/7ed867f1/attachment.html>

From paul at mcmillan.ws  Fri Oct  4 04:19:07 2013
From: paul at mcmillan.ws (Paul McMillan)
Date: Fri, 4 Oct 2013 05:19:07 +0100
Subject: [Openstack-security] Fwd: [Full-disclosure] [Django]
 Cookie-based session storage session invalidation issue
In-Reply-To: <CAH8yC8m1909uT4Hbw1qwodUM-eeNyKS+KQ=M1-cNt8w-ZKFOaA@mail.gmail.com>
References: <CAH8yC8m_75620J7asEHDTA1qYvbgZ2jtuxKHqtZV2WdhUKH5xA@mail.gmail.com>
 <CE71FE82.343A8%robert.clark@hp.com>
 <CAH8yC8=8_o_h4yRKBOCtm8skUuHe7zKvKE3rTdGighSaHVk99A@mail.gmail.com>
 <CAH8yC8k7z=-Hy-AZDNXd_WUSJB6y5wr44C1GBMZ6N-4_ss4P-g@mail.gmail.com>
 <524E314D.5030700@redhat.com>
 <CAO_YWRV8AWEM7M5JG3jt7=8wc67Qq1Q8gQbGG+pb6pB74-5t+g@mail.gmail.com>
 <524E3A9A.2000308@redhat.com>
 <CAH8yC8m1909uT4Hbw1qwodUM-eeNyKS+KQ=M1-cNt8w-ZKFOaA@mail.gmail.com>
Message-ID: <CAO_YWRWdPrCRSZ2YiiXibeAs5GQpGeXsP3wjAAsFu7KPde58QA@mail.gmail.com>

> Are the QA folks or Release team aware they need to inspect a setting
> and check a box?

As an application security specialist, I'm sure you realize that this
is something only the local systems administrator can determine. Since
openstack is not shipped as a plug-and-play software product, it
requires a certain amount of configuration. Part of that configuration
will of course be reviewing settings and making correct security
decisions.

In this particular case, if you deploy multiple Horizon instances and
you choose not to use the cookie-based session store, you have to
configure a shared session storage backend before it works correctly
at all. Configuring and deploying this is not a matter of a simple
checkbox. Similarly, if you want the best security, you deploy with
HTTPS, HSTS, and CSP. Each of these require individual configuration,
and cannot easily be encompassed in a "make me secure" checkbox. The
openstack security guide was written to help deployers make correct
decisions, and is a good place to start.

http://docs.openstack.org/sec/

 Each deployment will be slightly different, and nothing can
substitute for a careful security review by competent professionals.

-Paul



From robert.clark at hp.com  Fri Oct  4 14:07:12 2013
From: robert.clark at hp.com (Clark, Robert Graham)
Date: Fri, 4 Oct 2013 14:07:12 +0000
Subject: [Openstack-security] Python SSL vulnerability
Message-ID: <CE748A1F.34936%robert.clark@hp.com>

Hi Guys,

Worth flagging this here in case anyone missed it, I thought we were past the NULL Cname issues in SSL libraries, I guess not:

http://www.ubuntu.com/usn/usn-1983-1/

-Rob



From davanum at gmail.com  Fri Oct  4 14:07:43 2013
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Fri, 04 Oct 2013 14:07:43 -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: <20131004140743.29617.59522.malone@chaenomeles.canonical.com>

Review is here https://review.openstack.org/#/c/49664/

** Changed in: nova
     Assignee: GuoHui LIu (guohliu) => Davanum Srinivas (DIMS) (dims-v)

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

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

Status in OpenStack Compute (Nova):
  In Progress

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 kseifried at redhat.com  Fri Oct  4 16:00:31 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Fri, 04 Oct 2013 10:00:31 -0600
Subject: [Openstack-security] Python SSL vulnerability
In-Reply-To: <CE748A1F.34936%robert.clark@hp.com>
References: <CE748A1F.34936%robert.clark@hp.com>
Message-ID: <524EE61F.60708@redhat.com>

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

On 10/04/2013 08:07 AM, Clark, Robert Graham wrote:
> Hi Guys,
> 
> Worth flagging this here in case anyone missed it, I thought we
> were past the NULL Cname issues in SSL libraries, I guess not:
> 
> http://www.ubuntu.com/usn/usn-1983-1/
> 
> -Rob

To put it bluntly, almost everything that handles SSL does it wrong in
some way. Some have been mostly fixed, but I suspect there are new
classes of attacks. SSL is bad for failure scenarios too, you have to
intentionally mangle things quite badly (certificates/etc.) and things
may just keep working, but in an insecure manner that is non obvious.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSTuYfAAoJEBYNRVNeJnmTe2IQAIiacgFfYeCCtpAAARMia7RS
F0vxKo504Bf2zIZJHsp2rBp6Ow2NqOIZ5niJ3S/1OKWX8IHjnRbbBXbc2ZS6DQcK
amTZQWklNudTdmANSEKHKp+E7fJuTdyMbQyolQ2Xkup/GWC65DnefnfO1Gh6g+Ou
rpmbJNeorZfz7yeCci+TFLBYSwYF8hr7RH5y74n3R6X7ZQBvLU7CmGeCtuwHwDO5
X4pjn1MxLJ9Aybfkn7GbSfP3ipU1aAk+WnVDUABQxSb6qrAgmSQtIciRcceWH0VM
cvd5tYrclWgoa7roFHc9Ryiz3H6rU7LKNZqTPUGUxwBwc1cNPpw2nQtri7LLTe9O
t2sM91RvKIcQJSKAQ/dgYG2krodT7fKOa1Tt+WNlkttZOKtQcl7fkO7Z66eDBQQU
jc1hPXYvcrV6pyOawOH24o8J8MpwP5PG/dJ5YiagUuNrztbc5fVksCncwGG2KEYs
8eHUM/6U2tvNQcAAmqn+rU66uprPD3Y//EVoldLazZ8ymBQkt4nmlAFpm76gyudq
//Q6rrMFGPwRl5WuJjKVFRVlPPVAWgM5aMuBw1LGhecAVCZHepTFyOJOV0EOAYIs
lYJybqPw+wHZqMlVONzjuKpdna21wN+rISagdY0cfHfZvzZFUV5Gg+v1GkY/Z7Ez
bhoEjnZdbGaKSSl2vGrW
=vgbc
-----END PGP SIGNATURE-----



From noloader at gmail.com  Fri Oct  4 19:02:38 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 4 Oct 2013 15:02:38 -0400
Subject: [Openstack-security] Python SSL vulnerability
In-Reply-To: <CE748A1F.34936%robert.clark@hp.com>
References: <CE748A1F.34936%robert.clark@hp.com>
Message-ID: <CAH8yC8=KY=y09Qzvhr5DpVFdgTevxJbmr-xXXhO0VW6+WUL-jQ@mail.gmail.com>

On Fri, Oct 4, 2013 at 10:07 AM, Clark, Robert Graham
<robert.clark at hp.com> wrote:
> Hi Guys,
>
> Worth flagging this here in case anyone missed it, I thought we were past the NULL Cname issues in SSL libraries, I guess not:
>
> http://www.ubuntu.com/usn/usn-1983-1/
Yeah, I was surprised to see Moxie's NULL trick still being used
considering it dates back to 2009
(http://hackaday.com/2009/07/29/black-hat-2009-breaking-ssl-with-null-characters/).

I think CVE-2013-2099 is a little different, though. Python has a
history of hostname matching problems (cf, rejected bug report at
http://bugs.python.org/issue1589); and OpenSSL does not perform
hostname checking at the moment (its in HEAD and slated for OpenSSL
1.1.0).

I believe Squid and/or libcurl has test certificates built for testing
those adverse conditions (I'm fairly certain about libcurl, but I
can't find Daniel's post at the moment).

Jeff



From creffett at gentoo.org  Wed Oct  2 03:55:37 2013
From: creffett at gentoo.org (Chris Reffett)
Date: Wed, 02 Oct 2013 03:55:37 -0000
Subject: [Openstack-security] [Bug 1168252]
References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com>
Message-ID: <20131006062240.16447.76394.launchpad@loganberry.canonical.com>

We're done 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/1168252

Title:
  keystone.conf should not be world-readable (to keep LDAP password and
  admin_token secret)

Status in devstack - openstack dev environments:
  Confirmed
Status in OpenStack Security Notes:
  Fix Released
Status in Gentoo Linux:
  Fix Released

Bug description:
  The password configuration of LDAP and admin_token in keystone.conf
  should be secret to protect security information:

  [ldap]
  # url = ldap://localhost
  # user = dc=Manager,dc=example,dc=com
  # password = None                                            <- should be secrect
  # suffix = cn=example,cn=com
  # use_dumb_member = False
  # allow_subtree_delete = False
  # dumb_member = cn=dumb,dc=example,dc=com

  
  [DEFAULT]
  admin_token = passw0rd                                <- should be secrect

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



From 1168252 at bugs.launchpad.net  Sun Oct  6 06:22:37 2013
From: 1168252 at bugs.launchpad.net (Bug Watch Updater)
Date: Sun, 06 Oct 2013 06:22:37 -0000
Subject: [Openstack-security] [Bug 1168252] Re: keystone.conf should not be
	world-readable (to keep	LDAP password and admin_token secret)
References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com>
Message-ID: <20131006062239.16447.28971.launchpad@loganberry.canonical.com>

** Changed in: gentoo
       Status: Unknown => 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/1168252

Title:
  keystone.conf should not be world-readable (to keep LDAP password and
  admin_token secret)

Status in devstack - openstack dev environments:
  Confirmed
Status in OpenStack Security Notes:
  Fix Released
Status in Gentoo Linux:
  Fix Released

Bug description:
  The password configuration of LDAP and admin_token in keystone.conf
  should be secret to protect security information:

  [ldap]
  # url = ldap://localhost
  # user = dc=Manager,dc=example,dc=com
  # password = None                                            <- should be secrect
  # suffix = cn=example,cn=com
  # use_dumb_member = False
  # allow_subtree_delete = False
  # dumb_member = cn=dumb,dc=example,dc=com

  
  [DEFAULT]
  admin_token = passw0rd                                <- should be secrect

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



From thierry.carrez+lp at gmail.com  Thu Oct 10 09:08:52 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 10 Oct 2013 09:08:52 -0000
Subject: [Openstack-security] [Bug 1236675] Re: Keystone getting oauth
	access token by	brute-forcing oauth_verifier code
References: <20131008030759.26826.41914.malonedeb@chaenomeles.canonical.com>
Message-ID: <20131010090853.11529.87116.launchpad@gac.canonical.com>

** Information type changed from Private Security to Public

** No longer affects: ossa

** Tags added: security

** Tags added: havana-rc-potential

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

Title:
  Keystone getting oauth access token by brute-forcing oauth_verifier
  code

Status in OpenStack Identity (Keystone):
  Confirmed

Bug description:
  Title: Keystone getting oauth access token by brute-forcing
  oauth_verifier code
  Reporter: Phuong Cao
  Products: openstack/keystone
  Affects: keystone/master branch as of Oct 7th 2013

  Description:
  Phuong Cao reported a vulnerability in OAuth SQL backend of
  keystone/master branch.

  How does the attack work?
  By creating many access token requests with oauth_verifier code selected
  from the range 1000 to 9999,
  an attacker can request a valid access token to a role and a project,
  overriding a user who actually request access to the role and the project.

  Before describing in detail how the attack works, this is how OAuth
  works (summarized from RFC5849)

  1. Alice registers as a consumer with the Openstack admin.
  2. Alice asks the Openstack admin a token with a specified role and a
  project on behalf of Bob (Bob is the owner of the project).
  3. The Openstack admin returns to Alice a request token key.
  4. Alice sends the request token key to Bob to ask for permissions to
  access the project.
  5. Bob authorizes Alice's request token to have access to the project
  with the specified role.
  6. Bob generates an oauth_verifier code ranging from 1000 to 9999, then
  sends back to Alice an oauth_verifier code.
  7. Alice use the oauth_verifier code and the request token key to ask
  the Openstack admin for the access token to the project.

  This is how the attack works:
  At step 4, assuming an attacker can sniff Alice's request token key.
  This can be done by acting as a man in the middle if Alice interacts
  with Keystone using HTTP requests,
  or acting as a local user to list the process arguments if Alice is
  interacts with Keystone using openstack commandline tools (this case is
  similar to CVE 2013-2013).

  Now the attacker has Alice's request token key, he/she need to wait for
  Bob to authorizes Alice's request token (step 5), then repeatedly
  brute-forcing Keystone with the pair(oauth_verifier, Alice's request
  token key) using oauth_verifier from the range 1000 to 9999. Since the
  oauth_verifier is in a short range, and Openstack/Keystone doesn't have
  any mechanism to limit number of requests, the attacker can bruteforce
  for the valid oauth_verifier key until the request token expires.

  A more aggressive way is to keep brute-forcing Keystone until Bob
  authorizes Alice's request token, by doing this the attacker will have
  more chance getting the access token key before Alice.

  Where are the vulnerable code locations?
  Line 210 of sql.py file:
  https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210

  In OAuth SQL backend of keystone/master branch, the oauth_verifier code,
  a fundamental part of OAuth1 protocol, is generated using random numbers
  from 1000 to 9999.
  This is a small range of numbers and it is easy to be guessed/brute-forced.
  This attack is classified as "CWE-330: Use of Insufficiently Random
  Values" (http://cwe.mitre.org/data/definitions/330.html).

  What are the possible fixes?
  We suggest using a long random string (e.g., 32-bit or 64-bit). Using
  os.urandom() is a good one, it has been recommended for generating
  random number for cryptographic purposes.
  A patch is attached in the attached file (please note: we haven't tested
  this patch).

  Where is the exploit code?
  We attach a snippet code that we modify from test_bad_verifier()
  Keystone test case.
  The snippet is a sketch of how oauth_verifier code brute-forcing can be
  implemented.

  What is the affected version?
  The keystone/master on github as of Oct 7th 2013 is affected.

  References:
  Link to oauth1 file and vulnerable code location (sql.py, line #210):
  https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210
  CWE-330: Use of Insufficiently Random Values:
  (http://cwe.mitre.org/data/definitions/330.html).
  RFC5849: http://tools.ietf.org/html/rfc5849
  os.urandom(): http://docs.python.org/2/library/os.html
  OAuth in keystone tutorial:
  http://www.unitedstack.com/blog/oauth-in-keystone/

  # Patch
  --- /tmp/keystone/keystone/contrib/oauth1/backends/sql.py       2013-10-07 17:06:04.170603933 -0500
  +++ /home/vagrant/keystone/keystone/contrib/oauth1/backends/sql.py      2013-10-07 17:01:39.124008733 -0500
  @@ -17,6 +17,8 @@
   import datetime
   import random
   import uuid
  +import os
  +import binascii

   from keystone.common import sql
   from keystone.common.sql import migration
  @@ -207,7 +209,7 @@
               token_ref = self._get_request_token(session, request_token_id)
               token_dict = token_ref.to_dict()
               token_dict['authorizing_user_id'] = user_id
  -            token_dict['verifier'] = str(random.randint(1000, 9999))
  +            token_dict['verifier'] = binascii.b2a_hex(os.urandom(16))
               token_dict['role_ids'] = jsonutils.dumps(role_ids)

               new_token = RequestToken.from_dict(token_dict)

  # Test brute force
  class MaliciousOAuth1Tests(OAuth1Tests):

      # modified from test_bad_verifier()
      def test_bruteforce_verifier(self):
          
          # create consumer for oauth
          consumer = self._create_single_consumer()
          consumer_id = consumer.get('id')
          consumer_secret = consumer.get('secret')
          consumer = oauth1.Consumer(consumer_id, consumer_secret)

          url, headers = self._create_request_token(consumer,
                                                    self.project_id)
          # get request token
          content = self.post(url, headers=headers)
          credentials = urlparse.parse_qs(content.result)
          request_key = credentials.get('oauth_token')[0]
          request_secret = credentials.get('oauth_token_secret')[0]
          request_token = oauth1.Token(request_key, request_secret)

  
          # authorize request token
          url = self._authorize_request_token(request_key)
          
          body = {'roles': [{'id': self.role_id}]}
          resp = self.put(url, body=body, expected_status=200)
          verifier = resp.result['token']['oauth_verifier']
          self.assertIsNotNone(verifier)

          # we are not going to use received oauth_verifier here, instead, we brute-force to find the valid oauth_verifier
          for i in range(1000,10000):
              request_token.set_verifier(str(i))
              url, headers = self._create_access_token(consumer,
                                                       request_token)
              # We expect 401 status code for most of requests since most oauth_verifier code
              # that we try will be invalid.
              # The test will crash at the valid oauth_verifier code when returned status = 201,
              # which is different from the expected 401 status.
              r = self.post(url, headers=headers, expected_status=401)
              
              # Print out oauth_verifier, and raw response request that contains access token.
              if (r == 201): # We have found correct oauth_verifier code
                  print 'oauth_verifier: {}, raw access_token response request: {}'.format(str(i), str(r))

  
  We are looking forward hearing from you.

  Thank you.

  Best,

  Phuong Cao
  Research Assistant
  DEPEND group
  Coordinated Science Laboratory
  University of Illinois at Urbana Champaign
  Urbana, IL 61801, USA

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



From Numero.8 at free.fr  Thu Oct 10 20:04:02 2013
From: Numero.8 at free.fr (Numero 8)
Date: Thu, 10 Oct 2013 20:04:02 -0000
Subject: [Openstack-security] [Bug 1004114] Re: Password logging
References: <20120524190215.26515.18198.malonedeb@gac.canonical.com>
Message-ID: <20131010200405.11451.46129.launchpad@gac.canonical.com>

** Changed in: python-keystoneclient
     Assignee: Numero 8 (numero-8) => (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/1004114

Title:
  Password logging

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

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

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

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

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

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

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



From davanum at gmail.com  Mon Oct 14 12:59:12 2013
From: davanum at gmail.com (Davanum Srinivas (DIMS))
Date: Mon, 14 Oct 2013 12:59:12 -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: <20131014125914.28189.69237.launchpad@chaenomeles.canonical.com>

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

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

Status in OpenStack Compute (Nova):
  In Progress

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  Mon Oct 14 14:29:24 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 14 Oct 2013 14:29:24 -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: <20131014142926.15499.33868.launchpad@soybean.canonical.com>

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

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

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

Status in OpenStack Compute (Nova):
  In Progress

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  Mon Oct 14 14:26:55 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 14 Oct 2013 14:26:55 -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: <20131014142657.15812.4978.launchpad@soybean.canonical.com>

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

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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  Tue Oct 15 07:13:20 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Tue, 15 Oct 2013 07:13:20 -0000
Subject: [Openstack-security] [Bug 1236675] Re: Keystone getting oauth
	access token by	brute-forcing oauth_verifier code
References: <20131008030759.26826.41914.malonedeb@chaenomeles.canonical.com>
Message-ID: <20131015071321.30749.42912.launchpad@wampee.canonical.com>

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

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

Title:
  Keystone getting oauth access token by brute-forcing oauth_verifier
  code

Status in OpenStack Identity (Keystone):
  Confirmed

Bug description:
  Title: Keystone getting oauth access token by brute-forcing
  oauth_verifier code
  Reporter: Phuong Cao
  Products: openstack/keystone
  Affects: keystone/master branch as of Oct 7th 2013

  Description:
  Phuong Cao reported a vulnerability in OAuth SQL backend of
  keystone/master branch.

  How does the attack work?
  By creating many access token requests with oauth_verifier code selected
  from the range 1000 to 9999,
  an attacker can request a valid access token to a role and a project,
  overriding a user who actually request access to the role and the project.

  Before describing in detail how the attack works, this is how OAuth
  works (summarized from RFC5849)

  1. Alice registers as a consumer with the Openstack admin.
  2. Alice asks the Openstack admin a token with a specified role and a
  project on behalf of Bob (Bob is the owner of the project).
  3. The Openstack admin returns to Alice a request token key.
  4. Alice sends the request token key to Bob to ask for permissions to
  access the project.
  5. Bob authorizes Alice's request token to have access to the project
  with the specified role.
  6. Bob generates an oauth_verifier code ranging from 1000 to 9999, then
  sends back to Alice an oauth_verifier code.
  7. Alice use the oauth_verifier code and the request token key to ask
  the Openstack admin for the access token to the project.

  This is how the attack works:
  At step 4, assuming an attacker can sniff Alice's request token key.
  This can be done by acting as a man in the middle if Alice interacts
  with Keystone using HTTP requests,
  or acting as a local user to list the process arguments if Alice is
  interacts with Keystone using openstack commandline tools (this case is
  similar to CVE 2013-2013).

  Now the attacker has Alice's request token key, he/she need to wait for
  Bob to authorizes Alice's request token (step 5), then repeatedly
  brute-forcing Keystone with the pair(oauth_verifier, Alice's request
  token key) using oauth_verifier from the range 1000 to 9999. Since the
  oauth_verifier is in a short range, and Openstack/Keystone doesn't have
  any mechanism to limit number of requests, the attacker can bruteforce
  for the valid oauth_verifier key until the request token expires.

  A more aggressive way is to keep brute-forcing Keystone until Bob
  authorizes Alice's request token, by doing this the attacker will have
  more chance getting the access token key before Alice.

  Where are the vulnerable code locations?
  Line 210 of sql.py file:
  https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210

  In OAuth SQL backend of keystone/master branch, the oauth_verifier code,
  a fundamental part of OAuth1 protocol, is generated using random numbers
  from 1000 to 9999.
  This is a small range of numbers and it is easy to be guessed/brute-forced.
  This attack is classified as "CWE-330: Use of Insufficiently Random
  Values" (http://cwe.mitre.org/data/definitions/330.html).

  What are the possible fixes?
  We suggest using a long random string (e.g., 32-bit or 64-bit). Using
  os.urandom() is a good one, it has been recommended for generating
  random number for cryptographic purposes.
  A patch is attached in the attached file (please note: we haven't tested
  this patch).

  Where is the exploit code?
  We attach a snippet code that we modify from test_bad_verifier()
  Keystone test case.
  The snippet is a sketch of how oauth_verifier code brute-forcing can be
  implemented.

  What is the affected version?
  The keystone/master on github as of Oct 7th 2013 is affected.

  References:
  Link to oauth1 file and vulnerable code location (sql.py, line #210):
  https://github.com/openstack/keystone/blob/master/keystone/contrib/oauth1/backends/sql.py#L210
  CWE-330: Use of Insufficiently Random Values:
  (http://cwe.mitre.org/data/definitions/330.html).
  RFC5849: http://tools.ietf.org/html/rfc5849
  os.urandom(): http://docs.python.org/2/library/os.html
  OAuth in keystone tutorial:
  http://www.unitedstack.com/blog/oauth-in-keystone/

  # Patch
  --- /tmp/keystone/keystone/contrib/oauth1/backends/sql.py       2013-10-07 17:06:04.170603933 -0500
  +++ /home/vagrant/keystone/keystone/contrib/oauth1/backends/sql.py      2013-10-07 17:01:39.124008733 -0500
  @@ -17,6 +17,8 @@
   import datetime
   import random
   import uuid
  +import os
  +import binascii

   from keystone.common import sql
   from keystone.common.sql import migration
  @@ -207,7 +209,7 @@
               token_ref = self._get_request_token(session, request_token_id)
               token_dict = token_ref.to_dict()
               token_dict['authorizing_user_id'] = user_id
  -            token_dict['verifier'] = str(random.randint(1000, 9999))
  +            token_dict['verifier'] = binascii.b2a_hex(os.urandom(16))
               token_dict['role_ids'] = jsonutils.dumps(role_ids)

               new_token = RequestToken.from_dict(token_dict)

  # Test brute force
  class MaliciousOAuth1Tests(OAuth1Tests):

      # modified from test_bad_verifier()
      def test_bruteforce_verifier(self):
          
          # create consumer for oauth
          consumer = self._create_single_consumer()
          consumer_id = consumer.get('id')
          consumer_secret = consumer.get('secret')
          consumer = oauth1.Consumer(consumer_id, consumer_secret)

          url, headers = self._create_request_token(consumer,
                                                    self.project_id)
          # get request token
          content = self.post(url, headers=headers)
          credentials = urlparse.parse_qs(content.result)
          request_key = credentials.get('oauth_token')[0]
          request_secret = credentials.get('oauth_token_secret')[0]
          request_token = oauth1.Token(request_key, request_secret)

  
          # authorize request token
          url = self._authorize_request_token(request_key)
          
          body = {'roles': [{'id': self.role_id}]}
          resp = self.put(url, body=body, expected_status=200)
          verifier = resp.result['token']['oauth_verifier']
          self.assertIsNotNone(verifier)

          # we are not going to use received oauth_verifier here, instead, we brute-force to find the valid oauth_verifier
          for i in range(1000,10000):
              request_token.set_verifier(str(i))
              url, headers = self._create_access_token(consumer,
                                                       request_token)
              # We expect 401 status code for most of requests since most oauth_verifier code
              # that we try will be invalid.
              # The test will crash at the valid oauth_verifier code when returned status = 201,
              # which is different from the expected 401 status.
              r = self.post(url, headers=headers, expected_status=401)
              
              # Print out oauth_verifier, and raw response request that contains access token.
              if (r == 201): # We have found correct oauth_verifier code
                  print 'oauth_verifier: {}, raw access_token response request: {}'.format(str(i), str(r))

  
  We are looking forward hearing from you.

  Thank you.

  Best,

  Phuong Cao
  Research Assistant
  DEPEND group
  Coordinated Science Laboratory
  University of Illinois at Urbana Champaign
  Urbana, IL 61801, USA

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



From jamielennox at redhat.com  Tue Oct 15 20:43:41 2013
From: jamielennox at redhat.com (Jamie Lennox)
Date: Tue, 15 Oct 2013 20:43:41 -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: <20131015204348.28096.26702.launchpad@chaenomeles.canonical.com>

** Changed in: python-keystoneclient
       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:
  Fix Released
Status in OpenStack Object Storage (Swift):
  Invalid

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

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

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

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

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

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



From gerrit2 at review.openstack.org  Tue Oct 15 23:49:55 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Tue, 15 Oct 2013 23:49:55 +0000
Subject: [Openstack-security] [openstack/python-novaclient] SecurityImpact
 review request change Ib0ccaf5517e1bbdf723748dbc192d2565f5780fc
Message-ID: <E1VWEN9-0004kq-As@review.openstack.org>


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

Log:
commit 3f153182aec7997999a9cc510c4d9c056d0aaa96
Author: Joe Gordon <joe.gordon0 at gmail.com>
Date:   Thu Oct 10 08:31:37 2013 +0000

    Don't use EncryptedKeyring backend use PlaintextKeyring instead
    
    If EncryptedKeyring, there is no long running keyring and a
    password is required every time novaclient is run. But we already
    keep the keystone password in a plaintext file so this results
    in worse usability and no extra security.
    
    SecurityImpact
    
    Change-Id: Ib0ccaf5517e1bbdf723748dbc192d2565f5780fc




From 1231263 at bugs.launchpad.net  Wed Oct 16 03:02:11 2013
From: 1231263 at bugs.launchpad.net (OpenStack Infra)
Date: Wed, 16 Oct 2013 03:02:11 -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: <20131016030211.11243.9859.malone@gac.canonical.com>

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

commit c6d82083295e9b1b42f22d3a2d25a1ab7d341a13
Author: Davanum Srinivas <dims at linux.vnet.ibm.com>
Date:   Thu Oct 3 22:28:58 2013 -0400

    Sanitize passwords when logging payload in wsgi
    
    adminPass (or admin_pass) can be either part of a json object or
    an xml element or xml attribute. The patch includes
    regexps to support all these cases and adds tests
    as well
    
    Change-Id: Ic119f986a03863c1d13b566b4c005f3bc77d83d0
    Closes-Bug: 1231263


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

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

Status in OpenStack Compute (Nova):
  Fix Committed

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

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

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

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



From thierry.carrez+lp at gmail.com  Thu Oct 17 09:18:45 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 09:18:45 -0000
Subject: [Openstack-security] [Bug 1195431] Re: kombu_ssl_version is a
	cfg.StrOpt but the ssl	socket code requires an Integer value
References: <20130627190934.25966.77326.malonedeb@soybean.canonical.com>
Message-ID: <20131017091846.28096.15985.launchpad@chaenomeles.canonical.com>

** Changed in: oslo
    Milestone: havana-2 => 2013.2

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

Title:
  kombu_ssl_version is a cfg.StrOpt but the ssl socket code requires an
  Integer value

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

Bug description:
  When specifying 'kombu_ssl_version' for the RPC driver such as either
  "kombu_ssl_version=3" or "kombu_ssl_version=SSLv3" the relevant
  OpenStack service (nova, cinder, etc) will fail with the following
  traceback:

  2013-06-27 15:05:30.257 CRITICAL cinder [-] an integer is required
  2013-06-27 15:05:30.257 TRACE cinder Traceback (most recent call last):
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/bin/cinder-scheduler", line 50, in <module>
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 624, in wait
  2013-06-27 15:05:30.257 TRACE cinder     _launcher.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 135, in wait
  2013-06-27 15:05:30.257 TRACE cinder     service.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 168, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return self._exit_event.wait()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/event.py", line 116, in wait
  2013-06-27 15:05:30.257 TRACE cinder     return hubs.get_hub().switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 187, in switch
  2013-06-27 15:05:30.257 TRACE cinder     return self.greenlet.switch()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/greenthread.py", line 194, in main
  2013-06-27 15:05:30.257 TRACE cinder     result = function(*args, **kwargs)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 96, in run_server
  2013-06-27 15:05:30.257 TRACE cinder     server.start()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/service.py", line 359, in start
  2013-06-27 15:05:30.257 TRACE cinder     self.manager.init_host()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 62, in init_host
  2013-06-27 15:05:30.257 TRACE cinder     self.request_service_capabilities(ctxt)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/scheduler/manager.py", line 141, in request_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     volume_rpcapi.VolumeAPI().publish_service_capabilities(context)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/volume/rpcapi.py", line 133, in publish_service_capabilities
  2013-06-27 15:05:30.257 TRACE cinder     version='1.2')
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/proxy.py", line 142, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc.fanout_cast(context, self._get_topic(topic), msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/__init__.py", line 179, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     return _get_impl().fanout_cast(CONF, context, topic, msg)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 812, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     rpc_amqp.get_connection_pool(conf, Connection))
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 635, in fanout_cast
  2013-06-27 15:05:30.257 TRACE cinder     with ConnectionContext(conf, connection_pool) as conn:
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 122, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.connection = connection_pool.get()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/pools.py", line 119, in get
  2013-06-27 15:05:30.257 TRACE cinder     created = self.create()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/amqp.py", line 76, in create
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection_cls(self.conf)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 447, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.reconnect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 519, in reconnect
  2013-06-27 15:05:30.257 TRACE cinder     self._connect(params)
  2013-06-27 15:05:30.257 TRACE cinder   File "/opt/stack/cinder/cinder/openstack/common/rpc/impl_kombu.py", line 495, in _connect
  2013-06-27 15:05:30.257 TRACE cinder     self.connection.connect()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 246, in connect
  2013-06-27 15:05:30.257 TRACE cinder     return self.connection
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 761, in connection
  2013-06-27 15:05:30.257 TRACE cinder     self._connection = self._establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/connection.py", line 720, in _establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     conn = self.transport.establish_connection()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/kombu-2.5.11-py2.7.egg/kombu/transport/pyamqp.py", line 110, in establish_connection
  2013-06-27 15:05:30.257 TRACE cinder     **conninfo.transport_options or {})
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/connection.py", line 136, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self.transport = create_transport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 252, in create_transport
  2013-06-27 15:05:30.257 TRACE cinder     return SSLTransport(host, connect_timeout, ssl)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 170, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(SSLTransport, self).__init__(host, connect_timeout)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 105, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     self._setup_transport()
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/local/lib/python2.7/dist-packages/amqp-1.0.12-py2.7.egg/amqp/transport.py", line 178, in _setup_transport
  2013-06-27 15:05:30.257 TRACE cinder     self.sslobj = ssl.wrap_socket(self.sock, **self.sslopts)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 288, in wrap_socket
  2013-06-27 15:05:30.257 TRACE cinder     return GreenSSLSocket(sock, *a, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/dist-packages/eventlet/green/ssl.py", line 46, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     super(GreenSSLSocket, self).__init__(sock.fd, *args, **kw)
  2013-06-27 15:05:30.257 TRACE cinder   File "/usr/lib/python2.7/ssl.py", line 197, in __init__
  2013-06-27 15:05:30.257 TRACE cinder     ciphers)
  2013-06-27 15:05:30.257 TRACE cinder TypeError: an integer is required

  This is because the underlying rpc driver is trying to create an SSL
  socket which requires an integer such as the following built-in SSL
  integer constants:

  PROTOCOL_SSLv2
  PROTOCOL_SSLv3
  PROTOCOL_SSLv23
  PROTOCOL_TLSv1

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



From thierry.carrez+lp at gmail.com  Thu Oct 17 09:19:44 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 09:19:44 -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: <20131017091946.28321.83481.launchpad@chaenomeles.canonical.com>

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

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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 Oct 17 10:04:44 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 10:04:44 -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: <20131017100446.15734.4803.launchpad@soybean.canonical.com>

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

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

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

Status in Orchestration API (Heat):
  Fix Released

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 thierry.carrez+lp at gmail.com  Thu Oct 17 10:02:06 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 10:02:06 -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: <20131017100208.27758.30687.launchpad@chaenomeles.canonical.com>

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

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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 thierry.carrez+lp at gmail.com  Thu Oct 17 11:35:51 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 11:35:51 -0000
Subject: [Openstack-security] [Bug 1174608] Re: [OSSA 2013-010] Insecure
	directory creation for	signing
References: <20130430050543.22381.28885.malonedeb@chaenomeles.canonical.com>
Message-ID: <20131017113554.31222.40123.launchpad@wampee.canonical.com>

** Changed in: nova
    Milestone: havana-1 => 2013.2

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

Title:
  [OSSA 2013-010] Insecure directory creation for signing

Status in OpenStack Identity (Keystone):
  Invalid
Status in Keystone folsom series:
  Fix Committed
Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) folsom series:
  Fix Committed
Status in OpenStack Compute (nova) grizzly series:
  Fix Released
Status in OpenStack Security Advisories:
  Fix Released
Status in Python client library for Keystone:
  Fix Released

Bug description:
  Originally found by Grant Murphy (gmurphy at redhat.com):

  The signing directory is used to store the signing certificates
  and the default location for this directory is:

      signing_dir = /tmp/keystone-signing-nova

  In the file:

     keystone/middleware/auth_token.py

  During the initialization of the AuthMiddleware the following
  operations are made for the signing directory:

      IF the directory exists but cannot be written to a configuration error is raised.
      ELSE IF the directory doesn't exist, create it.
      NEXT chmod permisions(stat.S_IRWXU) to the signing_directory

  AFAICT The signing certificates used in validation will only be
  fetched from the keystone if the cms_verify action raises an exception
  because the certificate file is missing from the signing directory.

  This means that if an attacker populated the /tmp/keystone-signing-nova
  with the appropriate files for signautre verification they could potentially
  issue forged tokens which would be validated by the middleware. As:
      - The directory location deterministic. (default for glance, nova)
      - *If the directory already exists it is reused*

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



From thierry.carrez+lp at gmail.com  Thu Oct 17 12:00:29 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 12:00:29 -0000
Subject: [Openstack-security] [Bug 1210869] Re: Ratelimiting not working
References: <20130810211701.1599.34997.malonedeb@soybean.canonical.com>
Message-ID: <20131017120032.15812.34077.launchpad@soybean.canonical.com>

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

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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 thierry.carrez+lp at gmail.com  Thu Oct 17 12:38:52 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 12:38:52 -0000
Subject: [Openstack-security] [Bug 1178032] Re: ldap driver returns hashed
	passwords
References: <20130509001314.14958.69418.malonedeb@gac.canonical.com>
Message-ID: <20131017123854.15812.25489.launchpad@soybean.canonical.com>

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

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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 Oct 17 12:41:10 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 12:41:10 -0000
Subject: [Openstack-security] [Bug 1175906] Re: passlib: long passwords
	trigger long checks
References: <20130503065128.15095.65477.malonedeb@gac.canonical.com>
Message-ID: <20131017124113.31257.79234.launchpad@wampee.canonical.com>

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

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

Title:
  passlib: long passwords trigger long checks

Status in OpenStack Identity (Keystone):
  Fix Released
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 thierry.carrez+lp at gmail.com  Thu Oct 17 12:35:57 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 12:35:57 -0000
Subject: [Openstack-security] [Bug 1172195] Re: admin_token and LDAP
	password show up in log in	DEBUG mode
References: <20130424091037.5357.56734.malonedeb@wampee.canonical.com>
Message-ID: <20131017123559.11451.34378.launchpad@gac.canonical.com>

** Changed in: keystone
    Milestone: havana-1 => 2013.2

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

Title:
  admin_token and LDAP password show up in log in DEBUG mode

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone grizzly series:
  Fix Released

Bug description:
  This is a by-product of bug 1168252.

  Keystone auth_token and LDAP password are not market "secret" so they
  appear in DEBUG level logs:

  (keystone-all): 2013-04-23 23:17:09,101 DEBUG cfg log_opt_values admin_token                    = 111222333444
  (keystone-all): 2013-04-23 23:17:09,108 DEBUG cfg log_opt_values ldap.password                  = None

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



From thierry.carrez+lp at gmail.com  Thu Oct 17 12:57:51 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 12:57:51 -0000
Subject: [Openstack-security] [Bug 1118441] Re: Horizon does not implement a
	browser session timeout
References: <20130207150751.16050.96632.malonedeb@soybean.canonical.com>
Message-ID: <20131017125753.27010.60338.launchpad@chaenomeles.canonical.com>

** Changed in: horizon
    Milestone: havana-2 => 2013.2

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

Title:
  Horizon does not implement a browser session timeout

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Horizon does not terminate user sessions (from a browser) after a
  reasonable period of inactivity. The only timeout is that of
  keystone's token which is often set to very long periods. The only
  session timeout implemented by Horizon is Django's
  SESSION_EXPIRE_AT_BROWSER_CLOSE which closes the session when the
  browser closes.

  Due to the nature of what can be done in Horizon (both now and in the
  future) this could pose significant risk since it enables bystanders
  to make use of unlocked workstations in order to access sensitive data
  and do otherwise unauthorised activities on behalf of what some may
  call a 'careless' end-user.

  Implementing a reasonable inactive session timeout for Horizon would
  mitigate this risk.

  An option to solve this problem could be to include this code:
  https://github.com/subhranath/django-session-idle-timeout

  There is some discussion regarding possible solutions here:
  http://stackoverflow.com/questions/3024153/how-to-expire-session-due-
  to-inactivity-in-django

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



From thierry.carrez+lp at gmail.com  Thu Oct 17 11:55:26 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 11:55:26 -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: <20131017115529.28096.42029.launchpad@chaenomeles.canonical.com>

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

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/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 thierry.carrez+lp at gmail.com  Thu Oct 17 11:47:41 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Thu, 17 Oct 2013 11:47:41 -0000
Subject: [Openstack-security] [Bug 1074087] Re: XenApi migration driver
	should not use shell=True	with Popen
References: <20121101174933.5279.14962.malonedeb@gac.canonical.com>
Message-ID: <20131017114743.11385.4312.launchpad@gac.canonical.com>

** Changed in: nova
    Milestone: havana-2 => 2013.2

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

Title:
  XenApi migration driver should not use shell=True with Popen

Status in OpenStack Compute (Nova):
  Fix Released

Bug description:
  The XenApi drivers split a string to create an array for
  subprocess.Popen, rather than passing an array directly. This invites
  the potential for command injection / manipulation.

  There is no clearly valid reason to use string splitting here when
  arguments can be passed, as elsewhere, directly into Popen.

  The behavior here is present in current Trunk, Folsom, and Essex.  Per
  Trunk and Folsom, _rsync_vhds calls plugins.utils.subprocess to
  perform the splitting.  In Essex, this behaviorism was present
  directly in migration/transfer_vhd.py, rather than in utils.py.
  Earlier releases have not been evaluated.

  I am not certain if this is directly exploitable. The user field is
  inserted into the generated strings used for command-line execution,
  and it does seem that Keystone allows usernames to contain arbitrary
  tokens/characters such as spaces.  It is not clear to me if the user
  field directly matches that in Keystone, if the user field is
  otherwise validated in the API, etc.  Other fields inserted into the
  command string seem to be internally generated.

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



From gerrit2 at review.openstack.org  Fri Oct 18 00:34:19 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 18 Oct 2013 00:34:19 +0000
Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review
 request change Ic00009e635f81427ba909a9ce4ba168f14ff51df
Message-ID: <E1VWy1D-0006Xu-Kg@review.openstack.org>


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

Log:
commit 5fdac44d220c8904d82eccb647625f7e455deb0c
Author: Simo Sorce <simo at redhat.com>
Date:   Wed Aug 7 14:16:28 2013 -0400

    Key Distribution Server
    
    API for distribution of keys in support of:
    https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation
    
    SecurityImpact
    
    Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df




From gerrit2 at review.openstack.org  Fri Oct 18 01:55:56 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 18 Oct 2013 01:55:56 +0000
Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review
 request change Ic00009e635f81427ba909a9ce4ba168f14ff51df
Message-ID: <E1VWzIC-00029U-T9@review.openstack.org>


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

Log:
commit 2e5221387c81c1a4539ac3cc9a14b02c22331819
Author: Simo Sorce <simo at redhat.com>
Date:   Wed Aug 7 14:16:28 2013 -0400

    Key Distribution Server
    
    API for distribution of keys in support of:
    https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation
    
    SecurityImpact
    
    Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df




From gerrit2 at review.openstack.org  Fri Oct 18 02:04:59 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Fri, 18 Oct 2013 02:04:59 +0000
Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review
 request change Ic00009e635f81427ba909a9ce4ba168f14ff51df
Message-ID: <E1VWzQx-0002TS-4I@review.openstack.org>


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

Log:
commit 58b28271733f3f10a891a44515b45923e6adc38e
Author: Simo Sorce <simo at redhat.com>
Date:   Wed Aug 7 14:16:28 2013 -0400

    Key Distribution Server
    
    API for distribution of keys in support of:
    https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation
    
    SecurityImpact
    
    Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df




From malini.k.bhandaru at intel.com  Fri Oct 18 23:21:22 2013
From: malini.k.bhandaru at intel.com (Bhandaru, Malini K)
Date: Fri, 18 Oct 2013 23:21:22 +0000
Subject: [Openstack-security] Free Intel TXT eBook, hardcopy
Message-ID: <EE6FFF4F6C34C84C8C98DD2414EEA47E53D3BDF5@FMSMSX102.amr.corp.intel.com>

Hello OSSG!
If you would like a free hardware copy of the book below please provide address, email, phone number, and company affiliation by Oct 30.
The eBook is available free at Apress<http://www.apress.com/9781430261483> as well as Amazon<http://www.amazon.com/Trusted-Execution-Technology-Server-Platforms-ebook/dp/B00DREFPK6/ref=sr_1_1?ie=UTF8&qid=1381937332&sr=8-1&keywords=intel+trusted+execution>.com and other sites.
Regards
Malini

Intel(r) Trusted Execution Technology for Server Platforms, A Guide to More Secure Data Centers, by William Futral and James Greene, Software Engineers in Intel's Data Center Group, is now available for you to request copies for events and customers. It is an essential technical resource for the Field to use to drive technical alignment and accelerate the customers' development process. Please fill in and return the attached worksheet with the quantity you need for customers, DUE: 30-October. Orders are filled in priority order.

Intel(r) Trusted Execution Technology (Intel TXT) is a new security technology that started appearing on Intel server platforms in 2010. This book explains Intel Trusted Execution Technology for Servers, its purpose, application, advantages, and limitations. This book guides the server administrator / data center manager in enabling the technology as well as establishing a launch control policy that he can use to customize the server's boot process to fit the data center's requirements. This book explains how the OS (typically a Virtual Machine Monitor or Hypervisor) and supporting software can build on the secure facilities afforded by Intel TXT to provide additional security features and functions. It provides examples how the data center can create and use trusted pools.


[TXT cvr.jpg]
Remember, customers receiving books make less calls to the field for help!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131018/1ff4e10d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 7202 bytes
Desc: image003.jpg
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131018/1ff4e10d/attachment.jpg>

From noloader at gmail.com  Mon Oct 21 02:41:26 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 20 Oct 2013 22:41:26 -0400
Subject: [Openstack-security] Question on Documentation Comments (Discuss
	and Data Sharing)
Message-ID: <CAH8yC8nh4rRTvmAJj=K4eeea434mc8XUqTW1ihXpFqjPQ6zLwg@mail.gmail.com>

Hi All,

Forgive my ignorance here....

I have a Gmail account and the documentation allows one to comment
using Google services. See http://postimg.org/image/rln155gm1/.

When I click the red "G" for Google services, I am present with a
dialog that allows Disqus.com to view my email and account
information. See http://postimg.org/image/7ji7lzusb/.

If I decline to accept the offer to share my information, I am
presented with an error "Oops, something went wrong". See
http://postimg.org/image/eh51rzc2d/.

Some questions:

(1) Who/what is Disqus.com?
(2) Why am I required to share information with Disqus.com?
(3) How do I opt-out of their obscene Terms of Service?
(4) If they monetize the data, how do I collect my share of the profits?
(5) How does forcing users to share data further the goals of OpenStack?

For completeness, I don't participate in the social networking
experiments. So I don't have the other accounts, such as Facebook or
Tweeter.

Thanks in advance,
Jeffrey Walton



From gerrit2 at review.openstack.org  Mon Oct 21 07:25:12 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 21 Oct 2013 07:25:12 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change Ib47aca8f72623a07ff18f23d46d0af520e463fc9
Message-ID: <E1VY9rU-0001Bz-Hq@review.openstack.org>


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

Log:
commit 9b20a319365ae7e34a6bc21900f37fef2d2de07d
Author: Simo Sorce <simo at redhat.com>
Date:   Mon Oct 14 16:28:05 2013 +1000

    Initial KDS service
    
    The Key Distribution Service is used to register keys for services and
    distribute tickets to contact othe services.
    
    The KDS is used to digitally sign and optionally encrypt messages sent over the
    message queue by the rpc modules.
    
    It implements the service described in this document:
    https://wiki.openstack.org/wiki/MessageSecurity#A_Key_Distribution_Server_in_Keystone
    
    DocImpact
    SecurityImpact
    blueprint key-distribution-server
    Change-Id: Ib47aca8f72623a07ff18f23d46d0af520e463fc9
    Co-Authored-By: Jamie Lennox <jamielennox at redhat.com>




From tom at openstack.org  Mon Oct 21 08:14:27 2013
From: tom at openstack.org (Tom Fifield)
Date: Mon, 21 Oct 2013 19:14:27 +1100
Subject: [Openstack-security] Question on Documentation Comments
 (Discuss and Data Sharing)
In-Reply-To: <CAH8yC8nh4rRTvmAJj=K4eeea434mc8XUqTW1ihXpFqjPQ6zLwg@mail.gmail.com>
References: <CAH8yC8nh4rRTvmAJj=K4eeea434mc8XUqTW1ihXpFqjPQ6zLwg@mail.gmail.com>
Message-ID: <5264E263.8030601@openstack.org>

On 21/10/13 13:41, Jeffrey Walton wrote:
> Hi All,
>
> Forgive my ignorance here....
>
> I have a Gmail account and the documentation allows one to comment
> using Google services. See http://postimg.org/image/rln155gm1/.
>
> When I click the red "G" for Google services, I am present with a
> dialog that allows Disqus.com to view my email and account
> information. See http://postimg.org/image/7ji7lzusb/.
>
> If I decline to accept the offer to share my information, I am
> presented with an error "Oops, something went wrong". See
> http://postimg.org/image/eh51rzc2d/.
>
> Some questions:
>
> (1) Who/what is Disqus.com?
> (2) Why am I required to share information with Disqus.com?
> (3) How do I opt-out of their obscene Terms of Service?
> (4) If they monetize the data, how do I collect my share of the profits?
> (5) How does forcing users to share data further the goals of OpenStack?
>
> For completeness, I don't participate in the social networking
> experiments. So I don't have the other accounts, such as Facebook or
> Tweeter.
>
> Thanks in advance,
> Jeffrey Walton

All very valid Jeffrey - thanks for raising this.

I'm sure Anne Gentle will chime in here soon, but just to get you a 
swift response:
Disqus has changed quite a bit since we started using it and we're 
looking at ways to replace it with other things, such as a widget to 
ask.openstack.org.


Regards,


Tom





From thierry.carrez+lp at gmail.com  Mon Oct 21 13:31:24 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 21 Oct 2013 13:31:24 -0000
Subject: [Openstack-security] [Bug 1240382] Re: oauth2 dependency
References: <20131016072040.28005.15743.malonedeb@chaenomeles.canonical.com>
Message-ID: <20131021133124.2128.85850.malone@chaenomeles.canonical.com>

That would indeed be great.

** Information type changed from Public Security to Public

** Tags added: security

** Summary changed:

- oauth2 dependency 
+ oauth2 dependency is unmaintained and has security issues

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

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

** Summary changed:

- oauth2 dependency is unmaintained and has security issues
+ python-oauth2 dependency is unmaintained and has security issues

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

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

Status in OpenStack Identity (Keystone):
  Confirmed

Bug description:
  oauth2 is not maintained and have 2 CVE issues CVE-2013-4346 and CVE-2013-4347 and is not Python3 compatible
  can you remove this dependency (maybe switching to requests ? )

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



From anne.gentle at RACKSPACE.COM  Mon Oct 21 13:59:27 2013
From: anne.gentle at RACKSPACE.COM (Anne Gentle)
Date: Mon, 21 Oct 2013 13:59:27 +0000
Subject: [Openstack-security] Question on Documentation Comments (Discuss
	and Data Sharing)
Message-ID: <B9178F2AA23FE4478ED6678CF1BDA412A87DF3C4@ORD1EXD01.RACKSPACE.CORP>


Sorry for the inserted inline without the original post, but I wanted to address Jeffrey's questions on the list.

(1) Who/what is Disqus.com?
A third-party site used for comments on the blog and docs site.

(2) Why am I required to share information with Disqus.com?

Please use the doc bug link instead.

(3) How do I opt-out of their obscene Terms of Service?

By not using Disqus, using ask.openstack.org or the link to Launchpad instead. Let me know your goal for using Disqus at all and we can evaluate whether the other means solve your problem.

(4) If they monetize the data, how do I collect my share of the profits?

We are vigilant about refusing to enable monetization on the OpenStack docs sites, but see below for our replacement idea as we'd like input.

(5) How does forcing users to share data further the goals of OpenStack?

As a service we have tried to tweak the settings as much as possible to meet our needs but we are taking steps towards replacing it. We have:
1. Added the doc bug link to each page so that you don't have to use comments to report a doc bug.
2. Intend to replace with integration with ask.openstack.org in the Icehouse release.
3. Changed the settings so no OpenStack docs properties are monetized. Yes, I know that somehow Disqus makes money, but we're not purposely using our comments to monetize for OpenStack.

Please send comments on https://blueprints.launchpad.net/openstack-manuals/+spec/redesign-docs-site so we can shape it.

Thanks,
Anne


Anne Gentle
Content Stacker
my blog<http://justwriteclick.com/> | my book<http://xmlpress.net/publications/conversation-community/> | LinkedIn<http://www.linkedin.com/in/annegentle> | Delicious<http://del.icio.us/annegentle> | Twitter<http://twitter.com/annegentle>

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

From gerrit2 at review.openstack.org  Mon Oct 21 21:11:12 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Mon, 21 Oct 2013 21:11:12 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change I013ae466d626c0a4737d475e1b42b183a88dbe83
Message-ID: <E1VYMkr-0003Xz-00@review.openstack.org>


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

Log:
commit a204fd5b30a17952a1e603d19bfb78768b64ac63
Author: Simo Sorce <simo at redhat.com>
Date:   Mon Oct 21 16:58:01 2013 +1000

    Add group key support
    
    A requestor asking for a key for a target identified as a group object
    will receive a group_key ticket.
    
    Group keys are temporary keys with a limited timelife and are released
    together with a generation number. Multiple keys with different generation
    numbers may exist at the same time.
    
    When no valid keys are found or if the only valid key has less than 10 minutes
    of lifetime a new key is generated using the next available generation number.
    
    Generation numbers grow monotonically.
    
    Group keys can be retrieved using the get_group_key call only by
    requestors belonging to the group. A requestor is considered as belonging
    to a group if the first part of the name is the same as the group.
    
    Requestors must specify a valid generation number when requesting a group
    key. The generation number is used to create the destination name by
    postfixing it to the group name after a colon.
    
    Example:
    requestor: scheduler.xyz.example.com
    destination: scheduler:123
    
    The requestor is considered part of the scheduler group and asks for
    a key of generation number 123. If that key exist it will be returned
    encrypted with the requestor's key.
    
    blueprint key-distribution-server
    SecurityImpact
    Change-Id: I013ae466d626c0a4737d475e1b42b183a88dbe83
    Co-Authored-By: Jamie Lennox <jamielennox at redhat.com>




From 1168252 at bugs.launchpad.net  Tue Oct 22 22:49:00 2013
From: 1168252 at bugs.launchpad.net (Dean Troyer)
Date: Tue, 22 Oct 2013 22:49:00 -0000
Subject: [Openstack-security] [Bug 1168252] Re: keystone.conf should not be
	world-readable (to keep	LDAP password and admin_token secret)
References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com>
Message-ID: <20131022224901.12696.64893.launchpad@gac.canonical.com>

** Changed in: devstack
     Assignee: (unassigned) => Dean Troyer (dtroyer)

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

Title:
  keystone.conf should not be world-readable (to keep LDAP password and
  admin_token secret)

Status in devstack - openstack dev environments:
  Confirmed
Status in OpenStack Security Notes:
  Fix Released
Status in Gentoo Linux:
  Fix Released

Bug description:
  The password configuration of LDAP and admin_token in keystone.conf
  should be secret to protect security information:

  [ldap]
  # url = ldap://localhost
  # user = dc=Manager,dc=example,dc=com
  # password = None                                            <- should be secrect
  # suffix = cn=example,cn=com
  # use_dumb_member = False
  # allow_subtree_delete = False
  # dumb_member = cn=dumb,dc=example,dc=com

  
  [DEFAULT]
  admin_token = passw0rd                                <- should be secrect

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



From 1168252 at bugs.launchpad.net  Tue Oct 22 22:57:00 2013
From: 1168252 at bugs.launchpad.net (OpenStack Infra)
Date: Tue, 22 Oct 2013 22:57:00 -0000
Subject: [Openstack-security] [Bug 1168252] Fix proposed to devstack (master)
References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com>
Message-ID: <20131022225700.14615.42649.malone@wampee.canonical.com>

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

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

Title:
  keystone.conf should not be world-readable (to keep LDAP password and
  admin_token secret)

Status in devstack - openstack dev environments:
  Confirmed
Status in OpenStack Security Notes:
  Fix Released
Status in Gentoo Linux:
  Fix Released

Bug description:
  The password configuration of LDAP and admin_token in keystone.conf
  should be secret to protect security information:

  [ldap]
  # url = ldap://localhost
  # user = dc=Manager,dc=example,dc=com
  # password = None                                            <- should be secrect
  # suffix = cn=example,cn=com
  # use_dumb_member = False
  # allow_subtree_delete = False
  # dumb_member = cn=dumb,dc=example,dc=com

  
  [DEFAULT]
  admin_token = passw0rd                                <- should be secrect

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



From zigo at debian.org  Wed Oct 23 06:12:29 2013
From: zigo at debian.org (Thomas Goirand)
Date: Wed, 23 Oct 2013 14:12:29 +0800
Subject: [Openstack-security] keystone tokens
In-Reply-To: <1369226323.23339.38.camel@willson.li.ssimo.org>
References: <CDC2638E.1356F%robert.clark@hp.com> <519CADF1.3080902@kent.ac.uk>
 <1369226323.23339.38.camel@willson.li.ssimo.org>
Message-ID: <526768CD.1030808@debian.org>

On 05/22/2013 08:38 PM, Simo Sorce wrote:
> On Wed, 2013-05-22 at 12:37 +0100, David Chadwick wrote:
>> Two reasons
>>
>> 1. I think that some of your arguments (like long pw) were really 
>> unauthenticated not authenticated user arguments which can be used by 
>> any attackers, and
>>
>> 2. I think that a cloud service that offers free services to anyone with 
>> any email address is not really an authenticated user service, its more 
>> like a public service for everyone, where everyone is allowed to go back 
>> to their own specific stake in the cloud. So the users have not been 
>> identified and authenticated in any real sense.  Its an OpenID, level of 
>> assurance =1, type of service, where all the cloud can be assured of, is 
>> that is it probably the same user every time, but it has no idea of who 
>> this user is.
> 
> In both cases you can throttle either by IP or by user name.
> I bet there are many other expensive operations a user can perform.
> If there is no throttling a user can simply perform N more operations to
> reach the same load on keystone.
> Unless there is some form of throttling you cannot really defend to this
> kind of DoS attacks.
> 
> Simo.

If the above is truth, then I'd find it a very good thing if Keystone
offered this kind of throttling directly as a feature, rather than
relying on service providers to implement it themselves.

Thomas Goirand (zigo)




From gerrit2 at review.openstack.org  Thu Oct 24 02:08:09 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 24 Oct 2013 02:08:09 +0000
Subject: [Openstack-security] [openstack/identity-api] SecurityImpact review
 request change Ic00009e635f81427ba909a9ce4ba168f14ff51df
Message-ID: <E1VZALJ-00024I-GE@review.openstack.org>


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

Log:
commit 9c5815099671be4cc037af22317b0dbe278987e8
Author: Simo Sorce <simo at redhat.com>
Date:   Wed Aug 7 14:16:28 2013 -0400

    Key Distribution Server
    
    API for distribution of keys in support of:
    https://wiki.openstack.org/wiki/MessageSecurity#Key_Derivation
    
    SecurityImpact
    
    Change-Id: Ic00009e635f81427ba909a9ce4ba168f14ff51df




From noloader at gmail.com  Fri Oct 25 07:25:49 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 25 Oct 2013 03:25:49 -0400
Subject: [Openstack-security] List of steps to perform to prepare or
	condition long term keys?
Message-ID: <CAH8yC8mkykapO6us3xBcHWPkRHvXiGpZGtUuENChJCx7A9EmjA@mail.gmail.com>

I was reading through the OpenStack Security Guide dated Oct 25 2013
for Havana (http://docs.openstack.org/sec/). Good job on that, by the
way.

Does anyone have a list of steps to perform to prepare or condition
long term keys? For example, SSH keys should be regenerated, Samba's
secret should probably be recreated (if present), Ubuntu's Snake Oil
key should probably be deleted (if present), etc.

I'm interested in both the bare metal OS and VM instances. (VM
instances are somewhat covered under Chapter 43).

Thanks in advance.



From bdpayne at acm.org  Fri Oct 25 15:59:34 2013
From: bdpayne at acm.org (Bryan D. Payne)
Date: Fri, 25 Oct 2013 08:59:34 -0700
Subject: [Openstack-security] List of steps to perform to prepare or
 condition long term keys?
In-Reply-To: <CAH8yC8mkykapO6us3xBcHWPkRHvXiGpZGtUuENChJCx7A9EmjA@mail.gmail.com>
References: <CAH8yC8mkykapO6us3xBcHWPkRHvXiGpZGtUuENChJCx7A9EmjA@mail.gmail.com>
Message-ID: <CAFpPvXDDCr23j71D=veNT2qtZoX61twnd28P9cqV4FPX=DMV=Q@mail.gmail.com>

Are you talking about setting up the operating system (and it's various
applications) such that all of the keys are generated uniquely?  If so,
this is very deployment specific and difficult to generalize on.  If not,
could you provide some more detail on what you are asking?

-bryan


On Fri, Oct 25, 2013 at 12:25 AM, Jeffrey Walton <noloader at gmail.com> wrote:

> I was reading through the OpenStack Security Guide dated Oct 25 2013
> for Havana (http://docs.openstack.org/sec/). Good job on that, by the
> way.
>
> Does anyone have a list of steps to perform to prepare or condition
> long term keys? For example, SSH keys should be regenerated, Samba's
> secret should probably be recreated (if present), Ubuntu's Snake Oil
> key should probably be deleted (if present), etc.
>
> I'm interested in both the bare metal OS and VM instances. (VM
> instances are somewhat covered under Chapter 43).
>
> Thanks in advance.
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131025/9c9a45da/attachment.html>

From noloader at gmail.com  Sat Oct 26 10:54:23 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 26 Oct 2013 06:54:23 -0400
Subject: [Openstack-security] List of steps to perform to prepare or
 condition long term keys?
In-Reply-To: <CAFpPvXDDCr23j71D=veNT2qtZoX61twnd28P9cqV4FPX=DMV=Q@mail.gmail.com>
References: <CAH8yC8mkykapO6us3xBcHWPkRHvXiGpZGtUuENChJCx7A9EmjA@mail.gmail.com>
 <CAFpPvXDDCr23j71D=veNT2qtZoX61twnd28P9cqV4FPX=DMV=Q@mail.gmail.com>
Message-ID: <CAH8yC8=bBDKo-UB2Lyw_XfkJn8TLkyL89G0fYzdQSLeE2HOZOw@mail.gmail.com>

Hi Doctor,

On Fri, Oct 25, 2013 at 11:59 AM, Bryan D. Payne <bdpayne at acm.org> wrote:
> Are you talking about setting up the operating system (and it's various
> applications) such that all of the keys are generated uniquely?  If so, this
> is very deployment specific and difficult to generalize on.  If not, could
> you provide some more detail on what you are asking?
I'd be interested in both OS and OpenStack since I've never seen a
definitive guide on either. There's no telling what I might have
missed as I go rummaging for the keys.

For example under Havana, I noticed Keystone created a CA key and cert
for www.example.com; and created a Signing key and cert for
www.example.com.

Jeff

> On Fri, Oct 25, 2013 at 12:25 AM, Jeffrey Walton <noloader at gmail.com> wrote:
>>
>> I was reading through the OpenStack Security Guide dated Oct 25 2013
>> for Havana (http://docs.openstack.org/sec/). Good job on that, by the
>> way.
>>
>> Does anyone have a list of steps to perform to prepare or condition
>> long term keys? For example, SSH keys should be regenerated, Samba's
>> secret should probably be recreated (if present), Ubuntu's Snake Oil
>> key should probably be deleted (if present), etc.
>>
>> I'm interested in both the bare metal OS and VM instances. (VM
>> instances are somewhat covered under Chapter 43).



From thomas at goirand.fr  Wed Oct 23 06:05:23 2013
From: thomas at goirand.fr (Thomas Goirand)
Date: Wed, 23 Oct 2013 06:05:23 -0000
Subject: [Openstack-security] [Bug 1168252] Re: keystone.conf should not be
	world-readable (to keep	LDAP password and admin_token secret)
References: <20130412063457.22477.49207.malonedeb@wampee.canonical.com>
Message-ID: <20131023060523.13005.4037.malone@gac.canonical.com>

Hi,
FYI, I don't think Debian is affected by this issue, since both keystone.conf and the log files are owned by the keystone users, and aren't world readable. At least, that's what I can see in my POC.

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

Title:
  keystone.conf should not be world-readable (to keep LDAP password and
  admin_token secret)

Status in devstack - openstack dev environments:
  Confirmed
Status in OpenStack Security Notes:
  Fix Released
Status in Gentoo Linux:
  Fix Released

Bug description:
  The password configuration of LDAP and admin_token in keystone.conf
  should be secret to protect security information:

  [ldap]
  # url = ldap://localhost
  # user = dc=Manager,dc=example,dc=com
  # password = None                                            <- should be secrect
  # suffix = cn=example,cn=com
  # use_dumb_member = False
  # allow_subtree_delete = False
  # dumb_member = cn=dumb,dc=example,dc=com

  
  [DEFAULT]
  admin_token = passw0rd                                <- should be secrect

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



From tgrandison at proficiencylabs.com  Sun Oct 27 03:10:25 2013
From: tgrandison at proficiencylabs.com (Dr Tyrone W A Grandison)
Date: Sun, 27 Oct 2013 03:10:25 +0000
Subject: [Openstack-security] CFP: Web 2.0 Security and Privacy Workshop 2014
Message-ID: <526C8421.5050502@proficiencylabs.com>



W2SP brings together researchers, practitioners, web programmers, policy
makers, and others interested in the latest understanding and advances
in the security and privacy of the web, browsers, cloud, mobile and
their eco-system. We have had seven years of successful W2SP workshops.
This year, we will additionally invite selected papers to a special
issue of the journal.

W2SP is held in conjunction with the IEEE Symposium on Security and
privacy, which will take place from May 18-21, 2014, at the Fairmont
Hotel in San Jose, California. W2SP will continue to be open access:
all papers will be made available on the workshop website, and authors
will not need to forfeit their copyright.

More information at http://w2spconf.com/2014/cfp.html



From ayoung at redhat.com  Mon Oct 28 02:48:13 2013
From: ayoung at redhat.com (Adam Young)
Date: Sun, 27 Oct 2013 22:48:13 -0400
Subject: [Openstack-security] List of steps to perform to prepare or
 condition long term keys?
In-Reply-To: <CAH8yC8=bBDKo-UB2Lyw_XfkJn8TLkyL89G0fYzdQSLeE2HOZOw@mail.gmail.com>
References: <CAH8yC8mkykapO6us3xBcHWPkRHvXiGpZGtUuENChJCx7A9EmjA@mail.gmail.com>
 <CAFpPvXDDCr23j71D=veNT2qtZoX61twnd28P9cqV4FPX=DMV=Q@mail.gmail.com>
 <CAH8yC8=bBDKo-UB2Lyw_XfkJn8TLkyL89G0fYzdQSLeE2HOZOw@mail.gmail.com>
Message-ID: <526DD06D.2010107@redhat.com>

On 10/26/2013 06:54 AM, Jeffrey Walton wrote:
> Hi Doctor,
>
> On Fri, Oct 25, 2013 at 11:59 AM, Bryan D. Payne <bdpayne at acm.org> wrote:
>> Are you talking about setting up the operating system (and it's various
>> applications) such that all of the keys are generated uniquely?  If so, this
>> is very deployment specific and difficult to generalize on.  If not, could
>> you provide some more detail on what you are asking?
> I'd be interested in both OS and OpenStack since I've never seen a
> definitive guide on either. There's no telling what I might have
> missed as I go rummaging for the keys.
>
> For example under Havana, I noticed Keystone created a CA key and cert
> for www.example.com; and created a Signing key and cert for
> www.example.com.

Keystone does provide utilities for doing setting up the certs, but no 
Security savvy person would think that it was the correct approach.  I 
almost regret having written that code.

The CA cert should be your organizations CA cert, and your CA should 
have signed the  signing cert for Keystone.  Using the keystone-manage 
pk-setup is for development and for deployments with no other PKI available.

We are looking at replacing that Code with Cert monger.  But in oprder 
to do that, we need more plugins for Certmonger to work with the CAs out 
there.  right now, certmonger works well with Dogtag/RedHat CertServer 
and a sample implementation called Certmaster.  Long term, Certmonger is 
the way to go.


>
> Jeff
>
>> On Fri, Oct 25, 2013 at 12:25 AM, Jeffrey Walton <noloader at gmail.com> wrote:
>>> I was reading through the OpenStack Security Guide dated Oct 25 2013
>>> for Havana (http://docs.openstack.org/sec/). Good job on that, by the
>>> way.
>>>
>>> Does anyone have a list of steps to perform to prepare or condition
>>> long term keys? For example, SSH keys should be regenerated, Samba's
>>> secret should probably be recreated (if present), Ubuntu's Snake Oil
>>> key should probably be deleted (if present), etc.
>>>
>>> I'm interested in both the bare metal OS and VM instances. (VM
>>> instances are somewhat covered under Chapter 43).
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security




From thierry.carrez+lp at gmail.com  Mon Oct 28 11:20:14 2013
From: thierry.carrez+lp at gmail.com (Thierry Carrez)
Date: Mon, 28 Oct 2013 11:20:14 -0000
Subject: [Openstack-security] [Bug 1237989] Re: user can update his password
	without knowing the	old password
References: <20131010124138.28096.87746.malonedeb@chaenomeles.canonical.com>
Message-ID: <20131028112014.10487.33580.malone@wampee.canonical.com>

This was assigned CVE-2013-4471

** Tags added: security

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2013-4471

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

Title:
  user can update his password without knowing the old password

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Security Notes:
  New

Bug description:
  a user logged into horizon can change his password without needing to
  type in the correct old password. It's just required to type in
  anything as the old password.

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



From ayoung at redhat.com  Mon Oct 28 17:04:06 2013
From: ayoung at redhat.com (Adam Young)
Date: Mon, 28 Oct 2013 13:04:06 -0400
Subject: [Openstack-security] Certmonger
Message-ID: <526E9906.8040703@redhat.com>

PKI requires infrastructure, more than the OpenStack project can really 
dictate.  What OpenStack needs is a strategy to integrate in with 
existing PKI systems.

Certmonger https://fedorahosted.org/certmonger/  is a tool from the 
Fedora project for integrating with a remote Certificate Authority. As 
such, it seems to fill the gap in our strategy.  It can:


  Perform all of the local tasks for certificate request generation
  Monitor and request new certificates prior to expiration.
  Handle both NSS and OpenSSL local storage formats.

Currently, Certmonger works against FreeIPA/Dogtag 
http://pki.fedoraproject.org/wiki/PKI_Main_Page and Certmaster 
https://fedorahosted.org/certmaster/.

I'd like to propose that we make Certmonger the focus for our X509 
management strategy.  In order to do that, we need to ensure that 
Certmonger can support a large enough array of CA request formats.

Beyond the ones listed above, what are people concerned with supporting 
for CA software?  THe Wikipedia list of Open Source CA implementations 
https://en.wikipedia.org/wiki/Certificate_authority#Open_source_implementations 
is fairly short.  What are the dominant APIs that we need to support?

Many people might be tempted to follow the advice of "Just let puppet 
handle it."  I'm not certain that this is the right approach.  
Disregarding the shops that don't use Puppet or a comparable other 
Configuration management tool, it appears that Puppet performs "Master 
side" certificate generation, and not following the best practice of 
keeping the key in secure storage on the client.  I'd be interested in 
hearing more feedback on this. However, it seems to me that Puppet and 
Certmonger should be able to work together, with Certmonger managing the 
logic for generating certificate requests and Puppet performing the 
marshalling:  or maybe Certmonger can just talk directly to the Puppet CA.

I am not certain that the Puppet CA is doing Revocations or OCSP, 
either, one or the other required for a full X509 implementation.

It looks like Chef is also getting into the CA business. 
http://www.cryptocracy.com/blog/2013/04/20/very-simple-x509-pki-with-chef

I've submitted a session for this under Devstack, as there is no general 
purpose "Security" heading. http://summit.openstack.org/cfp/details/363  
However, it might be too late to schedule it. I will try to put together 
an unconference session to discuss this, in conjunction with the 
Security team.




From SHULMANA at il.ibm.com  Tue Oct 29 13:02:41 2013
From: SHULMANA at il.ibm.com (Alexandra Shulman-Peleg)
Date: Tue, 29 Oct 2013 15:02:41 +0200
Subject: [Openstack-security] AUTO: Alexandra Shulman-Peleg is out of the
	office. (returning 31/10/2013)
Message-ID: <OFB213D73F.899B3655-ONC2257C13.0047A887-C2257C13.0047A887@il.ibm.com>


I am out of the office until 31/10/2013.

I am out of office. If required, please contact my manager Dalit Naor
(dalit at il.ibm.com).
For matters related to the VISION project, please contact Hillel Kolodner
(kolodner at il.ibm.com).


Note: This is an automated response to your message  "Openstack-security
Digest, Vol 8, Issue 23" sent on 29/10/2013 14:00:01.

This is the only notification you will receive while this person is away.




From bdpayne at acm.org  Tue Oct 29 15:44:39 2013
From: bdpayne at acm.org (Bryan D. Payne)
Date: Tue, 29 Oct 2013 08:44:39 -0700
Subject: [Openstack-security] Certmonger
In-Reply-To: <526E9906.8040703@redhat.com>
References: <526E9906.8040703@redhat.com>
Message-ID: <CAFpPvXBqk6EdD+i-W4siQw1GERY0axXnZxvZ4XsSc+MMwjv-Eg@mail.gmail.com>

Adam,

Can you provide a little more detail on what pieces of OpenStack you are
imagining would integrate with Certmonger?  I think some concrete examples
of why this is needed would go a long ways towards helping to spark some
discussion here.  But you've piqued my interest and I'd like to hear more.
 I'd certainly attend a session on this on Hong Kong, for what it's worth.

Cheers,
-bryan



On Mon, Oct 28, 2013 at 10:04 AM, Adam Young <ayoung at redhat.com> wrote:

> PKI requires infrastructure, more than the OpenStack project can really
> dictate.  What OpenStack needs is a strategy to integrate in with existing
> PKI systems.
>
> Certmonger https://fedorahosted.org/**certmonger/<https://fedorahosted.org/certmonger/> is a tool from the Fedora project for integrating with a remote
> Certificate Authority. As such, it seems to fill the gap in our strategy.
>  It can:
>
>
>  Perform all of the local tasks for certificate request generation
>  Monitor and request new certificates prior to expiration.
>  Handle both NSS and OpenSSL local storage formats.
>
> Currently, Certmonger works against FreeIPA/Dogtag
> http://pki.fedoraproject.org/**wiki/PKI_Main_Page<http://pki.fedoraproject.org/wiki/PKI_Main_Page>and Certmaster
> https://fedorahosted.org/**certmaster/<https://fedorahosted.org/certmaster/>
> .
>
> I'd like to propose that we make Certmonger the focus for our X509
> management strategy.  In order to do that, we need to ensure that
> Certmonger can support a large enough array of CA request formats.
>
> Beyond the ones listed above, what are people concerned with supporting
> for CA software?  THe Wikipedia list of Open Source CA implementations
> https://en.wikipedia.org/wiki/**Certificate_authority#Open_**
> source_implementations<https://en.wikipedia.org/wiki/Certificate_authority#Open_source_implementations>is fairly short.  What are the dominant APIs that we need to support?
>
> Many people might be tempted to follow the advice of "Just let puppet
> handle it."  I'm not certain that this is the right approach.  Disregarding
> the shops that don't use Puppet or a comparable other Configuration
> management tool, it appears that Puppet performs "Master side" certificate
> generation, and not following the best practice of keeping the key in
> secure storage on the client.  I'd be interested in hearing more feedback
> on this. However, it seems to me that Puppet and Certmonger should be able
> to work together, with Certmonger managing the logic for generating
> certificate requests and Puppet performing the marshalling:  or maybe
> Certmonger can just talk directly to the Puppet CA.
>
> I am not certain that the Puppet CA is doing Revocations or OCSP, either,
> one or the other required for a full X509 implementation.
>
> It looks like Chef is also getting into the CA business.
> http://www.cryptocracy.com/**blog/2013/04/20/very-simple-**
> x509-pki-with-chef<http://www.cryptocracy.com/blog/2013/04/20/very-simple-x509-pki-with-chef>
>
> I've submitted a session for this under Devstack, as there is no general
> purpose "Security" heading. http://summit.openstack.org/**cfp/details/363<http://summit.openstack.org/cfp/details/363> However, it might be too late to schedule it. I will try to put together
> an unconference session to discuss this, in conjunction with the Security
> team.
>
>
> ______________________________**_________________
> Openstack-security mailing list
> Openstack-security at lists.**openstack.org<Openstack-security at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-security<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131029/ed023091/attachment.html>

From bdpayne at acm.org  Tue Oct 29 15:47:43 2013
From: bdpayne at acm.org (Bryan D. Payne)
Date: Tue, 29 Oct 2013 08:47:43 -0700
Subject: [Openstack-security] List of steps to perform to prepare or
 condition long term keys?
In-Reply-To: <CAH8yC8=bBDKo-UB2Lyw_XfkJn8TLkyL89G0fYzdQSLeE2HOZOw@mail.gmail.com>
References: <CAH8yC8mkykapO6us3xBcHWPkRHvXiGpZGtUuENChJCx7A9EmjA@mail.gmail.com>
 <CAFpPvXDDCr23j71D=veNT2qtZoX61twnd28P9cqV4FPX=DMV=Q@mail.gmail.com>
 <CAH8yC8=bBDKo-UB2Lyw_XfkJn8TLkyL89G0fYzdQSLeE2HOZOw@mail.gmail.com>
Message-ID: <CAFpPvXAtqTpEgzgh4r-nbBKW=bjrzOPqEAYNMYeJddac1QP8fQ@mail.gmail.com>

> I'd be interested in both OS and OpenStack since I've never seen a
> definitive guide on either. There's no telling what I might have
> missed as I go rummaging for the keys.
>

I think that the answer is simply too specific for each given deployment.
 For example, I could probably go on for a few pages about all that we do
with Nebula's deployment.  But that may have very little useful information
for someone else's deployment.  For better or worse, this is the kind of
thing that I think is best handled by an analysis of the specific system
that you are interested in.  And that is likely beyond the scope of this
mailing list.

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

From ayoung at redhat.com  Tue Oct 29 18:03:53 2013
From: ayoung at redhat.com (Adam Young)
Date: Tue, 29 Oct 2013 14:03:53 -0400
Subject: [Openstack-security] Certmonger
In-Reply-To: <CAFpPvXBqk6EdD+i-W4siQw1GERY0axXnZxvZ4XsSc+MMwjv-Eg@mail.gmail.com>
References: <526E9906.8040703@redhat.com>
 <CAFpPvXBqk6EdD+i-W4siQw1GERY0axXnZxvZ4XsSc+MMwjv-Eg@mail.gmail.com>
Message-ID: <526FF889.3050507@redhat.com>

On 10/29/2013 11:44 AM, Bryan D. Payne wrote:
> Adam,
>
> Can you provide a little more detail on what pieces of OpenStack you 
> are imagining would integrate with Certmonger?  I think some concrete 
> examples of why this is needed would go a long ways towards helping to 
> spark some discussion here.  But you've piqued my interest and I'd 
> like to hear more.  I'd certainly attend a session on this on Hong 
> Kong, for what it's worth.

Anything that requires an X509.  This is:  anything that does TLS: 
HTTPD, Messaging, etc.  In addition, Keystone should use it to manage 
the signing certificates.  If there are certifiates involved in the 
crypto signing of block devices, those would be managed via Certmonger 
as well.

I'll see if I can set up an unconference session.  THings are still 
settling out on the Developers conference schedule.

>
> Cheers,
> -bryan
>
>
>
> On Mon, Oct 28, 2013 at 10:04 AM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at redhat.com>> wrote:
>
>     PKI requires infrastructure, more than the OpenStack project can
>     really dictate.  What OpenStack needs is a strategy to integrate
>     in with existing PKI systems.
>
>     Certmonger https://fedorahosted.org/certmonger/  is a tool from
>     the Fedora project for integrating with a remote Certificate
>     Authority. As such, it seems to fill the gap in our strategy.  It can:
>
>
>      Perform all of the local tasks for certificate request generation
>      Monitor and request new certificates prior to expiration.
>      Handle both NSS and OpenSSL local storage formats.
>
>     Currently, Certmonger works against FreeIPA/Dogtag
>     http://pki.fedoraproject.org/wiki/PKI_Main_Page and Certmaster
>     https://fedorahosted.org/certmaster/.
>
>     I'd like to propose that we make Certmonger the focus for our X509
>     management strategy.  In order to do that, we need to ensure that
>     Certmonger can support a large enough array of CA request formats.
>
>     Beyond the ones listed above, what are people concerned with
>     supporting for CA software?  THe Wikipedia list of Open Source CA
>     implementations
>     https://en.wikipedia.org/wiki/Certificate_authority#Open_source_implementations
>     is fairly short.  What are the dominant APIs that we need to support?
>
>     Many people might be tempted to follow the advice of "Just let
>     puppet handle it."  I'm not certain that this is the right
>     approach.  Disregarding the shops that don't use Puppet or a
>     comparable other Configuration management tool, it appears that
>     Puppet performs "Master side" certificate generation, and not
>     following the best practice of keeping the key in secure storage
>     on the client.  I'd be interested in hearing more feedback on
>     this. However, it seems to me that Puppet and Certmonger should be
>     able to work together, with Certmonger managing the logic for
>     generating certificate requests and Puppet performing the
>     marshalling:  or maybe Certmonger can just talk directly to the
>     Puppet CA.
>
>     I am not certain that the Puppet CA is doing Revocations or OCSP,
>     either, one or the other required for a full X509 implementation.
>
>     It looks like Chef is also getting into the CA business.
>     http://www.cryptocracy.com/blog/2013/04/20/very-simple-x509-pki-with-chef
>
>     I've submitted a session for this under Devstack, as there is no
>     general purpose "Security" heading.
>     http://summit.openstack.org/cfp/details/363  However, it might be
>     too late to schedule it. I will try to put together an
>     unconference session to discuss this, in conjunction with the
>     Security team.
>
>
>     _______________________________________________
>     Openstack-security mailing list
>     Openstack-security at lists.openstack.org
>     <mailto:Openstack-security at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>

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

From bdpayne at acm.org  Tue Oct 29 18:13:29 2013
From: bdpayne at acm.org (Bryan D. Payne)
Date: Tue, 29 Oct 2013 11:13:29 -0700
Subject: [Openstack-security] Certmonger
In-Reply-To: <526FF889.3050507@redhat.com>
References: <526E9906.8040703@redhat.com>
 <CAFpPvXBqk6EdD+i-W4siQw1GERY0axXnZxvZ4XsSc+MMwjv-Eg@mail.gmail.com>
 <526FF889.3050507@redhat.com>
Message-ID: <CAFpPvXANKm6meS7mYjtOqy4j+_GQM59-NaHTePTuPuQKXuy8hg@mail.gmail.com>

> Anything that requires an X509.  This is:  anything that does TLS:  HTTPD,
> Messaging, etc.
>

Many of these things are more distro specific.  If there's a general
solution here that can help people across the board, then that's clearly
valuable.  But if this were to only help for certain deployment scenarios
then it may not be worth it, IMHO.

Cheers,
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131029/46c34681/attachment.html>

From ayoung at redhat.com  Tue Oct 29 18:14:54 2013
From: ayoung at redhat.com (Adam Young)
Date: Tue, 29 Oct 2013 14:14:54 -0400
Subject: [Openstack-security] List of steps to perform to prepare or
 condition long term keys?
In-Reply-To: <CAH8yC8mkykapO6us3xBcHWPkRHvXiGpZGtUuENChJCx7A9EmjA@mail.gmail.com>
References: <CAH8yC8mkykapO6us3xBcHWPkRHvXiGpZGtUuENChJCx7A9EmjA@mail.gmail.com>
Message-ID: <526FFB1E.8060500@redhat.com>

On 10/25/2013 03:25 AM, Jeffrey Walton wrote:
> I was reading through the OpenStack Security Guide dated Oct 25 2013
> for Havana (http://docs.openstack.org/sec/). Good job on that, by the
> way.
>
> Does anyone have a list of steps to perform to prepare or condition
> long term keys? For example, SSH keys should be regenerated, Samba's
> secret should probably be recreated (if present), Ubuntu's Snake Oil
> key should probably be deleted (if present), etc.
>
> I'm interested in both the bare metal OS and VM instances. (VM
> instances are somewhat covered under Chapter 43).
>
> Thanks in advance.
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
In general, direct Key management is an Antipattern:  they don't have 
revocation or expiration built in.  Where possible, favor X509.  For 
Automated management of X509 certificates we should coallesce around a 
soluition like Certmonger https://fedorahosted.org/certmonger/ .  I am 
interested in getting together an unconference session around this, or I 
will try to work it into one of the security track discussions.



From ayoung at redhat.com  Tue Oct 29 18:16:07 2013
From: ayoung at redhat.com (Adam Young)
Date: Tue, 29 Oct 2013 14:16:07 -0400
Subject: [Openstack-security] Certmonger
In-Reply-To: <CAFpPvXANKm6meS7mYjtOqy4j+_GQM59-NaHTePTuPuQKXuy8hg@mail.gmail.com>
References: <526E9906.8040703@redhat.com>
 <CAFpPvXBqk6EdD+i-W4siQw1GERY0axXnZxvZ4XsSc+MMwjv-Eg@mail.gmail.com>
 <526FF889.3050507@redhat.com>
 <CAFpPvXANKm6meS7mYjtOqy4j+_GQM59-NaHTePTuPuQKXuy8hg@mail.gmail.com>
Message-ID: <526FFB67.1060302@redhat.com>

On 10/29/2013 02:13 PM, Bryan D. Payne wrote:
>
>     Anything that requires an X509.  This is:  anything that does TLS:
>     HTTPD, Messaging, etc.
>
>
> Many of these things are more distro specific.  If there's a general 
> solution here that can help people across the board, then that's 
> clearly valuable.  But if this were to only help for certain 
> deployment scenarios then it may not be worth it, IMHO.
>
> Cheers,
> -bryan
Certmonger is supported on both RHEL and Debian based systems, and is 
easily portable to others.  What is essential is identification of what 
additional Certificate Authority protocols it needs to support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131029/07191015/attachment.html>

From bdpayne at acm.org  Tue Oct 29 18:23:06 2013
From: bdpayne at acm.org (Bryan D. Payne)
Date: Tue, 29 Oct 2013 11:23:06 -0700
Subject: [Openstack-security] Certmonger
In-Reply-To: <526FFB67.1060302@redhat.com>
References: <526E9906.8040703@redhat.com>
 <CAFpPvXBqk6EdD+i-W4siQw1GERY0axXnZxvZ4XsSc+MMwjv-Eg@mail.gmail.com>
 <526FF889.3050507@redhat.com>
 <CAFpPvXANKm6meS7mYjtOqy4j+_GQM59-NaHTePTuPuQKXuy8hg@mail.gmail.com>
 <526FFB67.1060302@redhat.com>
Message-ID: <CAFpPvXAG72=6Q1bq24QYEfgo_J65JNMCb5bd7bH3U9_0a071cw@mail.gmail.com>

> Certmonger is supported on both RHEL and Debian based systems, and is
easily
> portable to others.  What is essential is identification of what
additional Certificate
> Authority protocols it needs to support.

Sorry, I was referring to OpenStack distros, not Linux distros.  Basically
I think that everyone has slightly different tooling around how they handle
HTTPS termination (stud, pound, Apache, etc) and each of these would have
slightly different needs for orchestration of the certs and such.
 Traditionally, this has been done outside of the OpenStack projects and
has been more distro specific.  But, perhaps we are approaching the time
for some of that to be more fully integrated into the OpenStack projects
themselves.  Certainly a conversation worth having.

Cheers,
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131029/76df089a/attachment.html>

From kseifried at redhat.com  Tue Oct 29 18:39:38 2013
From: kseifried at redhat.com (Kurt Seifried)
Date: Tue, 29 Oct 2013 12:39:38 -0600
Subject: [Openstack-security] List of steps to perform to prepare or
 condition long term keys?
In-Reply-To: <526FFB1E.8060500@redhat.com>
References: <CAH8yC8mkykapO6us3xBcHWPkRHvXiGpZGtUuENChJCx7A9EmjA@mail.gmail.com>
 <526FFB1E.8060500@redhat.com>
Message-ID: <527000EA.6060301@redhat.com>

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

On 10/29/2013 12:14 PM, Adam Young wrote:
> On 10/25/2013 03:25 AM, Jeffrey Walton wrote:
>> I was reading through the OpenStack Security Guide dated Oct 25
>> 2013 for Havana (http://docs.openstack.org/sec/). Good job on
>> that, by the way.
>> 
>> Does anyone have a list of steps to perform to prepare or
>> condition long term keys? For example, SSH keys should be
>> regenerated, Samba's secret should probably be recreated (if
>> present), Ubuntu's Snake Oil key should probably be deleted (if
>> present), etc.
>> 
>> I'm interested in both the bare metal OS and VM instances. (VM 
>> instances are somewhat covered under Chapter 43).
>> 
>> Thanks in advance.
>> 
>> _______________________________________________ 
>> Openstack-security mailing list 
>> Openstack-security at lists.openstack.org 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

>
>> 
In general, direct Key management is an Antipattern:  they don't have
> revocation or expiration built in.  Where possible, favor X509.
> For Automated management of X509 certificates we should coallesce
> around a soluition like Certmonger
> https://fedorahosted.org/certmonger/ .  I am interested in getting
> together an unconference session around this, or I will try to work
> it into one of the security track discussions.
> 

OpenSSH supports a modified/limited certificate format now since 5.4:

http://www.openssh.org/txt/release-5.4

But I agree, it's best to do this via X.509.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBAgAGBQJScADqAAoJEBYNRVNeJnmTA0wQAL/UVusTDXs1sGWQR0tC6rnk
WJBNpG68IzrVPnkRGGKIllKFUrSj8BsG5WXI6/jl7fcYLef1YPFDFqO4AObrnmk3
bvjGlS0bx5IFPLfxyZ7TEoQvKEOZgPexYjKjSZtlBGHi7d7W/VE+60I2ltk8RGXY
wL+wkfhjuudlf7X3qv+CGGbETu1lf58MXtx0CmmQmRXQUBuT6D5VXvX0H7X+pi6g
P56rGANk+5JMYMzpZ0/yqLfGdT1ROblKa3drrKJZqCAsqdzqM7iXZgYueNwJMPpV
0xnbh7NPk2MNEx4b3MljVRtRBA/KpHowlAUFCElQcmfkCvFs7bMpNGWqS8xX9MyF
3s6x87kp8R1iwf9AXOU9BjsTMkkFjQq6Cv2YBCqw1QSZaNQnsMLJMApimow9AAAL
LBpabGEhH8Y1qjTi0HtKM7GftNyyudHZ1D/oSch7J514/sY2a32pQiUyzfnGXHYP
FxaaFPWjTUs0zpqTBKmbUEmpJOj4c/mkih90KuDNMY4P+9TcWYlPSc/lhF7UECMg
HwzyXBCKKU8fhY5MqnOUkE59La1SIlS7Ol7nSYY1kBcfkGglUyW6Jc0BpwjPQuin
Y8HgPzYfPBcYCb/8LvrZWQYQSae9o3a2IxJk5EDSu3FtOcYLUJwZXJeyhE4dxZKJ
mXvx4HfUj7PJ6IhVsk/d
=UHb6
-----END PGP SIGNATURE-----



From ayoung at redhat.com  Tue Oct 29 19:16:18 2013
From: ayoung at redhat.com (Adam Young)
Date: Tue, 29 Oct 2013 15:16:18 -0400
Subject: [Openstack-security] Certmonger
In-Reply-To: <CAFpPvXAG72=6Q1bq24QYEfgo_J65JNMCb5bd7bH3U9_0a071cw@mail.gmail.com>
References: <526E9906.8040703@redhat.com>
 <CAFpPvXBqk6EdD+i-W4siQw1GERY0axXnZxvZ4XsSc+MMwjv-Eg@mail.gmail.com>
 <526FF889.3050507@redhat.com>
 <CAFpPvXANKm6meS7mYjtOqy4j+_GQM59-NaHTePTuPuQKXuy8hg@mail.gmail.com>
 <526FFB67.1060302@redhat.com>
 <CAFpPvXAG72=6Q1bq24QYEfgo_J65JNMCb5bd7bH3U9_0a071cw@mail.gmail.com>
Message-ID: <52700982.3050504@redhat.com>

On 10/29/2013 02:23 PM, Bryan D. Payne wrote:
> > Certmonger is supported on both RHEL and Debian based systems, and 
> is easily
> > portable to others.  What is essential is identification of what 
> additional Certificate
> > Authority protocols it needs to support.
>
> Sorry, I was referring to OpenStack distros, not Linux distros. 
>  Basically I think that everyone has slightly different tooling around 
> how they handle HTTPS termination (stud, pound, Apache, etc) and each 
> of these would have slightly different needs for orchestration of the 
> certs and such.  Traditionally, this has been done outside of the 
> OpenStack projects and has been more distro specific.  But, perhaps we 
> are approaching the time for some of that to be more fully integrated 
> into the OpenStack projects themselves.  Certainly a conversation 
> worth having.
Even the SSL Termination tools do not typically handle Certificates, 
just punt to some other tooling.  I was thinking Devstack as a starting 
point, though, for TLS.

Thereare a handful of PKI uses inside of openstack that would be better 
served by X509, such as the SSH to the VMs...raw public keys have no 
expiry or revocation.  Any encryption that we are doing inside of OS at 
the application level, as I pointed out before, should also be using 
X509.  AMQP traffic, traffic between App server and database, and LDAP 
should all be passed over TLS, and this is indie the datacenter, so 
hardware termination is usually not appropriate.

We need an approach for SSL everywhere:  it is one of the issues rasied 
in the security guide.  Thus, the default deployment needs to show how 
to set that up.


>
> Cheers,
> -bryan




From bdpayne at acm.org  Tue Oct 29 19:20:16 2013
From: bdpayne at acm.org (Bryan D. Payne)
Date: Tue, 29 Oct 2013 12:20:16 -0700
Subject: [Openstack-security] Certmonger
In-Reply-To: <52700982.3050504@redhat.com>
References: <526E9906.8040703@redhat.com>
 <CAFpPvXBqk6EdD+i-W4siQw1GERY0axXnZxvZ4XsSc+MMwjv-Eg@mail.gmail.com>
 <526FF889.3050507@redhat.com>
 <CAFpPvXANKm6meS7mYjtOqy4j+_GQM59-NaHTePTuPuQKXuy8hg@mail.gmail.com>
 <526FFB67.1060302@redhat.com>
 <CAFpPvXAG72=6Q1bq24QYEfgo_J65JNMCb5bd7bH3U9_0a071cw@mail.gmail.com>
 <52700982.3050504@redhat.com>
Message-ID: <CAFpPvXAyU8FTMFsF2P5nYVYHGSsTZu4LN==h2CByCpCkyv3NyA@mail.gmail.com>

> We need an approach for SSL everywhere:  it is one of the issues rasied in
> the security guide.  Thus, the default deployment needs to show how to set
> that up.
>

Makes sense to me.
-bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20131029/b7386e9a/attachment.html>

From gerrit2 at review.openstack.org  Thu Oct 31 13:22:45 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 31 Oct 2013 13:22:45 +0000
Subject: [Openstack-security] [openstack/keystone] SecurityImpact review
 request change If5229d89a39dca952dee3b1c4cbf3b34b8afa95b
Message-ID: <E1VbsCz-0000e0-HW@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 72f741b6d263d0a19ef544089d59a9ab6973fe3e
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  Thu Oct 31 16:29:50 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 31 Oct 2013 16:29:50 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1Vbv82-0007fo-RO@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 22524e4f6c2eef29238164d2e9179b61e9f17fff
Author: Dan Genin <Daniel.Genin at jhuapl.edu>
Date:   Fri Oct 25 16:38:19 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 Oct 31 16:36:37 2013
From: gerrit2 at review.openstack.org (gerrit2 at review.openstack.org)
Date: Thu, 31 Oct 2013 16:36:37 +0000
Subject: [Openstack-security] [openstack/nova] SecurityImpact review request
 change I871af4018f99ddfcc8408708bdaaf480088ac477
Message-ID: <E1VbvEb-0008F7-Dj@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 d574e7d655a9a414bd998789e846d8492184f27b
Author: Dan Genin <Daniel.Genin at jhuapl.edu>
Date:   Fri Oct 25 16:38:19 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