TOMCAT CVE-2020-1938: Ghostcat (AJP)

dev support
21

yeah, I’m seeing that same problem, with 1.03s per request with 8.5.51, via Apache not IIS

Bug filed here 64182 – 1.03s delay on every request via ajp

I also encountered a problem with quirky config handling from the AJP connector

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" connectionTimeout="-1" secretRequired="false" address="127.0.0.1" secret="zac"/>

Lucee won’t start with this config, if I remove the secret, it works (Apache httpd 2.4 mod_proxy_ajp doesn’t support secrets until the next release)

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" connectionTimeout="-1" secretRequired="false" address="127.0.0.1"/>

It’s been already been filed as a bug 64180 – secretRequred=false is ignored if secret=<anything>

If you’re upgrading Tomcat by just replacing the lib directory, remember to copy across mod_cfml-valve_v1.1.11.jar, if your using an older version of mod_cfml, you can grab the new jar version from mod_cfml/java at master · viviotech/mod_cfml · GitHub

The newest version of mod_cfml supports returning a 307 to the first request (first request always gets a redirect), which is important, as otherwise it returns a 302 to the first request, which if it’s a POST from say a javascript app, will break everything as the POST becomes a GET and drops all the form fields.

1 Like
22

Does it change behaviour if you specify address="::1" vs address="127.0.0.1" (i.e. ipv6 vs ipv4)?

23

Thanks for confirming bug and filing/posting it Zac. For specific reasons we still make no use of IPV6 for now and we haven’t any address attribute set on 8009 connector tag. Going to set up this configuration on my dev machine as soon as I can and let you know then.

24

I’ve just added the setting address="::1" and I can confirm the performance changed. Looks like the delay went away with this setting.

2 Likes
25

The setting file and directory can be queried from the local system on the server by using a handler command like so:

http://localhost/a.cfm?BonCodeConnectorVersion=true

where a.cfm can be any mapped file extension, e.g. a.jsp, a.cfc etc.

2 Likes
26

I didn’t see a discussion around implications for running in docker containers and for the official image, itself: How to deal with TOMCAT CVE-2020-1938: Ghostcat (AJP) · Issue #61 · lucee/lucee-dockerfiles · GitHub

Hmm, I don’t appear to be using mod_proxy_ajp/mod_jk, anyway (rather, I’m using mod_proxy), so I think quick solution for me will be to remove this from server.xml:

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

Nope, wrong guess, at least with the RC version I’m running.

Commenting it out (below) didn’t change the message in the logs:

RUN sed \
    -i 's+\(<Connector [^\>]*AJP/[^>]*>\)+<!-- TOMCAT CVE-2020-1938: Ghostcat (AJP) \1 -->+' \
    '/usr/local/tomcat/conf/server.xml'

I think I’ve got to find a snapshot with the fix…

…but I have it already: 9.0.31.0 (as part of image 5.3.5.80-SNAPSHOT-tomcat9.0-jdk11-openjdk).

27

I have just been bitten with this also. I did a fresh install of Lucee on Windows & IIS using the installer to replace an old Lucee 4.5.

We could not understand why the site was so slow after the install. I remembered this thread and added in the address="::1" attribute and we are back up to speed.

Does anybody know if there is a reason that this is not included as part of the installation?

The Tomcat docs state:

For servers with more than one IP address, this attribute specifies which address will be used for listening on the specified port. By default, the connector will listen on the loopback address. Unless the JVM is configured otherwise using system properties, the Java based connectors (NIO, NIO2) will listen on both IPv4 and IPv6 addresses when configured with either 0.0.0.0 or ::. The APR/native connector will only listen on IPv4 addresses if configured with 0.0.0.0 and will listen on IPv6 addresses (and optionally IPv4 addresses depending on the setting of ipv6v6only) if configured with ::.
http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html

Perhaps having this setting in by default makes too many assumptions about peoples setup? Maybe it is just something that we need to remember to check following and install.

28

@martin: There has been already a debate about this here at github. The installer was always (and thankfully) supplied by @Jordan_Michaels (formerly at viviotech). Jordan is not at viviotech anymore and I don’t know if he or another person is supplying/will supply the future installers. But I know somebody supplied the last actual ones. I haven’t heard about Jordan for a long time now. I miss him and I hope he is doing well in these difficult times.

1 Like
29

@andreas - interesting read, thanks for pointing me to that. I did not know that Jordan was no longer at Viviotech - he has been a familiar name for a long time now.

30

Two additional points on this, first on Jordan’s move then on the possible future of ajp within tomcat.

First fwiw, here’s a post with a bit more when Jordan announced his move:

https://blog.viviotech.net/stepping-down/

In other “news anyone could have missed” I’ll point out that at tomcatcon 2019 the tomcat team discussed their intent to depreciate and ultimately remove ajp entirely. I expressed surprise and lament for the sake of so many I knew who used it (CFers and Lucee folks, though I didn’t say that as it would not likely help my cause) and for the sake of surely many others who do. They didn’t seem moved.

Igal was there and perhaps as a committer he may have new news. I’ve not followed it. Just thought I’d offer the heads up. Bilal, had you hearf or seen anything, relative to boncode perhaps?

Sorry that these are both a bit of a tangent on the thread. It just seemed an opportune time and audience in which to bring it up.

1 Like
31

Viviotech is still providing the installers for now. The Lucee installer work was the property of Viviotech and when Jordan moved on, he left it behind and entrusted it to another employee there. The installer builds have also been provided to LAS with the hope of someday getting them automated directly in the builds, but that will require someone with the time to do it.