hackers.mu

88 Avenue De Plevitz Roches Brunes Rose Hill 71259 +230 59762817 logan@hackers.mu

Internet TCP Maintenance and Minor Extensions The functionality provided by the TCP ACK throttling mechanism can be exploited as a side channel vulnerablity to terminate connections between two arbitrary hosts and inject data in the communication stream.

defines the challenge ACK response mechanism as a technique to mitigate against blind in-window attacks. Specifically, an ACK packet is sent in response to an incoming segment with a SYN bit to confirm that the preceding connection was lost. Another case is sending an ACK packet if the RST packet is received but the sequence number does not match the next expected sequence number. Lastly, to prevent data injection, the range of valid ACK value is reduced for better strictness, so the likelihood of old ACK values and very new ACK values are discarded. In all of those cases, the ACK packet is referrered to as a "Challenge ACK" through the rest of this document. also introduces an ACK throttling mechanism to reduce possible wastage of CPU and bandwidth resources by limiting the number of challenge ACK that can be sent in a given interval. An attacker can leverage the Challenge ACK and the ACK throttling mechanism to abuse on the global ACK throttling rate-limit on a target host. Through a series of step, the attacker can send spoofed packets to the target host, affect the the global challenge ACK rate-limiter, Count the number of challenge ACK received, and finally compare that number with the target system limit. The attacker can then gather clues about: the existence of a 4-tuple connection, the next expected sequence number, and the expected ACK number. Based on the gathered information, the attacker can mount connection reset attacks and data injection attacks. Those attacks have been demonstrated to work in real-world constraints according to . Due to the seriousness of the threat, it is sufficient to deprecate the ACK throttling mechanism, as defined in . This document updates .

Challenge ACK in this document denotes the ACK packet sent in response to an segment whose RST bit is set and the sequence number does not fully match the next expected sequence value, but is within the current receive window as defined in . The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in .

An implementation is not required to implement an ACK throttling mechanism which is conservative as defined in section 7 of . However, if there is a concern about CPU or bandwidth usage, an implementation may have a per-socket ACK throttling mechanism which is independent. This makes it more difficult to abuse compared to having a single (global) ACK throttling mechanism. Additionally, an implementation may also introduce a randomized value to the interval defined in Section 7 of . This makes the attack defined in section 1 much more difficult.

It will take time to update all of the TCP implementations that fully implement the ACK throttling mechanism as described in . An operator can increase the value of the ACK throttling limit to the highest value possible to mitigate the risk of the vulnerabilities defined in section 1 of .

None of the proposed measured have an impact on IANA.

The purpose of this document is to deprecate a feature of TCP that has been shown to lead to security vulnerabilities. Specific examples of those vulnerabilities can be found in [!]. In particular, the ACK throttling mechanism leads to a side-channel vulnerability that can be leveraged for connection reset and data injection attacks. A description of this functionality can be found in section 1.