You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@solr.apache.org by David Smiley <ds...@apache.org> on 2021/05/06 22:15:21 UTC

Solr and Security; what is CVE worthy?

Hello Solr user community,

**What sort of security problems warrant publishing a CVE?**

The Solr PMC grapples with this internally as we have access to messages
sent to security@solr.apache.org which report possible vulnerabilities /
security weaknesses in Solr.  Some reporters pressure us to issue a CVE,
which I assume is because it's tied to their livelihood / career in some
way.  In my day job, I also see how my employer takes CVEs quite seriously
as my colleagues and I scramble to do something about them, even when a
vulnerability is quite moot / irrelevant based on how we use / configure
the affected software.  So, CVEs are a big deal and they shouldn't be
issued over minor matters.

I don't think CVEs should be issued for scenarios where there is a clear
failing of a user to secure Solr adequately.  We publish advice on this in
the ref guide, and Solr even complains about Authentication / Authorization
not being configured on startup.  I suspect few users use those plugins but
there are many ways to secure Solr, and users needn't use all means
available.  I confess there is a gray area on what assumptions we have and
on what measures are adequate.

My approach to considering CVE-worthiness is strongly influenced by the
RBAC (Role Based Access Control) permission [4] for the endpoint.  If it's
a "read" based permission, I lean towards a CVE, otherwise, I lean against
it on the grounds that the user probably isn't restricting access to Solr
adequately.  Of course there is no formula to this but I want to share
that.  Also, problems with the access controls themselves are generally CVE
worthy, IMO.

I assert that all Solr components (plugins of all kinds) can be assumed to
be configurable only by trusted users.  Consequently, such components don't
have CVE worthy vulnerabilities *relating to their configuration* if they
can be configured by an attacker to cause harm.  I assert that it's up to
Solr security controls and you, our users, to use them and other controls
to stop an attacker from configuring whatever they please.  For example
someone is likely to report an issue soon relating to the
PingRequestHandler that requires that the attacker can configure it.  Does
this approach sound reasonable?

References:
* [1] Solr's security home page containing a list of CVEs:
https://solr.apache.org/security.html
* [2] Solr Reference Guide -- Securing Solr:
https://solr.apache.org/guide/8_8/securing-solr.html
* [3] Config API -- https://solr.apache.org/guide/8_8/config-api.html at
"/config"
* [4] Authentication / Authorization plugins --
https://solr.apache.org/guide/8_8/authentication-and-authorization-plugins.html
(RBAC -- Role Based Access Control).  The ref guide actually uses the
achronym RBAP.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley