> >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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
