From owner-freebsd-stable Sun Mar 18 8:13: 5 2001 Delivered-To: freebsd-stable@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 291E937B718 for ; Sun, 18 Mar 2001 08:12:57 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA04406; Sun, 18 Mar 2001 08:12:43 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda04404; Sun Mar 18 08:12:27 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f2IGCLC15576; Sun, 18 Mar 2001 08:12:21 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdQ13555; Sun Mar 18 08:11:43 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.3/8.9.1) id f2IGBf894065; Sun, 18 Mar 2001 08:11:41 -0800 (PST) Message-Id: <200103181611.f2IGBf894065@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdx93896; Sun Mar 18 08:11:12 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Matt Dillon Cc: Jonathan Lemon , stable@FreeBSD.ORG Subject: Re: Not only ftpd's problem with ls */../*..... In-reply-to: Your message of "Sat, 17 Mar 2001 21:43:37 PST." <200103180543.f2I5hb398084@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 Mar 2001 08:11:12 -0800 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103180543.f2I5hb398084@earth.backplane.com>, Matt Dillon writes: > > :> be set with a new api call, setgloblimit()? Or perhaps even just > :> have the setgloblimit() API call and don't even bother with a new flag > . > : > :I would think a better idea is to have the system default to a hard > :limit, and then allow those programs that know better to override it. > :This way, we catch most naive uses of glob, while allowing those users > :who actually want to iterate over more paths to continue. You'll also > :note that the glob interface explicitly allows continuing from a previous > :match (which is what gl_pathc is for), so this fits in nicely. The > :only additional change I can think of is to add a new error return to > :explicitly alert the user that the match limit was hit. > : > :Doing it this way also negates the need for a setgloblimit. > > Imposing a limit by default is no better then having the hard limit as > a default in the first place. The goal of this fix should be to be as > non-intrusive as possible. Having a hard limit by default is extremely > intrusive. It would be almost as bad as putting a hard limit in, say, > 'find'. You don't know *what* type of program will be using the > interface. Just because someone can D.O.S. ftpd doesn't mean that > you should suddenly impose an arbitrary limit on every single program > that might use the interface. Nor would it be appropriate to impose an > additional burden on the programmers using the interface to require them > to explicitly turn off the hard limit if they don't want it... that is > a terrible default API for something like glob! It immediately imposes > the arbitrary limit on every single program using the interface... a limi > t > that the programmers using the interface probably assume doesn't exist. > > It makes to try to protect programmers from themselves a little, but > it doesn't make sense to pollute the functionality and scaleability of > the default interfaces to reach that end. We shouldn't be trying to > protect idiots from themselves... let them learn the hard way so the > rest of us can use these APIs without having to go through loops with > flags and options to make them act the way we want them to act. It's not about protecting idiot programmers from themselves. It's about protecting naive users from idiot programmers. Enough on this philosophical tangent. Having said that, any malicious user could easily circumvent the patch by using their own glob() functions or starve the system of resources in some other way. I think that the ultimate solution is to impose limits on users via login.conf. I tried the exploit on an ftpd that was limited by login.conf. The system didn't crash, slow down, or even use more than a small amount of swap. Ftpd produced a simple message that it could not complete the requested action. I agree with you that the patch to glob() is not appropriate to stop this kind of DoS. Rather than resolving the cause of the problem, resource starvation, we are attacking the effect. I think that our options are: 1. Have ftpd impose limits on its own resource utilisation regardless of the resource limits imposed in login.conf. How many resources would an FTP daemon need anyway? I think this is a proactive solution. 2. A short term fix would be to limit ftpd in inetd.conf using limits(1). 3. Implement reasonable default limits in login.conf. These limits could even be determined at sysinstall time by querying the system about memory and swap sizes. 3a. #3 above but instead of sysinstall determining the limits define classes of users in login.conf such as default (with reasonable limits for most installations) and big (without limits). A simple solution for a simple problem. I think that the above points protect naive users from idiot programmers while while addressing Matt's concerns. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message