Hello All,
Firstly, I appreciate the Lucidworks resource shared earlier. However, it doesn't cover the CVEs related to jackson-databind that I've outlined below. These vulnerabilities are a point of concern for our security department. CVE Concerns I've compiled a list of CVEs related to jackson-databind that could potentially affect Solr, along with reasons why our security department wont approve it: 1. CVE-2018-11307 * Title: FasterXML jackson-databind Default Typing Issue with iBatis Gadget Class * Summary: This vulnerability allows attackers to exfiltrate content by exploiting Jackson's default typing along with a gadget class from iBatis. * Reason for Concern: If Solr uses an affected version of jackson-databind and also uses iBatis, it could be vulnerable to data exfiltration. 2. CVE-2018-14718 * Title: Remote Code Execution via slf4j-ext Class * Summary: Allows remote attackers to execute arbitrary code by failing to block the slf4j-ext class during deserialization. * Reason for Concern: If Solr uses a vulnerable version of jackson-databind and slf4j, remote code execution is possible. 3. CVE-2019-14892 * Title: Arbitrary Code Execution via commons-configuration JNDI Classes * Summary: Allows attackers to execute arbitrary code using commons-configuration 1 and 2 JNDI classes. * Reason for Concern: If Solr uses affected versions and commons-configuration, it's at risk of arbitrary code execution. 4. CVE-2019-16943 * Title: Polymorphic Typing Issue with p6spy * Summary: Allows attackers to execute a malicious payload if the service has the p6spy jar in the classpath. * Reason for Concern: If Solr uses p6spy and a vulnerable version of jackson-databind, it could execute malicious payloads. 5. CVE-2019-17267 * Title: Polymorphic Typing Issue with EhcacheJtaTransactionManagerLookup * Summary: Related to net.sf.ehcache.hibernate.EhcacheJtaTransactionManagerLookup. * Reason for Concern: If Solr uses Ehcache and is on an affected version of jackson-databind, it could be vulnerable. 6. CVE-2019-17531 * Title: Polymorphic Typing Issue with apache-log4j-extra * Summary: Allows attackers to execute a malicious payload if the service has apache-log4j-extra in the classpath. * Reason for Concern: If Solr uses apache-log4j-extra and a vulnerable version of jackson-databind, it could execute malicious payloads. 7. CVE-2019-20330 * Title: Lack of net.sf.ehcache Blocking * Summary: Lacks certain net.sf.ehcache blocking. * Reason for Concern: If Solr uses Ehcache and a vulnerable version of jackson-databind, it could be vulnerable. 8. CVE-2020-8840 * Title: Lack of xbean-reflect/JNDI Blocking * Summary: Lacks certain xbean-reflect/JNDI blocking. * Reason for Concern: If Solr uses xbean-reflect and a vulnerable version of jackson-databind, it could be vulnerable. 9. CVE-2020-9547 * Title: Serialization Gadget Issue with ibatis-sqlmap * Summary: Mishandles the interaction between serialization gadgets and typing. * Reason for Concern: If Solr uses ibatis-sqlmap and a vulnerable version of jackson-databind, it could be vulnerable. 10. CVE-2020-9548 * Title: Serialization Gadget Issue with anteros-core * Summary: Mishandles the interaction between serialization gadgets and typing. * Reason for Concern: If Solr uses anteros-core and a vulnerable version of jackson-databind, it could be vulnerable. It's worth noting that many of these jackson-databind issues are transitively referenced by htrace4. I'm currently investigating whether the affected dependencies are actually utilized in htrace4. Best regards, Tim ________________________________ Von: Colvin Cowie <colvin.cowie....@gmail.com> Gesendet: Dienstag, 22. August 2023 14:36 An: users@solr.apache.org <users@solr.apache.org> Betreff: Re: Inquiry Regarding CVEs and Their Impact on Apache Solr 8.11.2 Those CVEs all appear to relate to old Jackson versions. Solr 8.11.2 includes jackson 2.13.3 which is not affected by those CVEs. So I'm not sure why a scanner would even flag those CVEs, unless they're transitively referenced by other dependencies. On Tue, 22 Aug 2023 at 13:02, Mark Bennett <mbenn...@ideaeng.com> wrote: > Hi Guys, > > One of the cool things Lucidworks did was to publish AND REPEATEDLY UPDATE > all the CVE stuff. In addition to supporting their own Fusion product, > Lucid also does quite a bit of Solr work and communications. > > If you go on the public support site (no login needed), you can just search > for CVE info: > > https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.lucidworks.com%2Fhc%2Fen-us%2Fsearch%3Futf8%3D%25E2%259C%2593%26query%3Dcve&data=05%7C01%7C%7Cd06679f66e4145afe8ab08dba30c64cb%7C90423b5ca4e74157a4b27e1360854d93%7C0%7C0%7C638283045855813549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pcfEOpbH33ORlvWLuPETxHMQZ2bOnRZhXKM0vgwJHL8%3D&reserved=0<https://support.lucidworks.com/hc/en-us/search?utf8=%E2%9C%93&query=cve> > > They've got 4 or 5 notes.. If you managed to read them all and make notes, > you'll have a very good picture of the situation. > > ALSO, just because a CVE issue exists, often there must also be very > specific configuration or use pattern to trigger the breach. BUT, if > you're not using those particular features, the specific CVE risk may not > even be feasible in your locked down setup. > > Lucid really took this seriously. > > I hope some of that helps. > > > -- > Mark Bennett / mbenn...@ideaeng.com / Cell: 408-829-6513 > > > On Tue, Aug 22, 2023 at 5:20 AM Jan Høydahl <jan....@cominvent.com> wrote: > > > Hi, > > > > It would be helpful if you instead of copy/pasting 10 CVE numbers, could > > break it up and list one by one with its title and summary, and why you > > have reason to worry that it is a problem for Solr. > > > > Then our team can consider each one you believe to be problematic, and > > decide whether we are vulnerable or not, and perhaps update the list at > > > https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsolr.apache.org%2Fsecurity.html%23cve-reports-for-apache-solr-dependencies&data=05%7C01%7C%7Cd06679f66e4145afe8ab08dba30c64cb%7C90423b5ca4e74157a4b27e1360854d93%7C0%7C0%7C638283045855813549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=IHWFtTl348tcxnsPpSHTxnqWAisdMAA9OM0G%2FwjW%2B58%3D&reserved=0<https://solr.apache.org/security.html#cve-reports-for-apache-solr-dependencies> > > with the findings. We also accept Pull Requests for that page at > > https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fsolr-site&data=05%7C01%7C%7Cd06679f66e4145afe8ab08dba30c64cb%7C90423b5ca4e74157a4b27e1360854d93%7C0%7C0%7C638283045855813549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c1w9MFx%2F5d3syc%2BV%2FHG48mOZTEJZhCxfLYGeBuvSLg8%3D&reserved=0<https://github.com/apache/solr-site> > > > > Jan > > > > > 22. aug. 2023 kl. 13:03 skrev Tim Pfeifer (ext) < > tim.pfeifer....@devk.de > > .INVALID>: > > > > > > Dear Apache Solr Community, > > > > > > We are currently in the process of migrating to AWS Cloud, and as part > > of this transition, we scanned our existing Apache Solr 8.11.2 with > > AquaSec. Several critical security vulnerabilities have emerged from this > > scan. > > > > > > While many of the identified CVEs are already listed on > > https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsolr.apache.org%2Fsecurity.html&data=05%7C01%7C%7Cd06679f66e4145afe8ab08dba30c64cb%7C90423b5ca4e74157a4b27e1360854d93%7C0%7C0%7C638283045855813549%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oj55n%2FHqVuiOmSwWR1bB9ff6KJxyx9TLrJ27aehcq8U%3D&reserved=0<https://solr.apache.org/security.html> > > and labeled as "not affected", > > there are some for which we couldn't find any information. We would like > to > > know if Apache Solr is affected by the following CVEs: > > > > > > * CVE-2018-11307 > > > * CVE-2018-14718 > > > * CVE-2019-14892 > > > * CVE-2019-16943 > > > * CVE-2019-17267 > > > * CVE-2019-17531 > > > * CVE-2019-20330 > > > * CVE-2020-8840 > > > * CVE-2020-9547 > > > * CVE-2020-9548 > > > > > > This information is crucial for us to ensure that our deployment is > > secure and approved by our security department. Any information or advice > > you can provide regarding the aforementioned CVEs would be greatly > > appreciated. > > > > > > In conclusion, I thank you in advance for your time and support. Please > > let me know if you need any additional information or if I should clarify > > my request further. I will patiently await your response and am open to > any > > feedback or suggestions. > > > > > > Warm regards, > > > Tim > > > > >
