httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: WIN32 CGI - SECURITY THREAT - 4 OF 4
Date Tue, 26 Jan 1999 05:14:26 GMT
On Tue, 26 Jan 1999 wrote:

> Hi Marc... 
> Saw your POST on new-httpd...
> >  If a user can create a CGI script, what is the damage from them
> >  telling the system what interpreter to use for it?  They can already do
> >  whatever they want in the CGI.
> Not really. Under NORMAL circumstances they can't do 'whatever they want'.
> apache has already re-directed stdin/stdout, closed the local handles,
> set 'invisible' flags, set other 'limits' and other flags for the relevant
> '_beginthread' and/or 'CreateProcess()' call. This is good. This is OK...
> and under UNIX that's about the end of the story.

So?  It has done the same things by the time it runs the interpreter.
Think about it: if it hadn't, then how would these things magically
change between running the interpreter and the interpreter interpreting?

It is great to go on and on about how different things are under Win32,
how scary is, etc.  But you are missing the point!  The
user can do the exact darn thing from their CGI!  Nothing stops them
from doing the same thing that Apache could do by executing this 
supposedly insecure interpreter.

> It's a complicated issue and I'm not sure what the 'safest' thing
> to do is. I simply happened to notice that Apache for Win32 doesn't 
> seem to be aware that simply running a command without checking it 
> first can let someone do just about ANYTHING THEY WANT...
> no matter what the security or file permissions are.
> I'm not sure that's all the fault of the OS.

Sheesh.  If the interpreter being run to execute the CGI can do it,
then the CGI can do it.  If it can bypass the OS's file permissions,
then the OS doesn't have file permissions.

If you want to argue with me, you can't just go on and on about how
Win32 is different and how is scary, but you have to give
a specific technical example of why the interpreter name can magically
do something that the code itself can't.

View raw message