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.

Attachment: pgpmZzQnCUzPi.pgp
Description: PGP signature

Relevant Pages

  • TCPIP sequence number question
    ... How will the receiver behave upon receiving the packet with sequence ... and sending NAK to the sender? ...
    (comp.os.vms)
  • RE: IP Session Hijacking And Spoofing
    ... can use B as the bogus source address. ... A sends a SYN packet to T with B's address as the source to open a TCP ... Any sequence number will work in this packet. ... IP Session Hijacking And Spoofing ...
    (Security-Basics)
  • Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)
    ... >> FreeBSD host is sending a FIN to close an established connection, ... >> the peer host adding the window size advertised in the FIN packet to the ... >> sequence number acknowledged in the FIN packet, and using the sum as the ...
    (FreeBSD-Security)
  • Re: TCPIP sequence number question
    ... How will the receiver behave upon receiving the packet with sequence ... Since TCP uses a sliding window, a lot of data can be outstanding at the time of a retransmission. ... And this is normally all regulated by the amount of retransmissions you get. ...
    (comp.os.vms)
  • Re: tcp vulnerability? havent seen anything on it here...
    ... >> windows, the propability of guessing the right sequence number is not ... sending a corrective "ACK" packet back. ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)