Linux PCs, Servers, Gadgets Can Be Crashed by 'Ping of Death' Network Packets (theregister.co.uk) 132
Artem S. Tashkinov writes: The Register reports that it is possible to crash network-facing Linux servers, PCs, smartphones and tablets, and gadgets, or slow down their network connections, by sending them a series of maliciously crafted packets. It is also possible to hamper FreeBSD machines with the same attack. Patches and mitigations are available, and can be applied by hand if needed, or you can wait for a security fix to be pushed or offered to your at-risk device. A key workaround is to set /proc/sys/net/ipv4/tcp_sack to 0. At the heart of the drama is a programming flaw dubbed SACK Panic aka CVE-2019-11477: this bug can be exploited to remotely crash systems powered by Linux kernel version 2.6.29 or higher, which was released 10 years ago.
Puffy? (Score:1)
Re: (Score:1)
* Delete stale (i.e, cumulatively ack'd) holes. Hole is deleted only if
* it is completely acked; otherwise, tcp_sack_option(), called from
* tcp_dooptions(), will fix up the hole.
*/
void
tcp_del_sackholes(struct tcpcb *tp, struct tcphdr *th)
{
if (tp->sack_enable && tp->t_state != TCPS_LISTEN) {
tcp_seq lastack = SEQ_GT(th-
Re: (Score:2)
while (...)
if (...) {
} else
break;
Ew! Pass the eye bleach! Did a Python programmer write that?
Re: (Score:2)
Not Python. Too many "unnecessary" brackets and semi colons. And wavy bracktes {} aren't used that way in Python. And the -> operator seems to be a recent and quite obscure addition to the language that most folks don't know about. https://stackoverflow.com/ques... [stackoverflow.com]
Maybe pretty printed C or C++? Haven't looked at either for decades
Re: (Score:2)
Yep. Using indentation in C to indicate code blocks instead of { } is high on the list of things programmers should be fired for.
Re: (Score:2, Informative)
No sure about OpenBSD, but the vulnerability on FreeBSD is present only if using the "Rack TCP stack", which is an optional TCP stack contributed by Netflix and is not active by default.
So stock FreeBSD is not vulnerable, nor are the other BSDs, unless this feature has been activated. The article is misleading in this.
I'm also confident the patches will be incorporated soon in the official tree.
Re: (Score:2)
It speeds it up
I and using OpenBSD
Re: (Score:3)
Re: (Score:2)
How critical is that? (Score:2)
Re: (Score:2)
Re: (Score:1)
Once it's a CVE, consider it automatically added into exploit engines. (Which means malicious hands could be using it.)
Re: (Score:2)
Re: (Score:2)
except many firewalls and load balancers run linux variants
F5 BIG-IP and PAN-OS for example get many linux vulnerabilities
Re: Hmmm (Score:1)
Nah. The windows ones are way harder to mitigate.
Re: (Score:3)
Well to be fair the Windows version (AKA Winnuke) was fixed in like 1996.
Brings me back to nuking (and being nuked) way back when with Kali and Warcraft 2. Ahh... such fun when you're punkass teenager. Of course nowadays it would be considered 'hacking' and likely a felony offense.
(Though still far less harmful than SWATting, which is apparently what it's escalated to)
Re: (Score:2)
Kali (at least the one i was referring to) was an IPX emulator allowing you to play LAN games over the internet.
Re: (Score:2)
The fix can be found (Score:4, Funny)
Here
Re: (Score:1)
Thanks! I just installed it and now everything is wor
Re:The fix can be found (Score:5, Funny)
you forgot the *NO CARRIER* ;-)
kids these days
Re: (Score:2)
Didn't you forget something about a lawn?
Netflix (Score:5, Informative)
Actual source information. It was discovered, reported, and fixed by Netflix engineering team. https://github.com/Netflix/sec... [github.com]
mitigation (Score:1)
From TFA: echo 1 > /proc/sys/net/ipv4/tcp_sack
Anyone know the implications of this?
Re:mitigation (Score:5, Informative)
https://tools.ietf.org/html/rf... [ietf.org]
Basically, SACK (Selective ACKnowledgements) is a way to reduce the harm of bad packet loss, by more efficiently requesting retransmission. For good connections, disabling SACK will have no effect. For lossy connections, disabling SACK will result in an even worse experience.
Re: (Score:2)
Yeah, that was a mistype. Thanks for the kindly correction :)
Re: (Score:3)
yeah, just updated our Linux kernel (Score:2)
Open source fast fixes! (Score:2)
Quick fix (correct me if I'm wrong) (Score:1)
net.ipv4.tcp_sack=0
Unpossible. (Score:4, Funny)
Linux is perfect. Only Windows has an imperfect network stack so only Windows should be affected right?
1998 called (Score:2)
pf's reassemble tcp (Score:1)
Will pf's "scrub on $wan all reassemble tcp" catch this and take care of it, or does the problem happen on a lower level?
Re: (Score:2, Informative)
Except these aren't actually ICMP. They called them "pings" instead of "packets" for some reason. This is not that, this is a SACK = specific ack. They fly under your non-applicable ruleset.
Re: (Score:2)
Ping of Death [wikipedia.org]
So the idea is you build up a ping packet in a series of IP fragments that end up being larger than the largest allowable IP frame. Boom, instant death of the host stack - bringing down pretty much any server on the internet circa 1997.
Re: (Score:1)
Re: (Score:1)
Its not an ICMP vulnerability so blocking that wont help. Very deceptive heading. Its a TCP problem.
Re: (Score:3, Informative)
Pings are ICMP messages. It should also be possible to block these using iptables, which would mitigate the problem. iptables -A INPUT -p icmp -j DENY
Whether it's humorous or not, for everyone else at least:
Many ICMP packets are important/necessary. And you would need to call ip6tables too, to block icmpv6 packets (but ICMP packets are even more important important/necessary for IPv6).
More importantly still, selective ACKs are implemented through TCP packet options, not ICMP packets. The use of the expression "ping of death", is metaphoric here.
So just run `sysctl -w net.ipv4.tcp_sack=0`, and either run it some way early after each boot, or add "net.ipv4
Re: (Score:1)
This and other methods of turning off ICMP ought to work, which is what you ought to be doing anyway. You can turn off ICMP in router software, too, so that pings never arrive. It's only nominally inconvenient.
Re: (Score:2)
My bad. TCP SACK, e.g. RFC 2018.
Re: (Score:2, Informative)
Haven't you heard about MTU discovery?
You need to read up on how IP actually works before you make comments like that
Re: (Score:1)
That's the filename.
Do this:
echo 0 > /proc/sys/net/ipv4/tcp_sack
Re: (Score:1)
It works if you run it as root. As in # prompt, not $ prompt.
This will work if you use sudo:
sudo sh -c "echo '0' > /proc/sys/net/ipv4/tcp_sack"
Calling people don't understand Linux, when it is you how doesn't understand Linux! How's the idiot now?!
Re: (Score:2)
You know, if you don't know the answer to your "question", you clearly are not a Linux server admin, so it doesn't matter to you, really. Any real admin already knows what this means, and where to find distro-specific instructions for mitigation. IOW, fuck right off, troll.
Re: (Score:2)
Hey, dumbass -
sudo sysctl -w net.ipv4.tcp_sack=0
takes immediate effect.
Re: (Score:1)
I'm just going to leave this here...
http://shouldiblockicmp.com/
Re:Really? (Score:5, Informative)
Blocking icmp entirely is a bogus response and breaks things - in particular, path mtu discovery depends on the ICMP fragmentation needed packet. Servers and networks that block ICMP will find themselves inaccessible to many users.
Re: (Score:2)
"Please explain."
Here's a link that discusses the issue at some length. http://donaldkenney.x10.mx/BLA... [x10.mx]
"I never had a client complain his server wasn't reachable because ICMP was blocked."
That would likely be because diagnosing the problem is quite difficult. Also, the problems -- which depend on message size -- are likely to show up with services other than http. In one case I encountered personally, a rural school was trying to use services provided by the mothership -- the District sever located 10
Re: (Score:2, Interesting)
Re:Really? (Score:5, Informative)
Should block this nonsense. Who allows ICMP anymore? Who allows -anything- other than ssh? Not me. Unless it's a webserver, but even my webserver quietly drops anything that isn't expected (like ICMP)
SACK is a TCP extension. Absolutely nothing to do with ICMP.
Dropping ICMP prevents PMTUD from functioning which is required to assure proper operation of IP.
Golden rule of internet facing machines: Drop anything you're not expecting to receive. It's the only way to be sure.
Golden rule of Internet: Most of what you hear online is total bullshit.
Re: (Score:3)
IP functions just fine with no path MTU discovery.
Only when there is no constrained link between peers. Otherwise what happens the second either peer pushes more than any hop can handle the connection appears to hang or run really slow. Some stacks have heuristics to prevent total session loss but its not usable.
Of course DF bit must not be set in that case.
If you are relying on per route fragmentation you are in for a world of disappointment.
IPv6 does not even support per hop fragmentation. It's not even an option that could be implemented.
IPv4 is not much better. Major TCP stacks set DF automat
Re: (Score:3)
"Dropping ICMP prevents PMTUD from functioning which is required to assure proper operation of IP."
Absolutely! Not handling ICMP results in potential "Blackhole Routing" issues for any traffic relayed through the site by the Internet. Blackhole Routing means the site and any sites beyond it become a black hole that can, and probably will, simply eat some packets intended for other sites. Notification to the sender that the packet is never going to arrive? Nope.
Debugging Blackhole routing issues can be v
Re: (Score:3)
Re: (Score:2)
"Should block this nonsense. Who allows ICMP anymore? Who allows -anything- other than ssh? Not me. Unless it's a webserver, but even my webserver quietly drops anything that isn't expected (like ICMP)"
It's your network and you can run it any way you wish. It says so in the Magna Carta and probably the Bhagavad Gita as well.
But I suspect that if you fully understood the potential implications of messing with RFC1191 Path MTU Discovery, you'd very likely turn ICMP back on.