Back to the 90's: FragmentSmack

Published: 2018-08-17. Last Updated: 2018-08-17 10:36:07 UTC
by Remco Verhoef (Version: 1)
1 comment(s)

As we had the previous week SegmentSmack (CVE-2018-5390) allowing remote DoS attacks by sending crafted TCP packets, this week a similar vulnerability has been reported on IP fragments.

Juha-Matti Tilli has reported a vulnerability in the IP implementation of the Linux kernel, versions 3.9+. The vulnerability is being named FragmentSmack (CVE-2018-5391) and can be exploited by sending special crafted IP fragments at a low rate. Due to the increase of the reassembly queue size (you can find the commit here) in the Linux kernel 3.9+ it became exploitable. Similar vulnerabilities (exploits are being known as Teardrop attacks) have been seen before as far as in the 90's, starting with Windows NT 4.0, Windows 95 and Linux up to 2.0.32 (see this article). It has resurfaced in Windows 7 and Windows Vista and now reappearing in the Linux Kernel. The Teardrop attack originally crashed the system, while these newer vulnerabilities will "just" trigger excessive resource usage (increased CPU and RAM usage).

Crafted packets will use incorrect value for the fragment offset, causing it to be queued as long as the kernel is not able to reassemble and within thresholds.

The vulnerabilties can be exploited remotely, by sending crafted packets. As SegmentSmack needs a two-way TCP session (which makes it difficult to spoof), FragmentSmack works on IP fragments. Possibly making this spoofable and with increased impact. Proof of concept code hasn't appeared online (yet). 

Now there has been chosen an alternative approach by the Linux kernel developers, instead of fixing this specific issue, to completely drop the IP datagram in case of overlapping fragments. This makes it behaving the same as IPv6. There are no legitimate use cases for overlapping fragments, as can be found in the commit

If you are not able to apply the patch, changing the values net.ipv4.ipfrag_high_thresh and net.ipv4.ipfrag_low_thresh back to 256kB and 192 kB (respectively) or below will mitigate this problem.

References

  • http://www.tcpipguide.com/free/t_IPDatagramGeneralFormat.htm
  • https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=c2a936600f78aea00d3312ea4b66a79a4619f9b4 (commit introducing the vulnerability)
  • https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=c30f1fc041b74ecdb072dd44f858750414b8b19f (discard overlapping fragments)
  • https://insecure.org/sploits/linux.fragmentation.teardrop.html 
  • https://tools.cisco.com/security/center/viewAlert.x?alertId=122
  • https://www.kb.cert.org/vuls/id/641765
  • https://access.redhat.com/articles/3553061
  • https://bugzilla.redhat.com/show_bug.cgi?id=1609664

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec
PGP Key

Keywords:
1 comment(s)

Comments

Thresholds should be applied in correct order. Please see discussion in debian-security mailing list: https://lists.debian.org/debian-security/2018/08/msg00000.html

Diary Archives