[En-Nut-Discussion] local tcp port randomisation
harald.kipp at egnite.de
Tue Jul 3 09:39:46 CEST 2012
On 02.07.2012 23:54, Ole Reinhardt wrote:
Obviously I missed that one. Thanks for bringing it back to our attention.
I think, that the server was buggy, because it doesn't handle the new SYN correctly. Though, I'm not sure.
Anyway, the current Nut/OS implementation is problematic for several reasons. In the first place it is too easy for any attacker to guess the IP/port combination. It should be randomized, see RFC6056.
> a) it has a bug (local port number might overflow) and then would result
> in local ports between 1 and 4096
This is indeed bad, but even our current implementation doesn't follow IANA recommendations, which proposes 49152 to 65535 for ephemeral ports.
On the other hand, reducing the range will make guessing the port number easier. RFC6056 recommends to use 1024 to 65535. But that would require to keep a list of reserved ports, what we definitely don't want.
I'd suggest the following:
* Use timer ticks to select the start value _and_ the increment. Other algorithms like MD5 would add too much code.
* Use the IANA proposed range.
ticks = (uint16_t) NutGetMillis();
port = ticks;
port += ticks & 0x000F;
port |= 0xC000;
> Does anybody has noticed problems with the current implementation yet?
Never, but that shouldn't stop us from fixing it.
More information about the En-Nut-Discussion