Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

[Rémy Maucherat]

On Mon, Oct 7, 2019 at 4:46 PM Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> 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.

The discussion and proposal we had was to propose removing and see the
feedback. If there was some use, keep it as it does not actually pose
a security risk unless enabled.

Given the feedback, I would now say we should keep it for Tomcat 12.

Rémy

>
> - -chris
>
>
> [1] http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> at
> [2]
> 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/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bT78ACgkQHPApP6U8
> pFj9cQ/+Os1dBaXqqM3taTbqTzzCyLKCMz5q/66QreuH0ZMcqf/QjTGkxhsegelD
> 184cnAni2rWyV015yuqHvM/ZPn5BcH5pV31mEdJyGQiFIjvEfmZs37sGEoSOE584
> jutsktxcla7UEVMPfYU+YiVCapWRjWHNFusP2J/dP+UFYDg/cZJCoYDlMVjpfhmq
> UH6i/Sht3fpMfYYRHdgkP/r2wHLOD+qql/K8RNExhokwDZCiATmKA1uTuUHtQWQu
> rh71myzAqdzsEmLMRSLOnDY17XeG8Pd1W0JmcskdHNkZ/cYECLlMv5iqXLA3FbVM
> sLSd7PLJW1baFi9kqLTP4C44G8+j2tJAgjxkC+9nxFLB7Fy+abyV38Pt77zJ5NXS
> lIceS1jUIn4OBWFrMVnAii3slAl8WI0xknBBtJeObhw1uKtmRMJ2YtcefK89R/FR
> 9ZOAHghcYpkbTE8rO6z7HeyN/M+p972a7Pyr6nOH9XnanYBGuL/eg72/yAZpkofT
> k8AZe9VZ1SOK2TYBmNjHrzQDnodmvgtW3Q0RWY828CrOZ0x9vlQniKc/RWVa0HOR
> nv6l54oGGNoOezNnMKPRgOyUpzCtLCRkxMUVFkJJi2Hetf7QDo43MITgNNIz/VW8
> NEwTPtG/EUE98HQzl4MnV+I7MTBJK8kwwlIKYwtFFTnCy88QmOQ=
> =ap4d
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Security mechanisms to counter spam

[Rémy Maucherat]

On Fri, Jun 7, 2024 at 12:23 PM Dimitris Soumis  wrote:
>
> Hi All,
>
> Due to the surge in spam BZs today, I propose implementing a security
> mechanism to counter this issue and prevent further disruption to the
> mailing list.
>
> A potential solution could include a honeypot to identify and block bots,
> as well as a reCaptcha to verify users. Additionally, should monitor for
> multiple requests from the same IP address and block the IP if necessary.
>
> Can also leverage tools like this Mozilla Bugbot Spam Detection Script
>  to
> identify and filter out spam.

One of the more ambitious proposals (which is in the wiki but has not
yet made it to the list) is to move to Github Issues. This spamming
might skew the discussion, but well, bad luck for BZ I guess ...

Rémy

> Best regards,
>
> Dimitris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove CGI Servlet

[Rémy Maucherat]

On Thu, Jun 6, 2024 at 4:40 PM Christopher Schultz
 wrote:
>
> All,
>
> Resurrecting this thread from 2019.
>
> I will be proceeding with this 4.5-year-old plan to extract the CGI
> servlet to a separate JAR file to make it easy to "remove" from Tomcat
> if operators would prefer to do such things.
>
> I think I'll also move the configuration from conf/web.xml to
> webapps/docs/cgi-howto.html while I'm at it so those vestiges are gone.

I think I am +1 for removing CGI. For extraction, the issue is that
it's in the same package as default and WebDAV, usually it's meh to
split a package like that.

Rémy

>
> Thanks,
> -chris
>
> On 10/28/19 09:55, Christopher Schultz wrote:
> > All,
> >
> > Note: this was not a vote.
> >
> > There was very little feedback, and responses were mixed. We got
> > exactly one response on the users@ list about real-world usage of CGI,
> > so we cannot draw any conclusions about real-world uses.
> >
> > Otherwise, the consensus seems to be that CGIs should stay a part of
> > the main Tomcat distribution, but that perhaps separating it out into
> > a distinct JAR file and/or separate distribution might be advantageous.
> >
> > It appears that the CGIServlet is completely self-contained. It makes
> > use of the following internal(ish) Tomcat APIs:
> >
> > org.apache.catalina.util.IOTools
> > org.apache.juli.logging.Log
> > org.apache.juli.logging.LogFactory
> > org.apache.tomcat.util.compat.JrePlatform
> > org.apache.tomcat.util.res.StringManager
> >
> > All of these could be replaced if necessary to make a standalone,
> > container-agnostic package.
> >
> > It looks like it would be fairly easy to separate-out the CGIServlet
> > into a separate JAR file packaging if there's utility in that. For
> > example, security-conscious environments may want to remove that JAR
> > file entirely from the Tomcat deployment to be absolutely sure that
> > Runtime.exec() isn't available in the deployed Java code (from the
> > container; yet I realize that SSIServlet/SSIFilter has this, too).
> >
> > I'd like to go ahead and move the CGIServlet from the general
> > catalina.jar file into catalina-cgi.jar. That should only require a
> > small change to the build.xml script.
> >
> > Any objections?
> >
> > -chris
> >
> > On 10/7/19 10:59, 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 CGI Servlet
> >
> >> Justification:
> >
> >> The CGIServlet is another component, like server-side-includes,
> >> which is a remote-code execution (RCE) vulnerability as a feature.
> >> It is very easy to misconfigure. It is arguably not possible to
> >> secure it on Windows[2]. There are better solutions if you want to
> >> run Perl, Python, PHP, or whatever on your server in the form of
> >> the many fine web-server products out there.
> >
> >> -chris
> >
> >
> >> [1]
> >> http://tomcat.apache.org/presentations.html#latest-locking-down-tomc
> >
> >
> > at
> >> [2]
> >> https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/
> > 23
> >
> >
> > /everyone-quotes-command-line-arguments-the-wrong-way/
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Remove JSP file from ROOT web application

[Rémy Maucherat]

On Thu, Jun 6, 2024 at 4:44 PM Christopher Schultz
 wrote:
>
> All,
>
> I'd like to change the existing webapps/ROOT/index.jsp to index.html and
> remove the dynamic elements. Currently, the only truly dynamic element
> in the whole file is this:
>
> "
> Copyright ©1999-${year} Apache Software
> Foundation.  All Rights Reserved
> "
>
> I don't see any particular reason that the Copyright information must
> always show the "current year". We can simply set this to "the current
> year" during the release process.
>
> This will mean that the default application will be completely static.
> Not much of an upgrade, *but* if a user would prefer to completely
> remove Jasper, it means that the default home page will be readable.

The reason for this one was simply to have a JSP demo. Of course it is
simpler to have a static page ;)
So this is not needed anymore.

Rémy

> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Enable SecureLifecycleListener by default

[Rémy Maucherat]

On Thu, Jun 6, 2024 at 4:46 PM Christopher Schultz
 wrote:
>
> All,
>
> I'd like to remove the  around the SecureLifecycleListener
> in conf/server.xml that we bundle with Tomcat distributions.
>
> Before I do so, are there any objections to making this change?

+1
Having something commented out in the config is obviously the final
step before enabling it by default ;)

Rémy

> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 61773] When more than 10000 times of HTTPS websocket, Tomcat cannot respond to requesting HTTPS requests

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61773

Masel  changed:

   What|Removed |Added

URL||https://acuantoday.com
   Keywords||APIBug

--- Comment #5 from Masel  ---
https://acuantoday.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69129] New: Upgrade to Tomcat 10.1 breaks deployments with reverse proxies

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=69129

Bug ID: 69129
   Summary: Upgrade to Tomcat 10.1 breaks deployments with reverse
proxies
   Product: Tomcat 10
   Version: 10.1.24
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: WebSocket
  Assignee: dev@tomcat.apache.org
  Reporter: alexand...@gmx.net
  Target Milestone: --

With Tomcat 10.1 the configuration property
org.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS has been removed[1].

As a result, in deployments with Tomcat 10.1 behind certain reverse proxies
(notably Microsoft IIS/ARR) WebSockets do not work anymore.

Preliminary analysis:

Browsers like Chrome and Firefox send the Sec-WebSocket-Extensions header which
contains a permessage-deflate attribute to the server. The reverse proxy passes
this header to the backend Tomcat 10.1 instance which creates a response with
Sec-WebSocket-Extensions: permessage-deflate. The reverse proxy cannot handle
such responses and closes the connection to the client.

We could not find a configuration option which could replace
org.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS.

Ref.:
[1] https://tomcat.apache.org/tomcat-10.1-doc/changelog.html

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 61773] When more than 10000 times of HTTPS websocket, Tomcat cannot respond to requesting HTTPS requests

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61773

Chuck Caldarale  changed:

   What|Removed |Added

URL|https://acuantoday.com  |

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org