Re: Ambiguities in TCP/IP - firewall bypassing

From: Alan DeKok (aland@ox.org)
Date: 10/18/02


From: "Alan DeKok" <aland@ox.org>
To: bugtraq@securityfocus.com
Date: Fri, 18 Oct 2002 17:06:23 -0400

Benjamin Krueger <benjamin@seattlefenix.net> wrote:
...
> > 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.
>
> 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.

  So... what should the packet be? As I said, the spec is ambiguous.
If you don't know what the packet is, you obviously don't know how to
treat it.

  Sure, the spec *says* to treat packets with the SYN flag in a
certain way. I'm not arguing with that. What I'm arguing with is the
concept that because the spec is MISSING text on what to do in other
situations, that we know what to do in those situations.

  The spec is silent on the use of ambiguous or contradictory flags
(SYN+FIN). So what happens when such a packet is received can only be
described as "implementation defined."

  This is not the way to have a secure, or inter-operable protocol.

> > 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.

  So SYN+URG is disallowed. But to me, that combination seems
reasonable. So my implementation may not inter-operate with yours.
At the least, we're making different assumptions, which leads to
security problems.

  As I said, the spec is ambiguous.

> 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.

  Well, at least I didn't say that.

> > 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).

  <g> I may believe otherwise. Who's to say what's compliant, if the
definition of "compliance" isn't written down anywhere?

  Alan DeKok.



Relevant Pages

  • Re: USB GetDescriptor(Configuration) Error?
    ... And I'm not sure how I developed my false assumption about needing to send a zero length packet if the transfer length falls on the packet length boundary, since quite obviously you are correct about the USB 2 spec, and the USB 1.1 spec contains the same description of the process. ... I am still curious, however, when I watch bus traffic with an analyzer, the initial enumeration does involve a zero length data packet before the host begins the status stage, whereas the request my driver places does not. ...
    (microsoft.public.development.device.drivers)
  • Re: Bogon IPs traffic only seen by netflow, confined within a VLAN only
    ... things were caused by "jabbering" transceivers that would start transmitting ... their packet sooner than the spec allowed, resulting in the first few bytes ...
    (Incidents)
  • Re: Redistribution of Hotfix KB943198
    ... to be still in progress, ... The language in the spec refers to an "endpoint", ... transfers a zero-length packet." ...
    (microsoft.public.development.device.drivers)
  • Ethernet packet size and QinQ standard?
    ... For 802.1Q tagging, the spec was changed to allow a max packet size ... I'm kind of surprized because some hardware does have the packet size ...
    (comp.dcom.lans.ethernet)
  • Re: Ambiguities in TCP/IP - firewall bypassing
    ... Even RFC 2525 (Known TCP ... Identify what the packet should be, ... > The TCP state machine diagram has labels naming the flags on ...
    (Bugtraq)