Unsafe use of g_random_int()

Michael McConville mmcconville at mykolab.com
Sat Aug 15 13:44:48 EDT 2015


Ethan Blanton wrote:
> Folks,
> 
> What we need to decide here is whether we should do a coordinated
> release for this.  Mike is prepared to put a CSPRNG in purple 2 (using
> /dev/urandom), and purple 3 will have a proper RNG interface in
> purple_util (using an SSL library if available, and urandom if not).
> 
> This is certainly a security-related bug.  I think it should have a
> CVE.  I don't think it's readily exploitable due to its position (even
> with a non-CSPRNG, 64 bits of identical data is unlikely, and this
> nonce is only created on a connection attempt -- so the number of
> times you create it will be relatively low, and attacking it would
> involve auth failures, which you'd notice), but it's still bad.
> 
> I will help Mike through requesting a CVE from our RH friends.
> 
> But ... do we just publish the CVE, fix it and let it sit until the
> next purple-2 release, or do we coordinate a purple-2 release for
> shortly after GSoC with this fix in place?  Thoughts?
> 
> Ethan

Repo, for those interested:

	https://hg.pidgin.im/soc/2015/mmcc/rand


More information about the security mailing list