Re: CVE-2019-17558 on SOLR 6.1
(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: l 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!
Re: CVE-2019-17558 on SOLR 6.1
Thanks Shawn. On Fri, Feb 12, 2021 at 7:43 PM Shawn Heisey wrote: > 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: > > > > > regex="..jar" /> > > l > 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 > 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 >
Re: CVE-2019-17558 on SOLR 6.1
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: l 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 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
CVE-2019-17558 on SOLR 6.1
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: l 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!
