Re: [bug-GNUnet] Serious vulnerabilities in GNUnet 0.6.4

[Christian Grothoff]

On Monday 30 Aug 2004 10:11 pm, Jack Lloyd wrote:
> 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.

Right, we've pretty much known this one from version 0.0.1.  The reason why 
this is still there is that nobody bothered to fix it so far.  And I'm not 
sure that it is that critical either: 2^24 effort to crack connections where 
you could instead just participate in the network and *be* one of the peers? 
Anyway, I'll bump this up a bit on my list of things to fix, just to make 
people who care more happy :-).


> 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.

Which identical leading initial plaintext? The first part of each message is 
the sequence number, which means no two messages will ever really start 
alike.  Now, communicating the different IVs would add another 20 bytes 
per-message overhead.  Considering that the sequence number pretty much 
prevents the attack that you describe, I'm not sure that the additional 20 
bytes would buy us anything except on some abstract plane of perceived 
security ("more random").  If you have some insight that changes this 
perception, please share it (and I'll consider changing the protocol once we 
break compatibility big time in the future).  

> 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).

a) yes, the attack can work (and I thought about how serious it would
    be back in 2002 and at that point concluded that it's not a priority).
b) GNUnet does not trust the other peers, the identity of the requester only
    matters for the accounting, so a peer would have to invest a lot of
    resources (computationally + spoofing/sniffing) to gain very little.  
c) it is highly likely that this will be fixed once we break compatibility (we
    have not done on this level since 0.4.x or so and I still do not consider
    this attack 'strong' or serious enough to justify breaking compatibilty
    to just fix this problem).

> 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.

Yes, a single key is used in both directions.  Now, what happens in the 
playback case?  Pretty much nothing: there's a high chance that it will be 
discarded (bad sequence number).  If not, it will be processed.  Now you must 
look at the individual protocols, which are designed to guard against such 
problems (in other words: it must not be disasterous since the other peer 
could have maliciously sent the same message).  In fact, I can assure you 
that nothing would happen at all (since the message would be considered 
either invalid, a dupe or useless). 

> 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.

Hmm.  The idea is to never assert on anything that could be set to a 'bad' 
value from the outside (should just be checked & discared).  Now the 
OpenSSL-verifySig asserts on the keysize, which is ok if and only if all 
paths to verifySig from input messages first check if the input is 'correct' 
with respect to the assertion.  If not, we should either not assert (warn, 
SYSERR) or fix the path.  Do you have any particular message path in mind 
where you believe we don't check?  (I believe the first thing we check 
everywhere is the message size, which _should_ imply the correct keysize, but 
I could obviously be wrong).


Anyway, thanks for your audit, I'll make sure that your concerns are addressed 
in due time in some way or other.

Christian