On Wed, Sep 08, 2004 at 10:28:00AM -0600, nnposter@users.sourceforge.net wrote:
Is the PCRE in 1930.4 really supposed to look this way? It seems
to me that it contains unnecessary groupings and unescaped
braces and the IMAP command is truncated.
alert tcp $EXTERNAL_NET any -> $HOME_NET 143
(msg:"IMAP auth literal overflow attempt"; flow:established,to_server;
content:" AUTH"; nocase;
pcre:"/({(?=\d+}[^\n]*?\sAUTH)|AUTH\s[^\n]*?{(?=\d+}))/smi";
byte_test:5,>,256,0,string,dec,relative;
reference:cve,1999-0005; classtype:misc-attack; sid:1930; rev:4;)
Yes.
AUTH != AUTHENTICATE.
IMAP2BIS supports AUTH, which supports the following syntax:
"{%d} AUTH\r\nAUTHDATAHERE\r\n"
or
"* AUTH {%d}\r\nAUTHDATAHERE\r\n"
Before explaining what the regexp does, we should go over what we are
concerned at looking for. We are concerned about the length argument
of the AUTH command. That is stored as a number, inside the "{}" of
an AUTH request. We use byte_test to do number value compares, so we
need to make sure our doeptr is set at the { for byte_test to work
appropriately.
I'll try and explain what the regexp does here. The pcre is really
two regexps combined, so lets look at the first half of the regexp.
{(?=\d+}[^\n]*?\sAUTH)
What does this regexp do?
Look for {, that is followed by \d+}[^\n]*?\sAUTH, but don't
include that in the match buffer. This is important for the
byte_test that happens after regexp, since we want to byte_test on
the value after the "{". You might ask, whats with the "[^\n]*?"?
Some imap servers support literal comments, things inside of "".
An example support command could be:
{234} "stuff" AUTH\r\nAUTHDATAHERE\r\n
As such, we skip over everything until the \sAUTH.
Ok, now lets go onto the other bits of the regexp.
AUTH\s[^\n]*?{(?=\d+})
What does this regexp do?
Look for AUTH\s followed by anything until {, then look for digits
followed by }, but don't include that in the match. Again, we are
using "[^\n]*?" to skip over potential comments, something like
this:
* AUTH "stuff" {234}\r\nAUTHDATAHERE\r\n
If a packet matched the first half of the regexp, our "matched"
portion would be:
{
If a packet matched the second half of the regexp, our "matched"
portion would be:
AUTH "stuff" {
In either case, the doeptr would be set to {, which would allow us to
byte_test the value inside the "{}".
So, was that clear as mud? (Oh, yes. The space in the content match
shouldn't be there. Don't bother submitting an evasion update email,
I'm already on it.)
Brian
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
