Re: stream reassemble and dsize

[Martin Roesch <roesch () sourcefire com>]

This is happening because stream4 flushes the stream before it can
accumulate that many bytes.  Stream4 flushes accumulated packets through the
detection engine by accumulating some number of bytes of application layer
data and then flushing when it hits the current flush point.  This is
because we haven't come up with a good method of tracking when the data gets
sent to the application or buffering for different application layer
protocols safely (yet).

Anyway, to solve your problem you need to make an edit to spp_stream4.c
around line 139 (version 1.9) to the following code:

static u_int8_t flush_points[FCOUNT] = { 128, 217, 189, 130, 240, 221, 134,
129,
                                         250, 232, 141, 131, 144, 177, 201,
130,
                                         230, 190, 177, 142, 130, 200, 173,
129,
                                         250, 244, 174, 151, 201, 190, 180,
198,
                                         220, 201, 142, 185, 219, 129, 194,
140,
                                         145, 191, 197, 183, 199, 220, 231,
245,
                                         233, 135, 143, 158, 174, 194, 200,
180,
                                         201, 142, 153, 187, 173, 199, 143,
201 };

These values reflect how many bytes will be accumulated before flushing on a
given stream and we walk the array to provide pseudo-randomness and
unpredictability to Snort's flushing behavior.  All you have to do is set
the sizes to be larger than the largest dsize in your rules set and it
should work fine (in theory).  In this particular case, putting a '1' in
front of all of these numbers would solve the problem.

We're working on a better method of flushing based on the protocol, but
we're not quite there yet...

     -Marty



On 10/1/02 4:38 AM, "Holger.Woehle () arcor net" <Holger.Woehle () arcor net>
wrote:

> Hello,
> i have a question about stream reassembling and dsize:
> Am i right that dsize only looks in the current packet not in the whole
> reassembled stream ?
> Why i ask:
> There is a exploit in an older apache called "Authorization:Basic" but this
> problem belongs to all attacks dealing
> with such buffer overflows like "to long url" "to long POST" a.s.o .
>
> Sample attack:
>
> #!/bin/sh
> echo -n "GET / HTTP/1.0"
> echo -n $'\n'"Authorization: Basic"
> count=0
> fillin=2048
> while [ "$count" -lt $fillin ]
> do
>    echo -n "X"
>    let "count+=1"
> done
> echo -n $'\r'$'\n'$'\r'$'\n'
>
> piping this to netcat, snort recognises the attack with the standart rule in
> web-misc.rules . This belongs to snort-1.8 and snort-1.9 .
> Now the attacker sets his ethernet mtu to 100 (ifconfig eth0 mtu 100) and
> starts
> the attack a second time.
> Now snort, neither 1.8 nor 1.9 (the rules handling differs. See A+ against the
> flow:established keywords) detects the scan.
> snort1.8 rule : alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
> (msg:"WEB-MISC long basic authorization string"; flags:A+;
> content:"Authorization\: Basic "; nocase; dsize:>1000;
> classtype:attempted-dos;
> reference:bugtraq,3230; sid:1260;  rev:5;)
> snort1.9 rule : alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
> (msg:"WEB-MISC long basic authorization string"; flow:to_server,established;
> content:"Authorization\: Basic "; nocase; dsize:>1000;
> classtype:attempted-dos;
> reference:bugtraq,3230; sid:1260;  rev:5;)
> I think this is why dsize only recognizes packets with dsize under 100 in that
> case .
> If a set up the mtu to 1000 both snorts detect the scan.
> I screwed a little with stream4 parameters but nothing helps.
> How can i detect such an attack ?
>
> with regards
> Holger
>
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: DEDICATED SERVERS only $89!
> Linux or FreeBSD, FREE setup, FAST network. Get your own server
> today at http://www.ServePath.com/indexfm.htm
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users

-- 
Martin Roesch - Founder/CTO Sourcefire Inc. - (410) 290-1616
Sourcefire: Professional Snort Sensor and Management Console appliances
roesch () sourcefire com - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org



-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users