Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SACK Panic – Multiple TCP-based remote denial-of-service issues

access.redhat.com

Post reply on HN
Print view View original

51–60 of 134 posts

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#51

Post by gravitas »

jhayward wrote: post #47
gravitas wrote: post #18

I'm collecting vendor links internally for work: Red Hat / CentOS https://access.redhat.com/security/vulnerabilities/tcpsack https://access.redhat.com/security/cve/cve-2019-11477 https://access.redhat.com/security/cve/cve-2019-11478 https://access.redhat.com/security/cve/cve-2019-11479 Ubuntu https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SACKPanic https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2... h…

If you don't use the block-quote format, HN will make the links clickable: [edit: deleted link, OP has updated]

Done, thanks. Kinda looks like ass, but we don't have a lot to work with here. :-/

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#52

Post by gravitas »

captn3m0 wrote: post #46
gravitas wrote: post #18

I'm collecting vendor links internally for work: Red Hat / CentOS https://access.redhat.com/security/vulnerabilities/tcpsack https://access.redhat.com/security/cve/cve-2019-11477 https://access.redhat.com/security/cve/cve-2019-11478 https://access.redhat.com/security/cve/cve-2019-11479 Ubuntu https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SACKPanic https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2... h…

CoreOS has a new release out: https://coreos.com/releases/#2079.6.0

Got it, looks like 2 of y'all are watching CoreOS like a hawk. :)

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#53

Post by syn0byte »

acdha wrote: post #42
syn0byte wrote: post #32

Earlier quoted context omitted.

No, not "any system". Besides needing SACK enabled (which is by default) you also need segment offloading and non-shite networking hardware that will respect and preserve stupid MSS fields in packets. pending a patch simply disable SACK: ~$ echo 0 > /proc/sys/net/ipv4/tcp_sack and/or disable segmentation offloading: ~$ ethtool -K eth? tso off TCP and Checksum offloading still aren't super standard on customer grade N…

> TCP and Checksum offloading still aren't super standard on customer grade NICs or virtual machines. I thought VMware shipped that at least decade ago — is there some specific sub-feature you had in mind? Similarly, at least Apple's consumer hardware had checksum offloading back in the early 2000s and segmentation support shipped in 10.6 (2009) so it seems like it should be relatively mainstream since they tended to…

No doubt check summing support's been around for a while, ASIC Md5 is dirt cheap. Yes VMware shipped with it about a decade ago in ESXi but that was dependent on host NIC support. OSX may ship with the driver support but I'm having trouble finding hardware specs to verify hardware support. I said "not super standard" and "customer grade" I didn't say it wasn't supported at all.

As to the specific subset; TCP Segmentation Offload. As was mentioned in the article.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#54

Post by peterwwillis »

LinuxBender wrote: post #25

This is the way I block such things on my own VM's (not at work) using iptables: iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 640:65535 -j DROP Here it is in action: iptables -L -n -v -t raw | grep mss 84719 3392K DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 tcpmss match !640:65535 My settings may be a little aggressive and may block some old pptp…

And ipv6? Fragmentation and mss are handled somewhat differently, iirc

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#55

Post by href »

usrname wrote: post #12

Some solution: echo 0 > /proc/sys/net/ipv4/tcp_sack https://github.com/Netflix/security-bulletins/blob/master/ad...

Thanks for pointing this out. Applying this buys us time before we can properly patch all our systems. In our case this was easy to roll out in a jiffy.

I do wonder though, can anyone guess what kind of impact one might see with TCP SACK disabled? We don't have large amounts of traffic and serve mostly websites. Maybe mobile phone traffic might be a bit worse off if the connection is bad?

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#56

Post by acdha »

syn0byte wrote: post #53
acdha wrote: post #42

Earlier quoted context omitted.

> TCP and Checksum offloading still aren't super standard on customer grade NICs or virtual machines. I thought VMware shipped that at least decade ago — is there some specific sub-feature you had in mind? Similarly, at least Apple's consumer hardware had checksum offloading back in the early 2000s and segmentation support shipped in 10.6 (2009) so it seems like it should be relatively mainstream since they tended to…

No doubt check summing support's been around for a while, ASIC Md5 is dirt cheap. Yes VMware shipped with it about a decade ago in ESXi but that was dependent on host NIC support. OSX may ship with the driver support but I'm having trouble finding hardware specs to verify hardware support. I said "not super standard" and " customer grade " I didn't say it wasn't supported at all. As to the specific subset; TCP Segmen…

> As was mentioned in the article.

Yes, I know. I was asking for clarification on the off chance that you were describing something which didn’t ship a decade ago. I first used TSO on servers in the early 2000s and by 2010 even the consumer-grade hardware I was seeing had it.

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#57

Post by pferde »

bauruine wrote: post #9
hoffie wrote: post #2

Red Hat's article on these issues also provides further explanations: https://access.redhat.com/security/vulnerabilities/tcpsack

There is also an ansible playbook on the resolve tab to easily apply the net.ipv4.tpc_sack workaround on all your hosts.

With a typo ("tpc_sack" instead of "tcp_sack") in the task name. The playbook still works, but I found it chuckle-worthy. :)

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#58

Post by LinuxBender »

peterwwillis wrote: post #54
LinuxBender wrote: post #25

This is the way I block such things on my own VM's (not at work) using iptables: iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 640:65535 -j DROP Here it is in action: iptables -L -n -v -t raw | grep mss 84719 3392K DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 tcpmss match !640:65535 My settings may be a little aggressive and may block some old pptp…

And ipv6? Fragmentation and mss are handled somewhat differently, iirc

Good point. I don't have a place to test ipv6. You would also have to create ip6tables rules to test that. If you have a test server on ipv6, please apply the rule and link it here. Well, test first, then link here. :-)

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#59

Post by geggam »

Is this the same thing ?

https://www.cvedetails.com/cve/CVE-2005-0960/

Multiple vulnerabilities in the SACK functionality in (1) tcp_input.c and (2) tcp_usrreq.c OpenBSD 3.5 and 3.6 allow remote attackers to cause a denial of service (memory exhaustion or system crash).

Re: SACK Panic – Multiple TCP-based remote denial-of-service issues

#60

Post by chupasaurus »

LinuxBender wrote: post #25

This is the way I block such things on my own VM's (not at work) using iptables: iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 640:65535 -j DROP Here it is in action: iptables -L -n -v -t raw | grep mss 84719 3392K DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 tcpmss match !640:65535 My settings may be a little aggressive and may block some old pptp…

FYI Debian Security Team recommends setting new sysctl value net.ipv4.tcp_min_snd_mss to 536, even though they (Debian) are preserving the default kernel value of 48 for compatibility.
Post reply on HN