Universal Forwarder 8.2.0 < 8.2.12、9.0.0 < 9.0.6、9.1.0 < 9.1.1 (SVD-2023-0809)
critical Nessus Plugin ID 194926
語系：
概要
遠端 Web 伺服器上執行的應用程式受到一個弱點影響說明
遠端主機上安裝的 Splunk 版本低於測試版本。因此，會受到 SVD-2023-0809 公告中提及的一個弱點影響。- Google Chrome 91.0.4472.164 更舊版本的 Blink XSLT 中存在釋放後使用問題，此弱點允許遠端攻擊者可能透過建構的 HTML 頁面，惡意引致堆積損毀。(CVE-2021-30560)
- 早於 v8.0.0 版的 libcurl 中存在驗證繞過弱點。儘管已修改 SSH 選項，但程式仍會重複使用先前建立的 SSH 連線，此連線本應被阻止重複使用。如果組態相符，libcurl 會維護先前使用的連線集區，以便在後續傳輸中重複使用這些連線。不過，組態檢查中忽略了兩個 SSH 設定，這使得它們可以輕鬆比對，進而可能導致重複使用不當連線。(CVE-2023-27538)
- libcurl 8.0.0 之前版本在不同的處理序之間共用 HSTS 資料時，會產生重複釋放弱點。
引入此共用功能時未考慮跨獨立執行緒的共用，但說明文件中並未指出此事實。由於缺少 mutex 或執行緒鎖定，共用相同 HSTS 資料的兩個執行緒可能會導致重複釋放或釋放後使用。(CVE-2023-27537)
- libcurl 8.0.0 之前版本的連線重複使用功能中存在驗證繞過弱點，因為無法檢查 CURLOPT_GSSAPI_DELEGATION 選項中的變更，所以可使用錯誤的使用者權限重複使用之前建立的連線。此弱點會影響 krb5/kerberos/negotiate/GSSAPI 傳輸，並可能導致使用者在未經授權的情況下存取敏感資訊。如果 CURLOPT_GSSAPI_DELEGATION 選項已變更，則最安全的選項是不重複使用連線。(CVE-2023-27536)
- libcurl 8.0.0 之前版本的 FTP 連線重複使用功能中存在驗證繞過弱點，可導致在後續傳輸期間使用錯誤的憑證。如果先前建立的連線符合目前的設定，則會保留在連線集區中供重複使用。但是，某些 FTP 設定 (如 CURLOPT_FTP_ACCOUNT、CURLOPT_FTP_ALTERNATIVE_TO_USER、CURLOPT_FTP_SSL_CCC 和 CURLOPT_USE_SSL) 並未包含在組態相符檢查中，從而導致它們太容易相符。這可引致 libcurl 在執行傳輸時使用錯誤的憑證，進而可能允許使用者在未經授權的情況下存取敏感資訊。(CVE-2023-27535)
- curl 8.0.0 之前版本的 SFTP 實作中存在路徑遊走弱點。波浪號 (~) 除了預定用作指示使用者主目錄之相對路徑的第一個元素外，在第一個路徑元素中作為前置詞使用時，會被錯誤地取代。攻擊者可利用此弱點繞過篩選，或在以特定使用者的身分存取伺服器時，透過僞造類似 /~2/foo 的路徑來執行任意程式碼。(CVE-2023-27534)
- 在使用 TELNET 通訊協定進行通訊期間，curl 8.0 之前版本存在輸入驗證弱點，攻擊者可在伺服器交涉期間傳遞惡意特製的使用者名稱和 telnet 選項。
由於缺少適當的輸入清除，攻擊者可在沒有應用程式意圖的情況下傳送內容或執行選項交涉。如果應用程式允許使用者輸入，攻擊者就可以利用此弱點，在系統上執行任意程式碼。(CVE-2023-27533)
- v7.88.0 之前版本的 curl 基於鏈結式 HTTP 壓縮演算法，存在資源配置無限制或無節流弱點，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數設有上限，但該上限是依標頭實作的，惡意伺服器可利用許多標頭來插入幾乎不受限制的壓縮步驟數。使用此類解壓縮鏈可導致 malloc 炸彈，進而使 curl 最終花費大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2023-23916)
- 早於 v7.88.0 的 curl 中存在敏感資訊純文字傳輸漏洞，當並行請求多個 URL 時，該漏洞可能導致 HSTS 功能行為不正確。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。然而，當並行完成多個傳輸時，此 HSTS 機制會意外失敗，因為 HSTS 快取檔案會被最近完成的傳輸覆寫。之後對舊版主機名稱的純 HTTP 傳輸*不會*正確升級至 HSTS。
(CVE-2023-23915)
- 早於 v7.88.0 的 curl 中存在敏感資訊純文字傳輸弱點，當連續請求多個 URL 時，該漏洞可能導致 HSTS 功能失敗。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。然而，在相同命令行上完成後，後續傳輸會意外忽略此 HSTS 機制，因為狀態將無法正確執行。 (CVE-2023-23914)
- 低於 7.87.0 版的 curl 中存在一個釋放後使用弱點。可以要求 Curl 透過 HTTP Proxy 為其支援的所有通訊協定*建立通道*。HTTP Proxy 可以 (而且經常) 拒絕此類通道作業。
當特定通訊協定 SMB 或 TELNET 被拒絕時，curl 會在其傳輸關閉程式碼路徑中使用堆積配置結構。(CVE-2022-43552)
- curl <7.87.0 HSTS 檢查中存在弱點，攻擊者可繞過檢查以誘騙其繼續使用 HTTP。
若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。但是，如果給定 URL 中的主機名稱首先使用 IDN 轉換過程中被取代為 ASCII 對應項的 IDN 字元，則可能繞過 HSTS 機制。如同使用 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 字元，而非一般的 ASCII 句號 (U+002E)「.」。然後在後續要求中，它不會偵測 HSTS 狀態並進行純文字傳輸。因為它會儲存以 IDN 編碼的資訊，但尋找以 IDN 解碼的資訊。(CVE-2022-43551)
- 在 curl 7.86.0 之前版本中，使用者可以繞過 HSTS 檢查以誘騙其繼續使用 HTTP。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 直接使用 HTTPS (而不使用不安全的純文字 HTTP 步驟)。如果指定 URL 中的主機名稱使用在 IDN 轉換過程中被 ASCII 對應項取代的 IDN 字元，則可繞過此機制，例如，使用字元 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP)，而非常見的 ASCII U+002E 的句號 (.)。
最早的受影響版本是 7.77.0 2021-05-26。(CVE-2022-42916)
- curl 7.86.0 之前版本存在重複釋放問題。如果要求 curl 使用 HTTP Proxy 進行包含非 HTTP(S) URL 的傳輸，它會透過向 Proxy 發出 CONNECT 要求來設定與遠端伺服器的連線，然後讓其餘通訊協定通過。HTTP Proxy 可能會拒絕此要求 (HTTP Proxy 通常只允許至特定連接埠號碼的傳出連線，例如 HTTPS 的 443)，而是將非 200 狀態碼傳回給用戶端。由於錯誤/清理處理中存在錯誤，如果在傳輸的 URL 中使用下列配置之一，這可在 curl 中觸發重複釋放：dict、gopher、gophersldap、ldaps、rtmp、rtmps 或 telnet。最早的受影響版本是 7.77.0。(CVE-2022-42915)
- 可指示 curl 剖析憑證的「.netrc」檔案。如果該檔案以包含 4095 個連續的非空白字母的行結尾且無新行，curl 會先讀取超出堆疊型緩衝區結尾的範圍，如果是 readworks，則寫入超出其邊界的零位元組。在大多數情況下，這會造成區段錯誤或類似問題，但也可能會造成不同的結果。如果惡意使用者可向應用程式提供自訂 netrc 檔案，或以其他方式影響其內容，則可利用此缺陷引致拒絕服務。(CVE-2022-35260)
- 進行 HTTP(S) 傳輸時，如果之前曾使用相同的控點發出使用讀取回呼 (「CURLOPT_READFUNCTION」) 的「PUT」要求，則 libcurl 可能會錯誤地使用此回呼來要求要傳送的資料，即使已經設定「CURLOPT_POSTFIELDS」選項亦如此。此缺陷可能會使應用程式意外產生錯誤行為，並在後續的「POST」要求中傳送錯誤資料或使用釋放後的記憶體，或發生類似情況。從 PUT 變更為 POST 時，重複使用的控點邏輯中存在此問題。(CVE-2022-32221)
- 使用 curl 從 HTTP(S) 伺服器擷取和剖析 cookie 時，它會接受使用控製程式碼的 cookie，稍後將這些 cookie 傳回 HTTP 伺服器時，可能會使伺服器傳回 400 回應。
有效地允許協助網站拒絕對所有同級網站的服務。(CVE-2022-35252)
- curl 7.84.0 之前版本在執行受 krb5 保護的 FTP 傳輸時，會錯誤處理訊息驗證失敗。
攻擊者可利用此缺陷執行攔截式攻擊而不被察覺，甚至可以向用戶端插入資料。(CVE-2022-32208)
- curl 7.84.0 之前版本將 cookie、alt-svc 和 hsts 資料儲存到本機檔案時，會透過將暫存名稱重新命名為最終目標檔案名稱來完成作業，從而使此作業成爲原子型作業。在此重新命名作業中，它可能會意外*放寬*針對目標檔案的權限，讓更多使用者可存取更新後的檔案。(CVE-2022-32207)
- curl 7.84.0 之前版本支援鏈結式 HTTP 壓縮演算法，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數不受限制，因此惡意伺服器可以插入幾乎不限數量的壓縮步驟。使用此類解壓縮鏈可導致 malloc 炸彈，使 curl 最終佔用大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2022-32206)
- 惡意伺服器可在 HTTP 回應中提供 curl 過量的 `Set-Cookie:` 標頭，而 curl 7.84.0 之前版本會儲存所有這些標頭。數量足夠多 (大) 的 Cookie 會向此伺服器或與這些 Cookie 相符的其他伺服器發出後續 HTTP 要求，從而使建立的要求超過 curl 爲避免傳送過大要求 (1048576 位元組) 而在內部使用的閾值，而沒有傳回錯誤。只要保留和符合這些 Cookie 並且它們未過期，此拒絕狀態就可能持續存在。由於 Cookie 比對規則，「foo.example.com」上的伺服器可設定與「bar.example.com」相符的 Cookie，從而使同級伺服器可以有效造成相同二級網域上使用此方法的同級網站拒絕服務。(CVE-2022-32205)
- 若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 直接使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。如果在指定的 URL 中，主機名稱使用了尾隨點，但在構建 HSTS 快取時未使用，則可繞過此機制。或者相反
- 在 HSTS 快取中使用了尾隨點，但在 URL 中*未*使用尾隨點。
(CVE-2022-30115)
- 即使已變更 TLS 或 SSH 相關選項，libcurl 仍會重複使用之前建立的連線，而這些連線本應禁止重複使用。若其中一個連線符合設定，libcurl 會將之前使用過的連線保留在連線集區中，以備後續傳送重複使用。但是，組態比對檢查會遺漏數個 TLS 和 SSH 設定，這使匹配變得非常容易。(CVE-2022-27782)
- libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
(CVE-2022-27781)
- 解碼 URL 的主機名稱部分時，curl URL 剖析器會錯誤地接受以百分號編碼的 URL 分隔符號 (如「/」)，從而使其在以後擷取時成為使用錯誤主機名稱的 *不同* URL。例如，剖析器會允許諸如 `http://example.com%2F127.0.0.1/` 的 URL 並將其轉置為 `http://example.com/127.0.0.1/`。攻擊者可利用此瑕疵規避篩選、檢查等。
(CVE-2022-27780)
- 如果主機名稱以一個點結尾，libcurl 會錯誤地允許為頂層網域 (TLD) 設定 cookie。可以指示 curl 接收和傳送 cookie。構建 curl 的 cookie 引擎時，可以使用 [公開後置詞清單]，也可以不使用 (https://publicsuffix.org/)awareness。如果未提供 PSL 支援，則需要基本檢查，以至少防止在 TLD 上設定 cookie。如果 URL 中的主機名稱以一個點結尾，此檢查會被中斷。這可造成任意網站皆可設定 cookie，然後傳送至不同且不相關的網站或網域。(CVE-2022-27779)
- --no-clobber 與 --remove-on-error 一起使用時，7.83.1 版中已修正的使用錯誤解析的名稱弱點可能會移除錯誤的檔案。(CVE-2022-27778)
- curl 7.83.0 中修正的憑證保護不足弱點可能會在 HTTP 重新導向至相同主機不同連接埠號碼時洩漏驗證或 Cookie 標頭資料。(CVE-2022-27776)
- curl 7.65.0 至 7.82.0 中存在資訊洩漏弱點，在使用連線集區中具有不同區域 ID 的 IPv6 位址時，它可能會改為重複使用連線。(CVE-2022-27775)
- curl 4.9 至 7.82.0 版 (含) 存在憑證保護不足弱點，允許攻擊者在遵循身份驗證中結合使用的 HTTP(S) 重新導向時擷取憑證，將憑證洩漏給不同通訊協定或連接埠號碼上的其他服務。
(CVE-2022-27774)
- curl 7.33.0 至 7.82.0 (含) 版本中有不當驗證弱點，可能允許在未正確確定已使用為此傳輸設定的相同憑證來驗證連線的情況下，重複使用 OAUTH2 驗證的代理伺服器連線。此弱點會影響已啟用 SASL 的通訊協定：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S) (僅限 openldap)。(CVE-2022-22576)
- 當 curl >= 7.20.0 和 <= 7.78.0 連線至 IMAP 或 POP3 伺服器以擷取使用 STARTTLS 升級至 TLS 安全性的資料時，伺服器可回應並一次傳回 curl 快取的多個回應。
然後，curl 會升級至 TLS，但不會排清已快取回應的佇列，而是繼續使用並信任其在 TLS 交握*之前*收到的回應，如同這些回應已經通過驗證一般。藉此缺陷，中間攻擊者可先插入假的回應，然後從合法伺服器傳遞 TLS 流量，並誘騙 curl 將資料傳送回給認為攻擊者插入的資料來自受 TLS 保護之伺服器的使用者。(CVE-2021-22947)
- 與 IMAP、POP3 或 FTP 伺服器交談時，使用者可告知 curl >= 7.20.0 和 <= 7.78.0 以要求成功升級至 TLS (命令列上的 `--ssl-reqd` 或設為 `CURLUSESSL_CONTROL` 的 `CURLOPT_USE_SSL` 或 `CURLUSESSL_ALL` withlibcurl)。如果伺服器會傳回特製但完全合法的回應，則可繞過此要求。此缺陷會導致 curl 以無訊息模式繼續其作業
**沒有 TLS** 與指示和預期相反，可能透過網路以純文字洩漏敏感資料。(CVE-2021-22946)
- 將資料傳送至 MQTT 伺服器時，libcurl <= 7.73.0 和 7.78.0 版在某些情況下可將指標錯誤地保留至已釋放的記憶體區域，並在後續呼叫中再次使用該指標來傳送資料，然後*再次*釋放。(CVE-2021-22945)
- libcurl-using 應用程式可要求在傳輸中使用特定用戶端憑證。這是透過 `CURLOPT_SSLCERT` 選項 (`--cert` 與命令行工具) 達成。將 libcurl 建構為使用 macOS 原生 TLS 程式庫 Secure Transport 時，應用程式可使用相同選項依名稱或檔案名稱要求用戶端憑證。如果名稱以檔案形式存在，則將使用該檔案而非依名稱。如果應用程式目前執行的運作中目錄可由其他使用者寫入 (像是 `/tmp`)，惡意使用者便可建立與應用程式想要使用的名稱同名的檔案名稱，因此誘騙應用程式使用檔案型憑證，而非名稱參照的憑證，進而使 libcurl 在 TLS 連線交握中傳送錯誤的用戶端憑證。(CVE-2021-22926)
- curl 支援 `-t` 命令列選項，在 libcurl 中稱為 `CURLOPT_TELNETOPTIONS`。此很少使用的選項用於傳送 variable=content 對至 TELNET 伺服器。由於傳送 `NEW_ENV` 變數的選項剖析器存在缺陷，libcurl 可將未初始化的資料從堆疊型緩衝區傳送至伺服器。因此，這可能會將敏感的內部資訊洩漏給使用純文字網路通訊協定的伺服器，這是因為在剖析應用程式提供的字串時，curl 未正確呼叫和使用 sscanf()。(CVE-2021-22925)
- libcurl 會將先前使用的連線保留在連線集區中，以便在後續傳輸時重複使用其中符合設定的某個連線。由於邏輯中的錯誤，組態比對函式未將「issuercert」納入考量，因此會比較所涉及的路徑*案例不敏感地*，這可導致 libcurl 重複使用錯誤的連線。檔案路徑在許多系統上可能是或可能是區分大小寫的，但並非全部都區分大小寫，而且可能會根據所使用的檔案系統而有所不同。比較也未包含「issuer cert」其中，傳輸可設定為符合驗證伺服器憑證的方式。(CVE-2021-22924)
- 當指示 curl 使用 metalink 功能取得內容，並使用使用者名稱和密碼下載 metalink XML 檔案時，這些相同的憑證隨後會傳送至 curl 將從中下載或嘗試下載內容的每一個伺服器。通常與使用者的預期和意圖相反，而且不告訴使用者。(CVE-2021-22923)
- 指示 curl 使用 metalink 功能下載內容時，系統會根據 metalink XML 檔案中提供的雜湊驗證內容。metalink XML 檔案會向用戶端指出如何從一組不同的 URL (可能由不同的伺服器主控) 中取得相同的內容，然後用戶端可以從其中一個或多個 URL 下載檔案。以序列或平行方式。如果主控內容的其中一個伺服器遭到入侵，且該伺服器上的特定檔案內容已為修改後的內容取代，則在完成下載後，當檔案的雜湊不符時，curl 應該會偵測到此問題。
它應該移除內容，並嘗試從另一個 URL 取得內容。應用程式並未這樣做，而是僅在文字中提及此類雜湊不符，並且可能將惡意內容保留在磁碟上的檔案中。(CVE-2021-22922)
- curl 7.75.0 到 7.76.1 受到一個釋放後使用弱點影響，會導致在 TLS 1.3 工作階段票證透過連線抵達時使用已釋放的記憶體。惡意伺服器可在極少數不幸的情況下利用此弱點，進而可能在用戶端中造成遠端程式碼執行。當 libcurl 在運行時針對使用 OpenSSL 的連線設定支援 TLS 1.3 工作階段票證時，它會儲存指向傳輸記憶體中物件的指標，以便稍後在工作階段票證到達時擷取。如果有多個傳輸使用此連線 (例如使用重複使用的 HTTP/1.1 連線或多工 HTTP/2 連線)，則在該連線上建立新工作階段之前，可能會釋放第一個傳輸物件，然後該函式將存取可能被釋放的記憶體緩衝區。使用該記憶體時，libcurl 甚至可能會呼叫物件中的函式指標，如果伺服器可以以某種方式設法將特製的記憶體內容放入記憶體中的正確位置，則可能執行遠端程式碼。(CVE-2021-22901)
- 當使用 `-t` 命令列選項 (在 libcurl 中稱為`CURLOPT_TELNETOPTIONS`) 傳送 variable=content 配對至 TELNET 伺服器時，curl 7.7 到 7.76.1 會受到資訊洩漏問題的影響。由於傳送 NEW_ENV 變數的選項剖析器中有一個缺陷，libcurl 可能會被用來將未初始化的資料從堆疊型緩衝區傳遞至伺服器，進而可能導致使用純文字網路通訊協定向伺服器洩漏敏感的內部資訊。(CVE-2021-22898)
- 將 libcurl 構建為使用 Schannel TLS 程式庫時，由於 CURLOPT_SSL_CIPHER_LIST 的程式碼中有錯誤，curl 7.61.0 到 7.76.1 版會受到資料元素洩漏問題影響。所選的密碼集已儲存在程式庫中的單一靜態變數中，這會產生令人意外的副作用：如果應用程式設定了多個並行傳輸，則最後一個設定密碼的傳輸將意外控制所有傳輸使用的密碼集。在最壞的情況下，這會顯著削弱傳輸安全性。(CVE-2021-22897)
- curl 7.63.0 至 7.75.0 (含) 版本中存在弱點，由於應用程式不當處理 TLS 1.3 工作階段票證，惡意 HTTPS 代理伺服器可利用此弱點對連線執行 MITM 攻擊。使用 HTTPS 代理伺服器和 TLS 1.3 時，libcurl 可能會混淆來自 HTTPS 代理伺服器的工作階段票證， 而會將其當作來自遠端伺服器一樣運作，然後錯誤地縮短主機交握。當混淆票證時，HTTPS 代理伺服器可誘騙 libcurl 使用錯誤的主機工作階段票證，從而規避伺服器 TLS 憑證檢查，並使攻擊者可能在不被察覺的情況下執行 MITM 攻擊。請注意，此類惡意 HTTPS 代理伺服器需要爲充當 MITM 的伺服器提供 curl 可接受的憑證，才能發動攻擊，除非已告知 curl 忽略伺服器憑證檢查。(CVE-2021-22890)
- curl 7.1.1 至 7.75.0 版本 (含) 容易發生因在 HTTP Referer: 標頭中洩漏憑證而導致私人個人資訊洩漏給未經授權的執行者的問題。當自動填入傳出 HTTP 要求中的 Referer: HTTP 要求標頭欄位時，libcurl 不會從 URL 中去除使用者憑證，因此會有將敏感資料洩漏給第二個 HTTP 要求的目標伺服器的風險。(CVE-2021-22876)
- curl 7.41.0 至 7.73.0 容易受到不當檢查憑證撤銷弱點的影響，這是因為未充分驗證 OCSP 回應所致。(CVE-2020-8286)
- curl 7.21.0 至 7.73.0 (含) 容易受到不受控制的遞回弱點影響，這是因為 FTP 萬用字元配對剖析中存在堆疊溢位問題所致。(CVE-2020-8285)
- 惡意伺服器可利用 FTP PASV 回應誘騙 curl 7.73.0 和更早版本連回指定的 IP 位址和連接埠，這樣有可能會讓 curl 擷取本應為私人且未洩漏之服務的相關資訊，例如執行連接埠掃描和服務標題擷取。
(CVE-2020-8284)
- 由於使用了懸置指標，libcurl 7.29.0 至 7.71.1 版本會在傳送資料時使用錯誤的連線。(CVE-2020-8231)
- curl 7.20.0 至 7.70.0 版容易受到檔案和其他資源的不當名稱限制影響，而在使用 -J 旗標時可能導致過度覆寫本機檔案。(CVE-2020-8177)
- curl 7.62.0 至 7.70.0 版本 (含) 容易受到資訊洩漏弱點的影響，此弱點可導致部分密碼透過網路和 DNS 伺服器洩漏。(CVE-2020-8169)
- 在 3.6.2 版之前的 libarchive 中，軟體在呼叫 calloc 函式後不會檢查是否有錯誤，該函式會在函式失敗時傳回 NULL 指標，進而導致 NULL 指標解除參照。
注意：發現者引用了此 CWE-476 評論，但第三方對程式碼執行的影響存在爭議：在極少數情況下，當 NULL 等同於 0x0 記憶體位址且有權限的程式碼可以存取它時，就可以寫入或讀取記憶體，這可能會導致程式碼執行。(CVE-2022-36227)
- 解壓縮封存時會發生不當連結解析，從而引致封存外檔案的模式、時間、存取控制清單和旗標發生變更。攻擊者可向受害使用者提供惡意封存，當使用者嘗試擷取封存時觸發此缺陷。本機攻擊者可利用此缺陷在系統中取得更多權限。(CVE-2021-31566)
- libarchive 3.4.1 版至 3.5.1 版的 copy_string (從 do_uncompress_block 和 process_block 呼叫) 中有一個釋放後使用問題。(CVE-2021-36976)
- lz4 中有一個缺陷。攻擊者若將特製檔案提交至與 lz4 連結的應用程式，則可能會觸發整數溢位問題，導致對負大小引數呼叫 memmove()，進而造成超出邊界寫入和/或損毀。此缺陷對可用性影響最大，對機密性和完整性也可能有一定影響。(CVE-2021-3520)
- 在 8.44 之前的 PCRE 中，libpcre 允許透過 (?C 子字串之後的大數字造成整數溢位。
(CVE-2020-14155)
- 當模式 \X 經過 JIT 編譯，並用於比對非 UTF 模式的特別建構主旨時，在 10.34 之前的 PCRE 中發現一個超出邊界讀取問題。使用 PCRE 剖析非受信任輸入的應用程式可能容易發生此瑕疵，攻擊者可利用此瑕疵造成應用程式損毀。此瑕疵發生在 pcre2_jit_compile.c 的 do_extuni_no_utf 中。(CVE-2019-20454)
- 當停用 UTF，且 \X 或 \R 有多個固定的量詞時，8.43 版之前的 PCRE 中的 libpcre 允許在 JIT 中存在主體緩衝區過度讀取，此問題與 CVE-2019-20454 相關。(CVE-2019-20838)
- 如果在 C API 的字串引數中使用數十億個位元組，則 SQLite 1.0.12 版至 3.39.x 的 3.39.2 之前版本有時會發生陣列邊界溢位。(CVE-2022-35737)
請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
建議 Splunk Universal Forwarder 客戶升級至 8.2.12、9.0.6 或 9.1.1 版。另請參閱
Plugin 詳細資訊
嚴重性: Critical
ID: 194926
檔案名稱: splunk_911_svd-2023-0809.nasl
版本: 1.2
類型: combined
代理程式: windows, macosx, unix
系列: CGI abuses
已發布: 2024/5/2
已更新: 2024/5/30
支援的感應器: Nessus Agent, Nessus
風險資訊
VPR
風險因素: Medium
分數: 6.7
CVSS v2
風險因素: High
基本分數: 7.5
時間分數: 5.9
媒介: CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P
CVSS 評分資料來源: CVE-2022-32207
CVSS v3
風險因素: Critical
基本分數: 9.8
時間分數: 8.8
媒介: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
時間媒介: CVSS:3.0/E:P/RL:O/RC:C
CVSS 評分資料來源: CVE-2022-36227
弱點資訊
CPE: cpe:/a:splunk:universal_forwarder, cpe:/a:splunk:splunk
可被惡意程式利用: true
可輕鬆利用: Exploits are available
修補程式發佈日期: 2023/8/30
弱點發布日期: 2023/8/30
參考資訊
CVE: CVE-2019-20454, CVE-2019-20838, CVE-2020-14155, CVE-2020-8169, CVE-2020-8177, CVE-2020-8231, CVE-2020-8284, CVE-2020-8285, CVE-2020-8286, CVE-2021-22876, CVE-2021-22890, CVE-2021-22897, CVE-2021-22898, CVE-2021-22901, CVE-2021-22922, CVE-2021-22923, CVE-2021-22924, CVE-2021-22925, CVE-2021-22926, CVE-2021-22945, CVE-2021-22946, CVE-2021-22947, CVE-2021-30560, CVE-2021-31566, CVE-2021-3520, CVE-2021-36976, CVE-2022-22576, CVE-2022-27774, CVE-2022-27775, CVE-2022-27776, CVE-2022-27778, CVE-2022-27779, CVE-2022-27780, CVE-2022-27781, CVE-2022-27782, CVE-2022-30115, CVE-2022-32205, CVE-2022-32206, CVE-2022-32207, CVE-2022-32208, CVE-2022-32221, CVE-2022-35252, CVE-2022-35260, CVE-2022-35737, CVE-2022-36227, CVE-2022-42915, CVE-2022-42916, CVE-2022-43551, CVE-2022-43552, CVE-2023-23914, CVE-2023-23915, CVE-2023-23916, CVE-2023-27533, CVE-2023-27534, CVE-2023-27535, CVE-2023-27536, CVE-2023-27537, CVE-2023-27538