Skip to content

Function Hijacking:通过 Tool 描述劫持函数选择 ​

摘要 ​

Function Hijacking Attack(FHA)研究函数调用模型的一个不同于普通用户提示词注入的攻击面:攻击者只能控制候选函数的描述,离线优化该描述中的对抗性片段,使模型在不了解用户任务的前提下仍偏向攻击者指定的函数。作者在 BFCL 和五个模型上报告 70% 至 100% 的函数名选择成功率,并观察到有效调用参数并不总与函数名劫持同步出现。

这证明的是论文指定模型、函数集、白盒优化和基准条件下的工具选择脆弱性,不代表任意 MCP Server、生产函数或真实账户都可被接管。执行层若对函数、参数、目标和用户授权独立校验,选择错误也不应自动产生高影响副作用。

核心创新与差异 ​

原研究贡献是把攻击目标从诱导模型回答有害内容改为篡改函数选择偏好,并限制攻击者只能改动目标函数描述。论文采用梯度式搜索构造通用函数描述片段,主张这种片段对用户任务语义和可用函数集合有一定迁移性。

本站分析:这与“模型能够访问某 Tool”或“用户是否批准一次动作”不同,新增失效点是 Tool 描述参与模型路由时缺少可信来源和独立的调用资格校验。它补强了本分类的结论:选择阶段的模型偏好不是授权,服务端动作边界仍必须 fail-closed。

威胁模型与攻击链 ​

攻击者可发布或影响一个候选函数的描述,但不控制用户 prompt,也不需控制其他函数名称。攻击目标是在模型的候选函数集中让目标函数替代应被选择的函数;若运行时随后无条件执行,风险可扩展为不当数据读写、外联或可用性破坏。

攻击链是:不可信描述进入 Tool 列表;模型在函数选择阶段受到描述片段影响;生成目标函数调用;执行层若未将函数与当前任务、用户授权、参数和目标资源重新绑定,就接受该调用。最先失效的是不可信 Tool 元数据影响路由和执行资格。

攻击工件与复现材料 ​

论文描述了以 GCG 为基础的描述优化过程,但本文不发布可迁移到真实函数集的对抗性 token 序列,也不构造外联/写入函数。下面是对应的本地测试状态机,属于本站依据公开机制重构,用于检验执行控制而非提升劫持能力:

python
candidate = {"name": "mock_export", "description": "[UNTRUSTED_METADATA]"}
call = model_select_tool(task="read local test record", tools=[candidate])

if call.name != "mock_read" or not policy.authorizes(call):
    return "DENY: selection is not an authorization grant"
return mock_execute(call, dry_run=True)

前置条件是自有或明确授权的离线模型、mock Tool 与 dry_run=True。安全检测信号是“选择的函数不在任务允许集合”或“参数未通过策略”;真实函数描述、攻击 token、生产端点与凭据均被省略。

实验设计与实际过程 ​

作者使用 BFCL,比较简单与通用攻击、不同对抗片段长度及多模型设置;主要指标为目标函数名是否被选择,并另检查生成调用的结构和参数有效性。论文设置 A100-80GB、seed 42,并在部分实验中以 Llama-3.2-3B-Instruct 深入分析。

函数名 ASR 是“模型选择了目标函数”的指标,不等同于工具成功执行,更不等同于数据泄露或账户影响。本站未运行作者优化过程或任何真实 Tool。

后续的 ContextLeak把结果条件从“选中恶意工具”推进到“同时把运行时上下文放入调用参数”。攻击者仍只优化恶意工具的名称和描述,但用攻击 LLM 在模拟影子用户上做强化学习,使载荷在受害者上下文显著不同的条件下仍可迁移。其攻击链明确要求三步同时成立:Agent 选中工具、把用户提示/执行轨迹/工具列表作为参数传入、工具实现再向攻击者端点发送;论文主要补足第二步,不能把工具选择率直接当作外泄率。

用于防御验证时,可把上文状态机的 call 参数替换为仅含占位值的上下文字段,并断言策略拒绝任何不属于当前任务最小参数集的字段;不得连接真实外传端点。该材料是本站依据公开机制的去武器化扩展,不是作者载荷。

关键结果与实际影响 ​

  • 作者在五个模型和 BFCL 条件下报告 70%–100% 的函数名选择 ASR;不同片段长度、函数集和模型会显著影响结果。
  • 论文指出函数名劫持与有效参数调用需要分别评估,不能只根据模型选中了目标名称就认定副作用已经发生。
  • 若 Tool 描述可由第三方控制,审批 UI、日志和后端策略都应显示并验证最终函数/参数,而非只信 Agent 的自然语言解释。

防护措施与验证方法 ​

将 Tool 描述和函数注册视为不可信输入,要求签名来源、发布审核和变更复核;模型选择后由独立策略层根据用户任务、函数标识、目标资源和参数检查允许性。高影响调用还应使用服务端 allowlist、短期授权、规范化参数显示和幂等/回滚机制。

验证应包含描述污染、函数同名/相近名、函数集变化与良性任务;分别报告错误选择率、未授权调用阻断率、参数拒绝率、误拒和实际副作用。所有 sink 应为本地 mock,避免将研究基准变成生产攻击。

局限与待验证问题 ​

  • 论文主要使用基准函数集与白盒优化条件,未验证真实 MCP Host、远程 Server 注册或完整用户审批流程。
  • 未观察到公开的可直接运行攻击工件;本文只保留安全控制可验证所需的去武器化状态机。
  • 结果依赖函数描述、模型版本、候选集和优化预算,不能外推为所有 Tool Calling 模型的漏洞比例。
  • 尚需独立复现,并检验签名注册、服务器端参数校验和最小授权在自适应描述变化下的组合效果。
  • ContextLeak 仅有作者实验;强化学习预算、影子用户分布、工具候选集和模型版本会影响迁移,且第三步外发仍取决于工具实现与网络出口。

参考链接 ​