Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [BUG] Nmap host specification parsing
From: jah <jah () zadkiel plus com>
Date: Sun, 14 Jun 2009 13:51:35 +0100

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]