CVE-2017-3164: Server-Side Request Forgery (SSRF) in org.apache.solr:solr-core
Summary
CVE-2017-3164: Server-Side Request Forgery (SSRF) in org.apache.solr:solr-core. Affects org.apache.solr:solr-core versions >= 1.30, < 7.7.0. Fixed in 7.7.0. How to fix ↓
Also tracked for
- lucene-solr · Debian:11
The same CVE-2017-3164 is tracked separately for each ecosystem and vendor. Its fix information is the same; the package and affected versions differ.
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
Apache Solr is an open-source search platform built on Apache Lucene. It provides full-text search, faceted search, and indexing capabilities. Solr-core is a core component of Apache Solr that handles the main functionalities of the search platform. This vulnerability affects versions 1.3 to 7.6 of Solr-core. The 'shards' parameter in Solr-core does not have a whitelist mechanism, allowing a remote attacker with server access to make Solr perform an HTTP GET request to any reachable URL.
Vulnerability Detail
The vulnerability in Apache Solr allows an attacker to perform Server-Side Request Forgery (SSRF) attacks. By exploiting the 'shards' parameter, an attacker can make Solr-core send HTTP GET requests to arbitrary URLs. This can lead to various security issues, such as unauthorized access to internal resources, information disclosure, or even remote code execution if the targeted URL contains malicious content. The vulnerability has a CVSS score of 7.5, indicating a high severity level.
How To Fix
Minimum fixed version
7.7.0
This is the first release that contains the fix.
Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →
Workaround
If upgrading to the latest version is not immediately possible, a temporary workaround is to implement a whitelist mechanism for the 'shards' parameter. By explicitly allowing only trusted URLs, the risk of SSRF attacks can be mitigated. Here is an example of how to implement a whitelist in Java:
// Define a list of trusted URLs
List<String> whitelist = Arrays.asList("https://example.com", "https://trusted-site.com");
// Check if the requested URL is in the whitelist
if (whitelist.contains(requestedUrl)) {
// Process the request
} else {
// Handle unauthorized access
}
Conclusion
The Server-Side Request Forgery (SSRF) vulnerability in org.apache.solr:solr-core versions 1.3 to 7.6 allows a remote attacker to make Solr perform unauthorized HTTP GET requests to arbitrary URLs. This can lead to unauthorized access, information disclosure, or even remote code execution. It is crucial to upgrade to version 7.7.0 or later of org.apache.solr:solr-core to patch the vulnerability. If immediate upgrade is not possible, implementing a whitelist mechanism for the 'shards' parameter can provide a temporary workaround. For further support on vulnerability remediation, contact DevNack.com.
See every vulnerability recorded for org.apache.solr:solr-core →
FAQ
Server-Side Request Forgery (SSRF) is a type of vulnerability that allows an attacker to make a server perform arbitrary HTTP requests on behalf of the server itself. This can be used to access internal resources, bypass security measures, or perform attacks against other systems.
If your application uses Apache Solr versions 1.3 to 7.6 (inclusive) and allows user-controlled input for the 'shards' parameter, it is vulnerable to SSRF attacks. An attacker can exploit this vulnerability to make Solr-core perform unauthorized HTTP GET requests to arbitrary URLs, potentially leading to unauthorized access, information disclosure, or remote code execution.
Yes, upgrading to version 7.7.0 or later of org.apache.solr:solr-core will fix the SSRF vulnerability. It is recommended to update the package to the latest version to ensure the vulnerability is patched.
Yes, a temporary workaround is to implement a whitelist mechanism for the 'shards' parameter. By allowing only trusted URLs, the risk of SSRF attacks can be mitigated. Refer to the 'workaround' section for an example implementation.
For further support on vulnerability remediation, you can reach out to info@devnack.com. Our team of experts will be happy to assist you in addressing the vulnerability and ensuring the security of your application.
Related vulnerabilities
Recent vulnerabilities recorded for org.apache.solr:solr-core.
