CVE-2015-1805漏洞解析及驗證
轉載自：https://www.anquanke.com/post/id/83682
0x0 漏洞資訊
影響所有Nexus手機和部分Android手機的漏洞,Google於2016/03/18釋出了公告修復,具體請看連結.
http://www.cvedetails.com/cve-details.php?t=1&cve_id=cve-2015-1805X
http://source.android.com/security/advisory/2016-03-18.html
0x1 漏洞描述
在linux 核心3.16版本之前的fs/pipe.c當中,由於pipe_read和pipe_write沒有考慮到拷貝過程中資料沒有同步的一些臨界情況,造成了拷貝越界的問題,因此有可能導致系統crash以及系統許可權提升.這種漏洞又稱之為” I/O vector array overrun”
0x2 程式碼分析
//摘自fs/pipe.c:
static ssize_t
pipe_read(struct kiocb *iocb, const struct iovec *_iov,
unsigned long nr_segs, loff_t pos)
{
struct file *filp = iocb (5)//在這裡更新total_len
total_len -= chars;
if (!total_len)
break; /* common path: read succeeded */
}
if (bufs) /* More to do? */
continue;
if (!pipe->writers)
break;
if (!pipe->waiting_writers) {
/* syscall merging: Usually we must not sleep
* if O_NONBLOCK is set, or if we got some data.
* But if a writer sleeps in kernel space, then
* we can wait for that data without violating POSIX.
*/
if (ret)
break;
if (filp->f_flags & O_NONBLOCK) {
ret = -EAGAIN;
break;
}
}
if (signal_pending(current)) {
if (!ret)
ret = -ERESTARTSYS;
break;
}
if (do_wakeup) {
wake_up_interruptible_sync_poll(&pipe->wait, POLLOUT | POLLWRNORM);
kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT);
}
pipe_wait(pipe);
}
__pipe_unlock(pipe);
/* Signal writers asynchronously that there is more room. */
if (do_wakeup) {
wake_up_interruptible_sync_poll(&pipe->wait, POLLOUT | POLLWRNORM);
kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT);
}
if (ret > 0)
file_accessed(filp);
return ret;
}(1).首先pipe_read()函式會先迴圈讀取iovec結構,並且通過iov_fault_in_pages_write()函式判斷iov->len是否大於0,且iov->base指向的地址是否可寫且處於使用者態,之後返回atomic.
(2)如果atomic=1,則pipe_iov_copy_to_user -> __copy_to_user_inatomic ->
__copy_to_user_nocheck;如果atomic=0,則pipe_iov_copy_to_user -> copy_to_user -> access_ok.
(3).如果atomic為1,pipe_iov_copy_to_user拷貝出現錯誤,會進入redo的邏輯,將再次呼叫pipe_iov_copy_to_user函式進行拷貝,且將atomic置為0.但是pipe_iov_copy_to_user的第三個引數chars並沒有更新,還是會拷貝total_len大小的資料
static int
pipe_iov_copy_to_user(struct iovec *iov, const void *from, unsigned long len,
int atomic)
{
unsigned long copy;
while (len > 0)
{
while (!iov->iov_len)
iov++;
copy = min_t(unsigned long, len, iov->iov_len);
if (atomic)
{
if (__copy_to_user_inatomic(iov->iov_base, from, copy))
//(4)
return -EFAULT;
}
else
{
if (copy_to_user(iov->iov_base, from, copy))
//(4)
return -EFAULT;
}
from += copy;
len -= copy;
iov->iov_base += copy;
//每次對iov->iov_len進行更新
iov->iov_len -= copy;
}
return 0;
}4. 如果copy到某種情況出錯返回,已經copy成功的iov->len會被減去但總長度total_len並不會同步減去.也就是說如果total_len是0x100,第一次消耗掉了x;再次進入redo邏輯後還是0x100,然而實際已經被消耗掉了x.
0x3 具體探究
假設有一個iov結構,total_len為0x40,len為0x20.
iov[0]: iov_base = 0xdead0000 iov_len = 0x10
iov[1]: iov_base = 0xdead1000 iov_len = 0x10
iov[2]: iov_base = 0xdead2000 iov_len = 0x10
iov[3]: iov_base = 0xdead3000 iov_len = 0x10
如果iov[1].iov_base的地址被設定成不可寫入.那麼第一次pipe_iov_copy_to_user()會返回失敗.而iov->iov_base += copy,iov->iov_len -= copy.
iov[0]: iov_base = 0xdead0010 iov_len = 0
iov[1]: iov_base = 0xdead1000 iov_len = 0x10
iov[2]: iov_base = 0xdead2000 iov_len = 0x10
iov[3]: iov_base = 0xdead3000 iov_len = 0x10
現在,redo的邏輯發生在0xdead0010,它以某種方式被設定成可寫,並且len仍未0x20.那麼iov[1]和iov[2]都將被用掉.
iov[0]: iov_base = 0xdead0010 iov_len = 0
iov[1]: iov_base = 0xdead1010 iov_len = 0
iov[2]: iov_base = 0xdead2010 iov_len = 0
iov[3]: iov_base = 0xdead3000 iov_len = 0x10
在註釋(5)中,根據total_len -= chars;那麼total_len的大小就被設定為0x20(0x40 -0x20).如果total_len變為了0x20,可我們iov[3]的大小隻有0x10.這就會導致pipe_iov_copy_to_user()函式有可能讀取到一個未知的iov[4].具體來檢視下程式碼
static int iov_fault_in_pages_write(struct iovec *iov, unsigned long len)
{
//(6)
while (!iov->iov_len)
iov++;
while (len > 0) {
unsigned long this_len;
this_len = min_t(unsigned long, len, iov->iov_len);
if (fault_in_pages_writeable(iov->iov_base, this_len))
break;
len -= this_len;
iov++;
}
return len;
}
static inline int fault_in_pages_writeable(char __user *uaddr, int size)
{
int ret;
if (unlikely(size == 0))
return 0;
/*
* Writing zeroes into userspace here is OK, because we know that if
* the zero gets there, we'll be overwriting it.
*/
ret = __put_user(0, uaddr);
if (ret == 0) {
char __user *end = uaddr + size - 1;
/*
* If the page was already mapped, this will get a cache miss
* for sure, so try to avoid doing it.
*/
if (((unsigned long)uaddr & PAGE_MASK) !=
((unsigned long)end & PAGE_MASK))
ret = __put_user(0, end);
}
return ret;
}在iov_fault_in_pages_write()函式中的註釋(6),也就意味著iov[0],iov[1],iov[2]都會被跳過,iov[3]被用掉.之後len -= this_len;len被設定為0x10.iov的指標將指向一塊未知的記憶體區域.iov[4].iov_base將被__put_user使用.
0x4 如何利用
核心的思路就是想辦法觸發redo的邏輯,之後精心構造一個readv()呼叫.把payload結構定義在已經被校驗過的iov陣列後,讓它成為__put_user()等函式呼叫的目標地址.如果我們再以某種方式讓構造的slab結構在iov陣列後包含一個函式指標,讓它指向要寫的核心地址.
1.第一次迴圈要保證pipe_iov_copy_to_user()函式失敗,這樣會進入redo邏輯
2.第二次要保證pipe_iov_copy_to_user()成功,但是不能在這裡overrun,否則會走向copy_to_user,要校驗地址,所以還是無法寫核心地址
3.當iov->len走完之後,total_len還有剩餘,所以第三次迴圈的時候,atomic=1.可以overrun觸發
4.第一次要保證失敗,也就是說需要把iov_base的地址設定成不可寫,第二次要成功,就要保證iov_base的地址有效.所以這裡可以通過建立競爭關係的執行緒,呼叫mmap/munmap等函式來實現.
0x5 POC
我測試的Nexus 6p 6.0.1系統會crash掉.
Talk is cheap,show me the code…
漏洞驗證資源：https://download.csdn.net/download/qq_35559358/10420702