Re: Nsock SSL problem (r29134 explanations)

[Daniel Miller <bonsaiviking () gmail com>]

On 07/06/2012 08:51 AM, Henri Doreau wrote:
> Hello,
>
> yesterday I fixed a bug in nsock, which was kind of flying under the
> radar: only Daniel Miller reported it[1], and I personally never
> managed to reproduce this stalled scan symptom he saw despite days of
> debug. Still, this problem probably affects many users, in a way or
> another. I sent a quick description to the list yesterday[2] after
> committing r29134 but here are the details again:
>
>
> * Problem
>
> Internal reconnection attempts can occur under certain conditions
> described below:
> nsock_core.c
> """
> 465   /* SSLv3-only and TLSv1-only servers can't be connected to when the
> 466    * SSL_OP_NO_SSLv2 option is not set, which is the case when the pool
> 467    * was initialized with nsp_ssl_init_max_speed. Try reconnecting with
> 468    * SSL_OP_NO_SSLv2. Never downgrade a NO_SSLv2 connection to one that
> 469    * might use SSLv2. */
> [...]
> 472   close(iod->sd);
> 473   nsock_connect_internal(ms, nse, [...]);
> """
>
> The problem was that the close() statement removes the FD from the
> epoll set, and that the new one (from nsock_connect_internal) wasn't
> added instead. Nsock therefore lost track of the events associated to
> this IOD.
>
>
> * Fix
> I committed a first fix to make epoll_iod_modify() calls epoll_ctl() a
> second time, with EPOLL_CTL_ADD, in case the modification attempt
> failed with ENOENT (r29134).
>
>
> I would propose to replace this fix by the patch attached, which is
> much nicer IMO, and has the advantage of not being engine-specific.
> This new patch simply unregisters the IOD before the close() and
> nsock_connect_internal() statements and registers the IOD again (with
> the new FD) afterwards.
>
> I have also added a couple statements to engine_select.c to make it
> clean all FD sets on IOD unregistration. For some reason, the X set
> wasn't touched. Unless I miss something this was a mistake.
>
>
> Regards.
>
>
> [1] http://seclists.org/nmap-dev/2012/q2/649
> [2] http://seclists.org/nmap-dev/2012/q3/47
>
>
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
Henri,

Thanks for all your hard work on this bug. Unfortunately, I think there 
may be a problem with the patch. I'm trying to duplicate under a 
debugger, and will follow up with more info, but I had a scan crash last 
night during NSE scanning with this assertion error:

nmap: nsock_event.c:406: msevent_new: Assertion `msiod->state != 
NSIOD_STATE_DELETED' failed.

I'll post more information once I have reproduced the crash.

Dan

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