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

61–70 of 134 posts

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

#61

Post by pferde »

ones_and_zeros wrote: post #27
talawahtech wrote: post #14

AWS Bulletin: https://aws.amazon.com/security/security-bulletins/AWS-2019-... FYI if your instances are behind an Application Load Balancer or Classic Load Balancer then they are protected, but NOT if they are behind a Network Load Balancer. A patched kernel is available for Amazon Linux 1 and 2, so you won't have to disable SACK. You can run "sudo yum update kernel" to get it, but of course you have to reboot. Updat…

Even if your instances are behind ALBs or ELBs they may not be protected if they make outbound connections to the internet.

Is this so? Can this kernel panic also be triggered in TCP connections initiated by the victim? I can't find a conclusive mention of this anywhere.

As each direction of a TCP connection has its own MSS, it would make sense that an attacker's server could exploit this.

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

#63

Post by dsp »

syn0byte wrote: post #32
jkern wrote: post #5

So you can remotely cause a kernel panic on basically any system with kernel newer than 2.6.28? The doesn't sound great

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…

Disabling tso alone would not be enough. You also need to disable gso if you go that route.

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

#64

Post by dsp »

pferde wrote: post #61
ones_and_zeros wrote: post #27

Earlier quoted context omitted.

Even if your instances are behind ALBs or ELBs they may not be protected if they make outbound connections to the internet.

Is this so? Can this kernel panic also be triggered in TCP connections initiated by the victim? I can't find a conclusive mention of this anywhere. As each direction of a TCP connection has its own MSS, it would make sense that an attacker's server could exploit this.

This is so. Both passive and active connections are at risk.

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

#65

Post by wademealing »

href wrote: post #55
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?

Disclaimer: I worked on initial Red Hat article linked above.

In my personal AWS instance from the last few days less than half a percent of the traffic had hit the firewall rule to log the error.

Most of that traffic seemed to come from the China, this was possibly port probing / portscans or really old hardware accessing my the server.

I would say that the iptables rule is a 'better' solution than dropping sack as you may find you use significantly more CPU/bandwidth when dealing with retransmits when not using selective acknowledgements.

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

#66

Post by wademealing »

geggam wrote: post #59

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).

Similar concept, different operating system.

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

#67

Post by rphlx »

keyle wrote: post #62

What does OpenBSD/NetBSD do differently to not be affected by this?

They use a different TCP/IP stack which implemented SACK without introducing this bug.

It's a Linux-specific implementation defect, not an intrinsic problem with the TCP SACK wire protocol or spec.

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

#70

Post by rphlx »

foofc7c8 wrote: post #69
rphlx wrote: post #68

When was the last time Linux had a similar, reliably-remotely-exploitable kernel panic in the TCP/IPv4 stack? Pre-2000?

Never, from what I can recall.

Though not as bad as Win9x it definitely had some frag-of-death/ping-of-death vulns around 1997/98. teardrop et al.
Post reply on HN