遠端 Redhat Enterprise Linux 8 / 9 主機上安裝的套件受到 RHSA-2023:3612 公告中提及的多個弱點影響。

  - golang: net/http：接受 HTTP/2 要求的 Go 伺服器中發生記憶體過度增長 (CVE-2022-41717)

  - net/http、golang.org/x/net/http2：避免 HPACK 解碼中的二次方複雜度 (CVE-2022-41723)

  - golang: crypto/tls：大量交握記錄可造成錯誤 (CVE-2022-41724)

  - golang: net/http，mime/multipart：因資源消耗過度導致拒絕服務 (CVE-2022-41725)

  - golang：net/http、net/textproto：過度記憶體配置造成的拒絕服務 (CVE-2023-24534)

  - golang: net/http、net/textproto、mime/multipart：因資源消耗過度導致拒絕服務(CVE-2023-24536)

  - golang: go/parser：剖析中的無限迴圈 (CVE-2023-24537)

  - golang: html/template：未將反引號視為字串分隔符號 (CVE-2023-24538)

  - golang：html/template：不當處理 JavaScript 空格 (CVE-2023-24540)

  - runc：磁碟區掛載爭用情形 ( CVE-2019-19921 的遞迴) (CVE-2023-27561)

請注意，Nessus 並未測試這些問題，而是僅根據應用程式自我報告的版本號碼作出判斷。

遠端主機受到 GLSA-202311-09 中所述的弱點影響 (Go：多個弱點)

  - Reader.Read 未設定檔案標頭的大小上限。攻擊者可透過惡意特製的封存造成 Read 配置無限量的記憶體，這可能引致資源耗盡或錯誤。
    修正後，Reader.Read 會將標頭區塊的大小上限限制為 1 MiB。(CVE-2022-2879)

  - ReverseProxy 轉送的要求包含來自傳入要求的原始查詢參數，包括 net/http 拒絕的無法剖析的參數。當 Go Proxy 轉送具有無法剖析的值的參數時，可以觸發查詢參數走私。修正後，在 ReverseProxy 之後設定傳出要求的 Form 欄位時，ReverseProxy 會清理轉送的查詢中的查詢參數。Director 函式傳回，表示 Proxy 已剖析此查詢參數。不剖析查詢參數的 Proxy 會繼續原封不動地轉送原始查詢參數。(CVE-2022-2880)

  - 編譯來自非受信任來源的規則運算式的程式可能容易受到記憶體耗盡或拒絕服務攻擊。剖析的規則運算式的表示法與輸入的大小成線性關係，但在某些情況下，常數因子可高達 40,000，使得相對較小的 regexp 會消耗大量記憶體。修正後，將每個要剖析的規則運算式的記憶體佔用量都限制為 256 MB。如果表示法佔用的空間超過限制，此規則運算式會遭到拒絕。正常使用的規則運算式不受影響。(CVE-2022-41715)

  - 攻擊者可在接受 HTTP/2 要求的 Go 伺服器中造成記憶體過度增長。HTTP/2 伺服器連線包含用戶端傳送的 HTTP 標頭金鑰快取。雖然此快取中的項目總數設有上限，但攻擊者如果傳送非常大的金鑰，即可造成伺服器為每個開啟的連線配置大約 64 MiB。(CVE-2022-41717)

  - 惡意特製的 HTTP/2 串流可造成 HPACK 解碼器中發生 CPU 過度佔用問題，透過少量小型要求即可造成程式拒絕服務。(CVE-2022-41723)

  - 大量交握記錄可造成 crypto/tls 發生錯誤。用戶端和伺服器都可能傳送大量 TLS 交握記錄，這會分別造成伺服器和用戶端在嘗試建構回應時發生錯誤。此問題會影響所有 TLS 1.3 用戶端、明確啟用工作階段恢復的 TLS 1.2 用戶端 (透過將 Config.ClientSessionCache 設為非 nil 值)，以及要求用戶端憑證的 TLS 1.3 伺服器 (透過設定 Config.ClientAuth >= RequestClientCert) 。(CVE-2022-41724)

  - net/http 和 mime/multipart 中可能存在因資源消耗過度導致的拒絕服務問題。
    使用 mime/multipart.Reader.ReadForm 剖析 Multipart 表單時，可能會大量消耗無限量的記憶體和磁碟檔案。這也會影響 net/http 套件中使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 剖析表單的情況。ReadForm 採用 maxMemory 參數，並記錄為在記憶體中最多儲存 maxMemory 位元組 +10MB (為非檔案部分保留的空間)。無法儲存在記憶體中的檔案部分會儲存在磁碟上的暫存檔中。為非檔案部分保留的無法設定的 10MB 過大，可能會自行開啟拒絕服務媒介。但是，ReadForm 並未正確考量已剖析表單消耗的所有記憶體，例如對應項目額外負荷、部分名稱和 MIME 標頭，這允許惡意製作的表單消耗記憶體容量超過 10MB。此外，ReadForm 對建立的磁碟檔案數量沒有限制，允許相對較小的要求內文建立大量的磁碟暫存檔。修正後，ReadForm 現在會正確考量各種形式的記憶體額外負荷，並且現在應保持在其記錄的 10MB + maxMemory 位元組記憶體消耗範圍內。使用者仍應注意，此限制較高且可能仍然存在危險。此外，ReadForm 現在最多可建立一個磁碟上暫存檔，將多個表單部分合併為一個暫存檔。mime/multipart.File 介面類型的文件指出，如果儲存在磁碟上，檔案的基礎具體類型將為 *os.File.。如果表單包含多個檔案部分，則因為要將部分合併到一個檔案中，所以情況不再如此。之前針對每個表單部分使用不同檔案的行為，可透過環境變數 GODEBUG=multipartfiles=distinct 重新啟用。使用者應注意，multipart.ReadForm 和呼叫它的 http.Request 方法不會限制暫存檔消耗的磁碟量。呼叫者可使用 http.MaxBytesReader 限製表單資料的大小。(CVE-2022-41725)

  - 即使在剖析小輸入時，HTTP 和 MIME 標頭剖析仍可配置大量記憶體，進而可能導致拒絕服務。輸入資料的某些異常模式可造成用於剖析 HTTP 和 MIME 標頭的通用函式配置比保留已剖析標頭所需的更多的記憶體。攻擊者可惡意利用此行為，造成 HTTP 伺服器從小型要求配置大量記憶體，進而可能導致記憶體耗盡和拒絕服務。
    經過修正，標頭剖析現在只會正確配置保留已剖析標頭所需的記憶體。
    (CVE-2023-24534)

  - 處理含有極大量部分的表單輸入時，多部分表單剖析會消耗大量 CPU 和記憶體。這源於數個原因：1. mime/multipart.Reader.ReadForm 限制已剖析的多部分錶單可消耗的總記憶體。ReadForm 可低估消耗的記憶體量，導致其接受比預期更大的輸入。2. 限制總記憶體並未將具有許多部分的表單中的大量小配置對記憶體回收行程增加的壓力考慮在內。3.
    ReadForm 可配置大量存留期短的緩衝區，進一步增加記憶體回收行程的壓力。這些因素結合在一起，可允許攻擊者造成剖析多部分錶單的程式消耗大量 CPU 和記憶體，進而可能導致拒絕服務。
    這會影響使用 mime/multipart.Reader.ReadForm 的程式，以及具有 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 的 net/http 套件中的表單剖析。經過修正，ReadForm 現在可以更好地估計已剖析表單的記憶體消耗，並減少執行短期配置。此外，已修正的 mime/multipart.Reader 對剖析表單的大小進行了下列限制：1. 使用 ReadForm 剖析的表單最多可包含 1000 個部分。此限制可使用環境變數 GODEBUG=multipartmaxparts= 進行調整。 2. 使用 NextPart 和 NextRawPart 剖析的表單部分包含的標頭欄位不得超過 10,000。此外，使用 ReadForm 剖析的表單在所有部分中包含的標題欄位不得超過 10,000 個。此限制可使用環境變數 GODEBUG=multipartmaxheaders= 進行調整。(CVE-2023-24536)

  - 若在 Go 原始程式碼上呼叫含有非常大行數的 //line 指示詞的任何剖析函式，可因整數溢位而造成無限迴圈。(CVE-2023-24537)

  - 範本未正確將反引號 (`) 視為 Javascript 字串分隔符號，也未如預期對其進行逸出。自 ES6 起，JS 範本常值使用反引號。如果範本在 Javascript 範本常值中包含 Go 範本動作，則可使用動作內容終止該常值，從而將任意 Javascript 程式碼插入 Go 範本。由於 ES6 範本常值相當複雜，而且本身可以進行字串插入，因此決定簡單地禁止在其中使用 Go 範本動作 (例如 var a = {{.}})，因為此行為沒有明確可行的安全方法。這與 github.com/google/safehtml 所採用的方法相同。經過修正，Template.Parse 在遇到此類範本時會傳回 ErrorCode 值為 12 的錯誤。此 ErrorCode 目前未匯出，但將在 Go 1.21 版中匯出。依賴先前行為的使用者可使用 GODEBUG 旗標 jstmpllitinterp=1 重新執行該行為，但需要注意的是現在將逸出反引號。應謹慎使用。(CVE-2023-24538)

  - 使用 cgo 時，go 命令可能會在構建時產生未預期的程式碼。這可能會在執行使用 cgo 的 go 程式時導致非預期行為。執行名稱中含有新行字元的未受信任模組時，可能會發生此情況。使用 go 命令 (即透過「go get」) 擷取的模組不受影響 (使用 GOPATH 模式擷取的模組，即 GO111MODULE=off)。(CVE-2023-29402)

  - 在 Unix 平台上，使用 setuid/setgid 位元執行二進位檔時，Go 執行階段的行為並無不同。在某些情況下，這可能很危險，例如轉儲存記憶體狀態或假設標準 i/o 檔案描述符號的狀態時。如果在標準 I/O 檔案描述符號關閉的情況下執行 setuid/setgid 二進位檔，則開啟任何檔案都可能導致以提升權限讀取或寫入非預期的內容。
    同樣，如果 setuid/setgid 程式透過錯誤或訊號終止，則可能導致其暫存器的內容被洩漏。(CVE-2023-29403)

  - 使用 cgo 時，go 命令可能會在構建時執行任意程式碼。在惡意模組上執行 go get 時，或執行構建未受信任程式碼的任何其他命令時，可能會發生這種情況。這可以由透過 #cgo LDFLAGS 指示詞指定的連結器旗標觸發。許多非選用的旗標引數被錯誤地視為選用，進而允許透過 LDFLAGS 清理來走私不允許的旗標。這會影響 gc 和 gccgo 編譯器的使用。(CVE-2023-29404)

  - 使用 cgo 時，go 命令可能會在構建時執行任意程式碼。在惡意模組上執行 go get 時，或執行構建未受信任程式碼的任何其他命令時，可能會發生這種情況。這可以由透過 #cgo LDFLAGS 指示詞指定的連結器旗標觸發。未正確處理包含內嵌空格的旗標，進而允許透過 LDFLAGS 清理將不允許的旗標包含在另一個旗標的引數中。這會影響 gccgo 編譯器的使用。(CVE-2023-29405)

  - HTTP/1 用戶端未完整驗證 Host 標頭的內容。惡意特製的主機標頭可插入其他標頭或整個要求。修正後，HTTP/1 用戶端現在會拒絕傳送包含無效 Request.Host 或 Request.URL.Host 值的要求。(CVE-2023-29406)

  - 憑證鏈結中的 RSA 金鑰過大可造成用戶端/伺服器花費大量 CPU 時間來驗證簽章。修正後，交握期間傳輸的 RSA 金鑰大小會被限制為不超過 8192 個位元。根據對公開信任的 RSA 金鑰進行的調查，目前只有三個憑證的金鑰超過此大小，而且這三個憑證似乎都是未主動部署的測試憑證。私用 PKI 中可能會使用更大的金鑰，但我們的目標是 Web PKI，因此為了提高 crypto/tls 使用者的預設安全性，在此中斷使用似乎是合理做法。(CVE-2023-29409)

  - html/template 套件未正確處理類似 HTML 的註解 Token，也未正確處理 <script> 情境中的 hashbang #! 註解 Token。這可能會造成範本剖析器不當解譯 <script> 情境的內容，進而導致動作不當逸出。攻擊者可能會利用此弱點來執行 XSS 攻擊。(CVE-2023-39318)

  - html/範本套件未套用正確的規則來處理 <script, <!-- 的發生和 </script within JS literals in ><script> 情景。這可能會造成範本剖析器錯誤地認為指令碼上下文被提前終止，進而導致動作不當逸出。攻擊者可利用此弱點來執行 XSS 攻擊。(CVE-2023-39319)

  - 在模組內執行 go 命令時，Go 1.21 中引入的 go.mod 工具鏈指示詞可能會被用於執行相對於模組 root 的指令碼和二進位檔。這適用於使用 go 命令從模組 Proxy 下載的模組，以及直接使用 VCS 軟體下載的模組。(CVE-2023-39320)

  - 處理 QUIC 連線的不完整交握後訊息可造成錯誤。(CVE-2023-39321)

  - QUIC 連線在讀取交握後訊息時，未設定緩衝資料量的上限，進而允許惡意 QUIC 連線造成記憶體無限增長。修正後，連線現在會持續拒絕大小超過 65KiB 的訊息。(CVE-2023-39322)

  - Line 指示詞 (//line) 可用來繞過 //go: cgo_ 指示詞的限制，從而允許在編譯期間傳遞封鎖的連結器和編譯器標記。這可導致在執行 go build 時意外執行任意程式碼。Line 指示詞需要該指示詞所在檔案的絕對路徑，這會顯著加大惡意使用者利用此問題的難度。(CVE-2023-39323)

  - 惡意 HTTP/2 用戶端如能快速建立要求並立即將其重設，可以造成伺服器資源過度消耗。雖然要求總數受到 http2.Server.MaxConcurrentStreams 設定的限制，但重設進行中的要求讓攻擊者可在現有要求仍在執行時建立新要求。套用修正後，HTTP/2 伺服器現在會將同時執行的處置程式 goroutine 的數量限制為資料流並行限制 (MaxConcurrentStreams)。達到限制時到達的新要求 (只有在用戶端重設現有的執行中要求後才會發生) 將會排入佇列，直到處理常式結束。如果要求佇列變得過大，伺服器會終止連線。對於手動設定 HTTP/2 的使用者，此問題也已在 golang.org/x/net/http2 中修正。預設的資料流並行限制為每個 HTTP/2 連線 250 個資料流 (要求)。此值可使用 golang.org/x/net/http2 套件進行調整；請參閱 Server.MaxConcurrentStreams 設定和 ConfigureServer 函式。(CVE-2023-39325)

  - HTTP/2 通訊協定允許拒絕服務 (伺服器資源消耗)，因為要求取消可快速重設許多資料流，如 2023 年 8 月到 2023 年 10 月間遭到的猖獗惡意攻擊。(CVE-2023-44487)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

ID	名稱	產品	系列	已發布	已更新	嚴重性
194287	RHEL 8 / 9：OpenShift Container Platform 4.13.4 (RHSA-2023:3612)	Nessus	Red Hat Local Security Checks	2024/4/28	2025/8/15	critical
186294	GLSA-202311-09：Go：多個弱點	Nessus	Gentoo Local Security Checks	2023/11/27	2024/2/9	critical

偵測

搜尋 Plugin

critical

critical