Re: Email Extractor V5.6.0.0 Full Version With Patch
Jalisa Landgren
Jira is for discussing specific development modifications. Any Jira that contains only scan report output, or references multiple dependencies at the same time is likely to be ignored/closed. The large number of folks sending us reports of things that are already known is a serious drag on our (volunteer) time so please search Jira before opening a new issue.
The Solr PMC greatly appreciates reports of new security vulnerabilities found in Solr itself or demonstrations of exploiting vulnerabilities via dependencies.It is important not to publish a previously unknown exploit, or exploit demonstration code on public mailing lists.Please disclose new exploits responsibly by following these ASF guidelines for reporting.The contact email for reporting newly discovered exploits in Solr is secu...@solr.apache.org.
Since the process of checking whether CVEs in dependencies of Solr affect yourSolr deployment is tedious and error-prone, we are experimenting with sharinginformation about advisories that are known (not) to affect Solr in amachine-readable way.
We are currently providing vulnerability information in a CycloneDX JSON-basedformat here. We are very curious to hear about your experience,and to find out what is still missing to reduce the signal/noise ratio and makethese tools more effective. We invite you to join the discussion at thesecurity-discussmailinglist or,if you prefer to collaborate in private, contact...@apache.org. It will likely be interestingto know what security scanning/reporting tool you are using, exactly on whichartifacts, and if/how its vendor appears to support VEX. We'd be happy to workwith you to see if we can provide this information in other variations or formats.
The Solr sked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the "solr" and "admin" accounts for use by end-users, and a "k8s-oper" account which the operator uses for its own requests to Solr.One common source of these operator requests is healthchecks: liveness, readiness, and startup probes are all used to determine Solr's health and ability to receive traffic.By default, the operator configures the Solr APIs used for these probes to be exempt from authentication, but users may specifically request that authentication be required on probe endpoints as well.Whenever one of these probes would fail, if authentication was in use, the Solr Operator would create a Kubernetes "event" containing the username and password of the "k8s-oper" account.
Within the affected version range, this vulnerability affects any solrcloud resource which (1) bootstrapped security through use of the .solrOptions.security.authenticationType=basic option, and (2) required authentication be used on probes by setting .solrOptions.security.probesRequireAuth=true.
Mitigation:Users are recommended to upgrade to Solr Operator version 0.8.1, which fixes this issue by ensuring that probes no longer print the credentials used for Solr requests. Users may also mitigate the vulnerability by disabling authentication on their healthcheck probes using the setting .solrOptions.security.probesRequireAuth=false.
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, which fixes 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".
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.
Description:
Exposure of Sensitive Information to an Unauthorized Actor 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.
Solr Streaming Expressions allows users to extract data from other Solr Clouds, using a "zkHost" parameter.When original SolrCloud is setup to use ZooKeeper credentials and ACLs, they will be sent to whatever "zkHost" the user provides.An attacker could setup a server to mock ZooKeeper, that accepts ZooKeeper requests with credentials and ACLs and extracts the sensitive information,then send a streaming expression using the mock server's address in "zkHost".Streaming Expressions are exposed via the "/streaming" handler, with "read" permissions.
Mitigation:
Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue.From these versions on, only zkHost values that have the same server address (regardless of chroot), will use the given ZooKeeper credentials and ACLs when connecting.
Description:
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.
Description:
Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr.The Solr Metrics API publishes all unprotected environment variables available to each Apache Solr instance.Users are able to specify which environment variables to hide, however, the default list is designed to work for known secret Java system properties.Environment variables cannot be strictly defined in Solr, like Java system properties can be, and may be set for the entire host, unlike Java system properties which are set per-Java-process.
Impact:
An XXE attack may lead to the disclosure of confidential data, denial of service, server side request forgery (SSRF), port scanning from the Solr node, and other system impacts.
Users needing this SQL functionality are forced to upgrade to Solr 9.1. If Solr 8.11.3 is released, then it will be an option as well. Simply replacing Calcite and other JAR files may mostly work but could fail depending on the particulars of the query. Users interested in this or in patching their own versions of Solr should examine SOLR-16421 for a source patch.
Description:
An Improper Input Validation vulnerability in DataImportHandler of Apache Solr allows an attacker to provide a Windows UNC path resulting in an SMB network call being made from the Solr host to another host on the network. If the attacker has wider access to the network, this may lead to SMB attacks, which may result in:
Description:Apache Solr releases prior to 8.11.1 were using a bundled version of the Apache Log4J library vulnerable to RCE. For full impact and additional detail consult the Log4J security page.
The Log4J security page refers to setting log4j2.formatMsgNoLookups=true as a "discredited" mitigation. In reality, it depends.We've looked at the root cause and audited the code paths that lead to the vulnerability, and we feel confident in this mitigation being sufficient for Solr.See for discussion.
Description:The ReplicationHandler (normally registered at "/replication" under a Solr core) 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.
Description:When starting Apache Solr versions prior to 8.8.2, configured with the SaslZkACLProvider or VMParamsAllAndReadonlyDigestZkACLProvider and no existing security.json znode, if the optional read-only user is configured then Solr would not treat that node as a sensitive path and would allow it to be readable.Additionally, with any ZkACLProvider, if the security.json is already present, Solr will not automatically update the ACLs.
Description:When using ConfigurableInternodeAuthHadoopPlugin for authentication, Apache Solr versions prior to 8.8.2 would forward/proxy distributed requests using server credentials instead of original client credentials. This would result in incorrect authorization resolution on the receiving hosts.
b1e95dc632