Vulnerability Development mailing list archives
Re: TCP segments reordering and covert channels
From: Valdis.Kletnieks () vt edu
Date: Mon, 07 May 2007 13:40:23 -0400
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.
Attachment:
_bin
Description:
Current thread:
- TCP segments reordering and covert channels Kototama (May 05)
- Re: TCP segments reordering and covert channels Valdis . Kletnieks (May 07)
- Re: TCP segments reordering and covert channels Kototama (May 07)
- Re: TCP segments reordering and covert channels Valdis . Kletnieks (May 07)