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

L0rd Ch0de1m0rt l0rdch0de1m0rt at ...2499...
Thu Nov 7 16:42:22 EST 2013


Hello.

@Bad Horse: I tried http_raw_uri and it still does not work.  That is good
point about the colon in the uri.  The funny thing is that if I increase
the distance, it WILL work so it seems that maybe the parser it getting
"stuck" on the first content match (0x2F) and not evaluating everything in
full.  To test, I tried this rule and it DID work! :

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:50;)

@Baggy: I tried a number of versions and the latest was 2.9.5.3 I believe,
is that still supported?

Thanks for everyones' help.

Cheers,

Lord C.


On Thu, Nov 7, 2013 at 12:31 PM, Bhagya Bantwal <bbantwal at ...402...>wrote:

> Hello,
>
> Have you tested with snort version snort 2.9.5.5? With this snort version
> I see the alert as expected.
>
> If it still doesn't work, you can send me your pcap & conf and I will take
> a look.
>
> Thanks!
> B
>
>
> On Wed, Nov 6, 2013 at 2:01 PM, L0rd Ch0de1m0rt <l0rdch0de1m0rt at ...2499...>wrote:
>
>> 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.
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the
>> most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Snort-devel mailing list
>> Snort-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/snort-devel
>> Archive:
>> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>>
>> Please visit http://blog.snort.org for the latest news about Snort!
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20131107/9a06d075/attachment.html>


More information about the Snort-devel mailing list