tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rémy Maucherat <r...@apache.org>
Subject Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)
Date Mon, 28 Oct 2019 13:51:14 GMT
On Mon, Oct 28, 2019 at 2:34 PM Christopher Schultz <
chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Mime
View raw message