Nmap Development mailing list archives
Re: [PATCH] Allow comments in exclusion file
From: Tom Sellers <nmap () fadedcode net>
Date: Fri, 21 Aug 2009 15:52:13 -0500
David Fifield wrote:
On Wed, Jul 29, 2009 at 05:40:29PM -0500, Tom Sellers wrote:The attached patch modifies targets.cc so that comments will be allowed in the files specified by the --exculsionfile parameter. If the patch is accepted the following comment styles would be permitted: 1. Lines beginning with a '#', for example: #This IP address is for the server with the broken app, #input validation is your friend... 2. Comments prefixed with '#' that occur after the IP address or network specification. For example: 196.168.1.1 #home router with limited space on the firewall state table This functionality will make keeping track of an ongoing and/or lengthy exclusion list feasible.Thanks, Tom, this is a good idea. I'd like to merge the patch with just a couple of changes. First, please update the --excludefile documentation in docs/refguide.xml. You don't have to make sure the DocBook builds correctly, just add some text following the format of the file. Second, for "strncmp(pc, "#", 1) != 0", just write "*pc != '#'", but really that bit of code is better written /* Determine if the next token starts with a '#', if so, quit processing this line. */ if (*pc == '#') break; if(excludelist[i].parse_expr(pc,o.af()) == 0) { if (o.debugging > 1) error("Loaded exclude target of: %s", pc); ++i; } pc=strtok(NULL, "\t\n "); Is it really required to treat lines beginning with '#' as a special case? It appears that this would be handled properly by the in-loop code. If not, then the special case also needs to allow for whitespace preceding the initial '#'. The whole load_exclude function is really two pairs of symmetric parsing loops, the first loop to count the number of elements and the second loop to fill in the newly allocated array. Really, the first counting loop should be aware of comments too, but by being ignorant of comments it can only overestimate the amount of storage required so it's safe not to make it aware. In fact, I prefer that it not be made aware of comments, because having to remember to update both loops is a bad design and this will encourage me to rewrite the function. David Fifield
All, While working on this I came across a couple of things that might prevent these changes (comments in the targets and exclude files) from working. Before I continue, I would like to get some feedback... 1. The changes to the exclude file would break the specification for the file format which says that the file contains excluded targets delimited by newline, space or tab. The section of the code (targets.cc, starting line 310) reads a line at time. My changes stop processing the line if a # is found at the beginning of a line or token. Stopping at the beginning of the token lets lines that start with an IP and followed by a #comment be processed. Since I stop processing the line at the #, any IPs in the same line after # are considered comments and are not added to the list of excluded addresses. I expect that there are people who have exclude files that are just a series of addresses separated by spaces. This would break these files if a comment was included anywhere on a line except at the end. Should I abandon these changes? 2. The parsing of the target source list (-iL) is handled in an entirely different manner - character by character (nmap.cc, starting line 420). This presents its own challenges. I cannot add the ability to comment file entries without both breaking the spec and re-engineering the way that target validation is performed. Neither of which I think is wise. BTW, is there code somewhere that simply validates data to determine if it is a valid nmap target specification (i.e. only contain legal characters and ranges)? I have seen a few places in the code where separating this function from the error message would be useful. In particular, while validating the exclude file entries. Certain characters generate an error message, but there is no indication that it is because of issues in the exclusion list, not the targets list. Example: Invalid character in host specification. Note in particular that square brackets [] are no longer allowed. They were redundant and can simply be removed. If that the address validation function were available the logic could be changed to be something like this If !valid_address(string) { do something useful } else { address this somehow error("Invalid exclusion %s %s",string,reason) } I hope this was coherent... Tom _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- [PATCH] Allow comments in exclusion file Tom Sellers (Jul 29)
- Re: [PATCH] Allow comments in exclusion file David Fifield (Aug 06)
- Re: [PATCH] Allow comments in exclusion file Tom Sellers (Aug 06)
- Re: [PATCH] Allow comments in exclusion file Tom Sellers (Aug 21)
- Re: [PATCH] Allow comments in exclusion file David Fifield (Aug 23)
- Re: [PATCH] Allow comments in exclusion file Tom Sellers (Sep 26)
- Re: [PATCH] Allow comments in exclusion file David Fifield (Sep 28)
- Re: [PATCH] Allow comments in exclusion file David Fifield (Aug 06)