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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240829201100.GY1368797@kernel.org>
Date: Thu, 29 Aug 2024 21:11:00 +0100
From: Simon Horman <horms@...nel.org>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	David Ahern <dsahern@...nel.org>, Willy Tarreau <w@....eu>,
	Keyu Man <keyu.man@...il.ucr.edu>,
	Jesper Dangaard Brouer <hawk@...nel.org>, netdev@...r.kernel.org,
	eric.dumazet@...il.com
Subject: Re: [PATCH v2 net-next 0/3]  icmp: avoid possible side-channels
 attacks

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.