On 2/12/2021 11:17 AM, Rick Tham wrote:
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?
In order to be vulnerable to that problem, all of the following things
must be true. If any of them is NOT true, then this vulnerability does
not apply:
* The velocity jars must be loaded. A common way for this is the <lib>
configuration you mentioned, but there are other ways. Those other ways
require human intervention to move the actual files.
* Your config must *use* the jars, by containing a velocity config.
* The params resource loader must be enabled in the velocity config.
Note that the "velocity.params.resource.loader.enabled" flag only
applies if the velocity config in solrconfig.xml *references* that flag.
* Your Solr server must be reachable to unauthorized parties who would
exploit the vulnerability.
I have no idea whether any of this config can be changed remotely. I
have never used the config API. But if your Solr server is not
reachable to bad guys, it won't matter.
Simply controlling who can reach the Solr server is the easiest way to
avoid being vulnerable to anything. Although there are security
mechanisms available, Solr is not designed to be publicly reachable. It
should be heavily firewalled.
The velocity response writer usually requires end users to have direct
access to the Solr server for it to be worth something. We STRONGLY
discourage leaving Solr exposed.
Thanks,
Shawn
