Snort mailing list archives
Re: IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow
From: Joel Esler <jesler () sourcefire com>
Date: Sun, 25 Mar 2012 18:24:44 -0400
Thanks rmkml, I've reopened the original research to see what we can do, if anything. We have replicated the vulnerability, and it does not "require" "}" to be there. The public exploits that you reference simply use that character. So you will have severe FN with your modifications. In fact, we have one exploit (that is public) that doesn't use "}" at all. Also the new(ish) imap preprocessor will fire on several of the public exploits that are out there simply with these alerts: 141:1:1 (IMAP) Unknown IMAP4 command And this generic rule also fires on one of the exploits that we have: 1:2118:12 IMAP list overflow attempt However, as I mentioned at the beginning, the "}" character isn't necessary, (we have executed shellcode on a machine remotely without using "}"). We have reopened the bug to see if we can make more accurate detection. -- Joel Esler Senior Research Engineer, VRT OpenSource Community Manager Sourcefire On Mar 25, 2012, at 7:30 PM, rmkml wrote:
Personnaly I have rewrited these two VRT rules to simply "}}}}}" (of course removed dsize/flowbits, my rule are possible FN/FP but I don't have FP on my network traffic) http://www.securityfocus.com/bid/15980/exploit Regards Rmkml On Mon, 26 Mar 2012, Yew Chuan Ong wrote:Thanks.One question, it is normal to see packet with size greater than 668 bytes? Is it the only indicator? On Mon, Mar 26, 2012 at 5:53 AM, rmkml <rmkml () yahoo fr> wrote: Hi, Your revision on this rule are correct, but you don't have flowbits on this rule: strange ? Please add this flowbits: flowbits:isset,qualcom.worldmail.ok; Regards Rmkml On Mon, 26 Mar 2012, Yew Chuan Ong wrote: Hye guys, I experienced lots of FPs with this sig - IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow. alert tcp $EXTERNAL_NET any -> $HOME_NET 143 (msg:"IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow"; flow:established,to_server; dsize:>668; metadata:policy balanced-ips drop, policy security-ips drop, service imap; refer ence:bugtraq,15980; reference:cve,2005-4267; classtype:attempted-admin; sid:1732 8; rev:1;) When I checked on the payloads, these are just normal email contents (not suspicious). I am wondering why the packet size is more than 668 bytes if it is not a real buffer overflow attempt. Any ideas? Thanks. Regards Yew Chuan
------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Snort-sigs mailing list Snort-sigs () lists sourceforge net https://lists.sourceforge.net/lists/listinfo/snort-sigs http://www.snort.org Please visit http://blog.snort.org for the latest news about Snort!
Current thread:
- IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow Yew Chuan Ong (Mar 25)
- Re: IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow rmkml (Mar 25)
- Re: IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow Yew Chuan Ong (Mar 25)
- Re: IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow rmkml (Mar 25)
- Re: IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow Joel Esler (Mar 25)
- Re: IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow Yew Chuan Ong (Mar 25)
- Re: IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow rmkml (Mar 25)
- Re: IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow Joel Esler (Mar 25)