httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: WIN32 CGI - SECURITY THREAT - 4 OF 4
Date Tue, 26 Jan 1999 00:05:34 GMT

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.

But WIN32 is not UNIX... and COMMAND.COM and CMD.EXE are
not Korn again, Bourne again... or anything else again. They
are DIFFERENT... and if a user slips a 'fake interpreter line' in
with some of the 'scary' flags that can negate what would otherwise
be a secure pop-off under Unix... well... I think it's a problem...
and I think the application doing the 'pop-off' bears some responsibility
for what might happen since it is the entity 'running' the show.

>  If your OS doesn't give you file permissions then that is your problem,
>  and you shouldn't let untrusted users execute CGIs period.  That isn't
>  Apache's problem.

WIN32 does have file permissions. It also has COMMAND.COM and
CMD.EXE. You need to familiarize yourself with all the 'flags' associated
with these puppies. They have a LOT of 'legacy' options that still
work and for which there is no equivalent in the UNIX world.

I just don't think it's enough to do such a simple 'pop-off' in the
same way it would happen under UNIX and then say... "Well...
that's all we have to do with UNIX... what do you want from us?"

You are the ones offering the software. You advertise in the WIN32
arena... you are pressing for some market share there... is it
just for show or do you intend to make it real?

By NOT checking the 'interpreter line' AT ALL it simply opens
up a LOT of possibilites for neer-do-wells... to the point where
I daresay folks will be afraid to use it. Is this not at odds with
your goals? If you want more than 53% market share and you
don't want them coming up fast in your rear-view mirror then you
are going to have to address the needs of OSes other than UNIX.

Win32 'shell' commands have a lot of options that are unique and
don't exist under UNIX because... well... it's not UNIX.

Check out any DOS 6.2 manual and look at the scary options
for COMMAND.COM. Apache will happily allow anyone to use
any of them if they are part of a 'fake script interpreter' line.

Security is not totally the responsibility of any OS. It is also the
responsibility of applications that RUN under that OS. No system
is truly safe unless the applications that run under that system are
fully cognizant of what can happen when running on that system.

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.

It wouldn't be so bad if you weren't trusting the 'PATH' and the
'ENVIRONMENT' so much. 

How about this... Make sure ANY EXECUTABLE has to be in
a 'trusted' dir specified in ACCESS.CONF. You already do this
with CGI-BIN and all the broo-ha that goes with it... yet when it
comes to WIN32 and executing OTHER PROGRAMS... you 
happily pop-off anything that happens to be in the default path.

If SCRIPTS have to be in a 'special area' then why not ALL EXECUTABLES
including a 'trusted' COMMAND.COM and CMD.EXE. An Admin 
could easily 'patch out' the dangerous 'legacy' options and be sure
that when Apache pops-off 'CMD' or 'COMMAND'... it's doing it safely.

At least this would give a Win32 Admin a CHANCE to lock the system
down and still offer flexible CGI to customers.

View raw message