信息來(lái)源：紅黑聯(lián)盟  

這次iOS 9.2.1最新更新中蘋(píng)果修復(fù)了一個(gè)代碼執(zhí)行漏洞，是由Zimperium zLabs的兩位研究員Nikias Bassen和Joshua J. Drake在syslogd里的發(fā)現(xiàn)的。

在這篇文章里，我們將分享如何確定該漏洞以及漏洞背后可以讓攻擊者以Root權(quán)限在6.0到9.2版本的iOS設(shè)備上執(zhí)行代碼的技術(shù)細(xì)節(jié)。

起初，我們?cè)跈z查過(guò)程中發(fā)現(xiàn)模糊測(cè)試器跳過(guò)了syslog的代碼，但一當(dāng)我們調(diào)查測(cè)試崩潰的問(wèn)題時(shí)，它就對(duì)syslogd的開(kāi)源部分進(jìn)行了全面審查。因此我們才從中確定了syslogd代碼的bug并確實(shí)成功地觸發(fā)了崩潰。然后我們通知蘋(píng)果公司并與其安全團(tuán)隊(duì)共同合作來(lái)解決問(wèn)題。蘋(píng)果公司迅速作出反應(yīng)。 完整的安全公告是如下：

受影響的組件：

受影響的平臺(tái)和版本：

供應(yīng)商

CVE:

最新公開(kāi)的源代碼版本：

披露時(shí)間

概要

內(nèi)存重新分配過(guò)程中大小計(jì)算錯(cuò)誤導(dǎo)致在建立多個(gè)客戶端連接的時(shí)候syslogd的堆緩沖區(qū)溢出。

影響

本地權(quán)限提升，遠(yuǎn)程代碼執(zhí)行（WiFi下信任的設(shè)備）或DoS攻擊

介紹

Syslogd進(jìn)程是通過(guò)iOS的root權(quán)限運(yùn)行的。我們發(fā)現(xiàn)一個(gè)堆溢出漏洞會(huì)導(dǎo)致內(nèi)存受到破壞，并且在某些情況下可能會(huì)導(dǎo)致任意代碼的執(zhí)行。超出堆緩沖區(qū)邊界的數(shù)據(jù)會(huì)被文件描述符的值覆蓋。而且有一些操作也會(huì)允許對(duì)寫(xiě)入值的控制。不過(guò)想要利用這個(gè)漏洞可不簡(jiǎn)單。

背景

在設(shè)備上運(yùn)行的軟件可以以USB接口的方式或者通過(guò)將設(shè)備設(shè)置在相同WiFi網(wǎng)絡(luò)上遠(yuǎn)程連接到syslog中繼服務(wù)（com.apple.syslog_relay）來(lái)訪問(wèn)該設(shè)備的系統(tǒng)日志（syslog）。不過(guò)前提是無(wú)論使用哪個(gè)媒體，設(shè)備必須被配置為信任機(jī)才可以連接到服務(wù)。也就是說(shuō)，必須要先“配對(duì)”。

由于密碼鎖定的設(shè)備只能在解鎖的情況下才與一臺(tái)電腦配對(duì)，那么在不受信任的設(shè)備上利用這個(gè)漏洞就需要密碼。而且設(shè)備上運(yùn)行的第三方應(yīng)用程序也沒(méi)有辦法直接與syslogd連接。

細(xì)節(jié)

這個(gè)漏洞的根本原因在于源文件syslogd.tproj / dbserver.c的add_lockdown_session函數(shù)中。在執(zhí)行這個(gè)函數(shù)的時(shí)候，程序員需要給數(shù)組重新分配內(nèi)存大小。下圖是代碼有問(wèn)題的一部分：

第170行是問(wèn)題的根源。傳遞給reallocf函數(shù)的大小算錯(cuò)了。這個(gè)代碼應(yīng)該是為每一個(gè)新的連接生成四個(gè)字節(jié)的時(shí)域文件描述符數(shù)組，但從運(yùn)算符優(yōu)先級(jí)規(guī)則角度看計(jì)算出錯(cuò)了。代碼應(yīng)改為：

原代碼里是把整型數(shù)據(jù)字節(jié)數(shù)增加到時(shí)域數(shù)量，而上面代碼行是在時(shí)域數(shù)量后先加了1，然后再乘以sizeof（int）。這樣意義就不一樣了。

由于新版iOS和OS X的源代碼還無(wú)法獲得。我們需要通過(guò)二進(jìn)制文件的反匯編來(lái)證明出現(xiàn)在最新版本中的這個(gè)問(wèn)題。而且隨著運(yùn)算符優(yōu)先級(jí)規(guī)則的應(yīng)用和代碼在操作上進(jìn)行的優(yōu)化，反匯編讓問(wèn)題變得更加顯而易見(jiàn)了。下圖是iOS 9.0.2的syslogd二進(jìn)制反匯編：

同樣的問(wèn)題也在OS X的syslogd二進(jìn)制文件里和iOS 9.1里發(fā)現(xiàn),iOS 9.1甚至不需要多次連接到com.apple.syslog_relay服務(wù)來(lái)檢查二進(jìn)制文件就可以確認(rèn)了。只要堆內(nèi)重要的數(shù)據(jù)被破壞了，syslogd就會(huì)崩潰。下圖是OS X 10.11.1的syslogd二進(jìn)制反匯編：

請(qǐng)注意一下編譯器在這兩個(gè)版本中如何將“1 *sizeof（int）”簡(jiǎn)化為“sizeof（int）”，這使漏洞更加明顯。

當(dāng)一個(gè)新的客戶端連接時(shí)，函數(shù)被第一次調(diào)用，執(zhí)行時(shí)這個(gè)函數(shù)給初始緩沖器分配了第一個(gè)用于連接的文件描述符。因?yàn)閟izeof（int）的值一直是定值4，第一次 global.lockdown_session_count值為0，計(jì)算出的大小是正確的4個(gè)字節(jié)。但是當(dāng)?shù)诙€(gè)新的客戶端連接時(shí)，global.lockdown_session_count值變成了1，緩沖區(qū)大小就會(huì)被錯(cuò)誤地計(jì)算為5個(gè)字節(jié)。以此類推，第三個(gè)連接的大小是6個(gè)字節(jié)。

如果開(kāi)發(fā)商把新的連接的文件描述符存儲(chǔ)在global.lockdown_session_fds數(shù)組里，隨著字節(jié)數(shù)越來(lái)越大就會(huì)發(fā)生實(shí)際的堆溢出。下圖是syslogd中的syslogd.tproj / dbserver.c源文件代碼摘錄：

第179行的代碼，同時(shí)也是上面反匯編的最后一行，表示了代碼在沒(méi)有足夠內(nèi)存分配的緩沖器里溢出寫(xiě)入4個(gè)字節(jié)。由于內(nèi)存分配通常會(huì)四舍五入為8個(gè)字節(jié)，所以建立兩個(gè)連接不會(huì)破壞內(nèi)存。而創(chuàng)建第三個(gè)連接后，文件描述符就會(huì)寫(xiě)出界然后可能導(dǎo)致堆內(nèi)存的損壞。

當(dāng)然，有時(shí)內(nèi)存損壞發(fā)生可能需要不止三個(gè)連接才能使syslogd崩潰。但是，這取決于堆塊后的數(shù)據(jù)在利用后是否或如何被破壞。在我們的測(cè)試中syslogd中止執(zhí)行是因?yàn)閞emove_lockdown_session函數(shù)中堆損壞。