Open Stack

All,


I¹d be concerned about making this change. Fundamentally, the os
/dev/urandom is cryptographically secure while creating a
cryptographically secure PRNG is actually quite difficult, especially one
built on PyCrypto which is a non-verified code base.

In the case of /dev/urandom, it seeds from the internal pool that also
supplies /dev/random. Once this seeding is complete, urandom can be relied
upon to supply random data without blocking or exhaustion problems. The
only time when there could be an issue is shortly after boot before the
kernel has generated enough entropy to sufficiently seed urandom.

This problem seems unlikely to appear in most OpenStack deployments and is
the same problem one would have to solve to adequately seed the PyCrypto
PRNG anyway.

Barbican has been thinking about exposing a /random resource that would
allow any user (no auth required) to pull a block of truly random data
from the HSMs for any case where someone would need it. We¹ve been on the
fence as the actual use cases seem nonexistent at the moment, but it is an
option for the future if we need it.

In short - we can probably leave the code the way it is.


Jarret



On 1/13/14, 7:02 AM, "Thierry Carrez" <thierry.carrez+lp at gmail.com> wrote:

>Opened.
>
>** Information type changed from Private Security to Public
>
>** Tags added: security
>
>** No longer affects: ossa
>
>-- 
>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
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5551 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140113/e2848971/attachment.bin>