Bug#815442: stun: seeds RNG from TSC clock? (was: FTBFS on kfreebsd-amd64: #error Need some way to seed the random number generator)

[Steven Chamberlain]

Steven Chamberlain wrote:
> the TSC clock!?  *omg*  Is that really a good entropy source?

stunRand() takes the 32 LSBs from the TSC, on x86 machines.  It is a
CPU cycle counter.  These 32 bits seems to wrap around every 10-60
seconds or so, depending on clock speed.  Apart from that, they maybe do
contain a bit of entropy.

stun.cxx reads it only once, to seed random().  I don't know if this is
server or client code.  If it's a daemon that starts on boot, then
depending how quickly the system booted, the TSC may not have wrapped at
all yet and some of the MSBs would be zero.  Many bits could be the same
across reboots also.

If a local attacker polled the TSC at the same time (on boot or on a
subsequent restart of stun, they may be able to predict the RNG's seed
to within a few bits.

If a seccomp sandbox is used, reading the actual TSC may not be
possible, so I'm not sure what stun would seed with in that case.  Maybe
on some older processors there is no TSC available...?

The RNG seems to be used for some kind of HMAC later.  And for choosing
a 'random' port for something.  It uses random() for that, having seeded
it.  random() doesn't have strong cryptographic properties, so someone
able to observe the output may be able to backtrack to determine the
seed or predict the next value?

Maybe someone else has more expertise on this.  I'm fairly sure stun
should stop using the TSC here though?  And possibly not use random()
either.  I think this is a perfect situation to use arc4random() from
libbsd, because it knows how to reliably get entropy on every Debian
platform.  I'd be happy to provide a patch if desired.

Regards,
-- 
Steven Chamberlain
steven at pyro.eu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20160221/7372ec55/attachment.sig>