远程 Ubuntu 16.04 ESM/18.04 ESM/20.04 LTS/22.04 LTS/23.04 主机上安装的多个程序包受到 USN-6202-1 公告中提及的多个漏洞影响。

    David Korczynski 和 Adam Korczynski 发现 containerd 未能正确处理某些包含大文件的图像。攻击者可能利用该问题造成 containerd 崩溃，从而导致拒绝服务。(CVE-2023-25153)

    发现 containerd 在容器内错误设置附属组。具有容器直接访问权限的攻击者可能利用此问题获取敏感信息，或以更高权限执行代码。(CVE-2023-25173)

Tenable 已直接从 Ubuntu 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程主机上安装的 containerd 版本低于 1.6.19-1。因此，它受到 ALAS2DOCKER-2023-023 公告中提及的多个漏洞影响。

  - containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，用户可在其中耗尽主机上的内存。在 CRI 流服务器中，如果请求 TTY，则会启动一个 go 例程来处理终端大小调整事件。如果用户的进程因错误命令等原因无法启动，则 go 例程将在没有接收器的情况下等待发送，从而导致内存泄漏。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现，流服务器尅用于处理容器 IO。此错误已在 containerd 1.6.12 和 1.5.16 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的映像和命令，并且只有受信任的用户才有权限在运行中的容器中执行命令。(CVE-2022-23471)

  - containerd 是一个开源容器运行时。在 1.6.18 之前版本和 1.5.18 之前版本中，导入 OCI 镜像时，对某些文件的读取字节数没有限制。在未应用限制的情况下，恶意构建的包含大文件的镜像可导致拒绝服务。此错误已在 containerd 1.6.18 和 1.5.18 中修复。用户应更新到这些版本以解决该问题。变通方案是，确保仅使用受信任的镜像，并且只有受信任的用户才具有导入镜像的权限。
    (CVE-2023-25153)

  - containerd 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - containerd 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

因此，它受到公告 ALAS2023-2023-156 中提及的多个漏洞影响。

  - containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，用户可在其中耗尽主机上的内存。在 CRI 流服务器中，如果请求 TTY，则会启动一个 go 例程来处理终端大小调整事件。如果用户的进程因错误命令等原因无法启动，则 go 例程将在没有接收器的情况下等待发送，从而导致内存泄漏。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现，流服务器尅用于处理容器 IO。此错误已在 containerd 1.6.12 和 1.5.16 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的映像和命令，并且只有受信任的用户才有权限在运行中的容器中执行命令。(CVE-2022-23471)

  - containerd 是一个开源容器运行时。在 1.6.18 之前版本和 1.5.18 之前版本中，导入 OCI 镜像时，对某些文件的读取字节数没有限制。在未应用限制的情况下，恶意构建的包含大文件的镜像可导致拒绝服务。此错误已在 containerd 1.6.18 和 1.5.18 中修复。用户应更新到这些版本以解决该问题。变通方案是，确保仅使用受信任的镜像，并且只有受信任的用户才具有导入镜像的权限。
    (CVE-2023-25153)

  - containerd 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程主机上安装的 containerd 版本低于 1.6.19-1。因此，它受到 ALAS2ECS-2023-002 公告中提及的多个漏洞影响。

  - containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，用户可在其中耗尽主机上的内存。在 CRI 流服务器中，如果请求 TTY，则会启动一个 go 例程来处理终端大小调整事件。如果用户的进程因错误命令等原因无法启动，则 go 例程将在没有接收器的情况下等待发送，从而导致内存泄漏。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现，流服务器尅用于处理容器 IO。此错误已在 containerd 1.6.12 和 1.5.16 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的映像和命令，并且只有受信任的用户才有权限在运行中的容器中执行命令。(CVE-2022-23471)

  - containerd 是一个开源容器运行时。在 1.6.18 之前版本和 1.5.18 之前版本中，导入 OCI 镜像时，对某些文件的读取字节数没有限制。在未应用限制的情况下，恶意构建的包含大文件的镜像可导致拒绝服务。此错误已在 containerd 1.6.18 和 1.5.18 中修复。用户应更新到这些版本以解决该问题。变通方案是，确保仅使用受信任的镜像，并且只有受信任的用户才具有导入镜像的权限。
    (CVE-2023-25153)

  - containerd 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

请注意，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 进行的多部分表单解析会消耗大量不受限制的内存和磁盘文件。这也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。ReadForm 采用 maxMemory 参数，据记载其在内存中最多可存储 +10MB maxMemory 字节（为非文件部分预留）。无法存储在内存中的文件部分以临时文件的形式存储在磁盘上。为非文件部分保留的不可配置的 10MB 过大，可能会单独打开拒绝服务矢量。但是，ReadForm 没有正确考虑解析的表单消耗的所有内存，例如映射条目开销、部分名称和 MIME 标头，从而允许恶意构建的表单消耗远远超过 10MB。此外，ReadForm 对创建的磁盘文件数量没有限制，允许相对较小的请求正文创建大量磁盘临时文件。修复后，ReadForm 现在可以正确考虑各种形式的内存开销，并且现在应将开销保持在其记录的 10MB + maxMemory 字节内存消耗内。用户仍应意识到此限制较高且可能仍然存在危险。此外，ReadForm 现在至多创建一个磁盘临时文件，从而将多个表单部分合并为一个临时文件。mime/multipart.File 接口类型的文档指出，如果存储在磁盘上，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 解析的表单包含的部分不超过 1,000 个。此限制可通过环境变量 GODEBUG=multipartmaxparts= 进行调整。2. 使用 NextPart 和 NextRawPart 解析的表单部分包含的标头字段不超过 10,000 个。此外，使用 ReadForm 解析的所有表单部分包含的标头字段不超过 10,000 个。此限制可通过环境变量 GODEBUG=multipartmaxheaders= 进行调整。(CVE-2023-24536)

  - 在包含具有极大行号的 //line 指令的 Go 源代码中，调用任何 Parse 函数都有可能因整数溢出而造成无限循环。(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 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

  - 由于 HTML 规范化规则，在使用空输入执行未加引号的 HTML 属性（如 attr={{.}}）中包含操作的模板可能会导致在解析时产生意想不到的输出结果。这可能允许向标记中注入任意属性。 (CVE-2023-29400)

  - HTTP/1 客户端没有充分验证主机标头的内容。恶意构建的主机标头可以注入其他标头或整个请求。修复后，HTTP/1 客户端现在会拒绝发送包含无效 Request.Host 或 Request.URL.Host 值的请求。(CVE-2023-29406)

  - 不在 HTML 命名空间中的文本节点被错误地按字面呈现，导致应该转义的文本不存在。这会导致 XSS 攻击。(CVE-2023-3978)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Oracle Linux 8 主机上安装的程序包受到 ELSA-2023-6939 公告中提及的多个漏洞的影响。

  - 不在 HTML 命名空间中的文本节点被错误地按字面呈现，导致应该转义的文本不存在。这会导致 XSS 攻击。(CVE-2023-3978)

  - 并非所有有效的 JavaScript 空白字符都被视为空白。在 JavaScript 上下文中，在字符集 \t\n\f\r\u0020\u2028\u2029 外包含其他空白字符和操作的模板在执行期间可能未经正确审查。(CVE-2023-24540)

  - 恶意构建的 HTTP/2 流可造成 HPACK 解码器过度消耗 CPU，这足以通过少量小请求造成拒绝服务。(CVE-2022-41723)

  - 模板未正确将反引号 (`) 视为 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)

  - containerd 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

  - 1.1.4 及之前的 runc 版本含有导致权限提升的错误访问控制，此问题与 libcontainer/rootfs_linux.go 相关。要利用此问题，攻击者必须能够生成两个具有自定义 volume-mount 配置的容器，并且能够运行自定义图像。注意：存在此问题的原因是 CVE-2019-19921 回归。(CVE-2023-27561)

  - 解析恶意或大型 YAML 文档可能会消耗过多 CPU 或内存。(CVE-2022-3064)

  - 在处理包含大量部分的表单输入时，多部分表单解析可能会消耗大量 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 解析的表单包含的部分不超过 1,000 个。此限制可通过环境变量 GODEBUG=multipartmaxparts= 进行调整。2. 使用 NextPart 和 NextRawPart 解析的表单部分包含的标头字段不超过 10,000 个。此外，使用 ReadForm 解析的所有表单部分包含的标头字段不超过 10,000 个。此限制可通过环境变量 GODEBUG=multipartmaxheaders= 进行调整。(CVE-2023-24536)

  - runc 是一款用于根据 OCI 规范生成和运行容器的 CLI 工具。在受影响的版本中，无根 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)

  - HTTP/1 客户端没有充分验证主机标头的内容。恶意构建的主机标头可以注入其他标头或整个请求。修复后，HTTP/1 客户端现在会拒绝发送包含无效 Request.Host 或 Request.URL.Host 值的请求。(CVE-2023-29406)

  - 大量握手记录可能会造成 crypto/tls 错误。客户端和服务器都可能发送大型 TLS 握手记录，从而在尝试构造响应时分别造成服务器和客户端错误。这会影响所有 TLS 1.3 版客户端、明确启用会话恢复的 TLS 1.2 版客户端（通过将 Config.ClientSessionCache 设置为非 nil 值）以及请求客户端证书的 TLS 1.3 版服务器（通过设置 Config.ClientAuth >= RequestClientCert）。(CVE-2022-41724)

  - 在包含具有极大行号的 //line 指令的 Go 源代码中，调用任何 Parse 函数都有可能因整数溢出而造成无限循环。(CVE-2023-24537)

  - runc 是一款用于根据 OCI 规范生成和运行容器的 CLI 工具。据发现，当容器内的“/proc”与特定挂载配置进行符号链接时，可绕过 AppArmor。通过禁止符号链接“/proc”，此问题已在 runc 1.1.5 版中修复。详情请参阅 PR #3785。我们建议用户进行升级。无法升级的用户应避免使用不受信任的容器映像。(CVE-2023-28642)

  - 由于 HTML 规范化规则，在使用空输入执行未加引号的 HTML 属性（如 attr={{.}}）中包含操作的模板可能会导致在解析时产生意想不到的输出结果。这可能允许向标记中注入任意属性。 (CVE-2023-29400)

  - 即使在解析小型输入时，HTTP 和 MIME 标头解析也可能会分配大量内存，从而可能导致拒绝服务。输入数据的某些异常模式可导致用于解析 HTTP 和 MIME 标头的通用函数分配远超所需的内容来保存已解析的标头。攻击者可能会利用此行为，导致 HTTP 服务器通过小型请求分配大量内存，从而可能导致内存耗尽和拒绝服务。
    经修复后，标头解析现在可以正确分配所需内存来保存已解析的标头。
    (CVE-2023-24534)

  - 将尖括号 (<>) 插入到 CSS 上下文中时，不会视其为危险字符。如果使用不受信任的输入执行，包含由“/”字符分隔的多个操作的模板可能会导致意外关闭 CSS 上下文并允许意外注入 HTML。(CVE-2023-24539)

  - net/http 和 mime/multipart 中的过量资源消耗可能导致拒绝服务。
    使用 mime/multipart.Reader.ReadForm 进行的多部分表单解析会消耗大量不受限制的内存和磁盘文件。这也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。ReadForm 采用 maxMemory 参数，据记载其在内存中最多可存储 +10MB maxMemory 字节（为非文件部分预留）。无法存储在内存中的文件部分以临时文件的形式存储在磁盘上。为非文件部分保留的不可配置的 10MB 过大，可能会单独打开拒绝服务矢量。但是，ReadForm 没有正确考虑解析的表单消耗的所有内存，例如映射条目开销、部分名称和 MIME 标头，从而允许恶意构建的表单消耗远远超过 10MB。此外，ReadForm 对创建的磁盘文件数量没有限制，允许相对较小的请求正文创建大量磁盘临时文件。修复后，ReadForm 现在可以正确考虑各种形式的内存开销，并且现在应将开销保持在其记录的 10MB + maxMemory 字节内存消耗内。用户仍应意识到此限制较高且可能仍然存在危险。此外，ReadForm 现在至多创建一个磁盘临时文件，从而将多个表单部分合并为一个临时文件。mime/multipart.File 接口类型的文档指出，如果存储在磁盘上，File 的底层具体类型将为 *os.File.。当表单包含多个文件部分时，情况不再如此，这是因为将多个文件部分合并为一个文件所致。可通过环境变量 GODEBUG=multipartfiles=distinct 重新启用之前对每个表单部分使用不同文件的行为。用户应注意，multipart.ReadForm 和调用它的 http.Request 方法不会限制临时文件消耗的磁盘数量。调用方可使用 http.MaxBytesReader 限制表单数据的大小。(CVE-2022-41725)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Redhat Enterprise Linux 9 主机上安装的程序包受到 RHSA-2023: 6473 公告中提及的多个漏洞影响。

  - 恶意构建的 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 进行的多部分表单解析会消耗大量不受限制的内存和磁盘文件。这也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。ReadForm 采用 maxMemory 参数，据记载其在内存中最多可存储 +10MB maxMemory 字节（为非文件部分预留）。无法存储在内存中的文件部分以临时文件的形式存储在磁盘上。为非文件部分保留的不可配置的 10MB 过大，可能会单独打开拒绝服务矢量。但是，ReadForm 没有正确考虑解析的表单消耗的所有内存，例如映射条目开销、部分名称和 MIME 标头，从而允许恶意构建的表单消耗远远超过 10MB。此外，ReadForm 对创建的磁盘文件数量没有限制，允许相对较小的请求正文创建大量磁盘临时文件。修复后，ReadForm 现在可以正确考虑各种形式的内存开销，并且现在应将开销保持在其记录的 10MB + maxMemory 字节内存消耗内。用户仍应意识到此限制较高且可能仍然存在危险。此外，ReadForm 现在至多创建一个磁盘临时文件，从而将多个表单部分合并为一个临时文件。mime/multipart.File 接口类型的文档指出，如果存储在磁盘上，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 解析的表单包含的部分不超过 1,000 个。此限制可通过环境变量 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 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

  - 由于 HTML 规范化规则，在使用空输入执行未加引号的 HTML 属性（如 attr={{.}}）中包含操作的模板可能会导致在解析时产生意想不到的输出结果。这可能允许向标记中注入任意属性。 (CVE-2023-29400)

  - HTTP/1 客户端没有充分验证主机标头的内容。恶意构建的主机标头可以注入其他标头或整个请求。修复后，HTTP/1 客户端现在会拒绝发送包含无效 Request.Host 或 Request.URL.Host 值的请求。(CVE-2023-29406)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Oracle Linux 9 主机上安装的程序包受到 ELSA-2023-6473 公告中提及的多个漏洞的影响。

  - 恶意构建的 HTTP/2 流可造成 HPACK 解码器过度消耗 CPU，这足以通过少量小请求造成拒绝服务。(CVE-2022-41723)

  - 即使在解析小型输入时，HTTP 和 MIME 标头解析也可能会分配大量内存，从而可能导致拒绝服务。输入数据的某些异常模式可导致用于解析 HTTP 和 MIME 标头的通用函数分配远超所需的内容来保存已解析的标头。攻击者可能会利用此行为，导致 HTTP 服务器通过小型请求分配大量内存，从而可能导致内存耗尽和拒绝服务。
    经修复后，标头解析现在可以正确分配所需内存来保存已解析的标头。
    (CVE-2023-24534)

  - net/http 和 mime/multipart 中的过量资源消耗可能导致拒绝服务。
    使用 mime/multipart.Reader.ReadForm 进行的多部分表单解析会消耗大量不受限制的内存和磁盘文件。这也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。ReadForm 采用 maxMemory 参数，据记载其在内存中最多可存储 +10MB maxMemory 字节（为非文件部分预留）。无法存储在内存中的文件部分以临时文件的形式存储在磁盘上。为非文件部分保留的不可配置的 10MB 过大，可能会单独打开拒绝服务矢量。但是，ReadForm 没有正确考虑解析的表单消耗的所有内存，例如映射条目开销、部分名称和 MIME 标头，从而允许恶意构建的表单消耗远远超过 10MB。此外，ReadForm 对创建的磁盘文件数量没有限制，允许相对较小的请求正文创建大量磁盘临时文件。修复后，ReadForm 现在可以正确考虑各种形式的内存开销，并且现在应将开销保持在其记录的 10MB + maxMemory 字节内存消耗内。用户仍应意识到此限制较高且可能仍然存在危险。此外，ReadForm 现在至多创建一个磁盘临时文件，从而将多个表单部分合并为一个临时文件。mime/multipart.File 接口类型的文档指出，如果存储在磁盘上，File 的底层具体类型将为 *os.File.。当表单包含多个文件部分时，情况不再如此，这是因为将多个文件部分合并为一个文件所致。可通过环境变量 GODEBUG=multipartfiles=distinct 重新启用之前对每个表单部分使用不同文件的行为。用户应注意，multipart.ReadForm 和调用它的 http.Request 方法不会限制临时文件消耗的磁盘数量。调用方可使用 http.MaxBytesReader 限制表单数据的大小。(CVE-2022-41725)

  - 在处理包含大量部分的表单输入时，多部分表单解析可能会消耗大量 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 解析的表单包含的部分不超过 1,000 个。此限制可通过环境变量 GODEBUG=multipartmaxparts= 进行调整。2. 使用 NextPart 和 NextRawPart 解析的表单部分包含的标头字段不超过 10,000 个。此外，使用 ReadForm 解析的所有表单部分包含的标头字段不超过 10,000 个。此限制可通过环境变量 GODEBUG=multipartmaxheaders= 进行调整。(CVE-2023-24536)

  - containerd 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

  - 由于 HTML 规范化规则，在使用空输入执行未加引号的 HTML 属性（如 attr={{.}}）中包含操作的模板可能会导致在解析时产生意想不到的输出结果。这可能允许向标记中注入任意属性。 (CVE-2023-29400)

  - HTTP/1 客户端没有充分验证主机标头的内容。恶意构建的主机标头可以注入其他标头或整个请求。修复后，HTTP/1 客户端现在会拒绝发送包含无效 Request.Host 或 Request.URL.Host 值的请求。(CVE-2023-29406)

  - 并非所有有效的 JavaScript 空白字符都被视为空白。在 JavaScript 上下文中，在字符集 \t\n\f\r\u0020\u2028\u2029 外包含其他空白字符和操作的模板在执行期间可能未经正确审查。(CVE-2023-24540)

  - 将尖括号 (<>) 插入到 CSS 上下文中时，不会视其为危险字符。如果使用不受信任的输入执行，包含由“/”字符分隔的多个操作的模板可能会导致意外关闭 CSS 上下文并允许意外注入 HTML。(CVE-2023-24539)

  - 模板未正确将反引号 (`) 视为 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)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Redhat Enterprise Linux 8 主机上安装的一个程序包受到 RHSA-2023:3450 公告中提及的多个漏洞影响。

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

  - containerd：未正确设置附属组 (CVE-2023-25173)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程主机受到 GLSA-202408-01 中所述漏洞影响（containerd：多个漏洞）

    在 containerd 中发现多个漏洞。请检查下方引用的 CVE 标识符以了解详细信息。

Tenable 已直接从 Gentoo Linux 安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程主机上安装的 containerd 版本低于 1.6.19-1。因此，该 docker 受到 ALAS2NITRO-ENCLAVES-2023-023 公告中提及的多个漏洞的影响。

  - containerd 是一个开源容器运行时。在 containerd 的 CRI 实现中发现一个缺陷，用户可在其中耗尽主机上的内存。在 CRI 流服务器中，如果请求 TTY，则会启动一个 go 例程来处理终端大小调整事件。如果用户的进程因错误命令等原因无法启动，则 go 例程将在没有接收器的情况下等待发送，从而导致内存泄漏。
    Kubernetes 和 crictl 均可配置为使用 containerd 的 CRI 实现，流服务器尅用于处理容器 IO。此错误已在 containerd 1.6.12 和 1.5.16 中修复。用户应更新到这些版本以解决该问题。无法升级的用户应确保仅使用受信任的映像和命令，并且只有受信任的用户才有权限在运行中的容器中执行命令。(CVE-2022-23471)

  - containerd 是一个开源容器运行时。在 1.6.18 之前版本和 1.5.18 之前版本中，导入 OCI 镜像时，对某些文件的读取字节数没有限制。在未应用限制的情况下，恶意构建的包含大文件的镜像可导致拒绝服务。此错误已在 containerd 1.6.18 和 1.5.18 中修复。用户应更新到这些版本以解决该问题。变通方案是，确保仅使用受信任的镜像，并且只有受信任的用户才具有导入镜像的权限。
    (CVE-2023-25153)

  - containerd 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Redhat Enterprise Linux 8 主机上安装的程序包受到 RHSA-2023：6939 公告提及的多个漏洞的影响。

  - 解析恶意或大型 YAML 文档可能会消耗过多 CPU 或内存。(CVE-2022-3064)

  - 恶意构建的 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 进行的多部分表单解析会消耗大量不受限制的内存和磁盘文件。这也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。ReadForm 采用 maxMemory 参数，据记载其在内存中最多可存储 +10MB maxMemory 字节（为非文件部分预留）。无法存储在内存中的文件部分以临时文件的形式存储在磁盘上。为非文件部分保留的不可配置的 10MB 过大，可能会单独打开拒绝服务矢量。但是，ReadForm 没有正确考虑解析的表单消耗的所有内存，例如映射条目开销、部分名称和 MIME 标头，从而允许恶意构建的表单消耗远远超过 10MB。此外，ReadForm 对创建的磁盘文件数量没有限制，允许相对较小的请求正文创建大量磁盘临时文件。修复后，ReadForm 现在可以正确考虑各种形式的内存开销，并且现在应将开销保持在其记录的 10MB + maxMemory 字节内存消耗内。用户仍应意识到此限制较高且可能仍然存在危险。此外，ReadForm 现在至多创建一个磁盘临时文件，从而将多个表单部分合并为一个临时文件。mime/multipart.File 接口类型的文档指出，如果存储在磁盘上，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 解析的表单包含的部分不超过 1,000 个。此限制可通过环境变量 GODEBUG=multipartmaxparts= 进行调整。2. 使用 NextPart 和 NextRawPart 解析的表单部分包含的标头字段不超过 10,000 个。此外，使用 ReadForm 解析的所有表单部分包含的标头字段不超过 10,000 个。此限制可通过环境变量 GODEBUG=multipartmaxheaders= 进行调整。(CVE-2023-24536)

  - 在包含具有极大行号的 //line 指令的 Go 源代码中，调用任何 Parse 函数都有可能因整数溢出而造成无限循环。(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 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

  - runc 是一款用于根据 OCI 规范生成和运行容器的 CLI 工具。在受影响的版本中，无根 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)

  - 1.1.4 及之前的 runc 版本含有导致权限提升的错误访问控制，此问题与 libcontainer/rootfs_linux.go 相关。要利用此问题，攻击者必须能够生成两个具有自定义 volume-mount 配置的容器，并且能够运行自定义图像。注意：存在此问题的原因是 CVE-2019-19921 回归。(CVE-2023-27561)

  - runc 是一款用于根据 OCI 规范生成和运行容器的 CLI 工具。据发现，当容器内的“/proc”与特定挂载配置进行符号链接时，可绕过 AppArmor。通过禁止符号链接“/proc”，此问题已在 runc 1.1.5 版中修复。详情请参阅 PR #3785。我们建议用户进行升级。无法升级的用户应避免使用不受信任的容器映像。(CVE-2023-28642)

  - 由于 HTML 规范化规则，在使用空输入执行未加引号的 HTML 属性（如 attr={{.}}）中包含操作的模板可能会导致在解析时产生意想不到的输出结果。这可能允许向标记中注入任意属性。 (CVE-2023-29400)

  - HTTP/1 客户端没有充分验证主机标头的内容。恶意构建的主机标头可以注入其他标头或整个请求。修复后，HTTP/1 客户端现在会拒绝发送包含无效 Request.Host 或 Request.URL.Host 值的请求。(CVE-2023-29406)

  - 不在 HTML 命名空间中的文本节点被错误地按字面呈现，导致应该转义的文本不存在。这会导致 XSS 攻击。(CVE-2023-3978)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 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 进行的多部分表单解析会消耗大量不受限制的内存和磁盘文件。这也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。ReadForm 采用 maxMemory 参数，据记载其在内存中最多可存储 +10MB maxMemory 字节（为非文件部分预留）。无法存储在内存中的文件部分以临时文件的形式存储在磁盘上。为非文件部分保留的不可配置的 10MB 过大，可能会单独打开拒绝服务矢量。但是，ReadForm 没有正确考虑解析的表单消耗的所有内存，例如映射条目开销、部分名称和 MIME 标头，从而允许恶意构建的表单消耗远远超过 10MB。此外，ReadForm 对创建的磁盘文件数量没有限制，允许相对较小的请求正文创建大量磁盘临时文件。修复后，ReadForm 现在可以正确考虑各种形式的内存开销，并且现在应将开销保持在其记录的 10MB + maxMemory 字节内存消耗内。用户仍应意识到此限制较高且可能仍然存在危险。此外，ReadForm 现在至多创建一个磁盘临时文件，从而将多个表单部分合并为一个临时文件。mime/multipart.File 接口类型的文档指出，如果存储在磁盘上，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 限制了已解析的 multipart 表单可以使用的总内存。ReadForm 可能会低估所消耗的内存量，导致它接受的输入大于预期。2. 限制总内存的做法并未考虑到包含多个部分的表单中的大量小型分配给垃圾回收器增加的压力。3.
    ReadForm 可以分配大量短效缓冲区，这会进一步加大对垃圾回收器造成的压力。这些因素相结合，攻击者便可让解析多部分表单的程序消耗大量 CPU 和内存，从而可能导致拒绝服务。
    这会影响使用 mime/multipart.Reader.ReadForm 的程序，也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。经修复后，ReadForm 现在可以更好地估算已解析表单的内存消耗量，并大幅减少短效分配。此外，经修正的 mime/multipart.Reader 会对已解析表单的大小施加以下限制：1. 使用 ReadForm 解析的表单可能包含不超过 1,000 个部分。此限制可通过环境变量 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 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

  - 由于 HTML 规范化规则，在使用空输入执行未加引号的 HTML 属性（如 attr={{.}}）中包含操作的模板可能会导致在解析时产生意想不到的输出结果。这可能允许向标记中注入任意属性。 (CVE-2023-29400)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 CentOS Linux 9 主机上安装的多个程序包受到 podman-4.6.0-0.3.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 进行的多部分表单解析会消耗大量不受限制的内存和磁盘文件。这也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。ReadForm 采用 maxMemory 参数，据记载其在内存中最多可存储 +10MB maxMemory 字节（为非文件部分预留）。无法存储在内存中的文件部分以临时文件的形式存储在磁盘上。为非文件部分保留的不可配置的 10MB 过大，可能会单独打开拒绝服务矢量。但是，ReadForm 没有正确考虑解析的表单消耗的所有内存，例如映射条目开销、部分名称和 MIME 标头，从而允许恶意构建的表单消耗远远超过 10MB。此外，ReadForm 对创建的磁盘文件数量没有限制，允许相对较小的请求正文创建大量磁盘临时文件。修复后，ReadForm 现在可以正确考虑各种形式的内存开销，并且现在应将开销保持在其记录的 10MB + maxMemory 字节内存消耗内。用户仍应意识到此限制较高且可能仍然存在危险。此外，ReadForm 现在至多创建一个磁盘临时文件，从而将多个表单部分合并为一个临时文件。mime/multipart.File 接口类型的文档指出，如果存储在磁盘上，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 限制了已解析的 multipart 表单可以使用的总内存。ReadForm 可能会低估所消耗的内存量，导致它接受的输入大于预期。2. 限制总内存的做法并未考虑到包含多个部分的表单中的大量小型分配给垃圾回收器增加的压力。3.
    ReadForm 可以分配大量短效缓冲区，这会进一步加大对垃圾回收器造成的压力。这些因素相结合，攻击者便可让解析多部分表单的程序消耗大量 CPU 和内存，从而可能导致拒绝服务。
    这会影响使用 mime/multipart.Reader.ReadForm 的程序，也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。经修复后，ReadForm 现在可以更好地估算已解析表单的内存消耗量，并大幅减少短效分配。此外，经修正的 mime/multipart.Reader 会对已解析表单的大小施加以下限制：1. 使用 ReadForm 解析的表单可能包含不超过 1,000 个部分。此限制可通过环境变量 GODEBUG=multipartmaxparts= 进行调整。2. 使用 NextPart 和 NextRawPart 解析的表单部分包含的标头字段不超过 10,000 个。此外，使用 ReadForm 解析的所有表单部分包含的标头字段不超过 10,000 个。此限制可通过环境变量 GODEBUG=multipartmaxheaders= 进行调整。(CVE-2023-24536)

  - 在包含具有极大行号的 //line 指令的 Go 源代码中，调用任何 Parse 函数都有可能因整数溢出而造成无限循环。(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 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

  - 由于 HTML 规范化规则，在使用空输入执行未加引号的 HTML 属性（如 attr={{.}}）中包含操作的模板可能会导致在解析时产生意想不到的输出结果。这可能允许向标记中注入任意属性。 (CVE-2023-29400)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

远程 Oracle Linux 9 主机上安装的程序包受到 ELSA-2023-6474 公告中提及的多个漏洞的影响。

  - net/http 和 mime/multipart 中的过量资源消耗可能导致拒绝服务。
    使用 mime/multipart.Reader.ReadForm 进行的多部分表单解析会消耗大量不受限制的内存和磁盘文件。这也会影响使用 Request 方法 FormFile、FormValue、ParseMultipartForm 和 PostFormValue 在 net/http 程序包中进行的表单解析。ReadForm 采用 maxMemory 参数，据记载其在内存中最多可存储 +10MB maxMemory 字节（为非文件部分预留）。无法存储在内存中的文件部分以临时文件的形式存储在磁盘上。为非文件部分保留的不可配置的 10MB 过大，可能会单独打开拒绝服务矢量。但是，ReadForm 没有正确考虑解析的表单消耗的所有内存，例如映射条目开销、部分名称和 MIME 标头，从而允许恶意构建的表单消耗远远超过 10MB。此外，ReadForm 对创建的磁盘文件数量没有限制，允许相对较小的请求正文创建大量磁盘临时文件。修复后，ReadForm 现在可以正确考虑各种形式的内存开销，并且现在应将开销保持在其记录的 10MB + maxMemory 字节内存消耗内。用户仍应意识到此限制较高且可能仍然存在危险。此外，ReadForm 现在至多创建一个磁盘临时文件，从而将多个表单部分合并为一个临时文件。mime/multipart.File 接口类型的文档指出，如果存储在磁盘上，File 的底层具体类型将为 *os.File.。当表单包含多个文件部分时，情况不再如此，这是因为将多个文件部分合并为一个文件所致。可通过环境变量 GODEBUG=multipartfiles=distinct 重新启用之前对每个表单部分使用不同文件的行为。用户应注意，multipart.ReadForm 和调用它的 http.Request 方法不会限制临时文件消耗的磁盘数量。调用方可使用 http.MaxBytesReader 限制表单数据的大小。(CVE-2022-41725)

  - 恶意构建的 HTTP/2 流可造成 HPACK 解码器过度消耗 CPU，这足以通过少量小请求造成拒绝服务。(CVE-2022-41723)

  - 由于 HTML 规范化规则，在使用空输入执行未加引号的 HTML 属性（如 attr={{.}}）中包含操作的模板可能会导致在解析时产生意想不到的输出结果。这可能允许向标记中注入任意属性。 (CVE-2023-29400)

  - 即使在解析小型输入时，HTTP 和 MIME 标头解析也可能会分配大量内存，从而可能导致拒绝服务。输入数据的某些异常模式可导致用于解析 HTTP 和 MIME 标头的通用函数分配远超所需的内容来保存已解析的标头。攻击者可能会利用此行为，导致 HTTP 服务器通过小型请求分配大量内存，从而可能导致内存耗尽和拒绝服务。
    经修复后，标头解析现在可以正确分配所需内存来保存已解析的标头。
    (CVE-2023-24534)

  - 将尖括号 (<>) 插入到 CSS 上下文中时，不会视其为危险字符。如果使用不受信任的输入执行，包含由“/”字符分隔的多个操作的模板可能会导致意外关闭 CSS 上下文并允许意外注入 HTML。(CVE-2023-24539)

  - 不在 HTML 命名空间中的文本节点被错误地按字面呈现，导致应该转义的文本不存在。这会导致 XSS 攻击。(CVE-2023-3978)

  - 在处理包含大量部分的表单输入时，多部分表单解析可能会消耗大量 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 解析的表单包含的部分不超过 1,000 个。此限制可通过环境变量 GODEBUG=multipartmaxparts= 进行调整。2. 使用 NextPart 和 NextRawPart 解析的表单部分包含的标头字段不超过 10,000 个。此外，使用 ReadForm 解析的所有表单部分包含的标头字段不超过 10,000 个。此限制可通过环境变量 GODEBUG=multipartmaxheaders= 进行调整。(CVE-2023-24536)

  - 在包含具有极大行号的 //line 指令的 Go 源代码中，调用任何 Parse 函数都有可能因整数溢出而造成无限循环。(CVE-2023-24537)

  - 并非所有有效的 JavaScript 空白字符都被视为空白。在 JavaScript 上下文中，在字符集 \t\n\f\r\u0020\u2028\u2029 外包含其他空白字符和操作的模板在执行期间可能未经正确审查。(CVE-2023-24540)

  - containerd 是一个开源容器运行时。在低于 1.6.18 和 1.5.18 版的 containerd 中发现一个缺陷，容器内的附属组设置不正确。如果攻击者拥有对容器的直接访问权限并能操纵其附属群组访问权限，则在某些情况下，他们可能会使用附属群组访问权限绕过主要群组限制，从而可能获得对敏感信息的访问权限或在该容器中执行代码的能力。 使用 containerd 客户端库的下游应用程序也可能受到影响。已在 containerd v1.6.18 和 v.1.5.18 中修复此错误。用户应更新到这些版本并重新创建容器以解决该问题。
    用户如果依赖使用 containerd 客户端库的下游应用程序，应检查该应用程序是否有单独的公告和说明。变通方案是，确保不使用 `USER $USERNAME` Dockerfile 指令，将容器入口点设置为类似于“ENTRYPOINT [su, -, user]”的值，以允许“su”正确设置附属组。(CVE-2023-25173)

  - 大量握手记录可能会造成 crypto/tls 错误。客户端和服务器都可能发送大型 TLS 握手记录，从而在尝试构造响应时分别造成服务器和客户端错误。这会影响所有 TLS 1.3 版客户端、明确启用会话恢复的 TLS 1.2 版客户端（通过将 Config.ClientSessionCache 设置为非 nil 值）以及请求客户端证书的 TLS 1.3 版服务器（通过设置 Config.ClientAuth >= RequestClientCert）。(CVE-2022-41724)

  - 模板未正确将反引号 (`) 视为 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)

  - HTTP/1 客户端没有充分验证主机标头的内容。恶意构建的主机标头可以注入其他标头或整个请求。修复后，HTTP/1 客户端现在会拒绝发送包含无效 Request.Host 或 Request.URL.Host 值的请求。(CVE-2023-29406)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
178000	Ubuntu 16.04 ESM / 18.04 ESM / 20.04 LTS / 22.04 LTS / 23.04：containerd 漏洞 (USN-6202-1)	Nessus	Ubuntu Local Security Checks	2023/7/5	2025/5/12	high
173939	Amazon Linux 2：containerd (ALASDOCKER-2023-023)	Nessus	Amazon Linux Local Security Checks	2023/4/6	2025/5/12	high
226144	Linux Distros 未修补的漏洞: CVE-2023-25173	Nessus	Misc.	2025/3/5	2025/9/10	high
173839	Amazon Linux 2023：containerd、containerd-stress (ALAS2023-2023-156)	Nessus	Amazon Linux Local Security Checks	2023/4/4	2025/5/12	high
178287	Amazon Linux 2：containerd (ALASECS-2023-002)	Nessus	Amazon Linux Local Security Checks	2023/7/14	2025/5/12	high
185115	RHEL 9：podman (RHSA-2023: 6474)	Nessus	Red Hat Local Security Checks	2023/11/7	2025/3/6	critical
186122	Oracle Linux 8：container-tools: ol8 (ELSA-2023-6939)	Nessus	Oracle Linux Local Security Checks	2023/11/21	2025/9/9	critical
185132	RHEL 9：buildah (RHSA-2023: 6473)	Nessus	Red Hat Local Security Checks	2023/11/7	2025/3/6	critical
185848	Oracle Linux 9：buildah (ELSA-2023-6473)	Nessus	Oracle Linux Local Security Checks	2023/11/16	2025/9/9	critical
194254	RHEL 8：OpenShift Serverless Client kn 1.29.0（中等）(RHSA-2023:3450)	Nessus	Red Hat Local Security Checks	2024/4/28	2024/11/7	critical
205524	GLSA-202408-01：containerd：多个漏洞	Nessus	Gentoo Local Security Checks	2024/8/14	2024/8/14	high
173937	Amazon Linux 2：containerd (ALASNITRO-ENCLAVES-2023-023)	Nessus	Amazon Linux Local Security Checks	2023/4/6	2025/5/12	high
185675	RHEL 8：container-tools: rhel8 (RHSA-2023: 6939)	Nessus	Red Hat Local Security Checks	2023/11/14	2025/3/6	critical
191201	CentOS 9：buildah-1.30.0-2.el9	Nessus	CentOS Local Security Checks	2024/2/29	2024/4/26	critical
191372	CentOS 9：podman-4.6.0-0.3.el9	Nessus	CentOS Local Security Checks	2024/2/29	2024/4/26	critical
185829	Oracle Linux 9：podman (ELSA-2023-6474)	Nessus	Oracle Linux Local Security Checks	2023/11/16	2025/9/9	critical

检测

插件搜索

high

high

high

high

high

critical

critical

critical

critical

critical

high

high

critical

critical

critical

critical