Re: [RFC] Nsock connect error handling

[David Fifield <david () bamsoftware com>]

On Thu, Mar 16, 2017 at 10:37:51PM -0500, Daniel Miller wrote:
> I was just looking at a bug report [1] that showed that an ICMP Type 12
> (Parameter Problem) packet could cause Nsock to throw a fatal error. Timed just
> right, this could crash Nmap during version scan. The fix is simple: add EPROTO
> to the long list of known error codes in handle_connect_result [2]. But is that
> the best option?
>
> As far as I can tell, there is no reason for Nsock to be checking for specific
> error codes. The action is always the same: return a Nsock error and set the
> error code appropriately. The only non-error condition is explicitly handled:
> connect() returns 0, and Nsock returns success. Why can't we make the default
> case handle any error code possible?

I think you're right on both counts. You can fix the bug by adding
EPROTO to the list of known errors. And, the default error case could be
made to handle any error generically.
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/