I host a number of virtual domains that use cgiwrap, each owned by a
different user.
In many cases, cgiwrap incorrectly guesses the username the script
should run under.
To keep them out of the rest of my system, I disallow shell and chroot
their FTP session into their home directories.
Each virtual domain is defined like this:
NameVirtualHost 208.15.218.26
<VirtualHost 208.15.218.26>
ServerAdmin webmaster@...
DocumentRoot /home/ataylor/public_html
ServerName http://www.mcfumbler.com
AddHandler cgi-wrapper .cgi
Action cgi-wrapper /cgiwrap/cgiwrap/ataylor
<Directory /home/ataylor/public_html>
Options Indexes Includes ExecCGI
</Directory>
<Directory /home/ataylor/public_html/havers/dross>
Options Indexes Includes ExecCGI
</Directory>
CustomLog /var/log/httpd/mcfumbler.com-access_log combined
</VirtualHost>
This should allow the domain owner (ataylor in this case) to run
scripts through the wrapper anywhere in their web space.
However, this fails for http://www.mcfumbler.com/havers/dross/gm.cgi
It's as though Apache or cgiwrap ignores the "ataylor" part of the action
directive.
I used the following config to build the wrapper:
../configure --with-local-contact-name=Webmaster \
--with-local-contact-email=webmaster@... \
--with-wall \
--with-perl=/usr/bin/perl \
--with-cgi-dir=public_html \
--with-install-dir=/home/httpd/cgiwrap \
--with-httpd-user=nobody \
--with-minimum-uid=500 \
--with-logging-file=/var/log/httpd/cgiwrap.log \
--with-rlimit-cpu=15

Hi,
We are running into a problem with hackers. They beat the
crap out of a specific CGI trying to get it to release information
it shouldn't. In the matter of seconds its gotten a system up to a
load average of 200, taking 20 minutes to telnet into it. This is also
after we have instituted a program that once the load average is over 12
(It runs every 2 minutes) it will chmod 000 the cgi!
Its currently wrapped by an older copy of cgiwrap (3.6.4).
Its compiled with :
./configure --with-perl=/usr/local/bin/perl -with-install-dir=/var/www/cgi-bin -
-with-cgi-dir='' --with-httpd-user=www --with-logging-syslog='' --with-install-g
roup=wheel
Is there a way to stop, or atleast curb this insanity? I
saw --with-rlimit-nproc=, which I don't quite understand (I'm not
a programmer). Does this mean only 32 can run at one time? Was this
always the default, since we can easily have more than 32 running.
Is there some other items we can tweak to help? I don't know if limiting the
CPU seconds works with a default either, since it seems to allow it to have
more than 10 (On another machine we have an issue... It has actually let
CGI run for HOURS...).
Any help/hints/pointers are appreciated.
Thanks, Tuc/TTSG Internet Services, Inc.

On Mon, 26 Nov 2001, Ian 'Ivo' Veach wrote:
> We have users who want to organize their "many" cgi into subdirectories
> under their personal cgi-bin/ directory. At a glance, this seems like a
> bad idea [one I'm not thrilled about anyway]. However, given our user
> requests and since cgiwrap can check for symlinks and ../, is allowing
> users the capability to store subdir cgi a bad thing? Are there other
> issues at hand? Can someone give a practical counter example?
The only issue that I can think of occurs when your cgi-bin directory is a
subdirectory to your public_html directory (which unfortunately is the
default).
On servers like that, I'll touch index.html in their directory, so that
the server won't give a listing of their files. With multiple
directories, you'd want to do this for every directory. Unfortunately,
this is only fixing one symptom of a larger problem -- anyone can still
read your files if they know the name of them, it just makes it harder for
them to figure out the names of the files.
So, yes, there's sort of a problem, but if you have that problem, you have
an even bigger issue to deal with.
-----
Joe Hourcle

We have users who want to organize their "many" cgi into subdirectories
under their personal cgi-bin/ directory. At a glance, this seems like a
bad idea [one I'm not thrilled about anyway]. However, given our user
requests and since cgiwrap can check for symlinks and ../, is allowing
users the capability to store subdir cgi a bad thing? Are there other
issues at hand? Can someone give a practical counter example?
cheers and thanks,
________________________________________________________________________
Ian 'Ivo' Veach, imail@... UCCSN System Computing Services
http://www.nevada.edu/~ivo postmaster/webmaster/sysadmin
________________________________________________________________________

Ok here is the deal I own a cobalt, a raq4i, and have been reprogramming
these babies for weeks now. Yesterday I went to conquer the cgi wrap
and standard cgi. We have always given our users a choice of using
either one. The way it is setup on our old servers is .cgi and .pl
along with anything in the cgi-bin are standard cgi. Then anything with
.scgi or .spl or that are in the scgi-bin are ran wrapped. Well after
quite a bit of hacking, some rewrite rules, and a mis-use of the case
sensitivity I was able to get the scgi-bin to work. But here is my
problem. If any extension other then .pl or .cgi is associated with the
cgi wrapper (or if the script is in the scgi-bin with a non-default
extension) then it doesn't work. It does try and run it with cgi
wrapper since I get a pretty cgi-wrapper error page and it says Script
Not Found. This is quite weird since the path it gives to the script it
correct. Anyway I downloaded the binary of cgi wrap off my cobalt to
see if I could find anything and sure enough in there it referenced .pl
and .cgi and through some hex editing I was able to change the extension
to something else but as you may or may not know in binary you cant
really add to the file without corrupting it. Anyway so this didn't
truly solve my problem. So then I asked the owner and he said cobalts
were a mess and he didn't support them so I installed his version but he
said on cobalt it was impossible for whatever reason to get the user to
run the scripts on from the file permissions it had to get it from the
url like whatever/cgiwrap/user which I didn't like. So what im here to
ask is either:
A) How to convert my cobalt version to work with all file extensions not
just .pl or .cgi
Or
B) How to get his version to work but not need to get the login for the
url but rather who owns the file:-)
Thank You For Your Time,
Nick Daum
US CEO
Novanix, LLC.
<http://www.Novanix.com&gt; http://www.Novanix.com
This message was sent using a Digital Certificate to verify the sender.
If you have an attachment with a .p7s exstention that means your email
client does not support digital signatures and you should ignore it.
This message was also set with a vCard Attachment (ending in .vcf) if
your email client supports it you can import this into your Address
Book.

I remember years ago, the issue of CGIWrap under SSI would come up every
month or so (much like the .htaccess issues do these days), and I think I
may have found a solution.
I've tested this under netscape enterprise 4.1sp7, but not yet through
apache. First off, set up SSI with a noexec option (which seems to no
longer be documented on Netscape's site for hacking the object file
directly, so you might want to use the GUI, or you can try adding:
In your init section:
Init funcs="shtml_init,shtml_send" shlib="/full/path/libShtml.so" NativeThread="no" fn="load-modules"
Init LateInit="yes" fn="shtml_init"
Add in the object:
ObjectType fn="shtml-hacktype"
Service fn="shtml_send" type="magnus-internal/parsed-html" method="(GET|HEAD)" opts="noexec"
Now, you can call the SSI through:
<!--#include virtual="/cgi-bin/cgiwrap/user/script"-->
Which will cause the webserver to process the page independantly, calling
CGIWrap, and without the exec option, keeping them from being able to
directly call the CGI script.
[This may have already been discussed, but well, I didn't see it in the
docs, so I just thought I'd share.]
-----
Joe Hourcle

On Mon, 26 Nov 2001 cedric@... wrote:
> Hi,
>
> I am using CGIWRAP seemlessly with the AddHandler / Action directives with
> apache. I just discovered that it was possible to execute a script that is
> located in a password protected directory using .htaccess file.
>
> When accessing http://www.website.com/protected/script.cgi, Apache won't
> allow unauthorized access because there is a .htaccess file with the right
> directives in the protected directory. When supplying the right password,
> apache will execute the script by calling CGIWRAP. This is all good.
>
> Although, you guessed it, if one calls
> http://www.website.com/cgibin/cgiwrap/username/protected/script.cgi, it is
> easy to breach in.
>
> I would like to prevent cgiwrap to be accessed directly, like in the second
> exemple. Is there a way to do this?
Well, I would think that you'd have different environmental variables set
when called through the two different paths.
You might check if there's something that you can key off of, so that you
can reject if it's not being called through the way which you prefer.
-----
Joe Hourcle

Hi,
I am using CGIWRAP seemlessly with the AddHandler / Action directives with
apache. I just discovered that it was possible to execute a script that is
located in a password protected directory using .htaccess file.
When accessing http://www.website.com/protected/script.cgi, Apache won't
allow unauthorized access because there is a .htaccess file with the right
directives in the protected directory. When supplying the right password,
apache will execute the script by calling CGIWRAP. This is all good.
Although, you guessed it, if one calls
http://www.website.com/cgibin/cgiwrap/username/protected/script.cgi, it is
easy to breach in.
I would like to prevent cgiwrap to be accessed directly, like in the second
exemple. Is there a way to do this?
Thank you for your help,
Cédric

Correct. That's why it is important to be very careful what you put in that
directory and why it isn't enabled by default. As long as you are careful to
only put scripts that you have hand verified to be secure in there, you
should be perfectly safe.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@...
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Gennadi Umanski [mailto:umanski@...]
> Sent: Wednesday, November 21, 2001 10:51 AM
> To: Neulinger, Nathan
> Subject: cgiwrap & option --with-multiuser-cgi-dir=PATH
>
>
> Hi,
>
> i have a question about cgiwrap and the option
> "--with-multiuser-cgi-dir=PATH"
>
> > --with-multiuser-cgi-dir=PATH
> > define a central cgi script directory that is searched if
> the script is not found
> > in a user directory. This can be used to make a single
> script available
> > that will run as any user, however, this can be very
> dangerous if you're not
> > extremely careful designing your script. Do not enable
> this unless you know
> > what you're
> > doing. It is not needed for normal usage.
>
> We want use a shared cgi-directory with a cetrain
> cgi-scripts, that root
> installed. This cgi-script should run under user-id. We dont
> need a execution of
> user-script placed in user-homes.
> My question is: what are the dangers of such solution?
> These common-scripts
> run with user permission and they may do the same what a "normal"
> user-home-script may do too, dont they?
>
> TIA,
> G.Umanski
>
> --
> +----------------------------------------------------------------+
> | Dipl.Inform. G. Umanski | Phone: +49 651 201 2840 |
> | Dept. Computer Science | Fax : +49 651 201 3954 |
> | University of Trier / Germany | Room : V214 |
> | http://www.informatik.uni-trier.de/~umanskij/ |
> +----------------------------------------------------------------+
>

rmartin@... wrote:
>
> Hello,
>
> We have got a Colbalt RaQ with cgiwrap installed on it, which is excellent because it allows me
> to up-load files without contacting our ISP.
>
> However we can't get the attached file to work because of cgiwrap and no one knows why.
>
> Can you help?
>
> Many Thanks
> Rob Martin
> Transair UK Ltd
>
> ------------------------------------------------------------------------
> Name: encrypt.pl
> encrypt.pl Type: Perl Program (application/x-perl)
> Encoding: base64
Since you don't provide any diagnostic information or error messages,
and since you're running on a RaQ, Not really.
Does the perl script work when when run directly from the shell? Are you
getting any other errors? Are you able to run other perl scripts via
cgi?
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@...
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216

On Wed, 14 Nov 2001, Neulinger, Nathan wrote:
> Hacking around things should not be needed. Something is wrong with the
> setup on that machine if regular forks/system/etc. are not working.
The one machine that I've seen that had issues forking was calling _a_lot_
of CGIs (they had 2 SSI's on the main site, which called a CGI to do
browser detection, and output the correct CSS w/ HTML header, and again
for the HTML footer)
Every so often, you'd get a zombie process, and they'd slowly build up,
until the system wasn't able to fork any more.
Now, when running things from the shell, they ran just fine, so I'd assume
that it was an issue with the number of children allowed to a parent
process (the webserver).
Just to check if it's even an issue with perl, have you tried the
equivalent shell script?
#####
#!/bin/sh
echo "Content-type: text/html"
echo
uptime
#####
-----
Joe Hourcle

On 15/11/2001 05:04, Ralph Huntington wrote:
>I don't think he's using php; it's a perl script. I think he's just got a
>perl usage issue. He makes a system call, but does nothing with it -- or
>so it seems. He needs to capture the result of the system call.
however, the `uptime' command prints result to the standard
output. it should show in the browser (given the proper http
headers have been sent previously).
--
sh

Hello,
even a small perl script showing the uptime is hanging:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
system("uptime");
I started the script in debug-mode:
...
argv[0] = 'cgiwrapd'
Executing '/vrmd/http/web/test.pl'
Output of script follows:
=====================================================
<nothing follows, but connection stays open>
How can I configure cgiwrap to execute "uptime" or any other command?
Regards
Marten

Hi Folks,
Hope this question isn't too simplistic for y'all.
I am trying to install CGIWRAP for the first time. I downloaded to tar.gz
file and looked at its contents. In the installation instructions it states
that I need to "copy the cgiwrap executable to my... cgi-bin directory".
Which file is the executable? Doesn't CGIWRAP need a bunch of the files
contained within the tar.gz file?
If I copy the tar.gz file in its entirety to my server, where should I place
it before untarring/unzipping?
Sorry for my ignorance, but if anyone can help me get past the opening steps
here I'd be eternally grateful. :)
Marcus

Hello,
I got the following error
Warning: Unable to fork [/usr/X11R6/bin/convert > /dev/null] in test.php on line 26
doing an
$check = system("/usr/X11R6/bin/convert > /dev/null", $ret);
which worked with PHP as Apache Module perfectly. Is this a problem
with PHP als CGI or is this caused by cgiwrap? I didn't check so far
if e.g. a perl-script can fork a process.
Regards
Marten

On Thu, 8 Nov 2001, C Casey wrote:
> Whenever we fill this form out:
>
> http://www.4burialinsurance.com/newtestform.html
>
> we get this message:
>
> CGIWrap Error: Script Execution Failed
> CGIWrap encountered an error while attempting to execute this script:
>
> Error Message: Permission denied
> Error Number: 13
>
> The problem is that this script is exactly formatted like our other
> scripts, but it doesn't work. The permissions and path are the same.
>
> Any ideas? Our administrator is recently out of the hospital.
The 'Permission denied' line may not be regarding the script itself, but
it might be generated from something that the script is called.
For instance, with a perl script, if you have execute permissions on the
file, but don't have perl binary, you're going to throw a similar error.
-----
Joe Hourcle

Whenever we fill this form out:
http://www.4burialinsurance.com/newtestform.html
we get this message:
CGIWrap Error: Script Execution Failed
CGIWrap encountered an error while attempting to execute this script:
Error Message: Permission denied
Error Number: 13
The problem is that this script is exactly formatted like our other
scripts, but it doesn't work. The permissions and path are the same.
Any ideas? Our administrator is recently out of the hospital.
C Casey

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details