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

Peter Manev petermanev at gmail.com
Wed Feb 5 02:30:57 EST 2014


On Wed, Feb 5, 2014 at 4:49 AM, Anoop Saldanha <anoopsaldanha at gmail.com> wrote:
> 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
>>

Yes I agree with Will too.


>>
>> 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
> -------------------------------
> _______________________________________________
> Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
> Site: http://suricata-ids.org | Participate: http://suricata-ids.org/participate/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> Redmine: https://redmine.openinfosecfoundation.org/



-- 
Regards,
Peter Manev


More information about the Oisf-devel mailing list