Re: Broken service match lines

[Daniel Miller <bonsaiviking () gmail com>]

On 09/18/2012 01:03 PM, David Fifield wrote:
> On Tue, Sep 18, 2012 at 12:45:22PM -0500, Daniel Miller wrote:
> > List,
> >
> > In a recent scan, I ran into this error:
> > > Scanning 49 services on 27 hosts
> > > Warning: Hit PCRE_ERROR_MATCHLIMIT when probing for service http
> > > with the regex '^HTTP/1\.0 \d\d\d .*\n.*Server: uClinux-httpd
> > > ([\w._-]+)\n'
> > > Warning: Hit PCRE_ERROR_MATCHLIMIT when probing for service http
> > > with the regex '^HTTP/1\.0 \d\d\d .*[^\r]\n.*Server:
> > > uc-httpd/([\w._-]+)\r\n'
> > > Warning: Hit PCRE_ERROR_MATCHLIMIT when probing for service http
> > > with the regex '^HTTP/1\.0 \d\d\d .*\n.*Server: uClinux-httpd
> > > ([\w._-]+)\n'
> > > Warning: Hit PCRE_ERROR_MATCHLIMIT when probing for service http
> > > with the regex '^HTTP/1\.0 \d\d\d .*[^\r]\n.*Server:
> > > uc-httpd/([\w._-]+)\r\n'
> > > Service scan Timing: About 42.86% done; ETC: 11:45 (0:00:41 remaining)
> > > Warning: Hit PCRE_ERROR_MATCHLIMIT when probing for service http
> > > with the regex '^HTTP/1\.0 \d\d\d .*\n.*Server: uClinux-httpd
> > > ([\w._-]+)\n'
> > > Warning: Hit PCRE_ERROR_MATCHLIMIT when probing for service http
> > > with the regex '^HTTP/1\.0 \d\d\d .*[^\r]\n.*Server:
> > > uc-httpd/([\w._-]+)\r\n'
> > > Completed Service scan at 11:47, 158.82s elapsed (49 services on 27 hosts)
> > A little googling revealed this old thread:
> > http://seclists.org/nmap-dev/2009/q2/75
> >
> > -match http m|^HTTP/1\.0 \d\d\d .*\n.*Server: uClinux-httpd ([\w._-]+)\n|s p/uClinux-httpd/ v/$1/ o/Linux/ 
> > cpe:/o:linux:kernel/a
> > +match http m|^HTTP/1\.0 \d\d\d .*Server: uClinux-httpd ([\w._-]+)\n|s p/uClinux-httpd/ v/$1/ o/Linux/ 
> > cpe:/o:linux:kernel/a
> > -match http m|^HTTP/1\.0 \d\d\d .*[^\r]\n.*Server: uc-httpd/([\w._-]+)\r\n|s p/uc-httpd/ v/$1/
> > +match http m|^HTTP/1\.0 \d\d\d (?>.*?[^\r]\n).*Server: uc-httpd/([\w._-]+)\r\n|s p/uc-httpd/ v/$1/
> In the second one, don't do the (?> thing. Just make it .* like the
> other. I think it was trying to express that the server uses just \n
> after the status-line and not \r\n, but it's not important. We're not
> likely to have false matches for this server.
Sounds fine to me. Made these changes in r29838.
> > Unfortunately, a little grepping revealed several other match lines
> > with similar problems. Looking at these and others, it looks like
> > copy-pasting match info and then adding the |s modifier may be
> > creating a problem,
> I'm not sure what you mean by this, but it doesn't sound like anything
> that has happened in signature integration in the past few years.
Here are some examples (with s modifier):

match http m|^HTTP/1\.[01] \d\d\d .*\r\n.*Server: CommuniGatePro/([-.\w 
]+)\r\n|s p/CommuniGate Pro httpd/ v/$1/
match http m|^HTTP/1\.0 \d\d\d .*\r\n.*Server: Netscape-Enterprise/([-. 
\w]+)\r\n|s p/Netscape Enterprise httpd/ v/$1/
match http m|^HTTP/1\.1 \d\d\d .*\r\n.*Server: Netscape-Enterprise/([-. 
\w]+)\r\n|s p/Netscape Enterprise httpd/ v/$1/
match http m|^HTTP/1\.1 \d\d\d .*\r\n.*Server: 
Netscape-Enterprise/([\w._-]+) ([^\r]+)\r\n|s p/Netscape Enterprise 
httpd/ v/$1/ i/$2/
match http m|^HTTP/1\.1 \d\d\d .*\r\n.*X-Powered-By: 
Servlet/([\d.]+)\r\nServer: Sun GlassFish Enterprise Server v([\w._ 
-]+)\r\n|s p/Sun GlassFish/ v/$2/ i/Servlet $1/
match http m|^HTTP/1\.1 \d\d\d .*\r\n.*X-Powered-By: 
Servlet/([\d.]+)\r\nServer: Sun GlassFish Communications Server ([\w._ 
-]+)\r\n|s p/Sun GlassFish Communications Server/ v/$2/ i/Servlet $1/


And the only 4 lines in the whole file without s modifier:

match http m|^HTTP/1\.1 \d\d\d .*\r\n.*X-Powered-By: 
Servlet/([\w._-]+)\r\nServer: GlassFish/v([\w._ -]+)\r\n| p/Sun 
GlassFish/ v/$2/ i/Servlet $1/
match http m|^HTTP/1\.1 \d\d\d .*\r\n.*X-Powered-By: 
Servlet/([\w._-]+)\r\nServer: GlassFish v([\w._ -]+)\r\n| p/Sun 
GlassFish/ v/$2/ i/Servlet $1/
match http m|^HTTP/1\.1 \d\d\d .*\r\n.*X-Powered-By: Servlet/([\w._-]+) 
JSP/([\w._-]+) \(GlassFish Server Open Source Edition ([\w._ -]+) 
Java/Sun Microsystems Inc\./([\w._-]+)\)\r\n| p/Sun GlassFish Open 
Source Edition/ v/$3/ i/JSP $2; Servlet $1; Java $4/
match http m|^HTTP/1\.[01] \d\d\d .*\r\nWWW-Authenticate: Basic 
realm=\"([^\"]+)\"\r\n.*\r\n.*\r\nServer :Tandberg Television Web 
server\r\n| p/Tandberg Television httpd/ i/Realm: $1/ d/media device/


The GlassFish ones in particular are all very similar, but inconsistent 
in application of the s modifier.

> > Perhaps someone could come up with a test program to try out the
> > matches against "pathological" strings without running a full network
> > scan.
> I don't know how it would work, but it should be a part of the sv-tidy
> program.
>
> David Fifield
Yeah, I'm pretty sure it would be a Hard Problem, but I thought I'd 
throw the idea out there. Probably better to find some tool that can 
analyze regexes for Bad Things and just clean those out (very unlikely, 
but better safe than sorry).

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