swallowcc / rfc5766-turn-server

Automatically exported from code.google.com/p/rfc5766-turn-server
0 stars 0 forks source link

Nonces and Transaction-IDs not cryptographically random #109

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
According to RFC 5389, STUN Transaction IDs SHOULD be cryptographically random; 
RFC 5766 similarly says that nonces SHOULD be cryptographically random, and 
cites RFC 4086.

However, rfc5766-turn-server instead uses random() to generate STUN Transaction 
IDs and nonces, and seeds it using srandom(time(NULL)).  random() is a 
non-cryptographically-secure non-linear additive feedback random number 
generator, and guessing the time a server was started (to the nearest second) 
is often not very hard.

This could potentially let an attacker guess nonces and transaction-IDs, if it 
can make a reasonable guess about the time the server was started, or observe 
enough random bits output to determine the internal state of random().

What steps will reproduce the problem?
1. Generate nonces and transaction-IDs.

What is the expected output? What do you see instead?

Expect cryptographically-random bits; instead get weak randomness.

What version of the product are you using? On what operating system?

turnserver-3.2.2.7, Ubuntu 12.04

Please provide any additional information below.

Since rfc5766-turn-server depends unconditionally on OpenSSL, calling OpenSSL's 
RAND_bytes() function is probably the best way to get cryptographically random 
bytes in a portable manner.

The cryptographic randomness of transaction IDs isn't that important for the 
server as far as I can tell (since it only ever generates them for indications, 
for which transaction IDs are only useful for debugging), but this code is also 
shared with the client library where it's important for requests (since they 
stop an off-path attacker from forging responses).  For the server, security of 
nonces is more concerning.

I haven't audited the other uses of random() in the turn server code to see 
whether they also need to be cryptographically strong, but it probably couldn't 
hurt unless they're performance-critical.

Original issue reported on code.google.com by jonathan...@gmail.com on 19 Feb 2014 at 9:02

GoogleCodeExporter commented 9 years ago

Original comment by mom040...@gmail.com on 19 Feb 2014 at 9:43

GoogleCodeExporter commented 9 years ago
Will be fixed in 3.2.2.8

Original comment by mom040...@gmail.com on 20 Feb 2014 at 12:14

GoogleCodeExporter commented 9 years ago

Original comment by mom040...@gmail.com on 22 Feb 2014 at 8:32