Fast-pattern matcher does not honor ignore_data in the SMTP Preprocessor

[Joshua Kinard <kumba () gentoo org>]

Hi snort-devel,

I discovered a bug between the SMTP preprocessor and the fast_pattern
matcher when 'ignore_data' is turned on.  The issue stems from using a a
rule that has only a single content match with a pattern found only in the
e-mail body.  It seems that the fast-pattern matcher will find this pattern
in the overall packet and flag an event before the SMTP preprocessor has a
chance to fully normalize/decode the packet and apply the 'ignore_data' option.

I've attached an SMTP example session from twin Postfix MTAs running on a
Linux VM (over IANA reserved IPs on loopback, all local).  The sender is
"jack" from host "formenos.aman.arda" to "jill" at "tirion.aman.arda" (props
to anyone who gets the references).  The message body uses text generated
from the great Lorem Ipsum generator.  The file attachment is 768K of
/dev/urandom data to simulate a bog-standard SMTP session of message + MIME
attachment.

This is my sample SMTP Preprocessor config on snort-2.9.2.  Assume I have
the other preprocessors set to sane defaults:

preprocessor smtp:                  \
        normalize all               \
        inspection_type stateful    \
        ports { 25 587 }            \
        ignore_data                 \
        ignore_tls_data             \
        no_alerts                   \
        b64_decode_depth 0          \
        max_mime_mem 2097152


Given the above, this rule below WILL alert on the specified pattern (found
in the third Lorem Ipsum paragraph, last sentence), regardless of the
'ignore_data' directive:

alert tcp any any -> any 25 (                    \
        msg:"Lorem Ipsum?";                      \
        flow:established,to_server;              \
        content:"sollicitudin"; nocase;          \
        sid:42000009; rev:1; priority:1;         \
        classtype:bad-unknown;                   \
)

This is because the fast-pattern matcher finds "sollicitudin" in the
unreassembled packets.  I believe the SMTP preprocessor has some done kind
of processing by this point (I stepped through the code using gdb/ddd, and
the alert happens after the 8th TCP packet), but I guess a check somewhere
misses or fast-pattern simply doesn't handle the 'ignore_data' directive
properly.


A workaround I found was to short-circuit the fast-pattern matcher with a
content match you ALWAYS expect to be in an SMTP packet, like "Received:":

alert tcp any any -> any 25 (                    \
        msg:"Lorem Ipsum?";                      \
        flow:established,to_server;              \
        content:"Received|3a|"; fast_pattern;    \
        content:"sollicitudin"; nocase;          \
        sid:42000009; rev:1; priority:1;         \
        classtype:bad-unknown;                   \
)

With this, we short-circuit fast-pattern because it will find "Received:",
then the SMTP preprocessor does what it does, and the second content match
fails as expected because we want to ignore the DATA portion of the e-mail.

It's a hack, though, and you're giving up performance by the short-circuit.
 I honestly don't know a good way around this with the current design of the
SMTP preprocessor.  Other dynamic preprocessors, like SIP, DCE, the new GTP
ones, all provide functions to tell the engine where to look.  My guess is
an equivalent 'smtp_header' and 'smtp_body' set of rule options might be
needed (while 'file_data' continues to point at decoded MIME data), so that
the fast-pattern matcher can be pointed to the appropriate decode buffer and
not generate potential false positives.

Thoughts?

-- 
Joshua Kinard
Gentoo/MIPS
kumba () gentoo org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Attachment: smtp-lorem.pcap.bz2
Description:

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!