Re: [lwip-users] How to limit the UDP Rx packet size to avoid big RAM allocations

[address@hidden]

On 26.06.2018 15:15, R. Diez wrote:
> [..]
> However, if we now consider IP reassembly, a single reassembled packet
> can already get over that 32 KiB memory limit, right? I believe that a
> single UDP packet can be up to roughly 64 KiB long. An attacker can
> exhaust the whole lwIP memory with just 1 or 2 big, fragmented packets.
> If an attacker sends them continuously, lwIP processing will mostly
> grind to a halt, right?

That's why we have IP_REASS_MAX_PBUFS.

> With an MTU of around 1500 bytes, does it make sense for lwIP to try to
> reassemble such huge packets?

Yes. The MTU has nothing to do with the size of the packets you want to 
receive. That's why we have fragmentation and reassembly.

> How about a new constant like MAX_REASSEMBLED_PACKET_SIZE?

I'm not opposed to such a constant...

> If I set it to say 2,048, and lwIP
> immediately drops any segment that goes over that limit, wouldn't it at
> least mitigate such attacks?

... however, it does *not* harden your system against the attack you 
described:

> Or do you think that an effective defence is impossible anyway, because
> the attacker can just increase the number of IP packet fragments? Those
> fragments could belong to different IP packets, for example, just by
> changing the source port number of TCP packets.

And you seem to answer the question yourself. Again, that's why we have 
IP_REASS_MAX_PBUFS. Have you read the comment above the define in opt.h?

For TCP ooseq buffering (TCP_QUEUE_OOSEQ), you have a similar issue, but 
here we a hook that frees the queued pbufs of one pcb if we run out of 
input pbufs (in addition to various limitation defines). Maybe we could 
add the reassembly queues to this freeing hook...


Simon