安全流程

为了保护我们的社区，在我们的调查完成且任何必要的更新普遍可用之前， 不会披露、讨论或确认安全问题。

最近的安全更新列在下方的安全更新章节中。

安全文档在可能的情况下会通过 CVE-ID 引用漏洞。

报告安全或隐私漏洞

如果您认为您在 项目中发现了安全或隐私漏洞，请向我们报告。我们欢迎来自所有人的报告，包括安全研究人员、开发者和用户。

要报告安全或隐私漏洞，请发送电子邮件至 cve@forums.swift.org，其中包含

• 您认为受到影响的特定项目和软件版本。
• 您观察到的行为以及您期望的行为的描述。
• 重现问题所需的步骤的编号列表，和/或视频演示（如果步骤可能难以遵循）。

请使用 的 CVE PGP 密钥 来加密您通过电子邮件发送的敏感信息。

您将收到来自 的电子邮件回复，以确认我们收到了您的报告，如果我们需要更多信息，我们将与您联系。

如何处理这些报告

为了保护我们的社区，在我们的调查完成且任何必要的更新普遍可用之前， 不会披露、讨论或确认安全问题。

使用安全公告和我们的 security-announce 邮件列表来发布有关我们项目中安全修复的信息，并公开感谢向我们报告安全问题的人员或组织。

安全更新

• CVE-2020-9861

  Linux 版 Swift 中存在堆栈溢出问题。该问题已通过改进输入验证来处理深度嵌套的恶意 JSON 输入得到解决。

• CVE-2022-24666

  使用 swift-nio-http2 的程序容易受到拒绝服务攻击，这是由网络对等方发送特制的 HTTP/2 帧引起的。此攻击影响从 1.0.0 到 1.19.1 的所有 swift-nio-http2 版本。此漏洞是由解析 HTTP/2 HEADERS 帧时的逻辑错误引起的，其中帧包含优先级信息但没有任何其他数据。此逻辑错误导致了对帧大小的混淆，从而导致解析错误。此解析错误会立即导致整个进程崩溃。发送带有 HTTP/2 优先级信息的 HEADERS 帧不需要任何特殊权限，因此任何 HTTP/2 连接对等方都可以发送此类帧。对于客户端，这意味着他们连接的任何服务器都可能发起此攻击。对于服务器，他们允许连接的任何人都可以发起此类攻击。该攻击的成本很低：发送一个经过适当构造的帧只需极少的资源。对可用性的影响很高：接收到帧会立即导致服务器崩溃，断开所有正在进行的连接并导致服务需要重新启动。攻击者可以轻松地重复发送经过适当构造的帧，因此攻击者只需极少的资源即可实现大量的拒绝服务。攻击本身没有任何机密性或完整性风险：swift-nio-http2 正在内存安全代码中解析帧，因此崩溃是安全的。但是，突然的进程崩溃可能会导致服务中的不变量受到破坏，因此此攻击可能被用于触发具有机密性或完整性风险的错误情况。如果可以阻止不受信任的对等方与服务通信，则可以缓解此风险。许多服务都无法进行这种缓解。该问题已通过重写解析代码以正确处理这种情况来修复。该问题是由 oss-fuzz 的自动化模糊测试发现的。

• CVE-2022-24667

  使用 swift-nio-http2 的程序容易受到拒绝服务攻击，这是由网络对等方发送特制的 HPACK 编码的标头块引起的。此攻击影响从 1.0.0 到 1.19.1 的所有 swift-nio-http2 版本。在 HPACK 编码的标头块的解析中存在许多实现错误，这些错误允许恶意构造的 HPACK 标头块导致使用 swift-nio-http2 的进程崩溃。每个崩溃都是代替整数溢出而触发的。恶意的 HPACK 标头块可以在 HTTP/2 连接中的任何 HPACK 携带帧（HEADERS 和 PUSH_PROMISE）上发送，在任何位置都可以。发送 HPACK 标头块不需要任何特殊权限，因此任何 HTTP/2 连接对等方都可以发送一个。对于客户端，这意味着他们连接的任何服务器都可能发起此攻击。对于服务器，他们允许连接的任何人都可以发起此类攻击。该攻击的成本很低：发送一个经过适当构造的字段块只需极少的资源。对可用性的影响很高：接收到携带此字段块的帧会立即导致服务器崩溃，断开所有正在进行的连接并导致服务需要重新启动。攻击者可以轻松地重复发送经过适当构造的字段块，因此攻击者只需极少的资源即可实现大量的拒绝服务。攻击本身没有任何机密性或完整性风险：swift-nio-http2 正在内存安全代码中解析字段块，并且崩溃是代替整数溢出而触发的。但是，突然的进程崩溃可能会导致服务中的不变量受到破坏，因此此攻击可能被用于触发具有机密性或完整性风险的错误情况。如果可以阻止不受信任的对等方与服务通信，则可以缓解此风险。许多服务都无法进行这种缓解。该问题已通过重写解析代码以正确处理函数中的所有条件来修复。主要问题是由 oss-fuzz 的自动化模糊测试发现的，但代码审核发现了同一代码中的几个相关错误，并同时修复了。

• CVE-2022-24668

  使用 swift-nio-http2 的程序容易受到拒绝服务攻击，这是由网络对等方发送 ALTSVC 或 ORIGIN 帧引起的。此攻击影响从 1.0.0 到 1.19.1 的所有 swift-nio-http2 版本。此漏洞是由帧解析后但在帧处理之前的逻辑错误引起的。swift-nio-http2 当前不支持 ORIGIN 和 ALTSVC 帧，应忽略它们。但是，遇到它们的某个代码路径却有一个故意的陷阱。这是从最初的开发过程中遗留下来的，并且从未删除。发送 ALTSVC 或 ORIGIN 帧不需要任何特殊权限，因此任何 HTTP/2 连接对等方都可以发送此类帧。对于客户端，这意味着他们连接的任何服务器都可能发起此攻击。对于服务器，他们允许连接的任何人都可以发起此类攻击。该攻击的成本很低：发送这些帧之一只需极少的资源。对可用性的影响很高：接收到帧会立即导致服务器崩溃，断开所有正在进行的连接并导致服务需要重新启动。攻击者可以轻松地重复发送这些帧，因此攻击者只需极少的资源即可实现大量的拒绝服务。攻击本身没有任何机密性或完整性风险。这是一个受控的、故意的崩溃。但是，突然的进程崩溃可能会导致服务中的不变量受到破坏，因此此攻击可能被用于触发具有机密性或完整性风险的错误情况。如果可以阻止不受信任的对等方与服务通信，则可以缓解此风险。许多服务都无法进行这种缓解。该问题已通过重写解析代码以正确处理这种情况来修复。该问题是由 oss-fuzz 的自动化模糊测试发现的。

• CVE-2022-0618

  使用 swift-nio-http2 的程序容易受到拒绝服务攻击，这是由网络对等方发送特制的 HTTP/2 帧引起的。此漏洞是由解析 HTTP/2 HEADERS 或 HTTP/2 PUSH_PROMISE 帧时的逻辑错误引起的，其中帧包含填充信息但没有任何其他数据。此逻辑错误导致了对帧大小的混淆，从而导致解析错误。此解析错误会立即导致整个进程崩溃。发送带有 HTTP/2 填充信息的 HEADERS 帧或 PUSH_PROMISE 帧不需要任何特殊权限，因此任何 HTTP/2 连接对等方都可以发送此类帧。对于客户端，这意味着他们连接的任何服务器都可能发起此攻击。对于服务器，他们允许连接的任何人都可以发起此类攻击。该攻击的成本很低：发送一个经过适当构造的帧只需极少的资源。对可用性的影响很高：接收到帧会立即导致服务器崩溃，断开所有正在进行的连接并导致服务需要重新启动。攻击者可以轻松地重复发送经过适当构造的帧，因此攻击者只需极少的资源即可实现大量的拒绝服务。攻击本身没有任何机密性或完整性风险：swift-nio-http2 正在内存安全代码中解析帧，因此崩溃是安全的。但是，突然的进程崩溃可能会导致服务中的不变量受到破坏，因此此攻击可能被用于触发具有机密性或完整性风险的错误情况。如果可以阻止不受信任的对等方与服务通信，则可以缓解此风险。许多服务都无法进行这种缓解。该问题已通过重写解析代码以正确处理这种情况来修复。该问题是由 oss-fuzz 的自动化模糊测试发现的。

• CVE-2022-1642

  使用 swift-corelibs-foundation 的程序容易受到拒绝服务攻击，这是由潜在的恶意源产生包含类型不匹配的 JSON 文档引起的。此漏洞是由 Swift 标准库提供的反序列化机制 Codable 协议；以及 swift-corelibs-foundation 提供的 JSONDecoder 类之间的交互引起的，JSONDecoder 类可以基于提供的 JSON 文档的内容反序列化采用 Codable 协议的类型。当采用 Codable 的类型请求使用整数值初始化字段时，JSONDecoder 类使用具有不同访问器方法的类型擦除容器来尝试并强制转换相应的 JSON 值并生成整数。如果 JSON 值是带有浮点部分的数字字面量，则 JSONDecoder 在验证期间使用的类型擦除方法与在最终转换值期间使用的方法不同。由于这种不匹配，检查的转换会产生确定性的崩溃。JSONDecoder 类通常被流行的基于 Swift 的 Web 框架包装，以解析 HTTP 请求的主体并执行基本类型验证。这使得攻击的成本很低：在对这些端点的请求期间发送专门构造的 JSON 文档将导致它们崩溃。攻击本身没有任何机密性或完整性风险；崩溃是由中止函数确定性地产生的，该函数确保在面对这种假设违反时执行不会继续。但是，意外的崩溃可能会导致服务中的不变量受到破坏，因此此攻击可能被用于触发升级风险的错误情况。产生拒绝服务也可能是攻击者本身的目标。此问题在适用于 Linux 和 Windows 的 Swift 5.6.2 中已解决。此问题已通过确保在验证和转换期间都调用相同的方法来解决，从而不会发生类型不匹配。适用于 Linux 和 Windows 版本的 Swift 在 ABI 方面不可互换。要升级服务，其所有者必须更新到此版本的 Swift 工具链，然后重新编译并重新部署其软件。新版本的 Swift 包括更新的 swift-corelibs-foundation 包。在基于 Darwin 的操作系统上运行的 Swift 版本不受影响。

• CVE-2022-3215

  NIOHTTP1 和使用它生成 HTTP 响应的项目可能会受到 HTTP 响应注入攻击。当 HTTP/1.1 服务器接受来自传入请求的用户生成输入并以某种形式将其反映到 HTTP/1.1 响应标头中时，就会发生这种情况。恶意用户可以在其输入中添加换行符（通常以编码形式），并将这些换行符“注入”到返回的 HTTP 响应中。此功能允许用户通过注入完全错误的响应或其他新标头来绕过安全标头和 HTTP/1.1 框架标头。注入的错误响应也可能被视为对后续请求的响应，这可能会导致 XSS、缓存中毒和许多其他缺陷。此问题已通过向 HTTPHeaders 类型添加验证来解决，确保用户提供的 HTTP 标头中没有错误地存在的空格。由于现有的 API 表面是非故障的，因此所有无效字符都将替换为线性空格。

• CVE-2022-3252

  不正确的完整 HTTP body 解压缩检测 SwiftNIO Extras 提供了一对助手，用于透明地解压缩接收到的 HTTP 请求或响应 body。这两个对象（HTTPRequestDecompressor 和 HTTPResponseDecompressor）都无法检测到何时认为解压缩后的 body 已完成。如果尾部垃圾数据附加到 HTTP 消息 body，则代码会重复尝试解压缩此数据并失败。这将导致无限循环，无法向前进行，从而导致系统死锁和拒绝服务。任何能够发送压缩 HTTP 消息的攻击者都可能触发此问题。最常见的情况是 HTTP 服务器，因为压缩 HTTP 消息无法为 HTTP 请求协商，但用户也可能已配置 HTTP 请求的解压缩。该攻击的成本很低，并且很可能在不需要任何特权或系统访问的情况下就能达到。对可用性的影响很高：进程立即变得不可用，但不会立即崩溃，这意味着进程有可能保持在这种状态，直到管理员介入或自动断路器触发。如果不对其进行检查，则此问题将由于重复的缓冲区分配而非常缓慢地耗尽内存资源，但是缓冲区未写入，因此进程可能在相当长的时间内不会终止。可以通过删除透明 HTTP 消息解压缩来缓解此风险。该问题已通过正确检测 zlib 报告的压缩 body 的终止并拒绝解压缩更多数据来修复。该问题由 Vojtech Rylko (https://github.com/vojtarylko) 发现并在 GitHub 上公开报告。

• CVE-2023-0040

  1.13.2 之前的 Async HTTP Client 版本容易受到一种称为 CRLF 注入的有针对性的请求操纵形式的攻击。此漏洞是由于在将 HTTP 标头字段值发送到网络之前，对它们进行了不充分的验证而导致的。如果用户在未事先清理的情况下将不受信任的数据传递到 HTTP 标头字段值中，则用户很容易受到攻击。此处常见的用例可能是将数据库中的用户名放入 HTTP 标头字段中。此漏洞允许攻击者将新的 HTTP 标头字段或全新的请求注入到数据流中。这可能会导致远程服务器对请求的理解与预期大相径庭。总的来说，这不太可能导致数据泄露，但可能会导致许多逻辑错误和其他行为异常。

• CVE-2022-3918

  swift-corelibs-foundation 中的 FoundationNetworking 中的程序可能容易受到 URLRequest 标头中的 CRLF ( ) 注入攻击。在此漏洞中，客户端可以将一个或多个 CRLF 序列插入到 URLRequest 标头值中。当通过 URLSession 将该请求发送到 HTTP 服务器时，服务器可能会将 CRLF 之后的内容解释为额外的标头，甚至第二个请求。例如，考虑一个使用 GET 方法向 http://example.com/ 发出的 URLRequest。假设我们将 URLRequest 标头“Foo”设置为值“Bar Extra-Header: Added GET /other HTTP/1.1”。发送此请求后，它将在服务器上显示为两个请求： GET / HTTP/1.1 Foo: Bar Extra-Header: Added GET /other HTTP/1.1 通过这种方式，客户端能够注入额外的标头并构造一个全新的请求到单独的路径，尽管在 URLSession 中只进行了一次 API 调用。如果开发者完全控制请求及其标头，则此漏洞可能不会构成威胁。但是，如果将未经消毒的用户输入放置在标头值中，则此漏洞会升级。如果是这样，恶意用户可以将新标头或请求注入到中间或后端服务器。在这种情况下，开发者应特别注意对用户输入进行消毒，或升级其 swift-corelibs-foundation 版本以包含以下补丁。