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] [day] [month] [year] [list]

Message-Id: 
 <172504323041.2682525.16725338216073545525.git-patchwork-notify@kernel.org>
Date: Fri, 30 Aug 2024 18:40:30 +0000
From: patchwork-bot+netdevbpf@...nel.org
To: Eric Dumazet <edumazet@...gle.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
 dsahern@...nel.org, w@....eu, keyu.man@...il.ucr.edu, 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

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@...nel.org>:

On Thu, 29 Aug 2024 14:46:38 +0000 you 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
> ...
> 
> [...]

Here is the summary with links:
  - [v2,net-next,1/3] icmp: change the order of rate limits
    https://git.kernel.org/netdev/net-next/c/8c2bd38b95f7
  - [v2,net-next,2/3] icmp: move icmp_global.credit and icmp_global.stamp to per netns storage
    https://git.kernel.org/netdev/net-next/c/b056b4cd9178
  - [v2,net-next,3/3] icmp: icmp_msgs_per_sec and icmp_msgs_burst sysctls become per netns
    https://git.kernel.org/netdev/net-next/c/f17bf505ff89

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html