Re: IPv6 OS fingerprinting crashes on Ubuntu/Debian with UFW enabled

[Fyodor <fyodor () nmap org>]

On Sat, Aug 2, 2014 at 9:04 PM, Daniel Miller <bonsaiviking () gmail com>
wrote:

> Hi, List,
>
> This took me a while to track down. The crash:

Good find!


> So what can be done (besides requiring users to modify their firewall
> rules)? I see a few options:
>
> 1. Handle the error more gracefully. Perhaps we skip this probe, just like
> we skip some probes when we can't find an open or a closed TCP port. It
> will result in less-accurate fingerprints, but will probably still have
> lots to work with (e.g. all the TCP probes).

Is Nmap itself actually crashing/quitting?  If so, then I think we should
at least handle this more gracefully.  Printing a useful warning message is
fine, and probably desirable to help us track this issue.  I guess
continuing with OS detection without that probe seems reasonable, though in
that case we should probably mark the fingerprints as not good so we don't
ask the user to submit them.

2. Modify the probe. This may invalidate (or at least skew) our existing
> fingerprints database, though. We could use a non-0 routing type (0, 1, and
> 2 are valid, all others must be ignored, provided the Segments Left is 0,
> according to the RFC, but I'd be willing to bet some implementation will
> respond with ICMP errors instead). Or we could drop this header, since it's
> probably not the source of differentiating responses (the duplicate
> hop-by-hop header is what makes IE2 "special"). This header is also
> probably causing packets to be filtered at other network points like ISP
> gateways, so we may get better results after modifying it.

Well this whole probe is pretty sketchy, since the goal is to see what
error messages systems decide to use.  I suppose this is a case where it
would be good to get some empirical statistics on how removing this
extension header affects the number of responses we get (and ideally
whether it changes the responses in a material way).

So I'm not sure the best way to handle this, but Nmap should certainly not
quit.

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