[Snort-sigs] false positive for sid 2087
mkettler at ...189...
Tue Aug 3 10:48:02 EDT 2004
At 11:15 AM 8/3/2004, Chris Kronberg wrote:
>alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"SMTP From comment
>overflow attempt"; flow:to_server,established; content:"From|3A|"; nocase;
>content:"|28|"; distance:1; content:"|29|"; distance:1;
>classtype:attempted-admin; sid:2087; rev:6;)
> This triggers mails like the one included below which has nothing to
> do with the sendmail vulnerability.
> I understand that the distance keyword gives a relative offset to
> the last match, but then I do not understand what distance:0 does.
> As the vulnerabilty goes for oversized comments in the MAIL FROM
> and RCPT TO header, is there a possibility to rewrite the rule in
> the sense that it triggers wenn the content match above does _not_
> occur before the smtp DATA command?
> I'm currently playing with the within keyowrd to restrict the
> search depth, but I don't feel comfortable with that. Any better
> ideas? I'm interested for solutions for snort 2.0.x and 2.1.x.
Theoretically, your email should not have matched. the "distance:0" should,
theoretically, force the <> string to immediately follow the From: string.
However, since it's fundamentally pointless to ever use, a distance of 0 it
may be buggy.
Really, IMO, the From and the <> strings should be merged into a single
content check if they are meant to be one string. using distance:0 is
confusing, and likely to run into boundary conditions in parsers that don't
deal so well with underflow. (ie: it may be trying to do something like
"while i < distance-1" a classic programing bug that fails to handle 0
properly if you're doing unsigned numbers.)
I'd also be tempted to rewrite the whole thing as a single PCRE so I could
have more flexibility
something like this appears to match the original intent of the rule:
But you could make it more flexible to the number of <> sequences:
More information about the Snort-sigs