[495] in WWW Security List Archive
Re: Security risks with CGI
daemon@ATHENA.MIT.EDU (Garrett Burke)
Fri Mar 3 07:18:00 1995
To: "Phillip M. Hallam-Baker" <hallam@dxal18.cern.ch>
cc: www-security@ns2.rutgers.edu
In-reply-to: Your message of "Thu, 02 Mar 1995 11:37:43 +0900."
<95Mar2.113753+0900_met.63660-3+9@dxal18.cern.ch>
Date: Fri, 03 Mar 1995 08:48:40 +0000
From: Garrett Burke <gburke@dsg.cs.tcd.ie>
Errors-To: owner-www-security@ns2.rutgers.edu
In message <95Mar2.113753+0900_met.63660-3+9@dxal18.cern.ch>you write:
>
>>I'm looking for a comprehensive list of security risks with using CGI
>>scripts.
>
>It would be a very long one indeed.
>
This is the sort of comment that I have got from several quarters, but
it isn't very useful. What I'm trying to do is to make an informed
decision on whether to allow scripts i.e knowing that there are risks
A,B,C ... Z we will allow/disallow scripts.
(Hence the mail to both Philip & the mailing list)
Knowing there are problems, but not knowing the specifics,
isn't making an informed decision.
>I personally think the CGI-script idea was a bad one from the start.
>If you are security concious
As I said in my original mail, we aren't very security concious (anon
ftp, no firewall, multiple machine with net access etc), but are
sufficiently interested in security to sit up and take notice of
comments like the above: regarding a list of security problems with
cgi scripts .. 'That would be a very long list indeed'
>it is much better to have the routine compiled into the server.
Yes, but the flexibility of being able to extend the facilities of the
server is very useful. Possibly put a Perl interpreter (with no eval
,system call or execution of outside programs) inside the server and
get the server to execute the script directly?
>Spawning other executables on demand is a flakey business at the best
>of
>times. Spawning shell processes under UNIX is a nightmare.
>
>The problem is that people like having enough rope to hang themselves
>with.
Agreed.
>An
>analogous "feature" is the idea that someone posts every so often showing how
>one can add csh into a mailcap file and automaticaly execute Web pages as the
>arrive.
This is exactly the type of information that I am looking for:
'Don't allow execution of Web pages by putting csh entries in the
mailcap file'
Executing the incoming data, from a GET or POST, without doing some
pre-processing is risky. Just passing it to the shell to be executed
is insane as your example shows.
>I don't think thats a very good idea with a signed, authenticated
>service. Someday someone will load a shell script writen for Mupux-4.2.1(b) no
>t
>realising that their machine is now running <upux-4.2.2(f)patch levelIV. As a
>result of this incompatibility the command rm -Rf / will be executed by
>accident.
>
Right, but scripts are safer than doing this. At least you can force
the input to include some information (such as a version number) which
is then processed either by an extension to the server or an
executable between the server and the script which refuses to execute
the script if all is not well. Of course this suffers from all the
usual problems of how to trust the information coming in in the frist
place i.e the script really is version X.y.z and not X.y.w hence the
need for a signed, authenticated service.
>See the UNIX=Haters guide for the best summary of UNIX related risks.
>
Are you saying that the problems with CGI scripts, are general UNIX
problems, and thus can be tackled as such?
>
> Phill H-B
>
>
>
--
Garrett Burke | Tel: +353 1 7021539
Distributed Systems Group | Email: gburke@dsg.cs.tcd.ie
Dept. of Computer Science |
Trinity College Dublin | A jug of wine, a loaf of
Dublin 2, Ireland | bread and thou.
