Re: Ambiguities in TCP/IP - firewall bypassing

[Benjamin Krueger <benjamin () seattleFenix net>]

* Alan DeKok (aland () ox org) [021018 13:21]:
> Paul Starzetz <paul () starzetz de> wrote:
> > There are ambiguities in implementations of the TCP/IP suite for various 
> > operating systems.
>
>   What about the specifications?
>
>   In my (admittedly quick) readings of RFC 793 and RFC 1122, I don't
> see any text forbidding the use of other flags, in conjunction with
> SYN, when opening a new connection.  Even RFC 2525 (Known TCP
> Implementation Problems) doesn't appear to cover this issue.
>
>   RFC 1025 (TCP and IP bake-off) has the following text:
>
>       10 points for correctly being able to process a "Kamikaze"
>       packet (AKA nastygram, christmas tree packet, lamp test
>       segment, et al.).  That is, correctly handle a segment with
>       the maximum combination of features at once (e.g., a SYN URG
>       PUSH FIN segment with options and data).
>
>
>   But it doesn't define what it means by "correctly handle" such a
> packet.

  Identify what the packet should be, and treat it as such? If that is
the correct way to handle these packets, then these stacks are correct.

>   The TCP state machine diagram has labels naming the flags on
> transitions from 'listen' to 'syn received', but it's silent on the
> topic of which flags are NOT allowed.

  It does, however, consistantly refer to packets as "Syn" or "SynAck"
or "Fin" packets, suggesting that only a specific flag or combination
of flags should be used during the connection.

  One could also make a case for continuing to abide by the cardinal
rule "Be permissive in what you accept, and strict in what you send".
Tough call, but its difficult to justify describing stacks that are
permissive as "highly bogus" or "lazy" given that being permissive in 
what you accept is an established notion.

> > We believe that the flaws we have detected have a big impact on 
> > design of firewalls and packet filters since an improper implementation 
> > can easily lead to serious security problems.
>
>   I believe that all of the implementations you named are "compliant"
> with the ambiguous TCP specification.

Compliant by the letter, if questionably in spirit. I'm not aware of any
tcp client systems that would send SynFin in the real world, so a stack
that responded with RST could arguably be "more" correct (for example).

> > The ambiguities can be used to bypass/tunnel firewalls filtering TCP 
> > packets according to the TCP flags set. Especially stateless firewalls 
> > simply comparing the flags field with some expected value(s) to 
> > distinguish between synchronization packets and packet from an already 
> > open connection can be easily bypassed just by sending a bogus 
> > synchronization packet to a listening port.
>
>   Then the firewall is too permissive.  The people who designed it
> either did not understand TCP, or knowingly made the rules too
> permissive, or were stuck with a marketing department which required
> this insecure behaviour. :(
>
> > The currently deployed TCP stacks seem to be highly bogus and lazy
> > implemented.
>
>   One method around that would be to have a complete TCP
> specification via finite state machines.  Such a state machine can
> then be analyzed, and proven to be correct under whatever definitions
> of "correct" you choose.
>
>   I believe this has been tried, but I don't know that anyone has been
> successful at it yet.  Even the normal "state machine" diagram used to
> explain TCP is very high-level, and misses many of the implementation
> details and requirements.
>
>   Alan DeKok.

-- 
Benjamin Krueger
----------------------------------------------------------------
Send mail w/ subject 'send public key' or query for (0x251A4B18)
Fingerprint = A642 F299 C1C1 C828 F186  A851 CFF0 7711 251A 4B18