DoS vector in protocol message stream

[rade]

I haven't tested this, but I reckon there is DoS vector in the protocol message stream that attackers can exploit without breaking our crypto.

The weave TCP protocol is a gob stream of messages: a map[string][string] for the first message, the handshake, followed by []byte messages. The latter are all encrypted when crypto is enabled. Note that it's the individual messages that are encrypted, not the stream. And the first message - the handshake - is always unencrypted.

It is therefore possible for an attacker to exploit weaknesses in gob. The following spring to mind:

1. triggering an OOM crash by sending a very large gob message
2. triggering an OOM crash by sending a sequence of octets that triggers a large memory allocation in gob
3. triggering a loop in the gob decoder

I am quite sure 1 is possible. There is a 1GB limit in place but a) that's still quite large, and b) doesn't apply everywhere.

2 is different from 1 because it does not require network capacity and is therefore impossible to guard against with firewalls that enforce capacity limits. And I think it is possible, based on my reading of the gob decoder, i.e. there are places where a capacity is read and then an allocation of that capacity is performed.

I don't think 3 is possible, based on the description of gob. But I could well be wrong.

[inercia]

When you say "very large gob message", does the receiver accept messages with any length? I guess there should be a reasonable upper limit...

[rade]

see my analysis above re length. The only limit I can find is 1GB, and it does not apply everywhere.

[inercia]

You analysis talks about the gob limits, but what I mean is whether we check the message length before passing it to the gob decoder... I think it does not make sense to try to decode any message (specially if we want protocol upgradeability)

[rade]

There is no such thing as "messages" before the gob decoder. The gob layer is what gives us our message framing.

[inercia]

Oh, I see, so we are in the hands of gob...

[squaremo]

Oh, I see, so we are in the hands of gob...

Nice :)

It strikes me that either

1. The maximum buffer size in gob should be adjustable (drastically, downwards); or,
2. gob is a poor choice for the purpose to which weave puts it.

[paulbellamy]

Wire-encodings of messages is limited to 1GB, but by using specific structs you can create a gob stream where:

Encoded:     15 MB
Allocated: 1931 MB

Not yet sure if it is exploitable in weave.

[rade]

Is that using straight gob or did it involve injecting byte sequences that "look like gob"? It's the latter that I suspect might permit allocating arbitrary large amounts of memory from little input. Not sure though; very much depends on the structure and implementation of the gob codec.

[paulbellamy]

regular gob. Encoding a large recursive tree struct of strings (because zero-value strings are omitted from transmission).

[paulbellamy]

slices have their size checked before decoding, but structs don't.

[paulbellamy]

Related: golang/go#10490 and golang/go#10273