NMAP XP SP2 Patch Released!
Yep, that's right. The patch contains the fixes for the end of raw socket support in XP SP2. This is the only difference in this rev.
Here is the official word from Fyodor...
Nmap Hackers,
I have released Nmap 3.55-SP2, which works around most of the bone-headed raw sockets restrictions that Microsoft added to Windows XP Service Pack 2. Many thanks to Dana Epp (dana(a)vulscan.com) and Andy Lutomirski (luto(a)stanford.edu), who started working on the problem immediately, and had patches to me within 24 hours of my last nmap-hackers mail about the problem. I sent 3.55-SP2 to the dev list on the 13th to solicit feedback[1], and have not heard many problem reports. You can obtain the binaries from http://www.insecure.org/nmap/nmap_download.html#windows .
The only difference between this and vanilla 3.55 is Dana's short patch [2]. So there is no reason to upgrade unless you are using Nmap on Windows XP with SP2 installed (or if you are planning to install it). But remember that SP2 may arrive through the Windows Automatic Update system whether you want it or not. SP2 does offer many valuable, real security improvements in addition to IP stack crippling nonsense. Too bad they bundled it all together in one bloated, quarter-gigabyte patch.
[ If anti-MS ranting offends you, stop reading here. I have to get
some things off my chest :) ]
With SP2, Microsoft has crippled Windows in the following ways that affect Nmap: 1. TCP packets may no longer be sent through the raw sockets API 2. IP spoofed UDP packets may no longer be sent through raw sockets
(affects decoy and spoofed scanning).
3. Outbound TCP connection attempts are throttled to a slow rate.
I think MS should focus on hardening Windows defenses to keep attackers out (more timely patching, limiting services available by default, code auditing, privilege separation, etc.) rather than crippling the IP stack for legitimate users. Even if MS succeeds in preventing users from scanning their own Windows networks for vulnerabilities, attackers will rip right through them using superior systems such as Linux and *BSD that suffer from no such limitations.
More details (and spin) from the horse's mouth are available at [3]. This quote from that MS page sums up their attitude about breaking Nmap and many P2P apps:
Q: What works differently?
A: This change may cause certain security tools, such as port scanners,
to run more slowly.
Q: How do I resolve these issues?
A: Stop the application that is responsible for the failing connection
attempts.
If applications are broken by SP2, stop using them. Great solution, Microsoft! Fortunately for Nmap users, Microsoft implemented the new restrictions in their typical half-assed fashion. Instead of sending raw IP packets, we move one layer down and send our raw IP packets in raw ethernet frames. It took Microsoft years to develop SP2, but attackers can completely defeat the raw socket and (with a little more
work) connect() restrictions in minutes! One downside is that Windows Nmap now only works with Ethernet networks, while raw sockets were a cleaner, more portable solution. If this is a problem for you, talk to Microsoft! If enough people complain, they might actually listen to their customers and roll back the new restrictions. I am in communication with several Microsoft employees who are trying to convince the powers-that-be to fix raw sockets, but customer support for the change is critical. Mail me too, as we may be able to add support for other interface types if their is significant demand. Or write a patch and send it to me :).
I have not worried much about the connect() throttling at this point. The default SYN scan is usually preferable anyway. If you really want to use -sT on SP2, or if the restriction breaks your P2P or other apps, a patch to tcpip.sys is available at [4].
Cheers,
Fyodor
