[bug-GNUnet] Serious vulnerabilities in GNUnet 0.6.4

[Jack Lloyd]

Hi,

I noticed a number of vulnerabilities in GNUnet 0.6.4. This list is roughly
ordered from most to least critical.

1) Session keys are generated using rand(), seeded with time():

void makeSessionkey(SESSIONKEY * key) {
  int i;
  for (i=0;i<SESSIONKEY_LEN;i++)
    key->key[i] = rand();
}

It looks like if gcrypt is used then an entropy poll is run, but the PRNG is
not used for session keys.

There are only 31556926 seconds in a year, meaning an attacker can list and
check all the keys that are going to be generated this year with only 2^24
effort. Even if the clock is wildly off, most systems only support a 32-bit
time_t, leading to a maximum effort of 2^32 for a key recovery.

It's actually slightly more tricky that that, because it depends on the
system's implementation of rand(), but that only adds a factor of 2 or 3 to the
search (assuming the attacker doesn't know the user's OS through other means,
such as TCP fingerprinting).

Using the crypto libraries built-in PRNG will provide safe keys.

2) Initialization vectors are constant.

It appears that all packets are encrypted with a constant IV of "GNUnet!!"
using CFB mode. This is fairly insecure, as it fails to hide either identical
plaintexts or leading initial plaintexts. That is, if two plaintexts with the
same prefex are sent, the attacker can determine this. To prevent this, use
random per-message IVs.

3) Weak message authentication.

CRC is used as the message checksum. This is extremely weak -- note the attacks
against WEP and CIPE, which also use CRC for message authentication. HMAC with
a strong hash (eg, SHA-1 or SHA-256) should be used for MACs.

The same key should not be used by both the MAC and cipher mechanisms. It is
possible to derive two distinct keys from the same shared secret using a PRF
(TLS 1.0 provides a fairly good example of this).

4) Shared keys.

I am having a hard time figuring out exactly how the key exchange works, but it
appears that a single key is used in both directions of the communication. If
so, this means an attacker can capture a message and play it back at the
sender, who will think it came from the other party. Depending on the message
in question, the victim might either disregard the message as invalid, or
process it, which could have disasterous effects.

5) Easy to DOS

At various points GNUnet seems to call assert() in cases of invalid input. Some
of these inputs can be controlled by a remote party. For example, the OpenSSL
version of verifySig will assert if the other parties key is not exactly 2048
bits long.

Regards,
  Jack