[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snort-sigs
Subject:    [Snort-sigs] False positive on sid:2109  POP3 TOP overflow attempt
From:       Ben Dugdale <ben.dugdale () sheepcamp ! com>
Date:       2005-01-31 22:59:18
Message-ID: 41FEB9F8.2050702 () sheepcamp ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]