linux-kernel - Re: PROBLEM: DoS Attack on Fragment Cache

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]

Date:   Sat, 17 Apr 2021 21:30:07 -0400
From:   Matt Corallo <netdev-list@...tcorallo.com>
To:     Willy Tarreau <w@....eu>, Keyu Man <kman001@....edu>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        David Ahern <dsahern@...il.com>,
        Florian Westphal <fw@...len.de>, davem@...emloft.net,
        yoshfuji@...ux-ipv6.org, dsahern@...nel.org,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Zhiyun Qian <zhiyunq@...ucr.edu>
Subject: Re: PROBLEM: DoS Attack on Fragment Cache

See-also "[PATCH] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s" (and the two resends of it) - given 
the size of the default cache (4MB) and the time that it takes before we flush the cache (30 seconds) you only need 
about 1Mbps of fragments to hit this issue. While DoS attacks are concerning, its also incredibly practical (and I do) 
hit this issue in normal non-adversarial conditions.

Matt

On 4/17/21 03:50, Willy Tarreau wrote:
> On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote:
>> How about at least allow the existing queue to finish? Currently a tiny new
>> fragment would potentially invalid all previous fragments by letting them
>> timeout without allowing the fragments to come in to finish the assembly.
> 
> Because this is exactly the principle of how attacks are built: reserve
> resources claiming that you'll send everything so that others can't make
> use of the resources that are reserved to you. The best solution precisely
> is *not* to wait for anyone to finish, hence *not* to reserve valuable
> resources that are unusuable by others.
> 
> Willy
>