(Resending to the list. Sorry, Rick.)
FYI, my client was using 8.3.1, which should have mitigated the attack.
But the server was suffering a sudden death of the Solr process, and the log
showed it was being attacked using CVE-2019-17558.
We blocked the external access of Solr API. Then this sudden death ended. So I
tend to think just disabling the Velocity engine might not enough.
Of course there is a possibility that this server was also getting a different
kind of attack. We don't know.
But in general, the Solr port should be closed from external access.
TK
On 2/12/21 10:17 AM, Rick Tham wrote:
We are using Solr 6.1 and at the moment we can not upgrade due to
application dependencies.
We have mitigation steps in place to only trust specific machines within
our DMZ.
I am trying to figure out if the following is an additioanal valid
mitigation step for CVE-2019-17558 on SOLR 6.1. None of our solrconfig.xml
contains the lib references to the velocity jar files as follows:
<lib dir="${solr.install.dir:../../../..}/contrib/velocity/lib"
regex="..jar" />
l<ib dir="${solr.install.dir:../../../..}/dist/"
regex="solr-velocity-\d..jar" />
It doesn't appear that you can add these jars references using the config
API. Without these references, you are not able to flip the
params.resource.loader.enabled to true using the config API. If you are not
able to flip the flag and none of your cores have these lib references then
is the risk present?
Thanks in advance!
