81–90 of 134 posts
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
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...
Earlier 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.
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 any modem-connected system if you could figure out how to get it to echo "+++ATH0". Some IP stacks (e.g. Windows 95) would simply send the received ICMP payload as the response so a simple `ping -p …` would do it but people found ways to cause similar problems with sendmail, FTP, etc.
https://dl.packetstormsecurity.net/new-exploits/modem-DoS.tx...
Earlier quoted context omitted.
[ "$(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.
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…
??
here [1] gives example of ... is your just inverting/negating the DROP rule ?
>iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP
[1] https://github.com/Netflix/security-bulletins/blob/master/ad...
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…
How would you do that for the INPUT table (not a VM)? Just: > iptables -t raw -I INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss ! --mss 640:65535 -j DROP ?? here [1] gives example of ... is your just inverting/negating the DROP rule ? >iptables -A INPUT -p tcp -m tcpmss --mss 1:500 -j DROP [1] https://github.com/Netflix/security-bulletins/blob/master/ad...
So for the raw table, it would be
iptables -t raw -I PREROUTING -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss --mss 1:500 -j DROP
iptables -t filter -I INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m tcpmss --mss 1:500 -j DROP
The reason I use the opposite method is that we not the normal range we want. Programs can also set super high values or not set mss at all (which is not the same as 0).
I explicitly set the interface, so that we don't match interfaces such as lo, tun, tap, vhost, veth, etc... because you never know what weird behavior some program depends on. In my example, eth0 is directly on the internet. In your systems, that might be bond0.
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.
net.ipv4.route.min_adv_mss = 256
net.ipv4.tcp_base_mss = 512
net.ipv6.route.min_adv_mss = 1220Earlier quoted context omitted.
The fix was pushed just now to stable kernels.
That's just a detail of how linux is developed. The fixing patch was mailed on May 17th and it mentions the CVE.
Earlier 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…
YOUR_RULE -m limit --limit 2/sec -j LOG --log-prefix="MALFORMED_MSS: " --log-ip-options --log-tcp-options --log-level 7