老周不止一次的在公開場合說到，安全是360公司的底線，我們必須堅守。在360公司，有這樣一支隊伍，他們每天與時間賽跑，和黑暗勢力進行著較量。在威脅面前，他們從不畏懼，在安全問題上，他們從不妥協(xié)。他們常說安全探索永無止境，做好企業(yè)安全、產品安全，就是在保護360所有用戶的安全。但是安全從來都是越閉塞，問題越多，聯(lián)動的力量越大，安全系數(shù)越高。

360安全應急響應中心（以下簡稱360SRC）平臺上就聚集著眾多有識之士，他們不僅安全能力出眾，而且及其富有正義感。正是有他們在，我們才可以擁有更強大的力量來一起捍衛(wèi)億萬互聯(lián)網用戶的安全。

很多人對SRC的運營感到好奇，今天我們就通過一個真實的安全應急事件為您解惑。

360SRC平臺收到白帽子mango提交的名為《奇酷手機任意文件讀取》漏洞，經mango測試發(fā)現(xiàn)奇酷手機受ffmpeg文件竊取漏洞影響，通過一段視頻，就能獲得手機中的文件內容，包括用戶的通訊錄，短信以及其他的敏感文件被遠程盜取，泄露用戶的隱私信息。

FFmpeg的是一種多媒體框架，支持解碼，編碼，轉碼，復用，解復用，流媒體，過濾器和播放幾乎任何格式的多媒體文件。支持無數(shù)編碼的格式，比如，HLS。

HLS（HTTP Live Streaming）是蘋果公司開發(fā)的一種基于HTTP協(xié)議的流媒體通信協(xié)議。它的基本原理是把一個視頻流分成很多個ts流文件，然后通過HTTP下載，每次下載一份文件。在開始一個新的流媒體會話時，客戶端都會先下載一個m3u8（播放列表 Playlist）文件，里面包含了這次HLS會話的所有數(shù)據。

漏洞轉交到負責Android系統(tǒng)安全研究的同事處根據漏洞描述進行驗證。

負責驗證的同事看到漏洞詳情描述之后，表示這有可能是一個烏龍事件。

FFmpeg SSRF與本地文件讀取漏洞最初是在國外漏洞平臺曝光，去年在某CTF比賽中也被使用過。今年1月，官方發(fā)布了修復版本并公布了該漏洞。一方面手機系統(tǒng)應該早已更新到了新版本。另外，在ffmpeg SSRF與本地文件讀取漏洞爆發(fā)后，負責奇酷手機安全檢測的同事就對所有的手機版本進行過逐一排查，但并未發(fā)現(xiàn)奇酷手機集成了libffmpeg.so文件。

但本著嚴謹認真的安全態(tài)度，同事還是做了再次驗證和排查。

通過對比修復補丁發(fā)現(xiàn)，特征字符串為“file,”，在編譯好的so文件中的rodata段中能搜索到字符串“file,”，證明此so版本為修復后的版本。具體的掃描代碼如下：

command= '\.rodata' 
cmd= "readelf -S %s | grep '\s%s'" % (file_path,command) 
process= subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE,shell=True) 
ret,err= process.communicate()  
rets= ret.lstrip().split(' ') 
iflen(rets) == 0: 
continue 
r= [] 
for_a in rets: 
if_a != "": 
r.append(_a) 
if'.rodata' not in r: 
continue 
rodata_type= 0 
ifr[1] == '.rodata': 
rodata_type = 3 
ifr[2] == '.rodata': 
rodata_type = 4 
ifrodata_type != 0: 
withopen(file_path,'rb') as f: 
f.seek(int(r[rodata_type],16)) 
data =f.read(int(r[rodata_type+2],16)).replace('\0','\n') 
if 'detect bitstream' in data: 
rr = data.split('\n') 
if 'file,' in rr: 
print ‘not vul’ 
else: 
print ‘vul’ 

經上面的掃描代碼排查發(fā)現(xiàn)，手機系統(tǒng)并未及時更新至官方修復后的版本。同時也并未查到libffmpeg.so文件。

我們開始與白帽子進行溝通，請白帽子將測試時用的文件打包發(fā)給我們，然后進行再次的復現(xiàn)排查。最后發(fā)現(xiàn)文件管理器apk中打開文件夾后，文件夾里的惡意視頻文件會自動觸發(fā)，讀取指定文件，并回傳到服務器。

負責奇酷手機安全檢測的同事對文件管理器apk進行了分析，并沒有發(fā)現(xiàn)解析視頻的模塊。也查過調用的系統(tǒng)功能解析視頻文件，在系統(tǒng)庫中也并沒有找到libffmpeg.so文件。無奈之下把/system/lib和/system/lib64文件夾下的所有so文件提取出來，逐個對每一個文件進行檢查，到底要看看究竟是哪個文件集成了ffmpeg的功能。

經查后，果然發(fā)現(xiàn)了一些端倪，發(fā)現(xiàn)是libavdemuxer.so文件集成了libffmpeg的視頻解析功能，并改名為libavdemuxer.so，而libavdemuxer.so集成的是ffmpeg的2.6.1版本，而此版本正受該漏洞的影響。果然“工業(yè)級代碼”害死人。在此，我們強烈建議開發(fā)人員養(yǎng)成良好的安全開發(fā)習慣，規(guī)范命名，同時及時更新第三方代碼庫。

最后，確認該漏洞屬于遠程利用的信息泄露中危漏洞。同一時間，我們將問題反饋給業(yè)務線，讓他們升級libavdemuxer.so所使用的ffmpeg版本，并通過OTA為用戶升級。

如果您有使用ffmpeg的程序，請參照下面的版本進行升級：

FFmpeg 2.8.x系列升級至2.8.5或以上；

FFmpeg 2.7.x系列升級至2.7.5或以上；

FFmpeg 2.6.x系列升級至2.6.7或以上；

FFmpeg 2.5.x系列升級至2.5.10或以上；

或直接使用FFmpeg 3.0.x版本。

目前APPScan（http://appscan.#/）已經支持對ffmpeg漏洞的掃描。

你以為劇情到這里就結束了？怎么可能，我們還要給提交漏洞的白帽子進行現(xiàn)金獎勵。（360手機漏洞獎金計劃：http://security.#/News/news/id/68.html）而且“任性”的同事馬上對行業(yè)安全情況進行了深入的分析。

通過對手機助手市場提供的124371款app掃描，發(fā)現(xiàn)受此漏洞影響的產品數(shù)量為6314款，占總數(shù)的5%。并對其中受影響的app所使用的ffmepg庫文件做了個top10統(tǒng)計。

其中使用率最高的libeasemod_jni.so屬于環(huán)信sdk所帶的庫文件，libcyberplay-core.so是百度開放云播放器的Android SDK。

通過深入研究發(fā)現(xiàn)，即使使用了低版本有漏洞的FFmpeg庫文件，如果app業(yè)務功能中未涉及到HLS功能，將不會觸發(fā)漏洞邏輯，避免了危害的發(fā)生。環(huán)信sdk就是這樣的一種情況。

上圖是受影響app分類top10

千里之堤，潰于蟻穴。感謝老天讓我們有像mango一樣的安全專家，為360產品安全保駕護航。也歡迎更多的安全專家和團隊加入我們，因為我們相信：有你們，更安全。