-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All,
Note: this was not a vote. The consensus seems to be that SSIs should be moved into a separate JAR file. I've done a *very* short investigation, and I have discovered the following: 1. Tomcat builds fine after removing the entire org.apache.catalina.ssi source package, so it's completely isolated from the rest of Tomcat (which was entirely expected). This suggests that releasing Tomcat without any of the SSI components is practical and relatively easy. The stock conf/web.xml contains a sample configuration for the SSI servlet. We will have to decide what to do with that. I can think of at least two options: a. Remove it from the stock conf/web.xml entirely b. Add comments to conf/web.xml indicating that the SSI component is a separate download I think I like #2 better. 2. Separating the packaging should be easy. Note that I haven't actually done this: i. Modify files.catalina in build.xml to <exclude> the org.apache.catalina.ssi package ii. Modify the "package" target in build.xml to <jarIt jarfile="catalina-ssi.jar" .../> with the appropriate classes I think this is super simple to do and we should go ahead and do this, /now/. For embedded clients who don't care about SSI, this gives them a JAR today that they can simply remove from their bundled clients to save a little space. 3. The SSI component uses a bunch of internal(ish) Tomcat/Catalina APIs. This may complicate fully-extracting the SSI component and making it a standalone product (e.g. cross-container): org.apache.catalina.connector.Connector; org.apache.catalina.connector.Request; org.apache.catalina.util.IOTools; org.apache.catalina.util.Strftime; org.apache.catalina.util.URLEncoder; org.apache.coyote.Constants; org.apache.tomcat.util.buf.B2CConverter; org.apache.tomcat.util.buf.UDecoder; org.apache.tomcat.util.http.FastHttpDateFormat; org.apache.tomcat.util.http.RequestUtil; org.apache.tomcat.util.res.StringManager; org.apache.tomcat.util.security.Escape; Some of them are simply for convenience -- e.g. UDecoder, FastHttpDateFormat, etc. Those could easily be replaced with alternatives or re-implementations. I haven't yet looked at how much the org.apache.catalina.connector.Connector and org.apache.catalina.connector.Request classes are used. It's possible that these could be replaced with the generic versions of themselves (e.g. HttpServletRequest and ... I'm not sure what we get from the Connector but of course there is no direct replacement for that in the public API). So I'd like to move-forward with the separation of the SSI component into a separate JAR file and then see what can be re-factored within SSI itself to divorce it from internal Tomcat APIs. - -chris On 10/7/19 10:46, 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 Server-Side Includes > > Justification: > > The SSI module is a remote-code execution (RCE) vulnerability as a > feature. My sense is that SSI is a little-used feature. A few > years ago, markt[2] asked if anyone was using SSI. The only replies > were from other Tomcat devs commenting on what to do with SSI if > it's no longer in the main Tomcat distribution; there were no > community members who responded saying that SSI was important to > them. > > If the packaging of Tomcat could be tweaked a bit to move the SSI > components into a separate JAR file (e.g. move > org/apache/catalina/ssi/* to catalina-ssi.jar) and if the SSI > components don't rely on any Tomcat specific capabilities or > internals, then the cattalina-ssi.jar file could be used between > Tomcat versions. For example, a user of Tomcat 10 who still needs > SSI could get the SSI module from a distribution of Tomcat 8.5.x or > 9.x. > > -chris > > > [1] > http://tomcat.apache.org/presentations.html#latest-locking-down-tomc > > at > [2] > https://lists.apache.org/thread.html/969a9d1b6e883a4017907c44829288062 4c > > c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org%3E > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl227lQACgkQHPApP6U8 pFjvbg//W0fD5aokUYxmy7wbTS56RdPRhLo/OmB1DrN5lbjE1rIdpiNtQRkPi9qO C0X5QJZjYBnbNUr4YMUOVcjKjv8TBUuL6EGbVIsQupYIO0usoLthLfllH6ARXgsB pr9Wynx7mVCi/KiR+G1mYw4bHbbVuMgZpEKCPSiurK+ZJhW7J/FfQ5U0bfZBqWG9 gT27EapqA35xXt4hHNmCb65dtWRmeXgTXEXrnzeQr3lgtXy6wT/uXjQfxP6/12Lz vOhmi7HVzkrM6yGETsz45QvzMaY+JwS2bKfg8wxWT8B0A+3DhuevusYCHXxGunRD LbUomZOW3+l4mVjp85KWr7U0W8LZvA/GSgGaAueqyw5xcQ2de4VdFoefmUGdKRhZ 65gWtyrynDL7wksmx8CXOaXQbAQS0GwOXpEkpPCDqslvM/y9R0qYJdVuNqMnh6vY 7DlCovaS8hcHfOQRnWCBBtBPq2UbGWGIULk1bh8VYnFRpF8PdgGIXc/GiUlVA5cY pmPLIQ5euJJyY0nvF1IXipVdLHY0asl7tG9fvafH2Gk9TjYMUiek/1zeiD1iTcNU OqnkT+upJhZEpeG29Oycwtjh8EwQgiB2JwL9ThoArub4Pnh8uwLhgJo8BVD9JTu9 ifUk3ezGegoe8zK6J9APlnEaxoyc2aDx6IQsANt8Q4O7uwS0xRU= =hiwK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
