[Oisf-devel] PCRE '/R' bug?

[Anoop Saldanha]

Will,

Right.  For cases where there's no previous relative content specified
before a within/distance content, we would treat it like offset/depth.
 I think this was done more to have some sort of uniformity between
sticky buffers that allowed such a scheme in snort(dce_stub_data
required this previously), although it doesn't seem necessary.

Maybe some sort of warning message is in order!?

On Wed, Feb 5, 2014 at 2:56 AM, Will Metcalf <william.metcalf at gmail.com> wrote:
> If Suri supports it first, is it breaking compat with snort? (I think this
> was the case..) I would say that the bug is that suri 2.0 does not give an
> error on this condition. Unless the decision was made to treat
> distance/within like depth/offset. when no previous buffer was specified.
> While this might be snort compat, I think it's a bad choice. depth/offset
> should be from the start of packet/stream/buffer distance/within should be
> forced to have a previous match in the same packet/stream/buffer IMHO.
>
> Regards,
>
> Will
>
>
> On Tue, Feb 4, 2014 at 3:08 PM, rmkml <rmkml at yahoo.fr> wrote:
>>
>> Thx Will for feedback,
>>
>> Yes you are right, pcre IR or UR work (sid 3 and 6),
>> but before suri v2.0beta2, suri errors if pcre R+^ relative
>> http_raw_uri/http_uri (sid 2 and 5).
>> Maybe back error on suri v2 ? (because suri not fire)
>>
>> FYI, snort v2960 fire if pcre R+^ relative http_raw_uri/http_uri (sid 2
>> and 5).
>> but errors if pcre IR or UR... (sid 3 and 6)
>> (break suri / snort compatibility?)
>>
>> Tested with:
>> alert tcp any any -> any 80 (msg:"Testing Rule1"; content:"baduricontent";
>> http_raw_uri; pcre:"/[a-z]{5}\.html/R"; sid:1; rev:2;)
>> alert tcp any any -> any 80 (msg:"Testing Rule2"; content:"baduricontent";
>> http_raw_uri; pcre:"/^[a-z]{5}\.html/R"; sid:2; rev:2;)
>> alert tcp any any -> any 80 (msg:"Testing Rule3"; content:"baduricontent";
>> http_raw_uri; pcre:"/^[a-z]{5}\.html/IR"; sid:3; rev:2;)
>> alert tcp any any -> any 80 (msg:"Testing Rule4"; content:"baduricontent";
>> http_uri; pcre:"/[a-z]{5}\.html/R"; sid:4; rev:2;)
>> alert tcp any any -> any 80 (msg:"Testing Rule5"; content:"baduricontent";
>> http_uri; pcre:"/^[a-z]{5}\.html/R"; sid:5; rev:2;)
>> alert tcp any any -> any 80 (msg:"Testing Rule6"; content:"baduricontent";
>> http_uri; pcre:"/^[a-z]{5}\.html/UR"; sid:6; rev:2;)
>>
>> (pcap previously sended)
>>
>> Regards
>> @Rmkml
>>
>>
>>
>> On Tue, 4 Feb 2014, Will Metcalf wrote:
>>
>>> You need to specify relative pcre matches like this, then it works...
>>> Note the "I".
>>> alert tcp any any -> any 80 (msg:"Testing Rule"; content:"baduricontent";
>>> http_raw_uri; pcre:"/^[a-z]{5}\.html/IR"; sid:2; rev:2;)
>>>
>>>
>>>
>>> On Tue, Feb 4, 2014 at 9:50 AM, rmkml <rmkml at yahoo.fr> wrote:
>>>       Thx Anoop,
>>>
>>>       opened Suricata redmine ticket #1098.
>>>
>>>       Thx for your time.
>>>       @Rmkml
>>>
>>>
>>>       On Mon, 3 Feb 2014, Anoop Saldanha wrote:
>>>
>>>       rmkml,
>>>
>>>       If that specific case isn't firing, that's a bug indeed.  Can you
>>>       please open a ticket for it?
>>>
>>>       On Sat, Feb 1, 2014 at 3:58 AM, rmkml <rmkml at yahoo.fr> wrote:
>>>       Hi Harley,
>>>
>>>       Yes it's not work on Suricata v1.4.7 but fire on v2.0 beta 2.
>>>
>>>
>>>       oisf-devel: But maybe you have another bug on Suricata v2.0 beta 2,
>>> I'm
>>>       explain:
>>>        If you add ^ on pcre begin, suricata not fire with this uri:
>>>       baduricontentabcde.html
>>>       (It's fire on snort)
>>>
>>>       fire on suri v2:
>>>       alert tcp any any -> any 80 (msg:"Testing Rule";
>>> content:"baduricontent";
>>>       http_raw_uri; pcre:"/[a-z]{5}\.html/R"; sid:1; rev:2;)
>>>
>>>       not fire on suri v2:
>>>       alert tcp any any -> any 80 (msg:"Testing Rule";
>>> content:"baduricontent";
>>>       http_raw_uri; pcre:"/^[a-z]{5}\.html/R"; sid:2; rev:2;)
>>>
>>>       Tested with: wget http://google.com/baduricontentabcde.html
>>>       (joigned pcap file)
>>>
>>>       Anyone confirm please ?
>>>
>>>       Regards
>>>       @Rmkml
>>>
>>>
>>>
>>>
>>>
>>>       On Fri, 31 Jan 2014, Harley H wrote:
>>>
>>>       Good catch but that's a typo. I typed the rule in vice
>>> copying/pasting
>>>       like I should have.
>>>
>>>
>>> On Fri, Jan 31, 2014 at 5:02 PM, Edward Fjellsk?l
>>> <edwardfjellskaal at gmail.com> wrote:
>>>       -----BEGIN PGP SIGNED MESSAGE-----
>>>       Hash: SHA1
>>>
>>>       "/[a-z]{5}.html"/R"
>>>
>>>
>>> is there a " to much?
>>>
>>> E
>>>
>>> On 01/31/2014 10:40 PM, Harley H wrote:
>>>       Hello, I was going to submit this through Redmine but I'm not
>>>       receiving the account activation email. I'm trying to write a rule
>>>       like this:
>>>
>>>       alert tcp $HOME_NET any -> $EXTERNAL_NET $WEB_PORTS (msg: "Testing
>>>       Rule"; content: "baduricontent"; http_raw_uri; pcre:
>>>       "/[a-z]{5}.html"/R"; sid: 123; rev: 1;)
>>>
>>>       But am receiving this error message:
>>>
>>>       31/1/2014 -- 16:19:25 - <Error> - [ERRCODE:
>>>       SC_ERR_INVALID_SIGNATURE(39)] - No preceding content or uricontent
>>>       or pcre option 31/1/2014 -- 16:19:25 - <Error> - [ERRCODE:
>>>       SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp
>>>       $HOME_NET any -> $EXTERNAL_NET any (msg: "Testing URL"; content:
>>>       "baduricontent"; http_raw_uri; pcre: "/[a-z]{5}\.html/R"; sid:
>>>       98765; rev: 1;)" from file
>>>       /root/Desktop/Local_Workspace/IDS_Rules/testing.rules at line 1
>>>
>>>
>>>       When I get rid of 'http_raw_uri' and replace that 'content' with
>>>       'uricontent' the same error message is produced.
>>>
>>>       -Harley
>
>



-- 
-------------------------------
Anoop Saldanha
http://www.poona.me
-------------------------------