[Snort-devel] Commentary and patch for snort 1.8.3
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
Chris Green <cmg at ...402...>
More information about the Snort-devel