Unsafe use of g_random_int()

[Ethan Blanton]

Michael McConville spake unto us the following wisdom:
> I've been auditing Pidgin/libpurple's randomness usage for the past few
> days. Ethan and I are working on a CPRNG API that can be used throughout
> the codebase.
> 
> rand() is used in the MSN Nexus code (libpurple/protocols/msn/nexus.c).
> There isn't an immediately apparent use of srand(), so that's *really*
> bad. However, I can't find out whether MSN Nexus exists anymore or even
> what the hell it is.

This is part of the msnp protocol plugin that no longer works.  It
should be commented that it must be fixed if it's updated to work in
the future, and abandoned.

> There's a more serious concern, though. Specifically, there are uses of
> the Glib function g_random_int() to generate nonces in the Jabber SCRAM
> and DIGEST_MD5 SASL code. The Glib docs state:
> 
> > Do not use this API for cryptographic purposes such as key generation,
> > nonces, salts or one-time pads.
> 
> 	https://developer.gnome.org/glib/stable/glib-Random-Numbers.html
> 
> The nonces generated seem cryptographic, but I'm not familiar with the
> protocol. This may not be used if Cyrus is available.
> 
> I'm not sure whether Glib is just being conservative in this warning, or
> if using this for random number is seriously dangerous.

My analysis of this is that it's dangerous, but unlikely to be
immediately exploitable.  I think we should fix it, have a CVE issued,
and then coordinate the next normal release of Pidgin.  I don't think
we need to push a release for this.

The bigger problem here is that fixing this in libpurple2 may be
difficult, since we don't have or expose a good source of
cryptographically secure random data.  Probably we should go ahead and
snag a few bytes from /dev/urandom for this purpose.

Ethan