Nsock SSL problem (r29134 explanations)

[Henri Doreau <henri.doreau () gmail com>]

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

-- 
Henri

Attachment: nsock_ssl_fix.diff
Description:

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