Date: Fri, 19 Jan 2001 12:34:15 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: mouss <usebsd@free.fr> Cc: "Aleksandr A.Babaylov" <babolo@links.ru>, 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) Message-ID: <200101192034.f0JKYFW97724@earth.backplane.com> References: <20010117103330.L364@ringworld.oblivion.bg> <4.3.0.20010117215944.04b10ae0@pop.free.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
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 '<B>fubar</B>' into an input field the worst that happens is for
it to show up as '<B>fubar</B>' 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101192034.f0JKYFW97724>