Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

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

請注意，Nessus 依賴供應商報告的套件存在。

遠端 CentOS Linux 8 主機上安裝的套件受到 CESA-2023: 3319 公告中提及的一個弱點影響。

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

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

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

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

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

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

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

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

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

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

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

  - Windows 中的 filepath.Clean 存在路徑遊走弱點。在 Windows 中，filepath.Clean 函式可將無效路徑 (例如 a/../c: /b 轉換為有效路徑 c:\b。相對路徑 (若無效) 的這種轉換可觸發目錄遊走攻擊。修正之後，filepath.Clean 函式會將此路徑轉換為相對 (但仍無效的) 路徑。\c:\b。(CVE-2022-41722)

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

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

  - 並非所有有效的 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)

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

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

此 Solaris 系統缺少可解決重大安全性更新的必要修補程式：

遠端主機上安裝的 containerd 版本為早於 1.6.19-1 的版本。因此，會受到 ALAS2NITRO-ENCLAVES-2023-026 公告中所提及的多個弱點影響。

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

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

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

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

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

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

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

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

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

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

  - 範本包含以空白輸入執行的未加引號的 HTML 屬性 (例如 attr={{.}}) 中的操作，這可能會因為 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

遠端主機上安裝的 containerd 版本為早於 1.6.19-1 的版本。因此，會受到 ALAS2DOCKER-2023-029 公告中所提及的多個弱點影響。

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

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

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

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

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

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

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

因此，會受到 ALAS2023-2023-175 公告中所提及的多個弱點影響。

  - 在 Go 1.16.14 之前版本和 Go 1.17.x 至 1.17.7 版本中，math/big 的 Rat.SetString 內有溢位問題，可能導致不受控制的記憶體消耗。(CVE-2022-23772)

  - 在 Go 1.16.14 之前版本和 1.17.x 至 1.17.7 版本中，cmd/go 會錯誤地將分支名稱解釋為版本標籤。如果執行者能夠建立分支，但不能建立標籤，此弱點有可能會導致不正確的存取控制問題。(CVE-2022-23773)

  - 在 Go 1.16.14 之前版本和 Go 1.17.x 至 1.17.7 版本中，crypto/elliptic 內的 Curve.IsOnCurve 在 big.Int 值不是有效欄位元素的情況下，可能會不正確地傳回 true。(CVE-2022-23806)

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

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

  - 在 Windows 系統中的 Go 1.17.11 和 Go 1.18.3 之前版本中， crypto/rand 的 Read 中存在無限迴圈弱點，允許攻擊者透過傳送大於 1 << 32 - 1 位元組的緩衝區造成無限期懸置。(CVE-2022-30634)

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

  - Windows 中的 filepath.Clean 存在路徑遊走弱點。在 Windows 中，filepath.Clean 函式可將無效路徑 (例如 a/../c: /b 轉換為有效路徑 c:\b。相對路徑 (若無效) 的這種轉換可觸發目錄遊走攻擊。修正之後，filepath.Clean 函式會將此路徑轉換為相對 (但仍無效的) 路徑。\c:\b。(CVE-2022-41722)

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

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

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

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

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

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

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

  - 使用 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)

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

遠端主機上安裝的 Oracle TimesTen 為低於 22.x 的 22.1.1.7.0 版，
因此會受到 2023 年 7 月 CPU 公告中提及的多個弱點影響

  - Oracle TimesTen 記憶體內資料庫中的弱點 (元件：TimesTen IMDB (Dell BSAFE Micro Edition Suite))。受影響的支援版本是 22.1.1.1.0 - 22.1.1.6.0。攻擊此弱點的難度較大，能夠透過多個通訊協定存取網路的未經驗證的攻擊者可利用此弱點入侵 Oracle TimesTen In-Memory Database。(CVE-2020-35168)

  - Oracle TimesTen In-Memory Database 中的 Security-in-Depth 問題 (元件：EM TimesTen plugin (Netty))。(CVE-2022-41881)

  - Oracle TimesTen In-Memory Database 中的 Security-in-Depth 問題 (元件：EM TimesTen 外掛程式 (Golang Go))。
    (CVE-2023-24532)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
226214	Linux Distros 未修補弱點：CVE-2023-24532	Nessus	Misc.	2025/3/5	2025/3/5	medium
176390	CentOS 8：go-toolset: rhel8 (CESA-2023: 3319)	Nessus	CentOS Local Security Checks	2023/5/25	2024/2/8	critical
176392	RHEL 8：go-toolset: rhel8 (RHSA-2023: 3319)	Nessus	Red Hat Local Security Checks	2023/5/25	2025/3/6	critical
182699	Amazon Linux AMI：golang (ALAS-2023-1848)	Nessus	Amazon Linux Local Security Checks	2023/10/6	2024/12/11	critical
178626	Oracle Solaris 重要修補程式更新：jul2023_SRU11_4_58_144_3	Nessus	Solaris Local Security Checks	2023/7/20	2023/7/26	critical
179805	Amazon Linux 2：containerd (ALASNITRO-ENCLAVES-2023-026)	Nessus	Amazon Linux Local Security Checks	2023/8/14	2024/12/11	critical
176357	RHEL 9：go-toolset 和 golang (RHSA-2023: 3318)	Nessus	Red Hat Local Security Checks	2023/5/25	2025/3/6	critical
178816	Amazon Linux 2：golang (ALAS-2023-2163)	Nessus	Amazon Linux Local Security Checks	2023/7/26	2024/12/11	critical
180088	Amazon Linux 2：containerd (ALASDOCKER-2023-029)	Nessus	Amazon Linux Local Security Checks	2023/8/23	2024/12/11	critical
175071	Amazon Linux 2023：golang、golang-bin、golang-misc (ALAS2023-2023-175)	Nessus	Amazon Linux Local Security Checks	2023/5/3	2024/12/11	critical
182050	Amazon Linux 2：golang (ALASGOLANG1.19-2023-001)	Nessus	Amazon Linux Local Security Checks	2023/9/27	2024/12/11	critical
188072	Oracle TimesTen 22.x < 22.1.1.7.0 多個弱點 (2023 年 7 月 CPU)	Nessus	Misc.	2024/1/16	2024/1/17	critical

偵測

搜尋 Plugin

medium

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical

critical