You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jürgen Göres <jg...@gmx.de> on 2020/03/04 09:24:14 UTC
Fix for the Ghostcat vulnerability
Hi,
we are using Tomcat 9.0.x and 8.5.x in our stack. We make use of the AJP protocol since we use Apache HTTPD as reverse proxy and found it to be mostly hazzle-free over the last few years, so we would like to continue using it.
Since the HTTPD and the Tomcats are in general not on the same nodes, the AJP connector has to listen on all interfaces.
My first question is: what value do I need to set in the "address" attribute to indicate that I want the connector to listen on ALL interfaces (for IPv4 AND IPv6)? Maybe that should be documented. :-)
It is clear that the AJP ports should not be exposed to the end users (let alone the public internet ;-)) and we of course make sure that this is the case for our SaaS hosting, but on-premise customers tend to ignore the security guidelines we provide with our product and might have AJP connectors not firewalled off.
So it could be that there are installations out there which have the AJP ports exposed.
This leads me to trhe next question is about the fixes themselves. I checked the changelists mentioned on these pages:
https://tomcat.apache.org/security-8.html#Fixed_in_Apache_Tomcat_8.5.51
https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.31
From what I gathered, these changes only disable the AJP connector by default, change the listining interface to loopback (from "all interfaces"), add a feature to filter requests by request attributes and change the way the optional secret used between HTTPD and Tomcat is configured.
I could not see any changes that actually resolve the issue in the AJP connector's implementation that allow the exploit.
So the question is: is the root cause actually fixed? Or will an AJP connector that is (perhaps by accident) exposed still be vulnerable to the vulnerability?
If it is, what is the recommended mitigation? We consider using the "secret" feature (the filtering by request attributes is infeasible for us), but that would be a bit of effort and we are in a hurry.
Regards
JG
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Aw: Re: Fix for CVE-2020-1938
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 05.03.2020 08:12, schrieb Jürgen Göres:
>>
>> Ghostcat is the name of a malware strain that has been around since at
>> least October last year. When referencing vulnerabilities it is best
>> to
>> stick to the CVE reference since they should be unique (and if
>> something
>> goes wrong and they aren't there are procedures to get them re-issued
>> so
>> they are).
>>
>>> we are using Tomcat 9.0.x and 8.5.x in our stack. We make use of the
>>> AJP protocol since we use Apache HTTPD as reverse proxy and found it
>>> to be mostly hazzle-free over the last few years, so we would like to
>>> continue using it.
>>> Since the HTTPD and the Tomcats are in general not on the same nodes,
>>> the AJP connector has to listen on all interfaces.
>>> My first question is: what value do I need to set in the "address"
>>> attribute to indicate that I want the connector to listen on ALL
>>> interfaces (for IPv4 AND IPv6)? Maybe that should be documented. :-)
>>
>> It will vary by system. Some systems can't listen on both IPv4 and
>> IPv6
>> with a single socker. Usually either "::" or "0.0.0.0" will have the
>> desired result.
>
> That is a bit of a problem for us. In the environments we support (Win
> and Linux), from my observation the connectors would successfully bind
> to both IPv4 and IPv6 addresses. Since we have customers that use
> either IPv4, IPv6, or both and often have multiple interfaces on their
> machines, we cannot know which address/interface (or even which IP
> version) to bind to. And up to now, we didn't have to worry about it.
> Now our installation routine would somehow need to find out whether it
> should put a "::" or a "0.0.0.0" in the "address" attribute. What was
> "zero conf" for us so far now suddently becomes a new source for
> problems (=customer calls).
> Is there no way to optionally configure the old binding behaviour for
> the AJP connector?
Have you tried using either of the given configurations on your system?
I believe Thomas wanted to point out, that there are systems, that can't
bind to both, but that depends on your system, so we can't tell you, if
it works for you.
In my experience both of the configs will work and bind to both types
IPv4 and IPv6.
Felix
>
>
>>> So the question is: is the root cause actually fixed?
>>
>> Yes.
>
> Great, thx. :-)
>
>
>> The very nature of the AJP protocol is such that clients have to be
>> trusted.
>> Tomcat trusts the "real" client IP address provided. That could be
>> used
>> for access control.
>> Tomcat may be configured to trust the authenticated user name
>> provided.
>> That almost certainly will then be used for access control.
>
> So far, we had instructions for our customers to not expose the AJP
> ports (or any other internal ports of other components in our stack).
> However, I am pretty sure that there are installations out there where
> these ports are exposed (hopefully only on the intranet).
> In any case, we will update to the latest Tomcat version (but need to
> find a way to solve the "to which interface should we bind" problem
> without too much hazzle for customers), and in addition will also try
> to use the "secret" approach to secure access to the AJP connectors,
> so that even those customers that ignored the security guidelines will
> not be affected by other possible attacks over the AJP protocol.
>
>>
>>> If it is, what is the recommended mitigation? We consider using the
>>> "secret" feature (the filtering by request attributes is infeasible
>>> for us), but that would be a bit of effort and we are in a hurry.
>>
>> It would be unusual for an application to be using request attributes
>> directly. These have to be explicitly set in the reverse proxy and are
>> normally used for the reverse proxy to pass information to Tomcat
>> about
>> the client etc.
>
> I was under the naive assumptions that "request attributes" meant
> "HTTP request attributes". ;-)
> If I understand you right here we are talking about attributes used in
> the AJP protocol to convey info between reverse proxy and Tomcat.
> Like info about the true client IP address (i.e., an AJP equivalent to
> HTTP's X-Forwarded-For header).
>
>
>> - setting up a dedicated subnet for reverse proxy to Tomcat
>> communication;
>> - configuring a firewall on the Tomcat box to only accept connections
>> to the AJP port from specific hosts
>
> That is what we advise our customers to do.
>
>> For any network configuration you can configure a shared secret for
>> the
>> reverse proxy workers and the AJP connector.
>
> And since this is closest to "zero config" we can get, this is what we
> will do on perspective.
>
> Regards
>
> JG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Aw: Re: Fix for CVE-2020-1938
Posted by Mark Thomas <ma...@apache.org>.
On 05/03/2020 07:12, "Jürgen Göres" wrote:
>>> My first question is: what value do I need to set in the "address" attribute to indicate that I want the connector to listen on ALL interfaces (for IPv4 AND IPv6)? Maybe that should be documented. :-)
>>
>> It will vary by system. Some systems can't listen on both IPv4 and IPv6
>> with a single socker. Usually either "::" or "0.0.0.0" will have the
>> desired result.
>
> That is a bit of a problem for us. In the environments we support (Win and Linux), from my observation the connectors would successfully bind to both IPv4 and IPv6 addresses. Since we have customers that use either IPv4, IPv6, or both and often have multiple interfaces on their machines, we cannot know which address/interface (or even which IP version) to bind to. And up to now, we didn't have to worry about it.
> Now our installation routine would somehow need to find out whether it should put a "::" or a "0.0.0.0" in the "address" attribute. What was "zero conf" for us so far now suddently becomes a new source for problems (=customer calls).
> Is there no way to optionally configure the old binding behaviour for the AJP connector?
Let me re-phrase.
Usually, for the NIO and NIO2 Connectors, specifying "::" or "0.0.0.0"
will result in the server socket binding to all IPv4 and IPv6 addresses.
For APR/Native, "0.0.0.0" will be IPv4 only. "::" will be IPv4 and IPv6.
If the underlying OS does not support "dual stack" networking (most do),
"0.0.0.0" will result in listing on all IPv4 addresses and "::" will
result in listening on all IPv6 addresses.
For your use case "::" looks like the best default.
Most of this is in the docs for the HTTP Connector. I'll add the same
text to the AJP Connector.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Aw: Re: Fix for CVE-2020-1938
Posted by Jürgen Göres <jg...@gmx.de>.
>
>Ghostcat is the name of a malware strain that has been around since at
>least October last year. When referencing vulnerabilities it is best to
>stick to the CVE reference since they should be unique (and if something
>goes wrong and they aren't there are procedures to get them re-issued so
>they are).
>
>> we are using Tomcat 9.0.x and 8.5.x in our stack. We make use of the AJP protocol since we use Apache HTTPD as reverse proxy and found it to be mostly hazzle-free over the last few years, so we would like to continue using it.
>> Since the HTTPD and the Tomcats are in general not on the same nodes, the AJP connector has to listen on all interfaces.
>> My first question is: what value do I need to set in the "address" attribute to indicate that I want the connector to listen on ALL interfaces (for IPv4 AND IPv6)? Maybe that should be documented. :-)
>
>It will vary by system. Some systems can't listen on both IPv4 and IPv6
>with a single socker. Usually either "::" or "0.0.0.0" will have the
>desired result.
That is a bit of a problem for us. In the environments we support (Win and Linux), from my observation the connectors would successfully bind to both IPv4 and IPv6 addresses. Since we have customers that use either IPv4, IPv6, or both and often have multiple interfaces on their machines, we cannot know which address/interface (or even which IP version) to bind to. And up to now, we didn't have to worry about it.
Now our installation routine would somehow need to find out whether it should put a "::" or a "0.0.0.0" in the "address" attribute. What was "zero conf" for us so far now suddently becomes a new source for problems (=customer calls).
Is there no way to optionally configure the old binding behaviour for the AJP connector?
>> So the question is: is the root cause actually fixed?
>
>Yes.
Great, thx. :-)
>The very nature of the AJP protocol is such that clients have to be trusted.
>Tomcat trusts the "real" client IP address provided. That could be used
>for access control.
>Tomcat may be configured to trust the authenticated user name provided.
>That almost certainly will then be used for access control.
So far, we had instructions for our customers to not expose the AJP ports (or any other internal ports of other components in our stack). However, I am pretty sure that there are installations out there where these ports are exposed (hopefully only on the intranet).
In any case, we will update to the latest Tomcat version (but need to find a way to solve the "to which interface should we bind" problem without too much hazzle for customers), and in addition will also try to use the "secret" approach to secure access to the AJP connectors, so that even those customers that ignored the security guidelines will not be affected by other possible attacks over the AJP protocol.
>
>> If it is, what is the recommended mitigation? We consider using the "secret" feature (the filtering by request attributes is infeasible for us), but that would be a bit of effort and we are in a hurry.
>
>It would be unusual for an application to be using request attributes
>directly. These have to be explicitly set in the reverse proxy and are
>normally used for the reverse proxy to pass information to Tomcat about
>the client etc.
I was under the naive assumptions that "request attributes" meant "HTTP request attributes". ;-)
If I understand you right here we are talking about attributes used in the AJP protocol to convey info between reverse proxy and Tomcat.
Like info about the true client IP address (i.e., an AJP equivalent to HTTP's X-Forwarded-For header).
>- setting up a dedicated subnet for reverse proxy to Tomcat
>communication;
>- configuring a firewall on the Tomcat box to only accept connections
>to the AJP port from specific hosts
That is what we advise our customers to do.
>For any network configuration you can configure a shared secret for the
>reverse proxy workers and the AJP connector.
And since this is closest to "zero config" we can get, this is what we will do on perspective.
Regards
JG
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fix for CVE-2020-1938
Posted by Mark Thomas <ma...@apache.org>.
I assume from context that you mean CVE-2020-1938.
Ghostcat is the name of a malware strain that has been around since at
least October last year. When referencing vulnerabilities it is best to
stick to the CVE reference since they should be unique (and if something
goes wrong and they aren't there are procedures to get them re-issued so
they are).
> we are using Tomcat 9.0.x and 8.5.x in our stack. We make use of the AJP protocol since we use Apache HTTPD as reverse proxy and found it to be mostly hazzle-free over the last few years, so we would like to continue using it.
> Since the HTTPD and the Tomcats are in general not on the same nodes, the AJP connector has to listen on all interfaces.
> My first question is: what value do I need to set in the "address" attribute to indicate that I want the connector to listen on ALL interfaces (for IPv4 AND IPv6)? Maybe that should be documented. :-)
It will vary by system. Some systems can't listen on both IPv4 and IPv6
with a single socker. Usually either "::" or "0.0.0.0" will have the
desired result.
> So the question is: is the root cause actually fixed?
Yes.
> Or will an AJP connector that is (perhaps by accident) exposed still be vulnerable to the vulnerability?
No.
CVE-2020-1938 is primarily about the ability to obtain any file from the
web application and/or process any file from the web application as a
JSP. The changes for CVE-2020-1938 block this by default.
The very nature of the AJP protocol is such that clients have to be trusted.
Tomcat trusts the "real" client IP address provided. That could be used
for access control.
Tomcat may be configured to trust the authenticated user name provided.
That almost certainly will then be used for access control.
There was a discussion late last year within the Tomcat Security Team
whether it was necessary to provide a more secure by default
configuration for AJP. We were considering disabling by default in
Tomcat 10. It became apparent during the investigation of CVE-2020-1938
that there were a large number of Tomcat instances where the AJP port
was exposed directly to the internet. We therefore took the decision to
make a number of changes to make AJP more secure by default and require
that system administrators had to provide explicit configuration (so
hopefully they would think about what they were doing) to relax those
security restrictions.
> If it is, what is the recommended mitigation? We consider using the "secret" feature (the filtering by request attributes is infeasible for us), but that would be a bit of effort and we are in a hurry.
It would be unusual for an application to be using request attributes
directly. These have to be explicitly set in the reverse proxy and are
normally used for the reverse proxy to pass information to Tomcat about
the client etc.
How to mitigate will vary on a case by case basis. There will be some
systems where exposing an AJP port to the internet is not a security
concern. I still wouldn't recommend doing it but I can see how a case
could be made.
In short, you need to find a way to ensure that only trusted clients
(reverse proxies) can use the AJP port.
If the reverse proxy and Tomcat are on the same box you can use the
loopback address if you trust all the users which access to the box
(since they could log on and issue requests directly to the AJP port).
If the reverse proxy and Tomcat are on different boxes then you have
various options:
- setting up a dedicated subnet for reverse proxy to Tomcat
communication;
- configuring a firewall on the Tomcat box to only accept connections
to the AJP port from specific hosts
For any network configuration you can configure a shared secret for the
reverse proxy workers and the AJP connector.
Which approach, or combination of approaches, will work best for any one
user will vary from user to user.
Mark
>
> Regards
>
> JG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Aw: Re: Fix for the Ghostcat vulnerability
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jürgen,
On 3/5/20 01:59, "Jürgen Göres" wrote:
>
> Hi,
>
>>> If it is, what is the recommended mitigation? We consider using
>>> the "secret" feature (the filtering by request attributes is
>>> infeasible for us), but that would be a bit of effort and we
>>> are in a hurry.
>>>
>>
>> We're in the same position as you. External web servers talking
>> to Tomcat servers on other boxes via AJP.
>>
>> We've looked at a few options, none of which seemed great:
>>
>> * The current stable version of Apache doesn't support the
>> 'secret' attribute for AJP connectors in mod_proxy.
>
> we will use the "secret" approach. Since we use mod_jk which
> supports it, this will offer the least trouble when deploying in
> customer environments. We will generate a random secret for each
> tomcat instance.
Uhh. That will be a serious management headache.
> Since our apps already register in our service registry,we can
> just add the secret there. Our Apache HTTPD resp. a little tooling
> we wrote for it that generates the Apache config from information
> in the registry and can pick up the secret from there as well.
Interesting. So less of a headache.
Still. I would highly recommend that the entire world migrate away
from AJP. It's just a magic protocol which nobody understands and does
not need to exist anymore.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5hlowACgkQHPApP6U8
pFhf1A/9HxCzPy1J8oxwC2au3VJowVbt6xU5A4Z4gEbnXjQDh2D6hYLMwuM2pE7x
iYBiOCLuCa/6Iw2VI8LntFUmSK0TAVussLigylMFNivdvYtXEIe+fVt3ODWIOfxb
fddCQI2ey3fUKUtIAeyd6lHhJqJ8tXdiVfzOz0sy1XgvV/NTDF3m9EaZE5ftnAz8
KQrmeLPe6JVjj2tenCANfzymz5mMnwqtH7KrjCBSR3rLciyae4i/j/T1kq1tFdBp
dHzxXAYpQVH1AmNR7bpmHpe/FKnaFFlfG1Ri0zG9rJXywbxvyW/DcCmlIWfa0Gfp
2P5a/CaDr4MKR5hOtVshHP49cbnoKmNijEqA4XtkINsSDeZv0oIZDnfrGX02pGAU
3Ijv90lNT+5P3UEY02jurxb4uF3ejlnjc4aoSjDvnTZ2IaHHqaZ0kwov4FwEtLCX
BCo2cl/DIN0ywbvKQ2rHj4mgnDCRS++WlL2bXoRImdUHMiljAV5Ji2xqPRNZol0R
fFpmJBPLjswxUtUClcXM9PzUdNDwqhI0GNJsykpxEDepnMoLfXzQsC0dif1F/IHb
doFqNBHvHHQg4z8EET+GYT5LyQghojq5zjRA9CDuBQ96Y6x8pCtwyJo4hycE1/xg
fdvgzat70W7GO1PoxpZscx4FSWToQeoGVmTQXx+poEpOtFAIb7A=
=dQB6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Aw: Re: Fix for the Ghostcat vulnerability
Posted by Jürgen Göres <jg...@gmx.de>.
Hi,
>> If it is, what is the recommended mitigation? We consider using the
>> "secret" feature (the filtering by request attributes is infeasible
>> for us), but that would be a bit of effort and we are in a hurry.
>>
>
>We're in the same position as you. External web servers talking to
>Tomcat servers on other boxes via AJP.
>
>We've looked at a few options, none of which seemed great:
>
>* The current stable version of Apache doesn't support the 'secret'
>attribute for AJP connectors in mod_proxy.
we will use the "secret" approach. Since we use mod_jk which supports it, this will offer the least trouble when deploying in customer environments.
We will generate a random secret for each tomcat instance. Since our apps already register in our service registry,we can just add the secret there. Our Apache HTTPD resp. a little tooling we wrote for it that generates the Apache config from information in the registry and can pick up the secret from there as well.
Regards
JG
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fix for the Ghostcat vulnerability
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Dave,
On 3/5/20 06:21, Dave Ford wrote:
> On Wed, 2020-03-04 at 13:19 -0500, Christopher Schultz wrote:
>>
>>> We're in the same position as you. External web servers
>>> talking to Tomcat servers on other boxes via AJP.
>>
>> Are those connections properly secured?
>
> That's not a tremendously helpful question. Which connections are
> you talking about? How do you propose 'securing' an AJP
> connection?
There are many ways, the most obvious being mutually-authenticated TLS
using something like stunnel. Or do you usually just allow plain-text
protocol communication over open networks?
>> If your connections are properly-secured, simply set
>> secretRequired="false" and move on. If they aren't
>> properly-secured, then you need to fix that (and you had to fix
>> that before this recent announcement).
>
> Can you point the ill-informed amongst us to any helpful resources
> you may have that describe what you mean by 'properly secured'?
Imagine that you are using HTTP as a proxying protocol and that the
origin server takes special HTTP headers and converts those into e.g.
client connection information, authentication details (e.g. username +
"yep they are authenticated! trust me!), and request attributes and
just goes ahead and trusts them.
Now, how are you going to secure that connection to make sure that an
adversary doesn't inject Bad Stuff into your origin server?
There is nothing special about AJP that makes it any different in
terms of securing, except that there is no ajps:// protocol. If you
want ajps:// you have to tunnel ajp:// through something else, which
is why I recommend stunnel.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5hliAACgkQHPApP6U8
pFibMw//X4OdYQFSeh+BM9F+1tuErCHYW4TJmhL+Q1TrxZQfSWVS/IOHm0zjK/Pj
shP4RfCSlbEsvo/Ia82l4nqm2dHqHiVkty2OwLlbtoyr7B50uh5siZkRpuQ8tonY
WCrq5N37R9ean3mP9kNnm3gw7UJPudy2iSS7Qv37k4QaGLNqekUGXEALSX0TubE8
wGMfNwcAKftibfEYfbJbgdKPdaHH0qnB4m051tK0LoJzdbf/zNLJsYglySD2fO+q
lO9eKpvnav/OhJoQtWmIiJxWPnC4WqvtcbYWBSXGjxDDO+36vpV5pyCgaL54XmbO
7aVzWJBJ+k20y+61lL55abl39tNOg0bGJgW9WNx8dOsZezfsaBuVgsMIVrQx8wmm
GVlZJsxttVFjUvBuVtSW3RW5pZ44tW1JiVg1gFMYCYVqZ/8K4vDtKAMTFGo4Kj+K
O4+Y2PSUutV2o6c2ejYzwn22BdvPRpOWVjApqTdI3Sxt6tQELIhKxuo9QCuOA3w0
332hj37LSX7EeT9D1lknHELrHToiOttr+Rj+4uYtmqqI1JPTJZFKyZIxh5C/pVAn
vfySiyK9c5U7mSrJsKKYnyaZY1L3CXv4vUkSPiJTlwPOSD8qHblV6rvj/BQ9+U3t
1FI/TqA8/rukHGxZ7ncnoonQEZmScMWpTTOPcmgunBCGHBJJnnE=
=qFiH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fix for the Ghostcat vulnerability
Posted by Martin Grigorov <mg...@apache.org>.
Hi Dave,
On Thu, Mar 5, 2020 at 1:22 PM Dave Ford <ab...@bath.ac.uk.invalid> wrote:
> On Wed, 2020-03-04 at 13:19 -0500, Christopher Schultz wrote:
> >
> > > We're in the same position as you. External web servers talking
> > > to Tomcat servers on other boxes via AJP.
> >
> > Are those connections properly secured?
>
> That's not a tremendously helpful question. Which connections are you
> talking about? How do you propose 'securing' an AJP connection?
>
> > If your connections are properly-secured, simply set
> > secretRequired="false" and move on. If they aren't properly-secured,
> > then you need to fix that (and you had to fix that before this recent
> > announcement).
>
> Can you point the ill-informed amongst us to any helpful resources you
> may have that describe what you mean by 'properly secured'?
>
Properly secured would mean that AJP port is visible and usable only by its
supposed users, i.e. the proxy in front of it.
You should apply standard network security policies as:
1) bind AJP port only to the network interfaces where it is supposed to be
found
If the proxy is running on the same host then bind AJP only on localhost.
If the proxy is on a different machine then bind AJP only on a network
interface used for the internal network
1.1) you can create an internal sub-network just for the proxy and
Tomcat/AJP
2) apply firewall rules so that only the proxy machine can reach and use
the AJP port
3) use the "secret" configuration setting so that only the proxy could
communicate with AJP
>
> Regards
> Dave
>
>
Re: Fix for the Ghostcat vulnerability
Posted by Dave Ford <ab...@bath.ac.uk.INVALID>.
On Wed, 2020-03-04 at 13:19 -0500, Christopher Schultz wrote:
>
> > We're in the same position as you. External web servers talking
> > to Tomcat servers on other boxes via AJP.
>
> Are those connections properly secured?
That's not a tremendously helpful question. Which connections are you
talking about? How do you propose 'securing' an AJP connection?
> If your connections are properly-secured, simply set
> secretRequired="false" and move on. If they aren't properly-secured,
> then you need to fix that (and you had to fix that before this recent
> announcement).
Can you point the ill-informed amongst us to any helpful resources you
may have that describe what you mean by 'properly secured'?
Regards
Dave
Re: Fix for the Ghostcat vulnerability
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Dave,
On 3/4/20 05:45, Dave Ford wrote:
> On Wed, 2020-03-04 at 10:24 +0100, Jürgen Göres wrote:
>>
>> If it is, what is the recommended mitigation? We consider using
>> the "secret" feature (the filtering by request attributes is
>> infeasible for us), but that would be a bit of effort and we are
>> in a hurry.
>>
>
> We're in the same position as you. External web servers talking
> to Tomcat servers on other boxes via AJP.
Are those connections properly secured?
> We've looked at a few options, none of which seemed great:
>
> * The current stable version of Apache doesn't support the
> 'secret' attribute for AJP connectors in mod_proxy.
>
> * Valves can be used to secure Tomcat from listening to certain
> IPs Hostnames or subnets/vlans. But....
>
> * The RemoteCIDRValve affects every protocol/port. * The
> RemoteHostValve and RemoteAddrValve only allow a single allow or
> deny rule, which needs a regexp to match every required
> combinations of port and address/names for the whole of the desired
> context.
>
> In ours case, we'd want to permit a different set of hosts on AJP
> to those who can read the manager app, for instance. As this is
> being managed by puppet at our end, we decided the required regexp
> would be too complex and breakable and are probably going to
> isolate the AJP traffic using a firewall rule via iptables instead
> of relying on any intrinsic Tomcat feature.
If your connections are properly-secured, simply set
secretRequired="false" and move on. If they aren't properly-secured,
then you need to fix that (and you had to fix that before this recent
announcement).
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5f8SoACgkQHPApP6U8
pFidVQ//TybnY3LaS8RfuNYx2to518gJBMg0YxO7a81GAP8hSl4cNi/d17HrU8UN
sEiyoFLyFrtTUParyIimrHTzrlNjnL/SkbSZk2WsOXpmZ5zDreCDYrIkzreMavJ1
9PhzWUnGXpXvhkosyy25Xba3L/8aVpimqXp7dbyhzt1BiYpD/Ky6HS+AbIf2n2Y4
A+m4squvLkjw6hVt+cyP9bDi/JKdjKWoE70Yhp5o8FkmsZO+qd5Jc211HAnToJx9
LX/aq6RP89w5bNEi7lrcaelLLnWkdpulkXKNPaopK/i3YXbmmD7gd93oux5HXT/M
Vi4y+aFZg29R+ujV8eN5g5f5u0Zi8SbvDr8e+P4fQEWNEkCkp0nlEqtKsmn9uA7m
RH2VbI6l375iQMpbQK3P1A67CdnmdYlPqS5xT+BLXPFhGFUPadv3JW8WNKrZc5+H
UQxQrBIlQ623PlJhkg/seGmLzSnhFUKI0SxdzChzDy3FMyniMNHazdLZoGShmNEs
0YTOqJMSyA4Dq7WBV8Fx4VRUp/gnYKqnUqaCvaHweUhhvYfEFDvDacLlJvqJxr6J
rU0PbZKnqz6D7QR+BAlrebTta9df3hmOoPSNgnc6t63mrT4Ry4XspVm85YMl/7yU
gc62x4cwCGxMpiBIGLd5zVzBcXvZ1An9aZZzqkor+DZ8Z1rGFIs=
=fNQ0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Fix for the Ghostcat vulnerability
Posted by Dave Ford <ab...@bath.ac.uk.INVALID>.
On Wed, 2020-03-04 at 10:24 +0100, Jürgen Göres wrote:
>
> If it is, what is the recommended mitigation? We consider using the
> "secret" feature (the filtering by request attributes is infeasible
> for us), but that would be a bit of effort and we are in a hurry.
>
We're in the same position as you. External web servers talking to
Tomcat servers on other boxes via AJP.
We've looked at a few options, none of which seemed great:
* The current stable version of Apache doesn't support the 'secret'
attribute for AJP connectors in mod_proxy.
* Valves can be used to secure Tomcat from listening to certain IPs
Hostnames or subnets/vlans. But....
* The RemoteCIDRValve affects every protocol/port.
* The RemoteHostValve and RemoteAddrValve only allow a single allow or
deny rule, which needs a regexp to match every required combinations of
port and address/names for the whole of the desired context.
In ours case, we'd want to permit a different set of hosts on AJP to
those who can read the manager app, for instance. As this is being
managed by puppet at our end, we decided the required regexp would be
too complex and breakable and are probably going to isolate the AJP
traffic using a firewall rule via iptables instead of relying on any
intrinsic Tomcat feature.
Dave