當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

【译】BINDER - ANALYSIS AND EXPLOITATION OF CVE-2020-0041

發(fā)布時間：2025/3/15 编程问答 26 豆豆

生活随笔收集整理的這篇文章主要介紹了【译】BINDER - ANALYSIS AND EXPLOITATION OF CVE-2020-0041 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

2019年12月，在Linux內(nèi)核中推送了新的Binder提交。?此補丁修復(fù)了用于處理Binder事務(wù)中特定類型的對象的索引的計算。

本文研究了已更正問題的含義，為什么是安全漏洞以及如何利用它。

在閱讀本文之前，強烈建議先閱讀有關(guān)粘合劑內(nèi)部的文章。

補丁概述

差異--git a / drivers / android / binder.cb / drivers / android / binder.c 索引e9bc9fc..b2dad43 100644--- a /驅(qū)動程序/android/binder.c+++ b / drivers / android / binder.c@@ -3310,7 +3310,7 @@活頁夾大小struct binder_fd_array_object * fda =to_binder_fd_array_object（hdr）;-size_t num_valid =（buffer_offset-off_start_offset）*+ size_t num_valid =（buffer_offset-off_start_offset）/sizeof（binder_size_t）;struct binder_buffer_object *父=binding_validate_ptr（target_proc，t-> buffer，@@ -3384,7 +3384,7 @@t->緩沖區(qū)-> user_data + sg_buf_offset;sg_buf_offset + = ALIGN（bp-> length，sizeof（u64））;-num_valid =（buffer_offset-off_start_offset）*+ num_valid =（buffer_offset-off_start_offset）/sizeof（binder_size_t）;ret = binding_fixup_parent（t，線程，bp，off_start_offset，

該修補程序修復(fù)了num_valid索引的計算，該索引在binder_fixup_parent()的調(diào)用中用作參數(shù)。?乘號*被除法/代替。

當(dāng)活頁夾事務(wù)包含活頁夾對象時，偏移量列表將給出不同活頁夾對象在事務(wù)緩沖區(qū)中的位置。

活頁夾交易的沖銷緩沖區(qū)

讓我們舉個例子，如果對象的偏移量為0x10?（上圖中的對象BINDER_TYPE_PTR C），則索引的正確值應(yīng)為0x2?：

//正確的版本size_t num_valid = （buffer_offset - off_start_offset） / sizeof （binder_size_t）;/ *如果（buffer_offset-off_start_offset）= 0x10num_valid = 0x10 / 0x8num_valid = 0x2* /

在易受攻擊的版本中，計算得出的值為0x80?。

//版本不正確size_t num_valid = （buffer_offset - off_start_offset） * sizeof （binder_size_t）;/ *如果（buffer_offset-off_start_offset）= 0x10num_valid = 0x10 * 0x8num_valid = 0x80* /

那是完全不同的！?越野車版本允許通過偏移緩沖區(qū)（藍色）發(fā)送帶有父索引的活頁夾對象。

偏移緩沖區(qū)越界

函數(shù)binder_validate_ptr()使用num_valid并檢查兩件事：

如果給定索引（此處為off_start_offset?）小于num_valid?，則該函數(shù)僅信任已處理的對象。
在索引（?off_start_offset?）中找到的偏移量處是否存在有效的binder_buffer_object?（使用幻數(shù)進行檢查）。

//drivers/android/binder.c靜態(tài) 整數(shù) bind_fixup_parent （ struct bind_transaction * t，struct binder_thread * 線程，struct binder_buffer_object * bp，binding_size_t off_start_offset，binding_size_t num_valid，binding_size_t last_fixup_obj_off，活頁夾大小（ t last_fixup_min_off）{// [...]如果（！（ bp- > 標(biāo)志和 BINDER_BUFFER_FLAG_HAS_PARENT））返回 0 ;父 = 粘結(jié)劑有效期_ptr（target_proc， b 和對象， bp- > 父，off_start_offset 和 parent_offset，num_valid）; //drivers/android/binder.c靜態(tài) 結(jié)構(gòu) binder_buffer_object * binder_validate_ptr （struct binder_proc * proc，結(jié)構(gòu) binder_buffer * b，struct binder_object * 對象，活頁夾大小索引binding_size_t start_offset，活頁夾大小 *對象偏移量，binding_size_t num_valid）{// [...]如果（索引 > = num_valid）返回 NULL;buffer_offset = 起始偏移量 + sizeof （binder_size_t） * 索引;binding_alloc_copy_from_buffer（＆ proc- > alloc，＆ object_offset，b， buffer_offset， sizeof （object_offset））；object_size = binding_get_object（proc， b， object_offset， object）;如果（！ object_size || object- > hdr.type ！= BINDER_TYPE_PTR）返回 NULL;// [...]

即使父索引存在出界（讀訪問），也只能訪問內(nèi)存的有限部分，因為內(nèi)核會驗證內(nèi)存在接收方事務(wù)緩沖區(qū)中。?此外，在對象的開始處需要一個幻數(shù)，因此偏移量必須指向該幻數(shù)。?此外，如果魔術(shù)不正確，內(nèi)核不會泄漏該值。

目前，該錯誤的影響很難看到。?要了解可能的利用，我們需要對Binder中的對象父系統(tǒng)有更好的了解。

有活頁夾的父母

活頁夾對象BINDER_TYPE_PTR和BINDER_TYPE_FDA具有一個字段parent和parent_offset?，該字段允許在父緩沖區(qū)內(nèi)修補指針。?此功能由HIDL語言（硬件服務(wù)）使用，并且在上一則有關(guān)資料夾內(nèi)部的文章中進行了解釋。

HIDL_STING示例

hidl_string結(jié)構(gòu)是使用BINDER_TYPE_PTR父母的一個很好的例子。

//從system / libhidl / base / include / hidl / HidlSupport.h中提取struct hidl_memory {// ...私人的：hidl_handle mHandle __attribute__ （（aligned（ 8 ）））;uint64_t mSize __attribute__ （（aligned（ 8 ）））;hidl_string mName __attribute__ （（aligned（ 8 ）））;};

當(dāng)進程A?hidl_string進程B發(fā)送hidl_string?，該結(jié)構(gòu)包含一個屬于進程A的指針。為了使該結(jié)構(gòu)在接收方進程內(nèi)存中有效，Binder驅(qū)動程序必須通過屬于該內(nèi)存空間的指針對其進行更改。這是由BINDER_TYPE_PTR?parent和parent_offset字段完成的。

// BINDER_TYPE_PTR的結(jié)構(gòu)structinder_object_header {__u32 類型；};structinder_buffer_object {結(jié)構(gòu) binder_object_header hdr;__u32 標(biāo)志；binding_uintptr_t 緩沖區(qū)；binding_size_t 長度；binding_size_t 父對象； //父對象的索引（在偏移緩沖區(qū)中）活頁夾大小 //偏移以修補父緩沖區(qū)};

為了發(fā)送hidl_string?，第一個緩沖區(qū)（A）用于發(fā)送hidl_memory?C結(jié)構(gòu)，第二個緩沖區(qū)（B）用于存儲實際字符串（在這種情況下為“我的演示字符串”）。?緩沖區(qū)A是B的父級，而A的偏移量0是使用目標(biāo)過程存儲器中字符串的地址修補的。

帶有hidl_string的Binder父示例

家長修正規(guī)則

一些規(guī)則限制了在綁定對象中使用父對象。?當(dāng)然，在調(diào)用此檢查之前，綁定程序內(nèi)核已經(jīng)檢查了指向緩沖區(qū)及其大小的指針是否有效（指向調(diào)用者內(nèi)存的指針）。

通過調(diào)用binder_fixup_parent()檢查有關(guān)父代活頁夾對象層次結(jié)構(gòu)的這些規(guī)則。

內(nèi)核應(yīng)用的規(guī)則如下：

通過活頁夾檢查規(guī)則（）

[1]父索引必須小于或等于num_valid?。?內(nèi)核已驗證num_valid之前的所有對象。

通過活頁夾檢查規(guī)則（）

[2]僅允許對已驗證的最后一個緩沖區(qū)對象或其父對象進行修復(fù)
[3]我們僅允許緩沖區(qū)內(nèi)的修正在偏移增加時發(fā)生

對于本文的下一部分，這些以前的規(guī)則已由[1]到[3]的數(shù)字標(biāo)識。

規(guī)則檢查示例（有效）

為了驗證事務(wù)的所有綁定程序?qū)ο?#xff0c;內(nèi)核會按照它們在偏移緩沖區(qū)中注冊的順序檢查它們。?請記住，此緩沖區(qū)包含一個偏移量列表，其中活頁夾對象存儲在事務(wù)數(shù)據(jù)緩沖區(qū)中。

有效的活頁夾父母

此示例有效，并遵守所有規(guī)則。

規(guī)則檢查示例（無效1）

無效的父級偏移

該示例無效，因為它違反了規(guī)則[3]：

我們只允許緩沖區(qū)內(nèi)的修正以增加的偏移量發(fā)生

規(guī)則檢查示例（無效2）

在下圖中，內(nèi)核檢查與對象D對應(yīng)的偏移量時，驗證失敗。

無效的父母

該示例無效，因為它違反了規(guī)則[2]：

僅允許對最后一個經(jīng)過驗證的緩沖區(qū)對象或其父對象進行修復(fù)

在我們的例子中，最后一個驗證的對象是C?，而對象D的父對象是B。?但是B不是C或A?（C的父母）。?層次結(jié)構(gòu)無效。

如何利用漏洞？

利用此錯誤的一種有趣方法是使父緩沖區(qū)的字段buffer和length具有任意值。

該錯誤允許輕松繞過規(guī)則[1]，但是很難繞過規(guī)則[3]。

開發(fā)理念

訣竅是在驗證過程中更改父級層次結(jié)構(gòu)。?這可以使用extra緩沖區(qū)來完成！?確實，內(nèi)核使用緩沖區(qū)的這一部分來存儲與BINDER_TYPE_PTR對象有關(guān)的數(shù)據(jù)。?如果活頁夾對象的父索引指向該多余部分，則當(dāng)內(nèi)核在此位置復(fù)制數(shù)據(jù)時，其父對象將被更改。

內(nèi)核驗證-初始配置

要執(zhí)行此漏洞利用，需要具有以下層次結(jié)構(gòu)的三個緩沖區(qū)對象（添加一個未在偏移列表中注冊的緩沖區(qū)）：

對象D包含任意數(shù)據(jù)。

我們在計算num_valid使用此漏洞為對象B和C設(shè)置相同的父對象，并設(shè)置其父索引引用額外的數(shù)據(jù)部分（紫色區(qū)域）。?在驗證之前，多余的部分未初始化，并且包含以前的活頁夾交易記錄的數(shù)據(jù)。?這些數(shù)據(jù)可以通過發(fā)送事務(wù)并使用所需的offset A值向緩沖區(qū)噴灑來控制。

內(nèi)核驗證-選中C時暫停

內(nèi)核從offset A開始檢查偏移量列表中包含的對象。?直到C的所有對象都是有效的。?每次處理對象時，都會如下圖所示在多余部分中復(fù)制其相關(guān)緩沖區(qū)。

該圖顯示了算法的狀態(tài)。?內(nèi)核已經(jīng)檢查了緩沖區(qū)A和B?，但未檢查對象C。?此時，?parent_index的偏移量值尚未修改（設(shè)置為與offset A對應(yīng)的值），并且最后一個驗證的對象為B。

內(nèi)核驗證-對象C

活頁夾驅(qū)動程序處理對象C時，它首先在多余的部分復(fù)制其緩沖區(qū)。?但是，此副本將覆蓋parent_index的先前值。?準(zhǔn)備緩沖器C的數(shù)據(jù)以用與對象D相對應(yīng)的新值來改變該值。

此時，父母的等級會發(fā)生變化！

遵守所有規(guī)則！?實際上，?C的父對象（此處為D?）必須是最后一個經(jīng)過驗證的對象或其父對象之一。

使用此配置，我們已繞過了binder_validate_ptr()和binder_validate_fixup()

內(nèi)核驗證-父修補

一旦對象C通過所有檢查，內(nèi)核便通過調(diào)用函數(shù)binder_alloc_copy_to_buffer()修補父緩沖區(qū)。

//提取binder.c靜態(tài) 詮釋粘結(jié)劑_固定up_父母（...）{//在這里檢查規(guī)則[...]buffer_offset = bp- > parent_offset +（ uintptr_t ） parent- > 緩沖區(qū) - （ uintptr_t ）b- > user_data;binding_alloc_copy_to_buffer（＆ target_proc- > alloc， b， buffer_offset，＆ bp- > 緩沖區(qū)， sizeof （bp- > 緩沖區(qū)））;

請記住，執(zhí)行此代碼時，不會映射目標(biāo)進程。

所有/ dev / binder設(shè)備都可以在內(nèi)核內(nèi)存中訪問。?用戶界面進程映射了活頁夾文件描述符時。?內(nèi)核分配頁面（在此處使用kzalloc），并將這些頁面映射到進程內(nèi)存中。

在綁定程序事務(wù)期間，內(nèi)核可以通過在接收方進程的內(nèi)存地址上應(yīng)用偏移量來檢索此分配的內(nèi)核地址。?在正常調(diào)用中，?parent->buffer的值屬于目標(biāo)進程的/dev/binder內(nèi)存，因為該值先前是在處理父對象時由內(nèi)核修補的。?驅(qū)動程序可以通過以下計算獲得相應(yīng)的內(nèi)核地址：

kernel_proc_buffer = 父 -> 緩沖區(qū) -b- > user_data

使用我們的漏洞，我們可以部分控制kernel_proc_buffer因為b->user_data是未知的。

寫入父緩沖區(qū)的值（加上偏移量）是當(dāng)前對象的地址（在我們的示例中，是目標(biāo)進程內(nèi)存中對象C的地址：另外）

不幸的是，對于我們的利用而言，函數(shù)binder_alloc_copy_to_buffer()對要修補的地址執(zhí)行了附加檢查。

//在drivers / android / binder_alloc.c中int binding_alloc_copy_to_buffer （ struct binder_alloc * alloc，struct binder_buffer * 緩沖區(qū)，binding_size_t buffer_offset，無效 * src，size_t 字節(jié)）{return binding_alloc_do_buffer_copy（alloc， true， buffer， buffer_offset，src，字節(jié)）；}靜態(tài) 整數(shù) bind_alloc_do_buffer_copy （ struct binder_alloc * alloc，bool to_buffer，struct binder_buffer * 緩沖區(qū)，binding_size_t buffer_offset，無效 * ptr，size_t 字節(jié)）{/ *所有副本必須對齊32位且大小為32位* /BUG_ON（！ check_buffer（分配，緩沖區(qū)， buffer_offset，字節(jié)））;// [...]

函數(shù)binder_alloc_do_buffer_copy()檢查要修補的緩沖區(qū)是否在當(dāng)前綁定程序事務(wù)的當(dāng)前接收緩沖區(qū)內(nèi)。

此漏洞利用不允許針對內(nèi)核內(nèi)存?。

可以注意到，如果地址無效，內(nèi)核將調(diào)用BUG_ON?，這將停止內(nèi)核執(zhí)行。

通過繞過所有檢查，我們可以將任意值設(shè)置為parent->buffer但是我們只能嘗試一次，否則內(nèi)核將停止！?我們需要內(nèi)存泄漏才能知道目標(biāo)進程中/dev/binder的地址。

為了驗證該理論，讓我們來看一下所描述的利用工作。?由于尚未發(fā)生泄漏，因此我們在Android仿真器中運行了經(jīng)過修改的內(nèi)核。

靜態(tài) void binder_alloc_do_buffer_copy （ struct binder_alloc * alloc，bool to_buffer，struct binder_buffer * 緩沖區(qū)，binding_size_t buffer_offset，無效 * ptr，size_t 字節(jié)）{如果（！ check_buffer（alloc， buffer， buffer_offset， bytes））{size_t buffer_size = binder_alloc_buffer_size（alloc， buffer）;pr_info（ “ [JB] check_buffer buffer_size：0x％lx字節(jié)= 0x％lx偏移量= 0x％lx \ n ” ， buffer_size，字節(jié)， buffer_offset）;}/ *所有副本必須對齊32位且大小為32位* /BUG_ON（！ check_buffer（分配，緩沖區(qū)， buffer_offset，字節(jié)））;

添加了調(diào)試打印（調(diào)用pr_info()?，以檢查buffer_offset值是否無效）

POC

自定義內(nèi)核（基于msm-bonito-4.9-android10）與Pixel 3a XL固件一起啟動。?PoC使用先前圖中描述的父層次結(jié)構(gòu)將綁定程序事務(wù)發(fā)送到servicemanager器。

。 / 模擬器 -AVD Pixel_3a_XL_API_29_64b- 內(nèi)核 custom_bzImage- 顯示 - 內(nèi)核 - 否 - 窗口 - 詳細 - 隨機 - 否 - 快照 [148.291702]活頁夾：3410：3410 ioctl c0306201 7fff98cb5f20返回-22[148.295022] binding_alloc：[JB] check_buffer buffer_size：0x10e0字節(jié)= 0x8偏移量= 0x71829fdc8b8[148.299460] ------------ [在此處剪切] ------------[148.301159]內(nèi)核BUG位于drivers / android / binder_alloc.c：1133！[148.303042]無效的操作碼：0000 [＃1] PREEMPT SMP NOPTI[148.304537]模塊鏈接在：[148.305422] CPU：0 PID：3410 Comm：poc未受污染4.14.150HELLO +＃28[148.307397]硬件名稱：QEMU Standard PC（i440FX + PIIX，1996），BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014[148.311690]任務(wù)：0000000086b3eedc task.stack：0000000000a1c204[148.313730] RIP：0010：binder_alloc_do_buffer_copy + 0x8d / 0x15e[148.315692] RSP：0018：ffffa11501effa48 EFLAGS：00010246[148.317540] RAX：0000000000000000 RBX：ffff9e98a62079c0 RCX：0000000000000008[148.320403] RDX：ffff9e98aa0e5dd8 RSI：0000000000000000 RDI：ffff9e98aa0e5da0[148.323268] RBP：ffffa11501effaa0 R08：0000000000000ff4 R09：0000000000000000[148.325435] R10：0000000000000000 R11：0000000000000000 R12：0000000000000008[148.328290] R13：0000071829fdc8b8 R14：ffff9e98aa0e5da0 R15：ffff9e98a62079c0[148.330194] FS：000000000048d648（0000）GS：ffff9e98bfc00000（0000）knlGS：0000000000000000[148.331780] CS：0010 DS：0000 ES：0000 CR0：0000000080050033[148.332740] CR2：00007435311239a0 CR3：0000000010ee2000 CR4：00000000000006b0[148.333848]通話跟蹤：[148.334207] binding_alloc_copy_to_buffer + 0x1a / 0x1c[148.334895] binding_fixup_parent + 0x186 / 0x1ac

調(diào)試字符串證明PoC起作用，因為偏移量值無效（0x71829fdc8b8的偏移量很大！）

活頁夾分配器： [JB] check_buffer buffer_size ： 0x10e0 字節(jié) = 0x8 偏移量 = 0x71829fdc8b8

/ dev / binder的內(nèi)存映射泄漏

在不知道目標(biāo)進程的內(nèi)存映射的情況下，此PoC幾乎是沒有用的:(。但是，沒有丟失任何信息！

Android Java應(yīng)用程序具有特定性，它們都是Zygote或Zygote64?（取決于32/64位）。

Zygote是帶有預(yù)初始化的Java虛擬機的進程。?當(dāng)系統(tǒng)需要啟動新的Java應(yīng)用程序時，?Zygote被派生并開始執(zhí)行該應(yīng)用程序。?這種設(shè)計可以減少初始化步驟。?Java應(yīng)用程序可以盡快啟動。?但是，在執(zhí)行對fork()的調(diào)用時，虛擬內(nèi)存將被克隆，因此其內(nèi)存映射也將被克隆。?因此，Zygote的所有孩子都共享相同的映射。

讓我們檢查一下模擬器：

根1612 1 4758476 190144 poll_schedule_timeout 0 S zygote64...u0_a103 3891 1612 4927284 124964 SyS_epoll_wait 0 S com.foo.mypoc cat / proc / $（pidof com.foo.mypoc）/ maps | grep“ / dev / binder”7a6242192000-7a6242290000 r--p 00000000 00:12 7315 / dev

假設(shè)我們可以將任意代碼作為com.foo.mypoc包執(zhí)行，通過檢查進程內(nèi)存映射，可以找到/dev/binder的映射位置。?在我們的情況下，它映射為0x7a6242192000?。

進程com.foo.mypoc是從zygote64分叉的。?其他與同一個母親一起的過程如下：

generic_x86_64：/＃ps -e | grep $（pidof zygote64）根1612 1 ... zygote64 系統(tǒng)1845 1612 ... system_serveru0_a89 1996 1612 ... com.android.systemuinetwork_stack 2118 1612 ... com.android.networkstackradio 2199 1612 ... com.android.phone 系統(tǒng)2210 1612 ... com.android.settingsu0_a55 2261 1612 ... android.ext.servicesu0_a84 2296 1612 ... com.android.launcher3u0_a102 2321 1612 ... com.android.inputmethod.latinu0_a87 2436 1612 ... com.android.dialeru0_a37 2465 1612 ... android.process.acoresecure_element 2553 1612 ... com.android.se 無線電2586 1612 ... com.android.ims.rcsservice 系統(tǒng)2626 1612 ... com.android.emulator.multidisplayu0_a77 2686 1612 ... com.android.smspushu0_a67 2705 1612 ... com.android.printspooleru0_a40 2787 1612 ... android.process.mediau0_a97 2884 1612 ... com.android.emailu0_a78 2947 1612 ... com.android.messagingu0_a81 2971 1612 ... com.android.onetimeinitializeru0_a52 3005 1612 ... com.android.packageinstalleru0_a54 3027 1612 ... com.android.permissioncontrolleru0_a39 3050 1612 ... com.android.providers.calendaru0_a62 3075 1612 ... com.android.traceuru0_a41 3097 1612 ... com.android.externalstorage 系統(tǒng)3134 1612 ... com.android.localtransport 系統(tǒng)3230 1612 ... com.android.keychainu0_a103 3891 1612 ... com.foo.mypoc

軟件包com.android.settings看起來很有趣，因為它作為system運行。

generic_x86_64：/＃cat / proc / $（pidof com.android.settings）/ maps | grep“ / dev / binder”7a6242192000-7a6242290000 r--p 00000000 00:12 7315

實際上，綁定器設(shè)備與我們的應(yīng)用程序com.foo.mypoc映射在同一位置！

開發(fā)思路

使用先前的PoC和目標(biāo)進程的內(nèi)存映射，可以覆蓋與已驗證的活頁夾對象有關(guān)的數(shù)據(jù)。

Userland綁定程序庫（?libbinder.so和libhwbinder.so?）信任綁定程序驅(qū)動程序處理，并認為所有綁定程序?qū)ο缶颜_打補丁。?如果修補程序未正確完成，則在宗地反序列化步驟中，應(yīng)用程序可能很容易受到攻擊。

文件描述符

覆蓋BINDER_TYPE_FDA修補的對象，使其指向BINDER_TYPE_FDA且未經(jīng)檢查的文件描述符列表。?我們可以想象在目標(biāo)進程中關(guān)閉任意文件描述符，以將其替換為受控文件描述符。

活頁夾緩沖區(qū)

覆蓋BINDER_TYPE_PTR對象的大小。?如果使用該漏洞更改了嵌入式緩沖區(qū)結(jié)構(gòu)（如hidl_string?）的大小字段，則新值將是一個指針，并且對于正確的緩沖區(qū)無效。

詳細信息 :: hidl_pointer < const char > mBuffer;uint32_t mSize; //嘗試覆蓋大小bool mOwnsBuffer;

活頁夾/句柄對象

覆蓋BINDER_TYPE_HANDLE?/?BINDER_TYPE_WEAK_HANDLE對象的指針。?當(dāng)綁定程序內(nèi)核模塊處理這些對象時，它將在遠程進程中用其原始指針值替換處理程序。?內(nèi)核在其內(nèi)存中保留處理程序/指針之間的映射，并使用此表修復(fù)BINDER_TYPE_HANDLE或BINDER_TYPE_BINDER?。?有時，遠程服務(wù)需要實例化對象以執(zhí)行命令。?要使用此對象，客戶端將發(fā)送一個對象句柄（?BINDER_TYPE_HANDLE?）。?內(nèi)核將其替換為BINDER_TYPE_BINDER?，該對象在目標(biāo)接收緩沖區(qū)中包含實際指針。

如果攻擊者使用該漏洞替換了BINDER_TYPE_BINDER對象指針，則他可以控制該對象類型的所有字段以獲取代碼執(zhí)行BINDER_TYPE_BINDER?。

正常交易

對象指向受控數(shù)據(jù)

結(jié)論

對這個錯誤及其利用方法的分析非常有趣且新穎。?它允許與活頁夾父母一起玩。

即使此漏洞不允許定向內(nèi)核內(nèi)存，也可能導(dǎo)致利用特權(quán)更高的應(yīng)用程序。

本文完成的分析只是利用此漏洞所需的第一步。?將這些原語轉(zhuǎn)換為實際的權(quán)限提升漏洞需要大量的工作。

我認為，在將代碼添加到Linux內(nèi)核源代碼之前，請仔細檢查一下該錯誤。?我的陳述與我先前對secctx patch進行的補丁分析相同，最近在內(nèi)核源代碼中插入了幾個“簡單”的錯誤。

幸運的是，此最新漏洞僅影響了少數(shù)設(shè)備（Android 10上的Pixel 4和3a）。

總結(jié)

以上是生活随笔為你收集整理的【译】BINDER - ANALYSIS AND EXPLOITATION OF CVE-2020-0041的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇：《深入理解java虚拟机》第2章 Jav
下一篇：链表队列初始化