Re: False positives with SMTP RCPT TO overflow rule

[Matt Kettler <mkettler () evi-inc com>]

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 
probing.




> 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.
>
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users