CVE-2019-13272

PTRACE_TRACEME CVE-2019-13272 local privilege escalation vulnerability analysis

PTRACE_TRACEME — уязвимость повышения привилегий в ядре Linux, обнаруженная Янном Хорном (Jann Horn) в июле 2019 года.

Анализ уязвимости:

Ptrace — это системный вызов, который предоставляет механизм, позволяющий одному процессу (tracer) наблюдать и управлять выполнением другого процесса (tracee), а также проверять и изменять его образ ядра (core image) и регистры. В основном используется для установки точек останова (break point) при отладке и отслеживания вызовов системных вызовов.``` c 1 396 kernel/ptrace.c <<ptrace_attach>> ptrace_link(task, current); 2 469 kernel/ptrace.c <<ptrace_traceme>> ptrace_link(current, current->real_parent);

Существует два способа установить trace-отношение:
  - Процесс вызывает функцию fork, и его дочерний процесс вызывает `PTRACE_TRACEME` (соответствует функции `ptrace_traceme` в ядре) для инициализации tracee.
  - Процесс вызывает `PTRACE_ATTACH` или `PTRACE_SEIZE` (соответствует функции `ptrace_attach` в ядре) для инициализации tracer’а, который будет трассировать другой процесс.
  
Независимо от того, какой способ используется, в конечном итоге вызывается функция `ptrace_link` для установки trace-отношения между tracer’ом и tracee.
- Два параметра, передаваемые в `ptrace_link` для `ptrace_attach`: это 'task' (tracee) и 'current' (tracer)
- Два параметра, передаваемые в `ptrace_link` для `ptrace_traceme`: это 'current' (tracee) и 'current->real_parent' (tracer)

Здесь необходимо обратить внимание на то, какие именно два параметра tracer’а и tracee передаются в двух вышеуказанных способах при вызове функции `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
}

Как в коде выше, поскольку задачи B и C уже имеют trace links в этот момент, запрос ptrace может быть отправлен напрямую к C через B, после чего будет вызвана функция `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 }

Взглянув на приведенный выше код, мы видим, что функция `ptrace_access_vm` вызывает функцию `ptracer_capable`, которую мы проанализировали ранее, чтобы определить, может ли быть выполнен ее запрос. Согласно результатам предыдущего анализа, '*ptracer_cred*', сохраненный в задаче C на данный момент, является привилегированным cred, поэтому `ptracer_capable` будет пройдена в этот момент, что означает, что на предыдущий вопрос дан ответ. В этом случае задача B с обычными привилегиями может использовать ptrace для отправки запросов на чтение и запись в память и область кода задачи C, имеющей привилегии root. Теперь привилегия '*ptracer_cred*' предоставляется задачей C в двух случаях: - Задача C выполняет `execve(suid binary)` для повышения привилегий - Задача B с обычными привилегиями может выполнять ptrace для чтения и записи в область кода и памяти задачи C, тем самым управляя задачей C для выполнения произвольных действий Является ли сочетание этих двух ролей полноценной эскалацией привилегий? Прежде чем ответить на этот вопрос, давайте рассмотрим, как эта уязвимость эксплуатируется и как она была исправлена. # Кратко об исправлении уязвимости 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.

Давайте взглянем на патч: '*\_\_task_cred(new_parent)*' заменён на '*current_cred()*' Патч указывает, что при выполнении PTRACE_TRACEME, '*ptracer_cred*' не использует cred родительского процесса, а использует собственные cred. # Эксплуатация Ключ к эксплуатации этой уязвимости — найти подходящую исполняемую программу для запуска задачи B. Эта программа должна удовлетворять следующим условиям: - Обычный пользователь может её вызвать. - Должен быть этап повышения привилегий до root в процессе выполнения. - После получения прав root должна быть возможность понизить привилегии. (Цель временного повышения до root — позволить задаче C получить ptracer_cred от root, а цель понижения привилегий — позволить B быть присоединённым процессом с обычными привилегиями ptrace.) Вот 3 примера кода для эксплуатации: - [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) В [эксплойте Jann Horn](https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=401217) используется встроенная в систему программа [pkexec](http://manpages.ubuntu.com/manpages/trusty/man1/pkexec.1.html) (для настольной версии) для запуска задачи B. [pkexec](http://manpages.ubuntu.com/manpages/trusty/man1/pkexec.1.html) позволяет привилегированному пользователю запускать другую программу с правами другого пользователя; используется в фреймворке аутентификации polkit. При использовании параметра --user он позволяет процессу повысить привилегии до root, а затем понизить до указанного пользователя, поэтому его можно использовать для построения задачи B. Кроме того, нужно найти другие исполняемые программы, которые выполняются через polkit (Jann Horn использует хелперы). Эти программы должны быть такими, чтобы обычный пользователь мог выполнить их через pkexec без аутентификации (многие программы, выполняемые через polkit, требуют аутентификации через всплывающее окно). Способ выполнения следующий:``` sh /usr/bin/pkexec —user nonrootuser /user/sbin/some-helper-binary

CVE-2019-13272

Популярное

анализ эксплойта

Ссылки