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

Date:   Fri, 16 Apr 2021 16:09:52 -0700
From:   Keyu Man <kman001@....edu>
To:     "davem@...emloft.net" <davem@...emloft.net>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
        "dsahern@...nel.org" <dsahern@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Zhiyun Qian <zhiyunq@...ucr.edu>
Subject: PROBLEM: DoS Attack on Fragment Cache

Hi,

    My name is Keyu Man. We are a group of researchers from University
of California, Riverside. Zhiyun Qian is my advisor. We found the code
in processing IPv4/IPv6 fragments will potentially lead to DoS
Attacks. Specifically, after the latest 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 regardless whether 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 no GC mechanism, the victim host has to wait for 30s when the
fragments are expired to continue receiving incoming fragments
normally.
    In practice, 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, and GC worker
as well. We would kindly request to bring GC workers back to the
kernel to prevent the DoS attacks.

    Looking forward to hear from you

    Thanks,

Keyu Man


On Fri, Apr 16, 2021 at 3:58 PM Keyu Man <kman001@....edu> wrote:
>
> Hi,
>
>
>
>     My name is Keyu Man. We are a group of researchers from University of California, Riverside. Zhiyun Qian is my advisor. We found the code in processing IPv4/IPv6 fragments will potentially lead to DoS Attacks. Specifically, after the latest 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 regardless whether 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 no GC mechanism, the victim host has to wait for 30s when the fragments are expired to continue receive incoming fragments normally.
>
>     In practice, 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, and GC worker as well. We would gently request to bring GC worker back to the kernel to prevent the DoS attacks.
>
> Looking forward to hear from you
>
>
>
>     Thanks,
>
> Keyu Man