On Mon, Oct 28, 2019 at 2:34 PM Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----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. > Personally I am in favor of a separate JAR, but maintain everything else unchanged. The use of utility classes reduces code duplication. If it becomes cross container then I think SSI should be moved elsewhere. Maybe something like the taglibs subproject. It's a rather significant effort to test and maintain compatibility with everything out there IMO. Rémy > > - -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 > <https://lists.apache.org/thread.html/969a9d1b6e883a4017907c448292880624c> > > > > > 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 > >
