Microsoft, Cisco issue patches for newfangled DoS exploit
Relief for industry-wide TCP attack
Agentless Backup is Not a Myth
Updated 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 and Robert E. Lee of Sweden-based Outpost24. It gave many security watchers pause because it provided attackers with a new way to launch potentially crippling attacks on a wide array of equipment used to route traffic over the internet.
"This is definitely momentum and other vendors, once they fully understand what has been talked about here, will come up with mitigation strategies of their own," Lee told The Register. "This really is good progress from both Microsoft and Cisco."
On Tuesday, Microsoft responded with MS09-048, a security advisory that fixes a variety of networking vulnerabilities in Windows operating systems, including those discovered by Louis and Lee. The update implements a new feature called memory pressure protection, which automatically drops existing TCP connections and SYN requests when attacks are detected.
The update from Microsoft came during the company's Patch Tuesday, in which it fixed a total of eight security vulnerabilities in various versions of its Windows operating system. In all, Microsoft issued five patches, which change the way Windows processes javascript, MP3 audio files and wireless signals. As always, the Sans Institute provides a helpful overview here.
Cisco issued it's own bulletin warning that multiple products are vulnerable to DoS, or denial-of-service attacks that can be especially disruptive.
"By manipulating the state of TCP connections, an attacker could force a system that is under attack to maintain TCP connections for long periods of time, or indefinitely in some cases," the bulletin stated. "With a sufficient number of open TCP connections, the attacker may be able to cause a system to consume internal buffer and memory resources, resulting in new TCP connections being denied access to a targeted port or an entire system."
Several other companies issued their own advisories concerning the vulnerability, according to this advisory from the Computer Emergency Response Team in Finland. Security firm Check Point Software said it was updating several security gateway products. Linux distributor Red Hat, meanwhile, stopped short of issuing a fix, but offered this workaround.
The industry wide advisories are designed to address a design flaw in a core internet protocol. Louis and Lee discovered it in 2005 and kept it secret last year. The researchers have provided few public details about how to exploit the bug to prevent it from being targeted in real-world attacks. Now that fixes are being released, he plans to write several blog posts in the coming weeks that for the first time will publicly reveal how attacks are carried out.
The vulnerability is unusual in that it causes a server or router to stop working with relatively modest amounts of malformed traffic. What's more, the disruption lasts even after the malicious assault has ended. In many cases, the only way to repair a disabled device is to restart it, a remedy that's not suitable in most data centers.
Not all industry players agree on the severity of the flaw. Researchers from router maker Juniper Networks said they "found no unexpected or adverse impact to our equipment which is different from other types of TCP Denial of Service." VMware and Clavister said none of their products are vulnerable, either.
Lee cautioned that many companies are wrong when they claim their products are unaffected by the new class of DoS vulnerabilities. In particular, he said Juniper's insistence that its products aren't vulnerable "means the guys at Juniper didn't get it." He went on to say: "I'm reasonably certain they're absolutely vulnerable."
Barry Greene, director of Juniper's security incident response team, took exception to that claim. He said his security team tested Juniper's entire product portfolio using Outpost24's own security tools and found no evidence any of it was vulnerable to the types of attacks described by Louis and Lee.
"The expectation is that when you're under attack, your system should recover when you remove the attack," Greene said. "Your system shouldn't crash when you're under attack. Our expectation is that we recover as we do from any other DoS attack of this type." ®
This article was updated to include comment from Juniper.
COMMENTS
@AC above me, the "True Troll"? Take a read
1.) This DOS/DDOS attack utilizes an API call with a 0 window size parameter -> setsockopt 0
----
2.) TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems - which is what this attack sounds as if it is exploiting:
KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP) -> Tcp Scaling
http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm
PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."
Which, per the setsockopt 0 call & parameter?
Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!
----
3.) SynAttackProtect, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING, per this MS article on it:
http://msdn.microsoft.com/en-us/library/aa302363.aspx
PERTINENT QUOTE -> "NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows"
-----
4.) Tcp1323Opts - This also turns off the RFC 1323 "Hi-Performance TCP/IP" options like "Scalable Windows" (sliding Windows noted in "silly window syndrome") also, because, you would be safer on a Windows 2000 machine because of it no longer allowing the TcpWindowSize to be reset by this attack (that uses that to its advantage via setsockopt 0) - the ONLY QUESTION I HAVE HERE is, does this guarantee that "SET WINDOWS SIZE" (a buffer of requests Windows fills first, & then satisfies, in other words?).
http://www.speedguide.net/read_articles.php?id=157
Tcp1323Opts is a necessary setting in order to enable Large TCP Window support as described in RFC 1323. Without this parameter, the TCP Window is limited to 64K.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Tcp1323Opts="1" (DWORD, recommended setting is 1. The possible settings are 0 - Disable RFC 1323 options, 1 - Window scaling but no Timestamp options, 3 - Window scaling and Time stamp options.)
Like SynAttackProtect = 2?
Tcp1323Opts = 0 "turns off" the ability to use "scalable windows" that RFC1323 allows, & which it appears that this setsockopt 0 command exploits, via the "Silly Window Syndrome"...
----
Thus, if you have a 'hardcoded' TcpWindowSize in the registry, & one set to a PRE-DEFINED value/size, & "sliding window sizes" for TCP are 'turned off' by SynAttackProtect = 2 and Tcp1323Opts = 0?
The ability to use setsockopt 0 should, in theory, be utterly nullified.
APK
P.S.=> BOTTOM-LINE, is this: I am looking to others to comment on my thoughts here & find any errors in the suppositions I am making (just by deductive reasoning in what these TCP parameters can do):
Right now?
Well - I can't think of anything better than this, FOR WINDOWS 2000 SERVERS, but the evidence above tends to show that IF you use SynAttackProtect = 2 (which works vs. types of DOS/DDOS attacks, as is) and Tcp1323Opts = 0 which STALLS "SLIDING WINDOW SIZES" (Tcp Scaling in other words), then, this attack which seems to use the "Silly Window Syndrome" per the above cannot work...
(As it cannot reset TcpWindowSize & the system will NOT use TcpScaling/Sliding Windows anymore to "renegotiate" a new TcpWindow Size... & thus, setsockopt 0 shouldn't work to send your system into a 'tailspin" DOS/DDOS... even if it is a server!)
If this doesn't work, then, nothing really can (for servers, but MS says PORT FILTERING works for it, on workstations, Yes, I can agree on that much, but not on servers that solicit & accept connections)...apk
Ah, I get it now
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.
@AC: Read these articles on "Silly Window Syndrome", TcpWindowSize, & SynAttackProtect, ok?
"It mitigates TCP connections in a SYN-RECV state" - By Anonymous Coward Posted Tuesday 15th September 2009 12:31 GMT
So what? You do a netstat -n -b TCP and see what's "hanging" in a RCVD/RECV state, & block it out via IP Security Policies then & that can be done in ranges as well... which netstat with those parameters (netstat -b -n WILL show you).
I still would think this much, though, ontop of that, so read on:
"Please please stop, read about the attack, and understand how it works before commenting further." - By Anonymous Coward Posted Tuesday 15th September 2009 12:31 GMT
Why don't you do the same, & read this much:
http://msdn.microsoft.com/en-us/library/aa302363.aspx
Description: When SynAttackProtect is enabled, this value specifies the threshold of TCP connections in the SYN_RCVD state. When SynAttackProtect is exceeded, SYN flood protection is triggered.
KEYWORD = SYN_RCVD
AND
"The above registry key does not mitigate the attack described in the article" - By Anonymous Coward Posted Tuesday 15th September 2009 12:31 GMT
TCP "Silly Window Syndrome" and Changes To the Sliding Window System For Avoiding Small-Window Problems:
KEYWORD = SLIDING WINDOW SYSTEM (for TCP/IP)
http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow-4.htm [tcpipguide.com]
PERTINENT CONCEPT QUOTE -> "Key Concept: Modern TCP implementations incorporate a set of SWS avoidance algorithms. When receiving, devices are programmed not to advertise very small windows, waiting instead until there is enough room in the buffer for one of a reasonable size. Transmitters use Nagles algorithm to ensure that small segments are not generated when there are unacknowledged bytes outstanding."
Which, per the setsockopt 0 call & parameter? Does sound a LOT like this problem is, via setsockopt 0 calls issued by an attacking malware to exploit this for DDOS/DOS attacks!
----
Again - please, read the above, and take YOUR OWN ADVICE:
Reading the above article(s) especially & its KEY POINT/CONCEPTS, quoted from both above... & about how setsockopt 0 is used in attacks of this nature, on this vulnerability in Windows 2000.
APK
P.S.=> I.E.-> By setting a non-scaling TcpWindowSize, that should be enough to stall out the setsockopt 0 calls an attacking DDOS/DOS program would use, to set a SMALL Window size, & that is even for server-class systems!
That, alongsize using SynAttackProtect, which STOPS TCP WINDOW SCALING (vs. this "silly window syndrome" style attack - because it sounds like it IS using that much, via setsockopt 0) should help also, especially vs. DOS/DDOS attacks... apk
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Agentless Backup is Not a Myth
