Re: Why the "Linux goofiness" socket writability check?

[David Fifield <david () bamsoftware com>]

On Tue, Jul 14, 2009 at 11:58:47AM -0600, David Fifield wrote:
> What is the purpose of this code in handle_connect_result in
> nsock/src/nsock_core.c?
>
>     switch(socket_error) {
>     case 0:
> #ifdef LINUX
>       if (!FD_ISSET(iod->sd, &ms->mioi.fds_results_r)) {
>       /* Linux goofiness -- We need to actually test that it is writeable */
>       rc = send(iod->sd, "", 0, 0);
>       
>       if (rc < 0 ) {
>         nse->status = NSE_STATUS_ERROR;
>         nse->errnum = ECONNREFUSED;
>       } else {
>         nse->status = NSE_STATUS_SUCCESS;
>       }
>       } else {
>       nse->status = NSE_STATUS_SUCCESS;
>       }
> #else
>       nse->status = NSE_STATUS_SUCCESS;
> #endif
>       break;
>
> The function is called whenever the iod->sd bit is set in either
> fds_results_r, fds_results_w, or fds_results_x. The code is saying, if
> it was not because fds_results_r was set (presumably fds_results_w was
> set--the socket is writable), then do a 0-length send to test if the
> socket really is writable.
>
> The code predates the public Subversion repository, so I can't get a log
> message from when it was added.
>
> This code is problematic for a couple of reasons. First, this breaks
> SCTP connections, because SCTP does not support 0-length sends. You an
> "Invalid argument" error. http://seclists.org/nmap-dev/2009/q3/0088.html.
> Second, I found now that UDP connects are also routed through
> handle_connect_result, Nsock UDP connections are sending a packet with
> an empty payload right after connection.

Fyodor didn't remember what this code was for but it dates back to 2000
at least. (There was a problem with the permissions in the Subversion
repository, but Fyodor changed it and now you can see log messages going
back further.) We decided to remove it and see if it causes problems. It
is removed in r14426.

I tried to find an old Linux to test it with. I tried a Linux 2.4 live
CD but Nmap wouldn't run compiled against a newer Glibc, even compiled
statically. I compiled it under a 2.6.8.1 live CD from 2004, and version
detection, NSE, and Ncat worked without any problem.

David Fifield

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