From owner-freebsd-security Sat Mar 17 3: 6: 2 2001 Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 6DF1237B718 for ; Sat, 17 Mar 2001 03:05:58 -0800 (PST) (envelope-from roam@ringworld.nanolink.com) Received: (qmail 22363 invoked by uid 1000); 17 Mar 2001 11:05:15 -0000 Date: Sat, 17 Mar 2001 13:05:15 +0200 From: Peter Pentchev To: Matt Dillon Cc: Paul Herman , "ho-sang, yoon" , freebsd-security@FreeBSD.ORG, Kris Kennaway Subject: Re: Multiple vendors FTP denial of service (fwd) Message-ID: <20010317130515.A20798@ringworld.oblivion.bg> Mail-Followup-To: Matt Dillon , Paul Herman , "ho-sang, yoon" , freebsd-security@FreeBSD.ORG, Kris Kennaway References: <200103162116.f2GLGm674347@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103162116.f2GLGm674347@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Mar 16, 2001 at 01:16:48PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Mar 16, 2001 at 01:16:48PM -0800, Matt Dillon wrote: > :> > :> I don't think that the resourse limit does effect on this matter. > :> Or, am I something wrong? > : > :I, too, had thought that "max memory size" (or RLIMIT_RSS) would have > :kicked in, but it didn't. However, what does work is setting the > :"datasize" (RLIMIT_DATA), which will kill ftpd when "SIZE" exceeds > :RLIMIT_DATA. > : > :Now I'm wondering about RLIMIT_RSS, i.e. the amount of memory in core. > :I'm perusing through sys/vm now... > : > :-Paul. > > The 'datasize' limit (RLIMIT_DATA) only applies to malloc(). It does > not apply to mmap(). This is a known issue. In anycase, it would depend > on what ftpd uses. I would expect ftpd to use malloc() for internal > structures and perhaps mmap() (or sendfile()) when reading a file. > > The 'memoryuse' limit (RLIMIT_RSS) only applies to the process'es > in-core size. If the process exceeds this value and the machine is > loaded down, the kernel will attempt to swap pages out to get the > process back within the limit. If the machine is mostly idle, the > kernel ignores this limit. > > Currently we have no resource to limit mmap() use. I think in this case it's important to limit exactly malloc(), and definitely NOT mmap(). It's glob(3) that's causing this particular DoS, and it (or, in particular, lib/libc/gen/glob.c's globextend()) uses malloc(). We definitely do not want to limit the maximum filesize that ftpd can transfer - which uses sendfile(); I do not know where sendfile() gets its limits from, but being a syscall, it should not be dependent on RLIMIT_DATA. (well, OK, you probably know what I mean :) G'luck, Peter -- This sentence no verb. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message