[Snort-sigs] false +ves on IMAP fetch overflow attempt: sid 3070

Russell Fulton r.fulton at ...575...
Tue Jan 25 12:39:45 EST 2005

On Mon, 2005-01-24 at 22:17 -0600, Frank Knobbe wrote:
> On Tue, 2005-01-25 at 15:05 +1300, Russell Fulton wrote:
> > I am seeing many hits on this rule for what appear to be perfectly
> > normal IMAP requests.
> > 
> > [...] My understanding of this is that we are looking for a newline within 100
> > characters of 'FETCH' and alerting if we don't find it.  Unfortunately
> > there are many legitimate FETCH requests that are longer than 100 chars.
> > [..] I will be disabling this rule.
> Russell,
> instead of disabling it, why not just increase the amount of characters?
> Perhaps... say... 300? That should be less noisy but still catch
> attempts of people trying to overflow the server with long packets.

I've looked up the details on Security Focus and the exploits use 260
bytes of padding before approx 200 chars of shell code so changing the
length to 260 would appear to be safe to catch this exploit while very
substantially reducing the number of FPs. 

Would one of the good folk at SourceFire care to do this?

I am also seeing lots of FPs on "IMAP append literal overflow attempt"
sid: 3065 which is linked to the same BID.  This one has me puzzled:

alert tcp $EXTERNAL_NET any -> $HOME_NET 143 (msg:"IMAP append literal
overflow attempt"; flow:established,to_server; content:"APPEND"; nocase;
byte_test:5,>,256,0,string,dec,relative; reference:bugtraq,11775;
classtype:misc-attack; sid:3065; rev:1;) 

Again if I understand this correctly it looks for APPEND followed by
{<digits> with no LF between the D and { and then checks to see if the
number is > 256.  I have had a brief look at the IMAP RFC but failed to
find simple explanation of what the number represents.  We regularly see
numbers in the range of several 1000.  Eg:
 append "Sent" (\Seen) {5081+}

Which trigger this rule.

This would appear to be much more difficult to fix.


More information about the Snort-sigs mailing list