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@pyro.eu.org
Attachment:
signature.asc
Description: Digital signature