FreeBSD has its own TCP-queue-of-death bug, easier to hose than Linux's SegmentSmack Hard on the heels of the Linux kernel's packets-of-death attack dubbed SegmentSmack, a similar vulnerability has been disclosed and fixed in FreeBSD. Attributed to SegmentSmack discoverer Juha-Matti Tilli of Aalto University in Finland, the FreeBSD TCP issue is related to how the operating system's networking stack reassembles …
Someone once said that the existence of fragmentation in IP shows "how much experimentation was going on in the early days of the Internet".
I mean seriously, I know it seems like a straight-forward idea. You have a packet, it's larger than your MTU, you split it into two. However the complexity on the other side is immense if you think about it for more than a few minutes.
These problems seem to be about uncontrolled resource allocation for particular (malicious) edge-case patterns of network data.
But shouldn't good edge-case tests pick them up? A good test must include worst case. It seems like tests are only ever about the headlines: bandwidth and reliability with 'normal' data.
Somebody gotta crank up the fuzz.
As a mathematician, get hosed. Formally checked proofs are really, really hard to implement unless you have the training to do proper proofs in the first place, and there just aren't that many of us around.
And given that bad proofs have in fact gotten out from time to time means that even mathematicians are not immune to logical failures, so formally checked proofs ARE the only way to ensure a system is bug-free. If you can somehow prove that what has been proven actually corresponds to what has been implemented.
I spent seven years doing random testing at the microprocessor level. I guarantee one thing about fuzzers--they cannot cover everything.
IIRC, the (original) Windows IP stack was BSD derived, so it _might_ have silently inherited the bug. OTOH, that was some time ago, and one would hope that somewhere along the path to IPV6, somebody would have at least looked at the code.
As I wrote this, I wondered why this is referred to as a TCP issue. Fragments and re-assembly also apply to UDP, so maybe either
1) The same bug may be exploitable with a big enough UDP datagram.
or
2) For some reason (cough - cut and -paste -cough) the code was duplicated, and now _one_ copy has been fixed.
high bandwidth sites are probably the most effected. I expect those who have poor connection speed won't see any visible changes. Maybe a few spikes in CPU from some attempts to DDoS but that's about it.
The early fix simply surfaces the sysctl setting, apparently for this variable:
static u_int tcp_reass_maxqueuelen = 100;
by surfacing it as a sysctl setting, the sysadmin would be able to tweek it. However you'd need the first patch to be able to tweek it at all, and THEN the subsequent patch (which does not yet exist) to REALLY fix it.
Maybe I'll ask some of the devs on IRC - I hang out in a dev channel and do kernel-related stuff for FBSD on occasion. But by now I'm sure they're tired of being asked.
A bit of a necro-post, but someone may be reading the archives.
IP fragmentation and TCP segmentation are similar concepts at different layers. TCP generally segments the data so that the underlying IP packets don't need to be fragmented. UDP relies on IP fragmentation.
IP "frag bombs" have been known about since the early days of TCP/IP. Once you know the reassembly algorithm, you can figure out a way to send irregular fragments to maximize the memory used without the target being able to reassemble a complete packet. If they implement a fragment count limit, you send the a bunch of almost-full-sized fragments. If they implement a fragment data count limit, you send a zillion one word fragments. If they implement a per-endpoint limit, you spread the traffic over multiple endpoints.
Early TCP/IP implementations sometimes created 'mini frag bombs' unintentionally. The 'obvious' way to fragment a packet is to send the first fragment of data, then the second. The matching implementation appends the fragments to a list and attempts reassembly when the 'end' fragment is received. But since only the final fragment has the 'end' marker that indicates the size, some implementations send the final fragment first so that a reassembly buffer can be allocated immediately. If you do this, it is natural to send fragments in decreasing order, which is worst-case for the first approach.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
