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:58:55 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rémy,

On 10/28/19 09:51, Rémy Maucherat wrote:
> On Mon, Oct 28, 2019 at 2:34 PM Christopher Schultz 
> <chris@christopherschultz.net
> <mailto:chris@christopherschultz.net>> wrote:
> 
> 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.

Thanks for the feedback. I wouldn't bother replacing the uses of
utility classes unless we were expecting to spin the project off into
a subproject as you say.

If we did that, I would say that anyone wanting to run the
SSIServlet/Filter on another container would be caveat downloader and
that patches were always welcome; the subproject would only promise
compatibility with Tomcat, at least at first.

Who knows? Maybe there is a nascent community out there who wants to
support CGI forever on all servlet containers and they'll get behind
such a project. *shrug*

- -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/969a9d1b6e883a4017907c4482928806
2
>
>> 
4c
> <https://lists.apache.org/thread.html/969a9d1b6e883a4017907c4482928806
24c>
>
> 
> 
> c85eb22c490b241dc9c88@%3Cusers.tomcat.apache.org 
> <http://3Cusers.tomcat.apache.org>%3E
> 
> 
> ---------------------------------------------------------------------
>
> 
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> <mailto:dev-unsubscribe@tomcat.apache.org> For additional commands,
> e-mail: dev-help@tomcat.apache.org 
> <mailto:dev-help@tomcat.apache.org>
> 
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl229B8ACgkQHPApP6U8
pFjHcBAAwUSAv0RlJ8voEPcC/JpdmTHhp+WSlN1uZCiwD2TQjYtNlWJiFawpgJWm
T0on7AcDQ/KGHJjckfk8pbyE938FWLfTpc/UWmsSfmfB2qQCmqc7vtYxdClWadmG
jO+wNX2iH2ZW+mlme7e9zl/YM6cSlL5SxRlEaJ8p8WONoFt7Yf5oaSYHvwunEHu/
mLFK3/t9rjXfK5F09MT8+KXoCJQW9KVFo8c1J2flGEl1fSLwu63J1+ga6kToSZqV
JGDoScrL2kong82ugHMdsVqUUXCDYm6b9uR6glGc2X8C9KRu7kxIe9X2lEr4th5e
9nm5IcDqFmaKvFeOOj/R4fptGFoYtztG45CXK4i/N+7sW2NJ7OCVFW6kWan8ao/j
pTURcmPWiWKnujQhf0qAn9lBUm7Qh9/ghdC0H4chEpP+wPlP4LUfWb4ZtkL2/B/P
EcdQnxkPI6TKO+lNB4WTue5xqjpsYNDt8XEyGoprb+Mf5qH7j/Hjpt9jSAmIqNmv
XH97v8vvofGKyAooWlxe7FjnWnzbEz8q9pLzFvg+EBVQvl39kp04BB2bBcfBvPHf
4fAC5AQeMNSG9dDhvEN7xQNZqU05OhqEE8LVxFWzxEmelTkUnsW7qH2L08Ahb5wD
bQAhgkTCKymN8lUlh3dNZtaA295KAuDWaIOo87Otm9GpBkNqL5A=
=9e9A
-----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