[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cobalt-users] OFFTOPIC: Faking CGI environment



>is it possible to call a cgi from telnet and do something so that this cgi
>"believes" to be called from the web ? I mean: Can I set the environment
>variables that this cgi would get if it would be called via the web (e.g.
>the variables REMOTE_USER, SCRIPT_NAME etc.) ?

This would depend on the shell your using, but its probably bash, so you
can set enviornment variables by:

	export NAME="value"

So if you wanted to set a few of these it's easy to make a quick shell
script to set them and then call the cgi:

intrepid:~$ cat test.sh
#!/bin/sh

export DOCUMENT_ROOT="value"
./test.pl



Then we have a sample perl CGI Script:

intrepid:~$ cat test.pl 
#!/usr/bin/perl

print "Content-type: text/html\n\n";
print "DOCUMENT_ROOT = $ENV{'DOCUMENT_ROOT'}\n";


So if you run "./test.sh", it will setup an enviornment variable for
"DOCUMENT_ROOT" and then it runs a perl script which prints that out.
DOCUMENT_ROOT is set by apache to the DocumentRoot directive for the
particular vhost when its accessed via the web.

>If this is possible, I think some of the Cobalt administration cgis are very
>insecure. I just had a closer look into them. Most cgi scripts, e.g. the one
>for adding a virtual site, just check simple things, e.g. some hidden form
>values from the website they were called from. AND: These cgis scripts have
>the permissions 755 so anybody who is able to fake this cgi environment has
>almost full access to the server.

Not exactly.  Normal users are able to view these scripts and execute them.
 However, running them wont get you very far.  Cobalt's GUI is powered by
another copy of apache running an alternate config file on port 81
setuid/gid root,root.  There is no cgiwrap on this, so all cgi scripts are
ran as the httpd user, which is root.  

These scripts will only really work when they are run as root.  You can
probably fake the enviornment and get them to run, but they will fail to do
anything that would compromise security because a normal user wouldn't have
the rights to write to certain files that the gui scripts write to (I've
only looked at the user management cgis, which write to files such as
/etc/passwd, and because of the file permissions only root can write to
these).  


- Dave