Home page logo

bugtraq logo Bugtraq mailing list archives

Re: Ambiguities in TCP/IP - firewall bypassing
From: "Alan DeKok" <aland () ox org>
Date: Fri, 18 Oct 2002 15:36:12 -0400

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

  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

  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.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]