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]
Date:   Thu, 1 Apr 2021 21:43:16 +0200
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org
Subject: Re: Fw: [Bug 212515] New: DoS Attack on Fragment Cache



On 4/1/21 8:08 PM, Stephen Hemminger wrote:
> Initial discussion is that this bug is not easily addressable.
> Any fragmentation handler is subject to getting poisoned.
> 
> Begin forwarded message:
> 
> Date: Wed, 31 Mar 2021 22:39:12 +0000
> From: bugzilla-daemon@...zilla.kernel.org
> To: stephen@...workplumber.org
> Subject: [Bug 212515] New: DoS Attack on Fragment Cache
> 
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=212515
> 
>             Bug ID: 212515
>            Summary: DoS Attack on Fragment Cache
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 5.12.0-rc5
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IPV4
>           Assignee: stephen@...workplumber.org
>           Reporter: kman001@....edu
>         Regression: No
> 
> Hi,
> 
>     After the kernel receives an IPv4 fragment, it will try to fit it into a
> queue by calling function 
> 
>     struct inet_frag_queue *inet_frag_find(struct fqdir *fqdir, void *key) 
>     in
>     net/ipv4/inet_fragment.c. 
> 
>     However, this function will first check if the existing fragment memory
> exceeds the fqdir->high_thresh. If it exceeds, then drop the fragment
> regradless it belongs to a new queue or an existing queue. 
>     Chances are that an attacker can fill the cache with fragments that will
> never be assembled (i.e., only sends the first fragment with new IPIDs every
> time) to exceed the threshold so that all future incoming fragmented IPv4
> traffic would be blocked and dropped. Since there is GC machanism, the victim
> host has to wait for 30s when the fragments are expired to continue receive
> incoming fragments normally.
>     In pratice, given the 4MB fragment cache, the attacker only needs to send
> 1766 fragments to exhaust the cache and DoS the victim for 30s, whose cost is
> pretty low. Besides, IPv6 would also be affected since the issue resides in
> inet part.
>     This issue is introduced in commit 
> 648700f76b03b7e8149d13cc2bdb3355035258a9 (inet: frags: use rhashtables for
> reassembly units) which removes fqdir->low_thresh, which is used by GC worker.
> I would recommand to bring GC worker back to prevent the DoS attacks. 
> 
>     Thanks,
> Keyu Man
> 



Honestly I do not think we can fix anything.

IP defrag units can easily be flooded by attackers,
no strategy can guarantee that non malicious traffic can make it.

Whole point of 648700f76b03b was to allow admins to increase
storage for frags, increasing chances for frags to be reassembled.

Just say no to frags in general.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ