Nmap Development mailing list archives
Re: ncat broadcast support?
From: Fyodor <fyodor () insecure org>
Date: Wed, 12 May 2010 15:53:37 -0700
On Wed, May 12, 2010 at 01:50:29PM -0500, Daniel Miller wrote:
3. enable SO_BROADCAST on all nsock_connect_udp calls Pro: Easy! Con: Could mess up other features of Nsock. Specifically, I'm worried that recv() calls would pick up replies FROM and possibly TO broadcast addresses, which I'm pretty sure would cause issues with UDP port scans.
It is very good to have these concerns about possible side effects, but enabling SO_BROADCAST in all cases may actually be OK. Nmap has a broadcast_socket() function which does this, and calls to that are spread liberally throughout the code. Yet I don't recall SO_BROADCAST ever causing any problems. The setsockopt(3p) man page on my Linux system says: SO_BROADCAST Permits sending of broadcast messages, if this is supported by the protocol. This option takes an int value. This is a Boolean option. It may be that the only thing SO_BROADCAST does is disable the check which returns EPERM if there is an attempt to send to a broadcast address without setting this. But I haven't verified in the Linux source code whether anything else is done. So my suspicion is that we can set it in all cases for Nmap, but I hope anyone who can think of a problem with that will speak up! So if we add this, the next question is whether to set the flag in ncat whenever it gets a new socket from nsock, or to set it in nsock itself. Remember that changes to Nsock affect Nmap, Nping, and Ncrack as well as Ncat. An alternative would be that Ncat could use nsi_getsd to get new socket descriptors and then set the broadcast flag itself. My initial thought is that maybe we should have a function like nsp_setbroadcast() which specifies whether, from that point on, all newly created sockets should have SO_BROADCAST set. I suppose it should probably default to false, just like in the socket API. But I imagine that Ncat, Nping, and Nmap may want to enable this. Ncrack, on the other hand, may not. The change would have to tested on Windows and UNIX. If you really can't get access to a Windows system, you may be able to recruit testers on this list. So I'd encourage you to write a patch, and I definitely encourage other folks to chime in if they know stuff about SO_BROADCAST that we don't, or if they have any other implementation ideas or concerns. Cheers, -F _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- ncat broadcast support? Daniel Miller (May 11)
- Re: ncat broadcast support? Ron (May 11)
- Re: ncat broadcast support? Daniel Miller (May 12)
- Re: ncat broadcast support? Ron (May 12)
- Re: ncat broadcast support? Daniel Miller (May 12)
- Re: ncat broadcast support? Daniel Miller (May 12)
- Re: ncat broadcast support? Fyodor (May 12)
- Re: ncat broadcast support? Daniel Miller (May 13)
- Re: ncat broadcast support? Daniel Miller (May 13)
- Re: ncat broadcast support? Norris Carden (May 14)
- Re: ncat broadcast support? Daniel Miller (May 14)
- Re: ncat broadcast support? Luis MartinGarcia (May 14)
- Re: ncat broadcast support? David Fifield (May 18)
- Re: ncat broadcast support? David Fifield (May 18)
- Re: ncat broadcast support? David Fifield (May 20)
- Re: ncat broadcast support? Daniel Miller (May 12)
- Re: ncat broadcast support? Ron (May 11)