Package Instance

Improper Input Validation
Reported in SOLR-14515 (private) and fixed in SOLR-14561 (public), released in Solr version 8.6.0. The Replication handler allows commands backup, restore and deleteBackup. Each of these take a location parameter, which was not validated, i.e you could read/write to any location the solr user can access.

Server-Side Request Forgery in Apache Solr
The ReplicationHandler (normally registered at "/replication" under a Solr core) in Apache Solr has a "masterUrl" (also "leaderUrl" alias) parameter that is used to designate another ReplicationHandler on another Solr core to replicate index data into the local core. To prevent a SSRF vulnerability, Solr ought to check these parameters against a similar configuration it uses for the "shards" parameter. Prior to this bug getting fixed, it did not. This problem affects essentially all Solr versions prior to it getting fixed in 8.8.2.

Apache Solr: Backup/Restore APIs allow for  deployment of executables in malicious ConfigSets
Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Solr.This issue affects Apache Solr from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1.

In the affected versions, Solr ConfigSets accepted Java jar and class files to be uploaded through the ConfigSets API.
When backing up Solr Collections, these configSet files would be saved to disk when using the LocalFileSystemRepository (the default for backups).
If the backup was saved to a directory that Solr uses in its ClassPath/ClassLoaders, then the jar and class files would be available to use with any ConfigSet, trusted or untrusted.

When Solr is run in a secure way (Authorization enabled), as is strongly suggested, this vulnerability is limited to extending the Backup permissions with the ability to add libraries.
Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue.
In these versions, the following protections have been added:

  *  Users are no longer able to upload files to a configSet that could be executed via a Java ClassLoader.
  *  The Backup API restricts saving backups to directories that are used in the ClassLoader.

Apache Solr can leak certain passwords due to System Property redaction logic inconsistencies
Insufficiently Protected Credentials vulnerability in Apache Solr.

This issue affects Apache Solr from 6.0.0 through 8.11.2, from 9.0.0 before 9.3.0.
One of the two endpoints that publishes the Solr process' Java system properties, /admin/info/properties, was only setup to hide system properties that had "password" contained in the name.
There are a number of sensitive system properties, such as "basicauth" and "aws.secretKey" do not contain "password", thus their values were published via the "/admin/info/properties" endpoint.
This endpoint populates the list of System Properties on the home screen of the Solr Admin page, making the exposed credentials visible in the UI.

This /admin/info/properties endpoint is protected under the "config-read" permission.
Therefore, Solr Clouds with Authorization enabled will only be vulnerable through logged-in users that have the "config-read" permission.
Users are recommended to upgrade to version 9.3.0 or 8.11.3, both of which fix the issue.
A single option now controls hiding Java system property for all endpoints, "-Dsolr.hiddenSysProps".
By default all known sensitive properties are hidden (including "-Dbasicauth"), as well as any property with a name containing "secret" or "password".

Users who cannot upgrade can also use the following Java system property to fix the issue:
  `-Dsolr.redaction.system.pattern=.*(password|secret|basicauth).*`

Apache Solr Schema Designer blindly "trusts" all configsets
Incorrect Permission Assignment for Critical Resource, Improper Control of Dynamically-Managed Code Resources vulnerability in Apache Solr.

This issue affects Apache Solr from 8.10.0 through 8.11.2, from 9.0.0 before 9.3.0.

The Schema Designer was introduced to allow users to more easily configure and test new Schemas and configSets.
However, when the feature was created, the "trust" (authentication) of these configSets was not considered.
External library loading is only available to configSets that are "trusted" (created by authenticated users), thus non-authenticated users are unable to perform Remote Code Execution.
Since the Schema Designer loaded configSets without taking their "trust" into account, configSets that were created by unauthenticated users were allowed to load external libraries when used in the Schema Designer.

Users are recommended to upgrade to version 9.3.0 or 8.11.3, both of which fix the issue.