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