遠端 CentOS Linux 9 主機上安裝的套件受到 buildah-1.30.0-2.el9 版本變更記錄中提及的多個弱點影響。

  - 惡意特製的 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)

  - 範本未正確將反引號 (`) 視為 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)

  - 插入 CSS 內容時，不將尖括號 (<>) 視為危險字元。如果使用未受信任的輸入執行範本，包含多個以「/」字元分隔的動作的範本可導致非預期地關閉 CSS 內容並允許插入非預期的 HTML。(CVE-2023-24539)

  - 並非所有有效的 JavaScript 空白字元都被視為空白字元。在 JavaScript 內容中，在字元集 \t\n\f\r\u0020\u2028\u2029 之外，包含其他空白字元和動作的範本可能無法在執行期間正確清理。(CVE-2023-24540)

  - containerd 是一種開放原始碼的容器執行階段。在 containerd 1.6.18 之前版本和 1.5.18 之前版本中發現一個錯誤，容器內未正確設定附加群組。如果攻擊者擁有容器的直接存取權並操控其附加群組存取權，則在某些情況下，他們可能能夠使用附加群組存取權繞過主要群組限制，進而可能獲得敏感資訊的存取權，或能夠在此容器中執行程式碼。使用 containerd 用戶端程式庫的下游應用程式也可能受到影響。此錯誤已在 containerd v1.6.18 和 v.1.5.18 中修正。使用者應更新至這些版本，並且重新建立容易以解決此問題。
    使用者若依賴使用 containerd 用戶端程式庫的下游應用程式，應檢查此應用程式是否有單獨的公告和指示。因應措施是確保不使用 `USER $USERNAME` Dockerfile 指令，而是將容器入口點設定為類似 `ENTRYPOINT [su, -, user]` 的值，以允許 `su` 正確設定附加群組。(CVE-2023-25173)

  - 範本包含以空白輸入執行的未加引號的 HTML 屬性 (例如 attr={{.}}) 中的操作，這可能會因為 HTML 正規化規則而導致在剖析時產生未預期的結果。這可能允許在標籤中插入任意屬性。(CVE-2023-29400)

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

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

  - golang: archive/tar：讀取標頭時發生無限制的記憶體消耗 (CVE-2022-2879)

  - golang: net/http/httputil：ReverseProxy 不應轉送無法剖析的查詢參數 (CVE-2022-2880)

  - golang：crypto/elliptic：過大的純量造成的錯誤 (CVE-2022-28327)

  - golang：regexp/syntax：限制剖析 regexp 所使用的記憶體 (CVE-2022-41715)

  - 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/範本：不當清理 CSS 值 (CVE-2023-24539)

  - golang: html/template：不當處理空白 HTML 屬性 (CVE-2023-29400)

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

遠端主機上安裝的 golang 版本早於 1.20.5-1。因此，會受到 ALAS2-2023-2163 公告中所提及的多個弱點影響。

  - 大量交握記錄可造成 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)

  - 如果使用某些特定的未歸約純量 (大於曲線階數的純量) 呼叫 P256 Curve 的 ScalarMult 和 ScalarBaseMult 方法，可能會傳回錯誤結果。這不會影響 crypto/ecdsa 或 crypto/ecdh 的使用。(CVE-2023-24532)

  - 處理含有極大量部分的表單輸入時，多部分表單剖析會消耗大量 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)

  - 範本未正確將反引號 (`) 視為 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)

  - 並非所有有效的 JavaScript 空白字元都被視為空白字元。在 JavaScript 內容中，在字元集 \t\n\f\r\u0020\u2028\u2029 之外，包含其他空白字元和動作的範本可能無法在執行期間正確清理。(CVE-2023-24540)

  - 範本包含以空白輸入執行的未加引號的 HTML 屬性 (例如 attr={{.}}) 中的操作，這可能會因為 HTML 正規化規則而導致在剖析時產生未預期的結果。這可能允許在標籤中插入任意屬性。(CVE-2023-29400)

  - 在 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)

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

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

  - go-yaml：改善啟發方式，透過剖析惡意或大型 YAML 文件避免 CPU/記憶體遭到濫用 (CVE-2022-3064)

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

  - 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: html/template：未將反引號視為字串分隔符號 (CVE-2023-24538)

  - golang：html/範本：不當清理 CSS 值 (CVE-2023-24539)

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

  - golang: html/template：不當處理空白 HTML 屬性 (CVE-2023-29400)

  - golang: net/http：主機標頭清理不充分 (CVE-2023-29406)

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

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

  - 惡意特製的 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)

  - 插入 CSS 內容時，不將尖括號 (<>) 視為危險字元。如果使用未受信任的輸入執行範本，包含多個以「/」字元分隔的動作的範本可導致非預期地關閉 CSS 內容並允許插入非預期的 HTML。(CVE-2023-24539)

  - 並非所有有效的 JavaScript 空白字元都被視為空白字元。在 JavaScript 內容中，在字元集 \t\n\f\r\u0020\u2028\u2029 之外，包含其他空白字元和動作的範本可能無法在執行期間正確清理。(CVE-2023-24540)

  - containerd 是一種開放原始碼的容器執行階段。在 containerd 1.6.18 之前版本和 1.5.18 之前版本中發現一個錯誤，容器內未正確設定附加群組。如果攻擊者擁有容器的直接存取權並操控其附加群組存取權，則在某些情況下，他們可能能夠使用附加群組存取權繞過主要群組限制，進而可能獲得敏感資訊的存取權，或能夠在此容器中執行程式碼。使用 containerd 用戶端程式庫的下游應用程式也可能受到影響。此錯誤已在 containerd v1.6.18 和 v.1.5.18 中修正。使用者應更新至這些版本，並且重新建立容易以解決此問題。
    使用者若依賴使用 containerd 用戶端程式庫的下游應用程式，應檢查此應用程式是否有單獨的公告和指示。因應措施是確保不使用 `USER $USERNAME` Dockerfile 指令，而是將容器入口點設定為類似 `ENTRYPOINT [su, -, user]` 的值，以允許 `su` 正確設定附加群組。(CVE-2023-25173)

  - 範本包含以空白輸入執行的未加引號的 HTML 屬性 (例如 attr={{.}}) 中的操作，這可能會因為 HTML 正規化規則而導致在剖析時產生未預期的結果。這可能允許在標籤中插入任意屬性。(CVE-2023-29400)

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

  - 不在 HTML 命名空間中的文字節點未被正確地逐字轉譯，導致本應逸出的文字並未正確轉譯。這可導致 XSS 攻擊。(CVE-2023-3978)

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

遠端 Oracle Linux 8 主機中安裝的套件受到 ELSA-2023-6938 公告中提及的多個弱點影響。

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

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

  - 不在 HTML 命名空間中的文字節點未被正確地逐字轉譯，導致本應逸出的文字並未正確轉譯。這可導致 XSS 攻擊。(CVE-2023-3978)

  - runc 是一種 CLI 工具，用於根據 OCI 規範產生並執行容器。據發現，在受影響的版本中，rootless runc 使「/sys/fs/cgroup」在下列情況下可寫入：1. 在使用者命名空間內執行 runc，且「config.json」未指定取消共用的 cgroup 命名空間時 (例如，「(docker|podman|nerdctl) run --cgroupns=host」，使用 Rootless Docker/ Podman/nerdctl) 或 2. 在使用者命名空間之外執行 runc，且「/sys」掛載了「rbind, ro」(例如「runc spec --rootless」；此情形非常罕見)。容器可取得主機上使用者擁有的 cgroup 階層「/sys/fs/cgroup/user.slice/...」的寫入存取權。其他使用者的 cgroup 階層不受影響。
    建議使用者升級至 1.1.5 版。無法升級的使用者可能取消共用 cgroup 命名空間 (「(docker|podman|nerdctl) run --cgroupns=private)」。這是 cgroup v2 主機上 Docker/Podman/nerdctl 的預設行為。或新增「/sys/fs/cgroup」至「maskedPaths」。(CVE-2023-25809)

  - 範本包含以空白輸入執行的未加引號的 HTML 屬性 (例如 attr={{.}}) 中的操作，這可能會因為 HTML 正規化規則而導致在剖析時產生未預期的結果。這可能允許在標籤中插入任意屬性。(CVE-2023-29400)

  - 剖析惡意或大型 YAML 文件會消耗過量的 CPU 或記憶體。(CVE-2022-3064)

  - 即使在剖析小輸入時，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)

  - 範本未正確將反引號 (`) 視為 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)

  - 大量交握記錄可造成 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)

  - 並非所有有效的 JavaScript 空白字元都被視為空白字元。在 JavaScript 內容中，在字元集 \t\n\f\r\u0020\u2028\u2029 之外，包含其他空白字元和動作的範本可能無法在執行期間正確清理。(CVE-2023-24540)

  - 1.1.4 及之前的 runc 版本含有可導致權限提升的錯誤存取控制，此問題與 libcontainer/rootfs_linux.go 有關。若要利用此問題，攻擊者必須能夠生成兩個具有自訂 volume-mount 組態的容器，並且能夠執行自訂影像。注意：此問題之所以存在，是因為 CVE-2019-19921 迴歸造成。(CVE-2023-27561)

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

  - 插入 CSS 內容時，不將尖括號 (<>) 視為危險字元。如果使用未受信任的輸入執行範本，包含多個以「/」字元分隔的動作的範本可導致非預期地關閉 CSS 內容並允許插入非預期的 HTML。(CVE-2023-24539)

  - runc 是一種 CLI 工具，用於根據 OCI 規範產生並執行容器。據發現，當容器內的「/proc」與特定掛載組態進行符號連結時，可繞過 AppArmor。此問題已在 runc 版本 1.1.5 中修正，方法是禁止符號連結「/proc」。詳細資訊請查看 PR #3785。我們建議使用者進行升級。無法升級的使用者應避免使用不受信任的容器映像。(CVE-2023-28642)

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

遠端主機上安裝的 Splunk 版本低於測試版本。因此，它會受到 SVD-2024-0303 公告中提及的一個弱點影響。

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
191201	CentOS 9：buildah-1.30.0-2.el9	Nessus	CentOS Local Security Checks	2024/2/29	2024/4/26	critical
194327	RHEL 8 / 9：Red Hat Service Interconnect 1.4 Release (RHSA-2023:4003)	Nessus	Red Hat Local Security Checks	2024/4/28	2024/11/7	critical
178816	Amazon Linux 2：golang (ALAS-2023-2163)	Nessus	Amazon Linux Local Security Checks	2023/7/26	2024/12/11	critical
185100	RHEL 9：toolbox (RHSA-2023:6346)	Nessus	Red Hat Local Security Checks	2023/11/7	2025/3/6	critical
185115	RHEL 9：podman (RHSA-2023: 6474)	Nessus	Red Hat Local Security Checks	2023/11/7	2025/3/6	critical
186113	Oracle Linux 8：container-tools：4.0 (ELSA-2023-6938)	Nessus	Oracle Linux Local Security Checks	2023/11/21	2025/9/9	critical
194923	Splunk Enterprise 9.0.0 < 9.0.9、9.1.0 < 9.1.4、9.2.0 < 9.2.1 (SVD-2024-0303)	Nessus	CGI abuses	2024/5/2	2025/5/12	critical

偵測

搜尋 Plugin

critical

critical

critical

critical

critical

critical

critical