UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce the problem:
1. look at the code in old libsrtp under chrome tree.
2. look at the code in the new libsrtp under chrome tree
3. see that there is no check for enough entropy

What is the expected behavior?
before using random number generators a seed has to be initialized to make sure there is enough entropy. libsrtp didn't use to do this while using openssl and now is even worse.

What went wrong?
VULNERABILITY DETAILS

I looked at various libsrtp sources under your tree.

At old libsrtp versions the file rand_source_ossl.c was used to generate ramdom numbers but it was not used well. In newer versions crypto/cipher/cipher.c uses rand() that is not cryptographically secure.

**Old:

"chromium / chromium / deps / libsrtp / srtp / crypto / rng /rand_source_ossl.c"

The function RAND_bytes from openssl is called but it can not be sure about the entropy pool of the system. Under some intel CPUs that is enough according to this: https://software.intel.com/en-us/articles/how-to-use-the-rdrand-engine-in-openssl-for-random-number-generation

but under other platforms I think RAND_seed() or RAND_add() should be called.

**new:

At:
libsrtp/crypto/cipher/cipher.c 

static srtp_err_status_t srtp_cipher_rand (void *dest, uint32_t len)

It uses rand_s() where available (windows) but it defaults to rand() under linux so in my opinion the new version is worse than the previous version using openssl.

Best regards,

Iker.

Did this work before? No 

Chrome version: 58.0.3029.110  Channel: n/a
OS Version: any
Flash Version: