NVIDIA Riva漏洞使AI驱动的语音和翻译服务面临风险
摘要
Trend Micro Research发现多个组织在云环境中部署NVIDIA Riva时存在暴露的API端点模式。这些暴露的实例在没有身份验证的情况下运行，可能使它们对威胁行为者可访问。我们发现了两个漏洞（CVE-2025-23243和CVE-2025-23242）导致了这些暴露。
配置错误的Riva部署使未经授权的访问成为可能，允许攻击者无限制地滥用GPU资源和API密钥。暴露的API还增加了数据泄露、拒绝服务（DoS）攻击和系统中断的风险。
运行具有专有模型的AI驱动服务的组织可能面临知识产权盗窃的风险，特别是如果他们的模型或推理服务通过配置错误的API暴露。
公司应评估其部署，特别是在云环境中运行默认或配置错误的设置，因为这些可能导致Riva服务的意外暴露。在高级配置中使用Triton Inference Server的组织还应验证其安全状况，因为配置错误或过度暴露可能引入安全风险和潜在攻击向量。
Trend Vision One™云风险管理主动检测云部署中的意外网络暴露。有关其他最佳实践和详细建议，请参阅下面的缓解指南。
技术细节
NVIDIA Riva代表了AI语音识别、翻译和合成的突破，使公司能够将高性能模型集成到各种应用中，包括转录、语音助手和对话式AI。
然而，其实施带来了新的独特安全挑战。急于利用先进语音识别功能可能使企业面临安全风险，因为部署架构的复杂性以及AI模型和API的复杂层创建了广阔的攻击面，需要仔细考虑。
我们在多个组织的云环境部署中发现了令人担忧的暴露NVIDIA Riva API端点模式。这些实例体现了安全疏忽，在没有身份验证保护的情况下运行，并对任何潜在威胁行为者保持可访问。
这些问题将允许任何人免费访问Riva服务，例如使用昂贵的硬件资源和付费API密钥。另一个后果包括底层服务信息的披露，使其容易受到针对Triton Inference Server的拒绝服务（DoS）和内存攻击（当应用高级配置时）。
我们发现了两个漏洞（CVE-2025-23242和CVE-2025-23243）持续导致这些暴露。通过与Trend Zero Day Initiative™（ZDI）合作进行负责任的披露过程，这些漏洞已修复并在ZDI-25-145和ZDI-25-144下披露。
要理解这些漏洞，让我们从NVIDIA Riva快速入门指南开始。按照教程，我们可以获取NGC命令行实用程序并下载QuickStart资源。初始化脚本将从NVIDIA Artifact Registry下载必要的容器镜像和AI模型。请注意，需要具有GPU和有效API密钥的合适硬件来获取和使用模型。
初始化完成后，我们可以使用“bash riva_start.sh”命令启动Riva服务。一旦操作成功启动，Riva服务器在端口50051上监听gRPC连接。由于使用第三方库，底层实现可能保持隐藏。它作为一个方便的一体化包和复杂软件的开箱即用解决方案。
从容器到主机的多个暴露端口是开放的，监听0.0.0.0（所有IP地址）。此网络设置等效于docker –network host参数，并且没有任何防火墙设置，将对所有人可访问。
Riva gRPC API协议随gRPC反射启用而提供，允许每个人识别服务类型并重建二进制协议。这本身不是问题，因为通过 obscurity 的安全不是好实践。然而，当暴露时，它简化了服务识别。Riva gRPC协议通过GitHub上可用的多个开源存储库对开发人员来说是众所周知的。
这提出了一个问题：这些gRPC端点可以安全吗？通过文档和可用示例，用户可能认为可以通过修改config.sh脚本并生成适当的证书来以安全方式配置服务。
然而，即使所有证书参数都在NVIDIA QuickStart包中的config.sh中提供，gRPC服务器仅强制执行TLS/SSL连接并加密客户端和服务器之间的流量。这意味着您将能够验证服务器是否是其声称的。但是，没有人会验证客户端，每个人都将能够使用服务。此行为可能引发错误的安全感，而服务对所有人暴露。
其他暴露端口呢？Riva服务器内部与Triton Inference Server通信。实际上，它只是将API请求转换为Triton Inference Server理解的语言。由于容器配置，这些端口暴露Triton Inference Server二进制：
- REST API端点（默认8000）
- gRPC API端点（默认8001）
- HTTP指标端点（默认8002）（仅/metrics端点）
这使得REST和gRPC Triton Inference Server API对所有人可用。因此，即使成功保护Riva服务器gRPC端点，仍然可以通过将请求转换为Triton Inference Server端点来完全绕过。
值得注意的是，当Triton Inference Server配置有高级设置时，某些端点构成重大安全风险，因为它们可能暴露固有缺陷和先前披露的漏洞。
安全最佳实践和建议
我们建议所有Riva服务管理员检查其配置以防止意外服务暴露，并确保他们运行最新版本的Riva框架。除了NVIDIA的最佳实践外，考虑实施以下安全措施：
- 实施安全API网关并仅暴露预期的gRPC或REST API端点。这些有助于防止未经授权的访问并保护后端服务。
- 通过限制对Riva服务器和Triton Inference Server的访问到受信任的网络来应用网络分段。这有助于最小化攻击面并防止来自互联网的未经授权访问。
- 要求强身份验证机制并强制执行基于角色的访问控制，以确保只有授权用户和服务可以与Riva API交互。考虑零信任方法，例如身份感知访问，以确保只有经过身份验证和授权的用户和设备可以与Riva服务交互。
- 审查和修改容器设置以禁用不必要的服务，删除未使用的端口，并限制特权执行。这防止攻击者利用暴露的服务或配置错误。
- 在Riva和Triton Inference Server上启用日志记录和监控以检测异常访问模式、异常活动或潜在滥用。
- 考虑速率限制和API请求限制，特别是如果gRPC或REST端点暴露给外部网络或集成到威胁行为者可能尝试暴力或DoS攻击的环境中。
- 保持Riva框架、Triton Inference Server和依赖项最新，以缓解已知漏洞并保护 against 新发现的漏洞。
Trend Micro保护
云风险管理主动检测云部署中的意外网络暴露，类似于我们发现的暴露。云风险管理ID EC2-016和EC2-001是防止此类暴露的安全检查示例。
- EC2-016可以帮助确保Amazon EC2默认安全组限制所有入站公共流量，以强制AWS用户（管理员、资源经理等）创建自定义安全组，执行最小权限原则（POLP），而不是使用默认安全组。
- EC2-001可以帮助确保Amazon EC2安全组没有为入站流量打开端口范围，以保护关联的EC2实例免受拒绝服务（DoS）攻击或暴力攻击。云风险管理强烈建议仅根据应用程序要求在安全组中打开特定端口。