node-libnmap icon indicating copy to clipboard operation
node-libnmap copied to clipboard

libnmap does not return full child_process error

Open noMoneyNoProblems opened this issue 6 years ago • 2 comments

Summary: I noticed that the nmap executable called by libnmap was failing, but the error message contained no description of what caused it to fail. I'd like to see the the full error caught by node in the future.

But before the details, I want to offer my thanks to jas- for creating a simple library that makes it so easy to call nmap from javascript. I'm sure it was a lot of effort, and I've benefited from it!

Details: While running libnmap 0.4.11, I noticed repeated logs of the following sort:

2019-09-21 18:45:13+0900: NmapHandler: Error: Error: Command failed: "C:\Program Files (x86)\path_to_nmap\nmap.exe"  --host-timeout=120s -T4 --privileged -sS -sV --version-light -oX - -p22 xxx.yyy.zzz.aaa

2019-09-21 18:45:13+0900: NmapHandler: Error: Error: Command failed: "C:\Program Files (x86)\path_to_nmap\nmap.exe"  --host-timeout=120s -T4 --privileged -sU -sV --version-light -oX - -p53 aaa.bbb.ccc.ddd

Note that this error states that the nmap.exe on Windows is failing, but there's no mention of what is making it fail.

Here is the essence of the code that is logging the error:

libnmap.scan(scanConfig, (err, report) => {
            if (!err) {
                    return report;
            } else {
                console.error(`NmapHandler: ${err}`);
                //Handle error
            }
        });

I wasn't sure what caused the error, but I knew it had to do with the Windows environment. So I attempted to reproduce by jacking my Windows memory usage up to near 100%, and running some libnmap scans.

Upon doing this, I received the following error:

Error: Error: Unclosed root tag
Line: 8
Column: 0
Char:
    at tools.worker (C:\Program Files (x86)\path_to_node_modules\node_modules\libnmap\lib\libn
p.js:105:21)
    at C:\Program Files (x86)\path_to_node_modules\node_modules\libnmap\node_modules\async\dis
async.js:3888:9
    at C:\Program Files (x86)\path_to_node_modules\node_modules\libnmap\node_modules\async\dis
async.js:473:16
    at iterateeCallback (C:\Program Files (x86)\path_to_node_modules\node_modules\libnmap\node
odules\async\dist\async.js:988:17)
    at C:\Program Files (x86)\path_to_node_modules\node_modules\libnmap\node_modules\async\dis
async.js:969:16
    at C:\Program Files (x86)\path_to_node_modules\node_modules\libnmap\node_modules\async\dis
async.js:3885:13
    at xmlParser.parseString (C:\Program Files (x86)\path_to_node_modules\node_modules\libnmap
ib\classes\reporting.js:42:18)
    at Parser.<anonymous> (C:\Program Files (x86)\path_to_node_modules\node_modules\libnmap\no
_modules\xml2js\lib\parser.js:307:18)
    at Parser.emit (events.js:189:13)
    at SAXParser.onerror (C:\Program Files (x86)\path_to_node_modules\node_modules\libnmap\nod
modules\xml2js\lib\parser.js:122:26)​

You can see that it's not the same as the first errors, but it also doesn't tell you that libnmap is failing because of memory limitations, which is the root cause.

I was able to to log the real problem by adding a console.error to the /lib/classes/reporting.js file:

  reports(opts, report, cb) {
   console.error("HERE IS THE ERROR:");
   console.error(report);
    if ((!/object/.test(typeof report)) || (report.hasOwnProperty('code')))
    ...

And the memory exception I expected was logged:

HERE IS THE ERROR:
{ Error: Command failed: ".\path_to_nmap\Nmap\nmap.exe"  --host-timeout=120s -T4 --privileged -sS -sV --versi
on-light -oX - -p8080 8.8.8.8
Malloc Failed! Probably out of space.
QUITTING!

    at ChildProcess.exithandler (child_process.js:294:12)
    at ChildProcess.emit (events.js:189:13)
    at maybeClose (internal/child_process.js:970:16)
    at Socket.stream.socket.on (internal/child_process.js:389:11)
    at Socket.emit (events.js:189:13)
    at Pipe._handle.close (net.js:597:12)
  killed: false,
  code: 1,
  signal: null,
  cmd:
   '".\\path_to_nmap\\Nmap\\nmap.exe"  --host-timeout=120s -T4 --privileged -sS -sV --version-light -oX - -
p8080 8.8.8.8' }​

Questions:

  1. Is it expected behaviour to not log the full error returned by the child_process.exec command, or is it unexpected?
  2. If it's unexpected, can you spot something wrong with my setup / reproduction method that is causing the problem?

Thank you kindly for your time!

noMoneyNoProblems avatar Dec 03 '19 03:12 noMoneyNoProblems

Thanks for reporting this. The error handling doesn't bubble up here for any OS, pull requests and patches are welcome! Use the contributing document to help. I simply do not have the time to resolve it before the end of the year.

jas- avatar Dec 03 '19 11:12 jas-

Hey, thanks a lot for the quick response jas-!

I'll look into it, and send you a patch before Christmas.

Cheers!

noMoneyNoProblems avatar Dec 05 '19 03:12 noMoneyNoProblems