摘要

11月7日OpenAI发布会后，GPT-4的最新更新为用户带来了更加便捷的功能，包括Python代码解释器、网络内容浏览和图像生成能力。这些创新不仅开辟了人工智能应用的新境界，也展示了GPT-4在处理复杂任务方面的惊人能力。然而，与所有技术进步一样，新功能的引入往往伴随着新挑战。GPT-4新功能上线后，我们第一时间对其功能进行了安全分析，其中发现Python代码解释器疑似存在沙盒逃逸漏洞。

本文将深入探讨该漏洞的发现和挖掘过程，分享OpenAI官方对该问题的处理态度和处置思路，也希望该漏洞能够提供给大家更多对大语言模型（LLMs）应用安全风险的理解和思考。

01 漏洞发现与分析

绿盟研究团队起初的研究切入点为OpenAI本次更新当中支持了GPT-4在对话过程中能够根据用户的描述进行自动化的图表生成，并且通过界面上的分析按钮可以查看相关的图表是基于Python的matplotlib.pyplot库完成。

在发现GPT-4已经支持用户输入Python代码后，我们第一时间尝试对Python代码执行功能进行初步的测试，了解相关功能的使用范围和相关限制，并关注整个过程中是否存在安全保护机制以及针对Python环境实施的安全策略。在直接通过Python解释器执行系统id命令以及间接通过字符串拼接实现id命令的执行时，发现GPT-4针对Python执行系统功能时，存在一定的安全限制，针对恶意的代码组合方式会拒绝进行Python代码执行，从而限制⽤户运行影响进程⽂件和Python环境完整性的操作。

在多次测试与代码执行后，我们推测GPT-4中针对这一特性存在相关的安全检测机制：

1. ⽤户输⼊ → 2. ChatGPT检测执⾏代码是否影响系统进程、⽂件、⽹络等，⽆⻛险则继续 → 3. 组合⽤户输⼊和预制逻辑形成待执行代码 → 4. 执⾏代码 → 5. GPT-4解释执⾏结果

GPT-4沙箱逃逸到任意命令执行

尽管GPT-4具备这些安全措施，但依然可能实现Python沙盒逃逸。我们研究发现利用多次会话上文和ASCII编码隐藏敏感命令，最终通过字符串触发执行，绕过了GPT-4的安全检查，执行了cat /etc/issue命令，成功获取到了目标环境的Linux发行版。

02 漏洞提交过程 && OpenAI官方处理态度

在确认Python沙箱逃逸漏洞的可行性后，团队于第一时间上报国家漏洞库，并于11月8日通过BugCrowd向OpenAI提交了这一安全问题，并详细描述了相关的发现过程及绕过安全策略的方法。

11月9日OpenAI官方针对我们提交的漏洞进行了回复，比较遗憾的是，官方将此问题归类为模型幻觉问题，并且认为相关代码执行过程是大模型模拟出来并给出的虚假结果，并告知由于大模型的安全问题存在一定的特殊性，与模型提示词输入与响应内容相关的问题不在安全问题的范围之内，因此拒绝收录此漏洞。

后续我们多次对该问题进行了验证和测试，包括对代码执行环境的分析、GPTs私有化知识库探测等，依旧判定为是实际上的代码执行而非“模型幻觉问题”，关于GPTs应用的安全风险我们会在下一篇文章当中进行介绍。

03 OpenAI官方修复策略

在官方回复漏洞提交记录后，我们于11月13日重新测试发现先前在Python解释器中的安全检查机制已被移除，用户可无限制在Python解释器中输入并执行相关的系统命令，无需再绕过任何安全机制。以下是我们通过执行env命令输出的系统环境变量信息，可以看到Python解释器的Agent功能是放在K8S集群中执行的，并且用户在系统中的执行权限为sandbox。

我们分析代码执行沙箱的K8S 集群架构图如下：

站在OpenAI官方视角来看，该问题是很难直接在应用层面进行修复，大语言模型的魅力在于其对自然语言的理解、推理和生成能力，而在安全视角中，自然语言的多样性以及复杂的逻辑多样性又使得我们在以往传统应用安全中基于输入输出做变量控制的检测防御实践很难在LLM安全场景中应用起来，单一的应用层安全策略不足以应对复杂的安全挑战。

值得借鉴的是OpenAI在处置本次风险时直接在应用安全层面放开了Python代码的执行限制，选择在容器架构层面进行安全加固以及攻击面的收敛，通过基于K8S Pod的形式运行Python解释器沙箱，在底层Pod运行时环境中实施严格的安全措施，包括网络连接限制、可读写目录限制、Pod运行存活时间、禁用高危命令等限制策略，以此来修复问题。这种做法增强了模型应用基座系统的安全性，将攻击影响限制在了可控的范围之内。

04 总结：LLMs时代下的应用安全

在本文我们通过实证测试深入探讨了GPT-4的安全漏洞，同时也对OpenAI的安全策略和对待安全漏洞的态度进行了深入的分析。在LLMs时代，如何确保LLMs应用的安全性，已成为一个亟待解决的关键问题。

OpenAI针对该漏洞直接在应用层面修复此类问题面临较大难度，OpenAI选择在容器架构层面进行安全加固以及攻击面的收敛制策略，但即便如此，该场景下依然存在部分安全风险，包括代码执行和资源滥用、数据安全问题甚至容器逃逸风险等。突显出在LLMs时代，面对日益复杂的安全威胁，需要采取更为全面和多层次的安全策略。随着人工智能技术的快速发展，我们必须不断审视和更新我们的安全策略，以确保在LLMs时代下应用的安全和可靠性。

声明：本文来自M01N Team，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。