Re: TCP segments reordering and covert channels

On Sat, 05 May 2007 17:57:35 +0200, Kototama said:
> The author says that this technique is not applicable to IP or TCP
> because "the sequence number field and acknowledgement number field
> point to the number of octets of data and are not directly related to
> the packet number".

> Thus it seems that this technique is also available for TCP. We can
> guess the original order since sequence numbers are always increasing.

The *received* order is *not* guaranteed to be increasing. RFC793,
section 1.5 says:

  Reliability:
  
    The TCP must recover from data that is damaged, lost, duplicated, or
    delivered out of order by the internet communication system. This
    is achieved by assigning a sequence number to each octet
    transmitted, and requiring a positive acknowledgment (ACK) from the
    receiving TCP. If the ACK is not received within a timeout
    interval, the data is retransmitted. At the receiver, the sequence
    numbers are used to correctly order segments that may be received
    out of order and to eliminate duplicates. Damage is handled by
    adding a checksum to each segment transmitted, checking it at the
    receiver, and discarding damaged segments.

> I don't have the time yet to make a POC and I would like your advices.

OK.. let's say we encode a '0' as "2 segments in order A B" and a '1' as
"2 segments out of order B A". How do you distinguish between these cases:

1) packets intentionally crafted with out-of-order numbers (this raises its
own set of issues - namely you need enough access to craft and manage a TCP
connection, including sequence numbers).

2) If the destination is off the local subnet, a glitch (lost packet, routing
flap, load-balanced multiple links, etc) causes packet B to be received before
packet A (which shows up on retransmit, or a longer transmission path)? Keep
in mind that the TCP spec was specifically *designed* so that out-of-order
delivery is a "can happen" situation.

Between the fact that the covert data is encoded on something that's
not an invariant (namely, the order that packets arrive), and the fact that
you can only transmit 1 bit per packet, this doesn't look like a very practical
scheme.