Linux內核pwn之基礎rop提權

1. linux kernel pwn

kernel 也是一個程序，用來管理軟件發出的數據 I/O 要求，將這些要求轉義為指令，交給 CPU 和計算機中的其他組件處理，kernel 是現代操作系統最基本的部分。

以上便是ctf wiki原話 ，所以大家也不要太過于認為其很難，其實跟咱們用戶態就是不同而已，也可能就涉及那么些底層知識罷了（師傅輕噴，我就口嗨一下）。

而kernel 最主要的功能有兩點：

• 控制并與硬件進行交互

• 提供 application 能運行的環境

  包括I/O，權限控制，系統調用，進程管理，內存管理等多項功能都可以歸結到上邊兩點中。

需要注意的是，kernel 的crash 通常會引起重啟。（所以咱們這點調試的時候就挺不方便的了，相比于用戶態而言），不過這里也可能我剛開始學比較笨而已。

2. Ring Model(等級制度森嚴）

（1）intel CPU 將 CPU 的特權級別分為 4 個級別：Ring 0, Ring 1, Ring 2, Ring 3。

（2）Ring0 只給 OS 使用，Ring 3 所有程序都可以使用，內層 Ring 可以隨便使用外層 Ring 的資源。

（3）使用 Ring Model 是為了提升系統安全性，例如某個間諜軟件作為一個在 Ring 3 運行的用戶程序，在不通知用戶的時候打開攝像頭會被阻止，因為訪問硬件需要使用 being 驅動程序保留的 Ring 1 的方法。

注意大多數的現代操作系統只使用了 Ring 0 和 Ring 3。

3. syscall

也就是系統調用，指的是用戶空間的程序向操作系統內核請求需要更高權限的服務，比如 IO 操作或者進程間通信。系統調用提供用戶程序與操作系統間的接口，部分庫函數（如scanf，puts 等 IO 相關的函數實際上是對系統調用的封裝（read 和 write））。

4. 狀態轉換

user space to kernel space

當發生 系統調用，產生異常，外設產生中斷等事件時，會發生用戶態到內核態的切換，具體的過程為：

（1）通過swapgs切換 GS 段寄存器，將 GS 寄存器值和一個特定位置的值進行交換，目的是保存 GS 值，同時將該位置的值作為內核執行時的 GS 值使用。

（2）將當前棧頂（用戶空間棧頂）記錄在 CPU 獨占變量區域里，將 CPU 獨占區域里記錄的內核棧頂放入 rsp/esp。（這里我在調試的時候發現沒整rbp，我最開始就發現這里怎么只保存了rsp，這個問題暫時還不是很了解）

（3）通過 push 保存各寄存器值，具體的代碼如下:

ENTRY(entry_SYSCALL_64)
/* SWAPGS_UNSAFE_STACK是一個宏，x86直接定義為swapgs指令 */
SWAPGS_UNSAFE_STACK
/* 保存棧值，并設置內核棧 */
movq %rsp, PER_CPU_VAR(rsp_scratch)
movq PER_CPU_VAR(cpu_current_top_of_stack), %rsp
/* 通過push保存寄存器值，形成一個pt_regs結構 */
/* Construct struct pt_regs on stack */
pushq  $ __USER_DS      /* pt_regs->ss */
pushq  PER_CPU_VAR(rsp_scratch)  /* pt_regs->sp */
pushq  %r11             /* pt_regs->flags */
pushq  $__USER_CS      /* pt_regs->cs */
pushq  %rcx             /* pt_regs->ip */
pushq  %rax             /* pt_regs->orig_ax */
pushq  %rdi             /* pt_regs->di */
pushq  %rsi             /* pt_regs->si */
pushq  %rdx             /* pt_regs->dx */
pushq  %rcx tuichu    /* pt_regs->cx */
pushq  $-ENOSYS        /* pt_regs->ax */
pushq  %r8              /* pt_regs->r8 */
pushq  %r9              /* pt_regs->r9 */
pushq  %r10             /* pt_regs->r10 */
pushq  %r11             /* pt_regs->r11 */
sub $(6*8), %rsp      /* pt_regs->bp, bx, r12-15 not saved */

（4）通過匯編指令判斷是否為 x32_abi。

（5）通過系統調用號，跳到全局變量 sys_call_table 相應位置繼續執行系統調用。

這里再給出保存棧的結構示意圖，這里我就引用下別的師傅的圖了。注意這是保存在內核棧中：

5. kernel space to user space

退出時，流程如下：

（1）通過 swapgs 恢復 GS 值

（2）通過 sysretq 或者 iretq 恢復到用戶控件繼續執行。如果使用 iretq 還需要給出用戶空間的一些信息（CS, eflags/rflags, esp/rsp 等）

6. struct cred

咱們要管理進程的權限，那么內核必定會維護一些數據結構來保存，他是用 cred 結構體記錄的，每個進程中都有一個 cred 結構，這個結構保存了該進程的權限等信息（uid，gid 等），如果能修改某個進程的 cred，那么也就修改了這個進程的權限。

下面就是cred的數據結構源碼：

struct cred {
    atomic_t    usage;
#ifdef CONFIG_DEBUG_CREDENTIALS
    atomic_t    subscribers;    /* number of processes subscribed */
    void        *put_addr;
    unsigned    magic;
#define CRED_MAGIC  0x43736564
#define CRED_MAGIC_DEAD 0x44656144
#endif
    kuid_t      uid;        /* real UID of the task */
    kgid_t      gid;        /* real GID of the task */
    kuid_t      suid;       /* saved UID of the task */
    kgid_t      sgid;       /* saved GID of the task */
    kuid_t      euid;       /* effective UID of the task */
    kgid_t      egid;       /* effective GID of the task */
    kuid_t      fsuid;      /* UID for VFS ops */
    kgid_t      fsgid;      /* GID for VFS ops */
    unsigned    securebits; /* SUID-less security management */
    kernel_cap_t    cap_inheritable; /* caps our children can inherit */
    kernel_cap_t    cap_permitted;  /* caps we're permitted */
    kernel_cap_t    cap_effective;  /* caps we can actually use */
    kernel_cap_t    cap_bset;   /* capability bounding set */
    kernel_cap_t    cap_ambient;    /* Ambient capability set */
#ifdef CONFIG_KEYS
    unsigned char   jit_keyring;    /* default keyring to attach requested
                     * keys to */
    struct key __rcu *session_keyring; /* keyring inherited over fork */
    struct key  *process_keyring; /* keyring private to this process */
    struct key  *thread_keyring; /* keyring private to this thread */
    struct key  *request_key_auth; /* assumed request_key authority */
#endif
#ifdef CONFIG_SECURITY
    void        *security;  /* subjective LSM security */
#endif
    struct user_struct *user;   /* real user ID subscription */
    struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */
    struct group_info *group_info;  /* supplementary groups for euid/fsgid */
    struct rcu_head rcu;        /* RCU deletion hook */
} __randomize_layout;

基礎知識介紹完畢，咱們開始介紹咱們內核pwn的最主要的目的。

二

目的

借用arttnba3師傅的原話：“毫無疑問，對于內核漏洞進行利用，并最終提權到 root，在黑客界是一種最為 old school 的美學。

咱們在內核pwn中，最重要以及最廣泛的那就是提權了，其他諸如dos攻擊等也行，但是主要是把人家服務器搞崩之類的，并沒有提權來的高效。

1. 提權(Elevation of authority)

所謂提權，直譯也即提升權限，是在咱們已經在得到一個shell之后，咱們進行深入攻擊的操作，那么請問如何得到一個shell呢，那就請大伙好好學習用戶模式下的pwn吧。

而與提權息息相關的那不外乎兩個函數，不過咱們先不揭曉他們，咱們先介紹一個結構體：在內核中使用結構體 task_struct 表示一個進程，該結構體定義于內核源碼include/linux/sched.h中，代碼比較長就不在這里貼出了。

一個進程描述符的結構應當如下圖所示：

注意到task_struct的源碼中有如下代碼：

/* Process credentials: */

/* Tracer's credentials at attach: */
const struct cred __rcu        *ptracer_cred;

/* Objective and real subjective task credentials (COW): */
const struct cred __rcu        *real_cred;

/* Effective (overridable) subjective task credentials (COW): */
const struct cred __rcu        *cred;

看到熟悉的字眼沒，對，那就是cred結構體指針。前面我們講到，一個進程的權限是由位于內核空間的cred結構體進行管理的，那么我們不難想到：只要改變一個進程的cred結構體，就能改變其執行權限。

在內核空間有如下兩個函數，都位于kernel/cred.c中：

• struct cred* prepare_kernel_cred(struct task_struct* daemon)：該函數用以拷貝一個進程的cred結構體，并返回一個新的cred結構體，需要注意的是daemon參數應為有效的進程描述符地址或NULL,如果傳入NULL,則會返回一個root權限的cred
• int commit_creds(struct cred *new)：該函數用以將一個新的cred結構體應用到進程。所以我們最重要的目的是類似于用戶態下調用system("/bin/sh")一樣,咱們內核態就需要調用commit_creds(prepare_kernel_cred(NULL))即可達成提權功能！

這里我們也可以看到prepare_kernel_cred()函數源碼：

struct cred *prepare_kernel_cred(struct task_struct *daemon)
{
    const struct cred *old;
    struct cred *new;

    new = kmem_cache_alloc(cred_jar, GFP_KERNEL);
    if (!new)
        return NULL;

    kdebug("prepare_kernel_cred() alloc %p", new);

    if (daemon)
        old = get_task_cred(daemon);
    else
        old = get_cred(&init_cred);

三

保護措施

1. KASLR

與用戶態ASLR類似，在開啟了 KASLR 的內核中，內核的代碼段基地址等地址會整體偏移。

2. FGKASLR

KASLR 雖然在一定程度上能夠緩解攻擊，但是若是攻擊者通過一些信息泄露漏洞獲取到內核中的某個地址，仍能夠直接得知內核加載地址偏移從而得知整個內核地址布局，因此有研究者基于 KASLR 實現了 FGKASLR，以函數粒度重新排布內核代碼。

3. STACK PROTECTOR

類似于用戶態程序的 canary，通常又被稱作是 stack cookie，用以檢測是否發生內核堆棧溢出，若是發生內核堆棧溢出則會產生 kernel panic

內核中的 canary 的值通常取自 gs 段寄存器某個固定偏移處的值。

4. SMAP/SMEP

SMAP即管理模式訪問保護（Supervisor Mode Access Prevention），SMEP即管理模式執行保護（Supervisor Mode Execution Prevention），這兩種保護通常是同時開啟的，用以阻止內核空間直接訪問/執行用戶空間的數據，完全地將內核空間與用戶空間相分隔開，用以防范ret2usr（return-to-user，將內核空間的指令指針重定向至用戶空間上構造好的提權代碼）攻擊。

SMEP保護的繞過有以下兩種方式：

• 利用內核線性映射區對物理地址空間的完整映射，找到用戶空間對應頁框的內核空間地址，利用該內核地址完成對用戶空間的訪問（即一個內核空間地址與一個用戶空間地址映射到了同一個頁框上），這種攻擊手法稱為 ret2dir；
• Intel下系統根據CR4控制寄存器的第20位標識是否開啟SMEP保護（1為開啟，0為關閉），若是能夠通過kernel ROP改變CR4寄存器的值便能夠關閉SMEP保護，完成SMEP-bypass，接下來就能夠重新進行 ret2usr，但對于開啟了 KPTI 的內核而言，內核頁表的用戶地址空間無執行權限，這使得 ret2usr 徹底成為過去式。

四

環境利用

首先咱們拿到個ctf題目之后，咱們一般是先解包，會發現有這些個文件：

1.baby.ko

baby.ko是包含漏洞的程序，一般使用ida打開分析,可以根據init文件的路徑去rootfs.cpio里面找。

2.bzImage

bzImage是打包的內核代碼，一般通過它抽取出vmlinx,尋找gadget也是在這里。

3.initramfs.cpio

initramfs.cpio是內核采用的文件系統。

4.startvm.sh

startvm.sh是啟動QEMU的腳本

5.vmlinux

靜態編譯，未壓縮的內核文件，可以在里面找ROP

6.init文件

在rootfs.cpio文件解壓可以看到，記錄了系統初始化時的操作，一般在文件里insmod一個內核模塊.ko文件，通常是有漏洞的文件

7..ko文件：需要拖到IDA里面分析找漏洞的文件，也即一般的漏洞出現的文件

---
之后咱們可以利用rootfs.cpio解壓的文件中看到init腳本，此即為加載文件系統的腳本，在一般為boot.sh或start.sh腳本中也記錄了qemu的啟動參數

如何將exp送入本地調試

我的辦法比較笨，那就是本地編譯然后放到文件系統里面在壓縮為cpio，這樣再啟動虛擬機的時候就會重新加載這個文件系統了。