[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <52098fa9-2feb-08ae-c24f-1e696076c3b9@gmail.com>
Date: Fri, 16 Apr 2021 17:31:38 -0700
From: David Ahern <dsahern@...il.com>
To: Keyu Man <kman001@....edu>,
"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>,
Eric Dumazet <edumazet@...gle.com>
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: Re: PROBLEM: DoS Attack on Fragment Cache
[ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
On 4/16/21 3:58 PM, Keyu Man 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
>
Powered by blists - more mailing lists