Vuln Dev
TCP segments reordering and covert channels May 05 2007 03:57PM
Kototama (kototamo gmail com) (1 replies)
Re: TCP segments reordering and covert channels May 07 2007 05:40PM
Valdis Kletnieks vt edu (1 replies)
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:


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
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001


[ reply ]
Re: TCP segments reordering and covert channels May 07 2007 09:35PM
Kototama (kototamo gmail com)


Privacy Statement
Copyright 2010, SecurityFocus