Re: Problems with nmap with openvz or bridge interfaces

[David Fifield <david () bamsoftware com>]

On Sat, Jul 21, 2012 at 12:02:15PM +0100, Djalal Harouni wrote:
> My concern is that libdnet automatically flags this interface as an
> ethernet one which is not true, and later Nmap depends on this flag to
> send ethernet frames.
>
> IIRC when I took a look at how libdnet flags interfaces as ethernet ones I
> found it not perfect! if the BROADCAST flag is set then this is ethernet.
> see: libdnet-stripped/src/intf.c:_intf_set_type()
>
> Some Linux virtual interfaces will have the BROADCAST flag set.
>
> Now I'm not sure how Nmap and all the code path we have will deal with:
>  if ethernet_dev => send ethernet frames...

In previous version of Nmap (5.51), the venet0 interface just does not
appear in the --iflist output. In even earlier versions, there was a
fatal error, which was solved by this patch
http://seclists.org/nmap-dev/2009/q3/303. It changed in recent versions
because Nmap now always gets its interfaces through libdnet, whereas
previously it had its own special-case code for Linux. I'm fine if this
interface just doesn't appear at all.

> 1) libdnet will flag interfaces as ethernet based on the BROADCAST flag.
>    Fix: we should also check the address family and see if it's an
>    ethernet device. Every operating system have its own *special*
>    *expanded* address family numbers that are used to set the appropriate
>    type of these virtual devices.

Some interfaces should be devt_other rather than devt_ethernet, that's
true. There as a similar change for Solaris IPMP devices in r28558. I
don't like the idea of maintaining special expanded address family
numbers for each OS. I don't like the idea of creating a whole buggy new
interface table infrastructure.

> So I was thinking that the correct behaviour is to make libdnet check the
> address family and flag these interfaces as others, but I'm not sure
> about the downsides of using the 'devt_other' type, will Nmap/NSE...
> disable some scans that are perhaps supported by that device ?
> and how we deal with other systems, are address family numbers portable ?
>
> 2) Set the appropriate type as described in (1) and add another "supported
>    scans" tag to the "./nmap --iflist" output:
>
>    *******************Nmap Supported Scans*****************
>    DEV    (SHORT)       TYPE           Support
>    lo     lo            loopback       partial
>    eth0   eth0          ethernet       full
>    xxx    xxx           other          unknown (or partial?)

What's the idea behind this "partial" support column? I don't think it
will reduce bug reports. The only OS where we have such "partial"
support on an interface is Windows, and I think users will continue to
be dissatisfied that they can't do raw scans over their VPN interface.

> The current behaviour:
> 3) Let libdnet to flag all these interfaces as ethernet, perhaps users
>    will be able to run some scans that are supported by that special
>    device, this will not be the case if libdnet flags them as others.
>    
>    But what about: users are trying to send ethernet frames on a non
>    ethernet device.
>    Perhaps with this nmap-dev will receive more bug reports and the
>    output of "./nmap --iflist" will not help to determine the cause since
>    all these special interfaces are marked as 'ethernet'.

We are not getting many of this type of bug report, so I don't think
that is a justification for any big change. Is there another reason?

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