No error checking for source port binding

[nnposter]

Nsock currently ignores source port binding errors, leaving the consuming code blind to the fact that the connected socket is not using the chosen port. As you can see from the code of mksock_bind_addr() in nsock/src/nsock_connect.c, the error is logged but not propagated:

  nsock_log_info("Binding to %s (IOD #%li)", get_localaddr_string(iod), iod->id);
  rc = bind(iod->sd, (struct sockaddr *)&iod->local, (int) iod->locallen);
  if (rc == -1) {
    int err = socket_errno();

    nsock_log_error("Bind to %s failed (IOD #%li): %s (%d)",
                    get_localaddr_string(iod), iod->id,
                    socket_strerror(err), err);
  }
  return 0;

This is apparently by design, judging by the following comment in nsock_make_socket():

  if (iod->locallen)
    mksock_bind_addr(ms, iod);

  if (iod->ipoptslen && family == AF_INET)
    mksock_set_ipopts(ms, iod);

  if (ms->device)
    mksock_bind_device(ms, iod);

  if (ms->broadcast && type != SOCK_STREAM)
    mksock_set_broadcast(ms, iod);

  /* mksock_* functions can raise warnings/errors
   * but we don't let them stop us for now. */

This is causing issues. As an example, the following NSE code in rpc.lua is trying to avoid port collisions but the error checking is not effective because the error is not raised in the first place:

        -- Try to bind to a reserved port
        for i = 1, 10, 1 do
          local resvport = math.random(1, 1024)
          socket = new_socket()
          status, err = socket:bind(nil, resvport)
          if status then
            status, err = socket:connect(host, port)
            if status or err == "TIMEOUT" then break end
            socket:close()
          end
        end

I am proposing to revisit the decision for suppressing these errors so that the consuming code is not randomly failing.

[Stefan-mcp]

Could some error reporting code be added as a quick patch to make the user aware that the calling script may be failing, even if the error info isn't propagated upward to the script at this stage - this would be preferable to a completely silent failure which could undermine the testing results

[nnposter]

If you run nmap with debug level 1 or higher then you will get an error message:

NSOCK ERROR [0.1770s] mksock_bind_addr(): Bind to 0.0.0.0:631 failed (IOD #5): Address already in use (98)

[Stefan-mcp]

My concern is that people wont routinely be running nmap with debug on.

If my understanding is correct, at the moment some scripts could be outputting an explicit 'Not Vulnerable' when the reality is that they should be outputting 'Not Tested'. If people have used an affected script before they may be totally blindsided due to the intermittent nature of the bug so likely wont even realize they've missed something potentially important and cant trust the normal output

Seems dangerous to have that info hidden away from the main output and only shown in what will be an edge case of people running with debug on

[nnposter]

As a quick hack, you can replace nsock_log_error in the code quoted at the beginning of this issue with fprintf(stderr,...

[zyphlar]

I got a bunch of these errors for the first time in years and thought I was under attack by a trojan somehow. Does nmap really not bother retrying after it fails to bind to a port? Stefan-mcp is correct that the assumption here is not "ah, I need to re-run that scan because nmap was too dumb to realize it couldn't do that" but rather "I wonder why this unknown program NSOCK is trying to run mksock_bind_addr on my SSH port, nothing should ever be trying to bind to my SSH port besides SSH" and then they google it and arrive here.

[nnposter]

Which specific script was trying to bind to 22/tcp?

[zyphlar]

No idea, I regularly run the following command on my server:

nmap -Pn -p 1-65535 -T4 -sV 1.2.3.4 -oX /tmp/scan.xml

where 1.2.3.4 is the thing I'm trying to scan. It's been running this way for years (I do regular port scans of my infrastructure) and today is the first time I can recall seeing this error. It also errors on the other major ports that my server is listening on, stuff like DNS, SMTP, and RPC. Though curiously not HTTPS or NRPE.

[nnposter]

I am not aware of any reason why a regular version scan should be binding to specific ports. Are you sure that you were not running -sC or some other scripts?

[nnposter]

I take it back. Scripts like rpcinfo would bind to a port and run during a version scan. Still, they should not be binding to random ports below 512. If you find one that does then share the details.

[daniel-cues]

I take it back. Scripts like rpcinfo would bind to a port and run during a version scan. Still, they should not be binding to random ports below 512. If you find one that does then share the details.

I'm a bit late to the party, but rpc-grind as well, it tries to bind to a bunch of ports under 1000. My system doesn't allow this and It's annoying, I can't identify open UDP ports if the service detection is not working