近日，360 AI安全研究院（AIVUL团队）对Google Tensorflow进行了安全测试，在不到一个月的时间内发现多个安全问题，最终获得谷歌分配的24个CVE编号，其中危险等级严重的漏洞（critical severity）2个，高危（high severity）8个，中危（moderate severity）12个，低危（low severity）2个，影响上千万开发者及用户。

0x01 机器学习框架安全问题

近年来，谷歌（Google）、脸书（Facebook）、微软（Microsoft）等公司发布了一系列开源的人工智能框架，如Tensorflow、PyTorch、MXNet、CNTK、Caffe等，并已经被工业界和学术界广泛采用。这些框架可以帮助开发者高效、快速的构建网络模型进行训练和推理，而无需关心底层实现的细节。由于机器学习框架高效、便捷的特性，越来越多的开发者加入到AI应用研发的行列。如谷歌推出的Tensorflow是目前最流行的机器学习框架之一，深受广大开发者的喜爱，其下载量已达上千万级，特别是在2.0版本发布后，其在简单和易用性方面有了大幅度提升，极大地方便了开发者。

然而，在机器学习框架研发的时候，更多关注其功能、性能以及面向开发者的易用性，对框架软件本身实现层面的安全性缺乏充分考虑。一旦这些框架中存在安全问题，将会影响数以千万计的开发者以及用户。

早在2017年，360 AIVUL团队便对机器学习框架所依赖的第三方库进行了全面安全测试，最终发现了诸多安全问题。随着机器学习框架的不断完善、发展，三年后的今天，机器学习框架的安全性是否已经得到改善呢？

带着这个疑问，360 AIVUL团队再次对机器学习框架Tensorflow进行了安全测试，在不到一个月的时间内发现多个安全问题，最终获得谷歌分配的24个CVE编号，其中危险等级严重的漏洞（critical severity）2个，高危（high severity）8个，中危（moderate severity）12个，低危（low severity）2个，影响上千万开发者及用户。

360 AIVUL团队提交的Tensorflow漏洞列表

0x02 Tensorflow云端模块漏洞分析

TensorFlow云端模块主要运行在PC机或者服务器上，用于机器学习模型的训练以及推理。云端模块在训练模型时需要处理海量数据，在推理时主要完成模型优化、模型部署以及推断计算等工作，以上工作强依赖于密集型、并行化计算能力。

Tensorflow云端模块在2.4版本中修复了数十个由360 AIVUL团队提交的漏洞，漏洞类型包含：内存越界访问、内存越界写、堆崩溃、格式化字符串、空指针解引用等。这些漏洞可能导致任意代码执行、信息泄露以及拒绝服务等，进而影响机器学习应用的训练、推理结果。

以下我们介绍Tensorflow 2.3中存在的两个严重漏洞以及这些漏洞对用户的影响。

案例一：CVE-2020-15205 StringNGrams信息泄露（危险等级:严重）

漏洞POC如下，从代码中可以看到，其中只有一行简短的函数调用，正常使用了Tensorflow提供的函数StringNGrams来进行词组的组合。

然而程序运行结束后，在第六个结果中，“AIVul”之后包含了一串未知的16进制数据，经过分析发现，这些数据来自于内存空间，其中包含一些敏感信息，如返回地址等。

当受害者运行以上简单的函数后，便泄露了内存数据信息，方便攻击者进行下一步的攻击，比如通过泄露的信息构造攻击向量，绕过地址随机化，进而控制受害者的机器。

案例二：CVE-2020-15202 random.gamma越界写（危险等级:严重）

在这个案例中，当运行以下POC时，Tensorflow便会产生越界写的问题。

此时的崩溃栈如下，可以发现崩溃点在_pywrap_tensorflow_internal.so库的RandomGammaOp<float>::Compute函数中。

此时查看造成崩溃时的指令：

可以看到程序将xmm3中的数据保存在rdi+rax*4的地址空间中，通过查看寄存器rdi与rax数据：

并结合内存空间布局，最终可以发现，崩溃地址的指令向非法的内存写数据。

如果攻击者构造特殊的参数数值，控制写数据的地址，那么当受害者运行看似“人畜无害”的脚本或者函数后，将会影响模型的训练、推理结果，或者导致在受害者的机器中执行恶意指令，导致命令执行的后果。

0x03 Tensorflow终端模块漏洞分析

随着终端设备算力的增强，AI推理能力逐渐向端侧迁移，为了充分利用终端芯片，特别是AI芯片的计算能力，许多厂商都推出了可整合硬件（如CPU，GPU，DSP，NPU等）和软件算力的终端机器学习框架或模块，让搭载了AI芯片的终端设备具有更强的AI处理能力。

Tensorflow Lite是Tensorflow中的终端模块，主要面向移动端设备与IoT设备等终端设备。由于终端设备功耗、芯片等诸多限制，开发者首先需要通过转换工具将云端模块训练好的模型转换为终端设备适用的模型格式，然后借助Tensorflow终端模块TFLite，在终端设备上进行模型的加载、推理。

360 AIVUL团队在TFLite中同样发现了多个高危漏洞，这里以CVE-2020-15214为例详细的介绍终端框架漏洞可能导致的安全问题。

案例一：CVE-2020-15214 segment_sum函数越界写（危险等级:高危）

在TFLite中，segment_sum算子的功能是将一个tensor进行切割，分成多个segments，并且将同一segment下的数据进行求和。当TFLite加载我们构造的恶意模型进行推理时，便会产生越界写的效果。 

在TFLite的实现中，默认传入的segment_ids是递增排序的，并且使用segment_ids的最后一个元素来为output tensor分配内存空间。

但是，如果segments_ids不满足递增排序，在向output tensor写入数据时，便会产生问题。

在TFLite中，使用BuildFromBuffer和Interpreter::Invoke函数来加载和推理TFLite模型，尽管TFLite提供了Verify API来对模型文件的字段进行合法性检查，但是依旧可以通过精心构造恶意模型文件来绕过检查。所以当用户加载和推理精心构造的恶意模型文件时，就会触发漏洞，导致越界写数据的后果，进而可能在用户的终端设备中执行恶意代码。

0x04 总结

360 集团董事长兼CEO周鸿祎曾说过：“安全是基础，只有在安全的基础上，我们才有可能考虑舒适、便捷的人工智能式生活。”机器学习框架作为重要的人工智能基础设施，其安全性直接影响到广大AI应用开发者和用户。然而，目前开源机器学习框架往往缺乏严格的安全测试管理和认证，可能存在严重的安全

风险，一旦被攻击者恶意利用，就会危及整个人工智能产品和应用的可用性和可靠性，甚至有可能导致重大的财产损失与恶劣的社会影响。

360 AIVUL团队建议，未来各厂商应加强在框架安全方面的重视和投入，特别是要对涉及框架外部环境交互的模块、软件供应链等环节进行重点安全性检测。另外，框架安全应协同硬件安全、算法安全、数据安全等软硬件各维度的安全防御技术，建立一体化安全防御体系。

【AI安全研究院（AIVUL团队）】

360 AI安全研究院隶属于360未来安全研究院，专注于人工智能与安全前沿技术研究，在全球范围内率先发现了众多的人工智能安全问题，并开展人工智能赋能安全的研究工作；具体研究领域涉及AI基础设施安全、AI算法与数据安全、新一代智能化漏洞挖掘、基于AI的未知威胁检测等。团队在相关研究领域有丰富的成果积累：

• 是全球首个从系统实现角度对AI关键基础设施进行攻击的团队；
• 研制完成多款先进的漏洞挖掘工具，累计发现主流机器学习框架及依赖组件漏洞100+个，影响范围包括Tensorflow、Caffe、PyTorch、OpenVINO等；
• 发现常用软件漏洞200+个，智能设备漏洞20+个；
• 联合清华大学、西安交大的研究人员提出一种新型的数据流降维攻击方法，其危害性影响国内外主流厂商的AI云服务；
• 发现多款人脸识别设备的安全风险，可实现任意物体通过验证；
• 研制AI算法与数据安全攻防对抗平台，发现新型的具备对物理世界造成威胁的对抗攻击、后门攻击方法，并提出对应的安全防御技术；
• 在USENIX Security、S&P等国际顶尖信息安全学术会议上发表论文，在HITB、ISC、CNCC、POC、Defcon China、Syscan360等国内外知名安全会议上发表大量议题。

欢迎更多对AI与安全研究感兴趣的同学加入我们！(Email: zhangdeyue@360.cn)

Reference：

https://www.anquanke.com/post/id/86989

https://github.com/tensorflow/tensorflow/blob/master/RELEASE.md

https://github.com/tensorflow/tensorflow/blob/master/tensorflow/security/README.md

https://github.com/tensorflow/tensorflow/security/advisories

https://www.anquanke.com/post/id/209852