最近Linux 內核爆出了一個嚴重的安全漏洞，非root用戶可以通過該漏洞的exploit 獲取root權限。這并不罕見，值得一提的是這個補丁看起來如此平常以至于我們絕大多數人都不會以為這是安全問題。

先看這個問題的補丁，就是下面這個：

 static int perf_swevent_init(struct perf_event *event)
 {-	int event_id = event->attr.config;+	u64 event_id = event->attr.config;

 	if (event->attr.type != PERF_TYPE_SOFTWARE)
 		return -ENOENT;

我們第一眼的感覺就是這大概只是修復了編譯器報的一個小警告吧，怎么會引起如此嚴重的安全問題呢?

在沒打補丁的代碼中 event_id 是個帶符號的整型，而且就在下面不遠處的兩行代碼中只檢查了其上界：

if (event_id>= PERF_COUNT_SW_MAX)
                return -ENOENT;

而如果傳遞進來的 event->attr.config 值正好設置了符號位，那么 event_id 就會變成負值，而且能躲過上面的檢查。

負值意味著什么呢?再繼續看后面的代碼：

 if (!event->parent) {
                int err;
 
                err = swevent_hlist_get(event);
                if (err)
                        return err;
 
                atomic_inc(&perf_swevent_enabled[event_id]);
                event->destroy = sw_perf_event_destroy;
        }

意味著數組越界!這時你應該身上開始冒冷汗了。繼續，數組 perf_swevent_enabled[] 在 RHEL6 上的定義是：

atomic_t perf_swevent_enabled[PERF_COUNT_SW_MAX];

而 atomic_t 基本上就是int，也就是說 perf_swevent_enabled[] 是整型數組，那么用 event_id 訪問該數組時會把 event_id 的值乘以4再加上數組的起始地址。很簡單哈!

好，通過 System.map 文件我們可以得到 perf_swevent_enabled 的地址：

ffffffff81f360c0 B perf_swevent_enabled

那么當 event->attr.config == 0xffffffff (即有符號的-1)時，在 x86_64 上面我們最終會得到：

0xffffffffffffffff * 4 + 0xffffffff81f360c0 == 0xFFFFFFFF81F360BC

同理，當 event->attr.config == 0xfffffffe 時我們得到：

0xfffffffffffffffe * 4 + 0xffffffff81f360c0 == 0xFFFFFFFF81F360B8

所以上述的 atomic_inc() 其實增加的是前面兩個地址中存放的值，而這倆地址都指向內核空間(參見 Documentation/x86/x86_64/mm.txt)!這時你應該感到緊張了。。。

后面更有趣的事情發生在 sw_perf_event_destroy() 函數中，它是在 perf_event_open() 返回的 fd 被關閉時被調用，RHEL6 上其定義如下：

static void sw_perf_event_destroy(struct perf_event *event){
        u64 event_id = event->attr.config;
 
        WARN_ON(event->parent);
 
        atomic_dec(&perf_swevent_enabled[event_id]);
        swevent_hlist_put(event);}

很明顯的不同是，event_id 這次是無符號的類型。那么，同上，當 event->attr.config == 0xffffffff 時我們得到：

0xffffffff * 4 + 0xffffffff81f360c0 == 0x0000000381F360BC

當 event->attr.config == 0xfffffffe 時我們得到：

0xfffffffe * 4 + 0xffffffff81f360c0 == 0x0000000381F360B8

所以這里的 atomic_dec() 實際上減小的是用戶空間地址內的值。

上面是“基礎知識”，帶著這些知識我們看 exploit 代碼究竟做了什么，代碼片段如下：

#define BASE 0x380000000

#define SIZE 0x010000000

assert((map = mmap((void*)BASE, SIZE, 3, 0x32, 0,0)) == (void*)BASE);

memset(map, 0, SIZE);

sheep(-1); sheep(-2); // sheep will just invoke perf_event_open

// syscall with attr.config set to the param

for (i = 0; i 

assert(map[i+1]);

break;

}

它首先會 mmap() 起始地址是 0×380000000 的一塊內存區域。然后分別以 attr.config 為 -1 和 -2 調用兩次 perf_event_open()。根據前面的計算，它實際上分別增加了 0xFFFFFFFF81F360BC 和 0xFFFFFFFF81F360B8 兩處內存的值，減少了 0x0000000381F360BC 和 0x0000000381F360B8 的值。后面的 for 循環則是找出被減少的內存地址，這樣一來也就可以算出 perf_swevent_enabled[] 數組的地址(System.map 并不總是存在，如果存在而且可讀我們當然可以直接去讀這個值)。

知道這個地址我們就可以操縱內核中某處的32bit的值，把其值加一。正因為如此，作者巧妙地選擇了中斷描述符表——一個16字節描述符的數組，它的地址可以通過 sidt 指令獲取。它其中的描述符結構定義如下：

Offset 	Size 	Description
0 	2 	Offset low bits (0..15)
2 	2 	Selector (Code segment selector)
4 	1 	Zero
5 	1 	Type and Attributes (same as before)
6 	2 	Offset middle bits (16..31)
8 	4 	Offset high bits (32..63)
12 	4 	Zero

這里最有趣的是 offset 為8 的地方，在 x86_64 上面其值為 0xffffffff。作者選擇的中斷描述符是 0×4，所以相對于中斷描述符表它的偏移實際上是 0×48。現在的任務就成了通過 perf_swevent_enabled[] 來計算出該中斷描述符中偏移為8的內存地址，并對其加一!下面的代碼就是做的這個工作：

sheep(-i + (((idt.addr&0xffffffff)-0x80000000)/4) + 16);

i 是我們前面在 for 循環中搜到的 perf_swevent_enabled[] 的一個偏移，idt.addr 是中斷描述符表的絕對內核地址，取其低32位并減去 0×80000000 是為了得到低28位作為偏移，除以4是因為數組是int，最后加的16就是 0×4 中斷描述符中的偏移(4已經除去了)，所以最終sheep()里面的參數就是我們想要的偏移，這樣以來內核就替我們把 0×4 中斷描述符中的偏移為 8 的 0xffffffff 加上了1，也就成了0，也就成了用戶空間的地址!所以后面的 int 0×4 其實就會跳轉到用戶空間早已經設置好的代碼!!!

而這段代碼比較生澀，但其意思就是更改當前進程的 uid/gid 為0來提升權限，所以最終取得一個有 root 權限的 shell!整個攻擊大功告成!

注：上面的鏈接可能不能用，exploit 代碼也可以在這里看到：https://gist.github.com/onemouth/5625174