[Snort-devel] Snort 2.0 rule type possible side effect bug

Nils Ulltveit-Moe num at ...2020...
Tue Jun 10 05:33:05 EDT 2003


Hello

We have found a problem in Snort 2.0 that seems to cause a side effect
between a broad ranged alert rule, that is narrowed by a following
pass rule in combination with arbitrary other rules, as shown in the
example rule set below. This side effect did not occur in Snort 1.9.1.

The purpose of the rule set shown below, is to be able to detect and
alert any other SYN ACK packets than the ones emerging from the legal
web server at address 10.10.10.7, in order to detect services that may
be in violation to the companys traffic policy.

What happens, is that there seems to be a side effect between
other rules, and the first SYN ACK rule that causes the pass
rule not to be checked. This means that with the rule set shown below,
sending a SYN packet with source port 6699 and destination port 80
 to the web server 10.10.10.7 by using:

nmap -sS -P0 -g 6699 -p 80 10.10.10.7

Causes the web server to acknowledge the connection by answering with
SYN ACK, which should be triggered as legal traffic by the pass rule (sid:
1001001), but instead is alerted as "SYN ACK packet
detected" by the first Alert rule (Sid: 1001000) caused by some
strange kind of side effect by the third "P2P Napster Client Data"
rule (sid:561). Any other similar rule (like e.g. sid:1383 or
sid:2086) also triggers the same problem, if source port happens to be
1214 or 1220 respectively. 

If the rules that causes the side effect (here: sid: 561, 1383 or
2086) are commented out, the side effect does not occur, and the pass
rule passes the traffic as legal, as it should.

We have tried to debug the problem, and we believe the problem occurs
in or after fpCreateFastPacketDetection() in fpcreate.c. The problem
seems to be present when fpAddMatch() is called in
fpEvalHeaderSW. What we hope, is that by providing a test case that
does reproduce the problem, it will be possible for you to analyse and
detect the cause of the problem.

Please tell us if you need more information to reproduce the problem.

Best regards,

Nils Ulltveit-Moe
Ivar Thompsen
Proseq AS

####################################################
# Test rule set for reproducing the side effect bug#
####################################################
alert tcp $HOME_NET any -> !$HOME_NET any (msg:"SYN ACK packet detected"; flags:SA; sid: 1001000; rev:1;)

pass tcp 10.10.10.7 80 -> !$HOME_NET any (msg:"SYN ACK packet detected"; flags:SA; sid: 1001001; rev:1;)

# If these rules are disabled, the two rules above works as expected.
alert tcp $HOME_NET any <> $EXTERNAL_NET 6699 (msg:"P2P Napster Client Data"; flow:established; content:".mp3"; nocase; classtype:policy-violation; sid:561; rev:6;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 1214 (msg:"P2P Fastrack  (kazaa/morpheus) GET request"; flow:to_server,established; content:"GET "; depth:4; reference:url,www.musiccity.com/technology.htm; reference:url,www.kazaa.com; classtype:policy-violation; sid:1383; rev:4;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 1220 (msg:"WEB-CGI streaming server parse_xml.cgi access"; flow:to_server,established; content:"/parse_xml.cgi"; nocase; reference:cve,CAN-2003-0054;  classtype:web-application-activity; sid:2086; rev:1;)





More information about the Snort-devel mailing list