Open Stack

> As a result, if there is not sufficient entropy in the entropy
> pool, the returned values are theoretically vulnerable to a
> cryptographic attack on the algorithms used by the driver.
To avoid entropy depletion attacks, you keep the generator in good
working order.

To keep the generator in good working order, you should consider
practicing hedging. Hedging ensures there is sufficient entropy even
if the platform cannot. As long the prng's state is held secret from
the attacker, the system will be in good working order.

The two papers of interest on hedging that I am aware: [0, 1].

Hedging is not dependent upon lower level drivers, like virtio. Even
if the virtio driver is misconfigured or broken, its will still
produce a usable stream (assuming initial state was sufficient).


[0] When Virtual is Harder than Real: Resource Allocation Challenges
in Virtual Machine Based IT Environments,
http://static.usenix.org/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf

[1] When Good Randomness Goes Bad: Virtual Machine Reset
Vulnerabilities and Hedging Deployed Cryptography,
http://www.isoc.org/isoc/conferences/ndss/10/pdf/15.pdf


On Thu, Jan 16, 2014 at 6:34 PM, Grant Murphy <gmurphy at redhat.com> wrote:
> FWIW Tomas I can see how you may have thought that.
>
> This is from the manpage of urandom:
>
> A  read  from the /dev/urandom device will not block waiting for more entropy.  As a result, if there is not
> sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic
> attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current
> unclassified literature, but  it is theoretically possible that such an attack may exist.  If this is a concern in
> your application, use /dev/random instead.
>
>
> (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?
>
> So my question is now - Should we raise a bug against the use of
> PyCrypto is it hasn't been audited ?
>
> --
> 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

-- 
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