Will any Android phones be affected, or they don't support segment offloading?
SACK Panic – Multiple TCP-based remote denial-of-service issues
101–110 of 134 posts
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#102Earlier quoted context omitted.
Though not as bad as Win9x it definitely had some frag-of-death/ping-of-death vulns around 1997/98. teardrop et al.
Here's a golden oldie from 1996: https://packetstormsecurity.com/files/15507/CA-96.26.ping.ht... My favorite of that era was simply the working-as-designed simplicity of sneaking the Hayes modem hangup sequence into various protocols: actual Hayes modems used +++ with a time-delay to send commands such as ATH0 (hangup) but everyone else skipped that time-delay in an attempt to avoid the patent so you could disconnect…
IRC was a fun venue for that one ~25 years ago.
Pop into some random channel, send "/ctcp #channel ping +++ATH0", and wait patiently... a moment or two later you would be rewarded with a flood of "signoff" messages as the users' TCP sessions to the IRC server timed out (by responding to the CTCP, they had, in effect, told their modems to hang up).
The goal, of course, was to get the highest "body count" possible from a single CTCP message.
Smurf attacks, the "ping of death", AOHell, the latest sendmail and wu-ftpd holes of the week, open proxies... the Internet was a very entertaining place for a bored teenager from the midwest back then.
Thanks for the flashback!
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#103Earlier quoted context omitted.
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. :)
Thanks for the report, getting our team to fix that.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#104Earlier quoted context omitted.
Yes. In all seriousness, this is a "drop everything and patch" situation, as soon as the patches are available. It's a little bit more involved than a ping of death, but still, relatively easy to exploit.
Seems like anybody with an open TCP port and SACK enabled (the default) is vulnerable.
and Generic Segment offloading.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#105I guess this post beat mine? https://news.ycombinator.com/item?id=20205859
Nope, it's just the random dupe that ended up getting the upvotes for whatever reasons. This happens constantly and the one that gets the upvotes has more to do with chance than any other factor.
s/chance/timing/. Social media scoring can be fickle indeed, but there are entire industries devoted to optimizing and reverse-engineering the hotness algos of various traffic-drivers. This case is probably coincidental, but it's naive to ascribe high scoring merely to luck. It looks SEJeff posted around 12pm PDT, maybe on his way out to lunch. This post was two hours later, as everyone got back from lunch. :)
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#106Earlier quoted context omitted.
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…
So far on 3 VMs where I've checked (all are public facing, on is fairly high traffic MX, the other is a webhost), netstat -s informed me that SACK is barely used.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#107This 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.
It's worth noting that lwIP, the network stack used by most microcontroller based IoT devices, has a very low MSS. It's configurable, but typically defaults to 512.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#108Sorry, this is probably a bit simplistic, but I am curious: How likely is this to affect embedded devices? E.g., hardware firewalls, routers, IoT devices that all use a Linux kernel?
They are equally as affected. Linux is Linux, it makes no difference in what box it runs. What is usually a mitigating factor is that embedded devices usually have a very different configuration compared to non-embedded devices (built with minimal options, not a lot of services running on them etc.).
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#109Earlier quoted context omitted.
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…
I was involved with this one for another cloud provider. I have a personal Digital Ocean (not my employer) instance that is frequently being probed for stuff (primarily Russian and Chinese IPs). Same old, same old. I've been running with the rule for around a week just logging & dropping small MSS packets out of curiosity, but hardly seen anything worth writing home about. I was somewhat surprised. I'm curious to see…
Small MSS is often IoT devices which only have a kilobyte or so of RAM, so often have an MSS of below 256 bytes. They won't be rendering a webpage, but are totally capable of doing REST API requests.
More and more are moving away from $0.25 microcontrollers, and up to $5 SoC's running Linux, so the problem is going away gradually...
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#110This 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…
In the event anyone needs this, you can also override outbound mss in case someone is telling your client to use a low mss. This goes in the mangle table. DO NOT use this example unless you know for sure what you are doing. iptables -t mangle -I POSTROUTING -o eth0 -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m tcpmss --mss 1:100 -j TCPMSS --set-mss 1360 This example should work for most use cases, but don't do this un…
I read in a note just below --set-mss in man iptables-extensions that iptables will not increase mss if it's already lower than what set in --set-mss.