Re: [BUG] Nmap host specification parsing

[jah <jah () zadkiel plus com>]

On 14/06/2009 01:43, ithilgore wrote:
> It applies to the latest svn version and the problem is that when
> you put an extra comma ',' after any host, then Nmap adds an
> additional target to the list. The target is the IP that corresponds
> to 0 for the least significant byte and for the rest of the bytes to
> the same class network as the host before the comma.
>
> $ nmap -sL -n 10.0.0.1, 10.0.0.2
>
> Starting Nmap 4.85BETA10 ( http://nmap.org ) at 2009-06-14 03:33 EEST
>
> Host 10.0.0.1 not scanned
> Host 10.0.0.0 not scanned
> Host 10.0.0.2 not scanned
> Nmap done: 3 IP addresses (0 hosts up) scanned in 0.00 seconds
>
>
> $ nmap -sL -n 10.0.0.1, 192.168.0.10,
>
> Starting Nmap 4.85BETA10 ( http://nmap.org ) at 2009-06-14 03:38 EEST
>
> Host 10.0.0.1 not scanned
> Host 10.0.0.0 not scanned
> Host 192.168.0.10 not scanned
> Host 192.168.0.0 not scanned
> Nmap done: 4 IP addresses (0 hosts up) scanned in 0.00 seconds
>
>
> Something is obviously wrong with the parsing. I didn't have time to
> check where the problem in the code is but I would start by looking
> at TargetGroup::parse_expr() at TargetGroup.cc
Commas, of course, are meaningful in a host expression except when the
following character is not a digit.
Attached is a possible fix which causes TargetGroup::parse_expr() to
stop processing the current octet if there aren't any digits following
the comma (in that octet).

So for example:
nmap -sL -n 10.0.1,2,.0

Host 10.0.1.0 not scanned
Host 10.0.2.0 not scanned
Nmap done: 2 IP addresses (0 hosts up) scanned in 0.14 seconds

And if you should be daft enough to have more than one consecutive comma
we'll advance past them (and any other allowed non-digit character) to
any remaining digits in that octet
nmap -sL -n 10.0.1,2,,3.0

Host 10.0.1.0 not scanned
Host 10.0.2.0 not scanned
Host 10.0.3.0 not scanned
Nmap done: 3 IP addresses (0 hosts up) scanned in 0.16 seconds

Commas are also meaningless at the start of an octet and currently cause
exactly the same behaviour as ithilgore noted.  This patch also advances
past any leading commas in an octet to prevent this.  So in both cases,
we're ignoring meaningless commas and interpreting the host expression
as if they weren't there.

It's worth noting that specifying a IP address such as 1..3.4 results in
1.0.3.4 and ... results in 0.0.0.0  - i.e. empty octets are interpreted
as zeros.  This behaviour is unchanged with the application of this
patch.  Currently, specifying .,.,., is expanded to 0.0.0.0 8 times:
nmap -sL -n .,.,.,

Host 0.0.0.0 not scanned
Host 0.0.0.0 not scanned
Host 0.0.0.0 not scanned
Host 0.0.0.0 not scanned
Host 0.0.0.0 not scanned
Host 0.0.0.0 not scanned
Host 0.0.0.0 not scanned
Host 0.0.0.0 not scanned
Nmap done: 8 IP addresses (0 hosts up) scanned in 0.14 seconds

With this patch the commas are ignored and 0.0.0.0 will appear only once.

What do you think?

jah

--- TargetGroup.cc.orig 2009-06-14 03:41:13.453125000 +0100
+++ TargetGroup.cc      2009-06-14 13:31:51.531250000 +0100
@@ -247,9 +247,11 @@
       i=0;
 
       while(*r) {
+        j=1;
         if (*r == '.' && ++i < 4) {
           *r = '\0';
-          addy[i] = r + 1;
+          while(*(r+j) == ',') j++;
+          addy[i] = r + j;
         }
         else if (*r != '*' && *r != ',' && *r != '-' && !isdigit((int)*r)) 
           fatal("Invalid character in host specification.  Note in particular that square brackets [] are no longer 
allowed.  They were redundant and can simply be removed.");
@@ -282,7 +284,17 @@
           for(k=start; k <= end; k++)
             addresses[i][j++] = k;
           last[i] = j-1;
-          if (s) addy[i] = s + 1;
+          if (s) {
+            while (!isdigit(*(s+1))) {
+              if (*(s+1) == '\0') {
+                s = NULL;
+                break;
+              }
+              s++;
+            }
+            if (s) addy[i] = s + 1;
+            else break;
+          }
         } while (s);
       }
     }


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