cgiwrap-users

[cgiwrap-users] Anyone know

[Huw J. <huw...@so...>]

A good how-to on setting up CGI's with CGIwrap server side. I can't seem to
get scripts running and know I'm missing something real simple. But can't
work out what.

Regards

Huw Jenkins

[cgiwrap-users] INTERNAL SERVER ERROR

[Dimitrios M. <dma...@cs...>]

hello,

i installed cgiwrap (3.8rc1)  to execute php scripts
but i get Internal Server Error from apache Server which means that i =
have a
script level error
i placed the line #!/usr/local/bin/php to be the very first line of the =
php
script , even before the <?php tags?>

i configured with following options

./configure --with-install-dir=3DPATH --with-httpd-user=3DUSER =
--with-php=3D/usr/b
in/php  --with-php-cgiwrap --enable-discard-path

when then i type make i get following message

gcc -c -g -O2  -I. -I. cgiwrap.c
gcc -c -g -O2  -I. -I. debug.c
gcc -c -g -O2  -I. -I. util.c
gcc -c -g -O2  -I. -I. fetch.c
gcc -c -g -O2  -I. -I. stdutil.c
gcc -c -g -O2  -I. -I. msgs.c
msgs.c:637: warning: type mismatch with previous implicit declaration
msgs.c:376: warning: previous implicit declaration of
`MSG_Error_ServerConfigError'
msgs.c:637: warning: `MSG_Error_ServerConfigError' was previously =
implicitly
declared to return `int'
msgs.c:652: warning: type mismatch with previous implicit declaration
msgs.c:622: warning: previous implicit declaration of
`MSG_Error_UserConfigError'
msgs.c:652: warning: `MSG_Error_UserConfigError' was previously =
implicitly
declared to return `int'
gcc -o cgiwrap cgiwrap.o debug.o util.o fetch.o stdutil.o msgs.o


then i type make install i get following message

rm -f PATH/cgiwrap
rm -f PATH/cgiwrapd
rm -f PATH/nph-cgiwrap
rm -f PATH/nph-cgiwrapd
rm -f PATH/php-cgiwrap
rm -f PATH/php-cgiwrapd
cp cgiwrap PATH/cgiwrap
cp: cannot create regular file `PATH/cgiwrap': No such file or directory
make: *** [install] Error 1


i followed all instructions  but i couldn't make ti work
any help is appreciated

best regards
dimitris matzios (greece)

[cgiwrap-users] RE: release candidate for cgiwrap-3.8 available on sourceforge

[Neulinger, N. <nn...@um...>]

The cgiwrap version 3.8 release is now available on the sourceforge
files page for the cgiwrap project:

http://sourceforge.net/project/showfiles.php?group_id=3D8209

Tuc/TTSG Internet Services ( http://www.ttsg.com ) generously sponsored
most of the recent changes to cgiwrap. If you're in the market for
professional hosting/colocation services, give them a call or check out
their website!=20

Changes in this release:

  New in version 3.8:

     * Merged in special handling for PHP scripts by popular demand.
This
       is  based  mostly  on Piotr Klaban's php-cgiwrap patch, with
minor
       changes.
     * Added   options   for   php  support.  --with-php-interpreter
and
       --with-php-cgiwrap
     * Rewrote the path translated support. Is it finally correct?
     * Patch  from  sa...@co...  to use REDIRECT_URL if
available
       for SCRIPT_NAME.
     * Added support for access control files specific to each
HTTP_HOST,
       useful  for  ISP's using Apache handlers to run cgi's that want
to
       restrict  which  userids  can  run  cgi's  on  certain  vhosts.
If
       enabled, the vhost access control files must exist.
     * Added   option  to  require  that  REDIRECT_URL  be  specified
in
       environment.  Can be used to require that cgiwrap be invoked via
a
       handler/action  or some other internal apache
redirection/rewrite.
       Primarily  of  use  when  invoking  cgi's  for  virtual  hosts
via
       Action/SetHandler.
     * Modified  san's REDIRECT_URL support to be
--with-use-redirect-url
       instead of --with-check-redirect-url, since it's more a
functional
       change, not a security check.
     * Added   a   --with-quiet-errors   option  to  allow
significantly
       restricting  the  amount  of  internal  information  that an
error
       message displays.
     * Added  ability  to  override  the  vhost that cgiwrap users via
an
       optional  CGIWRAP_AUTH_VHOST env var, which if present and
feature
       enabled,  will  be  used  instead of HTTP_HOST. This is useful
for
       when   you   have  wildcard  servernames  in  apache.  Enable
the
       --with-vhost-override  option  if  you want this capabillity.
Only
       applicable if vhost allow/deny dir is enabled.
     * Added  ability  to  only allow scripts run by a specific userid
if
       the   CGIWRAP_REQUIRE_USER   env   var   is   specified   and
the
       --with-env-require-user feature is enabled.
     * Changed to autoconf 2.5 style templates and eliminated
acconfig.h.
     * Added   option   to  enable  the  special  PHP  support  only
for
       non-executable files.
     * Added  modified  patch  by  Gabriel  Ambuehl to use SCRIPT_URL
for
       SCRIPT_NAME generation.


If you're an ISP using cgiwrap, some of the above can be very helpful.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

[cgiwrap-users] Re[2]: [courier-users] SpamAssassin integration

[Gabriel A. <ga...@bu...>]

Hi Gordon Messmer,
you wrote.

GM> I'm not aware of a filter that will do so, but it seems like it would be
GM> trivial to extend perlfilter to use Mail::SpamAssassin, and return 
GM> success/fail based on the score the message receives.

Success and fail isn't exactly what I'm after, I want the whole
rewriting shebang SpamAssassin does. (Mostly because it's impressive
to the users *g*).

>> 2) Per user SpamAssassin (preferred): I'll use dot-courier dynamic
>> delivery to actually tell courier what to do with the mail. Now is
>> there a possibility to have my dynamic delivery module tell courier to
>> pipe the mail through SpamAssassin (or spamc, to be more accurate) and
>> continue delivery with the output of spamc?

GM> Before your other rules:
GM> xfilter "spamc"

So I'm forced to use maildrop... I would have preferred doing without
it. I'm not entirely sure how to tie maildrop and dynamic delivery
instructions together, either.

The dynamic delivery facility is too nice not to use. But if I pipe
mail into maildrop, I seem to be losing that facility as I can't feed
the output of maildrop back to the dot-courier part. If I could, I
wouldn't have to use maildrop in first place...

GM> just create a "hosteddomains" file under esmtpacceptmailfor.dir and make
GM> /etc/courier/hosteddomains a symlink to it.  That way, you only have one 
GM> file in which to list your domains.  Simple, no?

No. Postfix is simple as you can save that sort of stuff in the DB as
well, making it unnecessary to ever interface with the FS directly
(well, deleting accounts is the only point where something would need
to be triggered as Postfix will create maildirs on the fly if they
don't exist). But the alias features of postfix are utterly broken,
else I'd be using it as MTA and courierpop/imap for retrieval of mail.

Regards,
Gabriel

[cgiwrap-users] Re[2]: [courier-users] SpamAssassin integration

[Gabriel A. <ga...@bu...>]

Hi Anand Buddhdev,
you wrote.

AB> These notes are nice, but they show us how to use SpamAssassin with
AB> maildrop, *after* the message has already entered the mail system.
AB> What would be better to do is not to accept the junk in the first
AB> place, and reject it at the SMTP dialogue, which is what Gabriel was
AB> asking about.


Actually, not.

You can't use SpamAssassin on messages that aren't on your system yet,
it needs the message to do it checks. But I don't want to use
maildrop.

Essentially, I just want to pipe everything coming out of smtpd
through SpamAssassin and then hand it to the queue.


Regards,
Gabriel

[cgiwrap-users] Rewriting of directory indexes / Security implications

[Gabriel A. <ga...@bu...>]

Hi,
I'm stumbling over a probably rather easily solved problem with my
rewrite rules:

RewriteEngine On
RewriteRule (.*\.php.*) /cgi-sys/cgiwrap/user/$1 [PT,NS,T=application/x-http-cgi]
RewriteRule (.*\.cgi.*) /cgi-sys/cgiwrap/user/$1 [PT]

works perfectly for anything but the directory index (that is
index.cgi and index.php in our case, of course index.html still
works ;-) as cgiwrap doesn't seem to know that it should look for
index. whatever in case the final element of a path is a directory.
So now I'm wondering how to rewrite the URL to get that working or
would I have to patch cgiwrap to do that?


Furthermore, is there anything cgiwrap does against the following:
.htaccess auth required users accessing private/somescript.cgi by
simply using cgiwrap to execute the script? It's a known problem with
PHP that if you have it installed in the cgi-bin it might very well
expose your whole site to everyone who cares to look as it ignores
.htaccess.

Is .htaccess checked before a rewrite is done? If it were, I could
simply stop users from directly using cgiwrap and be on the safe side,
right?

Thanks for any comments,
Gabriel

[cgiwrap-users] (no subject)

[Nick P. <ni...@su...>]

Hello,

Got a simple question I hope.

I have setup a VirtualHost and setup a script alias to for the domains 
cgi-bin directory. Is it possible to wrap all scripts to one user/group in 
the cgi-bin directory (like one would do with suexec "User/Group" under the 
VirtualHost).

I'v tried a few things but didn't manage to get it working properly, the 
userdir is wrapped properly though.

The reason why I want to use Cgiwrap is that I can disable wrapping via 
.htaccess for openwebmail, which I don't want wrapped.

Hope someone can help me, thanks!

Nick

Re: Re[4]: [cgiwrap-users] cgiwrap 3.8 beta PHP rewriting troubles

[Nathan N. <nn...@um...>]

script_url patch modified and applied. Not going to apply the other -
strikes me as dangerous as it falls back to trying to do something that
the caller might not have intended. Not sure why anyone would need to
refer to users with their UID. If their username is numeric, it should
already work with existing code.

-- Nathan

On Sat, 2003-05-17 at 09:00, Gabriel Ambuehl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Hello Nathan,
> 
> Saturday, May 17, 2003, 2:34:58 PM, you wrote:
> 
> 
> >> What do you call regular scripts? Stuff in ScriptAlias directories?
> >> Users don't have access to ScriptAlias. I'll probably store cgiwrap
> in
> >> cgiwrap/cgiwrap as to not interfere with users's own cgi-bin (which
> >> right now is suexec and ExecCGI but I suppose I can dump ExecCGI
> >> anyway).
> 
> > Anything that would allow a regular user to execute code under their
> > control and have it run as the server userid.
> 
> Ah well I'm aware of that of course.
> 
> 
> Here's a patch I'd like to see integrated. It allows for
> numerical userids (some people love those):
> 
> - --- cgiwrap-3.8-rc1/cgiwrap.c   Tue May 13 17:54:49 2003
> +++ cgiwrap.c   Sat May 17 15:32:16 2003
> @@ -109,7 +109,10 @@
>         /* user - fetch this information from the passwd file or NIS
> */
>         if ( !(user = getpwnam(userStr)) )
>         {
> - -               MSG_Error_NoSuchUser(userStr);
> +               if ( !(user = getpwuid( atoi(userStr) )) )
> +               {
> +                       MSG_Error_NoSuchUser(userStr);
> +               }
>         }
>         memcpy(&Context.user, user, sizeof(struct passwd));
> 
> 
> 
> Another thing I'd like would be an option to set SCRIPT_NAME to the
> value of SCRIPT_VALUE. I there might have messed up something with
> configure.in, I HATE working with autoconf.
> 
> 
> - --- cgiwrap-3.8-rc1/configure.in        Tue May 13 17:54:49 2003
> +++ cgiwrap-3.8-rc1_bak/configure.in    Sat May 17 15:26:01 2003
> @@ -50,6 +50,26 @@
>                 AC_MSG_RESULT([disabled])
>         ])
> 
> +dnl
> +dnl Set SCRIPT_NAME to SCRIPT_URL
> +dnl
> +AC_MSG_CHECKING(for script-url-equals-script-name)
> +AC_ARG_WITH( script-url-equals-script-name,
> +        [  --with-script-url-equals-script-name]
> +        [  set SCRIPT_NAME to SCRIPT_URL, with Apache, SCRIPT_URL
> will be the path the user supplied],
> +        [
> +                if test "x$withval" != xno; then
> +                        AC_DEFINE(CONF_SCRIPT_URL_EQUALS_SCRIPT_NAME,
> [], [set SCRIPT_NAME to SCRIPT_URL, with Apache, SCRIPT_URL will be
> the path the user supplied])
> +                        AC_MSG_RESULT([enabled])
> +                else
> +                        AC_MSG_RESULT([disabled])
> +                fi
> +        ],
> +        [
> +                AC_MSG_RESULT([disabled])
> +        ])
> +
> +
>  AC_MSG_CHECKING(for require-redirect-url)
>  AC_ARG_WITH( require-redirect-url,
>         [  --with-require-redirect-url]
> 
> diff -u cgiwrap-3.8-rc1/util.c cgiwrap-3.8-rc1_bak/util.c
> - --- cgiwrap-3.8-rc1/util.c      Tue May 13 17:54:50 2003
> +++ cgiwrap-3.8-rc1_bak/util.c  Sat May 17 15:39:37 2003
> @@ -1288,6 +1288,16 @@
>                 return;
>         }
>  #endif
> +#if defined(CONF_SCRIPT_URL_EQUALS_SCRIPT_NAME)
> +       name = getenv("SCRIPT_URL");
> +       if ( name ) {
> +               buf = (char*) SafeMalloc (strlen("SCRIPT_NAME=") +
> strlen(name) + 3, "new SCRIPT_NAME environment variable");
> +               sprintf(buf, "SCRIPT_NAME=%s", name);
> +               SafePutenv(buf,  "set SCRIPT_NAME environment
> variable");
> +               return;
> +       }
> +
> +#endif
> 
>         name = getenv("SCRIPT_NAME");
>         if ( name ) {
> 
> 
> 
> 
> 
> Best regards,
>  Gabriel
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 6.0.2i
> 
> iQEVAwUBPsYyecZa2WpymlDxAQHMOQf+OKAPC2i7YbXh5dc9r944kVQj3sh40rms
> 4jF/X0kJrrgcaXmXsHXhw8C9ve5knvBZMp9BS6XEBngHUGe75DhoTwObZqQlRLQ0
> Qz36vRm6kOv4Ti1PHRmc5CuucfYP6byoPE+e85QznObdX14DvkvlwX/8QgOPrJrR
> 6DiIodjJZRaO8aabI0oSxUlih8mX9hYjAMuEt0M7SstnJbd8Z5+laIX/c6Qrum8C
> mFsDM7V/zMMnYn+XC4Yc9e/yMsXk761JzvsaMo02Rh5Q2mX0koIxJWjMLXHgB5h5
> p/D3N6hxFc8qGMNmFBE3VkKhjzv4CU/QCQi7KHoIdSvPLDwVOQMIVw==
> =5td0
> -----END PGP SIGNATURE-----
-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

Re: [cgiwrap-users] cgiwrap 3.8 beta PHP rewriting troubles

[Nathan N. <nn...@um...>]

On Sat, 2003-05-17 at 05:23, Gabriel Ambuehl wrote:
> Hi,
> I there have some trouble with mod_rewrite and PHP. cgiwrap works
> charmingly on its own, so
> /cgi-bin/cgiwrap/user/phpinfo.php
> which contains
> <? phpinfo(); ?>
> will have cgiwrap execute php and returns the corrent phpinfo page.
> The PHP script is neither executable nor does it contain the path to
> the PHP interpreter, so far, so good.
> Normal Perl CGI Scripts work, too.
> 
> Furthermore, I have the following rewrite rules:
> 
> RewriteEngine On
> RewriteRule (.*\.php.*) /cgi-bin/cgiwrap/user/$1 [PT]
> RewriteRule (.*\.cgi.*) /cgi-bin/cgiwrap/user/$1 [PT]

Change to add the extra parms like:

RewriteRule ^/pubd/(.*) /cgi-bin/cgiwrapd/helpweb/$1
[PT,NS,T=application/x-http-cgi]

Or us "R" instead of "PT". 

> Now Perl and Python .cgi scripts work perfectly when called as /script.cgi
> but if I try to access /phpinfo.php the server will return the cgiwrap
> binary! If I change phpinfo.php to contain the path to PHP and be
> executable, thus making it to a normal CGI script and renaming it
> accordingly, I still get the cgiwrap binary back to the browser.

Note - you should also make sure to NOT allow regular scripts to be
editable/installable by other than root - or you'll be creating a gaping
security hole, since they can they invoke cgiwrap directly and alter
environment that calls other scripts. 

> This particular machine is running FreeBSD 5.1 and Apache 2.0.45
> (prefork).
> 
> I'd really appreciate any pointers on this!
> 
> 
> Regards and TIA,
> Gabriel
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: If flattening out C++ or Java
> code to make your application fit in a relational database is painful, 
> don't do it! Check out ObjectStore. Now part of Progress Software.
> http://www.objectstore.net/sourceforge
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

[cgiwrap-users] cgiwrap 3.8 beta PHP rewriting troubles

[Gabriel A. <ga...@bu...>]

Hi,
I there have some trouble with mod_rewrite and PHP. cgiwrap works
charmingly on its own, so
/cgi-bin/cgiwrap/user/phpinfo.php
which contains
<? phpinfo(); ?>
will have cgiwrap execute php and returns the corrent phpinfo page.
The PHP script is neither executable nor does it contain the path to
the PHP interpreter, so far, so good.
Normal Perl CGI Scripts work, too.

Furthermore, I have the following rewrite rules:

RewriteEngine On
RewriteRule (.*\.php.*) /cgi-bin/cgiwrap/user/$1 [PT]
RewriteRule (.*\.cgi.*) /cgi-bin/cgiwrap/user/$1 [PT]


Now Perl and Python .cgi scripts work perfectly when called as /script.cgi
but if I try to access /phpinfo.php the server will return the cgiwrap
binary! If I change phpinfo.php to contain the path to PHP and be
executable, thus making it to a normal CGI script and renaming it
accordingly, I still get the cgiwrap binary back to the browser.

This particular machine is running FreeBSD 5.1 and Apache 2.0.45
(prefork).

I'd really appreciate any pointers on this!


Regards and TIA,
Gabriel

[cgiwrap-users] Re: release candidate for cgiwrap-3.8 available on sourceforge

[Nathan N. <nn...@um...>]

One thing I was wondering about before I release this... Would the php
interpreter support be better if optionally could be configured to only
be in effect if the script in question was not already marked
executable? Maybe --with-php-nonexec-only?

Obviously for most cases this wouldn't be applicable, but for testing
new php installs/etc. it might be beneficial to be able to override the
php path with a #! line...

-- Nathan

On Tue, 2003-05-13 at 13:11, Neulinger, Nathan wrote:
> A release candidate for cgiwrap-3.8 is available on the sourceforge
> files page for the cgiwrap project:
> 
> http://sourceforge.net/project/showfiles.php?group_id=8209
> 
> Please try it out and report any problems/suggestions asap so I can get
> any fixes needed into 3.8 release. 
> 
> Tuc/TTSG Internet Services ( http://www.ttsg.com ) generously sponsored
> most of the recent changes to cgiwrap. If you're in the market for
> professional hosting/colocation services, give them a call or check out
> their website! 
> 
> Changes in this release:
> 
>   New in version 3.8:
> 
>      * Merged in special handling for PHP scripts by popular demand.
> This
>        is  based  mostly  on Piotr Klaban's php-cgiwrap patch, with
> minor
>        changes.
>      * Added   options   for   php  support.  --with-php-interpreter
> and
>        --with-php-cgiwrap
>      * Rewrote the path translated support. Is it finally correct?
>      * Patch  from  sa...@co...  to use REDIRECT_URL if
> available
>        for SCRIPT_NAME.
>      * Added support for access control files specific to each
> HTTP_HOST,
>        useful  for  ISP's using Apache handlers to run cgi's that want
> to
>        restrict  which  userids  can  run  cgi's  on  certain  vhosts.
> If
>        enabled, the vhost access control files must exist.
>      * Added   option  to  require  that  REDIRECT_URL  be  specified
> in
>        environment.  Can be used to require that cgiwrap be invoked via
> a
>        handler/action  or some other internal apache
> redirection/rewrite.
>        Primarily  of  use  when  invoking  cgi's  for  virtual  hosts
> via
>        Action/SetHandler.
>      * Modified  san's REDIRECT_URL support to be
> --with-use-redirect-url
>        instead of --with-check-redirect-url, since it's more a
> functional
>        change, not a security check.
>      * Added   a   --with-quiet-errors   option  to  allow
> significantly
>        restricting  the  amount  of  internal  information  that an
> error
>        message displays.
>      * Added  ability  to  override  the  vhost that cgiwrap users via
> an
>        optional  CGIWRAP_AUTH_VHOST env var, which if present and
> feature
>        enabled,  will  be  used  instead of HTTP_HOST. This is useful
> for
>        when   you   have  wildcard  servernames  in  apache.  Enable
> the
>        --with-vhost-override  option  if  you want this capabillity.
> Only
>        applicable if vhost allow/deny dir is enabled.
>      * Added  ability  to  only allow scripts run by a specific userid
> if
>        the   CGIWRAP_REQUIRE_USER   env   var   is   specified   and
> the
>        --with-env-require-user feature is enabled.
>      * Changed to autoconf 2.5 style templates and eliminated
> acconfig.h.
> 
> 
> If you're an ISP using cgiwrap, some of the above can be very helpful. 
> 
> -- Nathan
> 
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nn...@um...
> University of Missouri - Rolla         Phone: (573) 341-4841
> Computing Services                       Fax: (573) 341-4216
-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

[cgiwrap-users] release candidate for cgiwrap-3.8 available on sourceforge

[Neulinger, N. <nn...@um...>]

A release candidate for cgiwrap-3.8 is available on the sourceforge
files page for the cgiwrap project:

http://sourceforge.net/project/showfiles.php?group_id=3D8209

Please try it out and report any problems/suggestions asap so I can get
any fixes needed into 3.8 release.=20

Tuc/TTSG Internet Services ( http://www.ttsg.com ) generously sponsored
most of the recent changes to cgiwrap. If you're in the market for
professional hosting/colocation services, give them a call or check out
their website!=20

Changes in this release:

  New in version 3.8:

     * Merged in special handling for PHP scripts by popular demand.
This
       is  based  mostly  on Piotr Klaban's php-cgiwrap patch, with
minor
       changes.
     * Added   options   for   php  support.  --with-php-interpreter
and
       --with-php-cgiwrap
     * Rewrote the path translated support. Is it finally correct?
     * Patch  from  sa...@co...  to use REDIRECT_URL if
available
       for SCRIPT_NAME.
     * Added support for access control files specific to each
HTTP_HOST,
       useful  for  ISP's using Apache handlers to run cgi's that want
to
       restrict  which  userids  can  run  cgi's  on  certain  vhosts.
If
       enabled, the vhost access control files must exist.
     * Added   option  to  require  that  REDIRECT_URL  be  specified
in
       environment.  Can be used to require that cgiwrap be invoked via
a
       handler/action  or some other internal apache
redirection/rewrite.
       Primarily  of  use  when  invoking  cgi's  for  virtual  hosts
via
       Action/SetHandler.
     * Modified  san's REDIRECT_URL support to be
--with-use-redirect-url
       instead of --with-check-redirect-url, since it's more a
functional
       change, not a security check.
     * Added   a   --with-quiet-errors   option  to  allow
significantly
       restricting  the  amount  of  internal  information  that an
error
       message displays.
     * Added  ability  to  override  the  vhost that cgiwrap users via
an
       optional  CGIWRAP_AUTH_VHOST env var, which if present and
feature
       enabled,  will  be  used  instead of HTTP_HOST. This is useful
for
       when   you   have  wildcard  servernames  in  apache.  Enable
the
       --with-vhost-override  option  if  you want this capabillity.
Only
       applicable if vhost allow/deny dir is enabled.
     * Added  ability  to  only allow scripts run by a specific userid
if
       the   CGIWRAP_REQUIRE_USER   env   var   is   specified   and
the
       --with-env-require-user feature is enabled.
     * Changed to autoconf 2.5 style templates and eliminated
acconfig.h.


If you're an ISP using cgiwrap, some of the above can be very helpful.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

RE: [cgiwrap-users] new features in cgiwrap cvs

[Jeff B. <soi...@sg...>]

Excellent... Thanks for the continued development of cgiwrap!

> 
> A few new features have been committed to cvs build of 
> cgiwrap in the past week or so. Here's a snippet from changes.html:
> 
> 
>   New in version 3.8:
> 
>      * Merged in special handling for PHP scripts by popular 
> demand. This
>        is  based  mostly  on Piotr Klaban's php-cgiwrap 
> patch, with minor
>        changes.
>      * Added   options   for   php  support.  --with-php-interpreter
> and
>        --with-php-cgiwrap
>      * Rewrote the path translated support. Is it finally correct?
>      * Patch  from  sa...@co...  to use REDIRECT_URL 
> if available
>        for SCRIPT_NAME.
> 
> stuff added recently:
>      * Added support for access control files specific to 
> each HTTP_HOST,
>        useful  for  ISP's using Apache handlers to run cgi's 
> that want to
>        restrict  which  userids  can  run  cgi's  on  certain 
>  vhosts. If
>        enabled, the vhost access control files must exist.
>      * Added   option  to  require  that  REDIRECT_URL  be  specified
> in
>        environment.  Can be used to require that cgiwrap be 
> invoked via a
>        handler/action  or some other internal apache 
> redirection/rewrite.
>        Primarily  of  use  when  invoking  cgi's  for  
> virtual  hosts via
>        Action/SetHandler.
>      * Modified  san's REDIRECT_URL support to be 
> --with-use-redirect-url
>        instead of --with-check-redirect-url, since it's more 
> a functional
>        change, not a security check.
>      * Added   a   --with-quiet-errors   option  to  allow
> significantly
>        restricting  the  amount  of  internal  information  
> that an error
>        message displays.
>      * Added  ability  to  override  the  vhost that cgiwrap 
> users via an
>        optional  CGIWRAP_AUTH_VHOST env var, which if present 
> and feature
>        enabled,  will  be  used  instead of HTTP_HOST. This 
> is useful for
>        when   you   have  wildcard  servernames  in  apache.  Enable
> the
>        --with-vhost-override  option  if  you want this 
> capabillity. Only
>        applicable if vhost allow/deny dir is enabled.
>      * Added  ability  to  only allow scripts run by a 
> specific userid if
>        the   CGIWRAP_REQUIRE_USER   env   var   is   specified   and
> the
>        --with-env-require-user feature is enabled.
> 
> These changes are mostly of use to folks that are doing 
> managed hosting/virtual hosts/etc. with cgiwrap behind the scenes. 
> 
> As soon as the sponsor of these changes is finished testing 
> them, I'll probably try and do a 3.8 release tarball. 
> 
> -- Nathan
> 
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nn...@um...
> University of Missouri - Rolla         Phone: (573) 341-4841
> Computing Services                       Fax: (573) 341-4216
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
> 

[cgiwrap-users] new features in cgiwrap cvs

[Neulinger, N. <nn...@um...>]

A few new features have been committed to cvs build of cgiwrap in the
past week or so. Here's a snippet from changes.html:


  New in version 3.8:

     * Merged in special handling for PHP scripts by popular demand.
This
       is  based  mostly  on Piotr Klaban's php-cgiwrap patch, with
minor
       changes.
     * Added   options   for   php  support.  --with-php-interpreter
and
       --with-php-cgiwrap
     * Rewrote the path translated support. Is it finally correct?
     * Patch  from  sa...@co...  to use REDIRECT_URL if
available
       for SCRIPT_NAME.

stuff added recently:
     * Added support for access control files specific to each
HTTP_HOST,
       useful  for  ISP's using Apache handlers to run cgi's that want
to
       restrict  which  userids  can  run  cgi's  on  certain  vhosts.
If
       enabled, the vhost access control files must exist.
     * Added   option  to  require  that  REDIRECT_URL  be  specified
in
       environment.  Can be used to require that cgiwrap be invoked via
a
       handler/action  or some other internal apache
redirection/rewrite.
       Primarily  of  use  when  invoking  cgi's  for  virtual  hosts
via
       Action/SetHandler.
     * Modified  san's REDIRECT_URL support to be
--with-use-redirect-url
       instead of --with-check-redirect-url, since it's more a
functional
       change, not a security check.
     * Added   a   --with-quiet-errors   option  to  allow
significantly
       restricting  the  amount  of  internal  information  that an
error
       message displays.
     * Added  ability  to  override  the  vhost that cgiwrap users via
an
       optional  CGIWRAP_AUTH_VHOST env var, which if present and
feature
       enabled,  will  be  used  instead of HTTP_HOST. This is useful
for
       when   you   have  wildcard  servernames  in  apache.  Enable
the
       --with-vhost-override  option  if  you want this capabillity.
Only
       applicable if vhost allow/deny dir is enabled.
     * Added  ability  to  only allow scripts run by a specific userid
if
       the   CGIWRAP_REQUIRE_USER   env   var   is   specified   and
the
       --with-env-require-user feature is enabled.

These changes are mostly of use to folks that are doing managed
hosting/virtual hosts/etc. with cgiwrap behind the scenes.=20

As soon as the sponsor of these changes is finished testing them, I'll
probably try and do a 3.8 release tarball.=20

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

RE: [cgiwrap-users] Cgiwrap with mod_userdir?

[Jeff B. <soi...@sg...>]

Excellent that works, thank you.

Also, I found that calling them from SSI with "#include virtual" I =
needed to
call it:

<!-- #include virtual=3D"/cgi-sys/cgiwrap/~user/script.cgi" -->

Where /cgi-sys/ is my system cgi-bin that hold the cgiwrap executables.

Jeff

>=20
> mod_userdir is the usual way it is used. Adjust your url:
>=20
> http://www/cgi-bin/cgiwrap/~user/script.cgi
>=20
> to run script.cgi in the (by default and assumine homedirs in=20
> /home) /home/user/public_html/cgi-bin/ directory.=20
>=20
> -- Nathan
>=20
> On Thu, 2003-05-01 at 18:43, Jeff Bert wrote:
> > Is it possible to use cgiwrap with mod_userdir.c ~=20
> directory when it's=20
> > called via:
> >=20
> >=20
> http://www.topleveldomain.com/~user/rel-path-> =
to-cgiwrap/cgiwrap/script
> > .cgi
> >=20

Re: [cgiwrap-users] Cgiwrap with mod_userdir?

[Nathan N. <nn...@um...>]

mod_userdir is the usual way it is used. Adjust your url:

http://www/cgi-bin/cgiwrap/~user/script.cgi

to run script.cgi in the (by default and assumine homedirs in /home)
/home/user/public_html/cgi-bin/ directory. 

-- Nathan

On Thu, 2003-05-01 at 18:43, Jeff Bert wrote:
> Is it possible to use cgiwrap with mod_userdir.c ~ directory when it's
> called via:
> 
> http://www.topleveldomain.com/~user/rel-path-to-cgiwrap/cgiwrap/script.cgi
> 
> I haven't been able to get it to work yet although I can setup domain names
> that go directly to the same folder as the "userdir" and it can work from
> that.  But, I was also hoping to get it to work for sites that are using
> mod_userdir
> 
> Thx,
> 
> Jeff
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

[cgiwrap-users] Cgiwrap with mod_userdir?

[Jeff B. <soi...@sg...>]

Is it possible to use cgiwrap with mod_userdir.c ~ directory when it's
called via:

http://www.topleveldomain.com/~user/rel-path-to-cgiwrap/cgiwrap/script.cgi

I haven't been able to get it to work yet although I can setup domain names
that go directly to the same folder as the "userdir" and it can work from
that.  But, I was also hoping to get it to work for sites that are using
mod_userdir

Thx,

Jeff

Re: [cgiwrap-users] Re: Help for latest security-fix to cgiwrap

[Nathan N. <nn...@um...>]

Which I've done... but definately doesn't warrant anything more than a
cvs commit. 

Thanks for the comments.

-- Nathan

On Thu, 2003-04-24 at 06:46, Peter M. Jansson wrote:
> On Wednesday, April 23, 2003, at 07:01 PM, Nathan Neulinger wrote:
> 
> > If you're referring to the bugtraq posting today, that's not a security
> > fix. It's a totally un-necessary change merely to shut up automated
> > security scan programs that are too stupid to see that something is
> > perfectly safe.
> >
> 
> > char *x = "my message here";
> > printf(x);
> >
> > and
> >
> > printf("my message here");
> 
> > are both perfectly safe.
> 
> Nathan,
> 
> I agree that what you've done is perfectly safe...for now.  The worry I 
> see is that maintainers have to take care with the content of the messages 
> to prevent exposures.  For example, a simple typo, such as changing a 
> message to "This is 100%safe" could cause a problem if the message is 
> passed as the first argument of either printf or syslog. I'm not saying 
> that you won't be careful, but you remove a possible source of error if 
> you change this:
> 
> 	char *x = "my message here";
> 	printf(x);
> 
> to this:
> 
> 	char *x = "my message here";
> 	printf("%s", x);
> 
> or even this:
> 
> 	#define SYSLOG_MSG_MAX	2048
> 	char *x = "my message here";
> 	printf("%.*s", SYSLOG_MSG_MAX, x);
> 
> I think the ongoing maintenance issue is the one worth any concern, not 
> the "can I exploit this today" issue.  From an engineering perspective, I 
> believe there is some value in being able to say that you've removed the 
> possibility for someone to make that mistake in the future.
> 
> Regards,
> 	Pete.
-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

Re: [cgiwrap-users] Re: Help for latest security-fix to cgiwrap

[Peter M. J. <pe...@cl...>]

On Wednesday, April 23, 2003, at 07:01 PM, Nathan Neulinger wrote:

> If you're referring to the bugtraq posting today, that's not a security
> fix. It's a totally un-necessary change merely to shut up automated
> security scan programs that are too stupid to see that something is
> perfectly safe.
>

> char *x = "my message here";
> printf(x);
>
> and
>
> printf("my message here");

> are both perfectly safe.

Nathan,

I agree that what you've done is perfectly safe...for now.  The worry I 
see is that maintainers have to take care with the content of the messages 
to prevent exposures.  For example, a simple typo, such as changing a 
message to "This is 100%safe" could cause a problem if the message is 
passed as the first argument of either printf or syslog. I'm not saying 
that you won't be careful, but you remove a possible source of error if 
you change this:

	char *x = "my message here";
	printf(x);

to this:

	char *x = "my message here";
	printf("%s", x);

or even this:

	#define SYSLOG_MSG_MAX	2048
	char *x = "my message here";
	printf("%.*s", SYSLOG_MSG_MAX, x);

I think the ongoing maintenance issue is the one worth any concern, not 
the "can I exploit this today" issue.  From an engineering perspective, I 
believe there is some value in being able to say that you've removed the 
possibility for someone to make that mistake in the future.

Regards,
	Pete.

[cgiwrap-users] Re: Help for latest security-fix to cgiwrap

[Nathan N. <nn...@um...>]

I'm still doing cgiwrap... cgiwrap is for the most part a stable
product, it doesn't see much activity, cause none is needed.

Is there something specific you were concerned about?

If you're referring to the bugtraq posting today, that's not a security
fix. It's a totally un-necessary change merely to shut up automated
security scan programs that are too stupid to see that something is
perfectly safe.


char *x = "my message here";
printf(x);

and

printf("my message here");


are both perfectly safe. But those automated security scan tools look at
the first one and think "He's using a printf without a separate format
string - that MUST be a format string vulnerability." when in fact, it's
perfectly legitimate safe code. 

Best place to send support questions is 

cgi...@li...

If there's something else you're concerned about, let me know. 

-- Nathan

On Wed, 2003-04-23 at 17:17, Stefan Neufeind wrote:
> Hi Nathan,
> 
> who is NOW responsible for CGIwrap? Who will incorporate fixes etc.? 
> As I see your website:
> 	http://cgiwrap.sourceforge.net/
> hasn't been updated for quite a time. Our company would offer you to 
> continue the work (applying patches etc.) that you did in the past.
> 
> Let me please know what you think about it.
> 
> 
> Yours sincerely,
>  Stefan Neufeind
> 
> ****************************************************
> SpeedPartner, Inh. Michael Metz
> Neukirchener Str. 57, 41470 Neuss, Germany
> Tel.: +49-2137 / 929 832, Fax: +49-2137 / 137 17
> E-Mail: in...@sp...
> ****************************************************
-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

RE: [cgiwrap-users] RE: Format strings vuln in CGIwrap

[Neulinger, N. <nn...@um...>]

In any case, I've changed this in cvs so as to avoid setting off any
future false-alarms.=20

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Neulinger, Nathan=20
> Sent: Wednesday, April 23, 2003 11:59 AM
> To: b0f www.b0f.net; bu...@se...
> Cc: cgi...@li...
> Subject: [cgiwrap-users] RE: Format strings vuln in CGIwrap
>=20
>=20
> This is not a security problem. This is a case of using an automated
> tool to find these vulnerabilites and not attempting to understand the
> code itself.=20
>=20
> Nowhere in the code is MSG_Error_General() passed anything=20
> other than a
> static compiled-into-the-executable string. It's purely a utility
> function to wrap common error text/footer/etc. around a=20
> generic string.
>=20
> -- Nathan
>=20
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nn...@um...
> University of Missouri - Rolla         Phone: (573) 341-4841
> Computing Services                       Fax: (573) 341-4216
>=20
>=20
> > -----Original Message-----
> > From: security-bounces+nneul=3Du...@li...=20
> > [mailto:security-bounces+nneul=3Du...@li...] On=20
> > Behalf Of b0f www.b0f.net
> > Sent: Wednesday, April 23, 2003 11:06 AM
> > To: bu...@se...
> > Subject: Format strings vuln in CGIwrap
> >=20
> >=20
> >=20
> >=20
> > A locally and possibly remotely exploitable format
> > strings bug exists=20
> > in cgiwrap available from =20
> > http://cgiwrap.sourceforge.net/
> > http://sourceforge.net/projects/cgiwrap
> > http://www.freebsd.org/ports/security.html=20
> >=20
> > I. BACKGROUND
> >=20
> > This is CGIWrap - a gateway that allows more secure
> > user access to
> > CGI programs on an HTTPd server than is provided by the
> > http server
> > itself. The primary function of CGIWrap is to make
> > certain that
> > any CGI script runs with the permissions of the user
> > who installed
> > it, and not those of the server.
> >=20
> > CGIWrap works with NCSA httpd, Apache, CERN httpd,
> > NetSite Commerce
> > and Communications servers, and probably any other Unix
> > based web
> > server software that supports CGI.
> >=20
> > II. DESCRIPTION
> >=20
> > On line 91 of msgs.c the printf() function is used
> > incorrectly. Which=20
> > results
> > in a format strings vulnerability.
> > <snip>
> > void MSG_Error_General(char *message)
> > {
> >         MSG_Header("CGIWrap Error", message);
> >         printf(message);=20
> >         MSG_Footer();
> >         exit(1);
> > }
> > </snip>
> >=20
> > The binaries in cgiwrap, (cgiwrap and nph-cgiwrap) are
> > installed setuid=20
> > root.
> > Thus could make this format problem exploitable locally
> > to gain root=20
> > privs or
> > possably remotely to gain root or the privs of the user
> > who owns the cgi=20
> > script.
> >=20
> > III. ANALYSIS
> > An attacker could exploit this issue to escalate privs
> > locally or=20
> > remotely on
> > a server running cgiwrap.
> >=20
> > IV. DETECTION
> >=20
> > This is vulnerable in the latest version of cgiwrap
> > version 3.7.1 and=20
> > properly
> > older versions(not checked). It would be exploitable on
> > any Linux/Unix=20
> > based OS
> > running cgiwrap=20
> >=20
> > V. VENDOR
> > The vendor has not been contacted about this issue.
> >=20
> > Regards
> > b0f  (Alan M)
> > www.b0f.net
> > _______________________________________________
> > UMR Security List Exploder
> > sec...@li...
> > https://lists.umr.edu/mailman/listinfo/security
> >=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> cgiwrap-users mailing list
> cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgiwrap-users
>=20

[cgiwrap-users] RE: Format strings vuln in CGIwrap

[Neulinger, N. <nn...@um...>]

This is not a security problem. This is a case of using an automated
tool to find these vulnerabilites and not attempting to understand the
code itself.=20

Nowhere in the code is MSG_Error_General() passed anything other than a
static compiled-into-the-executable string. It's purely a utility
function to wrap common error text/footer/etc. around a generic string.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: security-bounces+nneul=3Du...@li...=20
> [mailto:security-bounces+nneul=3Du...@li...] On=20
> Behalf Of b0f www.b0f.net
> Sent: Wednesday, April 23, 2003 11:06 AM
> To: bu...@se...
> Subject: Format strings vuln in CGIwrap
>=20
>=20
>=20
>=20
> A locally and possibly remotely exploitable format
> strings bug exists=20
> in cgiwrap available from =20
> http://cgiwrap.sourceforge.net/
> http://sourceforge.net/projects/cgiwrap
> http://www.freebsd.org/ports/security.html=20
>=20
> I. BACKGROUND
>=20
> This is CGIWrap - a gateway that allows more secure
> user access to
> CGI programs on an HTTPd server than is provided by the
> http server
> itself. The primary function of CGIWrap is to make
> certain that
> any CGI script runs with the permissions of the user
> who installed
> it, and not those of the server.
>=20
> CGIWrap works with NCSA httpd, Apache, CERN httpd,
> NetSite Commerce
> and Communications servers, and probably any other Unix
> based web
> server software that supports CGI.
>=20
> II. DESCRIPTION
>=20
> On line 91 of msgs.c the printf() function is used
> incorrectly. Which=20
> results
> in a format strings vulnerability.
> <snip>
> void MSG_Error_General(char *message)
> {
>         MSG_Header("CGIWrap Error", message);
>         printf(message);=20
>         MSG_Footer();
>         exit(1);
> }
> </snip>
>=20
> The binaries in cgiwrap, (cgiwrap and nph-cgiwrap) are
> installed setuid=20
> root.
> Thus could make this format problem exploitable locally
> to gain root=20
> privs or
> possably remotely to gain root or the privs of the user
> who owns the cgi=20
> script.
>=20
> III. ANALYSIS
> An attacker could exploit this issue to escalate privs
> locally or=20
> remotely on
> a server running cgiwrap.
>=20
> IV. DETECTION
>=20
> This is vulnerable in the latest version of cgiwrap
> version 3.7.1 and=20
> properly
> older versions(not checked). It would be exploitable on
> any Linux/Unix=20
> based OS
> running cgiwrap=20
>=20
> V. VENDOR
> The vendor has not been contacted about this issue.
>=20
> Regards
> b0f  (Alan M)
> www.b0f.net
> _______________________________________________
> UMR Security List Exploder
> sec...@li...
> https://lists.umr.edu/mailman/listinfo/security
>=20

[cgiwrap-users] cgiwrap running suid scripts

[Csaba A. <ma...@ya...>]

How can I configure CGIWRAP to run SETUID scripts? I
have a cobalt RaQ4 server, which gives me 

Can't do setuid
Premature end of script headers:
/home/openwebmail/cgi-bin/openwebmail/openwebmail.pl

,but that scripts needs to be setuid.

Thank you in advance,
Csaba

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

Re: [cgiwrap-users] simple question I HOPE

[Nathan N. <nn...@um...>]

You would need to ask whoever is hosting your domain and cgiwrap since
it would depend on how that particular site has cgi scripts configured. 

On Tue, 2003-04-22 at 16:24, Bec...@ao... wrote:
> why would I ask my isp (msn) they have bothing to do with my domain

-- 

------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

RE: [cgiwrap-users] simple question I HOPE

[Neulinger, N. <nn...@um...>]

You need to address this to the support contacts at your ISP.=20
=20
=20



------------------------------------------------------------
Nathan Neulinger                       EMail:  nn...@um...
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


	-----Original Message-----
	From: Bec...@ao... [mailto:Bec...@ao...]=20
	Sent: Tuesday, April 22, 2003 3:50 PM
	To: cgi...@li...
	Subject: [cgiwrap-users] simple question I HOPE
=09
=09
	I was just wondering what the basic procedure for installing a
ci script is with thw simple cgi wrapper =20
	what  or where is user/bin.perl=20
	does this follow my domain url http://www.beccasheaven.com
	or is this this a path I need to create . . . cause I have never
seen the user/bin/perl/ folders and is the user part actual "user" or my
"screen name"
	Please let me know I have done this befor on TRIPOD and for some
reason it alot nore complicated this time. Also it says I can do it with
my user name does that mean "just by signing in when it pops up thebox
for my screename and pass" por do I need to include my screen name
somewhere in the script?
=09
=09
	Thankyou=20
	a response "in easy to understand but detailed terms"=20
	would  be greatly appreciated . . . Becca=20