[Snort-devel] http_gunzip preprocessor

Frank Knobbe frank at ...2134...
Wed Jan 4 15:03:04 EST 2006

On Tue, 2006-01-03 at 14:06 -0500, Marc Norton wrote:
> So if you can better detail your requirements for this feature we might 
> be able to respond more intelligently.

Yup, I have a few thoughts and some ideas that could aide development
(from a 10mile high view, not decode->structure.level).

The goal is not to gunzip the whole data stream. It should be sufficient
to unzip up to a certain amount of bytes. My first thought was, unzip a
a certain number, counting from input, but that would leave it
vulnerable to zip-bombs. Instead, unzip up until a certain amount of
bytes has been produced, not more. Make it a var like http_unzip_depth
and set a default to 300 or 500 (but leave it adjustable).

The preproc should also support compress and deflate of course.

The purpose is to unzip just enough bytes of content to create rules for
known bad content. For example, there is a frightening amount of gzipped
Javascript being included from multiple sites. Some trustworthy, some
not. What's in that compresses Javascript? We don't know, can't alert on
it. Having the first 300-500 bytes available would allow us to create
sigs for hostile, compressed content. In case of the WMF exploit, I
would be content to just alert on the WMF header and not even bother to
check the rest.

I would take the packet from the stream, keep the header intact, and
replace the gzipped stuff with <http_unzip_depth> amount of bytes. That
stream is already limited by flow_depth so I would just override what's
there with the decoded stuff, and ignore the rest. If someone wants to
capture more, he will have to increase both _depth vars to higher level.

While the WMF issue sparked this, the processor is not designed just for
it as some people seem to believe. Instead, my main interest lies on
those compressed script files that can hose your machine, and you
currently can not detect.

Other people mentioned that it is silly to completely unzip the whole
stream, citing performance issues. Also odd arguments like SSL and
base64 already shrouding content so why bother. As I said, the goal
should not be to unroll the whole thing, but just enough to get
intelligent data. That shouldn't have too much of a performance impact.

SSL can be detected and/or prevented on a protocol level, being it on
port 443 or something else. gzipped HTML content is different in that it
rides on normal, plaintext HTTP data. You can inspect other HTTP data in
that session, even inspect the header of gzipped stuff. Being able to
see those and since you get no alerts on them, you could enjoy that cozy
feeling of 'ignorance is bliss'. Here you have a clear-text protocol and
data you can inspect which might let you to believe the session is
harmless when in fact it packs a punch in that little nugget you can't

I think unrolling 500 bytes of gzipped stuff should certainly be doable
without causing a performance hit. The more an IDS can inspect, the more
justification it has for its existence. Some of the comments here border
on why bother with IDS in the in first place if everything is encrypted.
SSL is harder to intercept and decode (client->Your_Server_Only anyway,
not your_client->outside_server). But gzip provides no challenge at all.
It is, after all, not encryption. So if we could inspect that with a
negligible performance hit... why not? I'm sure some other IDS can do
that so I think Snort (if it wants to remain viable) should too. And if
not, if you are the first IDS that can pull this off in a painless
manner... well... that just one more golden bullet point on the
marketing slicks.

It would truly be a great feature imho.


It is said that the Internet is a public utility. As such, it is best
compared to a sewer. A big, fat pipe with a bunch of crap sloshing
against your ports.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20060104/e368527b/attachment.sig>

More information about the Snort-devel mailing list