[Snort-devel] stream4 & Connection States

Evrim ULU evrim at ...1988...
Tue May 20 12:01:19 EDT 2003

Hash: SHA1


First post, so flames >> /dev/null.

Like most ppl, i was tracing spp_stream4.c (not after integer flow).
I've seen that, UpdateState is called before checking any th_seq, th_ack
or ttllimit. I really didn't get the idea, so please help me.

If i send a spoofed pack, i can brutely change the state of the stream.
I know, i know, TcpAction/StoreStreamPkt will alert if there is a tcp
state invasion, but who cares?, it's mostly disabled. Connection is not
dead and state is wrong. Below, i've just generated a scenario which
works in theory(as i've traced). I'm using snort 2.0.0rc2. This bug
maybe a duplicate, if so, discard it.

Consider a *legally* established stream. I send a spoofed FIN|ACK'ed
pack to server having same source/destination address & port to pass
Splay tree search(see GetSession(p)). Server goes to FIN_WAIT_1 and
client goes to CLOSE_WAIT. But, real server knows this packet does not
belong to stream and discards it(since i dunno th_seq number,
server/client is a linux2.4 for instance). Assume then, client legally
sends a data (which is normally only ACK flag on). Server then goes to
state FIN_WAIT_2 and client is again in CLOSE_WAIT state. Server then
will send a pack that he ack'ed the last sended data, since it's legal.
(This ack packet will change server's state to FIN_WAIT_2 which does not
make any change)

yeah, here is the interesting point. After this, if server state is
FIN_WAIT_2, and if client sends any pack which has only ACK flag (which
is the normal data transfer flag since stream is not dead), UpdateState
will only do the following 2 checks:

if (th_flags == (TH_FIN|TH_ACK) return ACTION_ACK_SERVER_DATA;
else if (th_flags == TH_FIN) return ACTION_ACK_SERVER_DATA;
else return ACTION_NOTHING;

Our client pack will return as ACTION_NOTHING which means the client
pack does not contain ANY DATA. In a more explanatory way, it tells
snort not to process CLIENT data as a part of the stream, as a result do
not evaluate any content matching rule.

Impact: I'm just sending exactly one sp00fed pack(which i don't need any
info about stream just sip,dip, dport, sport), it only generates
protocol evasion alerts(mostly disabled) in StoreStreamPkt(), and after
this point, any data sent by client is not processed by content matching

I might be wrong (none of the proposals above are checked in real
environment) but, before checking th_seq, ack, window, evaluating the
state is surely a *DESIGN MISTAKE*.

Thnx for reading.

Core Computer Security Group
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Snort-devel mailing list