Nmap NASL Wrapper Timing Bug --scan-delay

[vasmeister]

Hi,

I may have discovered a bug in nmap.nasl concerning the --scan-delay option. This research resulted because of an issue I initially had: Nmap (NASL wrapper) rate limits / timing settings

My feed version is 20210429T1046. This is the relevant nmap.nasl script excerpt:

Line 304 checks, if the given parameter p consist of numbers only. In line 206 the parameter p is added to the nmap arguments (argv). --scan-delay expects a time parameter. According to the nmap documentation:

Some options accept a time parameter. This is specified in seconds by default, though you can append ‘ms’, ‘s’, ‘m’, or ‘h’ to the value to specify milliseconds, seconds, minutes, or hours.

The parameter p is added without any unit, therefore it defaults to seconds. If you would specify 20ms in web user interface, the regex check is going to fail.

First option: fix in line 306: argv[i++] = p + 'ms';

Second Option: Drop mandatory ms scale in all timing options and let users decide the unit via the preferences in the user interface (e.g. 20ms).

[cfi]

Welcome to this community and great catch @vasmeister, thanks a lot for posting this.

Unfortunately the preference names currently can’t be changed (like e.g. Minimum wait between probes (ms) changed to just Minimum wait between probes) as long as there are a few GOS 6.0 installations still supported without breaking existing scan configurations.

This only leaves the first option for a fix. Expect these changes to arrive in the feeds in the next few days.

[vasmeister]

I understand the issue with such a big change. I’m good with the first option anyway.

I’m going to mark your reply as the solution, after I can confirm the arrival of the fix in the feeds.