[Snort-devel] Commentary and patch for snort 1.8.3

Chris Green cmg at ...402...
Sat Mar 23 12:23:11 EST 2002


Mike Fisk <mfisk at ...86...> writes:
> I have working patches against the current cvs tree, but I think there are
> some fundamental problems with the semantics of uricontent and
> content-list rules.  The rules for all of these rules are stored in the
> same ds_list[] element as normal content rules, but separate
> Check[Uri|OR]PatternMatch() functions are added to the OTN function list.  

> Unfortuntately, if you have a rule with multiple types of rules, say a
> uricontent and a normal content, then both patterns will be searched for
> by both Check functions.  The result is that the rule will only trigger if
> the pattern specified by the normal content option happens to occur in the
> URI.  There will also be an extra search over the entire payload for the
> uricontent pattern.

Yes that is a major bug since they do need to be separate lists of
things to check.

>
> For example, take the following rule:
>
> alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"WEB-MISC PHP-Nuke remote
> file include attempt"; flags:A+; uricontent:"index.php"; nocase;
> content:"file=http\://"; nocase; reference:bugtraq,3889;
> classtype:web-application-attack; sid:1399; rev:2;)
>
> If I send "file=http\://" in the URI, then the rule will match.  But if I
> send it elsewhere in the packet, then the rule doesn't match.  That seems
> wrong to me.  Agreed?
>
> I have modified code that handles this correctly by allocating new
> ds_list[] elements for these different flavors of content rules:
> 	#define PLUGIN_PATTERN_MATCH_URI    27
> 	#define PLUGIN_PATTERN_MATCH_OR    28

That is reasonable since each portion of the pattern matcher really
acts a bit differently and should check against a different list of
patterns.
--
Chris Green <cmg at ...402...>
Eschew obfuscation.





More information about the Snort-devel mailing list