Android提權漏洞CVE-2014-7920&CVE-2014-7921分析

来源:http://www.cnblogs.com/alisecurity/archive/2016/04/06/5358105.html
-Advertisement-
Play Games

沒羽@阿裡移動安全，更多安全類技術乾貨，請訪問阿裡聚安全博客 這是Android mediaserver的提權漏洞，利用CVE-2014-7920和CVE-2014-7921實現提權，從0許可權提到media許可權，其中CVE-2014-7921影響Android 4.0.3及以後的版本，CVE-201 ...


沒羽@阿裡移動安全，更多安全類技術乾貨，請訪問阿裡聚安全博客

 

 

這是Android mediaserver的提權漏洞，利用CVE-2014-7920和CVE-2014-7921實現提權，從0許可權提到media許可權，其中CVE-2014-7921影響Android 4.0.3及以後的版本，CVE-2014-7920影響Android 2.2及以後的版本。Google直到Android5.1才修複這2個漏洞。該漏洞[1]披露過程如下：

2016年1月24日漏洞作者發佈了漏洞分析及exploit[2]，拿到exploit後在幾個Android版本上均沒能運行成功，遂分析原因，學習漏洞利用思路。記錄如下，歡迎大家交流學習。

不熟悉Android Binder的同學，請自行網上搜索學習資料，下麵直接分析漏洞。

0x1漏洞成因

前文提到這2個漏洞出在mediaserver，mediaserver在main_mediaserver.cpp[3]實現，其main()函數中初始化了2個service：

一個是AudioFlinger[4]，service name為“media.audio_flinger”；另一個是AudioPolicyService[5]，service name為“media.audio_policy”。

1.1記憶體寫漏洞

記憶體寫漏洞產生在“media.audio_policy”中，介面類為IAudioPolicyService[6][7]，其中startOutput()介面存在遞增的記憶體寫漏洞，stopOutput()介面存在遞減的記憶體寫漏洞。

       startOutput()介面定義為：

startOutput(audio_io_handle_t output, audio_stream_type_t stream, int session = 0)

       stopOutput ()介面定義為：

stopOutput(audio_io_handle_t output, audio_stream_type_t stream, int session = 0)

1）startOutput的遞增寫漏洞

熟悉Android Binder的同學都知道，該介面的native類為BnAudioPolicyService[8]，當客戶端請求“START_OUTPUT”code即startOutput()介面時，BnAudioPolicyService::onTransact()收到請求，然後執行下麵的代碼：

繼續調用AudioPolicyService ::startOutput()[9]方法：

mpAudioPolicy->start_output(mpAudioPolicy, output, stream, session);

mpAudioPolicy為audio_policy類型，audio_policy:: start_output()在audio_policy_hal.cpp中被定義為ap_start_output()，該方法調用：

lap->apm->startOutput()由AudioPolicyManagerBase:: startOutput()方法實現，該方法調用：

我們來看AudioOutputDescriptor:: changeRefCount()[10]方法的代碼：

當2個if語句都為假時，mRefCount[stream] += delta;語句將被執行。

此時如果索引stream可被控制，那麼mRefCount記憶體的相對偏移記憶體將可被修改為加delta。恰巧stream為介面參數之一，也沒校驗，在AudioPolicyManagerBase:: startOutput()中傳入的delta為1 ，也就是說這裡存在一個遞增1的記憶體寫漏洞。這個記憶體寫漏洞的產生需要滿足以下條件：

  • isDuplicated()為False：幸運的是預設情況大部分output不是duplicated的。
  • (delta + (int)mRefCount[stream]) < 0：由於這個判斷條件，mRefCount[stream]<0x7FFFFFFF時才會為False，這就限制了這個記憶體寫漏洞，只能對記憶體內容小於0x7FFFFFFF的記憶體值進行遞增。

2）stopOutput的遞減寫漏洞

stopOutput()介面類似於startOutput()介面，我們直接看AudioPolicyManagerBase::stopOutput()方法，該方法調用的是：

outputDesc->changeRefCount(stream, -1);

與startOutput()介面類似，也存在相同的寫限制，不同的是這遞減1的記憶體寫漏洞。

1.2記憶體讀漏洞

記憶體寫漏洞也產生在“media.audio_policy”中，問題出在isStreamActive()介面。該介面定義為：

bool isStreamActive(audio_stream_type_t stream, uint32_t inPastMs)

類似於startOutput()介面，該介面調用了AudioPolicyManagerBase::isStreamActive()方法，該方法調用：

即AudioOutputDescriptor::isStreamActive()方法，該方法代碼為：

如果根據isStreamActive() 返回值判斷mRefCount[stream]是否為0，需要滿足2個條件：

  • mRefCount[stream] != 0；
  • ns2ms(sysTime - mStopTime[stream]) > inPastMs：

sysTime - mStopTime[stream]為時間差值，為正值，當inPastMs>=0x80000000時，該不等式成立。

所以可以通過控制stream和inPastMs的值判斷mRefCount記憶體相對偏移的值是否為0。

 

0x2利用之前

2.1利用技巧小結

1）利用記憶體讀，模糊匹配audio_hw_device對象

audio_hw_device這個結構包含了audio硬體設備函數指針，在“media.audio_policy”和“media.audio_flinger” service提供的介面中會被調用，這有利於寫exploit。audio_hw_device結構定義如下：

[圖片來自原文]

分析發現audio_hw_device對象中reserved和function_ptrs-> get_supported_devices為0，其它欄位為非0。該結構用0和非0的形式可表示為：

前面提到可以通過isStreamActive()介面判斷記憶體值是否為非0，這樣結合audio_hw_device結構的特征在記憶體中搜索，恰巧在mRefCount的上下記憶體區域中可以搜索到audio_hw_device對象。

2）利用記憶體寫，泄漏記憶體地址

 “media.audio_flinger”提供了getInputBufferSize()介面[11]，介面定義為：

其服務端代碼為：

當客戶端調用getInputBufferSize()介面，服務端最終調用get_input_buffer_size()即audio_hw.cpp::adev_get_input_buffer_size()函數，最後返回size。由arm指令特性可知，get_input_buffer_size(dev, &config)函數的反彙編中，通過R0傳入dev指針，即audio_hw_device對象，函數執行完後，返回值通過R0傳回。如果修改get_input_buffer_size函數指針，讓其指向“BX LR”，那個就可拿到audio_hw_device對象的記憶體地址。

恰巧get_input_buffer_size ()函數指針也存儲於audio_hw_device對象中，使用記憶體寫漏洞讓audio_hw_device. get_input_buffer_size指向一個“BX LR”的地址即可獲取audio_hw_device對象地址。

 

2.2踩到的坑

筆者在調試exploit時發生多次crash，將update後的exploit放在https://github.com/Vinc3nt4H/cve-2014-7920-7921_update，編譯環境：Android 4.3_r2.1，運行環境：AVD 4.3（4.3_r2.1）。

1）搜索audio_hw_device對象時mediaserver crash

在運行exploit時，可以搜索到audio_hw_device對象，但mediaserver crash了，可能是由於搜索的記憶體範圍過大，導致非法記憶體訪問。可縮小搜索範圍試試，比如設置MAX_OFFSET為-3000。

2）總是獲取不到adev_open_output_stream()地址

筆者在AVD 4.3上使用原gadget read_r0_offset_108，總是獲取不到adev_open_output_stream函數的指針，然後在camera.goldfish.so中找了一個gadget（thumb）：

3）android 4.4.2上crash

開始時筆者在AVD 4.4.2中執行exploit總是不成功，調試發現audio_hw_device. get_input_buffer_size的值被置了0，如下圖：

因為mediaserver中載入的audio.primary.goldfish.so基址大於0x7FFFFFFF，也就是mRefCount[offset_get_input_buffer_size] > 0x7FFFFFFF，即為負數，在利用遞增1/遞減1時，changeRefCount()方法，如果(delta + (int)mRefCount[stream]) < 0，則將mRefCount[stream]置為0。在4.4.2上很難利用成功。

 

0x3漏洞利用分析

3.1搜索audio_hw_device對象相對偏移

2.1-1中提到利用audio_hw_device結構的特征在mediaserver進程中搜索匹配的對象。利用isStreamActive()的記憶體讀漏洞讀取mRefCount附件記憶體區域生產0/非0的記憶體映射，然後與audio_hw_device結構特征匹配，計算出audio_hw_device對象相對於mRefCount的相對偏移。

3.2 Bypass ASLR

2.1-2中有提到利用記憶體寫漏洞獲取記憶體地址，接下來我們來分析exploit是如何利用記憶體寫繞過ASLR的。

1）獲取audio.primary.goldfish.so基地址

首先修改audio_hw_device. get_input_buffer_size指針的值，get_input_buffer_size原始指向adev_get_input_buffer_size，修改使其指向 camera.goldfish.so::0x1E290+1，記為gadget1，代碼如下：

其中library_offset為所使用的lib基址與audio.primary.goldfish.so庫基址之間的偏移，gadget_offset為相對於該lib庫基址的偏移；RELATIVE_ADDRESS_OF_GET_INPUT_BUFFER_SIZE為adev_get_input_buffer_size函數地址在audio.primary.goldfish.so中的偏移；modify_value()函數是記憶體遞增1 /遞減1操作的封裝。gadget1為：

然後調用AudioFlinger::getInputBufferSize()跳到gadget1。

uint32_t read_function_pointer_address = af->getInputBufferSize(0, (audio_format_t)0, (audio_channel_mask_t)0);

gadget1執行時R0為dev即audio_hw_device對象，參考audio_hw_device結構，R0+0x64為open_output_stream即adev_open_output_stream的值，通過R0返回。

再減去adev_open_output_stream在audio.primary.goldfish.so中的偏移READ_FUNCTION_POINTER_OFFSET_FROM_BASE_ADDRESS，即可得到audio.primary.goldfish.so的基址。

2）獲取audio_hw_device對象地址

修改audio_hw_device. get_input_buffer_size指針使其指向libcamera_client.so::0x208FC+1，即gadget2：

gadget2運行時直接返回dev（R0）的值，即audio_hw_device對象的地址。

3）設置write gadget

修改audio_hw_device. get_input_buffer_size為libcamera_client.so: 0x208f0+1，記為gadget3，利用代碼如下：

我們再來看看AudioFlinger::getInputBufferSize()方法，其中：

看gadget3，寫數據調用介面getInputBufferSize(address, 0, value)（該介面定義為getInputBufferSize(uint32_tsampleRate, audio_format_t format, audio_channel_mask_t channelMask)），走到get_input_buffer_size(dev, config)時，R0為dev, R1為&config，gadget3執行如下：

 

至此我們將audio_hw_device. get_input_buffer_size指向gadget3，再調用getInputBufferSize(address, 0, value)就可以向address-0xC記憶體寫入value。

3.3佈局Gadget Buffer

 

將system()函數地址及參數寫到audio_hw_device.reserved中，再修改audio_hw_device.get_input_buffer_size指向一個call gadget，當再次調用get_input_buffer_size()時call gadget被觸發。

1）寫入system()函數參數

看利用代碼：

write32()函數寫數據分為2步：

a）設置數據偏移

調用modify_value(aps, g_primary_device_offset + 1, offset - g_current_write_offset);修改dev.version的內容，該欄位作為後面數據寫入時的數組偏移；dev.version首次從0x200遞減直到0xC：

b）寫入數據

調用af->getInputBufferSize(g_primary_device_address + sizeof(uint32_t) + 12, (audio_format_t)0, (audio_channel_mask_t)value)觸發gadget3執行，調試時斷在gadget3上：

此時R0指向dev，R1為&config：

查看[R1]記憶體，R1[0]為config. sampleRate即address，為要寫入的地址，address為&dev[0]+4+12， R1[1]為config. channelMask即value ，值為“/dat”：

gadget3的偽代碼大致如下：

 

該gadget（某次）運行完後，數據已被寫入audio_hw_device對象中:

 

2）寫入system()函數地址

根據audio.primary.goldfish.so的基址計算出system()函數的地址，調用gadget3寫到dev+36：

3）寫入call gadget

調用gadget3修改audio_hw_device. get_input_buffer_size指針的值，使用指向，libstagefright.so: 0x5EF88+1，記為gadget4。

gadget4：

3.4觸發代碼執行

利用代碼為：

af->getInputBufferSize(0, (audio_format_t)0, (audio_channel_mask_t)0);

當調用getInputBufferSize()時觸發gadget4執行：

寄存器值：

調用system()函數，載入外命令/data/local/tmp/a。筆者寫了個遠程shell命名為a，下圖是運行成功後獲取的shell，為“media”許可權：

0x4參考鏈接

[1]http://bits-please.blogspot.com/2016/01/android-privilege-escalation-to.html

[2]https://github.com/laginimaineb/cve-2014-7920-7921

[3]http://androidxref.com/4.3_r2.1/xref/frameworks/av/media/mediaserver/main_mediaserver.cpp#40

[4]http://androidxref.com/4.3_r2.1/xref/frameworks/av/services/audioflinger/AudioFlinger.cpp

[5]http://androidxref.com/4.3_r2.1/xref/frameworks/av/services/audioflinger/AudioPolicyService.cpp

[6]http://androidxref.com/4.3_r2.1/xref/frameworks/av/include/media/IAudioPolicyService.h

[7]http://androidxref.com/4.3_r2.1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp

[8]http://androidxref.com/4.3_r2.1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#384

[9]http://androidxref.com/4.3_r2.1/xref/frameworks/av/services/audioflinger/AudioPolicyService.cpp#234

[10]http://androidxref.com/4.3_r2.1/xref/hardware/libhardware_legacy/audio/AudioPolicyManagerBase.cpp#3083

[11]http://androidxref.com/4.3_r2.1/xref/frameworks/av/media/libmedia/IAudioFlinger.cpp#346

[12]https://github.com/Vinc3nt4H/cve-2014-7920-7921_update

沒羽@阿裡移動安全，更多安全類技術乾貨，請訪問阿裡聚安全博客

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Android GZIP壓縮IO流，優化APP數據傳輸（一）
    我是小搬運工，今天講解流的壓縮傳輸 在我們安卓開發中，通常伴隨著大量的數據傳輸，在此，樓主給出一個簡單的壓縮流的數據進行操作。 public void GZIPCpf(String path) { /* * 描述 * 壓縮測試 * 通過壓縮的方式實現對java數據流的讀取 * java壓縮類屬於in ...
  • 我的android學習經歷7
    android簽名後報錯的問題 Duplicate id @+id/imageView, already defined earlier in this layout,android生成報錯 這個是項目重覆id報錯，解決方案如下： 1.點擊Window-Preferences 2.點擊android ...
  • iOS做新浪微博sso授權登錄遇到的一些坑
    新浪微博sso授權第三方登錄，這裡沒有藉助第三方框架，如shareSKD和友盟等，直接參考新浪官方SDK和文檔。 過程中遇到幾個坑，找了很久，好歹最後解決了，記錄如下 問題1： _NSInlineData base64EncodedString - unrecognized selector sen ...
  • IOS開發之自動佈局--VFL語言（不斷更新）
    前言：VFL是蘋果公司為了簡化Autolayout的編碼而推出的抽象語言。對於純代碼發燒友，值得我們去學習和瞭解哦。 1、什麼是VFL語言 VFL是蘋果公司為了簡化Autolayout的編碼而推出的抽象語言。 2、VFL使用示例： H:[cancelButton(72)]-12-[acceptBut ...
  • IOS block 迴圈引用的解決
    在介紹block迴圈引用前我們先瞭解一下typeof。 typeof是什麼？？？ typeof 是一個一元運算，放在一個運算數之前，運算數可以是任意類型。 它返回值是一個字元串，該字元串說明運算數的類型。 一、對於數字類型的操作數而言,typeof返回的值是number。比如說：typeof(1)， ...
  • Android TabHost使用
    TabHost是Android中自帶的選項卡控制項，效果圖如下： 主佈局文件 核心代碼： 兩個子頁面很簡單，兩個Activity以及對應佈局。 ...
  • android基於口令加密快速搞懂（一）
    import java.util.Random; import javax.crypto.Cipher;import javax.crypto.SecretKey;import javax.crypto.SecretKeyFactory;import javax.crypto.spec.PBEKey ...
  • ios極光推送快速集成教程
    之前有兩篇文章關於推送證書配置的,特別是對於新手很有用,可以去看看. http://www.cnblogs.com/wolfhous/p/5344871.html http://www.cnblogs.com/wolfhous/p/5344853.html 開始集成極光推送 1,官網下載sdk以及d ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類