From owner-freebsd-hackers Fri Jan 19 12:34:47 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 7CCFC37B401 for ; Fri, 19 Jan 2001 12:34:27 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0JKYFW97724; Fri, 19 Jan 2001 12:34:15 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Jan 2001 12:34:15 -0800 (PST) From: Matt Dillon Message-Id: <200101192034.f0JKYFW97724@earth.backplane.com> To: mouss Cc: "Aleksandr A.Babaylov" , roam@orbitel.bg (Peter Pentchev), walter@binity.com, wayne@staff.msen.com, hackers@FreeBSD.ORG Subject: Re: Protections on inetd (and /sbin/* /usr/sbin/* in general) References: <20010117103330.L364@ringworld.oblivion.bg> <4.3.0.20010117215944.04b10ae0@pop.free.fr> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A jailed environment will certainly help prevent them from breaking root, but keep in mind that the server side scripts already need to have read (and probably write) access to much of the data associated with the web site in order to operate the web site. You can do only so much. The real problem here is the CGI script / server-side design allowing the breakin in the first place. The KISS principle applies. Good programming practices (such as using the likes of asprintf() and snprintf() instead of sprintf() in C), and code auditing, pretty much removes the chance of an exploit. For C based CGI's you need only do a few things to reduce the errors down into nothing more then null-pointer derferences which generally cannot be exploited. It means not making any assumptions whatsoever on the size or content of input data, even if you have client-side javascript 'restricting' the content of the input data. It also means properly escaping all POST data so when someone types 'fubar' into an input field the worst that happens is for it to show up as 'fubar' in any HTML output rather then FUBAR (bolded 'fubar'). How often have you typed a single quote into an sql-database-backed web page input field and gotten a fault? A backslash? Punctuation? Hmm.... proper escaping is absolutely mandatory. It also means not trusting input data... properly massaging it before using it for things like, oh, command line arguments to exec'd programs, and stupid things like that. Some languages are less likely to be exploitable then others, but never assume that the scripting / programming language will protect you. After all, again, if the backend needs to access the data to drive the site then exploits can potentially also access the data, no matter what kind of security measures are taken in the language imlementation. If the backend needs to store persistent state, then exploits can also potentially modify that state. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message