Nmap Development mailing list archives
Re: Pcre Binding
From: Daniel Miller <bonsaiviking () gmail com>
Date: Thu, 15 Jan 2015 23:16:49 -0600
On Fri, Jul 11, 2014 at 4:50 PM, <nnposter () users sourceforge net> wrote:
Hello Patrick, Patrick Donnelly wrote:On Fri, Jul 11, 2014 at 2:51 PM, <nnposter () users sourceforge net> wrote:The PCRE/lpeg conversion broke telnet-brute.nse. A cursory look at the script code shows that some unwarranted liberties were taken when re-inventing the match patterns.I'm responsible for most of the conversions from PCRE to LPeg. telnet-brute was the only difficult script to convert. This is largely because it uses some peculiar patterns like \b (word boundary) and some unnecessary/obscure capture options (?).The reason behing the pattern complexity is to increase accuracy, such as to avoid false positives.I had to make a fix in r33180 because I botched the patterns. I'm pretty sure they are correct now and we have some simple asserts to verify subjects that should match.I have tested r33222. As an example, the script will report every tried username as valid on Cisco IOS.IMHO it is not appropriate to do so unless the person can in fact validate that the patterns are still working as expected. Put differently, either the new patterns should be functionally equal or the legacy PCRE bindings should not be messed with for the time being.I would normally agree with this philosophy but because we have so many scripts which are non-trivial to confirm actually work, I don't feel this is a sensible way to think.Of course it is non-trivial to re-validate that the updated scripts actually work and this is precisely why I believe that it is more prudent to assume that an original script author wrote the more complex patterns in a particular way for a good reason unless a defect or weakness is found. With the overarching objective of making sure that nmap works we should minimize changes that cannot be assessed. Devin's argument for removing the PCRE functionality is that Lpeg is a functional superset. If true, why not to simply reproduce them accurately?
nnposter, In response to your bug report [1], I put together the attached patch. My guess is that the information about anchors (beginning and end of string) was lost during the conversion. Since re.compile creates patterns which anchor at the beginning (as all lpeg patterns do), I used lpeg-utility.anywhere() to convert them to un-anchored patterns, though perhaps it would be cleaner with a ".*" prepended to the regex instead. Contrary to my comment on the Github bug report, there *is* a way to represent the "$" end-of-string anchor: "!." If you could try this out and let us know how it works for you then we can get this issue resolved. I don't have any telnet services handy to test with, unfortunately. Dan
Attachment:
telnet-brute.patch
Description:
_______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: Pcre Binding Daniel Miller (Jan 15)
- Re: Pcre Binding nnposter (Jan 31)
- Re: Pcre Binding Patrick Donnelly (Jan 31)
- Re: Pcre Binding nnposter (Jan 31)