Splunk Enterprise 9.0.0 < 9.0.9、9.1.0 < 9.1.4、9.2.0 < 9.2.1 (SVD-2024-0718)
critical Nessus Plugin ID 201209
語系：
概要
遠端 Web 伺服器上執行的應用程式受到一個弱點影響說明
遠端主機上安裝的 Splunk 版本低於測試版本。因此，它會受到 SVD-2024-0718 公告中提及的一個弱點影響。- 在 jackson-databind 2.15.2 及其之前所有版本中發現一個問題，攻擊者可以透過使用循環相依性的特製物件，造成拒絕服務或其他不明影響。注意：廠商認為這不是有效的弱點報告，因為外部攻擊者無法完成建構循環資料結構並嘗試將其序列化的步驟。(CVE-2023-35116)
- 在 2.7 版之前的 Apache Commons IO 中，當使用不適當的輸入字符串 (如 //../foo 或 \\..\foo) 叫用方法 FileNameUtils.normalize 時，得到的結果將是同一值；因此，如果交用程式碼是使用該結果來建構路徑值，則系統可能提供對父目錄中檔案的存取權限，但無法進一步存取其他內容 (因而路徑遍歷會遭到限制)。(CVE-2021-29425)
- snappy-java 是 snappy 的 Java 連接埠，是 Google 開發的快速 C++ 壓縮程式/解壓縮程式。據發現，在解壓縮具有過大區塊的資料時，SnappyInputStream 容易遭受拒絕服務 (DoS) 攻擊。由於缺少區塊長度的上限檢查，可能會發生無法復原的嚴重錯誤。所有 snappy-java 版本 (包括最新發布的 1.1.10.3 版本) 皆容易受此問題影響。認可「9f8c3cf74」中引入了一個修正，包含在 1.1.10.4 版本中。建議所有使用者進行升級。無法升級的使用者應只接受來自受信任來源的壓縮資料。(CVE-2023-43642)
- snappy-java 是適用於 Java 的快速壓縮/解壓縮程式。由於未經檢查的乘法，1.1.10.1 之前版本中可能會發生整數溢位，進而造成嚴重錯誤。「BitShille.java」檔案中的「shuffle(int[] input)」函式會接收整數陣列，並對其套用位元打亂。方法是，將長度乘以 4，然後將其傳遞至原生編譯的亂數函式。由於未測試長度，因此乘以四可造成整數溢位，並且值小於實際大小，甚至是零或負值。若為負值，則會引發「java.lang.NegativeArraySizeException」例外狀況，進而造成程式損毀。如果值為零或太小，之後參照已打亂陣列的程式碼會假設陣列的大小過大，這可能會造成「java.lang.ArrayIndexOutOfBoundsException」等例外狀況。
使用接收雙精度型、浮點型、長整型和短整型數的「亂數」函式時也存在相同問題，每個函式使用可能會造成相同問題的不同乘數。1.1.10.1 版包含此弱點的修補程式。(CVE-2023-34453)
- snappy-java 是適用於 Java 的快速壓縮/解壓縮程式。由於未經檢查的乘法，1.1.10.1 之前版本中可能會發生整數溢位，進而造成無法復原的嚴重錯誤。「Snappy.java」檔案中的「compress(char[] input)」函式會接收字元陣列並加以壓縮。方法是，將長度乘以 2，然後將其傳遞至 rawCompress` 函式。由於未測試長度，因此乘以 2 可造成整數溢位，並且值變成負值。然後，rawCompress 函式會使用收到的長度，並將其傳遞至原生編譯的 maxCompressedLength 函式，然後使用傳回的值來配置位元組陣列。由於 maxCompressedLength 函式將長度視為無正負號的整數，因此並不在意其是否為負值，它會傳回一個有效值，然後由 Java 引擎將其轉換為有正負號的整數。如果結果是負值，則嘗試配置陣列 `buf` 時，會引發 `java.lang.NegativeArraySizeException` 例外狀況。
另一方面，如果結果為正，則會成功配置 `buf` 陣列，但其大小值可能太小而無法用於壓縮，進而造成嚴重的存取違規錯誤。使用接收雙精度型、浮點型、整型、長整型和短整型數的「compress」函式時也存在相同問題，每個函式使用可能會造成相同問題的不同乘數。使用位元組陣列時，此問題很可能不會發生，因為原本不可能建立大小為 0x80000000 (或任何其他負值) 的位元組陣列。1.1.10.1 版包含針對此問題的修補程式。(CVE-2023-34454)
- snappy-java 是適用於 Java 的快速壓縮/解壓縮程式。由於使用未檢查的區塊長度，1.1.10.1 之前版本中會發生無法復原的嚴重錯誤。fileSnappyInputStream.java 中的 hasNextChunk 函式程式碼會檢查指定資料流是否有更多區塊要讀取。它會嘗試讀取 4 個位元組。如果無法讀取 4 個位元組，函式會傳回 false。
如果有 4 個位元組可用，程式碼會將其視為下一個區塊的長度。在 `compressed` 變數為 null 的情況下，會使用輸入資料指定的大小配置位元組陣列。
由於程式碼未測試「chunkSize」變數的合法性，因此可以傳遞負數 (例如為 -1 的 0xFFFFFFFF)，這將導致程式碼引發「java.lang.NegativeArraySizeException」例外狀況。傳遞極大的正值 (例如 0x7FFFFFFF) 時會發生更糟的情況，會引發嚴重的 `java.lang.OutOfMemoryError` 錯誤。1.1.10.1 版包含針對此問題的修補程式。(CVE-2023-34455)
- 在還原序列化不受信任的或損毀的資料時，讀取器消耗的記憶體可能超出允許的限制，因而導致系統記憶體不足。此問題會影響使用 Apache Avro Java SDK 及之前版本的 Java 應用程式，包括 1.11.2。使用者應更新至 apache-avro 1.11.3 版，便可解決此問題。(CVE-2023-39410)
- Apache Calcite Avatica JDBC 驅動程式會根據透過 `httpclient_impl` 連線屬性提供的類別名稱，建立 HTTP 用戶端執行個體；不過，驅動程式在具現化之前不會驗證該類別是否實作預期的介面，這可導致透過任意類別載入程式碼執行，以及在極少數情況下觸發遠端程式碼執行。如要利用此弱點：1) 攻擊者需要具有控制 JDBC 連線參數的權限；2) 且類別路徑中應有有弱點的類別 (具有 URL 參數且能夠執行程式碼的建構函式)。從 Apache Calcite Avatica 1.22.0 開始，在叫用建構函式之前，程式會驗證該類別是否實作了預期的介面。(CVE-2022-36364)
- 所有 Guava 版本中都存在暫存目錄建立弱點，具有電腦存取權的攻擊者可能會藉此存取由 Guava API com.google.common.io.Files.createTempDir() 建立的暫存目錄中的資料。根據預設，在類似 unix 的系統中，所建立的目錄任何人皆可讀取 (可由擁有系統存取權的攻擊者讀取)。此有問題的方法已在 30.0 版和更新版本中標記為 @Deprecated，且不應再使用。對於 Android 開發人員，我們建議選擇 Android 提供的暫存目錄 API，例如 context.getCacheDir()。對於其他 Java 開發人員，我們建議移轉至明確設定 700 權限的 Java 7 API java.nio.file.Files.createTempDirectory()，或將 Java Runtime 的 java.io.tmpdir 系統屬性設定為指向已適當設定權限的位置。(CVE-2020-8908)
- 在 Unix 系統和 Android Ice Cream Sandwich 系統中，Google Guava 1.0 至 31.1 版的 `FileBackedOutputStream` 中使用 Java 的預設暫存目錄建立檔案，這讓電腦上能夠存取預設 Java 暫存目錄的其他使用者和應用程式能夠存取該類別建立的檔案。儘管此安全性弱點已在 32.0.0 版中修正，我們仍建議使用 32.0.1 版，因為 32.0.0 版會中斷 Windows 中的某些功能。(CVE-2023-2976)
- Google Guava 11.0 版至 24.1.1 之前的 24.x 版 (含) 中包含無邊界的記憶體配置弱點，這使得遠端攻擊者可以對依賴此程式庫的伺服器發動拒絕服務攻擊，並還原序列化攻擊者提供的資料，原因是 AtomicDoubleArray 類別 (使用 Java 序列化進行序列化時) 和 CompoundOrdering 類別 (使用 GWT 序列化進行序列化時) 執行 eager 配置，但未對用戶端已傳送的內容及資料大小是否合理進行適當檢查。(CVE-2018-10237)
- aiohttp 是適用於 asyncio 和 Python 的非同步 HTTP 用戶端/伺服器架構。aiohttp v3.8.4 及其更早版本隨 llhttp v6.0.6 一起搭售。aiohttp 會在可用時針對其 HTTP 要求剖析器使用有弱點的程式碼，這是從 wheel 安裝時的預設情況。此弱點只會影響使用 aiohttp 作為 HTTP 伺服器 (即「aiohttp.Application」) 的使用者，如果您使用 aiohttp 作為 HTTP 用戶端程式庫 (即「aiohttp.ClientSession」)，則不會受到此弱點影響。傳送特製的 HTTP 要求會造成伺服器錯誤解譯其中一個 HTTP 標頭值，進而導致 HTTP 要求走私。
此問題已在 3.8.5 版中解決。建議所有使用者進行升級。無法升級的使用者可使用 `AIOHTTP_NO_EXTENSIONS=1` 作為環境變數重新安裝 aiohttp，以停用 llhttp HTTP 要求剖析器實作。純 Python 實作不會受到影響。(CVE-2023-37276)
- aiohttp 是適用於 asyncio 和 Python 的非同步 HTTP 用戶端/伺服器架構。AIOHTTP 中的 HTTP 剖析器有數個標頭剖析問題，這些問題可導致要求走私。此剖析器只會在啟用 AIOHTTP_NO_EXTENSIONS 時或未使用預先構建的 wheel 時使用。這些問題已在發行版本 3.8.6 中包含的認可「d5c12ba89」中解決。建議所有使用者進行升級。目前沒有任何因應措施可解決這些問題。(CVE-2023-47627)
- urllib3 是適用於 Python 的人性化 HTTP 用戶端程式庫。urllib3 並未特殊處理 `Cookie` HTTP 標頭，或提供任何協助程式來管理 HTTP 上的 Cookie，這是使用者的責任。
但是，如果使用者未明確停用重新導向，該使用者或可指定 `Cookie` 標頭，並透過 HTTP 重新導向至不同來源，進而在不知情的情況下泄漏資訊。此問題已在 urllib3 1.26.17 版或 2.0.5 版中修正。(CVE-2023-43804)
- urllib3 是適用於 Python 的人性化 HTTP 用戶端程式庫。先前，當要求方法根據 HTTP RFC 的要求，從可接受要求內文 (如「POST」) 變更為「GET」時，urllib3 便不會在 HTTP 重新導向回應使用狀態 301、302 或 303 時移除 HTTP 要求內文。
雖然此行為並未在重新導向區段中指定，但可藉由拼湊來自不同區段的資訊來推斷出，而且我們已在 curl 和網頁瀏覽器等其他主要 HTTP 用戶端實作中觀察到此行為。由於此弱點需要先前受信任的服務遭到入侵，才能對機密性造成影響，因此我們認為此弱點的可利用性較低。此外，許多使用者並未在 HTTP 要求內文中放置敏感資料，如果是這種情況，則此弱點不會遭到惡意利用。必須滿足以下兩個條件才會受到此弱點影響：1. 使用 urllib3 並提交 HTTP 要求內文中的敏感資訊 (例如表單資料或 JSON)，以及 2. 原始服務會遭到入侵，並會開始使用 301、302 或 303 重新導向至惡意對等端，或是出現重新導向至的服務遭到入侵的情況。
此問題已在 1.26.18 和 2.0.7 版中解決，建議使用者更新以解決此問題。無法更新的使用者應使用 `redirects=False` 停用未預期以重新導向回應的服務重新導向，並使用 `redirects=False` 停用自動重新導向，亦可透過去除 HTTP 要求內文來手動處理 301、302 和 303 重新導向。(CVE-2023-45803)
- Certifi 是精選的 Root 憑證集合，用於在驗證 TLS 主機身分的同時驗證 SSL 憑證的可靠性。2023.07.22 版之前的 Certifi 可辨識 e-Tugra root 憑證。e-Tugra 的 Root 憑證須接受系統報告安全性問題時提示的調查。Certifi 2023.07.22 從 Root 存放區移除了 e-Tugra 中的 Root 憑證。(CVE-2023-37920)
- 從 Mercurial VCS URL (即 pip install hg+...) 安裝具有 v23.3 之前 pip 的套件時，指定的 Mercurial 修訂版可用來將任意組態選項插入 hg clone 呼叫 (即 --config)。 控制 Mercurial 組態可修改安裝存放庫的方式和安裝位置。此弱點不會影響未從 Mercurial 進行安裝的使用者。(CVE-2023-5752)
- Python Packaging Authority (PyPA) setuptools 65.5.1 之前版本允許遠端攻擊者透過特製套件或自訂 PackageIndex 頁面中的 HTML 造成系統拒絕服務。package_index.py 中存在規則運算式拒絕服務 (ReDoS) 弱點。(CVE-2022-40897)
- 在 pygments 2.15.0 及其之前版本中，發現 pygments/lexers/smithy.py 的 SmithyLexer 中存在 ReDoS 問題。
(CVE-2022-40896)
- 在 Python Packaging Authority (PyPA) Wheel 0.37.1 和更舊版本中發現一個問題，遠端攻擊者可以透過由攻擊者控制的 wheel cli 輸入造成系統拒絕服務。(CVE-2022-40898)
- Requests 是一個 HTTP 程式庫。自 Requests 2.3.0 起，Requests 重新導向至 HTTPS 端點時會向目的地伺服器洩漏 Proxy-Authorization 標頭。這是我們使用 `rebuild_proxies` 將 `Proxy-Authorization` 標頭重新附加到要求的結果。對於透過通道傳送的 HTTP 連線，Proxy 會識別要求本身中的標頭，並在轉送至目的地伺服器之前將其移除。但在透過 HTTPS 傳送時，因為 Proxy 無法檢視通道要求，因而必須在 CONNECT 要求中傳送「Proxy-Authorization」標頭。這會導致 Requests 意外將 Proxy 憑證轉送至目的地伺服器，進而允許惡意執行者洩漏敏感資訊。此問題已在 2.31.0 版中修正。
(CVE-2023-32681)
- 在 Python Charmers Future 0.18.2 和更舊版本中發現一個問題，遠端攻擊者可透過來自惡意 Web 伺服器的特製 Set-Cookie 標頭造成程式拒絕服務。(CVE-2022-40899)
- python-idna：透過對 idna.encode() 的特製輸入進行資源消耗，進而引發潛在的 DoS (CVE-2024-3651)
請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
升級至 Splunk Enterprise 9.2.1、9.1.4、9.0.9 或更新版本。另請參閱
Plugin 詳細資訊
嚴重性: Critical
ID: 201209
檔案名稱: splunk_921_svd-2024-0718.nasl
版本: 1.3
類型: combined
代理程式: windows, macosx, unix
系列: CGI abuses
已發布: 2024/7/1
已更新: 2024/7/2
支援的感應器: Nessus Agent, Nessus
風險資訊
VPR
風險因素: Medium
分數: 6.0
CVSS v2
風險因素: Medium
基本分數: 5.8
時間分數: 5
媒介: CVSS2#AV:N/AC:M/Au:N/C:P/I:P/A:N
CVSS 評分資料來源: CVE-2021-29425
CVSS v3
風險因素: Critical
基本分數: 9.8
時間分數: 9.4
媒介: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:H/RL:O/RC:C
CVSS 評分資料來源: CVE-2023-37920
弱點資訊
CPE: cpe:/a:splunk:splunk
必要的 KB 項目: installed_sw/Splunk
可被惡意程式利用: true
可輕鬆利用: Exploits are available
修補程式發佈日期: 2024/7/1
弱點發布日期: 2018/4/25
參考資訊
CVE: CVE-2018-10237, CVE-2020-8908, CVE-2021-29425, CVE-2022-36364, CVE-2022-40896, CVE-2022-40897, CVE-2022-40898, CVE-2022-40899, CVE-2023-2976, CVE-2023-32681, CVE-2023-34453, CVE-2023-34454, CVE-2023-34455, CVE-2023-35116, CVE-2023-37276, CVE-2023-37920, CVE-2023-39410, CVE-2023-43642, CVE-2023-43804, CVE-2023-45803, CVE-2023-47627, CVE-2023-5752, CVE-2024-3651