Re: [PROPOSAL] Tomcat 10: Remove CGI Servlet

2024-06-08 Thread 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] Tomcat 10: Remove CGI Servlet

2024-06-07 Thread Mark Thomas 

On 06/06/2024 16:39, 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.


+1

Mark




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] Tomcat 10: Remove CGI Servlet

2024-06-06 Thread Christopher Schultz 

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.


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

Re: [PROPOSAL] Tomcat 10: Remove CGI Servlet

2019-10-28 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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/
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2281sACgkQHPApP6U8
pFjMLw//cR2e2f32IUVK7kbbK2isBhmqd+GB/MhC9/Dt6d7iBPElr1gOid2zegpg
BLVzAdzCjUxR1TlzTfOqq7riZwYPui6+URGePsVyNms3c4tM9hWMArqtYRJFnQXt
bQCRS7dsS7dyonJTdJzAQFwN+zqjP1We4AORSO1uOjPA8wF7NK4d4mQ1yMaF7Bsj
CzGIzvo31iRCix2TUJiok0SrRU9qRQn8IzTU2tUswTEGDR0lTjnSc6XUzvBgYbmx
WF8AVLsjYIJKt1zDDAmAckhnio1Vq9jIwp/fHYd16NPy8n5Mfn1IkWmuZ8RGMDXM
o0W4/HYRYV+9WWiGF3aUrSbmu2hOwXdbPcYm+hzntWzyHoY5JGVSCXS1HrFIGr4S
TZTLzj7sCV+Yl5Na8spie3S5rZ0EsI2BzP7fwmvmBEHAzetFr/tQFYv9t6ibZHUF
e06ef39ws7sO8GlII3TEKfMaByY1BMX/jv8RD6qSCrdLPQgwAzInfL3wJLdqykNC
8SkS1h0Oo4Dm4lrBuAnrwo6cCZOVzI5SJz1q3hJja5BnAg1+7920ts4LGS1EbJVu
2mnlgWJg7veMkjGEyZs3W0WKkOZHnuQjY1gZRBDBnBqqRy7OUmWIftVixUK2m6sP
IKVnaT0f5bS47gqt4wahhuwLo5+JCEiSTpEVlhNV2ZK5ZwAvSWU=
=dNvr
-END PGP SIGNATURE-

-
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

2019-10-08 Thread Rainer Jung 

Am 07.10.2019 um 18:37 schrieb Igal Sapir:

On 10/7/2019 8:14 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/7/19 11:10, Mark Thomas 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

-1. Not a veto, just a -1.

Fair enough. I didn't think I'd get 100% agreement. If anyone feels
like this is is something worth keeping around, I'm happy to let the
proposal drop.


Is it possible to extract these removals (including the other proposals 
in this question) to an external repo in case someone wants to add them 
manually to his/her own deployment?


That way if anyone depends on any of the removed items they can still 
add them.


+1 it would be great if that would be feasible.

Regards,

Rainer


-
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

2019-10-07 Thread Igal Sapir 

On 10/7/2019 8:14 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/7/19 11:10, Mark Thomas 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

-1. Not a veto, just a -1.

Fair enough. I didn't think I'd get 100% agreement. If anyone feels
like this is is something worth keeping around, I'm happy to let the
proposal drop.


Is it possible to extract these removals (including the other proposals 
in this question) to an external repo in case someone wants to add them 
manually to his/her own deployment?


That way if anyone depends on any of the removed items they can still 
add them.


Igal



-
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

2019-10-07 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/7/19 11:10, Mark Thomas 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
>
> -1. Not a veto, just a -1.

Fair enough. I didn't think I'd get 100% agreement. If anyone feels
like this is is something worth keeping around, I'm happy to let the
proposal drop.

>> 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].
>
> I disagree. That is an edge case.
>
>> 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.
>
> Yes, but that isn't the only use of CGI. It is essentially, a
> fairly easy way to integrate any executable into a web application.
> My sense that this use remains sufficiently widespread that we
> should not discontinue it.
>
> Maybe a topic for discussion on users@ ?

Sure.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bVmsACgkQHPApP6U8
pFhpGQ/+PWCpG7pJGeVHULrwDHMy3VkOc4OIcnt17gfcm5IXL9ZVDquaWc8dsCBb
iB5XNZ458RYwi7ewwQ3xI7il+Utnij8zFCHWaOSlPqbfb2VYrkSUD7/esJTqufhO
B3Sonkw6hTSov4+/GgdQTee0hN6rmuu2MrLpL0lU0xcz9wITDGbb16S4weBpDynW
cXCcQHYgT4nGvzayevhHqyiiMom0aC/O/ZwwkWgZf/JWb9SSw0P1b2dTulBbranL
DkGdYt+m5WaawZ40GVwh6sYT3dVlGkTebKEG5PFSJY36NbDJ1tIUKxCGeUOXyyCg
Qqrk42VdxjvXWZ+GmuFJegACExIlxiH8miM1RG2qaN75Irt+mEygvsX3GcG2uIwQ
HXcQpbf4uPJEBZ/Q954b2yXkvrn/0QHXhVsFVq+aTc6C6wmFRk53djgblHduOnBw
QPD3/Q5Eeh2btu67sSnAoFkAhr0/y11Kfc5iSdRqcLa4qdcG+U8TEshpoavX10az
9BOsELcutJ/EPWiXttd0IFn5Bt+zKIlIURRuXQGbxTYm6v69XvUz95Leb+qg/2+f
50kXRyqHmIU9/6Kxzv2FZZEIEnVnEg6pSYkTRXyG7y2Z4GNHvp7vnkXuwPDbdZK9
dw3rW223KpuxvXuoCHc+zzelcKm3ejiOCBBXBxhchswNwUxvzjo=
=qU2J
-END PGP SIGNATURE-

-
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

2019-10-07 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Coty,

On 10/7/19 11:02, Coty Sutherland wrote:
> On Mon, Oct 7, 2019 at 11:00 AM 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
>
>
>> +1
>
>
>
> 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.
>
>
>> I thought this was a really weird feature for Tomcat to provide
>> anyway :)

I think there was a lot of "me-too-ism" happening back in the day. I
get it: why use two separate servers when one will do the trick?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bVfwACgkQHPApP6U8
pFjA/RAAyW7nluFxfWFmQAKazbpGwjgBIM8LCxrVtWfVDzaXpEWdkP259P9HdO+m
TmFAOFYzlw4pstR73AhcQk/pLxF8mWYzU0Fi+uaPCDEDJ3OsJjKuGNRu3o51OMjF
j7+666hxS3VmfkiFqejhPClaFB3QPHzA0YopMdjPGyAJJ7eQExXZXdUVbSQeh+v3
1Ka/57Sm0wdRRHpdd2N22jh3NDKR/laC8gnqzbnr5WealN+Yeb9ECIg6c6ooD2cy
fo5SGAsllzMWdNWtckAPZ+Op7S96mdro6Komyp5VNgOLGd4kILA4e3KfbVyYBBAj
HEyY5st6BHIhqtbjRou+/9e0Z94sZU7Wa7JSDo/tdc9bWeoBYSfewTRDBKp7yREV
tHsHOMDAW88MveP6Eu/daxV+ZUhY/s6u/UHnfHsgYcdvnDHj7IFki80qRZpH7h19
LjHX6h1EnS79p8+lszY7bA/XFfOw+f4T5VjnvyAr/ospU9GVdE7SnUEI2lzejn1/
PUoTlWEhTH4BJ5+l5BtKxXriuyckfULSDLKckIoMyGe6+JrXHEbfc40aO6hsnZVq
2jYvTydaHPGOaINZahrs1m9eGa6upduHVo0rtwN1eBLDa339o072jKG1yP81xYUN
xql1LOjEqhcsUtxUfvZr/uDYOxivuqGJwfsHzNv+1XUGeY334to=
=2JSs
-END PGP SIGNATURE-

-
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

2019-10-07 Thread Mark Thomas 
> 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

-1. Not a veto, just a -1.

> 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].

I disagree. That is an edge case.

> 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.

Yes, but that isn't the only use of CGI. It is essentially, a fairly
easy way to integrate any executable into a web application. My sense
that this use remains sufficiently widespread that we should not
discontinue it.

Maybe a topic for discussion on users@ ?

Mark

-
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

2019-10-07 Thread Coty Sutherland 
On Mon, Oct 7, 2019 at 11:00 AM Christopher Schultz <
ch...@christopherschultz.net> 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 CGI Servlet
>

+1


>
> 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.
>

I thought this was a really weird feature for Tomcat to provide anyway :)


>
> - -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/
> 
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bUusACgkQHPApP6U8
> pFhGxw//V8a5sALHVJAGDuhYf3HJs+MyDkHI848BOW8U5JjSOC9erQg84xxOm11q
> ywHqmdJ1HkVCTlN6n+OMne4/DVtAywqetF6hVf3TdGvA/Xp2HGiz4H9FeBgD5oVS
> WgZqrShBk5xneElWkBH69yG7qC2XKhCZNtA8bNqMdUQ+zOW2Gwhk8k35r//jWivX
> ZkXloVRs2aQaArtqwIi0kWWMMbIEL6JJJigAfjfpap8HvTrLL/W5/dTpYUp1Y1Ms
> qGhv0CcbDSFmQqPEnZO0keaUJRi5QXsW7ByMnXjterr1ExEW8ZfHM7ZOAap/7VWz
> O2TFeq59YSG2KOrueDpzZk1u1l0G5vT9ttyoGtGJQlFt6TnxA0+4EouciFoVtPM8
> mrAEHkp9MSHIVGjTj6qanNnEkue3Bnyv5TQq2m5MX6mYCkyGUhZpdaIfK2aw6M2Y
> uJ4h8Qf1hX0s3/nfyF3ERTKnsB2aYcVORjcfLaEajJwbUAXRG4kLKqOszMsLKV3S
> FC/rzp1f7MSKf4nN9WVIQvxUZhxP70SjBSTtRN3UXZvrZvCiq/BaK0/inyYTKOIc
> 1QOjbfoZnI3Kcm8zKKODJRebpsrsF+f7EWwuEg07lAmgAxQGsdciss23rt6OALf0
> Dhr5Lb6mcMktmy4JLIKwbM9Hbk3IslbQlEWQEOSiagzph/ZMVP8=
> =28Zt
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[PROPOSAL] Tomcat 10: Remove CGI Servlet

2019-10-07 Thread Christopher Schultz 
-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 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/
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2bUusACgkQHPApP6U8
pFhGxw//V8a5sALHVJAGDuhYf3HJs+MyDkHI848BOW8U5JjSOC9erQg84xxOm11q
ywHqmdJ1HkVCTlN6n+OMne4/DVtAywqetF6hVf3TdGvA/Xp2HGiz4H9FeBgD5oVS
WgZqrShBk5xneElWkBH69yG7qC2XKhCZNtA8bNqMdUQ+zOW2Gwhk8k35r//jWivX
ZkXloVRs2aQaArtqwIi0kWWMMbIEL6JJJigAfjfpap8HvTrLL/W5/dTpYUp1Y1Ms
qGhv0CcbDSFmQqPEnZO0keaUJRi5QXsW7ByMnXjterr1ExEW8ZfHM7ZOAap/7VWz
O2TFeq59YSG2KOrueDpzZk1u1l0G5vT9ttyoGtGJQlFt6TnxA0+4EouciFoVtPM8
mrAEHkp9MSHIVGjTj6qanNnEkue3Bnyv5TQq2m5MX6mYCkyGUhZpdaIfK2aw6M2Y
uJ4h8Qf1hX0s3/nfyF3ERTKnsB2aYcVORjcfLaEajJwbUAXRG4kLKqOszMsLKV3S
FC/rzp1f7MSKf4nN9WVIQvxUZhxP70SjBSTtRN3UXZvrZvCiq/BaK0/inyYTKOIc
1QOjbfoZnI3Kcm8zKKODJRebpsrsF+f7EWwuEg07lAmgAxQGsdciss23rt6OALf0
Dhr5Lb6mcMktmy4JLIKwbM9Hbk3IslbQlEWQEOSiagzph/ZMVP8=
=28Zt
-END PGP SIGNATURE-

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