[Snort-devel] http_gunzip preprocessor

Eric Lauzon eric.lauzon at ...1967...
Thu Jan 5 11:49:02 EST 2006

> -----Original Message-----
> From: Frank Knobbe [mailto:frank at ...2134...] 
> Sent: 5 janvier 2006 14:33
> To: Eric Lauzon
> Cc: snort-devel at lists.sourceforge.net
> Subject: RE: [Snort-devel] http_gunzip preprocessor
> On Thu, 2006-01-05 at 14:12 -0500, Eric Lauzon wrote:
> > Case where you wont see anything:
> "Seeing" is not "detecting" ;)
> > Let say you have this webpage using uuencoded javascript to 
> redirect 
> > you to a server where there is the WMF, even if the initial 
> stream is 
> > "decompressed", where are you gonna be able to detect anything?
> While you could decode the javascript on the fly, you 
> wouldn't need to.
> You already have identified it as encoded javascript. Hell, 
> go as far as only detecting <script> and be done with it. You 
> can't do that when the page is gzip compressed in the HTTP 
> stream. There is no <script>. If it where uuencoded, you 
> could potentially match on that (due to the nature of the 
> algorithm), but you can't do that with zip/compress/deflate 
> unless you follow it from the beginning, which means decoding 
> on the fly.

I was taking about encoded html "document.write()", sorry i was no clear

> > One good example is :shellcode detection where after the birth of 
> > ADMmutate,ASCII shellcode encoding ,polymorphism , the only 
> real way 
> > to detect shellcode is to have host based IDS that monitor process 
> > memory, process structure and Instruction Pointer.
> Yet we had fnord.

fnord :) , so you can distinguish (valid obscured opcode and legit
opcode) from
any other bytes sent on the wire that could be equivalent in term of
value representation 
but completly harmless since what you detected will never get executed,
just by assuming execution over the wire? Sorry to break the illusion

> > The scope of should be writing a portion of code for a 
> specific case 
> > that just arised but has been exploited before why not 
> think about an 
> > http module that can use sub preprocessor on the http stream this 
> > could then lead toward stream anomaly / state detection.
> I'm sorry, I'm not able to follow your sentence structure 
> here. I *am* talking about a module that sits behind the 
> http_inspect thing and further normalizes the stream.

I am suggesting a complete http inspection/state framework , not a
based on whats existing rigt now.

> > Im still convinced that most of the people wont read and will then 
> > complain, thee other half will try but will encounter huge 
> > performances issues.
> How can you say that without even tried it? Please go do some 
> analysis of the compressed traffic actually present.

Why try when there is no benefits. If someone want it let them do it
im just trying to bring my point where feature dosen't mean usefull.

The idea is good but i dont see why we should uncompress when we can't
even evaluate
client/server http applicative state. So my choice of quick reliability
would be
an applicative proxy but if you prefer a snort preprocessor, thats your

> Man, I'm sorry dude, I have to put on my plonker list. If you 
> want to discuss technical merits in earnest (which it doesn't 
> look like), please use a different address.

Is that all you can say? I am sorry but im still gonna refuse the
to confront. My opinion in this e-mail represent Eric Lauzon the
not whom i am working for and not what other employees of here might
have done or said.

Keep that in mind and if you want to reply personaly so we can put this
garbage out of here
there is no problems, but dont claim to be sorry afterward.


More information about the Snort-devel mailing list