[Snort-users] spo_database oddity

Martin Roesch 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
it. :)

   -Marty

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).
> 
> Given:
> 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.
> 
> Roman
> 
> > 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.
>       http://www.voicenet.com/webmail/
> 
> _______________________________________________
> 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

--
Martin Roesch
roesch at ...1935...
http://www.sourcefire.com - http://www.snort.org




More information about the Snort-users mailing list