[Snort-sigs] False positive on sid:2109 POP3 TOP overflow attempt

It seems that this rule looks for 10 or more non-newline characters 
after the TOP command, and considers anything more a buffer overflow 
attempt.

alert tcp $EXTERNAL_NET any -> $HOME_NET 110 (msg:"POP3 TOP overflow 
attempt"; flow:to_server,established; content:"TOP"; nocase; 
isdataat:10,relative; pcre:"/^TOP\s[^\n]{10}/smi"; 
classtype:attempted-admin; sid:2109; rev:3;)

I've got a fetchmail process that consistently sets off the rule with a 
packet like this:

01/30-17:05:54.820048 0:30:7B:BC:48:1C -> 0:2:B9:45:A7:6E type:0x800 
len:0x52
xxx.xxx.xxx.xxx:36186 -> xxx.xxx.xxx.xxx:110 TCP TTL:63 TOS:0x0 ID:25677 
IpLen:20 DgmLen:68 DF
***AP*** Seq: 0x377E2A43  Ack: 0x37122A03  Win: 0x5B4  TcpLen: 32
TCP Options (3) => NOP NOP TS: 792484376 2669171
54 4F 50 20 31 20 39 39 39 39 39 39 39 39 0D 0A  TOP 1 99999999..

I looked in the RFC ( http://www.faqs.org/rfcs/rfc1939.html ) for a 
specification on the arguments given the top command, and see no 
indication of a limit.

         Arguments:
             a message-number (required) which may NOT refer to to a
             message marked as deleted, and a non-negative number
             of lines (required)

         Restrictions:
             may only be given in the TRANSACTION state

         Discussion:
             If the POP3 server issues a positive response, then the
             response given is multi-line.  After the initial +OK, the
             POP3 server sends the headers of the message, the blank
             line separating the headers from the body, and then the
             number of lines of the indicated message's body, being
             careful to byte-stuff the termination character (as with
             all multi-line responses).

             Note that if the number of lines requested by the POP3
             client is greater than than the number of lines in the
             body, then the POP3 server sends the entire message.

         Possible Responses:
             +OK top of message follows
             -ERR no such message

         Examples:
             C: TOP 1 10
             S: +OK

             S: <the POP3 server sends the headers of the
                message, a blank line, and the first 10 lines
                of the body of the message>
             S: .
                ...
             C: TOP 100 3
             S: -ERR no such message

FWIW, man fetchmail didn't give me any info about specifying something 
less, and my installation if pretty much default.

Something like:

alert tcp $EXTERNAL_NET any -> $HOME_NET 110 (msg:"POP3 TOP overflow 
attempt"; flow:to_server,established; content:"TOP"; nocase; 
isdataat:10,relative; pcre:"/^TOP\s[^\n]{12}/smi"; 
classtype:attempted-admin; sid:2109; rev:4;)

Would take care of my false positive, but I don't know about the 
possibility of others.  Where did the 10 character limit come from?  Is 
there a POP server that is vulnerable at that number, or have I missed a 
specification, or just common sense and I found the exception?


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs