On Sep 8, 2004, at 6:39 PM, nnposter@users.sourceforge.net wrote:
Actually, excellent explanation; no mud so far. Great trick to use the
positive look-ahead patterns for re-positioning doeptr.
Thanks. It was one of those "pat myself on the back" moments when I
came up with that idea. I was kinda waiting in the wings for someone
to ask WTF I was thinking with that regexp so I could show it off. :P
I'm currently in the process of updating a number of rules to use the
same trick, since it can make for more accurate rules in some cases.
If you do not mind I have a few follow-up questions:
1. Is the original published exploit for BID 130 then wrong in using
"AUTHENTICATE"?
Nope. IMAP4 uses AUTHENTICATE. From what I can tell, only IMAP2BIS
supported AUTH. A long time ago, I had a few friends deploy rules that
looked for "AUTH" commands in IMAP on a few major backbounds. The only
AUTH commands we ever saw were people exploiting the vulnerability.
(Hell, and they were all using this exploit :
http://www.hackcoza.com/exploits/daemon/imapd/imap2bis.c)
2. Is there some intrinsic value in favoring /blah[^\n]*blah/smi over
/blah.*blah/mi?
Yep, readability for myself. That, and when I'm merging multiple
regexps to make a single "megarule" like the one that spawned this
rule, one regexp may expect . to match \n, while one may not. Since
I'm the primary person mucking with the regexps, making it easy for me
is my primary concern. :)
3. Perhaps nit-picking but... Would it not make sense to remove the
all-enclosing grouping to remove the cost of back-references and
escape the braces so that they do not get accidentally interpreted
if the surrounding expression changes?
I'd prefer to use (?:first|second) but my crappy parser for pcre can't
handle the ":". Oh well. As per escaping the braces, I guess I could
do that for added readability. Honestly, I like the way it looks now,
makes people think "WTF is he thinking? ... OH, ok, I get it.". :)
4. Are you coding rules against a specific libpcre version? In other
words,
are you mandating/expecting a specific libpcre feature baseline?
Nope. I try to make sure all of the regexps work with 3.2, as well as
4.2. 4.2 is over a year old, so I could probably start requiring 4.2
one of these days. We are not using any of the experimental features,
such as unicode or C callout functions yet, so its not that important.
BUT... you should upgrade if you can. There are a ton of bug fixes in
newer releases of pcre.
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
