Open Stack

> -----Original Message-----
> From: Grant Murphy [mailto:gmurphy at redhat.com]
> Sent: Thursday, January 16, 2014 5:35 PM
> To: openstack-security at lists.openstack.org
> Subject: [Openstack-security] [Bug 1267912] Re: OS::Heat::RandomString
> uses OS entropy source directly
>
> (off topic)
> I would like to see a more consistent usage of cryptographic operations
> across the board. I guess this is the intention of Oslo. If the usage of
PyCryto
> is not advised at this point in time would it make more sense to use
> something like PyOpenSSL in Oslo instead?  It looks like it is a backend
for
> Jarret's cryptography module so would be a suitable as a temporary
> dependency or would that just introduce too much busy work?

The PyOpenSSL author is working with the cryptography team and has a branch
of PyOpenSSL based on cryptography. It's an alpha, but it will be the way
forward. I would like to see cryptography added to OpenStack at some point,
but I think we still have some work to do before we get there. In the
meantime, I would just leave it alone until we have a suitable replacement
in cryptography.

Paul Kehrer and I will be talking about these issues in April at Pycon. It
might be worth seeing where we are at that point and talking through the
options at the Summit in May. Assuming the code is ready, we could start the
process of creating / updating oslo.crypto and starting the process of teams
moving to use cryptography. This would allow the deployed to choose which
codebase they wanted. We currently have backends for openssl, common-crypto
for mac and gcrypt. We are looking into NSS and pycrypto as well.

> So my question is now - Should we raise a bug against the use of PyCrypto
is
> it hasn't been audited ?

There wouldn't be much an open source tool could do to solve that one. An
audit would require a significant sponsor. Depending on the desired audit
regime (e.g. if you want FIPS or the like) you could be talking anywhere
from 50k to several hundred thousand.


Jarret


> You received this bug notification because you are a member of OpenStack
> Security Group, which is subscribed to OpenStack.
> https://bugs.launchpad.net/bugs/1267912
> 
> Title:
>   OS::Heat::RandomString uses OS entropy source directly
> 
> Status in Orchestration API (Heat):
>   Confirmed
> 
> Bug description:
>   The RandomString resource documentation[1] suggests that it's useful
>   for generating passwords and secrets. It doesn't mention the security
>   guarantees, however.
> 
>   Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
>   something like PyCrypto or better yet, have Oslo provide a
>   cryptographically secure random generator and use that.
> 
>   On Linux, random.SystemRandom reads from /dev/urandom which if I
>   understand things correctly, can have its entropy depleted. So a Heat
>   user could use a template that asks for a huge amount of randomness
>   and empty the entropy pool of the entire system (not just Heat).
> 
>   This would probably be difficult to exploit, but I think it'd be safer
>   use the entropy to seed a CSPRNG instead of using it directly. Which
>   is exactly what PyCrypto seems to do.
> 
>   Regardless, the security guarantees and implications of
>   OS::Heat::RandomString should be documented.
> 
>   [1]:
> http://docs.openstack.org/developer/heat/template_guide/openstack.html
> #OS::Heat::RandomString
>   [2]:
> https://github.com/openstack/heat/blob/master/heat/engine/resources/ra
> ndom_string.py#L81
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

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

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

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