mailing list archives
Re: Ambiguities in TCP/IP - firewall bypassing
From: Benjamin Krueger <benjamin () seattleFenix net>
Date: Fri, 18 Oct 2002 13:55:15 -0700
* 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
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
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
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.
Send mail w/ subject 'send public key' or query for (0x251A4B18)
Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18
Re: Ambiguities in TCP/IP - firewall bypassing Florian Weimer (Oct 19)