深度学习框架中的魔鬼 -- 探究人工智能系统中的安全问题
导语：深度学习引领着新一轮的人工智能浪潮，受到工业界以及全社会的广泛关注。 虽然大家对人工智能有很多美好的憧憬，但是现实是残酷的 -- 随着一批深度学习应用逐渐开始变成现实，安全问题也渐渐显现出来。
ISC 2017中国互联网安全大会举办了人工智能安全论坛。 我们把论坛总结成为一系列文章，本文为系列中的第一篇。
深度学习引领着新一轮的人工智能浪潮，受到工业界以及全社会的广泛关注。 虽然大家对人工智能有很多美好的憧憬，但是现实是残酷的 — 随着一批深度学习应用逐渐开始变成现实，安全问题也渐渐显现出来。
人工智能应用面临来自多个方面的威胁：包括深度学习框架中的软件实现漏洞、对抗机器学习的恶意样本生成、训练数据的污染等等。 这些威胁可能导致人工智能所驱动的识别系统出现混乱，形成漏判或者误判，甚至导致系统崩溃或被劫持，并可以使智能设备变成僵尸攻击工具。
在推进人工智能应用的同时，我们迫切需要关注并解决这些安全问题。本文作为人工智能与安全的系列文章之一，首先介绍我们在深度学习框架中发现的安全问题。
1. 人工智能讨论中的安全盲点
目前公众对人工智能的关注，尤其是深度学习方面， 缺少对安全的考虑。我们把这个现象称为人工智能的安全盲点。 导致这个盲点的主要原因是由于算法与实现的距离。 近期对于深度学习的讨论主要停留在算法和前景展望的层面，对应用场景和程序输入有很多假设。受到关注的应用往往假定处于善意的或封闭的场景。例如高准确率的语音识别中的输入都是自然采集而成，图片识别中的输入也都来自正常拍摄的照片。这些讨论没有考虑人为恶意构造或合成的场景。
人工智能讨论中的安全盲点可以通过最典型的手写数字识别案例来说明。基于MNIST数据集的手写数字识别应用是深度学习的一个非常典型的例子， 最新的深度学习教程几乎都采用这个应用作为实例演示。在这些教程中（如下图所示）算法层的讨论所考虑的分类结果只关心特定类别的近似度和置信概率区间。算法层的讨论没有考虑输入会导致程序崩溃甚至被攻击者劫持控制流。这其中被忽略掉的输出结果反映出算法和实现上考虑问题的差距，也就是目前人工智能讨论中的安全盲点。
图1. 深度学习算法与安全所考虑的不同输出场景
现实中的开放应用需要处理的输入不仅来源于正常用户，也可以是来自黑产等恶意用户。 人工智能的应用必须考虑到应用所面临的现实威胁。程序设计人员需要考虑输入数据是否可控，监测程序是否正常执行，并验证程序执行结果是否真实反映应用的本来目的。
2. 深度学习系统的实现及依赖复杂度
深度学习软件很多是实现在深度学习框架上。目前基于深度学习系统框架非常多，主流的包括TensorFlow、Torch，以及Caffe 等。
深度学习框架的使用可以让应用开发人员无需关心神经元网络分层以及培训分类的实现细节，更多关注应用本身的业务逻辑。 开发人员可以在框架上直接构建自己的神经元网络模型，并利用框架提供的接口对模型进行训练。这些框架简化了深度学习应用的设计和开发难度，一个深度学习的模型可以用几十行代码就可以写出来。
图2. 深度学习框架以及框架组件依赖
深度学习框架掩盖了它所使用的组件依赖，同时也隐藏了系统的复杂程度。 每种深度学习框架又都是实现在众多基础库和组件之上，很多深度学习框架里还包括图像处理、矩阵计算、数据处理、GPU加速等功能。 图2展示了典型的深度学习应用组件和它们的依赖关系。例如Caffe除了自身神经元网络模块实现以外，还包括137个第三方动态库，例如libprotobuf, libopencv, libz 等。 谷歌的TensorFlow 框架也包含对多达97个python模块的依赖，包括librosa,numpy 等。
系统越复杂，就越有可能包含安全隐患。任何在深度学习框架以及它所依赖的组件中的安全问题都会威胁到框架之上的应用系统。另外模块往往来自不同的开发者，对模块间的接口经常有不同的理解。当这种不一致导致安全问题时，模块开发者甚至会认为是其它模块调用不符合规范而不是自己的问题。在我们的发现的导致深度学习框架崩溃的漏洞中就遇到过这种情况。
3. 魔鬼隐藏于细节之中
正如安全人员常说的， 魔鬼隐藏于细节之中 （The Devil is In the Detail）。任何一个大型软件系统都会有实现漏洞。 考虑到深度学习框架的复杂性， 深度学习应用也不例外。
360 Team Seri0us 团队在一个月的时间里面发现了数十个深度学习框架及其依赖库中的软件漏洞。发现的漏洞包括了几乎所有常见的类型，例如内存访问越界，空指针引用，整数溢出，除零异常等。 这些漏洞潜在带来的危害可以导致对深度学习应用的拒绝服务攻击，控制流劫持，分类逃逸，以及潜在的数据污染攻击。
以下我们通过两个简单的例子来介绍深度学习框架中的漏洞以及对应用的影响。两个例子都来源于框架的依赖库，一个是TensorFlow框架所依赖的numpy包，另一个是Caffe在处理图像识别所使用的libjasper库。
案例1： 对基于TensorFlow的语音识别应用进行拒绝服务攻击
案例中的 numpy 是TensorFlow所依赖的一个负责科学计算的python库。TensorFlow的很多应用在进行矩阵运算的时候都会用的它。 我们在这个库里发现一个简单逻辑漏洞（CVE-2017-12852）。 这个问题的简单情况如下图所示，它是发生在numpy中的pad函数。 在pad函数中，存在这样一个while循环，循环结束需要使 pad_before>safe_pad和pad_after>safe_pad同时不成立， 而在我们构造的例子中，可以使得pad_before和 pad_after不断的增大，而safe_pad不断的减小，使得循环始终无法结束，从而导致拒绝服务。
--- a/numpy/lib/arraypad.py
+++ b/numpy/lib/arraypad.py
@@ -1406,7 +1406,10 @@ def pad(array, pad_width, mode, **kwargs):
newmat = _append_min(newmat, pad_after, chunk_after, axis)
elif mode == 'reflect':
- for axis, (pad_before, pad_after) in enumerate(pad_width):
+ if narray.size == 0:
+ raise ValueError("There aren't any elements to reflect in 'array'!")
+
+for axis, (pad_before, pad_after) in enumerate(pad_width):
... ...
method = kwargs['reflect_type']
safe_pad = newmat.shape[axis] - 1
while ((pad_before > safe_pad) or (pad_after > safe_pad)):
... ...
我们选择了基于TensorFlow的语音识别应用来演示基于这个漏洞触发的攻击。攻击者通过构造语音文件，会导致上图中显示的循环无法结束，使应用程序长时间占用CPU而不返回结果，从而导致拒绝服务攻击。
我们选取了一个基于TensoFlow进行声音分类的应用来演示这个问题。这个应用是一个 TensorFlow程序演示，应用脚本源码可以从以下网站下载：[ “Urban Sound Classification”： https://aqibsaeed.github.io/2016-09-03-urban-sound-classification-part-1/ ]
当给定一个正常的狗叫的音频文件，应用可以识别声音内容为 "dog bark"，其过程如下：
./demo.sh dogbark.wav 02:34:42.713346: W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.1 instructions, but these are available on your machine and could speed up CPU computations. ... ... audio file: dogbark.wav softmax output: [[ 9.82184019e-07 1.81138901e-07 2.68021075e-04 9.97506797e-01 3.25933332e-04 4.26165315e-07 1.18322554e-03 4.01796569e-08 2.90570169e-05 6.85345207e-04]] The audio is dog_bark!
当给定一个畸形的声音文件可导致拒绝服务， 程序无法正常结束：
./demo.sh dos.wav 02:37:23.818618: W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.1 instructions, but these are available on your machine and could speed up CPU computations. ... ... audio file: dos.wav ^C^C^C^C^C
在前面关于模块依赖复杂导致漏洞的讨论中，我们提到过对模块接口的理解不一致会导致问题。值得一提的是Numpy这个漏洞的修复过程正好反映了这个问题。在我们最初通知Numpy开发者的时候，他们认为问题是由于调用者librosa库的开发人员没有对数据进行严格检测，导致空列表的使用。所以尽管有应用会因为此问题受到拒绝服务攻击， Numpy开发者最初认为不需要修复这个问题。但后来发现有多个其它库对numpy的相关函数也有频繁的类似调用，所以最终对这个漏洞进行了修复。同时librosa 开发者也对相关调用添加了输入检查。
案例2：恶意图片导致基于Caffe的图像识别应用出现内存访问越界
很多深度学习的应用是在图像和视觉处理领域。我们发现当使用深度学习框架Caffe来进行图片识别时，Caffe会依赖libjasper等图像视觉库来处理输入。libjasper对图像进行识别处理时，如果存在漏洞，例如内存越界，就可能导致整个应用程序出现崩溃，甚至数据流被篡改。下面的例子是用展示的是用Caffe所自带的例子图像识别程序来处理我们提供的畸形图片所出现的崩溃场景。
当利用Caffe来对正常图片进行分类时，正常的使用情况如下：
classification.bin ./caffe/models/bvlc_reference_caffenet/deploy.prototxt ./caffe/models/bvlc_reference_caffenet/bvlc_reference_caffenet.caffemodel ./caffe/data/ilsvrc12/imagenet_mean.binaryproto ./caffe/data/ilsvrc12/synset_words.txt cat.jpg ---------- Prediction for pocs/cat.jpg ---------- 0.3134 - "n02123045 tabby, tabby cat" 0.2380 - "n02123159 tiger cat" 0.1235 - "n02124075 Egyptian cat" 0.1003 - "n02119022 red fox, Vulpes vulpes" 0.0715 - "n02127052 lynx, catamount"
当利用Caffe来对恶意图片进行分类时，程序出现崩溃：
classification.bin ./caffe/models/bvlc_reference_caffenet/deploy.prototxt ./caffe/models/bvlc_reference_caffenet/bvlc_reference_caffenet.caffemodel ./caffe/data/ilsvrc12/imagenet_mean.binaryproto ./caffe/data/ilsvrc12/synset_words.txt bug.jpg ---------- Prediction for pocs/bug.jpg ---------- Segmentation fault gdb-peda$ bt #0 0x00007ffff3295f6b in ?? () from /usr/lib/x86_64-linux-gnu/libjasper.so.1 #1 0x00007ffff32961e0 in ?? () from /usr/lib/x86_64-linux-gnu/libjasper.so.1 #2 0x00007ffff32958ad in jpc_decode () from /usr/lib/x86_64-linux-gnu/libjasper.so.1 #3 0x00007ffff328f2f7 in jp2_decode () from /usr/lib/x86_64-linux-gnu/libjasper.so.1 #4 0x00007ffff3283eed in jas_image_decode () from /usr/lib/x86_64-linux-gnu/libjasper.so.1 #5 0x00007ffff6df4158 in cv::Jpeg2KDecoder::readHeader() () from /usr/lib/x86_64-linux-gnu/libopencv_highgui.so.2.4 #6 0x00007ffff6dd74fc in ?? () from /usr/lib/x86_64-linux-gnu/libopencv_highgui.so.2.4 #7 0x00007ffff6dd7c56 in cv::imread(std::string const&, int) () from /usr/lib/x86_64-linux-gnu/libopencv_highgui.so.2.4 #8 0x0000000000403f2b in main () #9 0x00007ffff606af45 in __libc_start_main (main=0x403dd0 <main>, argc=0x6, argv=0x7fffffffde28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde18) at libc-start.c:287 #10 0x000000000040435e in _start ()
以上仅仅是我们发现的众多问题中的两个展示。 360 Team Seri0s 团队已发现并公布了数十个导致深度学习框架出现问题的漏洞，其中包含已对外公开的15个CVE。 在上个月举行的ISC安全大会上，Team Seri0s成员已经展示了六个攻击实例。更多细节请参考ISC 2017大会人工智能与安全论坛所发布的内容。
4. 小结
本文的目的是介绍被大众所忽视的人工智能安全问题，尤其是深度学习软件实现中的漏洞以及可能造成的隐患。目前在媒体中展示的深度学习应用中，许多并不与外界直接交互，例如AlphaGo；或者是在封闭的环境下工作，例如通过用户行为日志对用户分类画像并进行异常检测。这些系统的攻击面相对较小，它们并不容易受到本文中所提到的漏洞的直接影响。 但是随着人工智能应用的普及，安全威胁会不断增加，更多的应用会把应用的输入接口直接或间接暴露出来，同时封闭系统的攻击面也会随着时间和环境而转化。 另外除了传统的基于软件漏洞的攻击，深度学习还面临对抗神经元网络以及其它各种逃逸攻击。 我们会在后续文章里对这方面的工作进行更新。
本文作者：肖奇学, 李康（来自360 Team Seri0us 团队）