On 06/06/2024 16:39, Christopher Schultz wrote:
All,
Resurrecting this thread from 2019.
I will be proceeding with this 4.5-year-old plan to extract the CGI
servlet to a separate JAR file to make it easy to "remove" from Tomcat
if operators would prefer to do such things.
I think I'll also move the configuration from conf/web.xml to
webapps/docs/cgi-howto.html while I'm at it so those vestiges are gone.
+1
Mark
Thanks,
-chris
On 10/28/19 09:55, Christopher Schultz wrote:
All,
Note: this was not a vote.
There was very little feedback, and responses were mixed. We got
exactly one response on the users@ list about real-world usage of CGI,
so we cannot draw any conclusions about real-world uses.
Otherwise, the consensus seems to be that CGIs should stay a part of
the main Tomcat distribution, but that perhaps separating it out into
a distinct JAR file and/or separate distribution might be advantageous.
It appears that the CGIServlet is completely self-contained. It makes
use of the following internal(ish) Tomcat APIs:
org.apache.catalina.util.IOTools
org.apache.juli.logging.Log
org.apache.juli.logging.LogFactory
org.apache.tomcat.util.compat.JrePlatform
org.apache.tomcat.util.res.StringManager
All of these could be replaced if necessary to make a standalone,
container-agnostic package.
It looks like it would be fairly easy to separate-out the CGIServlet
into a separate JAR file packaging if there's utility in that. For
example, security-conscious environments may want to remove that JAR
file entirely from the Tomcat deployment to be absolutely sure that
Runtime.exec() isn't available in the deployed Java code (from the
container; yet I realize that SSIServlet/SSIFilter has this, too).
I'd like to go ahead and move the CGIServlet from the general
catalina.jar file into catalina-cgi.jar. That should only require a
small change to the build.xml script.
Any objections?
-chris
On 10/7/19 10:59, Christopher Schultz wrote:
All,
I recently gave a presentation on locking-down Apache Tomcat[1] and
I briefly discussed the "sharp edges" present in Tomcat. Some of
them are unnecessarily sharp and may be actually unnecessary. I'm
going to make a few proposals to remove functions from Tomcat.
Proposal: Remove CGI Servlet
Justification:
The CGIServlet is another component, like server-side-includes,
which is a remote-code execution (RCE) vulnerability as a feature.
It is very easy to misconfigure. It is arguably not possible to
secure it on Windows[2]. There are better solutions if you want to
run Perl, Python, PHP, or whatever on your server in the form of
the many fine web-server products out there.
-chris
[1]
http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
at
[2]
https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/
23
/everyone-quotes-command-line-arguments-the-wrong-way/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
