Re: Nmap got a wrong result in windows 2003

[Jarett <zyrdyx () gmail com>]

Thank you for your hard job!your good professional ethic and professional
dedication impressed me,and I learned a lot.Chinese new year is coming,I
wish you and your team happy new year! (*^_^*)

2013/1/21 David Fifield <david () bamsoftware com>

> On Fri, Nov 30, 2012 at 01:29:39PM -0000, Rob Nicholls wrote:
> > I think David may have been confused into thinking two different people
> were
> > talking about the same bug, as the original emails you sent had the name
> > "rirong zhu", but your recent couple of emails now say "Jarett" (the
> email
> > address is the same for all of the emails).
> >
> > David, I think the subnets aren't being determined correctly when there's
> > more than one IP address assigned to an interface. I've just checked a
> > Windows 7 host that has two IP addresses running over the same interface
> (a
> > workaround on a test network due to a lack of spare physical interfaces,
> not
> > something I'd normally do) and instead of showing the correct subnet of
> /25
> > it's showing a subnet of /24 (which matches the subnet of the second IP
> > address assigned to the interface). It looks like the subnet is correctly
> > identified/shown in the ROUTES output (for me and Jarett), but is
> incorrect
> > under the INTERFACES output.
> >
> > If we were to assume that the subnet mask should be /28 for 115.236.23.45
> > instead of /29 I suspect it'll work as Nmap should know it can reach
> > 115.236.23.33 directly (instead of trying to route it through
> 115.236.23.45,
> > which is probably why we're seeing "localhost" issues).
> >
> > Jarett, as a workaround, it may be possible for Nmap to work if the
> second
> > IP (i.e. 124.160.125.118) is removed from the interface, assuming you're
> > able to do that.
>
> Thanks Rob, I think you're right.
>
> This code in libdnet-stripped/src/intf-win32.c is responsible:
>
>         /* Find the netmask length. This is stored in a parallel list.
>            We just take the first one with a matching address family,
>            but that may not be right. Windows Vista and later has an
>            OnLinkPrefixLength member that is stored right with the
>            unicast address. */
>         bits = 0;
>         for (prefix = a->FirstPrefix; prefix != NULL; prefix =
> prefix->Next) {
>                 if (prefix->Address.lpSockaddr->sa_family ==
> addr->Address.lpSockaddr->sa_family) {
>                         bits = (unsigned short) prefix->PrefixLength;
>                         break;
>                 }
>         }
>
> Unfortunately, I don't see an obvious solution to fixing this. The
> FirstPrefix list isn't guaranteed to come in any particular order, and
> the entries don't match up one-to-one with those of the
> FirstUnicastAddress list.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366058%28v=vs.85%29.aspx
> It looks as if one can go to heroic lengths to match prefixes to
> addresses, making some assumptions about the order and handling some
> special cases:
>
> https://code.google.com/p/openpgm/source/browse/trunk/openpgm/pgm/getifaddrs.c?r=1475#923
>
> An option is only to fix the problem for Vista and later, where
> IP_ADAPTER_UNICAST_ADDRESS has an OnLinkPrefixLength member.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366066%28v=vs.85%29.aspx
> It looks like even this has a bug with the prefix length of Teredo
> interfaces.
> http://stackoverflow.com/a/6579990
> http://openpgmdev.blogspot.nl/2011/07/cupcake-and-teredo.html
>
> David Fifield
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/