[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] How to limit the UDP Rx packet size to avoid big RAM al
From: |
address@hidden |
Subject: |
Re: [lwip-users] How to limit the UDP Rx packet size to avoid big RAM allocations |
Date: |
Tue, 26 Jun 2018 20:50:24 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
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