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.
