OpenClinica User Manual/TomcatAjpVulnerability
March 03 2020 a vulnerability in tomcat's AJP connector was published. The team that discovered it named it ghostcat. Apache-Tomcat has issued a patch for this vulnerability. The intention of this page is to help you decide whether you should take action or not and if so, in what way.
Should I be worried?Edit
If you are an OpenClinica-adminstrator, you should be worried, as OpenClinica runs on tomcat, so you could run a risk.
the short versionEdit
Let's make this short for the more technical readers: you run a risk if ajp is activated and is listening on a port that is exposed to the internet. If you fall in this category: download and install the latest version of tomcat, which for tomcat7 is at the time of writing, March 5 2020, 7.0.100 https://tomcat.apache.org/download-70.cgi
not so quick: first tell me what ajp isEdit
There are several ways to communicate with tomcat, or: to connect with tomcat. These different ways are therefore called connectors. You are probably aware that you can use http and/or https on some port. A typical out of the box installation allows for communication on port 8080 for http. But maybe you have setup secure communications with a certificate and use https on port 8443. Adding to this you may have a port open for ajp, which stands for Apache JServ Protocol. This is mostly used when you have a separate webserver, for example Apache or IIS, that does all the heavy encryption-work and serves static content. If this is your situation, skip the next paragraph. If you don't have a separate web-server, read on one more paragrah.
I don't have a separate web-server: am I safe?Edit
You may not "use" ajp because you don't have a separate web-server, but unfortunately this doesn't mean you're safe. In your installation you may have activated the ajp-connector and it is now listening, by default on port 8009. You can check this by issuing
netstat -vatn|grep 8009
and if the output is somehing like
tcp6 0 0 :::8009 :::* LISTEN
then you know that ajp is active and listening.
Or you can look at your server.xml for something that looks like this:
<!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8" maxParameterCount="-1" maxPostSize="-1" />
If you don't need ajp, you can safely de-activate it, by commenting it out in the server.xml
<!-- Define an AJP 1.3 Connector on port 8009 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8" maxParameterCount="-1" maxPostSize="-1" /> -->
so ajp is listening: does that mean I run a risk?Edit
If ajp is listening then yes, you do run a risk, but only if this port is exposed to the outside world. If you have set up a firewall to only allow https on port 443, and maybe some additional ports for maintenance, then you don't run a risk.
ajp is listening and I must expose the port to the outsideEdit
Now, if for whatever reason you can't de-activate ajp and you can't block communication on this port 8009 (or whatever port you defined), then you must upgrade your tomcat.
installing the patchEdit
If you want to patch your tomcat installation, do the following: Probably most OpenClinica installations use tomcat7, so go to https://tomcat.apache.org/download-70.cgi The first version to have the fix is tomcat 7.0.100. What this version has is an etra check for using the ajp-connector, namely a secret. You set this extra check in the server.xml, for example
<!-- Define an AJP 1.3 Connector on port 8009 --> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" URIEncoding="UTF-8" maxParameterCount="-1" secretRequired="true" secret="un_deux_trois" />
If you now restart your tomcat and try to request a page, using Apache in combination with ajp, then you will get a 403.
Good. Because this will also be the result for attackers.
Last step to take is telling the secret to Apache, so it can communicate with tomcat.
This is done in the worker.properties file
worker.tomcat7.port=8009 worker.tomcat7.host=localhost worker.tomcat7.type=ajp13 worker.tomcat7.secret=un_deux_trois
The vulnerability was discovered by a Chinese team, who published some background information. You can read more about ghostcat at https://www.chaitin.cn/en/ghostcat
A short version of the changes in tomcat7 can be found at https://tomcat.apache.org/migration-7.html#Tomcat_7.0.x_noteable_changes