Today I read that a flaw in a recent TCP specification leads to the injection of malicious content between the two communicating parties. How does the attack vector work?

I have also read a post in which the person writes randomizing the value in /proc/sys/net/ipv4/tcp_challenge_ack_limit can help in mitigating the attack. Is it true?

Link to the paper that explains the attack: 'Off-Path TCP Exploits: Global Rate Limit Considered Dangerous'. Please note this is not about off-path TCP sequence inference attacks. Read the paper.


1 Answer 1


... leads to the injection

The flaw does not lead to the injection but it allows an attacker to inject data. I.e no inadvertently data corruption but a targeted modification by an attacker.

How does the attack vector work?

Since you've referenced the paper I would expect that you've read it. Which parts you did not understand exactly? But to summarize it a bit:

  • The hard part of taking over a TCP connection is to guess the source port of the client and the current sequence number
  • The global rate limit for sending Challenge ACK's (100/s in Linux) introduced together with Challenge ACK (RFC5961) makes it possible in the first step to guess a source port used by the clients connection and in the next step to guess the sequence number. The main idea is to open a connection to the server and send with the source of the attacker as much RST packets with the wrong sequence mixed with a few spoofed packets. By counting how much Challenge ACK get returned to the attacker and by knowing the rate limit one can infer how much of the spoofed packets resulted in a Challenge ACK to the spoofed client and thus how many of the guesses where correct. This way can can quickly narrow down which values of port and sequence are correct. This attack can be done within a few seconds.
  • And of course the attacker need to be able to spoof the IP address of the client which is not true in all environments. It might be possible in local networks (depending on the security measures) but ISP will often block IP spoofing when done from the usual DSL/cable/mobile accounts.

But to really understand the attack you need to understand what Challenge ACK's are used (defend against off-path TCP RST) and how they work. Thus it might be useful to read the RFC 5961 too.

randomizing the value in /proc/sys/net/ipv4/tcp_challenge_ack_limit .. Is it true?

Setting it to a random value and keeping it there will probably not help because the attack can figure out the new static limit. Changing the value every few seconds will help to confuse the attack. Setting the value to a very large value will also make the attack impossible.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .