Date: Thu, 19 Feb 2004 01:47:23 +0100 From: Andre Oppermann <andre@freebsd.org> To: "Jacques A. Vidrine" <nectar@FreeBSD.org>, freebsd-net@freebsd.org, FreeBSD Security Officer Team <security-team@FreeBSD.org> Subject: Re: Fwd: [is this mbuf problem real?] Message-ID: <4034079B.8C29425C@freebsd.org> References: <20040218220230.GF47727@madman.celabo.org> <4034049A.906ACDB9@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andre Oppermann wrote: > > "Jacques A. Vidrine" wrote: > > > > Does anyone have time to investigate? I will try to get more > > information from iDEFENSE. > > Looking at the code there are indeed some problems. > > - there seems to be no boundary on how many segments we keep in the > tcp reassembly queue > - there seems to be no timeout of overaged fragments (we can drop > the segments after 1*msl because we don't have SACK and it has > to be retransmitted anyway since not ACK'ed which happens after > read from userland). Possibly it can be dropped earlier after > we've got x bytes or packets of more segments since it is un- > likely to receive the missing packet this late except for really > massive reordering > - this attack can be made with small packets which consume an mbuf > cluster anyway - it uses MALLOC() to allocate its queue entry wheras it probably should use the zone allocator. The max limit on the zone than directly gives us a upper limit on the number of concatenated segments (not mbufs) - it uses LIST_FOREACH which is pretty inefficient. NetBSD has optimized this part quite a bit with a tail queue > For IP packet reassembly we have global and local limits: > > net.inet.ip.maxfragpackets: 800 > net.inet.ip.maxfragsperpacket: 16 > > Something like this is needed for TCP as well to cope with this kind > of resource exhaustion attack. > > I can fix this stuff but I won't be able to do that in emergency mode. > The first code can be ready after the weekend. If someone else wants > to takle it earlier/faster tell me. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4034079B.8C29425C>