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