Re: Service scan on link-local IPv6 address without -e option causes Nmap to crash

["Mathias Morbitzer" <m.morbitzer () runbox com>]

Yes, i can confirm that the crash doesn't happen anymore. Good work, thanks for helping me out here!

However, the service scan still doesn't work, because Nsock doesn't know which interface to use. But the portscan 
works, and I think this creates a quite confusing situation. I would suggest we fix this in one of those two ways: 

+  We also don't perform the portscan, directly quitting with the error message that no interface was specified but a 
link-local address should be scanned
+ We let Nsock use the interface that was also used for the portscan (where I did not yet understand how this interface 
is chosen) 

Since basically all other tools won't do anything if no interface is specified together with a link-local address, my 
suggestion would be to do the same and quit directly. 

Also yes, the fe80::1%eth0 solution seems to be a good idea - or specifying an interface with -e. Maybe we could allow 
any of them, I think that would be the best. 

If others agree with me on that, I will try to provide a patch.  

Mathias

On Fri, 4 Mar 2016 17:05:24 -0600, Daniel Miller <bonsaiviking () gmail com> wrote:

> Mathias,
>
> I can confirm the crash. I fixed the crash in r35658, but I think we need a
> comprehensive evaluation of how we handle IPv6 addresses and scopes.
> Probably allowing fe80::1%eth0 type of thing would be best.
>
> Dan
>
> On Wed, Mar 2, 2016 at 10:09 AM, Mathias Morbitzer <m.morbitzer () runbox com>
> wrote:
>
> > Hello everyone,
> >
> > I've been executing an Nmap scan with the following commandline:
> >
> > sudo ./nmap -6 fe80::20c:29ff:feb9:7b9d -sV -p 111 -dd
> >
> > When reaching the service scan, Nmap crashes with the following output:
> >
> > [..]
> > Initiating Service scan at 03:20
> > Scanning 2 services on fe80::20c:29ff:feb9:7b9d
> > NSOCK INFO [1.8880s] nsock_iod_new2(): nsock_iod_new (IOD #1)
> > Starting probes against new service: fe80::20c:29ff:feb9:7b9d:22 (tcp)
> > NSOCK INFO [1.8880s] nsock_connect_tcp(): TCP connection requested to
> > fe80::20c:29ff:feb9:7b9d:22 (IOD #1) EID 8
> > NSOCK INFO [1.8880s] nsock_trace_handler_callback(): Callback: CONNECT
> > ERROR [Invalid argument (22)] for EID 8 [fe80::20c:29ff:feb9:7b9d:22]
> > Got nsock CONNECT response with status ERROR - aborting this service
> > NSOCK INFO [1.8880s] nsock_iod_delete(): nsock_iod_delete (IOD #1)
> > NSOCK INFO [1.8880s] nsock_iod_new2(): nsock_iod_new (IOD #2)
> > Starting probes against new service: fe80::20c:29ff:feb9:7b9d:111 (tcp)
> > NSOCK INFO [1.8880s] nsock_connect_tcp(): TCP connection requested to
> > fe80::20c:29ff:feb9:7b9d:111 (IOD #2) EID 16
> > NSOCK INFO [1.8880s] nsock_trace_handler_callback(): Callback: CONNECT
> > ERROR [Invalid argument (22)] for EID 16 [fe80::20c:29ff:feb9:7b9d:111]
> > Got nsock CONNECT response with status ERROR - aborting this service
> > NSOCK INFO [1.8880s] nsock_iod_delete(): nsock_iod_delete (IOD #2)
> > *** Error in `nmap': double free or corruption (out): 0x0000000003885060
> > ***
> >
> > I found the problem in the nsock_connect_internal() function in
> > nsock/src/nsock_connect.c . When a link-local IPv6 address is used without
> > stating with -e which interface to use, sin6->sin6_scope_id is not
> > initialized, causing the connect() function to return with error code 22.
> >
> > I wanted to provide a patch, but I actually don't know in which way to fix
> > this. When trying to scan a link-local address without stating an
> > interface, most other tools just quit and require the specification of an
> > interface. However, Nmap is also able to do the portscan without having an
> > interface implicitly specified, so why shouldn't it also be able to perform
> > the service scan?
> >
> > Being able to do the service scan without stating the interface would
> > require sin6->sin6_scope_id to either be set in nsock_connect_internal(),
> > or even before. However, I'm having troubles to figure out where the best
> > place to add this code would be, and how I would be able to access
> > information about the interface Nmap has used for the port scan. Maybe
> > somebody with more experience in the code base could point me in the right
> > direction?
> >
> > Further, I think that even if nsock_connect_internal() is not able to
> > establish a connection, Nmap still shouldn't crash. However, I was not yet
> > able to figure where memory is freed twice in case something goes wrong...
> >
> > Regards,
> > Mathias
> > _______________________________________________
> > Sent through the dev mailing list
> > https://nmap.org/mailman/listinfo/dev
> > Archived at http://seclists.org/nmap-dev/


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