[Snort-sigs] IMAP Qualcomm WorldMail IMAP Literal Token Parsing Buffer Overflow
jesler at ...435...
Sun Mar 25 18:24:44 EDT 2012
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.
Senior Research Engineer, VRT
OpenSource Community Manager
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)
> 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 at ...174...> wrote:
>> 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;
>> 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?
>> Yew Chuan
More information about the Snort-sigs