Slashdot Mirror
Microsoft, Cisco Finally Patch TCP DoS Flaw
Trailrunner7 writes "Today vendors are finally releasing patches for the TCP vulnerabilities first publicized nearly a year ago that affect a huge range of networking products, including any device running a version of Cisco's IOS software, and a number of Microsoft server and desktop operating systems. Both Microsoft and Cisco released fixes for the vulnerabilities today. The Microsoft Patch Tuesday release included the fix for the TCP flaw, which affects Windows Server 2003 and 2008, as well as Windows Vista, both the 32-bit and 64-bit editions, and Windows 2000 SP4, for which no fix is coming. The TCP flaws were identified several years ago and were made public last year by two researchers at Outpost24, Jack C. Louis and Robert E. Lee. Louis, who has since died, developed a tool called Sockstress that tested for the flaw and was able to maintain extremely long-term TCP connections with remote machines using very little bandwidth."
I mean, Robert E. Lee has been dead for *decades*.
-- the opinions stated above aren't those of my employer. in fact, they're probably not even my own. you know what, ju
Just think of all the meetings that had to be convened, coffee brewed, dinners expensed discussing the potential impact of these flaws, input from the legal department on the cost of fixing the bug versus potential liability including agreement to the shrinkwrap license that absolves MS of any liability unless a judge someday says otherwise, reading the tea leaves, God the list goes on and on.
I'm proud of them for releasing this fix in such a timely fashion.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
It just takes way too long for its developers to security patch.
I was afraid they weren't going to patch these kinds of flaws in Vista to push Windows 7. ...
What do you mean some people still prefer XP over Vista? ...
What do you mean XP isn't being patched?
and straightforward reason why these companies dont issue these patches sooner. "we dont have the resources" or "it just isnt hurting our bottom line yet" would be awesome to hear. i mean, if google can come out and do it then it says alot about the old guard if they cant.
Good people go to bed earlier.
Obviously at the time IOS was designed, everyone would write their own special-purpose operating system for embedded devices. These days, wouldn't it make more sense to just scrap it and switch to Linux? Lots of other manufacturers are doing it (Linksys, Netgear, D-Link, etc.). This would certainly prevent this kind of embarassment.
___
If you think big enough, you'll never have to do it.
This is something the press would be screaming end of the Internet if they got their hands on it.
What's the reality? Is this easy to exploit and is the Internet going to come crashing down?
http://www.microsoft.com/technet/security/bulletin/ms09-048.mspx mentioned no updates for Windows 2000 SP4 because it requires a major change in operating system (OS). If no fixes, then what will stop it? Hardware routers and/or software firewalls for those who still use it?
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Kill all humans!
-- I have a private email server in my basement.
In Microsofts case i read the bulletin as it allows remote code execution in w2k8 and Vista. Thats very unpleasant considering it happens in the TCP/IP level and not higher up. Im no hacker but from what i can understand this exploit allows a hacker to own ANY affected system directly over the internet as long as any port on that target is accessible. I really hope im reading this wrong.
A firewall wont help at all in that case and critical is a very moderate rating indeed. Im very glad we havent upgraded to w2k8 yet.
HTTP/1.1 400
Today was a joint release date. That is to say: Everyone agreed that nobody would release their fix(es) until everyone was ready.
This was done to ensure that an attacker did not reverse engineer one company's fix, and use the flaw to wreck havoc on another company's products.
And "Everyone" in this case includes more vendors than just Microsoft & Cisco. The firm I work for released our fix(es) for this issue today.
Instead of someone disclosing a security problem one month before the vendor's next scheduled patch date, wouldn't you prefer that a major remote flaw affecting hundreds of companys' products be hidden until most of them were ready to be patched?
Obviously at the time IOS was designed, everyone would write their own special-purpose operating system for embedded devices. These days, wouldn't it make more sense to just scrap it and switch to Linux? Lots of other manufacturers are doing it (Linksys, Netgear, D-Link, etc.). This would certainly prevent this kind of embarassment.
Juniper and Force10 use a BSD base. (As do Isilon and NetApp.)
Cisco is thought to be moving to FreeBSD as well:
http://it.toolbox.com/blogs/bsd-guru/freebsd-at-cisco-21312
All the world is not Linux.
so when can we expect a windows 2003 patch to come? anyone know the date?
I'd STRONGLY wager that the reason WHY Windows 2000 doesn't have a "fix", or an easy fix rather, is because if you look @ its LSP (Layered Service Provider List) in the registry?
The one listed for "TCP/IP" is RDR20.DLL in Windows 2000, & it's NOT THAT for Windows XP/Windows Server 2003 etc. et al (all of Win2k's descendants)... it is MSWSOCK.DLL for the later editions.
APK
P.S.=> Just a guess, but, I'd wager that has a "little something to do with it" - & that's where the problem lies (or, @ least, partially so)... apk
Let's not. They're entertaining.
"Windows 2000 is dead. This is a trick Microsoft does to force you to upgrade to their newer, crappier, versions of Windows. I wouldn't mind upgrading to XP too much, since the only really evil thing in it is activation, but XP isn't available. I'd have to upgrade to Vista or 7, which are both very evil. Instead, I will use OpenBSD" - by Anonymous Coward on Tuesday September 08, @07:17PM (#29359171)
Windows Server 2003 is the BEST Windows going, imo @ least: Much of the best of VISTA (since it IS the codebase for it, but, without the downsides, like:
1.) DRM (This one's KILLING MS imo... folks like their copied films/tunes etc. et al, & when you stop providing what folks like? They LEAVE... or, don't buy into it!)
2.) WGA (afaik, this ISN'T in it, but here? I might be "off/wrong" though - correct me if so guys, thanks)
3.) HOSTS files being unable to use 0 anymore as a blocking IP address for bad hostnames/domains (& instead now, you have to use the larger/slower 0.0.0.0 or 127.0.0.1)
4.) WFP single part defense alongside NDIS6, in VISTA onwards, which the folks @ rootkit.com are even saying is easier to "unhook & bypass" vs. the older 3 part/3 driver/3 diff. layer "greek phalanx"/"Zone Defense" pre-VISTA Windows used
5.) OpenGL ICD (this isn't SO bad, because you can get a driver from your vidcard maker that has one... but, it's bad enough, tearing out a 3d Graphical display std. that has "stood the test of time" & is easy enough to code around too, but it IS a "crippling/removal of a good feature" in an OS... &, imo @ least, only done imo to "snuff out" OpenGL in favor of DirectX 10)
(Those are some of the things that "bug me" about VISTA onwards... there are probably more, but that will do for now & that's all that "springs to mind" here on short-notice)
AND, Windows Server 2003 installs, by default, in a "WorkStation/Pro" mode, rather than full-blown server (if you need those components, e.g.-> IIS etc.? You add them, as needed, only... but, they do NOT install by default) - it's really nice!
It's MY personal "Favorite model" of Windows to date, in fact... it's the BEST of Windows XP, & Windows 2000 in the GUI as well!
(Just some "food 4 thought" for your consideration is all!)
APK
P.S.=> Just something to keep in mind... & I *THINK* why Microsoft isn't updating Windows 2000 on this, is for the very reasons you noted: To "snuff it out", so folks buy into "WGA" policed models of Windows really (from a business "POV", it does make sense though, even if I do NOT agree with it myself personally as you do not) & the fact that the Layered Service Provider (LSP) lib/dll used in Windows 2000 is RDR20.DLL, instead of the newer one used in Windows XP/Server 2003/VISTA/Server 2008/Windows 7, of MSWSOCK.DLL... that might not be ALL of it, but I wager, it is a large part of why this is going on! apk
See subject-line, & this quote from the pages @ MS on how to "mitigate" this type of attack (easily done really):
http://www.microsoft.com/technet/security/Bulletin/MS09-048.mspx
"To help protect from network-based attempts to exploit this vulnerability, enable advanced TCP/IP filtering on systems that support this feature"
I cover how to do that (& really, EVERYONE should on Windows 2000/XP/Server 2003, because it acts as another "layer" of defense, for "layered security" above & beyond std. firewalling, because it uses ipfltdrv.sys, which acts PERFECTLY FINE alongside all other defenses)
I cover a LOT of this here, & IP FILTERING'S VERY EASY TO SETUP (you may want to refer to the IANA ports list though, for YOUR particular needs, it does help):
-----
HOW TO SECURE Windows 2000/XP/Server 2003 & even VISTA, plus, make it "Fun-to-Do", via CIS Tool Guidance (& beyond):
http://www.tcmagazine.com/forums/index.php?s=33555fc937017deab726a927c1c4a7fd&showtopic=2662
(You MAY want to look @ points #3 - #5 there, they cover IP Filtering, IPSec, & more... specifically in regards to this, & protecting yourself vs. it, on Windows 2000... it SHOULD work, according to MS, & it is JUST GOOD "LAYERED SECURITY" anyhow!)
-----
Now, the IP FILTERING (ipfltdrv.sys) works PERFECTLY FINE alongside ipnat.sys (firewall driver), & ipsec.sys (IP Security Policies) too... all of them, alongside TCP FILTERING, work fine "all @ once"/"concurrently"... + of course, alongside tcpip.sys, the base IP driver)
The 3 other drivers work @ DIFFERENT LAYERS of the IP stack around tcpip.sys, making them function PRETTY MUCH like a "Zone Defense"/"Greek Phalanx", so if you take 1 down? The others are STILL IN THE WAY... it's neat - too bad MS did away with that w/ VISTA onwards now using the single layer (& thus, single "lock" only) WFP + NDIS6, which even the folks @ ROOTKIT.COM are stating is "much easier to unhook & bypass" vs. the older model whose architecture I just laid out...))
APK
P.S.=> Enjoy, that OUGHT to help you Windows 2000 folks out there, vs. this "bug"... do I think MS could fix it? Sure, but it'd "hurt business"... replace RDR20.DLL with MSWSOCK.DLL (for LSP/Layered Service Providers), the latter being what XP/Server 2003/VISTA onwards use, & it could be fixed imo... but, "that's business" for you! apk
Glad to see they hopped right on that!
And I should love proprietary software... WHY?
Oh yeah, because the competition pressures provide much more pressure to fix these kinds of things. NOT!
And what exactly did the theoretical vulnerability do to us? I certainly never had my machine slowed down, attacked, whatever by someone trying to exploit this. Perhaps they didn't bother to fix it for this long since it was no big deal anyway?
"M$". I see what you did there. That was very clever. And original, too.
Per the above subject-line: THIS IS SOMEWHAT IMPORTANT - It depends on how you use your system & THAT is why I noted the use of the IANA ports list in my last post (see the part where I note IANA & "your particular needs" above). I wrote this "addendum", because I feel I had best "specify" what those "particular needs" might be for users that try this:
Yes - The use of PORT FILTERING MIGHT be a caveat for those running servers (webservers port 80, ftp servers ports 21-22 typically, mail servers on ports 25/110, etc. et al - because in those cases, you'd be harming them possibly. That is because they have to solicit connections on said ports & on THEIR server systems (or workstations acting as servers)) Same again also, for those who use fileshares (for internal home networks, OR, those in corporate environs) which are driven on the LanMan/NetBIOS networking in Windows (via Client for Microsoft Networks + Windows File & Printer sharing & Server service etc., which use ports 139 & 445 iirc)
HOWEVER- Otherwise, if you are a "stand-alone" single machine user (connected to the internet especially)? This can, & does, actually work.
APK
P.S.=> What "upsets me" (well, not really, but... you know what I mean) the most about it though, is that MS should and most likely, COULD fix it!
Again - I suspect the problem is in (@ least in part) the RDR20.DLL lib/dll used in Windows 2000 (for LSP/Layered Service Provider for TCP/IP), vs. MSWSOCK.DLL lib/dll used in Windows XP/Server 2003 etc. et al (post Windows 2000 versions of Windows NT-based OS by MS)
(I say that much above now, because offhand, it is the ONLY part of the IP stack I could see that was "radically different" in that it uses a diff. named library/DLL than the others)
Plus - MS "backports" features from VISTA & Windows Server 2003 to XP for instance, like TcpChimney, quite a lot... why not THIS time? Some "Food 4 Thought", on that account... apk
For servers? PORT FILTERING, despite what MS says, may not work (see my 2 posts above/prior to this one again for details), again, especially depending on what the server is up to, because it has to open ports to work & accept connections on them... port filtering could block them, & thus, limit connections to said servers, period.
A possible alternate solution (or, set of them)? Look to IPSecurity Policies!
(I.E.-> That's where you can specifically LIMIT what comes in & out of your system, with finer 'granularity', in that you can stop IPAddresses or iirc, even hostnames, from talking to YOUR SERVER... it offers more 'fine grained control', than you can get using PORT FILTERING, but it is harder to work with, but my guide above in my 1st post covers that too)...
(AND, if this "malware" does any "talk back" to the "mothership" (a command & control server)? You can stall that via IPSecurity Policies too)
OR YOU COULD EVEN ADD THOSE "command & control servers" a malware may use, to a HOSTS file to block them (using 0, 0.0.0.0, or 127.0.0.1 in front of their hostnames, assuming they use those, & they usually do - because using a hardcoded IP is foolish for a botmaster really, because they get 'taken down" fast usually by the ISP or hosting provider for them... they instead tend to rely on domain names/hostnames because they can be quickly re-registered @ another ISP or hosting provider & use the SAME hostname/domainname)
OR, lastly?
Windows 2000 users can even look to your routing tables (route command, or hardware routers) to block the bad guys' command servers + slaved zombies out as well..
APK
P.S.=> I still think MS can, & SHOULD, patch this... via the replacement of Windows 2000's LSP (layered service provider) RDR20.DLL, since it is the ONLY PORTION OF THE IP STACK I COULD DETERMINE A "RADICAL DIFFERENCE" in, vs. Windows Server 2003, Windows XP, Windows VISTA, Windows Server 2008, or Windows 7 - as they use MSWSOCK.DLL as the LSP for TCP/IP, & that's PROBABLY WHERE THE "PROBLEM" LIES, in backporting this patch to Windows 2000!
Funny part is, MS 'backports' features from VISTA to Windows Server 2003 &/or Windows XP, such as "TcpChimney", & has NO PROBLEM doing so, & again, I suspect because of the diff. in the LSP lib used... apk
SYN flood protection is activated, vs. DOS/DDOS attacks, when you use this (& this attack vulnerability causes Denial of Service):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value name: SynAttackProtect
Key: Tcpip\Parameters
Value Type: REG_DWORD
Valid Range: 0,1,2
Default: 0
This registry value causes Transmission Control Protocol (TCP) to adjust retransmission of SYN-ACKS. When you configure this value, the connection responses time out more quickly in the event of a SYN attack (a type of denial of service attack).
2: Set SynAttackProtect to 2 for the best protection against SYN attacks. This value adds additional delays to connection indications, and TCP connection requests quickly timeout when a SYN attack is in progress. This parameter is the recommended setting.
NOTE: The following socket options no longer work on any socket when you set the SynAttackProtect value to 2: Scalable windows
TCP parameters that are configured on each adapter (including Initial RTT and window size)
For the TcpWindowSize & GlobalTcpWindowSize, I'd adjust them as well (large ones).
APK
P.S.=> I was asked on how I'd attempt to protect a mailserver that has to accept incoming connections from ALL OVER THE WORLD, & how I'd protect it vs. a DOS/DDOS of this nature... there is your answer (otherwise, I'd use IPSecurity Policies to tell my system to REJECT communications from a single DOS attacker (vs. a DDOS type attack, which can be from MANY systems worldwide)... best idea I can come up with, for those that use Windows 2000 servers.
This is easy to protect against using PORT FILTERING for a single Windows 2000 system, but not so easy, for servers... apk
ALSO - Wouldn't using Tcp1323Opts = 0 & SynAttackProtect = 2 work to stop "silly window syndrome" & 'scaling/sliding windows' in TCP/IP per RFC1323 "High-Performance TCP/IP features" it implements?
Think about this, & comment please:
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 [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!
----
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 [microsoft.com]
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, here -> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters STOPS TCP WINDOWS SCALING - This also turns off the RFC 1323 "Hi-Performance TCP/IP" options like "Scalable Windows" (sliding Windows noted in "silly window syndrome") also, & though you may go slower, 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 thing I am not certain of, is does this disallow SMALLER windows being negotiated, such as the setsockopt 0 uses in this type of DOS/DDOS attack. This I need feedback on, thanks.
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 (which seems to exploit "scaling windows"/"sliding windows" per "Silly Window Syndrome", which this seems to exploit) should, in theory, be utterly nullified.
APK
P.S.=> I can't think of anything better than this 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