Date: Sun, 18 Mar 2001 08:11:12 -0800 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Matt Dillon <dillon@earth.backplane.com> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, stable@FreeBSD.ORG Subject: Re: Not only ftpd's problem with ls */../*..... Message-ID: <200103181611.f2IGBf894065@cwsys.cwsent.com> In-Reply-To: Your message of "Sat, 17 Mar 2001 21:43:37 PST." <200103180543.f2I5hb398084@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103181611.f2IGBf894065>