[Snort-sigs] Serious problems Snort 2.9 with relative content matches using http_inspect preprocessor and http_uri keyword

L0rd Ch0de1m0rt l0rdch0de1m0rt at ...2420...
Wed Nov 6 14:01:40 EST 2013


Hello,

Previously I posted on this list with an email subject of, "distance,
within, and negated matches".  Today I bring another issue that I am having
that I believes could be related and is non-trivial and super serious.

When I analyze it I believe that relative (1 byte?) content matches are not
being properly applied in the http_uri buffer.  Other buffers for the http
preprocessor may be affected as well but I have not tested them but I won't
be suprised if they are also infected by this bug.

This is an example of the rule Im using:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Dont Cry 4 Me
Trojanina"; flow:established, to_server; content:"GET"; http_method;
content:"|2F|"; http_uri; content:"|3A|"; http_uri; distance:1; within:20;)

Using a simple pcap ("Follow TCP stream" output from Ethereal is here:)

GET /iused/2/trust/the.http_preprocessor/sad1/cr1090hs:SN-IF-FF- HTTP/1.1

The rule does not alert even though the Snort output shows that the HTTP
data is being properly recognized and processed by the http_inspect
preprocessor. The Snort output shows that the specific GET request is being
recognized as a HTTP "GET" request.

When I remove the http_inspect directives, the rule starts to work, this is
an example:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Dont Cry 4 Me
Trojanina"; flow:established, to_server; content:"GET"; http_method;
content:"|2F|"; content:"|3A|"; distance:1; within:20;)

Is this (still?) a known issue?  I have tested this on multiple different
versions of Snort 2.9.

Cheers,

Lord C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20131106/739f59b7/attachment.html>


More information about the Snort-sigs mailing list