[27503] in bugtraq
Re: Ambiguities in TCP/IP - firewall bypassing
daemon@ATHENA.MIT.EDU (Alan DeKok)
Fri Oct 18 16:39:15 2002
From: "Alan DeKok" <aland@ox.org>
To: Paul Starzetz <paul@starzetz.de>
In-Reply-To: Your message of "Fri, 18 Oct 2002 16:46:55 +0200."
<3DB01EDF.5070004@starzetz.de>
Date: Fri, 18 Oct 2002 15:36:12 -0400
Message-Id: <E182cuq-0002HV-00@giles.striker.ottawa.on.ca>
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.
