Solr™ 安全新聞

如何回報安全問題

掃描器偵測到的已發布 CVE

每個被軟體掃描器偵測到的 CVE，根據定義，都已經是公開的資訊。這表示 Solr PMC 和世界上其他人可能已經知道它了。

為了找到解決偵測到的 CVE 的方法，我們建議以下流程以獲得最快的結果：

  1. 查看本頁下方，看看該 CVE 是否被列為在 Solr 中可利用。
  2. 查看官方發布的不可利用漏洞列表，看看該 CVE 是否被列為在 Solr 中不可利用。
  3. 搜尋Solr 使用者郵件列表存檔，看看是否有人提出這個相依性 CVE。
  4. 如果沒有人提出，請訂閱使用者郵件列表，然後發送電子郵件詢問該 CVE。

應做與不應做

  • 請務必在使用者列表中討論可能的函式庫升級需求。
  • 請務必在 Jira 中搜尋 CVE 編號，看看我們是否已在處理它。
  • 請務必建立 Jira 問題和相關的 pull request，以提出和討論 *單一特定*相依性的升級。
  • 請勿在 Jira 中附加掃描報告或貼上掃描輸出 (請改為連結 CVE)
  • 請勿將掃描報告透過電子郵件寄到下方的安全電子郵件，它將被忽略。
  • 請務必使用 VEX 來研究自動化這方面的作業，並分享您的經驗。

Jira 的使用

Jira 用於討論特定的開發修改。任何僅包含掃描報告輸出或同時參考多個相依性的 Jira 都可能會被忽略/關閉。大量的人向我們發送已知問題的報告，嚴重拖累了我們（志願者）的時間，因此**請在開啟新問題之前搜尋 Jira**。

您在 Solr 中發現的新漏洞

Solr PMC 非常感謝收到在 Solr 本身中發現的新安全漏洞報告，或是透過相依性示範利用漏洞的報告。**重要的是不要在公開郵件列表中發布先前未知的漏洞**，或是漏洞示範程式碼。請依照這些ASF 指導方針來負責地揭露新的漏洞。報告 Solr 中新發現的漏洞的聯絡電子郵件為 security@solr.apache.org。

在報告新的漏洞之前，請確保您已針對執行支援版本且已正確設定的 Solr 實例進行過測試，並具有

  1. 驗證 - 沒有登入示範的漏洞浪費了我們的時間，因為 Solr 並不是要設定成讓全世界都能存取其所有 API。在沒有強制使用者登入的情況下執行，與在 Linux 中使用廣為人知的預設 root 密碼，或是在沒有密碼的 root 帳戶下執行資料庫一樣無效。
  2. 授權 - 除非經過驗證的使用者被設定的角色應該禁止該動作，或是無論角色為何都不應允許該動作，否則這不算漏洞。您的報告應說明您為何認為此動作對於您測試的角色來說是不可接受的。

VEX

由於檢查 Solr 相依性中的 CVE 是否影響您的 Solr 部署的過程既繁瑣又容易出錯，我們正在實驗以機器可讀的方式分享已知 (或未知) 會影響 Solr 的建議資訊。

用於分享此資訊的檔案格式稱為「VEX」格式。許多此類格式正在積極開發中，例如基於 CycloneDX 和 CSAF。

我們目前以基於 CycloneDX JSON 的格式在此提供漏洞資訊。我們非常想聽聽您的經驗，並找出仍缺少什麼來降低訊號/雜訊比，並使這些工具更有效。我們邀請您加入 security-discuss 郵件列表的討論，或者，如果您希望私下協作，請聯絡 security@apache.org。了解您正在使用哪個安全掃描/報告工具、確切的構件以及其供應商是否支援 VEX 以及如何支援，將會很有意思。我們很樂意與您合作，看看我們是否能以其他變體或格式提供此資訊。

更多資訊

您可以在我們的 Wiki 上找到更多安全相關資訊：https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity

Apache Solr 的近期 CVE 報告

以下是已發布的 CVE 漏洞清單。這些也以 ATOM 摘要的形式提供

CVE 編號 日期 公告
CVE-2024-45216 2024-10-14 Apache Solr：使用虛假的 URL 路徑結尾可能會繞過驗證
CVE-2024-45217 2024-10-14 Apache Solr：在備份還原命令期間建立的 ConfigSet 會被隱式信任
CVE-2024-31391 2024-04-12 Solr-Operator 活躍度和就緒探針可能會洩漏基本驗證憑證
CVE-2023-50291 2024-02-08 由於系統屬性編輯邏輯不一致，Apache Solr 可能會洩漏某些密碼
CVE-2023-50292 2024-02-08 Apache Solr 結構描述設計工具會盲目地「信任」所有 configset，可能會導致未經驗證的使用者執行 RCE
CVE-2023-50298 2024-02-08 Apache Solr 可以透過串流表達式洩漏 ZooKeeper 憑證
CVE-2023-50386 2024-02-08 Apache Solr：備份/還原 API 允許在惡意 ConfigSet 中部署可執行檔
CVE-2023-50290 2024-01-12 Apache Solr 允許讀取主機環境變數
CVE-2022-39135 2022-11-20 Apache Solr 容易受到透過 /sql 處理常式造成的 CVE-2022-39135 影響
CVE-2021-44548 2021-12-18 Apache Solr 透過 DataImportHandler 洩漏資訊的漏洞
CVE-2021-44228 2021-12-10 Apache Solr 受到 Apache Log4J CVE-2021-44228 的影響
CVE-2021-27905 2021-04-12 使用複製處理常式的 SSRF 漏洞
CVE-2021-29262 2021-04-12 不當套用的 Zookeeper ACL 可能會導致洩漏設定的驗證和授權設定
CVE-2021-29943 2021-04-12 Apache Solr 非特權使用者可能能夠對集合執行未經授權的讀取/寫入
CVE-2020-13957 2020-10-12 可以在 Apache Solr 中規避針對未經驗證的 configset 上傳新增的檢查

2024-10-14，CVE-2024-45216：Apache Solr：使用虛假的 URL 路徑結尾可能會繞過驗證

嚴重性
嚴重

受影響的版本

  • Apache Solr 5.3.0 至 8.11.4 之前的版本
  • Apache Solr 9.0.0 至 9.7.0 之前的版本

說明
Apache Solr 中的不當驗證漏洞。

使用 PKIAuthenticationPlugin 的 Solr 實例（當使用 Solr 驗證時，預設會啟用）容易受到驗證繞過的攻擊。在任何 Solr API URL 路徑結尾加上虛假的結尾，將允許請求跳過驗證，同時維持與原始 URL 路徑的 API 合約。此虛假的結尾看起來像是一個未受保護的 API 路徑，但在驗證後但在 API 路由之前會在內部剝除。

緩解措施
建議使用者升級到 9.7.0 或 8.11.4 版本，這些版本已修正此問題。

貢獻者：Liu Huajin (報告者)

參考資料
JIRA - SOLR-17417
CVE - CVE-2024-45216

2024-10-14，CVE-2024-45217：Apache Solr：在備份還原命令期間建立的 ConfigSet 會被隱式信任

嚴重性
中

受影響的版本

  • Apache Solr 6.6.0 至 8.11.4 之前的版本
  • Apache Solr 9.0.0 至 9.7.0 之前的版本

說明

Apache Solr 中的不安全資源預設初始化漏洞。

透過還原命令建立的新 ConfigSet，會從備份中複製 configSet 並給予新名稱，建立時不會設定「受信任」的中繼資料。如果中繼資料遺失，則不包含旗標的 ConfigSet 會被隱式信任，因此這會導致「受信任」的 ConfigSet 可能並非由經過驗證的請求建立。「受信任」的 ConfigSet 能夠將自訂程式碼載入至類別載入器，因此旗標應該只在上傳 ConfigSet 的請求經過驗證和授權時才會設定。

緩解措施
此問題影響 Apache Solr：從 6.6.0 至 8.11.4 之前的版本，從 9.0.0 至 9.7.0 之前的版本。此問題不會影響透過驗證/授權保護的 Solr 實例。

主要建議使用者在執行 Solr 時使用驗證和授權。但是，升級到 9.7.0 或 8.11.4 版本將可解決此問題。

貢獻者：Liu Huajin (報告者)

參考資料
JIRA - SOLR-17418
CVE - CVE-2024-45217

2024-04-12，CVE-2024-31391：Solr-Operator 活躍度和就緒探針可能會洩漏基本驗證憑證

嚴重性
中

受影響的版本
Solr Operator 0.3.0 至 0.8.0

說明： Apache Solr Operator 中將敏感資訊插入至記錄檔的漏洞。

為了引導 Solr 安全性，運算子將會啟用基本驗證並建立多個用於存取 Solr 的帳戶：包括供最終使用者使用的「solr」和「admin」帳戶，以及運算子用於其自身對 Solr 的請求的「k8s-oper」帳戶。這些運算子請求的一個常見來源是健康檢查：活躍度、就緒和啟動探針都用於判斷 Solr 的健康狀況和接收流量的能力。依預設，運算子會設定用於這些探針的 Solr API 免除驗證，但是使用者可能會特別要求也需要在探針端點上進行驗證。每當其中一個探針失敗時，如果正在使用驗證，Solr Operator 會建立一個包含「k8s-oper」帳戶的使用者名稱和密碼的 Kubernetes「事件」。

在受影響的版本範圍內，此漏洞會影響任何 solrcloud 資源，這些資源 (1) 透過使用 .solrOptions.security.authenticationType=basic 選項引導安全性，並且 (2) 透過設定 .solrOptions.security.probesRequireAuth=true 要求在探針上使用驗證。

緩解措施：建議使用者升級到 Solr Operator 0.8.1 版，此版本會修正此問題，方法是確保探針不再列印用於 Solr 請求的憑證。使用者也可以透過使用設定 .solrOptions.security.probesRequireAuth=false 來停用其健康檢查探針上的驗證，以緩解此漏洞。

參考資料
JIRA - SOLR-17216
CVE - CVE-2024-31391

2024-02-08，CVE-2023-50291：由於系統屬性編輯邏輯不一致，Apache Solr 可能會洩漏某些密碼

嚴重性
中

受影響的版本

  • Apache Solr 6.0.0 至 8.11.2
  • Apache Solr 9.0.0 至 9.3.0 之前的版本

說明
Apache Solr 中的憑證保護不足漏洞。

此問題影響 Apache Solr：從 6.0.0 版到 8.11.2 版，以及從 9.0.0 版到 9.3.0 版之前的版本。其中一個用於發布 Solr 處理程序 Java 系統屬性的端點 /admin/info/properties，僅設定為隱藏名稱中包含「password」的系統屬性。有許多敏感的系統屬性，例如「basicauth」和「aws.secretKey」並不包含「password」，因此它們的值會透過「/admin/info/properties」端點發布。此端點會在 Solr 管理頁面的首頁上填入系統屬性列表，使暴露的憑證在 UI 中可見。

此 /admin/info/properties 端點受到「config-read」權限的保護。因此，啟用授權的 Solr Cloud 只會透過具有「config-read」權限的已登入使用者受到攻擊。建議使用者升級至 9.3.0 或 8.11.3 版本，以修復此問題。現在有一個單一選項可以控制所有端點的 Java 系統屬性隱藏，即「-Dsolr.hiddenSysProps」。預設情況下，所有已知的敏感屬性都會被隱藏（包括「-Dbasicauth」），以及任何名稱包含「secret」或「password」的屬性。

無法升級的使用者也可以使用以下 Java 系統屬性來修復此問題
-Dsolr.redaction.system.pattern=".*(password|secret|basicauth).*"

緩解措施
建議使用者升級至 8.11.3、9.3.0 或更高版本，這些版本具有一致的 systemProperty 修訂邏輯。

貢獻者： Michael Taggart（回報者）

參考資料
JIRA - SOLR-16809
CVE - CVE-2023-50291

2024-02-08，CVE-2023-50292：Apache Solr Schema Designer 盲目「信任」所有 configset，可能導致未經身分驗證的使用者執行 RCE

嚴重性
中

受影響的版本

  • Apache Solr 6.0.0 至 8.11.2
  • Apache Solr 9.0.0 至 9.3.0 之前的版本

說明
Apache Solr 中關鍵資源的權限指派不正確，不當控制動態管理的程式碼資源漏洞。

此問題影響 Apache Solr：從 8.10.0 版到 8.11.2 版，以及從 9.0.0 版到 9.3.0 版之前的版本。

引入 Schema Designer 是為了讓使用者更容易地配置和測試新的 Schema 和 configSet。但是，在建立此功能時，並未考慮這些 configSet 的「信任」（身分驗證）。外部程式庫載入僅適用於「受信任」（由已驗證的使用者建立）的 configSet，因此未經身分驗證的使用者無法執行遠端程式碼執行。由於 Schema Designer 在載入 configSet 時未考慮其「信任」，因此允許在 Schema Designer 中使用由未經身分驗證的使用者建立的 configSet 來載入外部程式庫。

緩解措施
建議使用者升級至 8.11.3、9.3.0 或更高版本。

貢獻者： Skay（回報者）

參考資料
JIRA - SOLR-16777
CVE - CVE-2023-50292

2024-02-08，CVE-2023-50298：Apache Solr 可以透過串流運算式公開 ZooKeeper 憑證

嚴重性
低

受影響的版本

  • Apache Solr 6.0.0 至 8.11.2
  • Apache Solr 9.0.0 版到 9.4.1 版之前的版本

說明
Apache Solr 中未經授權的行為者暴露敏感資訊漏洞。此問題影響 Apache Solr：從 6.0.0 版到 8.11.2 版，以及從 9.0.0 版到 9.4.1 版之前的版本。

Solr 串流運算式允許使用者使用「zkHost」參數從其他 Solr Cloud 提取資料。當原始 SolrCloud 設定為使用 ZooKeeper 憑證和 ACL 時，這些憑證和 ACL 將會傳送到使用者提供的任何「zkHost」。攻擊者可以設定伺服器來模擬 ZooKeeper，該伺服器接受帶有憑證和 ACL 的 ZooKeeper 請求，並提取敏感資訊，然後使用「zkHost」中的模擬伺服器位址傳送串流運算式。串流運算式透過具有「讀取」權限的「/streaming」處理常式公開。

緩解措施
建議使用者升級至 8.11.3 或 9.4.1 版本，以修復此問題。從這些版本開始，只有具有相同伺服器位址（無論 chroot 為何）的 zkHost 值，才會在使用連線時使用給定的 ZooKeeper 憑證和 ACL。

貢獻者： Qing Xu（回報者）

參考資料
JIRA - SOLR-17098
CVE - CVE-2023-50298

2024-02-08，CVE-2023-50386：Apache Solr：備份/還原 API 允許在惡意的 ConfigSet 中部署可執行檔

嚴重性
中

受影響的版本

  • Apache Solr 6.0.0 至 8.11.2
  • Apache Solr 9.0.0 版到 9.4.1 版之前的版本

說明
Apache Solr 中不當控制動態管理的程式碼資源、不限制上傳危險類型檔案、包含來自不受信任控制範圍的功能漏洞。此問題影響 Apache Solr：從 6.0.0 版到 8.11.2 版，以及從 9.0.0 版到 9.4.1 版之前的版本。

在受影響的版本中，Solr ConfigSet 接受透過 ConfigSet API 上傳的 Java jar 和類別檔案。在備份 Solr 集合時，這些 configSet 檔案在使用 LocalFileSystemRepository（備份預設值）時會儲存到磁碟。如果備份儲存到 Solr 在其 ClassPath/ClassLoaders 中使用的目錄，則 jar 和類別檔案將可用於任何 configSet，無論是否受信任。

當 Solr 以安全方式執行（啟用授權）時（強烈建議），此漏洞僅限於擴展備份權限，使其具有新增程式庫的能力。

緩解措施
建議使用者升級至 8.11.3 或 9.4.1 版本，以修復此問題。在這些版本中，已新增以下保護措施

  • 使用者不再能夠將可透過 Java ClassLoader 執行的檔案上傳至 configSet。
  • 備份 API 限制將備份儲存至 ClassLoader 中使用的目錄。

貢獻者： L3yx（回報者）

參考資料
JIRA - SOLR-16949
CVE - CVE-2023-50386

2024-01-12，CVE-2023-50290：Apache Solr 允許讀取主機環境變數

嚴重性
重要

受影響的版本
Solr 9.0 到 9.2.1

說明
Apache Solr 中未經授權的行為者暴露敏感資訊漏洞。Solr Metrics API 會發布每個 Apache Solr 實例可用的所有未受保護的環境變數。使用者可以指定要隱藏的環境變數，但是，預設列表旨在適用於已知的機密 Java 系統屬性。環境變數無法像 Java 系統屬性那樣在 Solr 中嚴格定義，並且可以針對整個主機進行設定，這與每個 Java 處理程序設定的 Java 系統屬性不同。

Solr Metrics API 受「metrics-read」權限的保護。因此，設定授權的 Solr Cloud 只會透過具有「metrics-read」權限的使用者受到攻擊。

緩解措施
建議使用者升級至 9.3.0 或更高版本，其中環境變數不會透過 Metrics API 發布。

參考資料
JIRA - SOLR-15233
CVE - CVE-2023-50290

2022-11-20，Apache Solr 透過 /sql 處理常式容易受到 CVE-2022-39135 的攻擊

受影響的版本
Solr 6.5 到 8.11.2 Solr 9.0

說明
Apache Calcite 有一個漏洞 CVE-2022-39135，在 Apache Solr 的 SolrCloud 模式中可利用。如果不受信任的使用者可以向 Solr 的「/sql」處理常式提供 SQL 查詢（即使是透過 Proxy / 其他應用程式間接提供），則使用者可以執行 XML 外部實體 (XXE) 攻擊。Solr 的某些部署者可能為了讓內部分析師可以使用基於 JDBC 的工具而公開此漏洞，但不太可能授予更廣泛的受眾。

影響
XXE 攻擊可能會導致洩漏機密資料、拒絕服務、伺服器端請求偽造 (SSRF)、從 Solr 節點進行埠掃描以及其他系統影響。

緩解措施
大多數 Solr 安裝都沒有使用 SQL 功能。對於這些使用者來說，使用防火牆的標準 Solr 安全建議應該就足夠了。儘管如此，該功能可以停用。從 Solr 9 開始，它已模組化，因此成為選擇加入的功能，因此對於不使用它的 Solr 9 使用者來說，不需要任何操作。不使用 SolrCloud 的使用者根本無法使用此功能。對於其他希望停用此功能的使用者，您必須註冊一個請求處理常式，該處理常式會像在 solrconfig.xml 中那樣遮蔽基礎功能

  <requestHandler name="/sql" class="solr.NotFoundRequestHandler"/>

需要此 SQL 功能的使用者必須升級到 Solr 9.1。如果發布 Solr 8.11.3，那麼它也會是一個選項。簡單地替換 Calcite 和其他 JAR 檔案可能大部分情況下都有效，但可能會因為查詢的具體情況而失敗。有興趣了解此情況或修補自己版本的 Solr 的使用者應該檢查 SOLR-16421 以取得原始程式碼修補程式。

貢獻者
CoreMedia GmbH 的 Andreas Hubold

參考資料
JIRA - SOLR-16421
CVE - CVE-2022-39135

2021-12-18，CVE-2021-44548：Apache Solr 透過 DataImportHandler 的資訊洩漏漏洞

嚴重性
中

受影響的版本
8.11.1 之前的所有版本。受影響的平台：Windows。

說明
Apache Solr 的 DataImportHandler 中的輸入驗證不當漏洞允許攻擊者提供 Windows UNC 路徑，導致從 Solr 主機向網路上的另一個主機發出 SMB 網路呼叫。如果攻擊者對網路有更廣泛的存取權限，這可能會導致 SMB 攻擊，進而可能導致

  • 洩漏敏感資料，例如 OS 使用者雜湊值 (NTLM/LM 雜湊值)，
  • 在設定不當的系統中，SMB 中繼攻擊可能導致在 SMB 共用上冒用使用者身分，或者在最壞的情況下，遠端程式碼執行

此問題會影響 8.11.1 之前的所有 Apache Solr 版本。此問題僅影響 Windows。

緩解措施
升級至 Solr 8.11.1，以及/或確保只有受信任的用戶端才能向 Solr 的 DataImport 處理常式發出請求。

貢獻者
Apache Solr 感謝 Nsfocus 安全團隊的 LaiHan 回報此問題

參考資料
Jira 問題 SOLR-15826

2021-12-10，Apache Solr 受 Apache Log4J CVE-2021-44228 影響

嚴重性：嚴重

受影響的版本：7.4.0 到 7.7.3、8.0.0 到 8.11.0

描述：8.11.1 之前的 Apache Solr 版本使用捆綁的 Apache Log4J 程式庫版本，該版本容易受到 RCE 的攻擊。有關完整影響和其他詳細資訊，請參閱 Log4J 安全頁面。

7.4 之前的 Apache Solr 版本（即 Solr 5、Solr 6 和 Solr 7 到 7.3）使用 Log4J 1.2.17，對於使用包含 JMS Appender 的非預設記錄組態的安裝，它可能存在漏洞，請參閱 https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 進行討論。

Solr 的 Prometheus Exporter 也使用 Log4J，但它不會記錄使用者輸入或資料，因此我們認為這方面沒有風險。

Solr 沒有受到後續的 CVE-2021-45046 和 CVE-2021-45105 的攻擊。Solr 的 Wiki 中列出了這些和其他 CVE 以及一些理由：https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools

緩解措施：以下任何一種方法都足以防止 Solr 伺服器發生此漏洞

  • 升級到 Solr 8.11.1 或更高版本（可用時），其中將包含更新版本的 Log4J 相依性 (>= 2.16.0)。
  • 如果您使用 Solr 的官方 Docker 映像檔，則已在 Docker Hub 上列出的所有支援版本中進行了緩解：https://hub.docker.com/_/solr。您可能需要重新提取映像檔。
  • 手動更新執行階段類別路徑上的 Log4J 版本並重新啟動您的 Solr 應用程式。
  • （Linux/MacOS）編輯您的 solr.in.sh 檔案以包含：SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
  • （Windows）編輯您的 solr.in.cmd 檔案以包含：set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=true
  • 遵循 https://logging.apache.org/log4j/2.x/security.html 中列出的其他任何緩解措施

Log4J 安全頁面將設定 log4j2.formatMsgNoLookups=true 視為「名譽掃地」的緩解措施。實際上，這取決於具體情況。我們研究了根本原因，並審核了導致漏洞的程式碼路徑，我們確信此緩解措施對 Solr 而言已足夠。請參閱 https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz 以瞭解討論內容。

參考資料： https://logging.apache.org/log4j/2.x/security.html

2021-04-12，CVE-2021-27905：Replication 處理器的 SSRF 漏洞

嚴重性：高

受影響版本： 7.0.0 至 7.7.3、8.0.0 至 8.8.1

描述： ReplicationHandler（通常在 Solr 核心下的 "/replication" 註冊）具有一個 "masterUrl"（也稱為 "leaderUrl" 別名）參數，用於指定另一個 Solr 核心上的另一個 ReplicationHandler，以將索引資料複寫到本機核心。為了防止 SSRF 漏洞，Solr 應針對其用於 "shards" 參數的類似組態檢查這些參數。在修復此錯誤之前，它沒有這樣做。

緩解措施：以下任何一項都足以防止此漏洞

  • 升級至 Solr 8.8.2 或更高版本。
  • 如果無法升級，請考慮套用 SOLR-15217 中的修補程式
  • 確保對複製處理器的任何存取僅限於 Solr 內部。通常，它僅在外部用於診斷/資訊目的。

致謝：由奇安信集團（QI-ANXIN Technology Group Inc.）的 Caolinhong(Skay) 報告

參考資料： SOLR-15217：CVE-2021-27905：Replication 處理器的 SSRF 漏洞

2021-04-12，CVE-2021-29262：錯誤套用的 Zookeeper ACL 可能導致設定的驗證和授權設定洩漏

嚴重性：高

受影響版本： 7.0.0 至 7.7.3、8.0.0 至 8.8.1

描述： 當啟動 Apache Solr 8.8.2 之前的版本，並使用 SaslZkACLProvider 或 VMParamsAllAndReadonlyDigestZkACLProvider 組態且沒有現有的 security.json znode 時，如果組態了選用的唯讀使用者，則 Solr 不會將該節點視為敏感路徑，並允許其可讀取。此外，對於任何 ZkACLProvider，如果 security.json 已存在，則 Solr 不會自動更新 ACL。

緩解措施：以下任何一項都足以防止此漏洞

  • 手動在 /security.json znode 上設定適當的 ACL。
  • 升級至 Solr 8.8.2 或更高版本。
  • 如果無法升級，請考慮套用 SOLR-15249 中的修補程式
  • 確保對 zookeeper 的任何存取僅由受信任的應用程式進行。

致謝： Apple Cloud Services 的 Timothy Potter 和 Mike Drob

參考資料： SOLR-15249：CVE-2021-29262：錯誤套用的 Zookeeper ACL 可能導致設定的驗證和授權設定洩漏

2021-04-12，CVE-2021-29943：Apache Solr 未經授權的使用者可能能夠對集合執行未經授權的讀/寫操作

嚴重性：高

受影響版本： 7.0.0 至 7.7.3、8.0.0 至 8.8.1

描述： 當使用 ConfigurableInternodeAuthHadoopPlugin 進行驗證時，Apache Solr 8.8.2 之前的版本會使用伺服器憑證而不是原始用戶端憑證來轉發/代理分散式請求。這會導致接收主機上不正確的授權解析。

緩解措施：以下任何一項都足以防止此漏洞

  • 升級至 Solr 8.8.2 或更高版本。
  • 如果無法升級，請考慮套用 SOLR-15233 中的修補程式
  • 使用其他驗證外掛程式，例如 KerberosPlugin 或 HadoopAuthPlugin

致謝： Geza Nagy

參考資料： SOLR-15233：CVE-2021-29943：Apache Solr 未經授權的使用者可能能夠對集合執行未經授權的讀/寫操作

2020-10-12，CVE-2020-13957：在 Apache Solr 中新增至未經驗證的組態集上傳的檢查可以被規避

嚴重性：高

受影響版本： 6.6.0 至 6.6.6、7.0.0 至 7.7.3、8.0.0 至 8.6.2

描述： Solr 會阻止在未經驗證/授權的情況下透過 API 上傳的 ConfigSet 中組態一些被認為是危險的功能（可能用於遠端程式碼執行）。透過結合使用 UPLOAD/CREATE 動作，可以規避防止這些功能的檢查。

緩解措施：以下任何一項都足以防止此漏洞

  • 如果未使用，請停用 ConfigSets API 中的 UPLOAD 命令，方法是將系統屬性： configset.upload.enabled 設定為 false (請參閱文件)
  • 使用驗證/授權，並確保不允許未知的請求 (請參閱文件)
  • 升級至 Solr 8.6.3 或更高版本。
  • 如果無法升級，請考慮套用 SOLR-14663 中的修補程式
  • 沒有任何 Solr API（包括管理 UI）被設計為向非信任方公開。調整您的防火牆，以便只有受信任的電腦和人員才能存取

致謝： Tomás Fernández Löbbe、András Salamon

參考資料： SOLR-14925：CVE-2020-13957：新增至未經驗證的組態集上傳的檢查可以被規避

Apache Solr 相依性的 CVE 報告

以下是 Apache Solr 相依性中 CVE 漏洞的列表，以及它們對 Solr 的適用性狀態。

我們目前正在試驗以 機器可讀的 VEX 格式提供此資訊，並鼓勵您參與。

id 版本 jar 狀態 詳細資訊
CVE-2022-33980 < 9.1 commons-configuration2-2.7.jar 不受影響 Solr 僅將 commons-configuration2 用於「hadoop-auth」（用於 Kerberos）。它僅用於載入僅由受信任的管理員（而非外部（不受信任的））提供的 Hadoop 組態檔案。
CVE-2022-42889 < 9.1 commons-text-1.9.jar 不受影響 Solr 直接在 LoadAdminUiServlet 中使用 commons-text（StringEscapeUtils.escapeEcmaScript），該 servlet 不易受攻擊。Solr 還有一個「hadoop-auth」模組，該模組使用 Apache Hadoop，而 Apache Hadoop 透過 commons-configuration2 使用 commons-text。對於 Solr，關注點僅限於載入僅由受信任的管理員（而非外部（不受信任的））提供的 Hadoop 組態檔案。
CVE-2022-25168 < 9.1 hadoop-common-3.2.2.jar 不受影響 Solr 不會使用易受攻擊的程式碼，因為 Solr 僅將 HDFS 用作用戶端。
CVE-2021-44832 7.4-8.11.1 log4j-core-2.14.1.jar、log4j-core-2.16.0.jar 不受影響 Solr 的預設記錄組態不使用 JDBCAppender，而且我們認為使用者不會想要使用它或其他不明顯的 appender。
CVE-2021-45105、CVE-2021-45046 7.4-8.11.1 log4j-core-2.14.1.jar、log4j-core-2.16.0.jar 不受影響 Solr 使用的 MDC 資料用於集合、分片、副本、核心和節點名稱，以及潛在的追蹤 ID，這些都已清理過。此外，Solr 的預設記錄組態不使用雙錢號，而且我們認為使用者不會想要這樣做。
CVE-2020-13955 8.1.0 - 今日 avatica-core-1.13.0.jar、calcite-core-1.18.0.jar 不受影響 Solr 的 SQL 配接器不使用易受攻擊的類別 "HttpUtils"。Calcite 僅將其用於與 Druid 或 Splunk 通訊。
CVE-2018-10237 5.4.0 - 今日 carrot2-guava-18.0.jar 不受影響 僅與 Carrot2 叢集引擎一起使用。
CVE-2014-0114 4.9.0-7.5.0 commons-beanutils-1.8.3.jar 不受影響 這僅在編譯時使用，不能用於攻擊 Solr。由於通常不必要，因此此相依性已從 7.5.0 開始移除。請參閱 SOLR-12617。
CVE-2019-10086 8.0.0-8.3.0 commons-beanutils-1.9.3.jar 不受影響 雖然 commons-beanutils 已在 7.5 中移除，但在 8.0 中錯誤地重新加入，並在 8.3 中再次移除。易受攻擊的類別未在任何 Solr 程式碼路徑中使用。此 jar 仍然是 Velocity 和 hadoop-common 的相依性，但 Solr 不會在我們的實作中使用它。
CVE-2012-2098、CVE-2018-1324、CVE-2018-11771 4.6.0 - 今日 commons-compress（僅作為 Ant 1.8.2 的一部分） 不受影響 僅在測試框架和建置時使用。
CVE-2018-1000632 4.6.0 - 今日 dom4j-1.6.1.jar 不受影響 僅在 Solr 測試中使用。
CVE-2018-10237 4.6.0 - 今日 guava-*.jar 不受影響 僅在測試中使用。
CVE-2017-15718 6.6.1-7.6.0 hadoop-auth-2.7.4.jar、hadoop-hdfs-2.7.4.jar（所有 Hadoop） 不受影響 不會影響 Solr，因為 Solr 將 Hadoop 用作用戶端程式庫。
CVE-2017-14952 6.0.0-7.5.0 icu4j-56.1.jar、icu4j-59.1.jar 不受影響 問題僅適用於 ICU 的 C++ 版本，而不適用於 Lucene 使用的 ICU4J。截至 Lucene/Solr 7.6.0，ICU4J 為 v63.2
CVE-2017-15095、CVE-2017-17485、CVE-2017-7525、CVE-2018-5968、CVE-2018-7489、CVE-2019-12086、CVE-2019-12384、CVE-2018-12814、CVE-2019-14379、CVE-2019-14439、CVE-2020-35490、CVE-2020-35491、CVE-2021-20190、CVE-2019-14540、CVE-2019-16335 4.7.0 - 今日 jackson-databind-*.jar 不受影響 這些 CVE，以及自 2017 年以來大多數已知的 jackson-databind CVE，都與在還原序列化不受信任的資料期間可能被利用的問題「小工具」有關。Jackson 開發人員描述了要利用問題小工具必須滿足的 4 個條件。請參閱 https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062。Solr 對 jackson-databind 的使用不符合描述的 4 個條件中的 1 個，這使得這些 CVE 無法利用。Solr 未滿足的具體條件是第三個條件：「啟用多型別處理」Solr 不包含任何多型別處理，而且 Solr 不會將 jackson-databind 的還原序列化/序列化設定為期望或在序列化的 JSON 中包含類別名稱。兩個 CVE，2019-14540 和 2019-16335，與 HikariConfig 和 HikariDataSource 類別相關，這兩個類別都未使用在 Solr 的程式碼庫中。
CVE-2019-10241、CVE-2019-10247 7.7.0-8.2 jetty-9.4.14 不受影響 Solr 已將 Jetty 升級到 9.4.19 以用於 8.2 版本。此外，利用這些漏洞的路徑已在 8.1 和 7.7.2 中修復。較早的版本可以手動修補其組態，如 SOLR-13409 中所述。
CVE-2020-27218 7.3.0-8.8.0 jetty-9.4.0 至 9.4.34 不受影響 僅在使用 Jetty 的 GzipHandler 時可被利用，該處理常式僅在內嵌式 Solr 伺服器中實作。
CVE-2020-27223 7.3.0 - 目前 jetty-9.4.6 至 9.4.36 不受影響 僅當 Solr 的 webapp 目錄部署為符號連結時才可被利用，而這不是 Solr 的預設設定。
CVE-2021-33813 至今 jdom-*.jar 不受影響 JDOM 僅在 Solr Cell 中使用，而不應在生產環境中使用，這使得漏洞無法利用。它是 Apache Tika 的相依性，該相依性已分析該問題並確定漏洞僅限於搜尋應用程式中不常用的兩個程式庫，請參閱 TIKA-3488 以瞭解詳細資訊。由於 Tika 應在 Solr 之外使用，如果擔心暴露於此問題，請使用更新了受影響程式庫的 Tika 版本。
CVE-2018-1000056 4.6.0-7.6.0 junit-4.10.jar 不受影響 JUnit 僅在測試中使用；CVE 僅指代 Solr 未使用的 Jenkins 外掛程式。
CVE-2014-7940、CVE-2016-6293、CVE-2016-7415、CVE-2017-14952、CVE-2017-17484、CVE-2017-7867、CVE-2017-7868 7.3.1 lucene-analyzers-icu-7.3.1.jar 不受影響 所有這些問題都適用於 ICU 的 C++ 版本，而不適用於 Lucene 使用的 ICU4J。
CVE-2019-16869 8.2-8.3 netty-all-4.1.29.Final.jar 不受影響 這不包含在 Solr 中，但它是 ZooKeeper 3.5.5 的相依性。該版本已在 ZooKeeper 3.5.6 中升級，其中包含 Solr 8.3。CVE 中提到的特定類別未在 Solr 中使用（就 Solr 社群所知，在 ZooKeeper 中也未使用）。
CVE-2017-14868, CVE-2017-14949 5.2.0-至今 org.restlet-2.3.0.jar 不受影響 Solr 不應暴露在防火牆之外，讓惡意行為者可以發送 HTTP 請求。這兩個 CVE 特別涉及 Solr 在任何程式碼路徑中都沒有使用的類別（分別為 SimpleXMLProvider 和 XmlRepresentation）。
CVE-2015-5237 6.5.0-至今 protobuf-java-3.1.0.jar 不受影響 Hadoop 和 Calcite 的依賴項。??
CVE-2018-1471 5.4.0-7.7.2, 8.0-8.3 simple-xml-2.7.1.jar 不受影響 Carrot2 的依賴項，並在編譯期間使用，而不是在執行期間使用（請參閱 SOLR-769）。這個 .jar 檔案已在 Solr 8.3 中被取代，並反向移植到 7.7.3（請參閱 SOLR-13779）。
CVE-2018-8088 4.x-至今 slf4j-api-1.7.24.jar, jcl-over-slf4j-1.7.24.jar, jul-to-slf4j-1.7.24.jar 不受影響 所報告的 CVE 影響了 org.slf4j.ext.EventData，但 Solr 中沒有使用它。
CVE-2018-1335 7.3.1-7.5.0 tika-core.1.17.jar 不受影響 Solr 沒有執行 tika-server，因此這不是問題。
CVE- 7.3.1-至今 tika-core.*.jar 不受影響 所有可能成為 Solr 漏洞的 Tika 問題，只有在透過 SolrCell 索引不受信任的檔案時才會被利用。這不建議在生產系統中使用，因此 Solr 不認為這些是針對 Solr 的有效 CVE。
CVE- 6.6.2-至今 velocity-tools-2.0.jar 不受影響 Solr 沒有附帶 Struts jar。這是一個傳遞性的 POM 清單，並未包含在 Solr 中（請參閱 SOLR-2849 中的註解）。
CVE-2016-6809, CVE-2018-1335, CVE-2018-1338, CVE-2018-1339 5.5.5, 6.2.0-至今 vorbis-java-tika-0.8.jar 不受影響 請參閱 https://github.com/Gagravarr/VorbisJava/issues/30；所報告的 CVE 與 OggVorbis 完全無關。
CVE-2012-0881 ~2.9-至今 xercesImpl-2.9.1.jar 不受影響 僅用於 Lucene 基準測試和 Solr 測試。
CVE-2023-51074, GHSA-pfh2-hfmq-phg5 所有版本 json-path-2.8.0.jar 不受影響 我們使用 json-path 的唯一地方是查詢（透過 Calcite）以及轉換/索引自訂 JSON。由於該公告描述的問題僅限於當前執行緒，且允許查詢/轉換/索引的使用者已經被信任到某種程度的負載，因此此公告似乎不會影響 json-path 在 Solr 中的使用方式。