Splunk Enterprise < 8.1.14、8.2.0 < 8.2.11、9.0.0 < 9.0.5 (SVD-2023-0613)
critical Nessus Plugin ID 194919
語系：
概要
遠端 Web 伺服器上執行的應用程式受到一個弱點影響說明
遠端主機上安裝的 Splunk 版本低於測試版本。因此，會受到 SVD-2023-0613 公告中提及的一個弱點影響。- 在 2.10.3 之前的 libxml2 中發現一個問題。在啟用 XML_PARSE_HUGE 剖析器選項的情況下剖析數個 GB 的 XML 文件時，數個整數計數器可能溢位。這會導致程式嘗試以負的 2GB 位移存取陣列，這通常會導致區段錯誤。(CVE-2022-40303)
- 在 2.10.3 之前的 libxml2 中發現一個問題。某些無效的 XML 實體定義可損毀雜湊表金鑰，這可能導致後續發生邏輯錯誤。在一種情況下，可能會引發雙重釋放。(CVE-2022-40304)
- X.509 GeneralName 中有一個與 X.400 位址處理相關的類型混淆弱點。
X.400 位址被剖析為 ASN1_STRING，但 GENERAL_NAME 的公開結構定義錯誤地將 x400Address 欄位的類型指定為 ASN1_TYPE。此欄位隨後會被 OpenSSL 函式 GENERAL_NAME_cmp 解譯為 ASN1_TYPE，而非 ASN1_STRING。啟用 CRL 檢查時 (即應用程式設定 X509_V_FLAG_CRL_CHECK 旗標)，此弱點可能允許攻擊者向 memcmp 呼叫傳遞任意指標，使其能夠讀取記憶體內容或發動拒絕服務攻擊。在大多數情況下，攻擊者需要同時提供憑證鍊和 CRL，兩者都不需要有效的簽章。如果攻擊者只控制其中一個輸入，則另一個輸入必須已包含 X.400 位址作為 CRL 發佈點，此情況並不常見。因此，此弱點最有可能只影響已實作透過網路擷取 CRL 這一功能的應用程式。(CVE-2023-0286)
- 公開 API 函式 BIO_new_NDEF 是用於透過 BIO 串流 ASN.1 資料的協助程式函式。此函式主要用於 OpenSSL 內部，以支援 SMIME、CMS 和 PKCS7 串流功能，但也可能由終端使用者應用程式直接呼叫。此函式會接收來自呼叫者的 BIO，並在前面附加新的 BIO_f_asn1 篩選器 BIO 以形成 BIO 鏈結，然後將 BIO 鏈結的新標頭傳回給呼叫者。在某些情況下，例如，如果 CMS 收件人公開金鑰無效，則新篩選器 BIO 會被釋放，並且該函式會傳回 NULL 結果，表明失敗。但在此情況下，BIO 鏈結未經正確清理，且呼叫者傳送的 BIO 仍保留先前釋放的篩選器 BIO 的內部指標。如果呼叫者接著呼叫 BIO 上的 BIO_pop()，則會發生釋放後使用。這很可能會導致當機。此情況直接發生在內部函式 B64_write_ASN1() 中，其可能導致呼叫 BIO_new_NDEF()，並隨後在 BIO 上呼叫 BIO_pop()。此內部函式會接著由公開 API 函式 PEM_write_bio_ASN1_stream、PEM_write_bio_CMS_stream、PEM_write_bio_PKCS7_stream、SMIME_write_ASN1、SMIME_write_CMS 和 SMIME_write_PKCS7 呼叫。其他可能受到此弱點影響的公開 API 函式包括 i2d_ASN1_bio_stream、BIO_new_CMS、BIO_new_PKCS7、i2d_CMS_bio_stream 和 i2d_PKCS7_bio_stream。OpenSSL cms 和 smime 命令行應用程式受到類似影響。(CVE-2023-0215)
- OpenSSL RSA Decryption 實作中存在計時型旁路，其足可在 Bleichenbacher 式攻擊中跨網路復原純文字。若要成功解密，攻擊者必須能夠傳送大量的試用訊息以進行解密。
此弱點會影響所有 RSA 填補模式：PKCS#1 v1.5、RSA-OEAP 和 RSASVE。例如，在 TLS 連線中，用戶端通常會使用 RSA 將加密的 pre-master 密碼傳送至伺服器。攻擊者若觀察到用戶端與伺服器之間存在真正連線，就可以利用此缺陷將試用訊息傳送至伺服器，並記錄處理這些訊息所用的時間。攻擊者獲得充足的訊息之後，便可復原用於最初連線的 pre-master 密碼，進而能夠解密透過該連線傳送的應用程式資料。(CVE-2022-4304)
- 早於 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)
- 如果在 C API 的字串引數中使用數十億個位元組，則 SQLite 1.0.12 版至 3.39.x 的 3.39.2 之前版本有時會發生陣列邊界溢位。(CVE-2022-35737)
- 如果輸入包含許多遠端比對，zlib 1.2.12 更舊版本會在壓縮時允許造成記憶體損毀。(CVE-2018-25032)
- 在 zlib 1.2.12 及其之前版本中，透過額外的大型 gzip 標頭欄位，可在 inflate.c 的 inflate 造成堆積型緩衝區過度讀取或緩衝區溢位。注意：只有呼叫 inflateGetHeader 的應用程式會受到影響。部分常見應用程式隨附受影響的 zlib 原始程式碼，但可能無法呼叫 inflateGetHeader (例如，請參閱 nodejs/node 參考資料)。(CVE-2022-37434)
- Prism 容易受到跨網站指令碼弱點的影響。Previewers Plugin 的緩動預覽中包含 XSS 弱點，使得攻擊者可以在 Safari 和 Internet Explorer 中執行任意程式碼。Prism >=v1.1.0 使用 _Previewers_ plugin (>=v1.10.0) 或 _Previewer: Easing_ plugin (v1.1.0 至 v1.9.0)，因此所有使用 Prism >=v1.1.0 的 Safari 和 Internet Explorer 使用者皆會受此弱點影響。此問題已在 1.21.0 版中修復。
若要在不升級的情況下因應此問題，請在所有受影響的程式碼區塊上停用緩動預覽。您需要 Prism v1.10.0 或更新版本，才能套用此因應措施。(CVE-2020-15138)
- 在 Node.js 的 xmldom (發佈為 @xmldom/xmldom) 套件 0.8.3 之前版本中，透過 p 變數可在 dom.js 的 copy 函式中產生原型污染弱點。注意：廠商表示我們正在將此報告標記為無效，但是某些第三方認為原型插入/原型污染不僅在全域物件受到遞回合併或深度複製污染時發生，也在目標物件受到污染時發生。(CVE-2022-37616)
- Certifi 是精選的 Root 憑證集合，用於在驗證 TLS 主機身分的同時驗證 SSL 憑證的可靠性。Certifi 2022.12.07 從 root 存放區移除了 TrustCor 中的 Root 憑證。目前正在從 Mozilla 的信任儲存區中移除這些憑證。
根據一項媒體調查報告，TrustCor 的擁有者也經營一間生產間諜軟體的企業，目前 TrustCor 的 Root 憑證遭到移除。在連結的 Google 群組討論中可以找到 Mozilla 的調查結論。(CVE-2022-23491)
- 在 Color-String 1.5.5 及更舊版本中發現規則運算式拒絕服務 (ReDOS) 弱點，在提供應用程式並檢查特製的無效 HWB 字串時會發生此問題。
(CVE-2021-29060)
- decode-uri-component 0.2.0 容易產生不當輸入驗證問題，進而導致 DoS。(CVE-2022-38900)
- 這會影響低於 5.1.2 版本的 glob-parent 套件。enclosure regex 先前用於檢查以包含路徑分隔符號的 enclosure 結尾的字串。(CVE-2020-28469)
- JSON5 是熱門 JSON 檔案格式的擴充，其目標是為了更方便手動寫入和維護 (例如設定檔)。JSON5 程式庫 1.0.1 和更低版本以及 2.2.1 版中的 `parse` 方法未限制名為 `__proto__` 的金鑰剖析，所以允許特製的字串污染結果物件的原型。此弱點會污染由 `JSON5.parse` 傳回的物件原型，而非全域 Object 原型，而後者是「原型污染」的常見定義。不過，若該物件稍後用於受信任的作業中，則污染單一物件的原型可能會對應用程式造成重大安全性影響。此弱點可允許攻擊者在 `JSON5.parse` 傳回的物件上設定任意非預期的金鑰。實際影響將取決於應用程式利用傳回物件的方式以及它們篩選不需要金鑰的方式，但這可能包括拒絕服務、跨網站指令碼和權限提升攻擊，在極端情況下，還會導致遠端程式碼執行。剖析物件的 JSON 字串時，`JSON5.parse` 應限制剖析 `__proto__` 金鑰。作為參照點，JavaScript 中包含的 `JSON.parse` 方法會忽略 `__proto__` 金鑰。在上述範例中，只需將 `JSON5.parse` 變更為 `JSON.parse`，即可減輕此弱點的影響。此弱點已在 json5 1.0.2、2.2.2 和更新版本中修正。(CVE-2022-46175)
- 在 webpack loader-utils 2.0.0 中 interpolateName.js 的函式 interpolateName 中發現規則運算式拒絕服務 (ReDoS) 缺陷，透過 interpolateName.js 中的 resourcePath 變數可觸發此問題。
(CVE-2022-37599)
- 在 webpack loader-utils 中，透過 parseQuery.js 中的名稱變數，可在 parseQuery.js 的 parseQuery 函式中造成原型污染弱點。1.4.1 之前的所有版本和 2.0.3 版本會受到此弱點影響。(CVE-2022-37601)
- 在 webpack loader-utils 2.0.0 中 interpolateName.js 的函式 interpolateName 中發現規則運算式拒絕服務 (ReDoS) 缺陷，透過 interpolateName.js 中的 url 變數可觸發此問題。
(CVE-2022-37603)
- 在 minimatch 套件中發現一個弱點。使用特定引數呼叫 breedExpand 函式時，此缺陷允許發生規則運算式拒絕服務 (ReDoS)，進而導致程式拒絕服務。(CVE-2022-3517)
- moment 是一個 JavaScript 日期庫，用於剖析、驗證、操作和格式化日期。據發現，受影響的 moment 版本使用了低效率剖析演算法。具體而言，在 moment 中使用 string-to-date 剖析 (更確切地說，是預設嘗試的 rfc2822 剖析) 處理特定輸入時，複雜性爲二的次方 (N^2)。使用者可能會發現，當輸入資料超過 10k 字元時，處理速度會明顯減慢。如果使用者將由使用者提供的字串傳遞給 moment 建構函式，而未經過例行長度檢查，就容易遭受 (Re)DoS 攻擊。此問題已在 2.29.4 版中修補，且該修補程式可套用至調整極少的所有受影響的版本。建議所有使用者進行升級。無法升級的使用者應考慮限制接受使用者輸入的日期長度。(CVE-2022-31129)
- 所有版本的 path-parse 套件都容易受到藉由 splitDeviceRe、splitTailRe 和 splitPathRe 規則運算式觸發的規則運算式拒絕服務 (ReDoS) 攻擊。ReDoS 呈現出多項式最壞情況時間複雜度。(CVE-2021-23343)
- 套件 postcss 7.0.0 至 8.2.10 版本容易在 Source Map 剖析期間受到規則運算式拒絕服務 (ReDoS) 攻擊。(CVE-2021-23368)
- 套件 postcss 8.2.13 之前版本容易受到 lib/previous-map.js 中 getAnnotationURL() 和 loadAnnotation() 的規則運算式拒絕服務 (ReDoS) 弱點影響。此規則運算式弱點主要是由子模式 \/\*\s* sourceMappingURL=(.*) 造成。(CVE-2021-23382)
- 在 libexpat 2.4.9 以及之前的所有版本中，在記憶體不足的情況下，過度破壞 XML_ExternalEntityParserCreate 中的共用 DTD 會造成釋放後使用。(CVE-2022-43680)
- 6.10.3 之前的 qs 使用於 4.17.3 之前的 Express 和其他產品中，這會讓攻擊者造成 Express 應用程式的 Node 處理程序懸置，因為可以使用 __ proto__ 金鑰。在許多典型的 Express 使用案例中，未經驗證的遠端攻擊者可將攻擊承載置於用於造訪應用程式的 URL 查詢字串中，例如 a[__proto__]=b&a[__proto__]&a[length]=100000000。修復程式已反向移植到 qs 6.9.7、6.8.3、6.7.3、6.6.1、6.5.3、6.4.1、6.3.3 和 6.2.4 (因此版本說明中包含 deps: [email protected] 的 Express 4.17.3 不受此弱點影響)。(CVE-2022-24999)
- 所有版本的 trim 套件都容易受到 trim() 中的規則運算式拒絕服務弱點 (ReDoS) 影響。
(CVE-2020-7753)
- 因為使用不安全的規則運算式，terser 套件 4.8.1 之前版本以及 5.0.0 至 5.14.2 版皆容易受到規則運算式拒絕服務 (ReDoS) 弱點影響。(CVE-2022-25858)
- nth-check 容易受到低效規則運算式複雜性的影響 (CVE-2021-3803)
- Node.js 4.0.0 至 5.0.0 版中的 css-what 套件未確保屬性剖析具有相對於輸入大小的線性時間複雜度。(CVE-2021-33587)
- dot-prop npm 套件的 4.2.1 之前版本以及 5.x 版的 5.1.1 之前版本存在原型污染弱點，允許攻擊者添加任意屬性至 JavaScript 語言構造 (如物件)。
(CVE-2020-8116)
- Node.js 的 Elliptic 套件 6.5.2 允許透過編碼中的變體導致 ECDSA 簽章延展性，進而造成「\0」位元組或整數溢位。如果應用程式仰賴單一正式簽章，這可能會造成安全性相關影響。(CVE-2020-13822)
- Node.js 12.1.0 之前版本的 got 套件 (也已經在 11.8.5 中得到修正) 允許重新導向至 UNIX 通訊端。
(CVE-2022-33987)
- Login with Cognito WordPress Plugin 1.4.8 及更低版本未清理並逸出其部分設定，即使 unfiltered_html 功能遭到禁止 (例如在多網站設定中)，仍可允許高權限使用者 (如管理員) 執行儲存型跨網站指令碼攻擊。(CVE-2022-4200)
- 在 2.13.4 之前的 FasterXML jackson-databind 中，因為 BeanDeserializer._deserializeFromArray 中缺少爲防止使用深層巢狀陣列而執行的檢查，因而會發生資源耗盡的情況。只有在使用某些自訂的還原序列化選項時，應用程式才容易受到攻擊。(CVE-2022-42004)
- [Json-smart](https://netplex.github.io/json-smart/) 是一個注重效能的 JSON 處理器 lib。當遇到 JSON 輸入中的 [ 或 { 字元時，程式碼會分別剖析陣列或物件。據發現，程式碼對於此類陣列或物件的巢狀結構沒有任何限制。由於巢狀陣列和物件的剖析是以遞回方式完成，因此巢狀陣列和物件過多時可造成堆疊耗盡 (堆疊溢位) 和軟體損毀。(CVE-2023-1370)
- 在 kind-of v6.0.2 中，index.js 的 ctorName 允許外部使用者輸入透過衝突的名稱覆寫某些內部屬性，'constructor': {'name':'Symbol'} 即為一例。因此，攻擊者可利用特製的承載來覆寫此內建屬性，達到操控類型偵測結果的目的。(CVE-2019-20149)
- 在 lodash 4.17.20 之前版本中，使用 _.zipObjectDeep 時會觸發原型污染攻擊。(CVE-2020-8203)
- 早於 4.17.12 的 lodash 版本容易受到原型污染影響。defaultsDeep 函式可能遭到誘騙，使用構造函式負載添加或修改 Object.prototype 的屬性。
(CVE-2019-10744)
- 使用 Lexer 類別剖析時，1.2.2 版之前的 Sqlalchemy mako 容易發生規則運算式拒絕服務。此問題也會影響 babelplugin 和 linguaplugin。(CVE-2022-40023)
- 在 1.3.2 之前版本和 2.0.0 版中，mixin-deep 容易受到原型污染影問題影響。mixin-deep 函式可能遭到誘騙，使用構造函式負載添加或修改 Object.prototype 的屬性。(CVE-2019-10746)
- 在適用 Node.js 的低於 4.5.1、5.x 至 5.3.1 以及 6.x 至 6.0.1 的 normalize-url 套件中，存在一個 ReDoS (規則運算式拒絕服務) 問題，因 data:URL 的指數表現引起。
(CVE-2021-33502)
- ua-parser-js >= 0.7.14 使用的規則運算式容易受到拒絕服務攻擊 (此問題已在 0.7.24 版中修復)，如果攻擊者傳送惡意的 User-Agent 標頭，ua-parser-js 會長時間停滯處理。(CVE-2021-27292)
在 1.26.5 之前的 urllib3 中發現一個問題。當在授權元件中提供含有許多 @ 字元的 URL 時，授權規則運算式會出現災難性回溯，如果將 URL 作為參數傳遞或透過 HTTP 重新導向進行重新導向，則會造成拒絕服務。
(CVE-2021-33503)
- websocket-extensions npm 模組 0.1.4 之前版本允許透過 Regex 回溯造成拒絕服務 (DoS)。剖析含有未封閉字串參數值 (其內容為反斜線和其他字元的重複兩位元組序列) 的標頭時，延伸模組剖析器可能會花費雙倍時間。攻擊者可對此加以濫用，透過提供具有 Sec-WebSocket-Extensions 標頭的惡意承載，在單執行緒伺服器上發動 Regex 拒絕服務 (ReDoS)。(CVE-2020-7662)
- 3.2.2、 4.0.1 和 5.0.5 之前的 y18n 套件容易受到原型污染。 (CVE-2020-7774)
- 在 Go 1.16.14 之前版本和 Go 1.17.x 至 1.17.7 版本中，crypto/elliptic 內的 Curve.IsOnCurve 在 big.Int 值不是有效欄位元素的情況下，可能會不正確地傳回 true。(CVE-2022-23806)
- 在 Go 1.16.14 之前版本和 Go 1.17.x 至 1.17.7 版本中，math/big 的 Rat.SetString 內有溢位問題，可能導致不受控制的記憶體消耗。(CVE-2022-23772)
- 0.0之前的 x/crypto/ssh 套件。0-20211202192323-5770296golang.org/x/crypto 的 d904e 允許攻擊者造成 SSH 伺服器錯誤。(CVE-2021-43565)
- 在 Go 1.17.11 和 Go 1.18.3 之前版本中，os/exec 的 Cmd.Start 中存在程式碼插入弱點，允許在未設定 Cmd.Path 的情況下，透過呼叫 Cmd.Run、Cmd.Start、Cmd.Output 或 Cmd.CombinedOutput() 在名為 ..com 或 ..exe 的工作目錄中執行任何二進位檔。(CVE-2022-30580)
- 在 Go 1.17.12 之前版本和 Go 1.18.4 版中，encoding/xml 的 Unmarshal 中存在不受控制的遞回弱點，攻擊者可藉此透過將 XML 文件解組到具有使用「any」欄位標籤的巢狀欄位的 Go 結構中來造成堆疊耗盡，進而引致錯誤。(CVE-2022-30633)
- 在 Go 1.17.12 之前版本和 Go 1.18.4 版中，encoding/gob 的 Decoder.Decode 中存在不受控制的遞回弱點，攻擊者可藉此透過包含深度巢狀結構的 XML 文件來造成堆疊耗盡，進而引致錯誤。(CVE-2022-28131)
- 在 Go 1.17.12 之前版本和 Go 1.18.4 版中，path/filepath 的 Glob 中存在不受控制的遞回弱點，攻擊者可藉此透過包含大量路徑分隔符號的路徑造成堆疊耗盡，進而引致錯誤。
(CVE-2022-30632)
- 由於未清理 NUL 值，攻擊者可能能夠在 Windows 上惡意設定環境變數。
在 syscall.StartProcess 和 os/exec.Cmd 中，未正確檢查包含 NUL 值的無效環境變數值。惡意的環境變數值可利用此行為，為不同的環境變數設定值。例如，環境變數字串 A=B\x00C=D 設定變數 A=B 和 C=D。 (CVE-2022-41716)
- 在 Go 1.17.9 之前版本以及 1.18.x 的 1.18.1 之前版本中，crypto/elliptic 的一般 P-256 特徵允許透過長純量輸入造成錯誤。(CVE-2022-28327)
- Go 1.16.15 之前版本和 Go 1.17.x 至 1.17.8 版本中的 regexp.Compile 允許透過深度巢狀運算式造成堆疊耗盡。(CVE-2022-24921)
- 在 Go 1.17.12 之前版本和 Go 1.18.4 版中，io/fs 的 Glob 中存在不受控制的遞回弱點，攻擊者可藉此透過包含大量路徑分隔符號的路徑造成堆疊耗盡，進而引致錯誤。
(CVE-2022-30630)
- 適用於 Go 的 golang.org/x/crypto/ssh 套件 0.0.0-20220314234659-1baeb1ce4c0b 之前版本在涉及 AddHostKey 的某些情況下允許攻擊者造成伺服器當機。(CVE-2022-27191)
- 在 Go 1.16.14 之前版本和 1.17.x 至 1.17.7 版本中，cmd/go 會錯誤地將分支名稱解釋為版本標籤。如果執行者能夠建立分支，但不能建立標籤，此弱點有可能會導致不正確的存取控制問題。(CVE-2022-23773)
- 在 Windows 系統中的 Go 1.17.11 和 Go 1.18.3 之前版本中， crypto/rand 的 Read 中存在無限迴圈弱點，允許攻擊者透過傳送大於 1 << 32 - 1 位元組的緩衝區造成無限期懸置。(CVE-2022-30634)
- 編譯來自非受信任來源的規則運算式的程式可能容易受到記憶體耗盡或拒絕服務攻擊。剖析的規則運算式的表示法與輸入的大小成線性關係，但在某些情況下，常數因子可高達 40,000，使得相對較小的 regexp 會消耗大量記憶體。修正後，將每個要剖析的規則運算式的記憶體佔用量都限制為 256 MB。如果表示法佔用的空間超過限制，此規則運算式會遭到拒絕。正常使用的規則運算式不受影響。(CVE-2022-41715)
- 在 Go 1.17.9 之前版本以及 1.18.x 的 1.18.1 之前版本中，encoding/pem 允許透過大量 PEM 資料造成解碼堆疊溢位問題。(CVE-2022-24675)
- 在 Windows 上，可透過 os.DirFS 和 http.Dir 存取受限制的檔案。os.DirFS 函式和 http.Dir 類型提供以指定目錄為 root 之檔案樹狀結構的存取權。這些函式允許在該 root 下存取 Windows 裝置檔案。例如 os.DirFS(C:/tmp).Open(COM1) 會開啟 COM1 裝置。
os.DirFS 和 http.Dir 都只提供檔案系統的唯讀存取權。此外，在 Windows 上，目錄 (目前磁碟機的 root) 的 os.DirFS 可允許惡意特製的路徑從磁碟機逸出並存取系統上的任何路徑。套用修正後，os.DirFS() 的行為已變更。
之前，系統會將空 root 等同於 /，因此 os.DirFS().Open(tmp) 會開啟路徑 /tmp。現在會傳回錯誤。(CVE-2022-41720)
- 在 Go 1.18.6 之前版本和 1.19.1 之前的 1.19.x 版中，攻擊者可在 net/http 中造成拒絕服務，這是因爲如果嚴重錯誤先於關機操作執行，則 HTTP/2 連線可能在關閉期間懸置。(CVE-2022-27664)
- ReverseProxy 轉送的要求包含來自傳入要求的原始查詢參數，包括 net/http 拒絕的無法剖析的參數。當 Go Proxy 轉送具有無法剖析的值的參數時，可以觸發查詢參數走私。修正後，在 ReverseProxy 之後設定傳出要求的 Form 欄位時，ReverseProxy 會清理轉送的查詢中的查詢參數。Director 函式傳回，表示 Proxy 已剖析此查詢參數。不剖析查詢參數的 Proxy 會繼續原封不動地轉送原始查詢參數。(CVE-2022-2880)
- 在 Windows 系統中的 Go 1.17.11 和 Go 1.18.3 之前版本中，路徑/檔案路徑清理中會發生特定的無效路徑錯誤轉換為有效的絕對路徑，這可能引致目錄遊走攻擊。(CVE-2022-29804)
- 在 Go 1.17.13 之前版本和 1.18.5 版中，編碼訊息太短可造成 math/big 中的 Float.GobDecode 和 Rat GobDecode 發生錯誤，進而可能導致拒絕服務。(CVE-2022-32189)
- 在 Go 1.17.12 之前版本和 Go 1.18.4 版中，encoding/gob 的 Decoder.Decode 中存在不受控制的遞回弱點，攻擊者可藉此透過包含深度巢狀結構的訊息來造成堆疊耗盡，進而引致錯誤。
(CVE-2022-30635)
- 在 Go 1.17.12 之前版本和 Go 1.18.4 版中，compress/gzip 的 Reader.Read 中存在不受控制的遞回弱點，攻擊者可藉此透過含有大量串連長度為 0 的壓縮檔案的封存造成堆疊耗盡，進而引致錯誤。(CVE-2022-30631)
- Reader.Read 未設定檔案標頭的大小上限。攻擊者可透過惡意特製的封存造成 Read 配置無限量的記憶體，這可能引致資源耗盡或錯誤。
修正後，Reader.Read 會將標頭區塊的大小上限限制為 1 MiB。(CVE-2022-2879)
- 在 Go 1.17.12 之前版本和 Go 1.18.4 版中，net/http 中的 HTTP/1 用戶端會接受某些無效的 Transfer-Encoding 標頭，如果配合使用的中繼伺服器與也未正確拒絕此無效標頭，則可以觸發 HTTP 要求走私攻擊。(CVE-2022-1705)
- 在 Go 1.17.12 之前版本和 Go 1.18.4 版中，go/parser 中的 Parse 函式存在不受控制的遞回弱點，攻擊者可藉此透過深度巢狀類型或宣告造成堆疊耗盡，進而引致錯誤。(CVE-2022-1962)
- 在 Go 1.17.10 之前版本和 1.18.2 之前的 1.18.x 版本中具有不正確的權限指派。使用非零旗標參數呼叫時，Faccessat 函式可能會錯誤報告檔案可供存取。
(CVE-2022-29526)
- 在 Go 1.17.12 之前版本和 Go 1.18.4 版中，net/http 中存在不當暴露用戶端 IP 位址的弱點，藉由使用包含 nil 值的 Request.Header 對應爲 X-Forwarded-For 標頭呼叫 httputil.ReverseProxy.ServeHTTP 可以觸發此弱點，造成 ReverseProxy 將用戶端 IP 設定為 X-Forwarded-For 標頭的值。(CVE-2022-32148)
- 在 Go 1.17.11 之前版本和 1.18.3 版本中，crypto/tls 爲工作階段票證中的 ticket_age_add 使用非隨機值，因此，可觀察 TLS 交握的攻擊者能夠透過在工作階段恢復期間比較票證期限來關聯連續的連線。(CVE-2022-30629)
- Growl 將 growl 通知支援新增至 nodejs。Growl 1.10.2 之前版本未正確清理輸入便將其傳遞至 exec，進而允許任意命令執行。(CVE-2017-16042)
- 拒絕原因：請勿使用此候選版本編號。ConsultIDs：無。原因：此候選版本由其 CNA 撤回。備註：無 (CVE-2021-20095)
請注意，Nessus 並未測試此問題，而是僅依據應用程式自我報告的版本號碼作出判斷。
解決方案
建議 Splunk Enterprise 用戶升級至 8.1.14、8.2.11、9.0.5 或更高版本。另請參閱
Plugin 詳細資訊
嚴重性: Critical
ID: 194919
檔案名稱: splunk_905_svd-2023-0613.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-37616
弱點資訊
CPE: cpe:/a:splunk:splunk
必要的 KB 項目: installed_sw/Splunk
可被惡意程式利用: true
可輕鬆利用: Exploits are available
修補程式發佈日期: 2023/6/1
弱點發布日期: 2023/6/1
參考資訊
CVE: CVE-2017-16042, CVE-2018-25032, CVE-2019-10744, CVE-2019-10746, CVE-2019-20149, CVE-2020-13822, CVE-2020-15138, CVE-2020-28469, CVE-2020-7662, CVE-2020-7753, CVE-2020-7774, CVE-2020-8116, CVE-2020-8169, CVE-2020-8177, CVE-2020-8203, CVE-2020-8231, CVE-2020-8284, CVE-2020-8285, CVE-2020-8286, CVE-2021-20095, 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-23343, CVE-2021-23368, CVE-2021-23382, CVE-2021-27292, CVE-2021-29060, CVE-2021-31566, CVE-2021-33502, CVE-2021-33503, CVE-2021-33587, CVE-2021-3520, CVE-2021-36976, CVE-2021-3803, CVE-2021-43565, CVE-2022-1705, CVE-2022-1962, CVE-2022-22576, CVE-2022-23491, CVE-2022-23772, CVE-2022-23773, CVE-2022-23806, CVE-2022-24675, CVE-2022-24921, CVE-2022-24999, CVE-2022-25858, CVE-2022-27191, CVE-2022-27664, 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-28131, CVE-2022-28327, CVE-2022-2879, CVE-2022-2880, CVE-2022-29526, CVE-2022-29804, CVE-2022-30115, CVE-2022-30580, CVE-2022-30629, CVE-2022-30630, CVE-2022-30631, CVE-2022-30632, CVE-2022-30633, CVE-2022-30634, CVE-2022-30635, CVE-2022-31129, CVE-2022-32148, CVE-2022-32189, CVE-2022-32205, CVE-2022-32206, CVE-2022-32207, CVE-2022-32208, CVE-2022-32221, CVE-2022-33987, CVE-2022-3517, CVE-2022-35252, CVE-2022-35260, CVE-2022-35737, CVE-2022-36227, CVE-2022-37434, CVE-2022-37599, CVE-2022-37601, CVE-2022-37603, CVE-2022-37616, CVE-2022-38900, CVE-2022-40023, CVE-2022-40303, CVE-2022-40304, CVE-2022-41715, CVE-2022-41716, CVE-2022-41720, CVE-2022-4200, CVE-2022-42004, CVE-2022-42915, CVE-2022-42916, CVE-2022-4304, CVE-2022-43551, CVE-2022-43552, CVE-2022-43680, CVE-2022-46175, CVE-2023-0215, CVE-2023-0286, CVE-2023-1370, 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