[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