[Snort-sigs] New adobe vulnerability

nnposter at ...592... nnposter at ...592...
Fri Aug 20 08:39:07 EDT 2004

Frank Knobbe <frank at ...1978...> wrote
> On Thu, 2004-08-19 at 15:17, Joseph Gama wrote:
> > My rule was posted the same day as this posting and it
> > has no false positives:
> >=20
> > [...]pcre:"/[\w]+\.pdf%00[\w-_\.!~*'"\(\)]+HTTP\/1\.1/Bi";[...]
> Does your rule actually fire on the exploit?
> If so, question to nnposter, does his rule (using |00|) fire on the
> exploit?


> I understand that the preprocessor will convert %00 into |00| within
> matches using uricontent. But if Josephs rules works too, does that mean
> that anything that is matched using pcre has not been run through
> http_inspect?

Yes. Only uricontent is preprocessed with http_inspect. content and pcre
are not.

> How does the matching occur? All munged by http_inspect first, then
> matched by uricontent and pcre? Or first pcre, then munging by
> http_inspect, then uricontent?

The latter, see above.

> Who is right and will alert on the exploit (tested)? pcre using %00 or
> uricontent using |00| or both?

I have tested mine. I have not tested Joseph's variant but his approach of
matching on %00 with pcre will work in general as well. (Although I can 
see several ways how to craft false negatives to get around this 
particular PCRE.)

> Regards,
> Frank
> BTW: I try to stay away from pcre due to the performance impact. Is that
> fear unfounded these days (read, with newer versions of Snort)?

IMHO, having a rule without good "content" or "uricontent" is expensive. In
other words, PCRE is great but I would always try to use at least one content
or uricontent clause as a pre-match.


More information about the Snort-sigs mailing list