tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)
Date Mon, 28 Oct 2019 13:34:13 GMT
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message