Snort Forums Archive

Archive Home » Snort Development » technical issues with content matching in sp_pattern_match.c

Please note that the categories listed below represent an archived version of our forums pages. To view the current version and be able to post and reply to threads, please register and login here to go to the full forums pages.

[ Notice: Full Version of This Topic ]

technical issues with content matching in sp_pattern_match.c

Posted by rdsmith on September 14, 2005 15:01:02

Hi,

I've been going through the Snort source code and have found some seeming discrepancies between the documentation and what the source code does. I'm looking at 2.3.3 source and hoping somebody can clear these up--

1. Snort user's manual section 3.5.5 (offset) says that the offset keyword specifies where to start searching from the beginning of the payload. However, in function uniSearchReal() we find the following code, which shows that the offset can be added to the base_ptr, which is not necessarily the start of the packet payload:

/* if we're using a distance call */
if(pmd->distance)
{
/* set the base pointer up for the distance */
base_ptr += pmd->distance;
depth -= pmd->distance;
}
else /* otherwise just use the offset (validated by calling function) */
{
base_ptr += pmd->offset;
depth -= pmd->offset;
}

Is this a bug? If not it seems "offset" is in reality a synonym for "distance"

2. The beginning of function uniSearchReal contains the following comment:

* in theory computeDepth doesn't need to be called because the
* depth + offset adjustments have been made by the calling function

Which calling function are the depth + offset adjustments done in, or is the documentation out of date. The calling sequence is
CheckANDPatternMatch()
idx->search() (which is uniSearch)
uniSearchReal()

It appears that the checks are not done by a calling function; but this is compensated for by the calls to inBounds() further in the function.

Clarification on these two issues would be appreciated. Thanks.

Posted by rdsmith on September 15, 2005 10:39:34

Okay, I can at least partially answer my own question with regard to the use of offset. The 'distance' and 'within' keyword registration functions (PayloadSearchWithin(), etc) set the "use_doe" flag, which then affects the code snippet I supplied above.

Basically, if 'distance' and/or 'within' show up in the rule, then use_doe is set and 'offset' and 'distance' have the same semantics. If neither 'distance' nor 'within' are used, then 'offset' actually does refer to the offset from payload start.

The upshot to this is that if using both 'depth/offset' and 'within/distance' in the same rule, all occurrences of 'depth/offset' are actually relative, just like within/distance.

At least, I'm *pretty sure* that's what happens. Can anybody verify this?

Posted by Joel_Esler on September 15, 2005 18:55:35

Answers to Questions from Martin Roesch (from a chat I was having with him, where I asked your exact
questions, on irc.freenode.net in #snort)

1. the offset moves up the base_ptr and the base_ptr looks like it starts at p->data, and oh, and if it
hasn't changed, the base_ptr gets reset to p->data at the end of the search.

2. CheckANDPatternMatch has gotten a lot more complicated over the past few years, so we do the
initial pattern match and if we match we march down the option list and if the rest of the option list
fires successfully, we're done, if not then it appears we search again for the content.

Basically the docs are out of date on question 2, we need to update them, the inBounds call does the
check now in the function, which is a good idea.

Hope that helps

Joel Esler
SOURCEfire