Re: [PATCH] Nmap bug determining IP address from network interface name

[David Fifield <david () bamsoftware com>]

On Tue, Jul 07, 2009 at 02:37:41PM +0200, Luis M. wrote:
> Yesterday, Fyodor and I discovered a bug in Nping. For some strange reason
> network interface names were being "resolved" to IP 2.0.0.0.
>
> I've looked into it and discovered that the bug also affects nmap
> because I've tracked it down to function devname2ipaddr().
>
> So now let's see the problem. This is the code for devname2ipaddr():
>
> int devname2ipaddr(char *dev, struct in_addr *addr) {
> struct interface_info *mydevs;
> int numdevs;
> int i;
> mydevs = getinterfaces(&numdevs);
>
> if (!mydevs) return -1;
>
> for(i=0; i < numdevs; i++) {
>   if (!strcmp(dev, mydevs[i].devfullname)) {  
>     memcpy(addr, (char *) &mydevs[i].addr, sizeof(struct in_addr));
>     return 0;
>   }
> }
> return -1;
> }
>
> So devname2ipaddr() obtains a list of network interfaces and then tries to
> find the one whose name maches param "dev". Well, the problem here is that
> in the returned "struct interface_info", member "addr" is of type   
> "struct sockaddr_storage", and therefore, the conversion to "struct in_addr"
> cannot be done just saying "hey, let's copy &mydevs[i].addr into a
> "struct in_addr", because sockaddr_storage contains, at least, a member
> named sa_family before the actual address information. So, to sum up,
> we are copying data from the wrong memory address (on my Linux box, 4
> bytes earlier than we should).
>
> Of course, AF_INET is normally defined as "#define AF_INET 2", and
> that's why we are getting IP 2.0.0.0.

Nice job debugging. I tested the patch in Nmap and it works fine. I can
see in a debugger that the proper address is being set.

While you're at it, you should add a check to skip any interfaces where
the address family is not AF_INET. Currently the getinterfaces function
already skips those, but this way it won't break if that changes in the
future.

David Fifield

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