Re: [PATCH v2 net-next 0/3] icmp: avoid possible side-channels attacks

[Simon Horman <horms@kernel.org>]

On Thu, Aug 29, 2024 at 02:46:38PM +0000, Eric Dumazet wrote:
> Keyu Man reminded us that linux ICMP rate limiting was still allowing
> side-channels attacks.
> 
> Quoting the fine document [1]:
> 
> 4.4 Private Source Port Scan Method
> ...
>  We can then use the same global ICMP rate limit as a side
>  channel to infer if such an ICMP message has been triggered. At
>  first glance, this method can work but at a low speed of one port
>  per second, due to the per-IP rate limit on ICMP messages.
>  Surprisingly, after we analyze the source code of the ICMP rate
>  limit implementation, we find that the global rate limit is checked
>  prior to the per-IP rate limit. This means that even if the per-IP
>  rate limit may eventually determine that no ICMP reply should be
>  sent, a packet is still subjected to the global rate limit check and one
>  token is deducted. Ironically, such a decision is consciously made
>  by Linux developers to avoid invoking the expensive check of the
>  per-IP rate limit [ 22], involving a search process to locate the per-IP
>  data structure.
>  This effectively means that the per-IP rate limit can be disre-
>  garded for the purpose of our side channel based scan, as it only
>  determines if the final ICMP reply is generated but has nothing to
>  do with the global rate limit counter decrement. As a result, we can
>  continue to use roughly the same scan method as efficient as before,
>  achieving 1,000 ports per second
> ...
> 
> This series :
> 
> 1) Changes the order of the two rate limiters to fix the issue.
> 
> 2-3) Make the 'host-wide' rate limiter a per-netns one.
> 
> [1]
> Link: https://dl.acm.org/doi/pdf/10.1145/3372297.3417280
> 
> v2: added kerneldoc changes for icmp_global_allow() (Simon)

Thanks for the update; confirming that part looks good to me.