Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Snort-Signatures
[Top] [All Lists]

Re: [Snort-sigs] Strange PCRE usage in standard snort rules

Subject: Re: [Snort-sigs] Strange PCRE usage in standard snort rules
Date: Mon, 9 May 2005 16:03:04 +1000
On Mon, 9 May 2005 14:26:18 +1000
Erik de Castro Lopo <erikd+snort@sensorynetworks.com> wrote:

<snip a whole bunch of speculation>

I wish the docs were less ambiguous :-).

OK, in order to resolve this ambiguity, I looked at the code.
Here's the short version (with the justification below):

     0) Pcre components with the /R flag start their search at
        the end of the last search.
     1) Both content and pcre searches update the same current
        position pointer to be equal to the end of any matches
        they make.

This means that for the example I gave (rule number 2937 from 
the netbios rules):

    pcre:"/^.{27}/R";
    content:"&|00|"; distance:29; within:2;

Due the the /R (relative flag), the pcre engine starts searching 
at the end of the previous match. Note here that the absence of
the /s flag means that dot will only match non-newline characters.
Therefore, if there are 27 non-newline characters, the DE will
then look for the string "&|00|" at exactly 29 bytes from the end 
of the PCRE match.

This means that the PCRE could be replaced with "/^[^\n]{27}/R",
but cannot be dropped altogether.

-----------------------------------------------------------------

Longer version
==============

Looking at the code (src/detection-plugins/sp_pcre.c) I find that 
the presence of the /R specifier sets the SNORT_PCRE_RELATIVE flag.

When the detection engine needs to apply the PCRE engine to a packet,
it does so by calling the function SnortPcre() which in turn calls
the static function pcre_search() which has the following protoype:

    static int pcre_search(const PcreData *pcre_data,
                       const char *buf,
                       int len,
                       int start_offset,
                       int *found_offset);

In function SnortPcre(), the option flags are checked for 
SNORT_PCRE_RELATIVE and if it is set, the value of doe_ptr (the pointer 
that points the end of the current match) is added to the start address 
of the packet before calling pcre_search().

In addition, at the end of the SnortPcre() function, the doe_ptr value 
is updated to be equal to the end of the pcre match string.

I hope this helps.

Cheers,
Erik
-- 
-------------------------------------------------------
[N] Erik de Castro Lopo, Senior Computer Engineer
[E] erik.de.castro.lopo@sensorynetworks.com
[W] http://www.sensorynetworks.com
[T] +61 2 83022726
[F] +61 2 94750316
[A] L6/140 William St, East Sydney NSW 2011, Australia
-------------------------------------------------------
A good debugger is no substitute for a good test suite.


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs

<Prev in Thread] Current Thread [Next in Thread>