You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Pier P. Fumagalli" <pi...@betaversion.org> on 2001/08/18 10:43:46 UTC

CGI wrapper in Tomcat 4.0 b7

Whoha... Just had my nightly report on the server, and thank god it was
running TC40b7 when I had a NESSUS run :)

I got a TON of reports on CGIs installed on the system, and freaked out
AAAHHH someone broke into my server... UNTIL I didn't see a .exe CGI...
What, is it a UNIX or a WINDOWS box? Hmmm... There's something wrong here.

What do I find out? That Tomcat, simply sets the "200 OK" status regardless
whether the CGI exists or not! :) And so PATCH! :)

(Amy, please review and commit!)

    Pier

(BTW, wouldn't it be wise to disable CGI execution in the default
configuration? I don't know, after hearing people running Tomcat as root, I
feel we really should!)

Index: CGIServlet.java
===================================================================
RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets
/CGIServlet.java,v
retrieving revision 1.4
diff -c -3 -r1.4 CGIServlet.java
*** CGIServlet.java     2001/08/14 18:50:10     1.4
--- CGIServlet.java     2001/08/18 08:37:07
***************
*** 632,637 ****
--- 632,638 ----
                  if (cgiEnv.isValid()) {
                      out.println(cgiEnv.toString());
                  } else {
+                     res.setStatus(404);
                      out.println("<H3>");
                      out.println("CGI script not found or not specified.");
                      out.println("</H3>");


Re: CGI wrapper in Tomcat 4.0 b7

Posted by Mark Castillo <ma...@webFreak.com>.
>
> You work for _Counterpane_?!? I am involved in open source Java
cryptography
> projects, and cypto/security is where alot of my experience lies. I am, of
> course, quite familiar with Counterpane. ;-)
>
> You work with Bruce and shit ... damn, what and honor THAT would be :)

Yeah, he's a cool guy. But, i'm not much of a crypto-freak. As you might
know already, we have enough crypto (for now). The bigger problems are in
people processes (sysadmin config), user habits (mail attachment viruses and
such), and coding habits (design and careless server programming).

I usually don't see Bruce on a day-to-day basis, as he works out of his home
in some other state. The other guys from Counterpane labs live in North
Carolina and Netherlands (Niels Ferguson, who recently cracked the Intel
streaming video encryption scheme. hehe). I work at the San Jose
headquarters.

>
> It's a shame that the product won't be publicly available, because as a
> crypto/security nut, I would *love* to see what you Counterpane guys come
up
> with on intrusion detection. I bet it rocks.

Hmmm. Maybe once the company goes belly up like the dot-coms in the area,
we'll release it as "jakarta-sentry" ;-)

>
> > I am the lead Java guy for the event detection engine that runs on the
> > "sentry" intrusion detection box (no GUI, no human interface). We have
plans
> > to allow customers to see the status of their network via an https
interface.
> > The interface will also allow them to chat live with a security analyst
> > (which we have 24/7).
>
> That's cool as hell. I've been working on the Tomcat standalone SSL stuff
these
> days, in some part because my company is also in the process of developing
a
> product (a cluster management tool) which will need it. If you should ever
run
> across anything, or need something, in that department, let us know, and
I'll
> see what I can do =)

Cool. We'll talk more about that in non-list emails. What company is
developing your product?

>
> > Right now we've integrated Acme server (and integrated https and login
> > session support ourselves, which was a royal pain). So, I'm trying to
> > figure out if we want to continue maintaining (fixing/rewriting?) the
Acme
> > server or scrap it and go to something else. We want code that is small
enough
> > to audit (for security), but functional enough to support servlets and
> > secure sessions.
>
> I think Tomcat can definitely accomodate you ;-)

It think it will eventually, after all I only need it to run 2 servlets!

>
> - Christopher


Re: CGI wrapper in Tomcat 4.0 b7

Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting Mark Castillo <ma...@webFreak.com>:
>
> It is not a product that we are planning to have publicly available,
> although we develop it in a commercial release-like fasion. We do have
> the software running on about > 100 customer sites now. The company I work
> for is Counterpane Internet Security (http://www.counterpane.com), and our
> software team builds the tools that provide our monitoring service.

You work for _Counterpane_?!? I am involved in open source Java cryptography 
projects, and cypto/security is where alot of my experience lies. I am, of 
course, quite familiar with Counterpane. ;-)

You work with Bruce and shit ... damn, what and honor THAT would be :)

It's a shame that the product won't be publicly available, because as a 
crypto/security nut, I would *love* to see what you Counterpane guys come up 
with on intrusion detection. I bet it rocks.

> I am the lead Java guy for the event detection engine that runs on the
> "sentry" intrusion detection box (no GUI, no human interface). We have plans
> to allow customers to see the status of their network via an https interface. 
> The interface will also allow them to chat live with a security analyst
> (which we have 24/7).

That's cool as hell. I've been working on the Tomcat standalone SSL stuff these 
days, in some part because my company is also in the process of developing a 
product (a cluster management tool) which will need it. If you should ever run 
across anything, or need something, in that department, let us know, and I'll 
see what I can do =)

> Right now we've integrated Acme server (and integrated https and login
> session support ourselves, which was a royal pain). So, I'm trying to
> figure out if we want to continue maintaining (fixing/rewriting?) the Acme
> server or scrap it and go to something else. We want code that is small enough
> to audit (for security), but functional enough to support servlets and
> secure sessions.

I think Tomcat can definitely accomodate you ;-)

- Christopher

Re: CGI wrapper in Tomcat 4.0 b7

Posted by Mark Castillo <ma...@webFreak.com>.
yes, of course if you have legacy software. No arguments there. As for
regex, that's what ORO is for ;-)

--
Mark Castillo
markc@webFreak.com
http://www.webFreak.com
----- Original Message -----
From: "Jan Labanowski" <jk...@osc.edu>
To: <to...@jakarta.apache.org>
Cc: <jk...@osc.edu>
Sent: Saturday, August 18, 2001 9:36 PM
Subject: Re: CGI wrapper in Tomcat 4.0 b7


> Guys,
> You are getting religious about CGI... Religious is good, but I worry that
> it is a cult {:-)}. CGI was a good thing for last 6 years, and it is a
> still good thing sometimes. Note, we have tons of legacy perl software
> around, and believe me, I can sometimes do more in one line of perl, than
> in a page of Java. Yes, CGI is an "old ways", but it will be here for a
long
> time, since there is so much stuff written in it. I did not look carefully
> at regexp Java syntax, but can you have a
>    s/\b(\d+\.?\d*)C\b/int($1 * 1.8 +32) . "F"/e
> substitution in Java?
>
> I personally think that web server without CGI is not a fully operational
> Web server. End of story...
>
> This is GREAT that CGI is available in Tomcat. You should avoid it, but
> sometimes, if you have a week to move from Apache to Tomcat, you just
> cannot do it, and you need a way to move from CGI to servlets/jsp in an
> organized way.
>



Re: CGI wrapper in Tomcat 4.0 b7

Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting Jan Labanowski <jk...@osc.edu>:

> Guys,
> You are getting religious about CGI... Religious is good, but I worry
> that it is a cult {:-)}. CGI was a good thing for last 6 years, and it is a
> still good thing sometimes.

CGI is a technically _horrible_ solution. The entire process model is 
fundamentally flawed. As far as scaling is concerned, it would be the 
functional equivalent of me synchronizing all access to my middle-tier objects.

> Note, we have tons of legacy perl software around,

IMNSHO, legacy code is the only legitimate reason anyone should run CGI 
anymore. This is 2001.

> and believe me, I can sometimes do more in one line of perl, than
> in a page of Java.

Don't even get me started on my personal feelings about Perl =)

<rant target="Perl">

It's a nice language, and it definitely has some areas where it really shines, 
but it is, after all, a niche language. It is very efficient at what it does, 
but it has been extended WAY beyond its design. This whole trip about Perl 
being "the only language you'll ever need" (I'm not quoting you, just your 
average Perl nut) ... I've heard that line with just about every new language 
that has ever come out, and Perl is much less suited to be my "only language" 
than almost all of the previously-touted "do-all languages".

As far as the tired old "I can do more in one line of Perl than a mountain of 
{pick a language}" ... there's an old saying about Perl: Perl is the only 
language that looks the same before AND after encryption.

Perl can always seem to wash my car, feeds my cats, take my girlfriend out to 
dinner, and get me a beer, all in a single line of code. All I know is, while 
that may be true, if I ever have to end up maintaining one of these 1000-
character lines of code (that resemble what is left on my screen after my cat 
walks across the keyboard), I'm hunting down the guy that wrote it.

</rant>

> Yes, CGI is an "old ways", but it will be here for a long time, since there
> is so much stuff written in it.

That is true, and is the only reason I personally wouldn't like to see it 
removed from Tomcat altogether.

> I did not look carefully at regexp Java syntax, but can you have a
>    s/\b(\d+\.?\d*)C\b/int($1 * 1.8 +32) . "F"/e substitution in Java? 

Again with my cat on the keyboard ;-)

Anyway, as Mark pointed out, that's what jakarta-regexp is for.

> I personally think that web server without CGI is not a fully
> operational Web server. End of story... 

And I suppose that a computer with COBOL support libraries installed is not a 
fully-operational computer. Bottom line: CGI is a dead technology, and 
thankfully so. It was a nice hack in the beginning of time, but it outlived its 
usefulness three years ago, and that's being generous.

> This is GREAT that CGI is available in Tomcat.

That's highly debatable =)

> You should avoid it, but sometimes, if you have a week to move from Apache to
> Tomcat, you just cannot do it, and you need a way to move from CGI to
> servlets/jsp in an organized way.

Agreed. I would have to grudgingly agree that CGI support in Tomcat makes sense 
if only to support legacy code. Anyone writing new CGI programs to be run on a 
Servlet/JSP engine, however, is certifiable.

- Christopher

Re: CGI wrapper in Tomcat 4.0 b7

Posted by Jan Labanowski <jk...@osc.edu>.
Guys,
You are getting religious about CGI... Religious is good, but I worry that
it is a cult {:-)}. CGI was a good thing for last 6 years, and it is a
still good thing sometimes. Note, we have tons of legacy perl software
around, and believe me, I can sometimes do more in one line of perl, than
in a page of Java. Yes, CGI is an "old ways", but it will be here for a long
time, since there is so much stuff written in it. I did not look carefully
at regexp Java syntax, but can you have a
   s/\b(\d+\.?\d*)C\b/int($1 * 1.8 +32) . "F"/e 
substitution in Java? 

I personally think that web server without CGI is not a fully operational
Web server. End of story... 

This is GREAT that CGI is available in Tomcat. You should avoid it, but
sometimes, if you have a week to move from Apache to Tomcat, you just
cannot do it, and you need a way to move from CGI to servlets/jsp in an
organized way.

> Good for you. If I really had a choice, I would not include CGI support at
> all (isn't Tomcat just supposed to be a servlet container?). I don't know of
> anyone who really uses CGI for anything "real" these days. It just sucks for
> high performance sites and larger web applications. Now that we have
> javax.servlet we don't need no stinkin' CGI. Before servlets I was was doing
> CGI in C! yuck.
> 


Jan K. Labanowski            |    phone: 614-292-9279,  FAX: 614-292-7168
Ohio Supercomputer Center    |    Internet: jkl@osc.edu 
1224 Kinnear Rd,             |    http://www.ccl.net/chemistry.html
Columbus, OH 43212-1163      |    http://www.osc.edu/


Re: CGI wrapper in Tomcat 4.0 b7

Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Mark Castillo at markc@webFreak.com wrote:
> 
> Right now we've integrated Acme server (and integrated https and login
> session support ourselves, which was a royal pain). So, I'm trying to figure
> out if we want to continue maintaining (fixing/rewriting?) the Acme server
> or scrap it and go to something else. We want code that is small enough to
> audit (for security), but functional enough to support servlets and secure
> sessions.

Well... Then Embedded in Tomcat 4.0 (yes, o.a stands for org.apache)... You
can basically strip-out all the functionality you don't want from the
standard TC4.0), implement (maybe) your own logger and session manager, and
with a handful of classes, you're set...

    Pier


Re: CGI wrapper in Tomcat 4.0 b7

Posted by Mark Castillo <ma...@webFreak.com>.
>
> Sounds cool, but I'll let someone a little more familiar with CGI speak to
the
> feasibility in Tomcat. I started out my dynamic-content life with ASP
(D'oh!),
> then moved to servlets (Woo-hoo!), so I was rather fortunate in that I got
to
> skip the whole CGI nightmare :-)

Good for you. If I really had a choice, I would not include CGI support at
all (isn't Tomcat just supposed to be a servlet container?). I don't know of
anyone who really uses CGI for anything "real" these days. It just sucks for
high performance sites and larger web applications. Now that we have
javax.servlet we don't need no stinkin' CGI. Before servlets I was was doing
CGI in C! yuck.

>
> > Currently I'm reviewing the Tomcat sources for embedding a servlet
> > engine in our application. The application is part of a distributed
intrusion
> > detection system, which needs some sort of web-based status/admin
> > interface.
>
> Cool! Do you guys have a beta or anything that I could check out yet? I'm
> always interested in checking out software that can help with security!

It is not a product that we are planning to have publicly available,
although we develop it in a commercial release-like fasion. We do have the
software running on about > 100 customer sites now. The company I work for
is Counterpane Internet Security (http://www.counterpane.com), and our
software team builds the tools that provide our monitoring service.  I am
the lead Java guy for the event detection engine that runs on the "sentry"
intrusion detection box (no GUI, no human interface). We have plans to allow
customers to see the status of their network via an https interface.  The
interface will also allow them to chat live with a security analyst (which
we have 24/7).

Right now we've integrated Acme server (and integrated https and login
session support ourselves, which was a royal pain). So, I'm trying to figure
out if we want to continue maintaining (fixing/rewriting?) the Acme server
or scrap it and go to something else. We want code that is small enough to
audit (for security), but functional enough to support servlets and secure
sessions.




Re: CGI wrapper in Tomcat 4.0 b7

Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting Mark Castillo <ma...@webFreak.com>:

> Hi all. I'm new to the list. Sorry if someone has already brought this
> up, but couldn't the code provide some native methods for changing the uid
> of the process after binding to the network ports (if they want to start
> as root, binding to a port < 1024). Then, the CGI executed would run as a non-
> root user. The Jigsaw webserver does this.

Sounds cool, but I'll let someone a little more familiar with CGI speak to the 
feasibility in Tomcat. I started out my dynamic-content life with ASP (D'oh!), 
then moved to servlets (Woo-hoo!), so I was rather fortunate in that I got to 
skip the whole CGI nightmare :-)

> Currently I'm reviewing the Tomcat sources for embedding a servlet
> engine in our application. The application is part of a distributed intrusion
> detection system, which needs some sort of web-based status/admin
> interface.

Cool! Do you guys have a beta or anything that I could check out yet? I'm 
always interested in checking out software that can help with security!

(I'll let the core developers point you to the various Tomcat design docs.)

- Christopher

Re: CGI wrapper in Tomcat 4.0 b7

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Sat, 18 Aug 2001, Mark Castillo wrote:

> Hi all. I'm new to the list. Sorry if someone has already brought this up,
> but couldn't the code provide some native methods for changing the uid of
> the process after binding to the network ports (if they want to start as
> root, binding to a port < 1024).
> Then, the CGI executed would run as a non-root user. The Jigsaw webserver
> does this.
> 

This could certainly be done, at the cost of the native methods (of
course) being platform dependent.  The current implementation runs CGI
scripts under the same username as Tomcat itself runs -- which should
*not* be root.

To deal with port < 1024, there is already functionality that lets Tomcat
start up as root and then switch to a non-privileged user (same as Apache
does in order to bind to port 80).

> Currently I'm reviewing the Tomcat sources for embedding a servlet engine in
> our application. The application is part of a distributed intrusion
> detection system, which needs some sort of web-based status/admin interface.
> 

For embedding, you might want to look in particular at the
org.apache.catalina.startup.Embedded class.  This lets you "roll your
own" Tomcat configuration without using server.xml, if it suits your needs
better.  The J2EE reference implementation from Sun, for example, uses
this technique to configure it's embedded Tomcat 4 instance.

At the bottom of this class is a main() method that you can use as an
example.  It sets up an environment pretty similar to what the default
server.xml setup creates.

> As for my experience, I've been using Java since it first came out. As a
> software engineer I mainly  work on concurrent, OO, server based
> applications, design patterns, refactoring, blah, blah.
> 
> As for contributing to Tomcat, I'm not sure what needs to be done (bug
> fixing? testing? code review? refactoring?). I'm assuming that the TODO list
> is maintained in CVS? Is there any other software architecture documentation
> besides what's on the jakarta website and the sources?
> 

All of the above, plus docs.  What you see is pretty much all there is at
the moment, which is why I would add docs to your list.  (The TODO itself
is a little out of date, I'll be updating it soon -- but don't let
something not on the TODO constrain you from suggesting something new).

The "rules and regulations" for contributing to Jakarta projects are on
the Jakarta web site, starting at:

  http://jakarta.apache.org/site/getinvolved.html

Welcome!


Craig


> 
> 
> 
> ----- Original Message -----
> From: "Christopher Cain" <cc...@mhsoftware.com>
> To: <to...@jakarta.apache.org>
> Sent: Saturday, August 18, 2001 3:17 PM
> Subject: Re: CGI wrapper in Tomcat 4.0 b7
> 
> 
> > Quoting "Pier P. Fumagalli" <pi...@betaversion.org>:
> >
> > > (BTW, wouldn't it be wise to disable CGI execution in the default
> > > configuration? I don't know, after hearing people running Tomcat as
> > > root, I feel we really should!)
> >
> > +1
> 
> 


Re: CGI wrapper in Tomcat 4.0 b7

Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting Mark Castillo <ma...@webFreak.com>:

[snip]
> 
> What I was really wanting to evaluate was how you guys are managing
> "sessions" and how sessions information could possibly leak out via
> the filesystem, memory, or other ways. The application we are running runs
> in a hostile environment (remote offices, may or may not have firewall, etc).
> For example, some webservers had an example servlet installed that when
> invoked, you'd see a list of current session IDs. Very bad (session
> hijacking).

Yes, the underlying methods in the Servlet API that allowed you to even write a 
servlet that could do that ... that never really sat well with me. Fortunately, 
alot of the methods which allowed for that kind of nonsense have been 
deprecated in the new 2.3 spec. In fact, I think the most heinous one was 
already deprecated, and has now been removed altogether (I can't remember the 
exact one ... one of the getSessions signatures, maybe?).

- Christopher

Re: CGI wrapper in Tomcat 4.0 b7

Posted by Mark Castillo <ma...@webFreak.com>.
----- Original Message -----
>
> It's an experimental feature which is available in our CVS source tree...
> You might want to check out the "service" directory in the
> "jakarta-tomcat-4.0" CVS repository.

Ah! I see it. Nice.

>
> > Currently I'm reviewing the Tomcat sources for embedding a servlet
engine in
> > our application. The application is part of a distributed intrusion
> > detection system, which needs some sort of web-based status/admin
interface.
>
> Cool, check out Tomcat 4.0's Embedded classes in the o.a.catalina.startup
> package. It'll help.

Thanks for the pointer. "o.a" is short for "org.apache"?

What I was really wanting to evaluate was how you guys are managing
"sessions" and how sessions information could possibly leak out via the
filesystem, memory, or other ways. The application we are running runs in a
hostile environment (remote offices, may or may not have firewall, etc). For
example, some webservers had an example servlet installed that when invoked,
you'd see a list of current session IDs. Very bad (session hijacking).

>
> > As for contributing to Tomcat, I'm not sure what needs to be done (bug
> > fixing? testing? code review? refactoring?). I'm assuming that the TODO
list
> > is maintained in CVS? Is there any other software architecture
documentation
> > besides what's on the jakarta website and the sources?
>
> Err... We don't have a TODO list... :) At least so far for 4.0 :) I'll try
> to manage to do something for the WebApp module and the Service code.
>

I think i'll browse the sources for now :-)

>     Pier


Re: CGI wrapper in Tomcat 4.0 b7

Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Mark Castillo at markc@webFreak.com wrote:

> Hi all. I'm new to the list. Sorry if someone has already brought this up,
> but couldn't the code provide some native methods for changing the uid of
> the process after binding to the network ports (if they want to start as
> root, binding to a port < 1024).

It's an experimental feature which is available in our CVS source tree...
You might want to check out the "service" directory in the
"jakarta-tomcat-4.0" CVS repository.

I was supposed to clean it up (see the "jakarta-tomcat-service" CVS
repository) this week, but I was caught by an emergency on some of our
servers, and it's all week I'm securing machines (can't tell you how many
times I ran Nessus this week, and used "chown" and "chmod" - darn I'm
collapsing :)

> Then, the CGI executed would run as a non-root user. The Jigsaw webserver
> does this.

As I said Tomcat (as any other server) should NEVER be run as root... The
only disadvantage is binding to port 80, and that's what the "service" code
is supposed to fix.

> Currently I'm reviewing the Tomcat sources for embedding a servlet engine in
> our application. The application is part of a distributed intrusion
> detection system, which needs some sort of web-based status/admin interface.

Cool, check out Tomcat 4.0's Embedded classes in the o.a.catalina.startup
package. It'll help.

> As for contributing to Tomcat, I'm not sure what needs to be done (bug
> fixing? testing? code review? refactoring?). I'm assuming that the TODO list
> is maintained in CVS? Is there any other software architecture documentation
> besides what's on the jakarta website and the sources?

Err... We don't have a TODO list... :) At least so far for 4.0 :) I'll try
to manage to do something for the WebApp module and the Service code.

    Pier


Re: CGI wrapper in Tomcat 4.0 b7

Posted by Mark Castillo <ma...@webFreak.com>.
Hi all. I'm new to the list. Sorry if someone has already brought this up,
but couldn't the code provide some native methods for changing the uid of
the process after binding to the network ports (if they want to start as
root, binding to a port < 1024).
Then, the CGI executed would run as a non-root user. The Jigsaw webserver
does this.

Currently I'm reviewing the Tomcat sources for embedding a servlet engine in
our application. The application is part of a distributed intrusion
detection system, which needs some sort of web-based status/admin interface.

As for my experience, I've been using Java since it first came out. As a
software engineer I mainly  work on concurrent, OO, server based
applications, design patterns, refactoring, blah, blah.

As for contributing to Tomcat, I'm not sure what needs to be done (bug
fixing? testing? code review? refactoring?). I'm assuming that the TODO list
is maintained in CVS? Is there any other software architecture documentation
besides what's on the jakarta website and the sources?




----- Original Message -----
From: "Christopher Cain" <cc...@mhsoftware.com>
To: <to...@jakarta.apache.org>
Sent: Saturday, August 18, 2001 3:17 PM
Subject: Re: CGI wrapper in Tomcat 4.0 b7


> Quoting "Pier P. Fumagalli" <pi...@betaversion.org>:
>
> > (BTW, wouldn't it be wise to disable CGI execution in the default
> > configuration? I don't know, after hearing people running Tomcat as
> > root, I feel we really should!)
>
> +1


Re: CGI wrapper in Tomcat 4.0 b7

Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting "Pier P. Fumagalli" <pi...@betaversion.org>:

> (BTW, wouldn't it be wise to disable CGI execution in the default
> configuration? I don't know, after hearing people running Tomcat as
> root, I feel we really should!)

+1

Re: CGI wrapper in Tomcat 4.0 b7

Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Deacon Marcus at deacon_marcus@wwtech.pl wrote:

> Hi,
> 
>> -----Original Message-----
>> From: Pier P. Fumagalli [mailto:pier@betaversion.org]
>> Sent: Saturday, August 18, 2001 10:44 AM
>> To: tomcat dev jakarta.apache.org
>> Subject: CGI wrapper in Tomcat 4.0 b7
>> 
> [...]
>> 
>> (BTW, wouldn't it be wise to disable CGI execution in the default
>> configuration? I don't know, after hearing people running Tomcat
>> as root, I
>> feel we really should!)
> 
> You mean it's _enabled_ by _default_ ??

Err, whops... YES :) But that's why we still call 4.0 beta, don't we? :)

> /me is running to his server's console to immediately disable CGI before one
> of his customers find out it's enabled and it's too late ;/

Well, thank god that my Nessus run found it out yesterday night...
It's configured in the conf/web.xml configuration file...

> Greetings, deacon Marcus

    Pier


Re: CGI wrapper in Tomcat 4.0 b7

Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"Craig R. McClanahan" wrote:
> 
> On Sun, 19 Aug 2001, Deacon Marcus wrote:
> 
> > Hi,
> >
> > > -----Original Message-----
> > > From: Pier P. Fumagalli [mailto:pier@betaversion.org]
> > > Sent: Saturday, August 18, 2001 10:44 AM
> > > To: tomcat dev jakarta.apache.org
> > > Subject: CGI wrapper in Tomcat 4.0 b7
> > >
> > [...]
> > >
> > > (BTW, wouldn't it be wise to disable CGI execution in the default
> > > configuration? I don't know, after hearing people running Tomcat
> > > as root, I
> > > feel we really should!)
> >
> > You mean it's _enabled_ by _default_ ??
> > /me is running to his server's console to immediately disable CGI before one
> > of his customers find out it's enabled and it's too late ;/
> >
> 
> It's enabled by default for CGI scripts *inside* your web app, whose
> context relative URI paths match "/cgi-bin/*" and where the corresponding
> files are under "/WEB-INF/cgi".  Have any of those?
> 

When the CGI servlet was first added I recall the issue of security
being discussed and that the CGI Servlet would not be enabled by default.

Also that different servlets, manger, cgi, etc. would be broken out into
separate jar files so that different java SecurityManager policies could
be granted to each.

Regards,

Glenn

----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

RE: CGI wrapper in Tomcat 4.0 b7

Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting "Craig R. McClanahan" <cr...@apache.org>:
>
> Don't get me wrong, I'm ok with turning it off by default ... but it
> also needs someone to write a HOWTO document on how to turn it on and use
> it (to avoid endless questions on TOMCAT-USER about "I thought you said
> Tomcat 4 supported CGI" :-).

True enough. I'll take a look at the config stuff for it this weekend and put 
together a quick HOWTO, as well as the patch to default it to "off".

- Christopher

RE: CGI wrapper in Tomcat 4.0 b7

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Sat, 18 Aug 2001, Christopher Cain wrote:

> Quoting "Craig R. McClanahan" <cr...@apache.org>:
> > 
> > Craig (who is amused by this, since Apache itself ships with CGI
> > enabled)
> 
> True enough, but the very point of JSP/Servlets is to obviate the need for CGI. 
> I can't imagine that ANYONE would want to run CGI from Tomcat unless they had 
> some legacy CGI code, and even then they would probably run that on Apache.
> 
> Anyway, that's why I would be in favor of turning it off by default. It's true 
> that it is almost a non-risk given it's design, but no sense in leaving it 
> turned on by default. It's only purpose 99.9% of the time would be to sit there 
> unused.
> 

Don't get me wrong, I'm ok with turning it off by default ... but it also
needs someone to write a HOWTO document on how to turn it on and use it
(to avoid endless questions on TOMCAT-USER about "I thought you said
Tomcat 4 supported CGI" :-).

> - Christopher
> 

Craig



RE: CGI wrapper in Tomcat 4.0 b7

Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting "Craig R. McClanahan" <cr...@apache.org>:
> 
> Craig (who is amused by this, since Apache itself ships with CGI
> enabled)

True enough, but the very point of JSP/Servlets is to obviate the need for CGI. 
I can't imagine that ANYONE would want to run CGI from Tomcat unless they had 
some legacy CGI code, and even then they would probably run that on Apache.

Anyway, that's why I would be in favor of turning it off by default. It's true 
that it is almost a non-risk given it's design, but no sense in leaving it 
turned on by default. It's only purpose 99.9% of the time would be to sit there 
unused.

- Christopher

RE: CGI wrapper in Tomcat 4.0 b7

Posted by Deacon Marcus <de...@wwtech.pl>.
Hi,

> From: craigmcc@localhost.buzz.pl [mailto:craigmcc@localhost.buzz.pl]On
> Behalf Of Craig R. McClanahan
> Sent: Sunday, August 19, 2001 1:17 AM
>
> On Sun, 19 Aug 2001, Deacon Marcus wrote:
>
> > Hi,
> >
> > > -----Original Message-----
> > > From: Pier P. Fumagalli [mailto:pier@betaversion.org]
> > > Sent: Saturday, August 18, 2001 10:44 AM
> > > To: tomcat dev jakarta.apache.org
> > > Subject: CGI wrapper in Tomcat 4.0 b7
> > >
> > [...]
> > >
> > > (BTW, wouldn't it be wise to disable CGI execution in the default
> > > configuration? I don't know, after hearing people running Tomcat
> > > as root, I
> > > feel we really should!)
> >
> > You mean it's _enabled_ by _default_ ??
> > /me is running to his server's console to immediately disable
> CGI before one
> > of his customers find out it's enabled and it's too late ;/
> >
>
> It's enabled by default for CGI scripts *inside* your web app, whose
> context relative URI paths match "/cgi-bin/*" and where the corresponding
> files are under "/WEB-INF/cgi".  Have any of those?

Haven't currently, but it's perfectly ok for someone having standard www
package on my servers to create /cgi-bin and upload there anything he wants,
which wasn't part of the sold package anyway, so they shouldn't miss the
possibility and I can sleep without fearing someone'll upload malicious /
broken cgi.

> > Greetings, deacon Marcus
> >
> >
> >
> >
> Craig (who is amused by this, since Apache itself ships with CGI enabled)

I didn't choose Tomcat stand-alone to allow some ancient-ware cgi running on
my hardware.

Greetings, deacon Marcus




RE: CGI wrapper in Tomcat 4.0 b7

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Sun, 19 Aug 2001, Deacon Marcus wrote:

> Hi,
> 
> > -----Original Message-----
> > From: Pier P. Fumagalli [mailto:pier@betaversion.org]
> > Sent: Saturday, August 18, 2001 10:44 AM
> > To: tomcat dev jakarta.apache.org
> > Subject: CGI wrapper in Tomcat 4.0 b7
> >
> [...]
> >
> > (BTW, wouldn't it be wise to disable CGI execution in the default
> > configuration? I don't know, after hearing people running Tomcat
> > as root, I
> > feel we really should!)
> 
> You mean it's _enabled_ by _default_ ??
> /me is running to his server's console to immediately disable CGI before one
> of his customers find out it's enabled and it's too late ;/
> 

It's enabled by default for CGI scripts *inside* your web app, whose
context relative URI paths match "/cgi-bin/*" and where the corresponding
files are under "/WEB-INF/cgi".  Have any of those?

> Greetings, deacon Marcus
> 
> 
> 
> 
Craig (who is amused by this, since Apache itself ships with CGI enabled)




RE: CGI wrapper in Tomcat 4.0 b7

Posted by Deacon Marcus <de...@wwtech.pl>.
Hi,

> -----Original Message-----
> From: Pier P. Fumagalli [mailto:pier@betaversion.org]
> Sent: Saturday, August 18, 2001 10:44 AM
> To: tomcat dev jakarta.apache.org
> Subject: CGI wrapper in Tomcat 4.0 b7
>
[...]
>
> (BTW, wouldn't it be wise to disable CGI execution in the default
> configuration? I don't know, after hearing people running Tomcat
> as root, I
> feel we really should!)

You mean it's _enabled_ by _default_ ??
/me is running to his server's console to immediately disable CGI before one
of his customers find out it's enabled and it's too late ;/

Greetings, deacon Marcus