CVE-2022-32296: The Linux kernel before 5.17.9 allows TCP servers to identify clients by observing what source ports are used. (5th June 2022)

Preface: Move the TCP hashtable functions/structs to inet_hashtables.[ch] , it was happened 17 years ago.
On April 27, 2022, in an unpublished paper, report that clients can be accurately identified by forcing them to issue 40 times more connections than the number of entries in table_perturb[ ] Table, indexed by hash-joined tuples.
The current 2^8 setup allows them to perform this attack using only 10k connections, which is not hard to do in seconds.

Background: TCP – dynamically allocate the perturb table used by source ports. The kernel keeps the INET socket in a hash table so that the lookup operation is reasonably fast .

The vulnerability will be triggered under below circumstances.
Stochastic Fair Queuing: This queuing mechanism is based on fair queuing algorithm and proposed by John Nagle in 1987. Because it is impractical to have one queue for each conversation SFQ uses a hashing algorithm which divides the traffic over a limited number of queues. It is not so efficient than other queues mechanisms but it also requires less calculation while being almost perfectly fair. It is called “Stochastic” due to the reason that it does not actually assign a queue for every session; it has an algorithm which divides traffic over a restricted number of queues using a hashing algorithm. SFQ assigns a pretty large number of FIFO queues.

Ref: Stochastic Fairness Queueing is a classless queueing discipline available for traffic control with the tc(8) command. Example: man sfq

Vulnerability details: The Linux kernel before 5.17.9 allows TCP servers to identify clients by observing what source ports are used.

RFC 6056 3.3.4. Algorithm 4: Double-Hash Port Selection Algorithm
tcp: dynamically allocate the perturb table used by source ports. Note that we use 32bit integers (vs RFC ‘short integers’) because 2^16 is not a multiple of num_ephemeral and this property might be used by clever attacker.

Remedy: The solution is increasing the perturb table from 2^8 to 2^16 so that the same precision now requires 2.6M connections, which is more difficult in this time frame and harder to hide as a background activity. The impact is that the table now uses 256 kB instead of 1 kB, which could mostly affect devices making frequent outgoing connections. However such components usually target a small set of destinations (load balancers, database clients, perf assessment tools), and in practice only a few entries will be visited. Please refer to the link for details – https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4c2c8f03a5ab7cb04ec64724d7d176d00bcc91e5

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.