Re: Ambiguities in TCP/IP - firewall bypassing

["Alan DeKok" <aland () ox org>]

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.

  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.

> 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.

> 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.