概要
-
AI 大模型是以 LLM神经元网络为引擎,但是包括多个框架组件来支撑的复杂系统。
-
新一代大模型系统和应用正在逐渐引入具有代码执行能力的框架组件。
-
这些框架组件为 AI 系统带来丰富的功能和逻辑能力的提升,但是这些框架,尤其是有代码执行能力的组件也引入了新的安全风险。
-
发现并防御AI系统级风险应该得到AI算法安全,AI Safety等话题同样级别的重视。
-
起因
一年一次的1024来了。对于系统安全的从业人员来说,1024 不仅是2的10次幂,也是重要活动日期的代名词。GeekCon 2024 将在10月24号在上海如期召开。加上之前1023的看雪峰会,以及之前的补天白帽,这一周网络安全行业的众多精彩活动在上海密集发生。
早早地定了机票,旅馆,期待和行业的朋友在盛会上见面交流。作为技术宅享受最新的安全议题,行业小道消息,我做足了期待。可惜事与愿违。临时的行程变更,不得不错过这次盛会。
# GeekCon 2024的热点
今年GeekCon的活动颇有几个热点。大约十年前的极棒(GeekCon 的前身)就有设备电池过热,是否会发生自燃的挑战和议题。十年前的议题如今随着近期中东发生的BP机攻击事件直接变成国际话题。本届 GeekCon 会针对这个题目进行新的挑战。期待活动可以协助公众澄清对设备物理安全的担忧。
GeekCon的热点当然还有 AI,从AI系统自身的安全,到应用AI做安全。GeekCon今年年初新加坡站 [1] 进行了 AI “越狱”挑战;本次上海有对智能网联车辆的攻击挑战。GeekCon 2024 新加坡站用 AI 做安全防御;本次在上海可以看选手用AI生成安全攻击测试脚本。
# AI 是持续的安全热点话题
AI 大模型的发展和对工作效率的提升有目共睹。WordLift 和 ChatGpt 让技术人员写科普文章变得轻松(例如写这篇短文)。Copliot 和 Cursor 帮助程序员提升代码开发速度,让大龄程序员重获青春时最旺盛的搬砖感受。
惊人的能力自然带来了对AI的担心。程序猿担心工作被替代,出租车司机也担心。百度萝卜快跑出圈的余波刚刚平息没几个月,马斯克就在本月发布了自动驾驶概念车。虽然没撑起来特斯拉股价,但直接把自动驾驶安全带到了科技论坛的主版面。
本次 GeekCon 新设立了安全吐槽的环节,评委或选手可以上台发表一些行业观察。AI 近期的进展让我对 AI系统自身安全有了新的想法,本来打算报名上台讲一下我对AI系统自身安全的拙见。由于行程变更,我只好把拙见写成给 GeekCon 的预热稿,借以填补不能现场参与的遗憾。
2. 大语音模型(LLM) 与 远程代码执行(RCE)
我的思考来自对近期AI LLM能力增长的观察(以及一些道听途说)。
# 背景
因为要讨论让大模型应用做代码执行这个话题,让我们首先简单考虑一下大语音模型和输入中的代码。
作为一个神经元网络,LLM会把来自 Prompt 的输入作为一系列 Token 输入大模型,后者通过预先训练生成的模型参数进行计算,生成输出。整个计算过程即是大模型对于给定输入在已经训练好的神经元网络上的推演(inference)过程。
如果用户的输入中包括可执行的代码,或者文字描述的代码动作,经典的神经元网络并不会直接按照传统意义上的方法执行这些代码,虽然输出有可能包括类似代码执行后的结果。等下我会用例子说明。
# 涉及的系统目标 (LLM 系统 vs. LLM 算法)
LLM算法和系统的区别在于:LLM 算法的研究围绕核心引擎,从命令行获得文字输入,由神经元网络推演,生成文字输出。
实际的AI 应用程序往往需要支持用户多种形式的数据和输入,例如增强训练(RAG)的输入可能是 PDF 或者网页文档。这些需求造就了近两年 LLM 开发框架的繁荣。例如 LangChain 框架,目的是帮助开发者简化用大语言模型开发 AI 应用的过程。这些开发框架往往提供了与第三方服务和工具接口的集成, 例如 LangChain 包括了辅助用户生成代码,调试代码的组件。当然除了协助 LLM 开发, 社区里也涌现出 guardrail 等框架,帮助AI应用检测恶意Prompt 注入等不良输入。
基于这些信息,我们可以推想一个对外提供服务的AI系统实际上是由一系列组件围绕核心神经元网络组成的。AI系统的输出也不是单纯的神经元网路推演, 而是多个模块和LLM引擎互动的结果。
另外前沿大模型厂商从提升大模型“智能” 的角度,也在大模型服务中增加了神经元网络以外的模块,尤其是具有精确推理和逻辑能力的功能模块。这其中就包括各种执行代码的沙箱。这些被执行的代码可以是来自用户,第三方组件,甚至是 LLM 自己根据用户输入生成的代码。
下面我用一个简单例子来说明LLM 系统内组件的演化。
# 利用 LLM 进行代码执行
在这个例子里,我将会让 LLM 来计算一个任意字符串 (例如 “GeekCon2024”) 的哈希值。
首先让我们直接和一个以经典基础大模型 LLM 来互动。这里我用开源的 LLAMA 3.1 大模型为例。下面是我让 LLAMA 3.1计算 MD5哈希值的结果:
Figure 1: Asking LLAMA 3.1 about md5(“GeekCon2024”)
当我们问 LLAMA 来回答“GeekCon2024” 的哈希值时,我们得到了一个答案。这个答案看起来像个 MD5 哈希值。但是如果再次询问问几遍,LLM 自己会给出另一个答案,甚至后面又纠正了一次。
这样的结果显然说明 LLAMA 并没有按照传统意义上进行这个 MD5 哈希值的计算执行。答案只是输入通过了神经元网络一次后的推演(inference)结果。
相信这个结果符合大家对经典神经元网络(包括大模型)的预期。我测试了免费版的 ChatGPT,跟 LLAMA 的输出相似。给出的答案是看似 MD5 格式,但是数值不正确的哈希值。
让我们自己用传统方法计算一下GeekCon2024 的MD5 哈希值,输出应该是下面的结果
Figure 2: The Correct Value of md5(“GeekCon2024”)
但是新的 LLM 系统引入了对某些具体任务的执行能力,同样的问题送给最新的 Chatgpt,输出如下:
Figure 3: Latest ChatGPT provides the correct answer.
最新商用版 ChatGPT 给出了正确的答案!
我的推断是 ChatGPT 对特定任务采用了沙箱执行。当然对这些任务的识别可能是依赖大模型自己来完成的。为了让 AI 系统具有更强的逻辑能力,我的猜测是:领先的 AI大模型服务商都在采用代码执行与 LLM神经元网络结合的方式。
# 基于以上简单实验的推断
通过上面这个例子,我们可以在一定程度上说:AI 大模型系统在逐渐为用户提供命令/代码执行 (Code Execution) 能力。而且被执行的代码是由用户从 prompt 直接或者间接(用语言描述)产生的。当然这个代码的执行应该在严格的沙箱中,至少我希望是这样。
为什么我觉得这个趋势值得关注?从事系统安全的朋友看到这里应该会想到 LLM 引擎端的代码执行风险 (或许各位老司机早已经看到,想到,并在实验了)。一旦攻击者做到了远程代码的执行能力,例如逃离执行沙箱,就意味着攻击者可以对 AI LLM 服务端的内网运行环境可以一窥究竟。如果出现了高危的远程代码执行漏洞,甚至可以导致服务端脚本,例如 guardrail 组件,被替换。
# LLM 框架的安全风险案例
虽然我自己目前没有一个利用这种“代码执行”能力来演示安全风险的例子,但是这种担心也不是无端的。
在流行的 LLM 开发框架里(LangChain,PandasAI等),过去两年内已经出现了多起严重的安全漏洞。以 LangChain 为例,从 2023年开始,已经有多家安全公司发现并协助修复了多个安全漏洞。例如 CVE-2023-46629,恶意用户可以通过构建畸形的输入导致在 AI 应用的服务提供商内部网络运行恶意代码,导致AI服务商内部敏感数据外传。
同样还是在 LangChain 的框架里,一个协助代码生成的模块 PALChain 爆出远程代码执行漏洞 (CVE-2023-44467)。导致用户可以直接在 Prompt 里嵌入恶意代码并在 AI 服务端成功执行。这里直接引用已发布过的PoC,细节可以参考 Palo Alto 公司 UNIT42 团队的报告 [2]。
Figure 4: Sample PoC to Demo PALChain Vulnerability
上述所有漏洞已经在 LangChain 中被修复。但是 AI LLM 框架的漏洞近期仍然频出。本周 CCS 大会也有来自中科院陈恺老师团队的工作 [3] ,披露了更多 LangChain 和其它 LLM 框架的漏洞。感兴趣的朋友可以研读一下相关工作。
# RCE风险和后果
从事系统安全工作的研究员都清楚远程代码执行 (RCE) 漏洞的危害,但是在行业以外还是有很多朋友不理解系统级别安全漏洞的危害。
用最简单的方式概括,我可以断言的是:公众对大模型幻觉,AI 模型安全,甚至AI 算法偏见的讨论,其实都是以AI系统的自身安全没有问题作为前提的。当攻击者具有对 AI 系统后台控制能力,例如系统漏洞造成远程任意代码执行风险时,所有的各种公众担心的安全风险都可以被攻击者变成现实。
拿 LangChain 框架为例,当攻击者能够替换大模型的输出过滤脚本时,攻击者可以随意造成模型幻觉,有选择性地给出错误输出,或者给出带有最具恶意偏见的输出。
3. 结语
上面是我对 AI 大模型系统最新能力进展的一个简单思考。核心观点简单总结一下:1)新一代大模型系统和应用逐渐引入具有代码执行能力的框架组件;2)这些框架组件为 AI 系统带来更丰富的功能和逻辑能力的提升,但是这些框架,尤其是具有代码执行能力的组件也引入了更复杂的安全风险;3)发现并防御AI系统级风险应该受到和 AI Safety,AI算法安全等同样级别的重视。
说到这里刚好想起 GeekCon 今年的两个主题。一个是围绕”智能网联汽车的安全挑战“, 另一个是“对抗研判AVSS挑战赛“。
虽然两个都不是直接针对 AI 大模型的安全项目,但是都与AI系统安全相关。
智能汽车以及未来的AI自动驾驶系统必须作为一个系统来进行安全的研判,而不是仅仅测试其 AI 算法。算法的安全测试和对抗很重要,但是真实系统中安全问题可以出现在 AI 算法周边的各种组件,而且这些风险对于最终用户的影响不会弱于算法本身带来的风险。
AVSS 作为一种新的安全评测体系是从攻击者视角评测目标的安全性。如果把 AI 大模型作为 AVSS 的评测目标,我觉得一定是以把 AI 大模型的应用作为一个系统,评测包括远程代码执行的安全风险, 而且一定会把RCE作为高危级别风险来检测。
好久没动笔了,借这个机会写了上面这段文字,为 GeekCon 以及坚持深耕系统安全领域的诸位呐喊加油。也用这个方法跟错过的各位神仙打个招呼。期待下一次见面。
4. References
-
GeekCon 2024, https://www.geekcon.top/
-
UNIT 42 Threat Research Center Report https://unit42.paloaltonetworks.com/langchain-vulnerabilities
-
ACM CCS 2024, “Demystifying RCE Vulnerabilities in LLM-Integrated Apps”, Tong Liu, Zizhuang Deng, Guozhu Meng, Yuekang Li, Kai Chen.
原文始发于微信公众号(CTF黑客呓语):大模型安全 vs. 代码执行