Help - Search - Members - Calendar
Full Version: CGI and PERL access all server
The Planet Forums > Control Panels > Plesk
paulie
Hi there

I have a slight problem with my server running plesk, .cgi and .pl scripts can access all files on server... how can I lock it down.

Does some modifying need to be done ? How would I do this ? any help would be appreciated

Thanks

Paul
Rich2k
Yes I have noticed this as well... very worrying.

How can I lock it down? suEXEC? If so how do I configure it to run as a username rather than as nobody?
cwings2001
I have this problem as well. In the /cgi-bin/ that exists, it seems you can only store scripts and not other files (images, etc.) We have been instructing our users to create /cgibin/ (no dash) under /httpdocs/ and use that script directory since we enabled .cgi/.pl anywhere under their sites, etc. Is there any fix on the way from PLESK to enable having other types of files (images, etc.) stored in the /cgi-bin/ directory so that we don't have to use this work around?
misterb
Not sure about that one. I believe that is a suexec thing. When you install PSA you are getting apache with cgi support using suexec to, in a sense, secure cgi usage. It doesn't inhibit all the power of cgi, but it does have some strict rules with regard to where cgi files can be run... and what types of files can be run in the cgi-bin. Basically it assumes all files in the cgi-bin are in fact scripts.

I don't think there is a way to defeat other than to remove suexec completely which is obviously not the right thing to do.

In your previous server configurations, how were you dealing with the security of running cgi's? Suexec is probably the most common mechanism for doing this.
cwings2001
We have raq 4i's here also and never had any issues - I don't think they are running suEXEC are they?
cwings2001
What really *ARE* the dangers or removing suEXEC completely?
misterb
One example of what suexec does is to assure that the true owner of a file is the same who is executing it. Without it, then any user with cgi capabilities would be able to operate other cgi's on the server; from what I have read.
misterb
I think Raq's use Cgi-wrapper. That's another one of the cgi security things that is out there.

I'm actually looking into this a bit further, because now I'm actually wondering if this is truly a suexec thing. I'll let you know what I find out.
Rich2k
I think it's running the perl scripts as nobody which gives it access to the whole server.

I have been reading that suEXEC can put the perl scripts to run under the site's username so I guess suEXEC is not configured for that by default.

Obviously this could be a security risk for virtual hosting.

Anyone else got any thoughts?
misterb
Hey cwing.. I think I may be on to something.

If I remember correctly Cobalt does not use the ScriptAlias directive to define the cgi-bin as PSA does. I think they simply do AddHandler statements at the document root for both .cgi and .pl (If memory is serving this would be Raq3 as that is all I have seen before).

PSA uses a specific cgi-bin using the ScriptAlias directive to define this directory as a directory in which scripts would be run.

In any case, I believe the ScriptAlias directive tells Apache to assume that all files in this given directory are scripts. Therefore Apache doesn't know any better. Because of this, theoretically you should be able to have any file extension on files within the cgi-bin and Apache should still try to run them as scripts. But I haven't really tested this out yet. It's late... and I need to hit the hay, but I will talk this over with some of my better Apache guys tomorrow to see if I really am on to something or if I'm just blowin smoke.
cwings2001
Hey... I agree, ScriptAlias does make /cgi-bin/ act like it should only run scripts - but we've even tried changing "ScriptAlias" to just "Alias" (dropping the scripts, therefore, theoretically, dropping the scripts only designation).... and it still does not work.
misterb
Either way I think this is a step in the right direction. If it ends up being part of the vhost setup in Apache it may be something that can be fixed using a vhost.conf file.

Basically inside the domain directory you can add a file under ../domain.com/conf/vhost.conf in which you can add domain specific apache directives. You can override things that are setup by PSA or add new things. If there is a way to use this to fix your issue, and you want to implement it on all vhosts, then you would just do this within the ../psa/home/vhosts/.skel/ directory and then it would be applied to all vhosts right from the start. icon_smile.gif

Anyway, hang in there. I think the answer is close now.
misterb
I talked to some of my tech guys who know this stuff a good bit better than I and yes this is the right track, but they aren't sure of the best way to do it.

One question they asked was what you were really trying to do. Are you moving domains over from another machine that had a different phyisal directory setup, or are you creating new domains. Their recommendation, if creating new domains, is to learn the new structure and work with it, because it is technically a stronger more secure setup. If you are moving a large number of existing domains with existing content, etc. then you can probably do this using the vhost.conf but it would likely require doing manual mod's in each domain.

I also asked my contact at Plesk this morning and they stated that they were working on a formal answer for a customer as we spoke. So I'm guessing you got to them before me. icon_smile.gif
cwings2001
My customers want to be able to use this /cgi-bin/ directory, as you can imagine, however, they want to be able to store ALL types of files in this directory, and not just SCRIPT files.....
cwings2001
COURTESY of our friends at PLESK who helped solve this one :-) Here is the final solution......I've tested this on my two PLESK machines.

Ok here is the final solution on this that seems to be the best overall....

Basically what we did on your server is to create a few things with the /usr/local/psa/home/vhosts/.skel/ directory.

Inside the ../.skel/ directory you will find the following structure..

../.skel/httpdocs/cgi-bin/

This results in a /cgi-bin/ directory being placed inside the httpdocs directory of each vhost.

Then we have also created a .htaccess file here..
../.skel/httpdocs/cgi-bin/.htaccess

Inside this file are the following two directives:

Options +ExecCGI
AddHandler cgi-script .cgi

This results in the ability to run .cgi scripts within this directory. You should note that this setup is specifically for .cgi's. For .pl's it would likely require some additional directives. But the same idea would apply.

The other needed step is to make one modification to the httpd.conf file. Inside this file you need to comment out the following line:

#ScriptAlias /cgi-bin/ "/usr/local/psa/apache/cgi-bin/"

After that... everything should work fine.

One last thing you might want to consider is to remove the
../.skel/cgi-bin/. As long as you never selected CGI from the PSA interface I don't believe this would cause any problems. And if CGI is selected from the interface while using this setup... there will be other problems as well anyway. icon_smile.gif
rhordern
Isn't it possible to make it so that you can access .CGI's and .PL's from any directory on the server without adding a .httaccess each time??
I am in the process of moving poeple from a raq to the new server and on a raq you can run CGI's everywhere !!!
There MUST be a safe solution, wouldn't it be something like adding a line to the httpconf file which add a cgi handeler to all the directotorys ...

Richard
Rich2k
What's even more scary is that I have an account on one of the big virtual hosts as well as having a server here (not naming names though) and they have only just locked down being able to view all DBs on the server in PHP but more importantly suffer the EXACT same problem with CGIs and they are running solaris.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.