Microsoft, Cisco issue patches for newfangled DoS exploit Microsoft and Cisco have issued updates that protect against a new class of attack that requires very little bandwidth and can leave servers and routers paralyzed even after a flood of malicious data has stopped. The bug in the TCP, or transmission control protocol, was disclosed in October by security researchers Jack Louis …
I'm not so sure. I hate to speculate ahead of the "how it works" revelations, but it sounds like the vulnerability is inherent in the TCP standard.
If that proves to be the case, then Red Hat may well be doing the right thing by continuing to abide by the letter of the standard in the product and informing their customers how to configure bending the rules to eliminate the vulnerability if they so wish.
I'm going to cling to this theory for comfort as it leaves everything in the world in its usual places, Red Hat doing their best given the conflicting drivers and M$ just going with b0rking the standard as per usual.
This is the third TCP vulnerability that's crossed my desk in as many weeks. I haven't looked closely at the details or the vulnerability but I strongly suspect that this is just another of the ones for which a properly configured firewall can stop the attacker in their tracks and, importantly, you get to identify the attacker so you can send the boys round.
I think Red Hat are doing the right thing here.
Microsoft's KB article on this vulnerability says that they're not fixing this issue for Win2K..... yeah, I know it's an old OS, but some of us still use it and it is still supported by Microsoft.
"The architecture to properly support TCP/IP protection does not exist on Microsoft Windows 2000 systems, making it infeasible to build the fix for Microsoft Windows 2000 Service Pack 4 to eliminate the vulnerability. To do so would require rearchitecting a very significant amount of the Microsoft Windows 2000 Service Pack 4 operating system, not just the affected component. The product of such a rearchitecture effort would be sufficiently incompatible with Microsoft Windows 2000 Service Pack 4 that there would be no assurance that applications designed to run on Microsoft Windows 2000 Service Pack 4 would continue to operate on the updated system."
The full writeup on the vulnerability has just been posted on BUGTRAQ and off the top of my head most Unixes will not be vulnerable to it because they do not disable TCP timers in a TCP zero-window state after the app has closed the socket.
The control portion of Juniper software stack is FreeBSD derived from the days of version 3.x so it should not be vulnerable. If I correctly remember the source (cannot be bothered to look at it right now) it still has the timer running in that case so it will kill the connection.
Neither should be Linux because the fixes for the various old FIN resource exhaustion vulnerabilities should deal with this. On top of that Linux actually has a few recent "special" fixes to deal with zero-window and broken window scaling attacks which should catch that as well.
"I strongly suspect that this is just another of the ones for which a properly configured firewall can stop the attacker in their tracks"
You're wrong. Checkpoint and CIsco (among others) make firewalls, and have released or are to release patches for this vuln, which affects them. Don't just guess at whether you're vulnerable or not, find out.
You've completely misunderstood this vulnerability. If you have a 2k server which listens for connections on port 445 or 139 for shares, or it hosts a webserver on port 80 or 443, or it's a mailserver on port 25, you can't filter those ports, because they need to be open. So you're vulnerable to this issue.
See subject-line above and answer please
Why do you KEEP CAPITALISING things "which" don't require it or "put things" within quotation marks when quoting "doesn't help" convey any extra meaning?
Basically you're saying don't allow any TCP connections to the box, and you're laughing. That's fine as far as it goes, but unrealistic. Almost all networked servers require you to make TCP connections to them, so those network servers are vulnerable to this, and your mitigation advice is useless.
Incidentally, microsoft didn't misunderstand the vulnerability, they suggested that as a mitigation because they basically don't have one, and when that happens they suggest stupid things so that people who don't pay attention think there's a workaround. There isn't.
Ok, walk us through how to use "IPSecurity Policies" to protect a mail server from this vulnerability. Bear in mind it needs to accept SMTP email from anywhere on the internet. No? Ok, thanks for playing.
The point you consistently miss is that if you allow any TCP connection to the box AT ALL the vulnerability can be exploited.
The IANA Port list is irrelevant because the port number you allow is utterly irrelevant. If you don't get that then you've missed how the exploit works.
There are very few situations where configuring a server not to accept any TCP connections is a useful server configuration.
So basically you're suggesting a complicated way to "mitigate" attacks on a standalone workstation which does no sharing on a home network. Which would be more easily achieved by putting it behind a nat device, such as a router. Like everyone uses to get to the internet.
Also, this is a DoS attack. It's not "malware" "talking back" to a "mothership" (a ... mothership?)
Try to pay attention.
The above registry key does not mitigate the attack described in the article.
It mitigates TCP connections in a SYN-RECV state. That is not how this DoS attack works.
Please please stop, read about the attack, and understand how it works before commenting further.
Finally I twig. Troll.
It was the way you went from a registry key which helps protect against SYN-Floods to an entirely unrelated discussion of modern TCP stacks protecting against silly window syndrome, as if they were in some way related concepts, and as if they were somehow relevant to the Dos attack described in the article.
I'll cheerfully stop now. Enjoy the view from the bridge.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
