[Snort-users] False positives with SMTP RCPT TO overflow rule
mkettler at ...4108...
Thu Jun 27 12:09:13 EDT 2002
Well, no known exploit for executing code exists, but a DoS attack can be
achieved easily with this vulnerability. However, there's no particular
data necessary to cause the DOS, only an exceptionally large amount of it.
Hence the difficulty in creating a reasonable snort signature.
Ideally the signature would trigger on RCPT TO: followed by more than 512
bytes before a newline, and would account for the data being sent in
multiple TCP segments.
However, snort doesn't have any "length of string till newline" type
functionality. It has string matching ability, and segment size matching
ability, and those are used to approximate a reasonable rule. In fact, if
your SMTP server doesn't support pipelining, it's a pretty good rule, which
is probably why it was written the way it was.
Unfortunately most reasonable implementations of SMTP with ESMTP support
pipelining, and most listservs take advantage of it. Yes there's a lot of
"kludged to support internet mail" groupware servers out there that don't
support pipelining, but I don't call kludges reasonable implementations :)
My stand is that anyone foolish enough to run a really old version of lotus
notes as a directly exposed-to-the-internet mailserver isn't likely to be
clueful enough to be running snort. The rule is false-positive prone, false
negative prone, and just generally silly. Every time I update my rules this
is one of the first things I kill in the ruleset, right after most of the
ping rules that don't bother me, and upping the size for the large UDP
packet one that gets set off by some weird IP stacks (AIX?) sense of MTU
>I noticed in the archived Bugtraq description of the vulnerability
>that no known exploit exists. Does that make it difficult/impossible
>to create a signature specific to this vulnerability?
>Speaking of general-purpose snort deployments, are there any
>documented recommendations for which rules/rulesets ought to be
>included? Or is it just a given that one should be reviewing each
>and every rule for applicability to one's own situation? I looked
>through the Snort docs, but they seem to be more tailored to rule
>creation. If I didn't RTFM carefully enough, please let me know.
>Nels Lindquist <*>
>Information Systems Manager
>Morningstar Air Express Inc.
>ThinkGeek at http://www.ThinkGeek.com/
>Snort-users mailing list
>Snort-users at lists.sourceforge.net
>Go to this URL to change user options or unsubscribe:
>Snort-users list archive:
More information about the Snort-users