[Snort-users] spo_database oddity
roesch at ...1935...
Fri May 4 15:32:08 EDT 2001
Ok, I'm pretty sure I fixed this, I tested it out locally and it seems
to be working fine now. I modified the PrintXrefs function so that it
initializes its ds_ptr to NULL, moved the function call into the scope
if the check to make sure the Packet pointer is valid, and NULL'd the
otn_tmp variable at the end of each detection cycle. That ought to do
roman at ...438... wrote:
> 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)
> > MySQL
> > 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.
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> Snort-users list archive:
roesch at ...1935...
http://www.sourcefire.com - http://www.snort.org
More information about the Snort-users