6月24号的时候hackerone网站上公布了一个ffmpeg的本地文件泄露的漏洞，可以影响ffmpeg很多版本，包括3.2.2、3.2.5、3.1.2、2.6.8等等。

hackerone网站上的漏洞介绍: https://hackerone.com/reports/226756。与之相关联的还有其他几篇hackerone上的漏洞报告：https://hackerone.com/reports/243470、https://hackerone.com/reports/242831)

实际上这个漏洞@EmilLerner和@PavelCheremushkin最早在今年的phdays大会上就已经披露了，视频可以在https://www.phdays.com/broadcast/搜索Attacks on video converter得到，不过是全俄语的，暂时没有英文字母。也可以参考漏洞作者在phday大会上的ppt

作者实际上在5月份的时候就发现了该漏洞并提交，6月26号的时候公布出来，最新的ffmpeg版本3.3.2中已经修复了，但是旧的版本不保证。

FFmpeg是一套目前非常流行的可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序。它提供了录制、转换以及流化音视频的完整解决方案。目前有非常多的视音频软件或是视频网站、手机 APP 都采用了这个库，但是这个库历史上曝出的漏洞也非常之多。这次的漏洞是利用了ffmpeg可以处理 HLS 播放列表的功能，在 AVI 文件中的 GAB2字幕块中嵌入了一个 HLS 文件，然后提供给ffmpeg进行转码，在解析的过程中把它当做一个 XBIN 的视频流来处理，再通过 XBIN 的编解码器把本地的文件包含进来，最后放在转码后的视频文件当中。

漏洞重现方法

1) 下载脚本 235K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6F1k6h3g2^5i4K6u0r3k6X3k6E0M7r3g2Y4i4K6u0V1j5i4k6A6i4K6u0V1L8e0y4#2i4K6u0V1P5r3u0A6L8W2)9J5c8X3u0D9L8$3u0Q4x3V1k6E0j5i4y4@1k6i4u0Q4x3V1k6Y4k6h3&6Q4y4h3k6^5j5X3W2F1i4K6g2X3j5i4k6A6i4K6u0W2M7s2V1`.
2) 运行脚本：python3 gen_xbin_avi.py file:///etc/passwd sxcurity.avi
3) 访问e92K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6S2M7Y4S2A6N6i4y4Q4x3X3g2A6L8#2!0q4c8W2!0n7b7#2)9^5b7#2!0q4y4q4!0n7z5q4)9^5b7g2!0q4y4q4!0n7b7#2!0m8x3s2y4^5j5%4g2J5K9i4c8&6i4K6u0W2j5i4k6A6
4) 等待上传处理视频
5) 录像处理完成后，点击播放就可以看到/etc/passwd的内容

这次的漏洞实际上与之前曝出的一个 CVE 非常之类似，可以说是旧瓶装新酒，老树开新花。

之前漏洞的一篇分析文章：

SSRF 和本地文件泄露（CVE-2016-1897/8）http://static.hx99.net/static/drops/papers-15598.html

这个漏洞实际上也是利用了ffmpeg在处理 HLS 播放列表文件的过程中，由于支持非常多的协议，如http、file、concat等等，导致可以构造恶意的url造成 SSRF 攻击和本地文件泄露。下面这幅图介绍了整个的攻击流程。

官方对这个漏洞的修复是把concat协议加入了黑名单并在结构体中加入了protocol_blacklist和protocol_whitelist这两个域。但是这次的漏洞利用了内嵌在字幕块中的 m3u8文件成功绕过了ffmpeg的某些限制。

HLS(HTTP Live Streaming)是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的基于HTTP协议的流媒体解决方案。在 HLS 技术中 Web 服务器向客户端提供接近实时的音视频流。但在使用的过程中是使用的标准的 HTTP 协议，所以这时，只要使用 HLS 的技术，就能在普通的 HTTP 的应用上直接提供点播和直播。该技术基本原理是将视频文件或视频流切分成小片(ts)并建立索引文件(m3u8)。客户端会先向服务器请求 m3u8索引文件，然后根据索引文件里面的url去请求真正的ts视频文件。如果是多级的m3u8索引的话，那就会从根索引文件开始，一层一层的往下去请求子的索引文件，获取最终的TS流文件的http请求地址与时间段。

M3U8文件中有很多TAG，每一个 TAG 的详细的作用可以参考这篇文章：http://blog.csdn.net/cabbage2008/article/details/50522190

先介绍一下ffmpeg是怎样把一个输入文件转码成另一种格式的视频文件，流程图如下：（图片引用自http://blog.csdn.net/leixiaohua1020/article/details/25422685）

然后我们观察一下攻击者提供的poc生成的sxcurity.avi文件的结构

最开始是 AVI 文件的文件头，然后中间有一个 GAB2字幕的文件头“GAB2”，在 GAB2的文件头后面还有 HLS 播放列表的文件头"#EXTM3U"，在文件头后面就是 HLS 的文件内容了。

这次的漏洞主要是利用了ffmpeg处理 GAB2字幕块的时候的逻辑错误，所以我们重点从ffmpeg打开输入文件时调用 read_gab2sub()这个函数开始分析，read_gab2sub() 函数是被avformat_find_stream_info() 这个函数调用的。整个函数调用流程图如下：

我们可以看到在为播放列表确定demuxer的时候探测出格式为XBIN，但是单看sxcurity.avi文件中并没有 XBIN 的文件头，那么ffmpeg是怎么确定格式是 XBIN 的呢。这就与 HLS 的解析过程密切相关了。在判断一个播放列表的格式时候，ffmpeg会读取播放列表的第一个segment，然后根据这个 segment 的url去请求文件内容，然后根据读取到的文件内容来判断格式。

我们可以看到sxcurity.avi里面内嵌的 playlist 的前几行是这样写的

#EXT-X-MEDIA-SEQUENCE:0
### echoing b'XBIN\x1a \x00\x0f\x00\x10\x04\x01\x00\x00\x00\x00'
#EXT-X-KEY: METHOD=AES-128, URI=/dev/zero, IV=0x4c4d465e0b95223279487316ffd9ec3a
#EXTINF:1,
#EXT-X-BYTERANGE: 16
/dev/zero

#EXT-X-KEY: METHOD=NONE

### echoing b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\xbf\n'
#EXT-X-KEY: METHOD=AES-128, URI=/dev/zero, IV=0x140f0f1011b5223d79597717ffd95330

以#EXT开头的都是m3u8文件中的标签，其他以#开头的是注释，不以#开头的是一个url

介绍一下上面出现的标签的含义

#EXT-X-MEDIA-SEQUENCE:每一个media URI 在 PlayList中只有唯一的序号，相邻之间序号+1, 一个media URI并不是必须要包含的，如果没有，默认为0。

#EXTINF:  duration 指定每个媒体段(ts)的持续时间（秒），仅对其后面的URI有效。

#EXT-X-KEY表示怎么对mediasegments进行解码。其作用范围是下次该tag出现前的所有mediaURI，属性为NONE或者 AES-128。对于AES-128的情况，URI属性表示一个key文件，通过URI可以获得这个key，如果没有IV（Initialization Vector）,则使用序列号作为IV进行编解码；如果有IV，则将改值当成16个字节的16进制数。

那么上面几行代码包括了两个segment，每一个 segment 都需要使用 AES-128进行解密，密文是从/dev/zero这个 url获取的16个字节，其实就是16个'\0'， key 也是从/dev/zero这个url获取的16个字节，16个'\0'，IV是自己指定的一串十六进制数。ffmpeg对第一个 segment 进行解密后的结果是b'XBIN\x1a \x00\x0f\x00\x10\x04\x01\x00\x00\x00\x00', 和漏洞作者在注释中给出的一样。前四个字节 XBIN 就是 XBIN 的文件头。从而使得ffmpeg判定这个播放列表的格式是 XBIN。

在open_input_file的函数结尾，程序会调用av_dump_format函数打印格式信息，打印结果如下

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课