Apollo 查询规划器和 Apollo 网关可能会在足够复杂的查询上无限循环（CVE-2024-43414）
CVE编号
CVE-2024-43414利用情况
暂无补丁情况
N/A披露时间
2024-08-28漏洞描述
Apollo Federation是一种声明式地组合API到统一图谱的架构。每个团队可以独立拥有他们自己的图谱切片，使他们能够自主并逐步地提供服务。使用@apollo/query-planner版本在2.0.0到2.8.5之间的实例受到拒绝服务漏洞的影响。同时，使用@apollo/gateway版本在2.0.0到2.8.5之间以及Apollo Router版本小于1.52.1也受到其使用的@apollo/query-panner的影响。如果要求@apollo/query-planner规划足够复杂的查询，它可能会无限循环并且永远不会完成，导致内存消耗无界并最终崩溃或内存溢出（OOM）终止。如果您至少有一个可以由多个子图解决的非@key字段，则可以触发此问题。要识别这些共享字段，必须查看每个子图的模式。子图使用的Federation版本的识别机制会有所不同。您可以通过查看模式来检查子图是否使用Federation 1或Federation 2。Federation 2子图模式将包含引用正在使用的Federation版本的@link指令，而Federation 1子图则不会。例如，在Federation 2子图中，您会发现一行类似于@link(url: "https://specs.apollo.dev/federation/v2.0")。如果子图模式中不存在类似的@link指令，那么它正在使用Federation 1。请注意，超图可以包含混合的Federation 1和Federation 2子图。此问题源于Apollo查询规划器在某些情况下尝试使用一个超出Javascript的Number.MAX_VALUE的数字。在Javascript中，Number.MAX_VALUE是（2^1024 - 2^971）。当查询规划器接收到入站的GraphQL请求时，它将查询拆分成多个部分，并针对每个部分生成潜在执行步骤的列表，以解决问题。这些候选人代表了查询规划器为满足更大查询的各个部分而采取的步骤。作为正常操作的一部分，查询规划器需要并计算总查询的可能查询计划的数量。也就是说，它需要查询的每个部分的查询计划候选人的数量乘积。在正常情况下，在生成所有查询计划候选人并计算所有排列之后，查询规划器会继续对候选人进行排名并删除次优选项。在特别复杂的查询中，尤其是那些可以通过多个子图解决的字段，这可能会导致所有查询计划的排列数量激增。在最坏的情况下，这可能会变成一个大于Number.MAX_VALUE的数字。在Javascript中，如果超出Number.MAX_VALUE，Javascript会将值表示为“无穷大”。如果候选人的数量被评估为无穷大，那么负责修剪次优查询计划的查询规划器组件实际上并不会修剪候选人，导致查询规划器评估了远超过必要的查询计划候选人数量。这个问题已在@apollo/query-planner v2.8.5、@apollo/gateway v2.8.5和Apollo Router v1.52.1中得到解决。建议用户进行升级。此问题可以通过确保没有字段可以从多个子图中解析出来来避免。如果所有子图都使用Federation 2，您可以确认您不受此影响，方法是确保您的子图模式没有使用@shareable指令。如果您使用的是Federation 1子图，则需要验证是否有字段可由多个子图解析。解决建议
"将组件 @apollo/query-planner 升级至 2.8.5 及以上版本""将组件 @apollo/gateway 升级至 2.8.5 及以上版本""将组件 apollo-router 升级至 1.52.1 及以上版本"- 攻击路径 N/A
- 攻击复杂度 N/A
- 权限要求 N/A
- 影响范围 N/A
- 用户交互 N/A
- 可用性 N/A
- 保密性 N/A
- 完整性 N/A
| CWE-ID | 漏洞类型 |
Exp相关链接
版权声明
本站原创文章转载请注明文章出处及链接，谢谢合作！
评论