利用ML模型的Pickle文件攻击：第2部分 - Trail of Bits博客

Boyan Milanov
2024年6月11日
机器学习

在第1部分中，我们介绍了Sleepy Pickle攻击，它利用恶意Pickle文件 stealthily 破坏ML模型并对终端用户发起复杂攻击。在这里，我们展示了如何调整这种技术，以在受感染系统上实现持久存在并保持不被检测。这种变体技术，我们称之为Sticky Pickle，包含一个自复制机制，将其恶意负载传播到受感染模型的后续版本中。此外，Sticky Pickle使用混淆技术来伪装恶意代码，以防止被Pickle文件扫描器检测。

使恶意Pickle负载持久化

从我们之前的博客文章中回顾，Sleepy Pickle攻击依赖于将恶意负载注入到包含打包ML模型的Pickle文件中。当Pickle文件反序列化为Python对象时，该负载被执行，破坏模型的权重和/或相关代码。如果用户决定修改受感染的模型（例如，微调）然后重新分发，它将被序列化为攻击者无法控制的新Pickle文件。这个过程可能会使攻击失效。

为了克服这个限制，我们开发了Sticky Pickle，一个自复制机制，将我们的模型破坏负载封装在一个持久的封装负载中。封装负载在执行时执行以下操作：

• 在本地文件系统上找到正在加载的原始受感染Pickle文件。
• 打开文件并从磁盘读取封装负载的字节。（负载无法通过其自己的Python代码直接访问它们。）
• 在预定义的属性名称下，将自身的字节码隐藏在正在反序列化的对象中。
• 钩住pickle.dump()函数，以便在对象重新序列化时：
  • 使用常规的pickle.dump()函数序列化对象。
  • 检测对象是否包含字节码属性。
  • 手动将字节码注入到刚刚创建的新Pickle文件中。

图1：恶意ML模型文件中的持久负载

通过这种技术，恶意Pickle负载自动传播到衍生模型，而不会在受感染Pickle文件之外的磁盘上留下痕迹。此外，钩住Python解释器中任何函数的能力允许其他攻击变体，因为攻击者可以访问其他本地文件，如训练数据集或配置文件。

负载混淆：潜入雷达之下

基于Pickle的攻击的另一个限制源于恶意负载直接作为Python源代码注入。这意味着恶意代码以明文形式出现在Pickle文件中。这有几个缺点。首先，可以通过简单的文件扫描和一些针对Pickle文件中原始Python大块存在的启发式方法来检测攻击。其次，安全团队只需查看就可以轻松识别攻击及其意图。

我们开发了一种负载混淆和编码方法，克服了这些限制，并使负载检测更加困难。从我们原始的破坏Pickle ML模型的代码负载开始，我们通过两种方式修改它。

首先，我们通过将负载编译成Python代码对象并使用marshal库将其序列化为字符串来混淆它。这使我们能够将这个序列化的负载字符串注入到Pickle文件中，后跟一个特殊的字节码序列。当执行时，这个特殊序列在字符串上调用marshal.loads()来重建负载的代码对象并执行它。这使得负载对扫描器或人工检查完全不可读，因为它作为编译的Python字节码而不是源代码注入。

其次，我们使用简单的XOR编码在每个受感染文件中变化负载。XORed负载不仅包含原始模型破坏代码，还包含原始负载的XOR编码Python源代码以及一个类似于以下的解码和执行存根：

1
2
3
4
5
6

def compromise_model(model):
    # XOR编码的Python负载源代码字符串
    encoded_payload = 
    # 这行代码解码负载并执行它
    exec(bytearray(b ^ 0x{XOR_KEY:X} for b in encoded_payload))
    return model

由于混淆密钥可以取任何值并在解码存根中硬编码，这种方法通过允许攻击者编写一个在新Pickle文件中重新注入时生成新混淆密钥的负载来补充持久性功能。这导致不同的Python负载、代码对象和最终Pickle负载被注入到受感染文件中，而恶意行为保持不变。

图2：在注入Pickle文件之前Python负载的混淆

图2显示了这种混淆方法如何完全隐藏文件中的恶意负载。扫描文件的自动化工具或安全分析师只会看到：

• Python负载的原始字节，这些字节被编译然后marshalized。解释这些字节并将其标记为危险几乎是不可能的。
• 调用marshal.loads()的Pickle序列。这是一种常见模式，也出现在良性Pickle文件中，因此不足以警告用户潜在的恶意行为。

当加载包含混淆负载的Pickle文件时，负载阶段按以下顺序执行，如图3所示：

1. 恶意Pickle操作码加载序列化代码对象的原始字节，然后使用marshal.load()重建Python代码对象，最后执行代码对象。
2. 代码对象被执行并解码XOR编码的原始负载Python源代码。
3. 解码的原始负载代码被执行并破坏加载的ML模型。

图3：混淆负载执行阶段概述

封盖Pickle的风险

这些持久性和规避技术展示了Pickle攻击可以达到的复杂程度。扩展我们在本系列第一部分展示的关键风险，我们看到了单个恶意Pickle文件如何：

• 破坏其他本地Pickle文件和ML模型。
• 规避文件扫描并使手动分析 significantly 更加困难。
• 使其负载多态化，并在不断变化的形式下传播它，同时保持相同的最终阶段和最终目标。

虽然这些只是其他可能攻击改进中的示例，但持久性和规避是Pickle攻击的关键方面，据我们所知，尚未被演示。

尽管Pickle文件带来了风险，我们承认ML生态系统的主要框架远离它们将是一个长期努力。在短期内，您可以采取以下行动步骤来消除对这些问题的暴露：

• 避免使用Pickle文件分发序列化模型。
• 采用更安全的替代方案，如HuggingFace的SafeTensors。
  • 也查看我们对SafeTensors的安全评估！
• 如果必须使用Pickle文件，使用我们自己的Fickling扫描它们以检测基于Pickle的ML攻击。

长期来看，我们继续努力推动ML行业采用安全设计技术。如果您想了解更多关于我们的贡献，请查看我们的awesome-ml-security和ml-file-formats Github仓库以及我们最近对名为Leftover Locals的关键GPU漏洞的负责任披露！

致谢

感谢我们的实习生Russel Tran在Pickle负载混淆和优化方面的辛勤工作。

如果您喜欢这篇文章，请分享：
Twitter LinkedIn GitHub Mastodon Hacker News

页面内容

• 使恶意Pickle负载持久化
• 负载混淆：潜入雷达之下
• 封盖Pickle的风险
• 致谢
• 近期文章
  • The Unconventional Innovator Scholarship
  • Hijacking multi-agent systems in your PajaMAS
  • We built the security layer MCP always needed
  • Exploiting zero days in abandoned hardware
  • Inside EthCC[8]: Becoming a smart contract auditor

© 2025 Trail of Bits.
使用Hugo和Mainroad主题生成。