On Thu, Jun 6, 2024 at 4:40 PM Christopher Schultz <ch...@christopherschultz.net> 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.
I think I am +1 for removing CGI. For extraction, the issue is that it's in the same package as default and WebDAV, usually it's meh to split a package like that. Rémy > > 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
