Default Security in Solr 8.4

Apache Solr 8.4 is an important, notable release for one reason: it’s default security settings.

I’m guilty as charged for having been broadly dismissive of security issues with Solr for a few reasons (excuses, really): 

1. Solr is a search engine that needs to have All The Data in order to be useful.
2. I come from an academic / knowledge mindset of Open is Better.
3. Solr relies on its deployed environment for resources and configuration, which is out of Solr’s control and thus “not [our] problem”.

Firewall It!

“Firewall it!” has been many a first response to, “How do I secure my Solr?” That’s still sage advice. But it’s easier said than done on a system that has historically run open by default. Attacks/mishaps from inside the firewall are common anyway. Just firewalling things isn’t the answer to the real question at hand (though “of course you should firewall it”). The answer is that Solr must own it’s own security.

Security is a nuanced topic spanning open bound ports, server exposed endpoints and capabilities thereof, authentication and authorization of users accessing the system, in to the data available and access control requirements of each piece of data, and ultimately even the resources available on or from the systems exposed.

What’s Fixed in Solr 8.4

The Apache Solr team wrangled several security vulnerabilities over the last year. With immense credit and gratitude to the other Solr committers notably Ishan and Noble in this case, I swept up behind the mess that I had made in an age-old feature I contributed to Solr and worked directly to address its zero-day RCE (remote code execution) vulnerability.

There are several categories of security related changes in this release: addition of security related HTTP response headers, the removal of built-in “contrib” modules from the default collection configuration, the hardening of VelocityResponseWriter, and package/plugin management features.

Security related HTTP headers

SOLR-13982 added several additional headers to Solr’s HTTP responses to that deter inline JavaScript from executing, cross-site scripting (XSS), and cross-origin HTML frames

Removal of “contrib” modules from default collection configuration

We’ve allowed Solr’s default configuration to become an accumulation of various end-points through what’s know as “contrib” (built into the distribution, but separate components that can be plugged in easily).  These components are powerful (allow scripting capabilities), yet aren’t supported as well as core Solr code. Rarely does one _really_ run all of these things, but they’re ready for action on all default `bin/solr create -c <collection>` created collections since days of yore.  

This is now now longer the case, with the following dramatic changes to the default configset ( SOLR-13978):

• Library inclusions (<lib ../>) for extraction, solr-cell libs, clustering, velocity, LTR and language identifier
• /browse, /tvrh and /update/extract handlers
• TermVector component
  (if someone wants it, can be added using config APIs)
• XSLT response writer
• Velocity response writer

Using these components in your collections is now a matter of adding the necessary pieces to a trusted configset of your choosing through configset editing via ZK operations or Config APIs.

Additionally, untrusted configsets (ones that are uploaded via unsecured configset API) cannot use the <lib> directive.  (via SOLR-14071) 

I’m working on an update on the https://lucidworks.com/post/solr-5-new-binpost-utility/ series of articles due to these changes, as all of these niceties of being able to easily create a collection, post data to it, and visually navigate search results in a few commands is no longer out of the box pleasant… for your own (default) good, mind you.

Hardening of the VelocityResponseWriter

I built this thing to be able to do *anything* and *everything*.   Velocity is a templating library, that renders the output of processing macros which ultimately are Java objects which have methods.  The VelocityResponseWriter puts the kitchen sink into the Velocity _context_, the “data” (err, objects) available to the templates is rich.  That’s where I went too far, or rather took the easy way out and gave the templates everything when all they really need are some key/value strings to render, not object graphs that can navigate to `$rt.getRuntime().exec(…)`.  Oh the power!

Solr 8.3.1 was a first attempt at addressing this issue, but left one other door open.  The 8.4 release closed all known, and many theoretically and technically possible avenues as well.  With this component not registered by default any more, it’s not a vector contender out of the box.

Package/plugin management features

SOLR-13821 gives us a solid start to one of Solr’s holy grail needs – a security conscious package management.  Packages, encapsulated in .jar files, must be signed and hosted by a trusted package store. We expect to see those components removed from the default configuration re-emerge as new and improved easily installable packages in the Solr 9.0 time frame.

Be Careful Out There

Solr 8.4 gets us to a tight, secure core out of the box, still with all the powerful componentry available to authenticated, trusted configurations.  The team will continue to work vigilantly to be security-minded while still providing all the necessary capabilities safely.