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)
