Re: ncat broadcast support?

[Daniel Miller <bonsaiviking () gmail com>]

Ok, so I'm down to (I think) three possible ways to do this, with 
challenges in each:

1. Support a --broadcast flag to enable SO_BROADCAST on all sockets
    Pro: Don't have to figure out what a broadcast address is (~netmask 
| addr or 255.255.255.255)
    Con: the flag would be in the ncat code, but the actual socket 
calls are in the nsock code, so it would mean changing the Nsock API 
(probably) to pass the request.
2. enable SO_BROADCAST on nsock_connect calls to broadcast addresses
    Pro: contained entirely in nsock_connect.c, very similar to what I 
already wrote
    Con: Finding out what a broadcast address is could be tricky
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.

Anyone more familiar with the code who would be willing to help choose a 
method for this?

Dan

On 05/12/2010 09:38 AM, Daniel Miller wrote:
> Well, since my patch applies to the Nsock library instead of just 
> Ncat, it probably does affect other things. I figured that checking if 
> the connection is to INADDR_BROADCAST would prevent most 
> complications. I'm pretty sure we wouldn't want SO_BROADCAST on every 
> socket, since it (I think) affects the way the socket receives 
> responses from the network. Again, any tips for what interactions to 
> check for or a test suite to run would be great.
>
> Dan
>
> On 05/12/2010 09:21 AM, Ron wrote:
> > Hey Daniel,
> >
> > Do you know if this can potentially affect anything else in the application? In other words, is there any reason that we 
> > *wouldn't* want SO_BROADCAST on every connection?
> >
> > If there is, you might want to add a commandline argument --broadcast that sets SO_BROADCAST rather than setting it in every 
> > case. But, if there's no side effect, then setting it in every case is probably ok (not that it's my call to make :) ).
> >
> > Ron
> >
> > On Wed, 12 May 2010 09:16:50 -0500 Daniel Miller
> > <bonsaiviking () gmail com>  wrote:
> >    
> > > Thanks for the tip, Ron! Here's what I came up with, which works for
> > > me for this particular application.
> > >
> > > --- nmap.orig/nsock/src/nsock_connect.c    2010-05-12
> > > 09:09:20.663173832 -0500
> > > +++ nmap/nsock/src/nsock_connect.c    2010-05-11 16:32:33.347640392
> > > -0500 @@ -120,6 +120,14 @@ void nsock_connect_internal(mspool *ms,
> > >          }
> > >        }
> > >
> > > +    if (sin->sin_addr.s_addr == INADDR_BROADCAST) {
> > > +      int rval;
> > > +      if (setsockopt(iod->sd, SOL_SOCKET, SO_BROADCAST, (void*)
> > > &rval, sizeof(int)) == -1) {
> > > +        if (ms->tracelevel>  0)
> > > +          nsock_trace(ms, "Setting of SO_BROADCAST failed (IOD #%li)
> > > EID %li", iod->id, nse->id);
> > > +      }
> > > +    }
> > > +
> > >        if (connect(iod->sd, (struct sockaddr *) ss, sslen) == -1) {
> > >          int err = socket_errno();
> > >
> > >
> > > I'd like to make it part of the official distribution, but I know I'm
> > > missing some critical pieces:
> > >
> > > 1. I don't think this supports IPv6
> > > 2. It will probably do the same thing for TCP, which may break or not
> > > work as expected
> > > 3. I don't have a good test suite to make sure I didn't break anything
> > > 4. I only tested on Ubuntu 10.04 with g++ 4.4.3
> > >
> > > Any hints as to what my next step would be?
> > >
> > > Thanks,
> > > Dan
> > >
> > > On 05/11/2010 03:31 PM, Ron wrote:
> > >      
> > > > I believe what you need to do is find out where it calls Socket()
> > > > and add a call to Setsockopt() with SO_BROADCAST set to 1.
> > > >
> > > > Search udp.c in my nbtool codebase for 'SO_BROADCAST':
> > > > http://svn.skullsecurity.org:81/ron/security/nbtool/udp.c
> > > >
> > > > To see an example.
> > > >
> > > > Hope that helps!
> > > >
> > > > On Tue, 11 May 2010 15:00:22 -0500 Daniel Miller
> > > > <bonsaiviking () gmail com>   wrote:
> > > >
> > > >        
> > > > > I would like to use ncat in UDP mode to send broadcast datagrams,
> > > > > but I get "permission denied" errors, even running as root. I
> > > > > understand that there are differences in how to call the
> > > > > underlying system calls when connecting to broadcast, and I'm
> > > > > willing to attempt a patch, but I don't know where to start. Could
> > > > > someone give me a quick pointer to the files I'd have to change to
> > > > > get this to work?
> > > > >
> > > > > doesnotwork# ncat -vvvvv --udp 192.168.1.255 161
> > > > > Ncat: Version 5.30BETA1 (http://nmap.org/ncat  )
> > > > > NSOCK (0.0010s) UDP connection requested to 255.255.255.255:161
> > > > > (IOD
> > > > > #1) EID 8
> > > > > NSOCK (0.0010s) Callback: CONNECT ERROR [Permission denied (13)]
> > > > > for EID 8 [255.255.255.255:161]
> > > > > Ncat: Permission denied.
> > > > >
> > > > > Thanks for any assistance (or "No, that's a bad idea," as the case
> > > > > may be)
> > > > >
> > > > > Dan
> > > > > _______________________________________________
> > > > > Sent through the nmap-dev mailing list
> > > > > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > > > > Archived athttp://seclists.org/nmap-dev/
> > > > >
> > > > >          
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Sent through the nmap-dev mailing list
> > > > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > > > Archived athttp://seclists.org/nmap-dev/
> > > >        
> > > _______________________________________________
> > > Sent through the nmap-dev mailing list
> > > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > > Archived athttp://seclists.org/nmap-dev/
> > >      
> >    
> >
> >
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived athttp://seclists.org/nmap-dev/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/