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

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

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

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

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

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

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

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

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