Sorry, 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?
SACK Panic – Multiple TCP-based remote denial-of-service issues
71–80 of 134 posts
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#72What 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.
They found a bug in FreeBSD too: https://github.com/Netflix/security-bulletins/blob/master/ad...
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#73Earlier quoted context omitted.
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.
Ah, yeah. Takes me back to my college years. I was a sophomore at the time and was running Win2k server release candidates. Had a new freshman brag about having WinME, which was on the 9x kernel. Went back to my room in the dorms amd alternately sent a ping of death. Ping of death would crash him, but a ping flood was a DoS. His computer would hang trying to handle all of the traffic. Rendered the network unusable on my end while I was doing it, but the PC was otherwise fine (i.e. I could play offline games). Proved my point, he was humbled and stopped bragging and I left him alone after my little demonstration.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#74Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#75I 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.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#76Earlier quoted context omitted.
I am finding that HN has limited formatting options - if I don't indent by two spaces (aka code mode) it's a run-on mess, which then requires a large amount of ugly line breaks making the post 5x as large and unreadable. HN formatting instructions are all of 3 sentences long. https://news.ycombinator.com/formatdoc
I agree that formatting could definitely do with some work! If you put each link on a line and then leave a newline between each one you should get a nice list though.
Nope, a single newline would just be translated to a space character without a paragraph break. There's no way to
in HN.
in HN.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#77Earlier quoted context omitted.
Thanks for this. Any chance you can you edit the comment to make the links clicky please?
I am finding that HN has limited formatting options - if I don't indent by two spaces (aka code mode) it's a run-on mess, which then requires a large amount of ugly line breaks making the post 5x as large and unreadable. HN formatting instructions are all of 3 sentences long. https://news.ycombinator.com/formatdoc
Normally code mode is entirely unusable for text on mobile phones, as it prevents wrapping beyond the phone truncation point at somewhere around 20-40 characters. Good idea using it for a list of headings and links here.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#78Is there any way to quickly test if any of my machines are vulnerable?
[ "$(uname -s)" = Linux ] && echo "Vulnerable" ("CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values (all Linux versions)", "CVE-2019-11478: SACK Slowness (Linux https://github.com/Netflix/security-bulletins/blob/master/ad...
I know you're being glib, but are 2.6.x kernels vulnerable? The big corps tend define all linux as all linux that they support and isn't end of life. As far as I read early 3.x kernels on the Ubuntu side are not effected. Like version 12 and before.
So there's plenty of linux being used out there that's probably not effected.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#79Earlier quoted context omitted.
That seems to have a bit more information, so we switched to it from https://www.openwall.com/lists/oss-security/2019/06/17/5 . Thanks!
https://github.com/Netflix/security-bulletins/blob/master/ad... is the advisory by the party that discovered the issue. (Disclosure: I have met Jonathan Looney and know some of the Netflix engineering staff, but I don't work for Netflix.)
This mentions FreeBSD impacts as well which the RedHat link doesn't.
Re: SACK Panic – Multiple TCP-based remote denial-of-service issues
#80Earlier 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…
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 how long it takes for that rule to go nuts (my shellshock rule still triggers from time to time, that had a definite curve of action)