[Snort-devel] small tag bug

Andreas Östling andreaso at ...387...
Fri Nov 8 07:31:04 EST 2002

Version 2.0.0beta (Build 27) (and 1.9.x too).

I think there is a bug when a sig with tagging matches twice (or more), e.g. 
first from client and then from server.

For example using this sig:

alert tcp any any <> any any (msg: "foo, TAGGING"; content: "foo"; tag: host, 
5, src, seconds;)

And then make it match twice:

$ nc 25
220 blabla ESMTP Sendmail 8.12.6/8.12.6; Fri, 8 Nov 2002 14:34:36 +0100 (CET)
500 5.5.1 Command unrecognized: "foo"

It's causing these alerts:

11/08-15:01:30.520740  [**] [1:0:0] foo, TAGGING [**] [Priority: 0] {TCP} ->
11/08-15:01:30.520903  [**] [1:0:0] foo, TAGGING [**] [Priority: 0] {TCP} ->

In AddTagNode() there is a check for duplicate tags (in two places)
and if a dup is found (which it is in the above case) seconds/bytes/packets 
are doubled. When using 'seconds' as metric (which is saved as the time of 
expiration, not seconds left to expiration) this means that the expiration 
time will become like 2073524964, which is sometime in 2035 :)

It also seems to occure when simply sending the matching string multiple 
times, and each time the returned->seconds is incresed with a few years, and 
->bytes and ->packets are doubled..

If I understand the dup check (which I'm not sure I'm doing), it's there to 
extend the seconds/bytes/packets limit when a tagged packet matches a tag sig 
again. But then, wouldn't it make more sence to reset seconds/bytes/packets 
to the original value specified in the sig instead of being doubled each 

On the other hand this would be bad if a packet first matches sig 1 which has 
a tag of 100000000 seconds, and then a packet that was tagged by this rule 
immediately matches a different tag rule with a tag of 2 seconds. In that 
case one wouldn't want to decrease the original huge tag time down to 2.
I'm just thinking loud here so I think I should stop now.


More information about the Snort-devel mailing list