oss-sec mailing list archives

Concerns about CVE-2017-5972


From: Wade Mealing <wmealing () redhat com>
Date: Thu, 9 Mar 2017 14:53:52 +1000

Gday,

From the original description from Hosein Askari (CC'ed) :

---
The TCP stack in the Linux kernel 3.x does not properly implement a
SYN cookie protection mechanism for the case of a fast network
connection, which allows remote attackers to cause a denial of service
(CPU consumption) by sending many TCP SYN packets, as demonstrated by
an attack against the kernel-3.10.0 package in CentOS Linux 7.
---

This topic was covered by github[1], in which they chose to use
synsanity as a mitigation process.

After spending some time looking at this allocation, I was unable to
reproduce the initial findings on either Red Hat Enterprise Linux 6
(based on 2.6.32) or 7 (based on 3.10) using direct host to host via
qemu or the e1000 driver as shown in the backtrace.  This with both
syn cookies enabled and disabled.

The backtrace provided shows that there is a slowpath in transmitting
ICMP reply packets which does not show the TCP syn cookie function in
the slowpath/backtrace.

I have attempted to performance profile this and found the syncookie
generation (under heavy syn attacks from multiple sources) did not
show significant impact on CPU performance compared to the packet
handling  in use.  I'm not saying its impossible I'm just saying the
backtrace doesn't match the events that are shown.

I -have- however been able to artificially recreate a very similar
backtrace through stuffing fake packets in with a kernel module and
created a hardening bug, however this seems unrelated as far as I can
see ( See https://bugzilla.redhat.com/show_bug.cgi?id=1428684 ).

The reproducer code is from a file called called "Trigemini.c" and is
found in several DDoS kits for at least the last 2 years, although
it's true origins are probably older, it is not possible to reproduce
or recreate on any scale I was able to test with.

I give Hosein a chance to talk more about his reproducer, in hope that
we can get a better understanding on how this was reproduced reliably.

Thank you

Wade Mealing
Red Hat Product Security

[1] https://githubengineering.com/syn-flood-mitigation-with-synsanity/
[2] https://github.com/LOLSquad/DDoS-Scripts/blob/master/TriGemini.c


Current thread: