[Snort-users] spo_database oddity

roman at ...438... roman at ...438...
Fri May 4 14:26:14 EDT 2001

This is what I have been able to confirm:  (see Steve's message)

It would appear that the 
"OptTreeNode *otn_tmp->ds_list[PLUGIN_REFERENCE_NUMBER]" 
is not being reset to null between triggers of alert messages
under certain circumstances.  As a consequence, certain alerts
will have incorrect references attributed to them by the DB
plug-in (perhaps others).

A1 = some rule triggered alert with references
A2 = some rule triggered alert without references
A3 = preprocessor (portscan) triggered alert (obviously no references). 

Triggering A1 => A2 will cause the correct results
  - A1 has references logged
  - A2 has NO references logged

Triggering A1=>A3=>A2 will cause improper results (see Steve's message
for an example)
  - A1 has references logged (correct)
  - A3 has A1's references logged (incorrect!)
  - A2 has NO references logged (correct)
Since A3 was not generated by a rule, there is no corresponding
OptTreeNode to use.  Hence, the value received by the DB
plug-in (when it declares the extern variable in Database() ) will 
be the last _triggered_ rule.


> Scenario:
> 1) A rule triggers that has reference info.
> 2) ref info is properly added to the database for the signature in #1.
> 3) The next alert comes from a preprocessor.
> 4) The ref info from #2 that applies to alert in #1 is added to the database
> for the signature create for #3.
> 5) All preprocessor generated alerts after this also get the ref info from
> #2, until a rule based alert happens with no ref info.  If a rule based
> alert happens with and different ref, the preprocssor alerts log with the
> new ref.
> This has been seen with spp_portscan.  I have not tested the other
> preprocessors, but a quick look through the code suggests to me that it
> should effect all preprocessor generated alerts.  This happens with
> spo_database. Syslog and logfile logging do not have this behavior. Other
> log types have not been tested.  It appears to me the the value of otn_temp
> not getting reset and then getting called by spo_database for all alerts
> (including preprocessor ones) is the problem.
> Snort 1.8 (CVS from yesterday)
> How to reproduce:
> 1)  Trigger an alert with ref info (I just did a
> http://www.webserver.com/../../ to one of my webservers)
> 2)  Quickly nmap -p 1-10 ipaddress (you need a limited scan that wont
> trigger any rule based alerts)
> Of course you need to have spp_portscan connected to the alert facility.
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users

This message was sent using Voicenet WebMail.

More information about the Snort-users mailing list