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
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.
Re: Ambiguities in TCP/IP - firewall bypassing Florian Weimer (Oct 19)