TCP Flaw Lets Remote Attackers Stall Devices With Tiny DoS Attack (zdnet.com) 54
An anonymous reader quotes a report from ZDNet: Security researchers are warning Linux system users of a bug in the Linux kernel version 4.9 and up that could be used to hit systems with a denial-of-service attack on networking kit. The warning comes from Carnegie Mellon University's CERT/CC, which notes that newer versions of the Linux kernel can be "forced to make very expensive calls to tcp_collapse_ofo_queue() and tcp_prune_ofo_queue() for every incoming packet which can lead to a denial of service (DoS)".
It lists a number of network-equipment vendors, PC and server manufacturers, mobile vendors, and operating-system makers that may be affected but notes that it hasn't confirmed whether any of them actually are. But, given the widespread use of Linux, the bug could affect every vendor from Amazon and Apple through to Ubuntu and ZyXEL. A remote attacker could cause a DoS by sending specially modified packets within ongoing TCP sessions. But sustaining the DoS condition would mean an attacker needs to have continuous two-way TCP sessions to a reachable and open port. The bug, dubbed "SegmentSmack" by Red Hat, has "no effective workaround/mitigation besides a fixed kernel."
It lists a number of network-equipment vendors, PC and server manufacturers, mobile vendors, and operating-system makers that may be affected but notes that it hasn't confirmed whether any of them actually are. But, given the widespread use of Linux, the bug could affect every vendor from Amazon and Apple through to Ubuntu and ZyXEL. A remote attacker could cause a DoS by sending specially modified packets within ongoing TCP sessions. But sustaining the DoS condition would mean an attacker needs to have continuous two-way TCP sessions to a reachable and open port. The bug, dubbed "SegmentSmack" by Red Hat, has "no effective workaround/mitigation besides a fixed kernel."
Re: (Score:1)
You're angry because you have a tiny DoS.
Tiny DoS Attack (refrain) (Score:4, Funny)
Hold me closer, Tiny DoSser...
Count the packets on the (information super) highway,
Lay me down with TCP calls,
You've had a busy day today.
Re: (Score:1)
Slow clap.
Re: (Score:2)
Slow claps are the best claps!
Re: (Score:3)
Re: (Score:2)
Eww... too much information.
Re: (Score:1)
Re: (Score:1, Funny)
Yes, I heard they duct tape old iPhones together to make their servers.
Re: (Score:1)
+1, adorable
Not just Linux (Score:5, Informative)
The summary seems to suggest the TCP issue is primarily a Linux bug, but the FreeBSD team fixed this same issue earlier in the week. The bug is not limited to one kernel.
Re: (Score:1)
If I have to switch from Mac OS X/macOS, I know which OS I'm going to use. The FreeBSD team seems quick to fix things.
Re: (Score:3)
If you don't care about running a binary graphics driver, it's a fine choice. If you do, then Linux is your only non-Windows/OSX choice. If I had an antique graphics card I'd probably be happy with the free driver, but it's only one generation old and for full performance I still need a real driver.
Re:Not just Linux (Score:4, Informative)
All they did is add an option to limit reassembly queue size. Not a fix. Merely a workaround.
https://lists.freebsd.org/pipermail/freebsd-announce/2018-August/001837.html
TCP flaw? (Score:2)
Did the find a flaw in the Transmission Control Protocol? Or in the Linux implementation of same? In the latter case, that's a Linux bug, not TCP.
Re: (Score:3)
Most flaws found have been implementation flaws (e.g., xmas attack and others), I think the only real TCP flaw was SYN-flooding with spoofed hosts. Before everyone switched to syncookies, doing so would consume resources on the host for book-keeping of those half-open connections (until it timed out). Now that everyone uses syncookies to do the book-keeping of TCP
Linux Patch Link Here (Score:5, Informative)
Not sure why the editors didn't include the actual patch or technical details, but here's the thread [ozlabs.org]. Click "Related" at the top to see the 5-part patch.
In short, looking at the patch, the DOS attacks the sequence/buffer for reordering TCP packets. Specifically, after sending lots of tiny packets with out of order sequence numbers, a couple things happen:
(1) There is an expensive operation to coalesce adjacent packets. This has to run through the entire out of order RB tree, and generally sucks. The fix avoids doing this until the OOO buffer is almost entirely full.
(2) When doing the collapse, keep track of how many 'tiny' packets there are and just bail out rather than continuing to do lots of operations/copies attempting to coalesce them.
(3) Once you've filled up the entire OOO buffer, Linux only drops just enough older packets to get under the boundary. This exacerbates the previous issues, as the attacker can keep the buffer entirely full. The patch changes this always drop in batches (1/8th of the memory) each time it's full.
Neat patch. Editors, next time can we get some real analysis?
Re: Kernel update required?? (Score:2)
You probably should have read the next two words, instead of just stopping at "4.9".
TFS's most interesting moniker for Oracle... (Score:3)
The "Solaris slinger"