-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No error checking for source port binding #1939
Comments
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 |
If you run nmap with debug level 1 or higher then you will get an error message:
|
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 |
As a quick hack, you can replace |
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. |
Which specific script was trying to bind to 22/tcp? |
No idea, I regularly run the following command on my server:
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. |
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 |
I take it back. Scripts like |
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 |
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()
innsock/src/nsock_connect.c
, the error is logged but not propagated:This is apparently by design, judging by the following comment in
nsock_make_socket()
: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:I am proposing to revisit the decision for suppressing these errors so that the consuming code is not randomly failing.
The text was updated successfully, but these errors were encountered: