Vulnerability Development mailing list archives
Re: TCP segments reordering and covert channels
From: Kototama <kototamo () gmail com>
Date: Mon, 07 May 2007 23:35:35 +0200
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:Yes sure, you need some good administrative privileges to modify/patch the kernel or insert modules/drivers.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.
Yes I agree.
This can be mitigated with redundancies, CRC or error-correcting codes. For the bandwidth problem the thesis schema doesn't work with only two packets! You can do permutation of n packets and encode more information (your encoding alphabet is not a binary one in this case ).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.
I don't really care if the technique is a good one or not, I was just surprised that the author of the thesis considered it was not possible in TCP but only in IPsec.
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)