SACK Panic: Multiple TCP-based remote denial of service vulnerabilities

Installing and Using OpenWrt
1

Netflix has identified several TCP networking vulnerabilities in FreeBSD and Linux kernels.

The vulnerabilities specifically relate to the minimum segment size (MSS) and TCP Selective Acknowledgement (SACK) capabilities. The most serious, dubbed “SACK Panic ,” allows a remotely-triggered kernel panic on recent Linux kernels.

6 Likes
2

Currently known workarounds:

  • Disable SACK processing by executing "sysctl -w net.ipv4.tcp_sack=0". And to make it permanent across reboots, "echo "net.ipv4.tcp_sack=0" > /etc/sysctl.d/90-SACK_Panic.conf".
  • Block low-MSS packets on the firewall with "echo "iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP" >> /etc/firewall.user".
2 Likes
3

...except that it doesn't fix CVE-2019-11479 on Linux.

4

I am editing my post right now, adding instructions for that vulnerability, too; thanks for pointing it out.

5

kernel source been patched yesterday https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.127

1 Like
6

does not work since missing -w -> sysctl -w net.ipv4.tcp_sack=0

From own experience, a node with kernel 4.14.123, the above has stopped the reboots caused by the attack - seen this been exploited for the past 2 weeks

7

Well, it seemed to work here, but it makes sense; I fixed my post, thanks!

1 Like
8

iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP addresses CVE-2019-11479 according to https://www.openwall.com/lists/oss-security/2019/06/17/5.

9

That comes at additional cpu cost. Are you implying that the patched source kernel is not sufficient and requires additional netfilter intervention?

10

No I am implying that the statement "[@eduperez posted workarounds] don't fix CVE-2019-11479 on Linux" contradicts https://www.openwall.com/lists/oss-security/2019/06/17/5 which suggests the netfilter rule (among other filter options) as temporary workaround for issue #4 (CVE-2019-11479).

1 Like
11

I see, thanks for the clarification. So were waiting then for the patched kernel to arrive

12

isn't the default on wan port to block all incoming. Is this not sufficient?

13

Some reports indicate the only devices that accept incoming TCP connections are affected. However, I am not sure that devices routing TCP connections on behalf of others are not affected.

I do not pretend to be an expert on the subject, I'm just reporting here the info I have gathered.

14

It is not unfortunately, you would have to look into the technicalities of the bug or the patch.

15

The kernels containing the fixes for these CVE's have been pushed to master, 19.07 and 18.06.
17.01 will follow within 1 .. 2 days normally.

edit: @hauke pushed to 17.01 already.

1 Like
16

For FreeBSD users, from the linked Netflix article

CVE-2019-5599: SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

Workaround #1: Apply the patch split_limit.patch and set the net.inet.tcp.rack.split_limit sysctl to a reasonable value to limit the size of the SACK table.

Workaround #2: Temporarily disable the RACK TCP stack.

From https://lists.freebsd.org/pipermail/svn-src-all/2018-June/165204.html

  To build this into your kernel you will need to enable in your
  kernel:
     makeoptions WITH_EXTRA_TCP_STACKS=1
     options TCPHPTS
  
  Sponsored by:	Netflix Inc.
1 Like
17

Thanks for this! Had to install iptables-mod-ipopt to be able to run the iptables line on 18.02.

18

Which I wrote before @eduperez edited his post (indicated by post #4) :slight_smile:

19

I am very sorry then. Didn't notice that the post was edited earlier.

20

No worries