Re: Snort exploits

[Chris Green <cmg () sourcefire com>]

I've just made Snort 1.8.7beta1 available at 
http://www.snort.org/dl/beta/snort-1.8.7beta1.tar.gz.

This should correct the issues that fragroute induces. 

I want to thank Andrea Barisani, Joe McAlerney, and Peter Johnson for
feedback on on the commits I've done over the past few days.  I'm also
glad Dug Song wrote fragroute as I'd been talking to Andrea about the
fragmentation attacks I'd like to see in ftester

One of the problems snort was having is with getting fragments out of
order on the network and then sending them through the detection
engine.  We still do that but also alert on overlapping fragments.

TTL Limits have been added to both frag2 and pointed out in stream4 to
be used in conjunction with min_ttl options.

Here my post to the snort user lists from Monday:

I just committed a lot of changes today to snort's HEAD branch in CVS
to deal with the test cases iterated in fragroute.

To get the full benefit of these changes:

preprocessor frag2: detect_state_problems
processessor stream4: detect_state_problems

If you find a new set of options that evade snort, drop me a line and
I'll work to fix and/or detect them and give you full credit.

The bugtraq post was the first I'd seen the README.snort so let me
just say that I spent a lot of Thursday superlate-> Today thinking
about the problems while trying to get work done.

Anyway, fragroute is a neat tool and does a lot of the stuff that has
been on the todo list to check.  Ahh only hours in the day.

> 1. older TCP retransmission chaff (snort's TCP segment reassembly
>    seems to always favor newer data, even for properlby sequenced
>    received data):
>
>       tcp_seg 1
>       tcp_chaff rexmit
>       order random


Should be fixed and if we see retransmissions of older data that
differs from what we already have, we generate an alert and throw away
the packet

> 2. forward TCP segmentation overlap, favoring newer data (both Windows
>    and Unix operate this way, in contrast to Ptacek and Newsham's
>    results):
>
>       tcp_seg 1 new

Fixed and generates alerts on packets that are part of a stream that
has already been reassembled.

> 3. chaff TCP segments with older TCP timestamp options forcing PAWS
>    elimination:
>
>       tcp_seg 1
>       tcp_chaff paws
>       order random

This should be relooked at but after making the first two changes,
this one was picked up very loudly.

> 4. older IP fragment duplicates (snort's IP fragment reassembly seems
>    to always favor newer data, even for properly sequenced received
>    data):
>
>       ip_frag 8
>       ip_chaff dup
>       order random

Alert on frags with option data and suck them all away.

Philosophical question:  Should we ignore frags we didn't see the
first fragment of?

[ Answered later:  We cope with out of order fragments but will alert
on a fragment we've recieved multiple times ]

> 5. IP duplicate fragment chaff with bad options:
>
>       ip_frag 8
>       ip_chaff opt
>       order random

We alert on ip fragments with ip options.

> 6. either TCP or IP chaffing with short TTLs (that expire before
>    reaching the end host, but pass by the monitor):
>
>       ip_frag 8
>       ip_ttl 11
>       ip_chaff 10
>       order random
>
>       tcp_seg 1
>       ip_ttl 11
>       tcp_chaff 10
>       order random

TCP stream stuff already had the min_ttl option to detect this attack
so that it will throw away anything underneath that.

I added this option to frag2

Also, there is a ttl_limit option to both.  Basically, this will alert
on anything that is different by more than a certain limit

The default is 5 picked off the cuff.  Know of any papers that measure
the avg and std deviation of TTLs on normal internet traffic across a
large sample and I'll be your buddy.

-- 
Chris Green <cmg () sourcefire com>
"Yeah, but you're taking the universe out of context."