Re: CVE-2017-7525 fix for Solr 7.7.x
Kevin & Colvin Thanks for this details response. Lotfi On Thu, Dec 19, 2019 at 11:59 AM Colvin Cowie wrote: > Sorry, in Solr 8 and master there are some additional users of Jackson. But > they still don't appear to use default typing or unrestricted subtypes. > > > On Thu, 19 Dec 2019 at 16:50, Colvin Cowie > wrote: > > > Hi, > > > > We've got users on Solr 6 (and use Jackson ourselves), so I had a look at > > this CVE and related Jackson exploits, to see whether they are actually > > exploitable in Solr. > > > >- What parts of Solr actually use Jackson (I thought noggit was used > >for the JSON de/serialization)? > >- Do any of the object mappers used enable default typing? (which is > >necessary to exploit CVE-2017-7525 > > > https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/ > >) > >- Is polymorphism used with Jackson without restricting subtypes (e.g. > >@JsonTypeInfo with JsonTypeInfo.Id.CLASS, which allows other exploits > like > >CVE-2017-15095 > > > https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 > >) > > > > Aside from test classes, the only users of Jackson appear to be > > > >- org.apache.solr.analytics.AnalyticsRequestParser > >- org.apache.solr.prometheus.scraper.SolrScraper > > > > From what I can see in the source on master and the 7_7 branch default > > typing isn't ever enabled, and @JsonTypeInfo is restricted to named > > subtypes. > > > > In the 6_6 branch source it seems Jackson is only used in a handful of > > tests. > > Prior to Solr 6.3 (https://issues.apache.org/jira/browse/SOLR-9589) > > > org.apache.solr.client.solrj.response.DelegationTokenResponse.JsonMapResponseParser > > constructed an ObjectMapper without configuration. > > > > So, as far as I can see, the polymorphic deserialization Remote Code > > Execution vulnerabilities on (older versions of) Jackson shouldn't > actually > > be exploitable in Solr 7.7... but I could be wrong, and new > vulnerabilities > > may still be discovered. > > > > Colvin > > > > > > On Wed, 18 Dec 2019 at 18:16, Kevin Risden wrote: > > > >> There are no specific plans for any 7.x branch releases that I'm aware > of. > >> Specifically for SOLR-13110, that required upgrading Hadoop 2.x to 3.x > for > >> specifically jackson-mapper-asl and there are no plans to backport that > to > >> 7.x even if there was a future 7.x release. > >> > >> Kevin Risden > >> > >> > >> On Wed, Dec 18, 2019 at 8:44 AM Mehai, Lotfi > >> wrote: > >> > >> > Hello; > >> > > >> > We are using Solr 7.7.0. The CVE-2017-7525 have been fixed for Solr > 8.x. > >> > https://issues.apache.org/jira/browse/SOLR-13110 > >> > > >> > When the fix will be available for Solr 7.7.x > >> > > >> > Lotfi > >> > > >> > > >
Re: CVE-2017-7525 fix for Solr 7.7.x
Sorry, in Solr 8 and master there are some additional users of Jackson. But they still don't appear to use default typing or unrestricted subtypes. On Thu, 19 Dec 2019 at 16:50, Colvin Cowie wrote: > Hi, > > We've got users on Solr 6 (and use Jackson ourselves), so I had a look at > this CVE and related Jackson exploits, to see whether they are actually > exploitable in Solr. > >- What parts of Solr actually use Jackson (I thought noggit was used >for the JSON de/serialization)? >- Do any of the object mappers used enable default typing? (which is > necessary to exploit CVE-2017-7525 >https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/ >) >- Is polymorphism used with Jackson without restricting subtypes (e.g. >@JsonTypeInfo with JsonTypeInfo.Id.CLASS, which allows other exploits like >CVE-2017-15095 > > https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 >) > > Aside from test classes, the only users of Jackson appear to be > >- org.apache.solr.analytics.AnalyticsRequestParser >- org.apache.solr.prometheus.scraper.SolrScraper > > From what I can see in the source on master and the 7_7 branch default > typing isn't ever enabled, and @JsonTypeInfo is restricted to named > subtypes. > > In the 6_6 branch source it seems Jackson is only used in a handful of > tests. > Prior to Solr 6.3 (https://issues.apache.org/jira/browse/SOLR-9589) > org.apache.solr.client.solrj.response.DelegationTokenResponse.JsonMapResponseParser > constructed an ObjectMapper without configuration. > > So, as far as I can see, the polymorphic deserialization Remote Code > Execution vulnerabilities on (older versions of) Jackson shouldn't actually > be exploitable in Solr 7.7... but I could be wrong, and new vulnerabilities > may still be discovered. > > Colvin > > > On Wed, 18 Dec 2019 at 18:16, Kevin Risden wrote: > >> There are no specific plans for any 7.x branch releases that I'm aware of. >> Specifically for SOLR-13110, that required upgrading Hadoop 2.x to 3.x for >> specifically jackson-mapper-asl and there are no plans to backport that to >> 7.x even if there was a future 7.x release. >> >> Kevin Risden >> >> >> On Wed, Dec 18, 2019 at 8:44 AM Mehai, Lotfi >> wrote: >> >> > Hello; >> > >> > We are using Solr 7.7.0. The CVE-2017-7525 have been fixed for Solr 8.x. >> > https://issues.apache.org/jira/browse/SOLR-13110 >> > >> > When the fix will be available for Solr 7.7.x >> > >> > Lotfi >> > >> >
Re: CVE-2017-7525 fix for Solr 7.7.x
Hi, We've got users on Solr 6 (and use Jackson ourselves), so I had a look at this CVE and related Jackson exploits, to see whether they are actually exploitable in Solr. - What parts of Solr actually use Jackson (I thought noggit was used for the JSON de/serialization)? - Do any of the object mappers used enable default typing? (which is necessary to exploit CVE-2017-7525 https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/ ) - Is polymorphism used with Jackson without restricting subtypes (e.g. @JsonTypeInfo with JsonTypeInfo.Id.CLASS, which allows other exploits like CVE-2017-15095 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 ) Aside from test classes, the only users of Jackson appear to be - org.apache.solr.analytics.AnalyticsRequestParser - org.apache.solr.prometheus.scraper.SolrScraper >From what I can see in the source on master and the 7_7 branch default typing isn't ever enabled, and @JsonTypeInfo is restricted to named subtypes. In the 6_6 branch source it seems Jackson is only used in a handful of tests. Prior to Solr 6.3 (https://issues.apache.org/jira/browse/SOLR-9589) org.apache.solr.client.solrj.response.DelegationTokenResponse.JsonMapResponseParser constructed an ObjectMapper without configuration. So, as far as I can see, the polymorphic deserialization Remote Code Execution vulnerabilities on (older versions of) Jackson shouldn't actually be exploitable in Solr 7.7... but I could be wrong, and new vulnerabilities may still be discovered. Colvin On Wed, 18 Dec 2019 at 18:16, Kevin Risden wrote: > There are no specific plans for any 7.x branch releases that I'm aware of. > Specifically for SOLR-13110, that required upgrading Hadoop 2.x to 3.x for > specifically jackson-mapper-asl and there are no plans to backport that to > 7.x even if there was a future 7.x release. > > Kevin Risden > > > On Wed, Dec 18, 2019 at 8:44 AM Mehai, Lotfi > wrote: > > > Hello; > > > > We are using Solr 7.7.0. The CVE-2017-7525 have been fixed for Solr 8.x. > > https://issues.apache.org/jira/browse/SOLR-13110 > > > > When the fix will be available for Solr 7.7.x > > > > Lotfi > > >
Re: CVE-2017-7525 fix for Solr 7.7.x
There are no specific plans for any 7.x branch releases that I'm aware of. Specifically for SOLR-13110, that required upgrading Hadoop 2.x to 3.x for specifically jackson-mapper-asl and there are no plans to backport that to 7.x even if there was a future 7.x release. Kevin Risden On Wed, Dec 18, 2019 at 8:44 AM Mehai, Lotfi wrote: > Hello; > > We are using Solr 7.7.0. The CVE-2017-7525 have been fixed for Solr 8.x. > https://issues.apache.org/jira/browse/SOLR-13110 > > When the fix will be available for Solr 7.7.x > > Lotfi >
CVE-2017-7525 fix for Solr 7.7.x
Hello; We are using Solr 7.7.0. The CVE-2017-7525 have been fixed for Solr 8.x. https://issues.apache.org/jira/browse/SOLR-13110 When the fix will be available for Solr 7.7.x Lotfi
Re: cve-2017-
Thank you very much On Fri, Mar 1, 2019 at 12:24 AM Tomás Fernández Löbbe wrote: > I updated the description of SOLR-12770 > <https://issues.apache.org/jira/browse/SOLR-12770> a bit. The problem > stated is that, since the "shards" parameter allows any URL, someone could > make an insecure Solr instance hit some other (secure) web endpoint. Solr > would throw an exception, but the error may include information from such > endpoint (parsing error). I don't believe this would allow access to a > local file (though, if you know of a way, please report to > secur...@lucene.apache.org) > > The only way to know (to my knowledge) if your Solr instance was affected > is by looking at your Solr logs. If you log queries, you should be able to > see what's being included in the "shards" parameter and detect something > that's not looking right. Also, if Solr is fooled to hit some other > endpoint, it would fail with a parsing error, so you should probably see > exceptions in your logs. The worst case, I guess, depends on how much > access the Solr process has and how much damage it can cause to an adjacent > web endpoint via a GET request. > > Note that this can only impact you if your Solr instance can be directly > accessed by untrusted sources. > > HTH > > On Thu, Feb 28, 2019 at 11:54 AM Jeff Courtade > wrote: > > > This particular cve came out in the mailing list. Fed 12th > > > > > > CVE-2017-3164 SSRF issue in Apache Solr > > > > I need to know what the exploit for this could be? > > > > > > can a user send a bogus shards param via a web request and get a local > > file? > > > > > > What does an attack vector look like for this? > > > > > > I am being asked specifically this... > > > > > > - How would we know if the vulnerability in the Solr CVE was > > taking advantage of? What are signs of us being exploited? What is the > > worst case scenario with this CVE? > > > > Could someone help me answer this please? > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/www-announce/201902.mbox/%3CCAECwjAVjBN=wO5rYs6ktAX-5=-f5jdfwbbtsm2ttjebgo5j...@mail.gmail.com%3E > > > > > > > > the bug is > > > > > > > > https://issues.apache.org/jira/browse/SOLR-12770 > > > > > > > > the mitigation is upgrading to solr 7.7 > > >
Re: cve-2017-
Thanks, very helpful. We make an internal Jira for every Solr vulnerability and I was checking this one out this week. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Feb 28, 2019, at 9:23 PM, Tomás Fernández Löbbe > wrote: > > I updated the description of SOLR-12770 > <https://issues.apache.org/jira/browse/SOLR-12770> a bit. The problem > stated is that, since the "shards" parameter allows any URL, someone could > make an insecure Solr instance hit some other (secure) web endpoint. Solr > would throw an exception, but the error may include information from such > endpoint (parsing error). I don't believe this would allow access to a > local file (though, if you know of a way, please report to > secur...@lucene.apache.org) > > The only way to know (to my knowledge) if your Solr instance was affected > is by looking at your Solr logs. If you log queries, you should be able to > see what's being included in the "shards" parameter and detect something > that's not looking right. Also, if Solr is fooled to hit some other > endpoint, it would fail with a parsing error, so you should probably see > exceptions in your logs. The worst case, I guess, depends on how much > access the Solr process has and how much damage it can cause to an adjacent > web endpoint via a GET request. > > Note that this can only impact you if your Solr instance can be directly > accessed by untrusted sources. > > HTH > > On Thu, Feb 28, 2019 at 11:54 AM Jeff Courtade > wrote: > >> This particular cve came out in the mailing list. Fed 12th >> >> >> CVE-2017-3164 SSRF issue in Apache Solr >> >> I need to know what the exploit for this could be? >> >> >> can a user send a bogus shards param via a web request and get a local >> file? >> >> >> What does an attack vector look like for this? >> >> >> I am being asked specifically this... >> >> >> - How would we know if the vulnerability in the Solr CVE was >> taking advantage of? What are signs of us being exploited? What is the >> worst case scenario with this CVE? >> >> Could someone help me answer this please? >> >> >> >> >> http://mail-archives.apache.org/mod_mbox/www-announce/201902.mbox/%3CCAECwjAVjBN=wO5rYs6ktAX-5=-f5jdfwbbtsm2ttjebgo5j...@mail.gmail.com%3E >> >> >> >> the bug is >> >> >> >> https://issues.apache.org/jira/browse/SOLR-12770 >> >> >> >> the mitigation is upgrading to solr 7.7 >>
Re: cve-2017-
I updated the description of SOLR-12770 <https://issues.apache.org/jira/browse/SOLR-12770> a bit. The problem stated is that, since the "shards" parameter allows any URL, someone could make an insecure Solr instance hit some other (secure) web endpoint. Solr would throw an exception, but the error may include information from such endpoint (parsing error). I don't believe this would allow access to a local file (though, if you know of a way, please report to secur...@lucene.apache.org) The only way to know (to my knowledge) if your Solr instance was affected is by looking at your Solr logs. If you log queries, you should be able to see what's being included in the "shards" parameter and detect something that's not looking right. Also, if Solr is fooled to hit some other endpoint, it would fail with a parsing error, so you should probably see exceptions in your logs. The worst case, I guess, depends on how much access the Solr process has and how much damage it can cause to an adjacent web endpoint via a GET request. Note that this can only impact you if your Solr instance can be directly accessed by untrusted sources. HTH On Thu, Feb 28, 2019 at 11:54 AM Jeff Courtade wrote: > This particular cve came out in the mailing list. Fed 12th > > > CVE-2017-3164 SSRF issue in Apache Solr > > I need to know what the exploit for this could be? > > > can a user send a bogus shards param via a web request and get a local > file? > > > What does an attack vector look like for this? > > > I am being asked specifically this... > > > - How would we know if the vulnerability in the Solr CVE was > taking advantage of? What are signs of us being exploited? What is the > worst case scenario with this CVE? > > Could someone help me answer this please? > > > > > http://mail-archives.apache.org/mod_mbox/www-announce/201902.mbox/%3CCAECwjAVjBN=wO5rYs6ktAX-5=-f5jdfwbbtsm2ttjebgo5j...@mail.gmail.com%3E > > > > the bug is > > > > https://issues.apache.org/jira/browse/SOLR-12770 > > > > the mitigation is upgrading to solr 7.7 >
cve-2017-
This particular cve came out in the mailing list. Fed 12th CVE-2017-3164 SSRF issue in Apache Solr I need to know what the exploit for this could be? can a user send a bogus shards param via a web request and get a local file? What does an attack vector look like for this? I am being asked specifically this... - How would we know if the vulnerability in the Solr CVE was taking advantage of? What are signs of us being exploited? What is the worst case scenario with this CVE? Could someone help me answer this please? http://mail-archives.apache.org/mod_mbox/www-announce/201902.mbox/%3CCAECwjAVjBN=wO5rYs6ktAX-5=-f5jdfwbbtsm2ttjebgo5j...@mail.gmail.com%3E the bug is https://issues.apache.org/jira/browse/SOLR-12770 the mitigation is upgrading to solr 7.7
[SECURITY] CVE-2017-3164 SSRF issue in Apache Solr
CVE-2017-3164 SSRF issue in Apache Solr Severity: High Vendor: The Apache Software Foundation Versions Affected: Apache Solr versions from 1.3 to 7.6.0 Description: The "shards" parameter does not have a corresponding whitelist mechanism, so it can request any URL. Mitigation: Upgrade to Apache Solr 7.7.0 or later. Ensure your network settings are configured so that only trusted traffic is allowed to ingress/egress your hosts running Solr. Credit: dk from Chaitin Tech References: https://issues.apache.org/jira/browse/SOLR-12770 https://wiki.apache.org/solr/SolrSecurity
Solr and vulnerabilities CVE-2017-15718 and CVE-2017-15713
Hi,Is solr affected by these two vulnerabilities CVE-2017-15718 and CVE-2017-15713? ThanksMikhail
Re: Fwd: CVE-2017-3163 - SOLR-5.2.1 version
Pad Read the CVE. Do you have an affected version of Solr? Do you have the replication feature enabled in solrconfig.xml? Note that it might be enabled by default. Test directory traversal on your system: can you read files remotely? No? Then you are finished. A better plan: upgrade to a newer version of Solr (I know, you may not be able to). Cheers -- Rick On November 20, 2017 4:01:47 AM EST, padmanabhan gonesani <paddu.1...@gmail.com> wrote: >Please help me here > > > >-- Forwarded message -- >From: padmanabhan gonesani <paddu.1...@gmail.com> >Date: Mon, Nov 13, 2017 at 5:12 PM >Subject: CVE-2017-3163 - SOLR-5.2.1 version >To: gene...@lucene.apache.org > > > >Hi Team, > >*Description:* Apache Solr could allow a remote attacker to traverse >directories on the system, caused by a flaw in the Index Replication >feature. An attacker could send a specially-crafted request to read >arbitrary files on the system (CVE-ID: CVE-2017-3163) > >Security vulnerability link: https://cve.mitre.org/cgi-bin/ >cvename.cgi?name=CVE-2017-3163 > >*Apache SOLR implementation:* > >We are using Apache Solr-5.2.1 and replication factor=1 for index >creation. >We are using basic common SOLR features and it doesn't have the >following >features > >1. Index Replication >2. Master / slave mechanism > >*Considering the above not implemented features will this "CVE-ID: >CVE-2017-3163" security vulnerability have any impact?* > >Any help is appreciated here. > > >Best Regards, >Paddy G >+91-8148593020 <+91%2081485%2093020> > > > >-- > > >Best Regards, >Paddy G >+91-8148593020 -- Sorry for being brief. Alternate email is rickleir at yahoo dot com
Fwd: CVE-2017-3163 - SOLR-5.2.1 version
Please help me here -- Forwarded message -- From: padmanabhan gonesani <paddu.1...@gmail.com> Date: Mon, Nov 13, 2017 at 5:12 PM Subject: CVE-2017-3163 - SOLR-5.2.1 version To: gene...@lucene.apache.org Hi Team, *Description:* Apache Solr could allow a remote attacker to traverse directories on the system, caused by a flaw in the Index Replication feature. An attacker could send a specially-crafted request to read arbitrary files on the system (CVE-ID: CVE-2017-3163) Security vulnerability link: https://cve.mitre.org/cgi-bin/ cvename.cgi?name=CVE-2017-3163 *Apache SOLR implementation:* We are using Apache Solr-5.2.1 and replication factor=1 for index creation. We are using basic common SOLR features and it doesn't have the following features 1. Index Replication 2. Master / slave mechanism *Considering the above not implemented features will this "CVE-ID: CVE-2017-3163" security vulnerability have any impact?* Any help is appreciated here. Best Regards, Paddy G +91-8148593020 <+91%2081485%2093020> -- Best Regards, Paddy G +91-8148593020
[ANNOUNCE] [SECURITY] CVE-2017-12629: Several critical vulnerabilities discovered in Apache Solr (XXE & RCE)
CVE-2017-12629: Several critical vulnerabilities discovered in Apache Solr (XXE & RCE) Severity: Critical Vendor: The Apache Software Foundation Versions Affected: Solr 5.5.0 to 5.5.4 Solr 6.0.0 to 6.6.1 Solr 7.0.0 to 7.0.1 Description: The details of this vulnerability were reported on public mailing lists. See https://s.apache.org/FJDl The first vulnerability relates to XML external entity expansion in the XML Query Parser which is available, by default, for any query request with parameters deftype=xmlparser. This can be exploited to upload malicious data to the /upload request handler. It can also be used as Blind XXE using ftp wrapper in order to read arbitrary local files from the solr server. The second vulnerability relates to remote code execution using the RunExecutableListener available on all affected versions of Solr. At the time of the above report, this was a 0-day vulnerability with a working exploit affecting the versions of Solr mentioned in the previous section. However, mitigation steps were announced to protect Solr users the same day. See https://lucene.apache.org/solr/news.html#12-october-2017-please-secure-your-apache-solr-servers-since-a-zero-day-exploit-has-been-reported-on-a-public-mailing-list Mitigation: Users are advised to upgrade to either Solr 6.6.2 or Solr 7.1.0 releases both of which address the two vulnerabilities. Once upgrade is complete, no other steps are required. If users are unable to upgrade to Solr 6.6.2 or Solr 7.1.0 then they are advised to restart their Solr instances with the system parameter `-Ddisable.configEdit=true`. This will disallow any changes to be made to your configurations via the Config API. This is a key factor in this vulnerability, since it allows GET requests to add the RunExecutableListener to your config. Users are also advised to re-map the XML Query Parser to another parser to mitigate the XXE vulnerability. For example, adding the following to the solrconfig.xml file re-maps the xmlparser to the edismax parser: Credit: Michael Stepankin (JPMorgan Chase) Olga Barinova (Gotham Digital Science) References: https://issues.apache.org/jira/browse/SOLR-11482 https://issues.apache.org/jira/browse/SOLR-11477 https://wiki.apache.org/solr/SolrSecurity -- Regards, Shalin Shekhar Mangar.
Re: CVE-2017-12629 which versions are vulnerable?
Sorry, I missed the post from Florian Gleixner: >Re: Several critical vulnerabilities discovered in Apache Solr (XXE & RCE) Am 16.10.2017 um 16:52 schrieb Uwe Reh: Hi, I'm still using V4.10. Is this version also vulnerable by http://openwall.com/lists/oss-security/2017/10/13/1 ? Uwe
CVE-2017-12629 which versions are vulnerable?
Hi, I'm still using V4.10. Is this version also vulnerable by http://openwall.com/lists/oss-security/2017/10/13/1 ? Uwe
CVE-2017-9803: Security vulnerability in kerberos delegation token functionality
CVE-2017-9803: Security vulnerability in kerberos delegation token functionality Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Solr 6.2.0 to 6.6.0 Description: Solr's Kerberos plugin can be configured to use delegation tokens, which allows an application to reuse the authentication of an end-user or another application. There are two issues with this functionality (when using SecurityAwareZkACLProvider type of ACL provider e.g. SaslZkACLProvider), Firstly, access to the security configuration can be leaked to users other than the solr super user. Secondly, malicious users can exploit this leaked configuration for privilege escalation to further expose/modify private data and/or disrupt operations in the Solr cluster. The vulnerability is fixed from Solr 6.6.1 onwards. Mitigation: 6.x users should upgrade to 6.6.1 Credit: This issue was discovered by Hrishikesh Gadre of Cloudera Inc. References: https://issues.apache.org/jira/browse/SOLR-11184 https://wiki.apache.org/solr/SolrSecurity -- The Lucene PMC
[ANNOUNCE] [SECURITY] CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr
CVE-2017-7660: Security Vulnerability in secure inter-node communication in Apache Solr Severity: Important Vendor: The Apache Software Foundation Versions Affected: Solr 5.3 to 5.5.4 Solr 6.0 to 6.5.1 Description: Solr uses a PKI based mechanism to secure inter-node communication when security is enabled. It is possible to create a specially crafted node name that does not exist as part of the cluster and point it to a malicious node. This can trick the nodes in cluster to believe that the malicious node is a member of the cluster. So, if Solr users have enabled BasicAuth authentication mechanism using the BasicAuthPlugin or if the user has implemented a custom Authentication plugin, which does not implement either "HttpClientInterceptorPlugin" or "HttpClientBuilderPlugin", his/her servers are vulnerable to this attack. Users who only use SSL without basic authentication or those who use Kerberos are not affected. Mitigation: 6.x users should upgrade to 6.6 5.x users should obtain the latest source from git and apply this patch: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/2f5ecbcf Credit: This issue was discovered by Noble Paul of Lucidworks Inc. References: https://issues.apache.org/jira/browse/SOLR-10624 https://wiki.apache.org/solr/SolrSecurity -- The Lucene PMC
[SECURITY] CVE-2017-3163 Apache Solr ReplicationHandler path traversal attack
CVE-2017-3163: Apache Solr ReplicationHandler path traversal attack Severity: Moderate Vendor: The Apache Software Foundation Versions Affected: Solr 1.4 to 6.4.0 Description: When using the Index Replication feature, Solr nodes can pull index files from a master/leader node using an HTTP API which accepts a file name. However, Solr did not validate the file name, hence it was possible to craft a special request involving path traversal, leaving any file readable to the Solr server process exposed. Solr servers protected and restricted by firewall rules and/or authentication would not be at risk since only trusted clients and users would gain direct HTTP access. Mitigation: 6.x users should upgrade to 6.4.1 5.x users should upgrade to 5.5.4 4.x, 3.x and 1.4 users should upgrade to a supported version of Solr or setup proper firewalling, or disable the ReplicationHandler if not in use. Credit: This issue was discovered by Hrishikesh Gadre of Cloudera Inc. References: https://issues.apache.org/jira/browse/SOLR-10031 https://wiki.apache.org/solr/SolrSecurity The Lucene PMC signature.asc Description: Message signed with OpenPGP
